Subject: [v6ops] draft-ietf-v6ops-slaac-renum and draft-ietf-v6ops-cpe-slaac-renum

From: Fred Baker <[email-masked]>
Date: Mon, 18 May 2020 11:50:27 -0700

I'm following up on
https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum
https://tools.ietf.org/html/draft-ietf-v6ops-cpe-slaac-renum
  "Improving the Reaction of Customer Edge Routers to Renumbering Events",
  Fernando Gont, Jan Zorz, Richard Patterson, 2020-05-18

https://datatracker.ietf.org/doc/draft-ietf-v6ops-slaac-renum
https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum
  "Reaction of Stateless Address Autoconfiguration (SLAAC) to Flash-
  Renumbering Events", Fernando Gont, Jan Zorz, Richard Patterson,
  2020-05-05

These have been in discussion for a few months, and have been recently updated. I have two questions:

First, and this especially to those that commented in those last calls, but of course not limited to them. Did the authors address all of the issues raised? Are there other issues to raise?

Second, we need a document shepherd as we send the documents to the IESG. Would volunteers please send a note to [email-masked]?

---

From: Owen DeLong <[email-masked]>
Date: Mon, 18 May 2020 12:35:13 -0700

I believe the documents are in an appropriate state to move forward. All concerns I expressed have been addressed.

Owen

> On May 18, 2020, at 11:50 , Fred Baker <[email-masked]> wrote:
> 
> I'm following up on
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Philip Homburg <[email-masked]>
Date: Tue, 19 May 2020 14:49:55 +0200

>  "Improving the Reaction of Customer Edge Routers to Renumbering =
>Events",

In my opinion, L-15 needs to be a SHOULD NOT or otherwise have space 
for the operator of the router to override this behavior. I have provided
a use case for that in the past.

