stability of IP addresses (was: Finding the appropriate work stream for draft-nottingham-for-the-users)

[Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx>]

On 3/19/19 6:51 AM, Ole Troan wrote:

The IAB is considering adopting this document onto the IAB stream as Informational:

https://datatracker..ietf.org/doc/draft-nottingham-for-the-users/

with a focus on explaining why decisions in the IETF often are or should be  user-focused.

However, in discussion some felt that there might be interest in adopting this document into the IETF stream as a BCP (most likely in the General Area), with a stronger focus on setting guidelines for working groups when they face these sorts of issues. 

The IAB is seeking input from the community about the level of interest (or disinterest) in the latter approach. Please do so on this list, by sending mail to architecture-discuss@xxxxxxx (our public discussion list) or to iab@xxxxxxxx (to reach just the IAB).  You can also discuss with individual IAB members in Prague.

In 6man we have a discussion triggered by a draft (slaac-renum) where “for-the-users” is very relevant (thank you for publishing).
The discussion is exposing the tussle between network operators wanting operational freedom of being able to instantly renumber end-user networks against the end-user’s expectation of stable addressing (and planned renumbering).

The stronger the IETF consensus behind this document, the easier it will be to use it to guide working group discussion and decisions.

In this case I might frame the discussion differently.   Users clearly have an interest in having associations between (some) application instances maintained indefinitely.   It's not the network's job (nor IETF's) to decide when this is in users' interests. 

The question can therefore be reframed as an engineering tradeoff between layers - e.g. at what point should higher-layer protocols have to be responsible for maintaining such associations when needed?

This "point" could be expressed in terms of minimum address-to-interface binding lifetime, how much advance notice should be provided to endpoints before renumbering occurs, and what's the minimum overlap time between old and new addresses. (*)   Too short a lifetime, or too little notice, or too little overlap, puts a huge burden on the higher layers, makes it very difficult for them to recover, and results in traffic storms.   Too long a lifetime and/or too much notice puts pressure on the network routing system, and the routers, to accommodate the instant renumberings that are sometimes unavoidable.

I suspect that this tussle is entirely unavoidable.  IETF's problem is that not that it hasn't made the tussle magically disappear, but rather that nobody's in charge of the architecture.

The reason we haven't picked a general-purpose higher-layer mechanism for adapting to renumbering by now, is that we've been too busy pretending that it's not necessary.    So none of the pieces necessary to make it work are in place.   We don't even have a mechanism to allow an endpoint to discover a peer's application endpoint's current address/port (**).

Keith

(*) I'll put stakes in the ground just for discussion purposes: minimum address-to-interface binding lifetime should be at least seven days, and minimum advance notice should be at least 24 hours, minimum overlap time should be at least 24 hours.   But these are not questions that a group discussing SLAAC should be having to try to answer.

(**) someone will surely claim that DNS can do this, but not without (at a minimum) additional profiling for exactly how it's to be used.  DNS doesn't make any distinction between address used for initial connection attempt and address/port used for reconnects, and there's no good way for individual endpoints or networks to update the RRs that application endpoints would need to use to make such a discovery.  Also, DNS assumes that query results can be cached, and that a fixed TTL makes sense.   There may also be security issues with publicly disclosing application endpoint information - seems like such advertisement would greatly aid DoS attacks.