Re: [v6ops] A common problem with SLAAC in "renumbering" scenarios

[j h woodyatt <[e-mail]>]

Hi Fernando,

It matters a lot what “unsolicited” means, c.f. the final prepositional phrase in this explanation from Section 2.3:

   The general operating principle is that transport layer traffic is
   not forwarded into the interior network of a residential IPv6 gateway
   unless it has been solicited explicitly by interior transport
   endpoints, e.g., by matching the reverse path for previously
   forwarded outbound traffic, or by matching configured exceptions set
   by the network administrator.

The use of a PCP server or the selection of the “transparent mode” configuration option *is* a solicitation of inbound flows to passive listeners. There is no recommendation for the default configuration of either a PCP server or the transparent mode. Under a strict interpretation of only RFC 6092 (without attempting to reference RFC 4864 normatively as one hopes external bodies would not do), it MAY be the case that inbound flows to passive listeners are solicited by DEFAULT until explicitly configured otherwise.

It’s RFC 4864 that recommends denying all inbound flows to passive listeners, and RFC 6092 was carefully written to remain neutral on that point. Precisely because we expected RFC 6092 to be input to external standards, and we expected that some bodies would require transparent mode by default.


--james woodyatt <[e-mail]>



> On Feb 20, 2019, at 01:59, Fernando Gont <[e-mail]> wrote:
> 
> 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
> 
> 
> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------