Subject: Moving draft-gont-slaac-renum forward (fwd: New Version Notification for draft-gont-6man-slaac-renum-06.txt)

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Apr 2020 16:45:30 -0300

Folks,

I've just posted a revision of draft-gont-6man-slaac-renum 
(<https://www.ietf.org/internet-drafts/draft-gont-6man-slaac-renum-06.txt>), 
which incorporates these changes:

* It updates the section on the default PIO lifetimes (Section 4.1.1) 
according to the discussion we had both at the 6man interim meeting and 
on the mailing-list.

* Added an "Implementation status" section

At this point, we would like 6man to be polled for adoption of this 
document as a wg item.

The topic and variants of this document have been discussed for over a 
year now, with the problem statement document becoming a wg item of 
v6ops (draft-ietf-v6ops-slaac-renum).

We believe that both the topic and the document have received a fair 
share of interest and discussion, and that it is time for the wg to make 
a decision on the document, for the wg to continue to work on it as a 
working group document.

Thanks!

Cheers,
Fernando

-------- Forwarded Message --------
Subject: New Version Notification for draft-gont-6man-slaac-renum-06.txt
Date: Mon, 06 Apr 2020 12:37:26 -0700
From: [email-masked]
To: Fernando Gont <[email-masked]>, Jan Zorz <[email-masked]>, 
Richard Patterson <[email-masked]>

A new version of I-D, draft-gont-6man-slaac-renum-06.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:		draft-gont-6man-slaac-renum
Revision:	06
Title:		Improving the Robustness of Stateless Address Autoconfiguration 
(SLAAC) to Flash Renumbering Events
Document date:	2020-04-06
Group:		Individual Submission
Pages:		29
URL: 
https://www.ietf.org/internet-drafts/draft-gont-6man-slaac-renum-06.txt
Status: 
https://datatracker.ietf.org/doc/draft-gont-6man-slaac-renum/
Htmlized:       https://tools.ietf.org/html/draft-gont-6man-slaac-renum-06
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-gont-6man-slaac-renum
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-gont-6man-slaac-renum-06

Abstract:
    In renumbering scenarios where an IPv6 prefix suddenly becomes
    invalid, hosts on the local network will continue using stale
    prefixes for an unacceptably long period of time, thus resulting in
    connectivity problems.  This document improves the reaction of IPv6
    Stateless Address Autoconfiguration to such renumbering scenarios.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Fernando Gont <[email-masked]>
Date: Wed, 8 Apr 2020 11:52:34 -0300

Folks,

Ping?

On 6/4/20 16:45, Fernando Gont wrote:
> Title:        Improving the Robustness of Stateless Address 
> Autoconfiguration (SLAAC) to Flash Renumbering Events
> Status: https://datatracker.ietf.org/doc/draft-gont-6man-slaac-renum/
> Htmlized: https://datatracker.ietf.org/doc/html/draft-gont-6man-slaac-renum
> Diff: https://www.ietf.org/rfcdiff?url2=draft-gont-6man-slaac-renum-06
> 
> Abstract:

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

---

From: Loganaden Velvindron <[email-masked]>
Date: Wed, 8 Apr 2020 19:02:57 +0400

> a decision on the document, for the wg to continue to work on it as a
I support moving this I-D forward to a WG document. I will also help with review
and implementation.

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Fri, 10 Apr 2020 00:02:24 -0300

Bob,

Can we place have a wg call for adoption on this document?

Thanks,
Fernando

On 8/4/20 11:52, Fernando Gont wrote:
>> according to the discussion we had both at the 6man interim meeting 
>> and on the mailing-list.
>>
>> share of interest and discussion, and that it is time for the wg to 
>> make a decision on the document, for the wg to continue to work on it 
>> as a working group document.
>>
>> Thanks!
>>
>> Cheers,
>> Fernando
>>
>>
>>
>>
>> https://tools.ietf.org/html/draft-gont-6man-slaac-renum-06
>> Htmlized: 

-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Tore Anderson <[email-masked]>
Date: Fri, 10 Apr 2020 20:38:52 +0200

* Fernando Gont

> I've just posted a revision of draft-gont-6man-slaac-renum (<https://www.ietf.org/internet-drafts/draft-gont-6man-slaac-renum-06.txt>), which incorporates these changes:

Hello,

I have read through this draft. The recommendations in section 4.1.2 would, as I understand it, unfortunately break deployed production usage of IPv6 in our data centre networks in two ways:

1) Infinite preferred/valid lifetimes (0xffffffff per RFC 4861 section 4.6.2). Our data centre networks are stable, we never renumber them. Therefore we assign addresses with infinite lifetimes. The lifetime capping in the draft appears to break this feature.

2) Use of ND for SLAAC but not for default router assignment (i.e., RAs with Router Lifetime = 0). We use this when we instead use dynamic routing protocols such as BGP to configure hosts with (off-link) routing, and also when the advertising router can only be used to reach a subset of ::/0 (in this case, we may use RIOs to communicate which specific prefixes are reachable through the advertising router). The formula in the draft appears to ensure that the address lifetimes would in this use case be capped to 0, which is obviously problematic.

I hope these issues can be resolved.

Tore

---

From: Fernando Gont <[email-masked]>
Date: Fri, 10 Apr 2020 15:53:14 -0300

Hello, Tore,

Thanks for your feedback! In-line...

> 1) Infinite preferred/valid lifetimes (0xffffffff per RFC 4861 section 4.6.2). Our data centre networks are stable, we never renumber them. Therefore we assign addresses with infinite lifetimes. Th…

Question:
1) If the addresses are essentially static, why do you use SLAAC?
2) I expect that if you employ SLAAC, you have a router sending RAs, 
right? In such case, why would the proposal here "break this feature"? 
-- i.e., addresses would never become unpreferred or invalidated.

