draft-gont-6man-slaac-renum-00

[Lee Howard <[e-mail]>]

1. Introduction

I would prefer "A common deployment scenario" over "Probably the most 
common deployment scenario."

"tipically" --> "typically"

3.1 Improvement to SLAAC

The passive voice confused me here. I think you mean, "When a host 
receives an RA from a router from which it has received other RAs, but 
this RA does not include PIO (+A) for the previous prefix, it (the host) 
should set the Preferred Lifetime for addresses in that prefix to 0."

This solution assumes that a router will include all prefixes in ever 
RA; rfc4861 (NDP) says that RAs in response to RSs, or during 
initialization, "a router SHOULD include all options so that all 
information (e.g., prefixes) is propagated quickly during system 
initialization." Since it's not a MUST, it's potentially legal for 
routers to send separate RAs with different prefixes. In your proposed 
SLAAC scenario, the host would alternately deprecate each address.

3.3 Stable prefixes

Where most of the discussion on the lists has been.

When I was involved in large networks, we had two problems with stable 
prefixes. First, we had redundant DHCPv6 servers in diverse data 
centers, and no scalable way to share lease information between them. So 
if DHCPv6 server A issued a prefix, but then at renew or reboot or 
whatever DHCPv6 server A was unreachable or DHCPv6 server B just 
responded faster, then server B would issue a prefix from its pools. We 
found some ways to link backend systems such that we could do a few 
stable prefixes based on DUIDs, but it didn't scale (especially 
considering DUIDs are only stable with the gateway).

The other problem was that the network changes constantly. There is no 
assurance that the edge device to which a customer is currently 
connected will remain the same, or that that edge device will remain in 
the same logical hub. For a variety of reasons, there was the potential 
for many thousands of disaggregated prefixes to be leaked into the IGP, 
and that would not be good for the network.

I think this option needs to be included in the draft for the sake of 
completeness, but I still disagree with those who want it to be mandatory.

When a client has learned its address from DHCPv6, does it also have 
this problem? I think it would, until the DHCPv6 lifetime expires. A CE 
router that reboots wouldn't know it needs to send a Reconfigure (and my 
understanding is that there's little support for that option, but I 
haven't tested).

Additional suggestion:

If home gateways implemented RPF, they would simply drop packets from 
invalid (i.e., old) prefixes. We could add a new ICMPv6 message called 
"Invalid Source" which the router would return, notifying the host that 
either that source address prefix is stale, or it was sending to the 
wrong router. Host logic could pretty well sort out whether there was a 
better router to try, might send RSs for more information, and/or might 
deprecate that prefix/address and try a different one, or try DHCPv6.


I note that anywhere IP addresses are used for policy, the "flash 
renumbering" problem exists. In an SD-WAN environment, the controller 
might be able to learn the new prefix from the CE router and trigger new 
security and routing policies, and maybe even update DNS, but it can't 
touch hosts.


I think this draft is important in describing this issue and giving us 
written exploration of solution space, but I don't think the problem 
description needs to advance; ultimately, a solution document should be 
adopted and move forward.


Lee