Re: A common problem with SLAAC in "renumbering" scenarios

[Fernando Gont <[e-mail]>]

On 20/2/19 06:32, Mark Smith wrote:
[....]
>>> - As Ole implied, TCP uses addresses as identifiers, so TCP expects
>>> that the address will persist for the entire duration of the TCP
>>> connection, regardless of how long that duration is.
>>
>> Your are turning a kludge into a design principle.
> 
> It's been a design assumption and expectation rather than a principle,
> and an expectation TCP has had since 1974 (see RFC675, 2.2  "Sockets
> and Addressing"  (That's TCPv1, before IP was split off)).
> 
>  <snip>
> 
>>
>> Clearly, with your model of TCP connections surviving interface up/downs
>> and the default lifetimes, you really have a host that is unusable,
>> except in very specific network conditions -- such as: the host never
>> moves (quite unlikely these days)
> 
> A 2013 presentation that makes that observation and some others.
> 
> "The Rapid Rise of the Mobile Multihomed Host, and What It Might Mean
> to the Network"
> http://www.ausnog.net/sites/default/files/ausnog-2013/presentations/D01%20P06-the%20rapid%20rise%20of%20the%20mobile%20multihomed%20host.pdf
> 
> 
>> and nothing (including the CPE) fails
>> (quite unlikely).
>>
> 
> I'm not saying these behaviours and expectations are necessarily correct today.

Besides "mobile" nodes, we have had RFC4941 for quite a long time now.
Temporary addresses are preferred over stable addresses in RFC6724. --
so short-lived addresses are more the norm than the exception for IPv6,
I'd say.



> What I am saying is that they are and have been foundation design and
> implementation assumptions that have been in place for multiple
> decades. I think the longer a foundation assumption has been in place,
> the more care and consideration you need to give to changing it,
> because there can be unexpected impacts. Given those impacts, it may
> be better to preserve them and design around them, compared to trying
> to change them ("boiling the ocean"). The Mobile IP people, for
> example, took this approach.

Based on the deployment level of Mobile IP, I'm not sure we want to
follow that road ;-)



> People have said moving to multi-path transport layer protocols is
> trying to boil the ocean.
> 
> Compared to providing stable PD prefixes within the BNG
> infrastructure, I consider upgrading CPE to be boiling the ocean -
> waiting on a CPE vendor to develop that firmware (depending on their
> development priorities you may be waiting 3 to 6 months or possibly
> longer), testing, and then deploying 100s of 1000s of CPE software
> upgrades during many middles' of the night, with a risk of a
> percentage of upgrades failing.

Note: me, I think that many CPEs will never store prefixes on stable
storage. So, as far as *I* am concerned, the CPE advice is "this is what
you should do if you want to be nice".

As noted before, a host cannot rely on the ISP to do stable prefixes,
nor on CPEs to be nice. So if you want to be robust, the best place to
improve such robustness is at the host.



> That's if you have managed CPE. If you
> support BYO CPE (very common in Australia), then the time frame for
> CPE functionality changes through upgrades is in the order of 5 years
> or more, because people don't replace BYO CPE unless it stops working,
> and they don't upgrade firmware either if it subjectively seems to
> them to be working.

I agree with you in this respect. That's why I said you cannot rely on
the CPE doing "the right thing" to get this problem solved.



> Upgrading ISP network infrastructure and back-end systems isn't easy
> either, however it is within house so runs to your schedule and
> resource availability, and all customers using that
> infrastructure/system gain the benefit without having any changes made
> to their equipment or configuration.

An ISP may have its own reasons for doing dynamic prefixes. A poll made
by Jordi indicates that 37% of surveyed ISPs employ dynamic prefixes.
That's a significant percentage... and you want host to be robust in
such scenarios, too.


-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492