(that said, 0xffffffff is a special case -- i.e., has special semantics, 
so it can certainly be treated as a special case in the draft -- i.e., 
don't cap if PIO lifetime is 0xffffffff)

> 2) Use of ND for SLAAC but not for default router assignment (i.e., RAs with Router Lifetime = 0). We use this when we instead use dynamic routing protocols such as BGP to configure hosts with (off…

Good grief! We fixed this for the router-side stuff (Section 4.1.1) but 
forgot to fix this for the host side (Section 4.1.2).

It would seem to me that it would be best that both cases (Router 
Lifetime == 0, and PIO lifetimes == 0xffffffff) would be better handled 
by treating them as special cases (since they are, indeed, special 
cases!) and don't perform any capping in that case.

Thoughts?

Thanks!

Cheers,

---

From: Tore Anderson <[email-masked]>
Date: Fri, 10 Apr 2020 21:15:57 +0200

* Fernando Gont

> 1) If the addresses are essentially static, why do you use SLAAC?

Mostly because it is simpler to use and deploy than DHCPv6. We try to KISS where possible.

> 2) I expect that if you employ SLAAC, you have a router sending RAs, right? In such case, why would the proposal here "break this feature"? -- i.e., addresses would never become unpreferred or invalidated.

Only if the router sends periodic unsolicited RAs to reset the lifetimes. With infinite address lifetimes and a RA default lifetime that is zero anyway and does not need to be refreshed (cf. the use case I described in the second point) there is no need for unsolicited RAs, in which case capped address lifetimes can possibly count down to zero and cause outages.

Also, in those situations where we do use unsolicited RAs: we have sometimes experienced that the RA transmission function fails, while the router continues to operate fine in every other way. In that situation, the addresses can possibly expire and cause outages because the hosts on the link can no longer reach each other. Ideally we would like to avoid that risk.

(If the RA also advertises a default route, we still have an outage risk because we cannot have an infinite default lifetime, which sucks. Fortunately, that can be worked by including a ::/0 RIO with an infinite lifetime instead.)

> (that said, 0xffffffff is a special case -- i.e., has special semantics, so it can certainly be treated as a special case in the draft -- i.e., don't cap if PIO lifetime is 0xffffffff)

Works for me.

> Good grief! We fixed this for the router-side stuff (Section 4.1.1) but forgot to fix this for the host side (Section 4.1.2).
> 
> It would seem to me that it would be best that both cases (Router Lifetime == 0, and PIO lifetimes == 0xffffffff) would be better handled by treating them as special cases (since they are, indeed, special cases!) and don't perform any capping in that case.

I would prefer it if the logic was to disable capping if (Router Lifetime == 0 *OR* PIO lifetimes == 0xffffffff), i.e., not AND; that would work for me.

Tore

---

From: Fernando Gont <[email-masked]>
Date: Fri, 10 Apr 2020 16:25:57 -0300

> Mostly because it is simpler to use and deploy than DHCPv6. We try to KISS where possible.

I mean, why not static configuration? (not objecting, but asking).

[....]
>> (that said, 0xffffffff is a special case -- i.e., has special semantics, so it can certainly be treated as a special case in the draft -- i.e., don't cap if PIO lifetime is 0xffffffff)

Cool. Will fix this. Thanks!

> I would prefer it if the logic was to disable capping if (Router Lifetime == 0 *OR* PIO lifetimes == 0xffffffff), i.e., not AND; that would work for me.

Yes, exactly -- that's what I meant.

Will apply that both to the I-D and the code I have produced.

Thanks a lot for you input!

Cheers,

---

From: Tore Anderson <[email-masked]>
Date: Fri, 10 Apr 2020 21:34:38 +0200

* Fernando Gont

> I mean, why not static configuration? (not objecting, but asking).

Fixed unique-per-host config to be provisioned to each server *before* the network is up?

That sounds like a provisioning nightmare to me, to be honest...I'm sure there are ways one could pull off something like that at scale, but it sure sounds more complicated and less KISS-y than simply using SLAAC.

Thanks!

Tore

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 10 Apr 2020 20:39:19 +0100

Fernando Gont wrote on 10/04/2020 19:53:
>> 2) Use of ND for SLAAC but not for default router assignment (i.e., 
>> RAs with Router Lifetime = 0). We use this when we instead use dynamic 
>> routing protocols such as BGP to configure hosts with (off-link) 
>> routing, and also when the advertising router can only be used to 
>> reach a subset of ::/0 (in this case, we may use RIOs to communicate 
>> which specific prefixes are reachable through the advertising router). 
>> The formula in the draft appears to ensure that the address lifetimes 
>> would in this use case be capped to 0, which is obviously problematic.
> 

this is very definitely a corner case. Off-label use of ND, perhaps? :-)

Nick

---

From: Erik Kline <[email-masked]>
Date: Sun, 12 Apr 2020 21:57:45 -0700

<no hats>

I think I would prefer if we can solve 90+% of the problem with: (a) hosts
try to do right thing as told to them by routers and (b) the routers tell
hosts the right thing.  I think improved timer guidance (vis. v6ops drafts)
could be of value in regard to (b).

That having been said, as noted there are times where the routers might not
be able to correctly deprecate a prefix.  (Also the whole "2 hour" PIO
lifetime thing always struck me as a a bit of wart.)

I feel like what's wanted here is for hosts to be able to do something like
BFD for any given non-link-local unicast address -- some host OSes /might/
even want to do something (log/warn, maybe) about manual/DHCPv6 configured
addresses that might fall within a problematically disappearing prefix.

Is it just as workable, and less complicated, if hosts that want to check
the validity of a previously advertised prefix do a few unicast NSes for
the router's link-local address from a source address in the prefix to see
if the router thinks the path to prefix is back onto the link?  I just did
this at home it worked, but my setup is also about as simple as they come.

On Wed, Apr 8, 2020 at 7:59 AM Fernando Gont <[email-masked]> wrote:

