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

From: Lee Howard <[email-masked]>
Date: Mon, 18 Feb 2019 13:07:37 -0500

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

---

From: Fernando Gont <[email-masked]>
Date: Sat, 23 Feb 2019 06:18:09 -0300

Hi, Lee,

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

> "tipically" --> "typically"

Done.

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

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

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

> 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

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.

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

> 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: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492