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

[Fernando Gont <[e-mail]>]

Hi, Lee,

*Thanks* for providing feedback on the I-D! ;-)  Comments in-line....

On 18/2/19 15:07, Lee Howard wrote:
> 
> 
> 1. Introduction
> 
> I would prefer "A common deployment scenario" over "Probably the most
> common deployment scenario."
> 
> "tipically" --> "typically"

Done.



> 
> 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."

Not at once. The very reason for which we use a flag (LTA) in the
algorithm is so that it requires two consecutive RAs with PIOs that lack
the previously-advertised prefix for any changes to occur.


That is:

1) Two RAs with PIOs without previous prefix -> stale addresses become
un-preferred

2) Two more RAs with PIOs without previous prefix -> stale addresses are
removed.



> 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.

You'd only deprecate (but not remove) the addresses if you get two RAs
with other PIOs. And remove the addresses if you receive a total of four
consecutive RAs with PIOs that do not advertise the
previously-advertised prefix.




> 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.

You mean the option to "solve" the problem by making the prefixes stable?

The problem with this option -- as any other option that does not
"happen" on the host -- is it's not under the control of the host.

Stupid example: Say your ISP does not do stable prefixes. Clearly, you
are in trouble. You need your hosts to behave in a way that even if you
ISP doesn't play nice in this respect, things still work for you.



> When a client has learned its address from DHCPv6, does it also have
> this problem? I think it would, until the DHCPv6 lifetime expires. 

I assume it would. But in all scenarios I've seen, addresses on the
local side are generated via SLAAC (not DHCPv6).


> 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).

In this case you'd be screwed, I guess, since the server will not send
you a RECONFIGURE (modulo the fact that it was been argued that
RECONFIGURE is not widely supported), but also the client will not send
a RENEW, either.

Forcing the CPE to send RECONFIGUREs upon reboot would need more stable
storage on the CPE side, too.



> 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.

Problem is: In order for this to work you need both the CPEs and the
hosts to be updated.  The CPE might or might not ever be updated. --
many require manual updates, and are employed as long as they still work.

The host-side improvements solve the problem even if neither the network
nor the CPE play nice.



> 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.

So far we have elaborated on the problem only as much as necessary to
justify why we need a solution. I'd hope that at least by the time we
publish the next rev, the problem is well-understood (if it wasn't) and
it's clear that we should do something to solve it.

Thanks!

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