> > (<
> https://www.ietf.org/internet-drafts/draft-gont-6man-slaac-renum-06.txt>),
>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Apr 2020 02:54:19 -0300

Hi, Erik,

On 13/4/20 01:57, Erik Kline wrote:
> <no hats>
> 
> I think I would prefer if we can solve 90+% of the problem with: (a) 
> hosts try to do right thing as told to them by routers and (b) the 
> routers tell hosts the right thing.  I think improved timer guidance 
> (vis. v6ops drafts) could be of value in regard to (b).

FWIW, Section 4.1 of draft-gont-6man-slaac-renum-06 is exactly that:
* Section 4.1.1 changes the defaults for routers
* Section 4.1.2 sanitizes the received lifetimes

Part of the rationale behind this document is that we need to improve 
things with what we have. e.g., there are going to be routers that will 
not be updated until they are phased out.

The v6ops work is indeed useful and tackles one of the most common cases 
where this kind of scenario takes place (CE in a home deployment)... but 
doesn't apply to the general case of routers. And I believe that is 
needed, too. What we have as current default values should be changed.

> That having been said, as noted there are times where the routers might 
> not be able to correctly deprecate a prefix.  (Also the whole "2 hour" 
> PIO lifetime thing always struck me as a a bit of wart.)

Indeed. And as noted in the I-D, with all the other vectors that remain 
open, it doesn't make sense to do this 2-hour thing.

> I feel like what's wanted here is for hosts to be able to do something 
> like BFD for any given non-link-local unicast address -- some host OSes 
> /might/ even want to do something (log/warn, maybe) about manual/DHCPv6 
> configured addresses that might fall within a problematically 
> disappearing prefix.
> 
> Is it just as workable, and less complicated, if hosts that want to 
> check the validity of a previously advertised prefix do a few unicast 
> NSes for the router's link-local address from a source address in the 
> prefix to see if the router thinks the path to prefix is back onto the 
> link?  I just did this at home it worked, but my setup is also about as 
> simple as they come.

The document essentially has to sets of components:

1) A set of modications that help deprecate stale prefixes in a timelier 
manner, including:
    - remove the prohibition to reduce the to < 2-hours
    - more appropriate lifetimes at routers
    - capping PIOs at hosts

2) Then an algorithm (Section 4.5.1 or 4.5.2) to infer stale prefixes.

If I understand correctly your proposal/evaluation of BFD as a possible 
alternative would be an alternative for 2), but not for 1). Is that correct?

I believe that BFD would be exercising something else, as opposed to, 
specifically, if the prefixes have become stale. Additionally, it would 
seem to me that doing something ala BFD would be much more complicated, 
and with a number of corner cases that are hard to predict, and prone to 
failure. -- just me thinking out loud:

* What if the router advertises the prefix, but is not a default router?

* How often would you send probes? If you have multiple prefixes and 
multiple routers, would you do all the possible combinations?

* Would you have different timers for BFD?

* What would be the criteria for deprecating/invalidating addresses? -- 
i.e., how would BFD map into these to ND phases?

Part of the design goal we had in mind when developing the algorithms in 
Section 4.5 was to avoid sending extra packets (the two algorithms are 
essentially passive), and have something which integrates with ND/SLAAC 
as much as possible.

If one were to opt for actively "probing" stuff, then one might simply 
poll routers with RSs, and check if they keep advertising the same 
information.

IMHO, what we need to check for dealing with stale information is 
whether the advertised information is current or not -- with current 
meaning "there's a router actively advertising such information, on a 
regular basis". While in a way you might infer that if you can't BFD the 
information is stale, I think the two are verifying two different 
things. What we are doing is, in a way, garbage collection (passive 
stuff), where BFD requires active action on the host side.

That aside, what would be the advantage of the algorithm you describe vs 
e.g. Section 4.5.2 of drf-gont-6man-slaac-renum?

Thanks!

Cheers,

---

From: Erik Kline <[email-masked]>
Date: Mon, 13 Apr 2020 01:13:08 -0700

> e.g. Section 4.5.2 of drf-gont-6man-slaac-renum?
<still no hats>

Well, I was trying to share some thinking about an alternative without
having to be overly prescriptive.  But seeing as I've had a nice glass of
whiskey and am otherwise heading to bed...here goes.  Please forgive the
typos.

TL;DR: this email can be skipped, unless maybe you're quarantined and
suuuper-bored.

[1] Let's be clear: I was not proposing BFD itself -- in no way whatsoever.

I my simple mind, Bidirectional Forwarding Detection mostly means a
protocol for asking and answering the question: "does node X have a routing
configuration that routes Y back to me?".  I could well be wrong, but it
also doesn't really matter for the purposes of what I had in mind.

I was thinking about what's important about an address configured (by any
means) from within a PIO advertised to a node by one or more routers.
(footnote 1)

If I have an address and no return path routing for it from any router, I
think I can maybe:

    (a) get node-local applications to talk to/with it,
    (b) maybe -- maybe -- use it to talk to some on-link friends,
    (c) post a screenshot of ifconfig output to social media showing how
cool I am, and
    (d) not a whole lot else.

So what I was getting at was that the thing of interest, I think, is
evaluating the router's idea of whether that PIO is still routed out the
interface on which the RAs contained it were sent.

NOTE: I'm assuming that when a router reboots and loses its old delegated
prefix and gets a new one that it also no longer has any route installed
for the old prefix.

[2] The NS of the router's LL addr from a GUA within PIO in question seemed
to me to implement a cheap check of the router's configuration vis. the
PIO.  (Technically it's testing the router's packet processing path for an
originated packet and not a forwarded packet.)

This applies even if the default router lifetime is zero.  The router might
retain other connectivity (perhaps even sent in RIOs) that is of interest
to the host.

[3] There would seem to be to be ~3 phases to this whole thing:

    (a) detection that the PIO might no longer be valid as far as router
X's is concerned,
    (b) evaluation of the the usefulness of an address in the PIO, and
    (c) action taken upon deciding the PIO is likely gone.

Text around (3a) would of course include good things like noticing RAs from
router X no longer contain the PIO in question.  The exact timing and
number of missed RAs before triggering evaluation would be decided by
working group consensus, and then overrideable anyway via
/proc/sys/net/ipv6/...

But the text around (3a) might also leave open the option for higher layer
signals to trigger evaluation.  Perhaps the TCP stack might notice an
excessive number of retransmits and a lack of replies and ask the IP layer
to evaluate the source address for a given connection.  In a network with
RAs that are very seldom sent (or very seldom received), this might speed
up detection.

For (3b), I was just thinking 3-5 unicast NSes using the ND timers from the
RA (or from /proc/sys/net/ipv6/...).  If the router replies, then any
connectivity problems are probably elsewhere.

