Subject: [v6ops] Thoughts on draft-gont-6man-slaac-renum

From: Jen Linkova <[email-masked]>
Date: Thu, 28 Mar 2019 21:30:39 +1100

I've been thinking about the draft and the renumbering/prefix failure
problem in general...

IMHO there is no a single silver bullet so maybe it makes sense to
look at issues caused by misbehaving CPEs which are not invalidating
"old" prefixes after getting new prefix (or network  address change in
general) and prioritize them. All issues are painful but some are more
painful than others for operators...

Here is what I've come up with for the scenario when the network
prefix has changed and the host has now two (or more) addresses from
different prefixes and not all them belong to the network anymore -
based on the draft and my experience with that problem:.

#1: High priority/must have: ensure that the host selects an address
from the "working" prefix for new sessions.

#2: Med/High priority, nice to have: preserving existing connections
or at least explicitly quickly terminate them instead of letting them
timing out.

#3: Med/Low priority: ensuing that if the old prefix is reassigned to
another part of the network, the host can communicate to new owners of
the prefix

#4: Preventing the host from exceeding the number of allowed/supported
# of addresses on the interface.

Obviously it would be highly desirable to minimize the disruptive
changes to the protocol.

So what can we do to address those issues:

Problem #1:

1.0) Consider doing Happy Eyeballs for source addresses if the host
has GUAs from more than one /64. What do the host implementors think?
It would help with other blackholing cases as well..

1.1) whatever caused the issue, in many scenarious (esp.
residential/hotsopt deployments) it does not make much sense to have
PIO lifetime being significantly higher that default router lifetime.
Therefore two things could be done:

1.1.1) Update RFC4861 with smth like:

    the default value for AdvPreferredLifetime should be Max
(1.2*AdvDefaultLifetime; 3*MaxRtrAdvInterval)

    the default value for AdvValidLifetime should be
Max(1.5**AdvDefaultLifetime; 3*MaxRtrAdvInterval, 2hrs)

(MAX is used to ensure that deprecating the router does not
automtically deprecate the prefix if the PIO lifetime is not
explicitly configured)

1.2.2) Provide guidleines to operators recommenting putting sensible
values for the corresponding timers for DHCP-PD leases and CPE
configs.

1.3) [additional crazy idea I was playing with...] changing the
network addressing could be considering as changing the PvD. What if a
router, when sending RAs, uses LLA which is a stateless hash function
of PIOs?

So then let's say the router has a prefix P1 configured on the
interface. It sends RAs with the PIO1 using LLA1 = f(P1).

Then the prefix has changed (reboot, crash, uplink flap - or even
worse, the whole CPE was replaced). The router (the same or new one)
has now another prefix P2 on the interface. Then it wll be sending RAs
from LLA2 = f(P2). RFC8028-compliant hosts (aka supporting rule 5.5)
would invalidate LLA1 as a next-hop by using NUD and by starting using
LLA2 they would select addresses from P2 as the source addresses.

Problem #2:

2.1) Would it be reasonable to expect a CPE (or an operator, at BNG
level, for example) to implement a kind of basic BCP38 and send ICMPv6
error back if the packet coming from the downstream has the source
IPv6 address from the prefix which is not delegated to that network?
At least it would give the hosts some clear signal...

Problem #3

Not sure how much it's a problem really but 1.1) (see above) should
help as well as addresses would be invalidated much faster than in 30
days.

Problem #4:

Would it be really a problem if problems 1-3 are fixed? If the OS
limit for valid addresses is too low, maybe the OS needs to be fixed?

One might say that there is no point of propising any changes on CPEs
as if they are not doing the right things now they are very unlikely
to implement the proposed changes correctly. However the main issue is
related to keeping the state between reboots and/or coordinating
different components (DHCPv6 client and radvd etc) - and there is a
case of CPE replacement. Changes which are limited to default values
changes or modifying just one component (BCP38) might be more
successful.

Thoughts?

-- 
SY, Jen Linkova aka Furry

---

From: Bob Hinden <[email-masked]>
Date: Thu, 28 Mar 2019 11:42:54 +0100

Jen,

This is useful.

It reminded me to say, this draft would be better if it didn’t use the word renumbering.   Renumbering is a much bigger topic that includes updating DNS records, updating filter/firewall rules, and any other place where prefixes are recorded.   I think this draft is focused on a specific issue.   

However, there will be related issues if a site's prefix changes quickly.