(It would be nice if Fernando could fix his mail server (or remove the IPv6
address on his MX. I have a mail to him that has been in my mail queue for
quite a while now).

---

From: Fernando Gont <[email-masked]>
Date: Tue, 19 May 2020 12:35:09 -0300

> a use case for that in the past.

These are requirements for the CPE, not for the operator. i.e., what the 
CPE is expected to do without human intervention. It would seem to me 
that, in that light the current "MUST" conveys the meaning of "if you 
don't follow this, you are breaking things".  A device that employs 
local addresses for more than the leased time may potentially employ 
addresses for longer than valid.

Am I missing something?

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

---

From: Philip Homburg <[email-masked]>
Date: Wed, 20 May 2020 10:55:25 +0200

>addresses for longer than valid.

I think the need to relax L-15 comes from the fact that ISPs have an 
incentive to use very short lease times.

I don't know the details, but what seems to happen is that when a
customer swaps one CPE for anothor, the old CPE doesn't release the
lease (i.e., people just poweroff or disconnect the old CPE).

Then when the new CPE asks for a lease and the customer has a fixed
prefix, the radius daemon finds that the lease is already in use by
the old CPE and doesn't give any lease to the new CPE.

The hacky quick fix for this is to set lifetimes in the lease to only
a few hours at most and ask people to wait.

We have to be careful, that we don't reserve the term CPE for
'device used by a customer who doesn't know any better'.

Historically, we allow operators of routers to set all kinds of parameters
even if they would shoot themselves in the foot doing that. So the CPE
specs are useful set of specifications to connect a router to a DSL or
cable connection. But that doesn't mean we should prevent to owner of the
CPE from configuring the local network as that person sees fit.

Now I think there is a workaround for the L-15 requirement. The CPE
could allow the user to not advertise the prefix obtained through
DHCPv6 PD and allow the user to statically configure a prefix to
advertised.

I think this workaround is more convoluted than allowing the user to
directly override the lifetime parameters. But that seems to be what
this wg wants.

---

From: Richard Patterson <[email-masked]>
Date: Wed, 20 May 2020 11:28:08 +0100

> a few hours at most and ask people to wait.

So this is indeed a concern for an Operator running IPoE services, but is a
problem to be tackled on the BNG rather than the CPE router.
One mitigation is as you suggest, the Operator uses short DHCP lease times
so that the session times out gracefully within a reasonable time, but this
is even more reason for L-15 to exist as a MUST, so the CPE doesn't
overpromise the prefix duration on the LAN.

There are also additional approaches depending on the BNG vendor, that
either reactively clear subscriber sessions when they detect a
duplicate/conflict, or more proactively check the aliveness of the CPE
Router periodically with ARP/ND.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 20 May 2020 18:09:55 +0200

>overpromise the prefix duration on the LAN.

I have a hard time following this reasoning. We know that customers with
static prefixes are impacted by this and end up with short leases on their
prefixes. There is no point in limiting RA values for static prefixes. 

Of the other hand, for dynamic prefixes, which this draft tries to deal
with, there is no problem with relatively long lease times.

So this draft makes the situation worse for static prefixes to better
deal with the unwanted situation of dynamic prefixes. To me that strikes me
as completely the wrong way around.

---

From: Richard Patterson <[email-masked]>
Date: Wed, 20 May 2020 21:55:10 +0100

> prefixes. There is no point in limiting RA values for static prefixes.

The DHCPv6 PD client doesn't know that the prefix is static, just that it
has the rights to use that prefix for up to the Valid Lifetime.
It's presumptuous and foolish of the host to over-promise the use of said
prefix downstream.

> with, there is no problem with relatively long lease times.

But there is, that's what we're trying to mitigate.

> as completely the wrong way around.

You might have to expand on why you think shorter lifetimes are "worse".

---

From: Fernando Gont <[email-masked]>
Date: Wed, 20 May 2020 23:10:57 -0300

Hello, Philip,

> a few hours at most and ask people to wait.

In that case, how would the new CPE get its packets, anyway? I don't 
seem to see what you'd be "fixing" by manually extending the lifetimes.

> CPE from configuring the local network as that person sees fit.

The recommendations in this document have to do with what the CE Router 
does, by default, without human intervention.

We're not precluding CE Routers to have other knobs to do other things.

So I fail to see why you say L-15 should be "relaxed". -- L-15 is not 
arguing that you should or should not manually configure stuff in your 
CE Router.

Thanks,

---

From: Owen DeLong <[email-masked]>
Date: Wed, 20 May 2020 19:17:33 -0700

> On May 20, 2020, at 19:10 , Fernando Gont <[email-masked]> wrote:
> 
> Hello, Philip,
> 
> In that case, how would the new CPE get its packets, anyway? I don't seem to see what you'd be "fixing" by manually extending the lifetimes.

As silly as it seems to you and me, he wants the LAN to continue to function while disconnected by misconfiguring his router.

> The recommendations in this document have to do with what the CE Router does, by default, without human intervention.
> 
> So I fail to see why you say L-15 should be "relaxed". -- L-15 is not arguing that you should or should not manually configure stuff in your CE Router.

I suspect he’s interpreting it (and some vendors are not unlikely to as well) to say that vendors should not allow this misconfiguration.

Perhaps if we add the words “by default” or something like that into the language to make it clear that this specifies only the required default behavior
fo the CE Router and does not preclude knobs allowing one to misconfigure their device to obtain a desired result it would address his singular concern
without relaxing the requirement to the point of doing substantial damage elsewhere.

Owen

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 May 2020 14:57:14 +1200

On 21-May-20 14:17, Owen DeLong wrote:
> 
> 
>> On May 20, 2020, at 19:10 , Fernando Gont <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Hello, Philip,
>>

I think that is why we invented ULAs. At least, RFC 4193 starts out by stating that ULAs are "intended for local communications."

It's a shame that draft-ietf-v6ops-ula-usage-considerations never made it. "The benefit is to ensure stable and specific local communication regardless of the ISP uplink failure."

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 20 May 2020 23:40:42 -0300

On 20/5/20 23:17, Owen DeLong wrote:
>> The recommendations in this document have to do with what the CE 
>> Router does, by default, without human intervention.
>>
> I suspect he’s interpreting it (and some vendors are not unlikely to as 
> well) to say that vendors should not allow this misconfiguration.
> 
> Perhaps if we add the words “by default” or something like that into the 
> language to make it clear that this specifies only the required default 
> behavior
> fo the CE Router and does not preclude knobs allowing one to 
> misconfigure their device to obtain a desired result it would address 
> his singular concern

Then, how about adding this to the "Introduction" section:

"This document specifies recommendations for the default behavior of CE 
Routers, and does not preclude the availability of configuration knobs 
that might allow an operator or user to manually-configure the CE Router 
to deviate from these recommendations"

?

Thanks,

---

From: Owen DeLong <[email-masked]>
Date: Thu, 21 May 2020 19:48:55 -0700

Works for me… 

Owen

> On May 20, 2020, at 19:40 , Fernando Gont <[email-masked]> wrote:
> 
> "This document specifies recommendations for the default behavior of CE Routers, and does not preclude the availability of configuration knobs that might allow an operator or user to manually-configure the CE Router to deviate from these recommendations"
> 
> ?
> 
> Thanks,
> -- 
> Fernando Gont
> SI6 Networks

---

From: Philip Homburg <[email-masked]>
Date: Fri, 22 May 2020 17:18:03 +0200

>It's presumptuous and foolish of the host to over-promise the use of said

I'm not talking about the DHCPv6 client, but about the RA server component.
The RA server gets as input the prefix with lifetimes from DHCPv6, and
(optionally) a request from the operator of the device to advertise a longer
lifetime. In that case the RA server should honour the user's request.

>You might have to expand on why you think shorter lifetimes are "worse".

In any more complex setup where some servers are used both internally
and externally, there is a good chance that even internally the server is
referenced using a public DNS name.

So if the internet connection goes down and the static prefix is no longer
available due to short lifetimes, then internal connections suffer.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 22 May 2020 17:46:38 +0200

>seem to see what you'd be "fixing" by manually extending the lifetimes.

I'm assume that there are and will be plenty of cases where hosts use
the public prefix to communicate internally, certainly if the customer
has a static prefix.

>arguing that you should or should not manually configure stuff in your 

I assume that when RFC 2119 says about MUST NOT: 'This phrase, or the
phrase "SHALL NOT", mean that the definition is an absolute prohibition
of the specification.' it includes overrides by the user.

In particular when SHOULD NOT says: 'This phrase, or the phrase "NOT
RECOMMENDED" mean that there may exist valid reasons in particular
circumstances when the particular behavior is acceptable or even useful,
but the full implications should be understood and the case carefully
weighed before implementing any behavior described with this label.'

But maybe my interpretation is wrong.

BTW, I noticed that the draft does not have the boilerplate text that
refers to RFC 2119.

---

From: Owen DeLong <[email-masked]>
Date: Fri, 22 May 2020 11:53:05 -0700

> On May 22, 2020, at 08:18 , Philip Homburg <[email-masked]> wrote:
> 

Why wouldn’t the operator in such a case simply configure the RA side as static?

Owen

---

From: Fernando Gont <[email-masked]>
Date: Fri, 22 May 2020 16:06:23 -0300

> the public prefix to communicate internally, certainly if the customer

If the prefix is static, I wonder why you'd use DHCPv6. That said, a 
static prefix would be, I guess, a prefix with an infinite lifetime. So, 
if anything, one might consider this value as a special case -- i..e, if 
the DHCPv6 valid-lifetime is infinity (0xffffffff), set the RA lifetime 
to infinity.

> BTW, I noticed that the draft does not have the boilerplate text that

That is indeed a good point. Maybe we should copy the terminology 
section from RFC7084, which describes the usage of these terms in this 
document? Namely:

---- cut here ----
X.Y.  Requirements Language

    Take careful note: Unlike other IETF documents, the key words "MUST",
    "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
    "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used as
    described in RFC 2119 [RFC2119].  This document uses these keywords
    not strictly for the purpose of interoperability, but rather for the
    purpose of establishing industry-common baseline functionality.  As
    such, the document points to several other specifications (preferable
    in RFC or stable form) to provide additional guidance to implementers
    regarding any protocol implementation required to produce a
    successful CE router that interoperates successfully with a
    particular subset of currently deploying and planned common IPv6
    access networks.
---- cut here ----

Thanks,

---

From: Simon Hobson <[email-masked]>
Date: Fri, 22 May 2020 21:41:04 +0100

Philip Homburg <[email-masked]> wrote:

> available due to short lifetimes, then internal connections suffer.

Riiight.
So the network admin has built a network using "consumer grade" or ISP supplied CPE, using default configuration.
Split horizon DNS is not hard, that would deal with it one way by using local addressing internally - just like most people tend to do with IPv4 and NAT already.
Or the network admin could simply statically configure the RAs - so they are not dependent on the WAN link(s) being up.

So the answer to that corner case is simply "properly build your network". Personally I think trying to cater for all use cases, so as to allow a corporate level network to be built without any router config (or, it seems, admin skills), is a road to a massively over-complicated spec that makes it harder rather than easier to build "non-trivial" networks.

Just my 2d worth.

Simon

---

From: Owen DeLong <[email-masked]>
Date: Fri, 22 May 2020 15:26:41 -0700

> On May 22, 2020, at 12:06 PM, Fernando Gont <[email-masked]> wrote:
> 
> If the prefix is static, I wonder why you'd use DHCPv6. That said, a static prefix would be, I guess, a prefix with an infinite lifetime. So, if anything, one might consider this value as a special case -- i..e, if the DHCPv6 valid-lifetime is infinity (0xffffffff), set the RA lifetime to infinity.

Lots of ISPs use the DHCP process to trigger TACACS or RADIUS which is then used to hook in scripts that trigger things like static routes to customer CPE, etc.

Even though the prefix is very long lived, they use DHCP for configuration to reduce customer interactions required for CPE changes, etc.

> That is indeed a good point. Maybe we should copy the terminology section from RFC7084, which describes the usage of these terms in this document? Namely:
> 
> ---- cut here ----

---

From: Philip Homburg <[email-masked]>
Date: Mon, 25 May 2020 16:52:13 +0200

[note, I'm replying here to multiple messages]

> Why wouldnt the operator in such a case simply configure the RA
> side as static?

Yes, but it introduces extra complexity. In particular, the CPE has to
continue to request a prefix using DHCPv6. Then a naive implementation may
end up with two entries for the same prefix in a single RA. Finally, the
implementor may realize that filtering out the prefix from DHCPv6 may
actually cause the CPE to violate a MUST NOT, so a strict interpretation of
the CPE may cause the CPE to remove the user supplied prefix.

> If the prefix is static, I wonder why you'd use DHCPv6. That said,
> a static prefix would be, I guess, a prefix with an infinite
> lifetime. So, if anything, one might consider this value as a
> special case -- i..e, if the DHCPv6 valid-lifetime is infinity
> (0xffffffff), set the RA lifetime to infinity.

The DHCPv6 lifetime is actually very short for reasons I described before.

> section from RFC7084, which describes the usage of these terms in
> this document? Namely:
> 
> ---- cut here ---- X.Y.  Requirements Language
> 
>     Take careful note: Unlike other IETF documents, the key words
>     "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
>     "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>     document are not used as described in RFC 2119 [RFC2119].  This
>     document uses these keywords not strictly for the purpose of
>     interoperability, but rather for the purpose of establishing
>     industry-common baseline functionality.  As such, the document
>     points to several other specifications (preferable in RFC or
>     stable form) to provide additional guidance to implementers
>     particular subset of currently deploying and planned common
>     IPv6 access networks.  

I'm not sure what that means. Does it mean that an implementation is
free to violate a MUST NOT, because it doesn't really mean MUST NOT?

> Riiight.  So the network admin has built a network using "consumer
> grade" or ISP supplied CPE, using default configuration.  

What does this mean? Do we have 'real' routers that allowed to use
longer lifetimes in RAs, because they are expensive and there are
'consumer grade' routers that are not?

Is that how we want to make standards?

> So the answer to that corner case is simply "properly build your
> network". Personally I think trying to cater for all use cases, so
> as to allow a corporate level network to be built without any router
> config (or, it seems, admin skills), is a road to a massively
> over-complicated spec that makes it harder rather than easier to
> build "non-trivial" networks.

The only thing I'm asking for is an exception to the MUST NOT that allows
the admin of the CPE to override the lifetimes. That is not a remote
corner case, that's the kind of stuff every serious router allows the admin
to do.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 25 May 2020 13:49:30 -0300

> the CPE may cause the CPE to remove the user supplied prefix.

Again: this document specifies a recommended behavior when the CE Router 
handles the whole thing automatically. You don't even need permission to 
have a manual knob that allows you to do something else.

> free to violate a MUST NOT, because it doesn't really mean MUST NOT?

It means this is not a protocol spec. In fact, you might well decide to 
not implement this spec and still be compliant with all the protocol specs.

> corner case, that's the kind of stuff every serious router allows the admin

As noted, you're allowed to, already. In fact, I had suggested this text 
(for the "Introduction" section) in another email, which hopefully makes 
this very explicit:

Thoughts?

Thanks!

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

---

From: Owen DeLong <[email-masked]>
Date: Mon, 25 May 2020 20:19:57 -0700

> On May 25, 2020, at 07:52 , Philip Homburg <[email-masked]> wrote:
> 

We are saying that the CE router MUST NOT do this BY DEFAULT.

If the CE router vendor wishes to provide a mechanism whereby the user can
misconfigure their network to misbehave in the way you describe, then they are
free to do so without being in violation of this draft.

Owen

---

From: Philip Homburg <[email-masked]>
Date: Tue, 26 May 2020 18:18:56 +0200

>have a manual knob that allows you to do something else.

If there is consensus that manual configuration does not violate the 
MUST NOT, then why not write something to the effect of: "this does not
affect lifetimes explicitly configured by the operator of the CPE"

>to deviate from these recommendations"

I prefer adding that next to the MUST NOT, however, it does work for me
as well.

I think that MUST NOT should be reserved for cases where there are no
exceptions to the required behavior. So a blanked statement that manually
configuration can always override a MUST NOT strikes me as weird.

---

From: Simon Hobson <[email-masked]>
Date: Tue, 26 May 2020 17:19:31 +0100

> the CPE may cause the CPE to remove the user supplied prefix.

The complexity is caused by insisting on using "not permanent"* addresses for things where you want connectivity to be permanent. So if the user insist on using GUA addresses internally and wanting those addresses to work when the WAN is down - then "something" must be configured in order for that to work. Argue over what that "something" may be - but don't dismiss suggestions as "complexity" when they are required in order to make things work.

* For whatever level of intermittency your WAN connectivity may cause.

> 'consumer grade' routers that are not?

I was not addressing the issue of artificially increasing RA lifetimes - which IMO is the wrong thing to do.

But, IME there are a lot of "lower end" routers out there that have some "interesting" limitations - some to the point where you have to wonder what the design team were smoking when they decided on the feature set !

So, if the "network designer" simply plugs together a bunch of these low end routers, leaves all the knobs (such as are provided) at their defaults, and expects some things to work - such as being able to use the ISP provided GUAs when the WAN link is down - then the network designer is an idiot. In the case in point, the GUA won't ever change because it's "static" - then the workaround is to simply configure a static RA on the appropriate router (with the proviso that the router going down will similarly break internal operations). If the router doesn't have that option - then install something that does. If the router does have that option, but the network designer chooses not to use it - then the network designer is in the wrong and you can't make standards idiot proof.

If the router can't cope with such a static RA configuration - then the router is broken.

And, another point to note ... Statically configuring the prefix is possible without the WAN link being up. If you are using GUAs internally (e.g. by having them in the DNS) then you know what the prefix is and can manually configure it. If the router has lost it's WAN link, and the lease has timed out, then how to you get the router to "know about" the prefix so it can advertise it with mangles timers ?

> corner case, that's the kind of stuff every serious router allows the admin

That would be a router vendor's choice (see above about "interesting" limitations), but I don't believe a standard saying what the default actions should be is stopping it.

But if (for the sake of discussion) "just" extending RA lifetimes is "the answer" - to what value ? A day ? A week ? A month ? What happens when the WAN has been down for "a long time" and things do eventually time out ? I'd argue that in some ways it's worse than a "fairly quick" failure in that it divorces the result (loss of internal connectivity) from the event (loss of WAN link) to a degree that can make troubleshooting harder. And yes, I've known WAN connection be down for days or weeks.
What I have in mind is the naive admin simply extends the RA timers - maybe triggered by having internal stuff stop working when the WAN link is down. Next time the WAN link is down, users are happy that internal stuff still works and the admin pats himself on the back. Or it may be that he's forgotten what he did a couple of years ago. Then (for example) a couple of days later things stop working - but it can't be due to the WAN being down, they've been working OK for the last couple of days.

As an aside I have seen this happen more than once. On one occasion, a router had been added to a network to act as a switch because the user needed some extra ports. Unfortunately, the person adding the router forgot about it's DHCP service ... Nothing broke because it was an all-Windows network and the PCs were typically sticky about their addresses. Until there was another problem, and eventually a bunch of PCs go addresses in a different IPv4 subnet. Cue some head scratching as no changes had been done to the network for many months !

And excuse me for having long since lost track of the details of this, were you proposing that you simply took the DHCPv6 derived PD, ignored the lease length, and then advertised the prefix internally with longer valid times ?
If so, then presumably the router would stop advertising the prefix at some point when the lease expired - but devices would continue to use the prefix due to the extended validity timers ? What happens to devices that re-configure interfaces (link down event, reboot, sleep-wait, ...) - do they simply not use the prefix as it's no longer being advertised ?
What happens when the user - either by themselves or as the first thing instructed by their ISP - reboots the router to see if it restores connectivity ? On the assumption that the router does not have non-volatile storage (for things like this, as is usually the case with low end routers), it will then fail to advertise the prefix anyway - so no device bringing up a link will be able to access internal devices using their GUAs.

Simon

---

From: Owen DeLong <[email-masked]>
Date: Wed, 27 May 2020 00:37:16 -0700

> On May 26, 2020, at 09:18 , Philip Homburg <[email-masked]> wrote:
> 
> affect lifetimes explicitly configured by the operator of the CPE”

It’s already there… The entire document is about what the router can put into RAs
that are based on lifetimes received via DHCP-PD. If you’re hand-configuring them,
then you’re already out of the defined scope of the document.

> configuration can always override a MUST NOT strikes me as weird. 

If that’s the weirdest thing you encounter in RFCs, then you lead a sheltered life.

Owen