The text around (3c) should probably be open to a variety of OS-specific
options.  At a minimum, addresses in the PIO should be depref'd for source
address selection when router X is the selected next hop.  That's not
necessarily the same thing as 'setting the "Preferred Lifetime" to 0', but
it does depend -- as I think you and others noted elsewhere -- on
implementing 6724 rule 5.5.  Setting the preferred lifetime to 0 may well
be just as good if there are no other routers on the link advertising the
PIO.  If there is another router advertising the PIO then it could quickly
get complicated trying to evaluate which ones advertise default routes and
RIOs and the availability of other useful PIOs, etc.

That's a random brain dump of what I was thinking.

The thing about this approach, though, is that I believe it could be
implemented in hosts (e.g. Android) without any 6man document and no kernel
changes.  It could probably be implemented with some user-space code, a
netlink socket, and an icmp6 socket.  It's just an operational policy.  It
also doesn't risk being over-prescriptive for nodes in other circumstances
(e.g. datacenters).

Apologies for the long rambling,
-ek

Footnote 1: W.R.T. Ole's "addressing != routing", I suspect I'm more in
Lorenzo's camp on this.  To me this is sort of like saying "currency !=
financial transactions".  That's true.  If I have no money there are maybe
few transactions I can conduct?  But if I have tons of money and no
mechanics by which to spend it on anything...then I'd better hope the money
is also edible.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Apr 2020 10:00:26 -0400

On Apr 13, 2020, at 12:57 AM, Erik Kline <[email-masked]> wrote:
> Is it just as workable, and less complicated, if hosts that want to check the validity of a previously advertised prefix do a few unicast NSes for the router's link-local address from a source address in the prefix to see if the router thinks the path to prefix is back onto the link?  I just did this at home it worked, but my setup is also about as simple as they come.

When would they do this?  What would trigger this behavior?   I think it’s not a bad suggestion, but it’d need to be fleshed out a bit.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Apr 2020 11:35:17 -0300

Hello, Erik,

Thanks for your comments! In-line....

On 13/4/20 05:13, Erik Kline wrote:
[....]
> having to be overly prescriptive. 

A meta question here is: What are the algorithms from Section 4.5 missing?

I welcome the brainstorming, but I'm still failing to see what the 
algorithm we have proposed are lacking to motivate an alternative.

You seem to be suggesting that "we need something else", but it's not 
clear to me why.

[....]
> 
> I was thinking about what's important about an address configured (by 
> any means) from within a PIO advertised to a node by one or more 
> routers. (footnote 1)
> 
> If I have an address and no return path routing for it from any router, 
> I think I can maybe:
> 
>      (c) post a screenshot of ifconfig output to social media showing 
> how cool I am, and

I'm not saying this has no use. But I'm saying that this goes beyond 
that problem we are trying to solve.

The basic premise here is detection that PIO information has changed, in 
a timelier manner. i.e., do garbage collection on network configuration 
information.

There might be other things one might want to do at a node for other 
reasons -- but for solving the problem we have I hand, I don't think 
much more is needed than use appropriate lifetime values and check 
whether PIOs have disappeared from RAs.

For other cases where one might one to do some sort of BFD, one would do 
it for the scope of the addresses in question. e.g. information that a 
link-local addresses is usable in the local link might be of value. 
However, information about a global address that is forwardable on the 
local-link not so much, if it will nevertheless at, say, hop N=2.

> [2] The NS of the router's LL addr from a GUA within PIO in 
> question seemed to me to implement a cheap check of the router's 
> configuration vis. the PIO.  (Technically it's testing the router's 
> packet processing path for an originated packet and not a forwarded packet.)

BUt, if what you want to check is whether the information is valid -- as 
in the sense of "being currently and actively advertised by a router", 
why would you check the forwarding path, as opposed to check the 
information itself.  (passively as we do, or actively via an RS if you 
felt like actively asking for it (which IMHO is unnecessary)).

> 
> This applies even if the default router lifetime is zero.  The router 
> might retain other connectivity (perhaps even sent in RIOs) that is of 
> interest to the host.
> 
>      (a) detection that the PIO might no longer be valid as far as 
> router X's is concerned,
> Text around (3a) would of course include good things like noticing RAs 
> from router X no longer contain the PIO in question.  The exact timing 
> and number of missed RAs before triggering evaluation would be decided 
> by working group consensus, and then overrideable anyway via 
> /proc/sys/net/ipv6/...
> 
> But the text around (3a) might also leave open the option for higher 
> layer signals to trigger evaluation.  Perhaps the TCP stack might notice 
> an excessive number of retransmits and a lack of replies and ask the IP 
> layer to evaluate the source address for a given connection.  

IMO, that would be like boiling the ocean for what we have at hand.

[....]
> options.  At a minimum, addresses in the PIO should be depref'd for 
> source address selection when router X is the selected next hop.  That's 
> not necessarily the same thing as 'setting the "Preferred Lifetime" to 
> 0', but it does depend -- as I think you and others noted elsewhere -- 
> on implementing 6724 rule 5.5.

Setting the preferred lifetime to 0 does mean that the address is 
unpreferred. And this is exercised by rule #3 of RFC6724.

(Rule 5.5. is required by multi-router multi-prefix scenarios)

>  Setting the preferred lifetime to 0 may 
> well be just as good if there are no other routers on the link 
> advertising the PIO.  If there is another router advertising the PIO 
> then it could quickly get complicated trying to evaluate which ones 
> advertise default routes and RIOs and the availability of other useful 
> PIOs, etc.

You need this, anyway. Either you assume that any router will happily 
forward packets for any prefix, or, as discussed in RFC8028, you don't, 
and you keep track of who advertised what.

> implemented in hosts (e.g. Android) without any 6man document and no 
> kernel changes.  It could probably be implemented with some user-space 
> code, a netlink socket, and an icmp6 socket. 

For most OSes, you generally end up implementing this in the same place 
where you implement SLAAC. In fact, I believe this is part of SLAAC, so 
no surprises there.

