Re: draft-ietf-6man-slaac-renum: Honoring small Lifetime values

[David Farmer <[e-mail]>]

On Thu, Aug 27, 2020 at 11:28 AM Fernando Gont <[e-mail]>
wrote:

> Hello, David,
>
> On 27/8/20 12:46, David Farmer wrote:
> [....]
> >
> > Why isn't setting the Preferred Lifetime = 0 sufficient to deprecate a
> > PIO? Any new sessions will stop using that prefix and current TCP
> > sessions will timeout eventually. Why is it necessary for sessions to
> > terminate immediately when the PIO is deprecated? Is there some
> > advantage I'm not seeing? I don't see these questions answered in the
> > drafts.
>
> What the change means is that, if a router is in a position to
> positively know that the prefix is gone, it *can* signal that condition.
>
> Leaving addresses lying around doesn't come for free. e.g., you cannot
> communicate with the new owner of the address. Besides, there are
> implementations that enforce a limit on the maximum number of configured
> addresses.
>
> That's the main thing. Now, if you ask me, I also think that if the
> addresses are known to fail, it is better to terminate connections and
> resume them afterwards. TCP timeouts can be particularly long, at which
> point the user experience is not really good.
>

Ok, then someplace in this group of drafts please explicitly address why
the current mechanism of deprecation, PL=0, is not sufficient and the
change of allowing hosts to accept VL = 0 is necessary, or at least the
advantages of accepting VL=0 over only PL=0.  Currently, you acknowledge
that hosts can act on PL=0, but I see nothing about why this is
insufficient or even what advantages accepting VL=0 will additionally
provide.


> > Now, imagine the following misconfiguration; A network with two
> > routers, RTR A and RTR B. The routers each advertises two PIOs, for
> > Prefix A and Prefix B, but each with different time out values. RTR A
> > advertises Prefix A with Preferred Lifetime = 45 minutes and a Valid
> > Lifetime = 90 minutes and Prefix B with Preferred Lifetime = 0 minutes
> > and a Valid Lifetime = 0 minutes. And, RTR B advertises Prefix A with
> > Preferred Lifetime = 0 minutes and a Valid Lifetime = 0 minutes and
> > Prefix B with Preferred Lifetime = 45 minutes and a Valid Lifetime = 90
> > minutes.
> >
> > With RFC 4862 as currently specified, both prexies will be valid and the
> > hosts on the network will have stable IPv6 addresses in each prefix, as
> > long as the RAs are advertised more than every two hours, which is
> > pretty common. However, if changed as proposed, hosts will not have
> > stable IPv6 addresses and will oscillate between addresses on Prefix A
> > and Prefix B as the RAs are received from each router.
>
> The real solution to this is RFC8028. As soon as you employ multiple
> routers/prefixes on a single subnet, if you don't have RFC8028, you are
> asking for problems.
>
> In the scenario you describe, without RFC8028 both routers will compete
> for being the default router. If the host keeps the prefix (as in the
> scenario you describe), but it happens to send its packets to the other
> router, packets would likely be egress-filtered.
>
> With RFC8028, one would expect that the host knows that both routers can
> route that prefix. When the host receives an RA from RTB with VL=0, it
> will simply disassociate the prefix with this particular router. BUt
> since there was another router advertising the same prefix, addresses
> would not me removed.
>

I'm sorry, but RFC8028 won't address this, at least as currently specified.
Again this is a perverse misconfiguration of the PIOs, where each router is
saying, I'm right and the other router is explicitly wrong. The routing
problem you are talking about, that RFC8028 intends to resolve, may or may
not actually exist, because it involves both routing and filtering of
traffic, without the filtering of some kind the routing problem doesn't
exist.

For this situation to occur the routers, or the person managing them, needs
explicit knowledge of the existence of the other router, and the PIO the
other router is advertising. In the intended scenario that RFC8028
resolves, the two routers and the people managing them probably have no
knowledge of, or even cares about, the existence of the other router.

For something like this misconfiguration to occur, I expect it needs manual
intervention, probably in some kind of failed or misguided manual renumber
attempt, probably in an enterprise network. In that case, both routers
could conceivably deliver the traffic if the hosts were to configure both
prefixes as would currently occur. You seem to be focusing only on CPE and
ISPs scenarios, but changing SLAAC affects all hosts whatever kind of
network scenarios they are part of and their particular quirks.

I don't think this perverse misconfiguration by itself is a sufficient
reason to not make the change you are proposing, but we need to try to
think of all the corner case scenarios, be they perverse or
simple misconfigurations, where this change could have bad results. Are
there other corner case scenarios that should be considered?

I was thinking of another scenario, what if you were unplugging one
interface to move it to a new network and then plugging a new interface
into the old network. This is a flash renumbering scenario where you don't
want to deprecate the PIOs, but the router isn't going to have knowledge of
the change nor any reason to send a PL=0 or VL=0, so this change is mute in
that scenario.

Thanks

-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================