Bob

> On Mar 28, 2019, at 11:30 AM, Jen Linkova <[email-masked]> wrote:
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Philip Homburg <[email-masked]>
Date: Thu, 28 Mar 2019 14:55:37 +0100

>from the "working" prefix for new sessions.

I'd like to add that this should happen relatively quickly. Say within
one minute of the old prefix not working anymore.

>or at least explicitly quickly terminate them instead of letting them

Here I'd like to add be conservative, do not break connection unless
the connection cannot work anymore. Do not break a connection because,
for example, one RA got lost.

>another part of the network, the host can communicate to new owners of

I think there are two cases here:
- the old prefix is reassigned after any DHCP lease has expired
- or, two overlapping leases for the prefix exist.

>It would help with other blackholing cases as well..

My experience with Happy Eyeballs is that it is already hard to do
for destination addresses. It would be nice to have a standard algorithm
that also includes source addresses, but I think it is unlikely anything
would both get concensus and get widely deploy on a reasonable time scale.

To consider just one corner case, take the DNS stub resolver in a C library
(for example glibc). Now make that also deal with probing multiple source
addresses.

>Therefore two things could be done:

With the requirement that the old prefix should not be used on a time scale
of minutes, making those changes will not have the desired effect unless
Max(1.2*AdvDefaultLifetime; 3*MaxRtrAdvInterval) is in the order of one
minute. Which requires a huge increase in RA multicast rate.

>values for the corresponding timers for DHCP-PD leases and CPE

Again that doesn't solve problem number 1 in a timely matter.

>router, when sending RAs, uses LLA which is a stateless hash function

It seems to me that this could work.

>At least it would give the hosts some clear signal...

The tricky thing here is for the host to figure out that it is the 
source address that causes problems. Though I guess destination unreachable
codes could be allocated.

>help as well as addresses would be invalidated much faster than in 30

I think it would be good to have a CPE spec recommend defaulting to 
valid lifetimes on the order of hours.

Having the host limit the valid lifetime may result in hosts not having
any global addresses if a router goes down for a long time. Given the
complexity of dealing with link local addresses, that could leave hosts
with no network.

So in my opinion it is best if the network controls the lifetimes.

>limit for valid addresses is too low, maybe the OS needs to be fixed?

It shouldn't be too hard for hosts to expire old addresses in case there
are too many.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 28 Mar 2019 17:22:48 +0100

>router, when sending RAs, uses LLA which is a stateless hash function

It just occurred to me that generating a new random link local address upon
boot would also work.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 28 Mar 2019 17:49:57 +0100

Hello, Jen,

Thanks so much for your feedback! Comments in-line....

> painful than others for operators...

Agreed.

> another part of the network, the host can communicate to new owners of

#2 and #3 are essentially the same thing. If you want to talk to the new
owner of the prefix, you have to tear down connections that employ the
stale prefix. i.e., what you do on #2 is an implicit decision on what
you do on #3.

> # of addresses on the interface.

This is somehow tied to #2-#3 too. If you don't do proper "garbage
collection", eventually you'll hit the limit.

> It would help with other blackholing cases as well..

I wouldn't go this path... at least for *this* issue.

> automtically deprecate the prefix if the PIO lifetime is not

This is essentially what Section 5.1.1.2 proposes. We are updating the
I-D so that Section 5.1.1.1 is replaced with a proposal to set the PIO
valid lifetime to the router lifetime.

FWIW, while it would seem to me that there's no need to set the PIO
valid lifetime to a value longer than the router lifetime, I wouldn't
mind to increase it a bit over that, as you suggest.

> values for the corresponding timers for DHCP-PD leases and CPE

Agreed. ANy proposals here?

> LLA2 they would select addresses from P2 as the source addresses.

Might be worth exploring, but would seem overkill to address just this
issue.

> At least it would give the hosts some clear signal...

Problem here is the semantics of ICMP error messages: they signal soft
errors, rather than hard errors.

> help as well as addresses would be invalidated much faster than in 30

This can be addressed with some version of what we propose in Section
5.1.3 of our I-D.

One variant of that would be to count (say in variable "n")the number of
consecutive RAs that contain PIOs other than the previously advertised
prefix.

we specify N1 and N2.

when n >= N1, we unprefer the address
when N >= N2, we remove the corresponding addresses

> limit for valid addresses is too low, maybe the OS needs to be fixed?