You may implement this in the kernel if you are relying on the kernel 
implementation of slaac, or in userspace if slaac is implemented in 
userland (NetworkManager, systemd-networkd, OpenBSD's slaacd, etc.)

> It's just an operational policy. 

I clearly disagree here. This is an implementation of appropriate 
garbage collection for slaac.

An operational policy is essentially an operator playing with the knobs 
he already have. Where what we are discussing here is a clear 
modification of the protocol.

> It also doesn't risk being over-prescriptive for nodes in 
> other circumstances (e.g. datacenters).

If you're referring to Tore's comment, that has already been addresses 
in my working copy of the document. He was just exercising the special 
semantics of specific values, which we had overlooked. That's easily 
addressable, and we have done so.

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Mon, 13 Apr 2020 11:39:11 -0300

Hello, Ted,

On 13/4/20 11:00, Ted Lemon wrote:
> On Apr 13, 2020, at 12:57 AM, Erik Kline <[email-masked] 
> <mailto:[email-masked]>> wrote:
>> link?  I just did this at home it worked, but my setup is also about 
>> as simple as they come.
> 
> When would they do this?  What would trigger this behavior?   I think 
> it’s not a bad suggestion, but it’d need to be fleshed out a bit.

I believe a good starting point is "What will this achieve that the 
algorithms we have in Section 4.5 wouldn't?" -- even more when this 
alternative idea seems more complex to implement, and is going beyond 
the problem at stake (essentially garbage collection of stale network 
configuration information)

Thanks,

---

From: "Olopade, Olorunloba" <[email-masked]>
Date: Tue, 14 Apr 2020 23:20:26 +0000

Hmm, the suggested algorithm is passive and implied. Do we need to consider an approach that is active and explicit?

Just a thought.

Loba Olopade

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Fernando Gont
Sent: 13 April 2020 15:39
To: Ted Lemon <[email-masked]>; Erik Kline <[email-masked]>
Cc: [email-masked]
Subject: Re: Moving draft-gont-slaac-renum forward (fwd: New Version Notification for draft-gont-6man-slaac-renum-06.txt)

Hello, Ted,

On 13/4/20 11:00, Ted Lemon wrote:
>> prefix to see if the router thinks the path to prefix is back onto 
>> the link?  I just did this at home it worked, but my setup is also 
>> about as simple as they come.
> 

I believe a good starting point is "What will this achieve that the algorithms we have in Section 4.5 wouldn't?" -- even more when this alternative idea seems more complex to implement, and is going beyond the problem at stake (essentially garbage collection of stale network configuration information)

Thanks,

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
Save Paper - Do you really need to print this e-mail?

Visit www.virginmedia.com for more information, and more fun.

This email and any attachments are or may be confidential and legally privileged
and are sent solely for the attention of the addressee(s).

Virgin Media will never ask for account or financial information via email. If you are in receipt of a suspicious email, please report to www.virginmedia.com/netreport

If you have received this email in error, please delete it from your system: its use, disclosure or copying is unauthorised. Statements and opinions expressed in this email may not represent those of Virgin Media. Any representations or commitments in this email are subject to contract.

Registered office: 500 Brook Drive, Reading, RG2 6UU

Registered in England and Wales with number 2591237

---

From: Fernando Gont <[email-masked]>
Date: Tue, 14 Apr 2020 21:26:14 -0300

> Hmm, the suggested algorithm is passive and implied. Do we need to consider an approach that is active and explicit?

Not sure what you mean by "implied".

What we need is to solve the problem, and in the most simple possible way.

Thanks,

---

From: "Olopade, Olorunloba" <[email-masked]>
Date: Wed, 15 Apr 2020 15:48:50 +0000

By implied, I mean that the host still have to infer from missing PIO information in the RA messages. Why not just request the information from the router, if we think it is missing? I think you mentioned that you did not like this approach, but wondering why this is not preferred. In my opinion, if information is deemed to be missing, the preference would be a request, not a timer or missing counter approach. But not sure what has been discussed in the past.

I think another thing that complicate things is the possibility of conveying RA messages in multiple packets. A host should be able to know when it has received full information from the router. Will it not make sense then to include an option (to indicate fragments) in the RA if multiple packets are being used?

Loba Olopade

Liberty Global Technology & Innovation
Enabling growth across Europe

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: 15 April 2020 01:26
To: Olopade, Olorunloba <[email-masked]>; Ted Lemon <[email-masked]>; Erik Kline <[email-masked]>
Cc: [email-masked]
Subject: Re: Moving draft-gont-slaac-renum forward (fwd: New Version Notification for draft-gont-6man-slaac-renum-06.txt)

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 16 Apr 2020 14:40:25 +0900

Fernando,

What is the use case here? It seems that the problem described in the
introduction only occurs if:

   1. The router has no stable storage.
   2. The router crashes without being brought down gracefully (if it did,
   it could send an RA to withdraw its announcement).
   3. The router is not the thing that is providing L2 link (otherwise
   devices would lose link and drop the prefixes)
   4. The network renumbers the router while it is disconnected.

#1 may be frequent, and #2 can happen.
#3 is very unlikely. Generally routers are both L2 and L3 devices, and
regardless of whether the hosts are wired or wireless, when the router
crashes, they will lose link and there will be no problem.
As for #4, I don't see how it can happen at all except with a violation of
the standards. If the router never sends a PIO a lifetime larger than the
lifetime of the PD it got the prefix from, then when the device comes back,
it will either still have a valid lease (and the network will give it back
the same prefix it had before), or it won't have a valid lease and the PIO
will have expired.

What am I missing?

Cheers,
Lorenzo

---

From: Fernando Gont <[email-masked]>
Date: Thu, 16 Apr 2020 03:58:26 -0300

Hello, Lorenzo,

>  4. The network renumbers the router while it is disconnected.

Please see draft-ietf-v6ops-slaac-renum -- it mentions multiple scenarios.

> #1 may be frequent, 

For CPE routers, that's the norm, not the exception.

> and #2 can happen.

Not sure why you think #3 is unlikely. e.g., right now I'm working at 
home on a laptop that is wired to a switch, which is in turn wired to my 
CPE router. -- the CPE router only has 4 ports, and I have over 10 
devices wired.. so I do need need the setup in question.

> As for #4, I don't see how it can happen at all except with a violation 
> of the standards.

#4 can happen as a result of #2. BUt also see the other examples in 
draft-ietf-v6ops-slaac-renum.

> If the router never sends a PIO a lifetime larger than 
> the lifetime of the PD it got the prefix from, then when the device 
> comes back, it will either still have a valid lease (and the network 
> will give it back the same prefix it had before), or it won't have a 
> valid lease and the PIO will have expired.

For the CPE case,

* It has been reported that some CPEs do indeed just copy the DHCPv6 
lease lifetime to the PIO lifetimes, and do not decrement the PIO 
lifetime. That's indeed a violation of the standards, but still a 
deployed reality.

* Besides, if, when a router comes back, it gets a different leased 
prefix (i.e., dynamic prefixes), and the router does not have stable 
storage, from the host pov the previous (now stale) prefix will still be 
valid, but it will be unusable.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 16 Apr 2020 04:03:22 -0300

>     devices would lose link and drop the prefixes)

FWIW, at my parents house the router is not providing L2 link .. e.g., 
in one of the cases an AP sitting at the backyard is wired to the CPE 
router to provide coverage at the backyard, since the wifi signal of the 
CPE router is not strong enough to provide coverage to the backyard.

Thanks,

---

From: Philip Homburg <[email-masked]>
Date: Thu, 16 Apr 2020 12:16:23 +0200

>By implied, I mean that the host still have to infer from missing PIO informat
>ion in the RA messages. Why not just request the information from the router, 
>if we think it is missing? I think you mentioned that you did not like this ap
>proach, but wondering why this is not preferred. In my opinion, if information
> is deemed to be missing, the preference would be a request, not a timer or mi
>ssing counter approach. But not sure what has been discussed in the past.
>
>I think another thing that complicate things is the possibility of conveying R
>A messages in multiple packets. A host should be able to know when it has rece
>ived full information from the router. Will it not make sense then to include 
>an option (to indicate fragments) in the RA if multiple packets are being used
>?

I think the scenario is the following:
We have a legacy CPE, the CPE reboots gets a new prefix from upstream and
starts annoucing the new prefix. The old prefix doesn't work anymore,
but hosts (and the CPE) don't know that.

1) Because it needs to work with legacy CPEs, we can't require changes on the
CPE.

2) A host doesn't really know that the CPE rebooted. So it has no clear signal
to request new information. The one signal that the host gets is a new
prefix.

3) We can assume that the current RAs tolerate a loss of 2 RAs. Ideally any
changes to the host should still be robust if two RAs get lost.

I can imagin an active approach where a host would send a series of RS messages
to a router each time it sees a new prefix from a router for which it already
knows a prefix. However, we would have to be very careful that the host
keeps sending RS messages long enough to deal with potential packet loss in
the split RA case (i.e. if the host receives 3 RAs containing the new prefix
then we can safely conclude that the router is not annoucing the old
prefix)

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Thu, 16 Apr 2020 12:58:45 +0200

> to request new information. The one signal that the host gets is a new

Exactly.

This have been initially described also in RIPE-690 document.

https://www.ripe.net/publications/docs/ripe-690#5-2--why-non-persistent-assignments-are-considered-harmful

As we have Lorenzo in this thread - I'm wondering if Google is still 
measuring "IPv6 brokeness" and blacklist those networks in their DNSes 
with not serving them AAAA anymore?

That happened to some ISPs in the past and that was the main reason why 
we documented it in RIPE-690 and consequently are trying to fix things here.

Cheers and thnx, Jan

---

From: Philip Homburg <[email-masked]>
Date: Thu, 16 Apr 2020 13:38:44 +0200

>we documented it in RIPE-690 and consequently are trying to fix things here.

What I recall from earlier discussions here (or in v6ops) is that some
operators have operational reasons for changing prefixes. 

>From Section 5.3: 
"Finally, if you're unconvinced about the use of persistent prefixes,
"you should at least consider using non-persistent but long-lived
"assignments so the lease time is as long as your provisioning system
"allows.

This will still create problems when the prefix is changed.

I.e. in my opion we should make hosts and CPEs robust against renumbering.
In my experience, just about all renumbering is done wrong. Essentially nobody
has the tools to record the old prefix, keep that working for a while and
meanwhile introduce a new prefix.

Plenty of operators have pools of prefixes and change the prefix of a 
customer when the customer is moved to a different pool. Are you aware of
any documents that describe how to move a customer from one pool to another
without flash renumbering?

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Thu, 16 Apr 2020 19:00:59 +0200

> This will still create problems when the prefix is changed.

True :) We tried to mitigate the problem as much as we could :(

> I.e. in my opion we should make hosts and CPEs robust against renumbering.

Yup. That's what operational reality tells us.

> without flash renumbering?

Nope. I've never seen one. Usually that happens when customers are (for 
whatever reason) moved from one BRAS/LAR/BNG to another. Then sh*t hits 
the fan and Google starts DNS-blacklisting the whole ASN.

Cheers, Jan

---

From: "Olopade, Olorunloba" <[email-masked]>
Date: Thu, 16 Apr 2020 18:51:11 +0000

Ah. I see your point with respect to the legacy devices. I think we should still address the issue of split RAs, though that probably should not be covered with this. 

However, I still don't see why the use of RS would be less preferred. 

Loba Olopade
Principal Design Engineer | CTIO | Planning and Engineering 
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Philip Homburg
Sent: 16 April 2020 11:16
To: [email-masked]
Cc: Olopade, Olorunloba <[email-masked]>
Subject: Re: Moving draft-gont-slaac-renum forward (fwd: New Version Notification for draft-gont-6man-slaac-renum-06.txt) 

>By implied, I mean that the host still have to infer from missing PIO 
>informat ion in the RA messages. Why not just request the information 
>from the router, if we think it is missing? I think you mentioned that 
>you did not like this ap proach, but wondering why this is not 
>preferred. In my opinion, if information  is deemed to be missing, the 
>preference would be a request, not a timer or mi ssing counter approach. But not sure what has been discussed in the past.
>
>I think another thing that complicate things is the possibility of 
>conveying R A messages in multiple packets. A host should be able to 
>know when it has rece ived full information from the router. Will it 
>not make sense then to include an option (to indicate fragments) in the 
>RA if multiple packets are being used ?

I think the scenario is the following:
We have a legacy CPE, the CPE reboots gets a new prefix from upstream and starts annoucing the new prefix. The old prefix doesn't work anymore, but hosts (and the CPE) don't know that.

1) Because it needs to work with legacy CPEs, we can't require changes on the CPE.

2) A host doesn't really know that the CPE rebooted. So it has no clear signal to request new information. The one signal that the host gets is a new prefix.