Well, I would understand OS vendors arguing: do you really want more
than , say 16 configured prefixes?

> changes or modifying just one component (BCP38) might be more

I do agree that there's no silver bullet and that it would be correct to
attack the problem from different angles.

Your suggestions don't seem to be far from what we are proposing in our
I-D, though. -- we hope that the next rev of the I-D will be more
clearly in line with that...

Thanks!

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

---

From: Martin Huněk <[email-masked]>
Date: Thu, 28 Mar 2019 21:20:16 +0100

Hi,

please see reply inline for mentioned issues.
> from the "working" prefix for new sessions.

Wouldn't be just better to add a rule to RFC6724 which would say the longer 
Preferred lifetime wins? Let say between rule #7 and #8?
> or at least explicitly quickly terminate them instead of letting them

Question is if unknown prefix to the router should be treated according to BCP 
38 - dropped or if it should be treated as special case (for let say home 
router) and should get rejected. And if so, what should be the code.
> another part of the network, the host can communicate to new owners of

As valid lifetime should not be longer than PD lease time, then it should not 
be a problem. As it should not be leased to another holder before the first 
lease expires.
> # of addresses on the interface.

I don't think that we would be able to do that. What I know such limitations 
were placed there (at least in Linux) as reaction to RA flood attacks. By 
rising that limitations, OS would became more vulnerable to those.

I think that if we are talking mainly about home network after the CPE. It is 
the false presumption that RA guard is reality there. We as a network people 
might have RA guard deployed at home, but at least what I can tell usual home 
network has one router (cheapest available option) and sometimes one 
unmanageable L2 switch. Same applies to some small enterprises or even some 
medium ones outside telco.

Just a few thoughts:
Do we really need to change the constant of default Pref./valid lifetime by 
another constant? Would it fit all?

Wouldn't be better to specify CPE behavior towards the prefixes received by 
DHCPv6-PD? Like valid lifetime should not exceed in any single moment 1/2 of 
original lease time and preferred lifetime should not exceed 1/4 and either 
should be valid longer then the lease itself (we have that already). Those 
fractions are just example.

From ISP point of view, I'm quite happy to lease the clients prefix for 
several days (probably not for the whole month), as I give client stable 
prefixes, it is not problem for me. In this case having valid lifetime to be a 
fraction of lease time would at least protect clients devices from 
deconfiguration of valid prefix by the RA flood (at least for 2 hours). Even 
that it doesn't save them the internet connection, at least they would be able 
to receive packets.

Maybe it has been already discussed here, in that case I apologies. But 30/10 
minutes seems too strict and uncalled for.

Martin

---

From: Fernando Gont <[email-masked]>
Date: Fri, 29 Mar 2019 12:05:28 +0100

> Preferred lifetime wins? Let say between rule #7 and #8?

No. In a multi-prefix network, for example, different routers might be
employing different preferred values for the different prefixes.

The semantics of the "preferred lifetime" is the amount of time for
which an address may be preferred, rather than an intrinsic measure of
"how preferred" such addresses should be.

> router) and should get rejected. And if so, what should be the code.

Either way, icmp error messages signal soft (transient) error conditions.

> be a problem. As it should not be leased to another holder before the first 

There are folks that employ PD lifetimes in the order of months.... SO
capping the PIO lifetimes to the PD lifetimes is not a guarantee that
you are going to get "shorter" lifetimes....

> rising that limitations, OS would became more vulnerable to those.

If we hit a limit of, say, 16 addresses because 15 of them are stale,
we're clearly doing a bad job at "garbage collection".

> fractions are just example.

That *might* work. However, I'm of the idea that it is better to use
shorter lifetimes and refresh them (i.e., even if the CPE router gets a
lease of, say, 10 days, it should advertise PIOs of, say, 30 minutes,
and refresh such lifetimes as gratuitous RAs are sent on the LAN side),
rather than advertising PIOs which long lifetimes that then, if things
break, ensure brokeness for a long time.

> several days (probably not for the whole month), 

If you give clients stable prefixes, than the lease time does not really
matter.

> as I give client stable 

If you are referring to ND/SLAAC attacks, then the idea is quite simple:
either you filter RAs, or you don't. If you do, you don't need to play
with timers to protect from such attacks. If you don't, then there are
so many possible attack vectors that simply using timers to mitigate one
specific vector will not have any practical impact.

> minutes seems too strict and uncalled for.

Could you please elaborate?

Thanks!

Cheers,