3) We can assume that the current RAs tolerate a loss of 2 RAs. Ideally any changes to the host should still be robust if two RAs get lost.

I can imagin an active approach where a host would send a series of RS messages to a router each time it sees a new prefix from a router for which it already knows a prefix. However, we would have to be very careful that the host keeps sending RS messages long enough to deal with potential packet loss in the split RA case (i.e. if the host receives 3 RAs containing the new prefix then we can safely conclude that the router is not annoucing the old
prefix)
--------------------------------------------------------------------
Save Paper - Do you really need to print this e-mail?

---

From: Fernando Gont <[email-masked]>
Date: Thu, 16 Apr 2020 17:41:50 -0300

> Ah. I see your point with respect to the legacy devices. I think we should still address the issue of split RAs, though that probably should not be covered with this.

Split RAs,, why not present in real deployments, *are* already addressed 
by the algorithm from Section 4.5.2. The reason for setting the 
Preferred Lifetime to LTA_DEPRECATE (instead of setting it rightaway to 
0) is indeed to allow for split RAs.

> However, I still don't see why the use of RS would be less preferred.

If one wanted to to actively probe a prefix, one could schedule a 
unicast RS e.g. when a prefix is deprecated. I personally don't think 
this is really needed. Or, if one were to actively send RS, I don't 
think more than one or two would be needed.

Essentially, if a prefix becomes deprecated, it means you *are* 
receiving RAs. And the Valid Lifetime is set to LTA_INVALID allowing for 
enough time to receive broadcasted RAs.

I don't mind even including such a thing as a possible algorithm, just 
for the wg to have it handy for consideration. However, I believe this 
would be a tiny modification to what we already have.

Thanks,

---

From: Mark Smith <[email-masked]>
Date: Fri, 17 Apr 2020 06:49:14 +1000

> without flash renumbering?

The general renumbering procedure in RFC4291 would apply.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 17 Apr 2020 11:31:32 +0200

>The general renumbering procedure in RFC4291 would apply.

Can you be more specific? I can't find a renumbering procedure in RFC 4291
(IP Version 6 Addressing Architecture)

In any case, I'm not looking for a protocol level description, but something
for operators. I.e., for commonly used platforms, which options make 
DHCPv6 servers serve the previously prefix with a lifetime of zero. If
the operator has multiple DHCPv6 servers that are served with more or
less fixed prefixes from radius, how do you renumber using radius. Does that
require a extra code on the provisioning side or are there existing
solutions.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 17 Apr 2020 22:25:21 +0900

> Please see draft-ietf-v6ops-slaac-renum -- it mentions multiple scenarios.

I'm not sure any of those are important enough to change the standards for.
Going in order:

   1. "CPE router crashes and reboots and gets a different prefix". How
   does this happen? Even if the CPE that crashes doesn't have stable storage,
   the one that doesn't crash keeps the current prefix in memory.
   2. "Manually moving a switch port to another VLAN and hosts don't retry
   802.1x". Seems either a) an operational problem that can be resolved by
   bouncing the port and causing the hosts to retry, or a b) bug in the 802.1x
   client. Even if this is deployed reality, fixing the standards to work
   around this bug is not a solution, because if the clients upgraded, they
   could fix the bug.
   3. "The prefix changes, and the RAs that tell the clients that the old
   prefix is gone are dropped". But if the RAs are dropped, then the clients
   don't have the new prefix either, and nothing the clients do will fix the
   problem.
   4. "Automated config push changes the subnet". That seems like a bug in
   the code doing the push. An automated push can and should perform a
   two-phase change, with graceful renumbering. If nothing else, a flash
   renumber is a disruptive event because active connections stop working.

> devices wired.. so I do need need the setup in question.

I said unlikely, not impossible. I think you'll agree that fraction of home
users that have over 10 wired devices is vanishingly small. :-)

> draft-ietf-v6ops-slaac-renum.

As I said, I don't think #4 can happen without a violation of the
standards. Do you have an example?

> lifetime. That's indeed a violation of the standards, but still a

I'm not sure that we should attempt to fix standards violations on the part
of CPEs by changing the standards for hosts to follow.

> valid, but it will be unusable.

I think the key is: why will the router get a different prefix? DHCP is
stateful. If the lease has not expired, when the router comes back, it will
get the same prefix again.

---

From: Jan Zorz - Go6 <[email-masked]>
Date: Fri, 17 Apr 2020 15:25:27 +0200

> require a extra code on the provisioning side or are there existing

Well, if you are running IPv6-only on access network - current best 
advice would be "do it and at the same time shut down the phones in your 
helpdesk department, wait an hour or two and switch phones back on..." :)

Cheers, Jan

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 18 Apr 2020 08:45:44 +1200

>> (IP Version 6 Addressing Architecture)

I am sure this was intended to be https://tools.ietf.org/html/rfc4192, but that was not aimed at SOHO networks. Neither was https://tools.ietf.org/html/rfc7010.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Sat, 18 Apr 2020 21:21:26 -0300

Hi, Lorenzo,

JUst a quick response (will come back with a longer one)...

On 17/4/20 10:25, Lorenzo Colitti wrote:
> On Thu, Apr 16, 2020 at 3:58 PM Fernando Gont <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> I'm not sure any of those are important enough to change the standards 
> for. Going in order:
> 
>     does this happen? Even if the CPE that crashes doesn't have stable
>     storage, the one that doesn't crash keeps the current prefix in memory.

About 40% of surveyed do dynamic prefixes. That aside, are DHCPv6 
servers required to lease you the same prefix even when you don't even 
provide hints? (CPE routers do not remember what prefix they were leased 
before, so they effectively ask a new one).

[....]
> I said unlikely, not impossible. I think you'll agree that fraction of 
> home users that have over 10 wired devices is vanishingly small. :-)

Every small business I know of in Argentina has exactly that network 
setup. So yeah, it might be unlikely for home users, but the setup is 
actually quite common.

(The use of wifi rage extenders probably leads to the same scenario).

[...]
> I'm not sure that we should attempt to fix standards violations on the 
> part of CPEs by changing the standards for hosts to follow.
> 

No. We attempt to change standards to improve their robustness. In the 
current situation, the SLAAC setup is not robust, and it takes ages to 
recover from such situations. That's not robust design.

> stateful. If the lease has not expired, when the router comes back, it 
> will get the same prefix again.

Please see above.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sat, 18 Apr 2020 21:23:40 -0300

[...]
> will get the same prefix again.

Just to add yet another example: RFC7844

In any case, it's all about improving robustness.

---

From: Mark Smith <[email-masked]>
Date: Sun, 19 Apr 2020 13:37:56 +1000

Also a quick response to one point,

> before, so they effectively ask a new one).

DUID is for that purpose, and devices are expected to preserve it as much
as possible i.e. across reboots and hardware changes, per RFC 8415, section
11.

As RFC 8415 references, the only reason a DUID should purposefully change,
except for a device factory reset, is for privacy reasons per RFC 7844.

The persistence or not of a DUID is pretty much the end-user/device
indicator of how persistent they want the delegated prefix to be, within
the valid lifetime of the prefix(es) as stated by the prefix provider.

---

From: "Olopade, Olorunloba" <[email-masked]>
Date: Mon, 20 Apr 2020 00:09:28 +0000

The use of 3rd party CPE routers, sitting behind the ISPs device should also result in this scenario. 

Loba Olopade

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Fernando Gont
Sent: 19 April 2020 01:21
To: Lorenzo Colitti <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: Moving draft-gont-slaac-renum forward (fwd: New Version Notification for draft-gont-6man-slaac-renum-06.txt)

Hi, Lorenzo,

>     storage, the one that doesn't crash keeps the current prefix in memory.

About 40% of surveyed do dynamic prefixes. That aside, are DHCPv6 servers required to lease you the same prefix even when you don't even provide hints? (CPE routers do not remember what prefix they were leased before, so they effectively ask a new one).

[....]
> home users that have over 10 wired devices is vanishingly small. :-)

Every small business I know of in Argentina has exactly that network setup. So yeah, it might be unlikely for home users, but the setup is actually quite common.

[...]
>     valid, but it will be unusable.

No. We attempt to change standards to improve their robustness. In the current situation, the SLAAC setup is not robust, and it takes ages to recover from such situations. That's not robust design.

> I think the key is: why will the router get a different prefix? DHCP 
> is stateful. If the lease has not expired, when the router comes back, 
> it will get the same prefix again.

Please see above.

Thanks,

---

From: Richard Patterson <[email-masked]>
Date: Mon, 27 Apr 2020 15:17:25 +0100

> the valid lifetime of the prefix(es) as stated by the prefix provider.

Agreed, however this is something I've seen implemented poorly in CPE
routers.  For example one unnamed vendor regenerates a randomised DUID
every time the PPP session flaps, causing the prefix leased to needlessly
change.

The recommendation to use stable DUIDs is something I'd like to see added
to draft-ietf-v6ops-cpe-slaac-renum, referencing RFC8415.

---

From: [email-masked]
Date: Mon, 27 Apr 2020 16:28:31 +0200

> DUID is for that purpose, and devices are expected to preserve it as much as possible i.e. across reboots and hardware changes, per RFC 8415, section 11.
> 
> As RFC 8415 references, the only reason a DUID should purposefully change, except for a device factory reset, is for privacy reasons per RFC 7844. 
> 
> The persistence or not of a DUID is pretty much the end-user/device indicator of how persistent they want the delegated prefix to be, within the valid lifetime of the prefix(es) as stated by the prefix provider.
> 
> Agreed, however this is something I've seen implemented poorly in CPE routers.  For example one unnamed vendor regenerates a randomised DUID every time the PPP session flaps, causing the prefix leased to needlessly change.  
> 
> The recommendation to use stable DUIDs is something I'd like to see added to draft-ietf-v6ops-cpe-slaac-renum, referencing RFC8415.

https://tools.ietf.org/html/rfc7084
Requirement W-5.

If an ISP supports only a single router / supports a single PPP link. There is no need to use the DUID as identifier. Then you're better off with Remote-ID or Line-ID (option 82 equivalent).

O.

---

From: Richard Patterson <[email-masked]>
Date: Mon, 27 Apr 2020 15:45:53 +0100

On Mon, 27 Apr 2020 at 15:28, <[email-masked]> wrote:

> > DUID is for that purpose, and devices are expected to preserve it as
> much as possible i.e. across reboots and hardware changes, per RFC 8415,
> section 11.
> >
> > As RFC 8415 references, the only reason a DUID should purposefully
> change, except for a device factory reset, is for privacy reasons per RFC
> 7844.
> >
> > The recommendation to use stable DUIDs is something I'd like to see
> added to draft-ietf-v6ops-cpe-slaac-renum, referencing RFC8415.
>
>
> If an ISP supports only a single router / supports a single PPP link.
> There is no need to use the DUID as identifier. Then you're better off with
> Remote-ID or Line-ID (option 82 equivalent).
>
> For authentication, or the DHCP lease state?  Authentication, I fully
agree, but for binding of the lease....... not sure it's wise for a DHCPv6
server to make that distinction and rely on an *option* to create a lease.
But I'm also not a vendor.

Yes, W-5 of 7084 is also a good reference regarding my anecdote of
misbehaving CPEs.

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 27 Apr 2020 18:11:16 +0100

Richard Patterson wrote on 27/04/2020 15:45:
> agree, but for binding of the lease....... not sure it's wise for a 
> DHCPv6 server to make that distinction and rely on an *option* to create 
> a lease.

option 82 is how a customer site is identified using dhcp for subscriber 
services on e.g. docsis / adsl / gpon networks.

Nick

---

From: Richard Patterson <[email-masked]>
Date: Mon, 27 Apr 2020 18:37:29 +0100

On Mon, 27 Apr 2020 at 18:11, Nick Hilliard <[email-masked]> wrote:

> Well in the context of this working group I'd hope it's actually DHCPv6
Options 18 and 37 that are being used rather than DHCPv4 Option 82. :)

But indeed, these options are suitable for identification and
authentication of the subscriber service (or site as you put it) using an
external service like RADIUS, but DUID has a different specific use within
the DHCPv6 machinery itself.
i.e. DUID identifies the DHCPv6 Client, DHCPv6 Options 18/37 (and DHCPv4
Option 82.1 / 82.2) do not.