Subject: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

From: Fernando Gont <[email-masked]>
Date: Wed, 23 Oct 2019 03:51:32 -0500

Folks,

Earlier this year there was a lot of discussion about slaac renumbering
problems. Our original I-D covered everything from the problem statement
to proposed protocol updates and operational workarounds.

Based on the comments received while discussing this topic on this list
and other forums, and in order to keep the discussion better focused on
specific aspects of the problem, we have posted a v6ops-targetted
document that focuses on:

* The problem statement
* Discussion of operational workarounds, and associated constraints

The document is available at:
https://tools.ietf.org/html/draft-gont-v6ops-slaac-renum

We'd like to hear from the wg whether we have missed anything, whether
the document is useful to the community, etc.

Thanks!

Cheers,
-- 
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, 23 Oct 2019 17:08:15 +0200

>https://tools.ietf.org/html/draft-gont-v6ops-slaac-renum

I think this is an important subject that is worth fixing.

In this reply I'll focus on the preferred and valid lifetimes.

On a host, the preferred and valid lifetimes play quite different roles.

The preferred lifetime plays a role in setting up new flows. I.e. if the
application does not provide a source address then the IPv6 layer uses
the preferred lifetime to select the best source address among multiple
candidates. Mistakenly setting the preferred lifetime of an address to zero 
may cause problems for new flows but has no impact on existing flows

In contrast setting the valid lifetime to zero immediately signals an error
condition to existing flows. This could cause a lot of trouble for long 
lived flows.

The other side of the coin is that if a host ends up with stale prefixes,
then the user maybe willing to wait for a few minutes for the situation to
resolve itself, but probably not much longer.

So the suggestion that
	AdvPreferredLifetime: AdvDefaultLifetime
is likely not sufficient to be responsive to a user. And at the same time
	AdvValidLifetime: 1.5 * AdvDefaultLifetime
is very risky if AdvDefaultLifetime is low.

Note that RFC 4861 allows MaxRtrAdvInterval to be a low as 4 seconds, 
AdvDefaultLifetime can be as low as MaxRtrAdvInterval, so also 4 seconds.

This creates a very fragile system.

At the same time, AdvDefaultLifetime is commonly 1800 seconds. Which is way
too long to wait for stale information to expire.

I agree that valid and preferred lifetimes of resp. 30 days and 7 days 
are excessive. But I'm not at all convinced that tying them to 
AdvDefaultLifetime will have a positive effect. I'm also not convinced
that there are sensible values for these lifetimes that are robust enough 
and at the same time responsive enough to deal with the issue at hand.

Reducing the lifetimes would help against build up of stale prefixes. If
they are set to a couple of hours.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 23 Oct 2019 11:07:20 -0500

> resolve itself, but probably not much longer.

Agreed.

> This creates a very fragile system.

I may agree. That said, note that according to RFC7772, you'd never send
RAs at a high frequency such as once as every 4 seconds.

> AdvDefaultLifetime will have a positive effect.

I'd say that at the very least the Preferred lifetime shouldn't be
larger than AdvDefaultLifetime (what's the point of preferring an
address you don't have a router for?).

I do agree with your analysis of the valid lifetime -- is trickier.

> I'm also not convinced

I do agree that this is not a complete solution, but, as you correctly
note, would help against build up of stale prefixes.

A better mitigation is to affect the preferred and possibly the valid
lifetimes in response to consecutive RAs from the same router that lack
the original (stale) prefix. e.g., after two consecutive RAs that do not
contain the existing prefix, reduce the preferred lifetime. After two
additional RAs, reduce the valid lifetime.

Thoughts?

Thanks!

Cheers,

---

From: Philip Homburg <[email-masked]>
Date: Thu, 24 Oct 2019 09:42:58 +0200

>additional RAs, reduce the valid lifetime.

I think that to avoid confusion it is probably best to have 3 documents:
- one that describes host behavior. I think that what you describe above would
  fit in such a document. There is a lot we can do to make hosts more robust.
- one that describes CPE behavior. If the CPE explicitly deprecates old
  prefixes then that solves the problem with CPE reboots. Having
  more sensible lifetimes fits in such a document, but I don't think it
  provides a solution. It just reduces some secondary effects such as
  stale prefix build up.
- Finally, a document for ISPs describing how to best provide prefixes 
  using DHCPv6-PD. 

I think all 3 approaches are needed:
- a host doesn't want to rely on a cheap CPE doing its job.
- a quality CPE can provide better support for hosts today. There will always
  be ISPs that do flash renumbering
- finally a quality ISP may have a need to renumber customers and would like
  to do so without breaking things.

---

From: Mark Smith <[email-masked]>
Date: Thu, 24 Oct 2019 19:17:45 +1100

On Thu, 24 Oct 2019, 03:08 Fernando Gont, <[email-masked]> wrote:

> > candidates.

Actually it doesn't, according to SA selection in RFC 6724.

It's easy to think that, which is why I have in the past.

I've even thought about proposing it, however when you think about it, you
realise there are cases where it wouldn't work. The largest preferred
lifetime address isn't always the best SA to use.

For example, say you wanted to renumber a network. At the same time, you
want to have a lower preferred and valid lifetime for the new prefix
(perhaps it was set too high when the network was built). Yet the as the
old addresses still have larger preferred lifetimes, they would be
preferred.

What you're really trying to choose is the newest addresses learned by the
host. Preferred lifetime doesn't really always tell you that.

I thought about this in the exact context of the scenario of this draft.
Although the design of the broadband deployment I worked on always planned
to give out stable prefixes, I worked through this scenario and realised
that so many complex issues disappear if you provide stable prefixes.

Fundamentally, if an ISP is selling an always on link to the same location,
then the addressing should be as permanent as the link delivery location is.

Mistakenly setting the preferred lifetime of an address to zero
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 24 Oct 2019 11:20:57 +0200

> the document is useful to the community, etc.

The document is useful because it sheds light on an existing problem 
that is not described elsewhere.

In particular, the home networks scenario is very appropriate.

First, I must say that the home network that I use uses a fixed /56 
allocated by my ISP.  In this, the prefix never changes, and it is not 
obtained by DHCPv6-PD - it is guaranteed by contract signed by hand. 
Such a case could be mentioned, as not being a problem described in this 
draft.

Second, with respect to this text:
> o  The most common deployment scenario for IPv6 in home networks is
>       that in which a CPE router employs DHCPv6 Prefix Delegation
>       (DHCPv6-PD) [RFC8415] to request a prefix from an Internet Service
>       Provider (ISP), and a sub-prefix of the leased prefix is
>       advertised on the LAN-side of the CPE router via Stateless Address
>       Autoconfiguration (SLAAC) [RFC4862].  In scenarios where the CPE
>       router crashes and reboots, the CPE may be leased (via DHCPv6-PD)
>       a different prefix from the one previously leased, and therefore
>       advertise (via SLAAC) the new prefix on the LAN side.

I agree with this deployment scenario.  We have used a similar scenario 
here in the lab (not at home).  We wrote a 'DANIR' draft that describes 
the implementation: the IoT Router (similar to a CPE) requests a prefix 
with DHCPv6-PD and then forms /64s and advertises them on the Ethernet link.

I must say that this kind of software (request a prefix with DHCPv6-PD, 
form sub-prefixes, and put them in RAs on the other interfaces) does not 
exist as open source or some other available package.

Because of that, I am surprised that you call it 'the most common 
deployment scenario'.  Is this a scenario that is _expected_ to be 'common'?

Then, a list of bullets follow, with more scenarios.

I would like to request addition of two other scenarios:

- an IoT scenario, in which an IoR Router connects several sensors to 
the Internet.  For example, an IoT Router is deployed in a box at a 
traffic lights.  The IoT device is the Traffic Lights Controller 
connected on Ethernet to the IoT Router.  The IoT Router is connected on 4G.

- a vehicular networks scenario: the On-Board Unit is deployed in a car. 
  This OBU has a 4G interface and an Ethernet interface.  There are 
several computers in the car that need IPv6 addresses.

One may think about fitting these proposed two scenarios (IoT, and 
vehicles) into the three others ('switch-port VLAN', 'planned network 
renumbering' or 'automated device config mgmt').  But these scenarios 
sound more like Enterprise.  IoTs and vehicles rarely if ever involve 
VLANs or planned network renumberng.

Alex

---

From: Trevor Warwick <[email-masked]>
Date: Thu, 24 Oct 2019 10:57:26 +0100

On Thu, 24 Oct 2019 at 09:18, Mark Smith <[email-masked]> wrote:

> Fundamentally, if an ISP is selling an always on link to the same
> location, then the addressing should be as permanent as the link delivery
> location is.
>
>
If you're an ISP today, and using DHCPv6-PD to hand out IPv6 prefixes, what
are the possible scenarios if you don't try hard to keep the prefixes
stable?

- You could be running a closed environment where all customers are forced
to use your CPE, in which case you can make sure that your CPE has various
 hacks added to try to cope with prefix instability and avoid customer
hosts experiencing connectivity issues when prefixes change. Maybe you can
make this work well enough, and advanced customers who don't want to use
your CPE are just out of luck.

- If you're in an environment where customers can chose their own CPE, then
it seems almost guaranteed that there will be connectivity problems when
the prefix changes, because many CPE implementations don't handle this
situation at all. So you're then relying on hosts falling back seamlessly
to IPv4, in order to continue to have connectivity. In which case, I'd
wonder why you're bothering to provide an IPv6 service in the first place.

I do think this is an important problem that needs to be solved, for this
context and the others mentioned in the draft.

---

From: Mark Smith <[email-masked]>
Date: Thu, 24 Oct 2019 21:43:43 +1100

On Thu, 24 Oct 2019, 20:59 Trevor Warwick, <[email-masked]> wrote:

> If you're an ISP today, and using DHCPv6-PD to hand out IPv6 prefixes,
> what are the possible scenarios if you don't try hard to keep the prefixes
> stable?
>

Why don't you want to try hard? Not trying hard gives customers a bad
experience. They're paying you to try hard to give them the best suitable
service you can give them.

> - If you're in an environment where customers can chose their own CPE,
> then it seems almost guaranteed that there will be connectivity problems
> when the prefix changes, because many CPE implementations don't handle this

See what I said about selling an always on service to a fixed location, and
the addressing having the same amount of stability as the service and link
itself.

The reason this problem really exists is that ISPs have fundamentally
continued to treat residential, always on broadband customers although they
were still dial up customers. Nothing has changed - per BRAS (NAS) IP
address pools, pool route aggregation at the router, customer gets a single
IPv4 address when they attach, that can change each time they attach. PPPoE
is making Ethernet connectivity resemble dial up connectivity.

Now this dial up model is trying to be applied to semi-permanent IPv6
services, where it's even less applicable now that customers get their own
routed address space on a semi-permanent link.

Treat all customers as routed subnet SOHO customers, so they get the same
prefix regardless of which BRAS they attach to. Move the route aggregation
boundary to a higher level to e.g. a cluster of BRASes, or a region.

Use an IPv6 address provisioning model that suites and matches the service
they're paying for, not a nearly 30 year old dial up model.

If your customers can BYO their CPE, then stable prefixes are the only
choice.

See slide 6.

Residential IPv6 CPE - What Not to Do and Other Observations
https://www.slideshare.net/mobile/markzzzsmith/residential-ipv6-cpe-what-not-to-do-and-other-observations

---

From: Ole Troan <[email-masked]>
Date: Thu, 24 Oct 2019 12:47:08 +0200

Mark,

Right. Instant/flash renumbering is not supported in IP networks.
IPv6 does nothing to help with this, well, assuming a network hiding behind NAT, it makes it harder.
Apart from "does not work", what more can the IETF say or do here?

Cheers,
Ole

> On 24 Oct 2019, at 12:43, Mark Smith <[email-masked]> wrote:
> 
> 
> 
> I thought about this in the exact context of the scenario of this draft. Although the design of the broadband deployment I worked on always planned to give out stable prefixes, I worked through this scenario and realised that so many complex issues disappear if you provide stable prefixes.
> 
> Fundamentally, if an ISP is selling an always on link to the same location, then the addressing should be as permanent as the link delivery location is.
> 
>  
> If you're an ISP today, and using DHCPv6-PD to hand out IPv6 prefixes, what are the possible scenarios if you don't try hard to keep the prefixes stable?
> 
> Why don't you want to try hard? Not trying hard gives customers a bad experience. They're paying you to try hard to give them the best suitable service you can give them.
> 
> 
> - You could be running a closed environment where all customers are forced to use your CPE, in which case you can make sure that your CPE has various   hacks added to try to cope with prefix instability and avoid customer hosts experiencing connectivity issues when prefixes change. Maybe you can make this work well enough, and advanced customers who don't want to use your CPE are just out of luck.
> 
> - If you're in an environment where customers can chose their own CPE, then it seems almost guaranteed that there will be connectivity problems when the prefix changes, because many CPE implementations don't handle this situation at all. So you're then relying on hosts falling back seamlessly to IPv4, in order to continue to have connectivity. In which case, I'd wonder why you're bothering to provide an IPv6 service in the first place. 
> 
> See what I said about selling an always on service to a fixed location, and the addressing having the same amount of stability as the service and link itself.
> 
> The reason this problem really exists is that ISPs have fundamentally continued to treat residential, always on broadband customers although they were still dial up customers. Nothing has changed - per BRAS (NAS) IP address pools, pool route aggregation at the router, customer gets a single IPv4 address when they attach, that can change each time they attach. PPPoE is making Ethernet connectivity resemble dial up connectivity.
> 
> Now this dial up model is trying to be applied to semi-permanent IPv6 services, where it's even less applicable now that customers get their own routed address space on a semi-permanent link.
> 
> Treat all customers as routed subnet SOHO customers, so they get the same prefix regardless of which BRAS they attach to. Move the route aggregation boundary to a higher level to e.g. a cluster of BRASes, or a region.
> 
> Use an IPv6 address provisioning model that suites and matches the service they're paying for, not a nearly 30 year old dial up model.
> 
> If your customers can BYO their CPE, then stable prefixes are the only choice.
> 
> See slide 6.
> 
> I do think this is an important problem that needs to be solved, for this context and the others mentioned in the draft.
> 
>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 24 Oct 2019 08:12:21 -0300

> Apart from "does not work", what more can the IETF say or do here?

Maybe honor the "E" in IETF? :-)

P.S.: The ISP renumbers the residential user is just one of many reasons
for which this scenario could take place.

Thanks,

---

From: Mark Smith <[email-masked]>
Date: Thu, 24 Oct 2019 22:13:05 +1100

> Apart from "does not work", what more can the IETF say or do here?

I think the issue could be not real knowing or thinking about any
alternatives and not knowing that while it may have been possible to
continue to follow the dial up model for IPv4 with NAT, that model can't be
stretched to accommodate IPv6 and delegated prefixes without causing the
issues in the draft.

So an Informational RFC?

> > - You could be running a closed environment where all customers are
> forced to use your CPE, in which case you can make sure that your CPE has
> various   hacks added to try to cope with prefix instability and avoid
> customer hosts experiencing connectivity issues when prefixes change. Maybe
> you can make this work well enough, and advanced customers who don't want
> to use your CPE are just out of luck.
> >
> > See what I said about selling an always on service to a fixed location,
> and the addressing having the same amount of stability as the service and
> link itself.
> >
> > Treat all customers as routed subnet SOHO customers, so they get the
> same prefix regardless of which BRAS they attach to. Move the route
> aggregation boundary to a higher level to e.g. a cluster of BRASes, or a
> region.
> >
> > Use an IPv6 address provisioning model that suites and matches the
> service they're paying for, not a nearly 30 year old dial up model.
> >
> > I do think this is an important problem that needs to be solved, for
> this context and the others mentioned in the draft.
> >
> >

---

From: Fernando Gont <[email-masked]>
Date: Thu, 24 Oct 2019 08:17:48 -0300

Hello, Philip,

>   fit in such a document. There is a lot we can do to make hosts more robust.

Agreed. FWIW, We should have such document ready this weekend.

>   provides a solution. It just reduces some secondary effects such as

Agreed

>   to do so without breaking things.

I fully agree with your assessment. That said, maybe the first step is
to start with a problem statement, as with this document?

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 24 Oct 2019 08:22:52 -0300

On 24/10/19 03:17, Mark Smith wrote:
> 
> 
> On Thu, 24 Oct 2019, 03:08 Fernando Gont, <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> Actually it doesn't, according to SA selection in RFC 6724.>

Using the preferred lifetime for SAS makes the source address flap if
there are multiple prefixes on the local network. This is not nice for
troubleshooting.

> I've even thought about proposing it, however when you think about it,
> you realise there are cases where it wouldn't work. The largest
> preferred lifetime address isn't always the best SA to use.

Indeed. And while there are recommended defaults, multiple routers might
be using different preferred lifetimes for the prefixes they advertise.

> Although the design of the broadband deployment I worked on always
> planned to give out stable prefixes, I worked through this scenario and
> realised that so many complex issues disappear if you provide stable
> prefixes.

FWIW, we're not against stable prefixes. We recognize there are
scenarios in which they will not be stable, and we want the network to
be robust in such scenarios.

Thanks!

Cheers,

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 24 Oct 2019 13:11:03 +0000

Ole

What about a "IPv6 renumbering considered harmful" or "Unstable DHCP-PD prefix considered harmful" ?

-éric (enjoying my 3-year old /48 or is it 5 years?)

On 24/10/2019, 12:47, "v6ops on behalf of Ole Troan" <[email-masked] on behalf of [email-masked]> wrote:

    Mark,

    Cheers,
    Ole

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 24 Oct 2019 15:34:44 +0200

+1 !

Regards,
Jordi
@jordipalet

El 24/10/19 15:12, "v6ops en nombre de Eric Vyncke (evyncke)" <[email-masked] en nombre de [email-masked]> escribió:

    Ole

    
        Mark,

        Cheers,
        Ole

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Ole Troan <[email-masked]>
Date: Thu, 24 Oct 2019 15:38:36 +0200

Eric,

> What about a "IPv6 renumbering considered harmful" or "Unstable DHCP-PD prefix considered harmful" ?

Perhaps, but isn't there a long list of documents the IETF has produced on IPV6 renumbering already?
Would a new document say anything new and more useful?

And it's not like DHCPv6 PD (RFC3633) isn't clear either. From the abstract:

   The Prefix Delegation options provide a mechanism for automated
   delegation of IPv6 prefixes using the Dynamic Host Configuration
   Protocol (DHCP).  This mechanism is intended for delegating a long-
   lived prefix from a delegating router to a requesting router, across
   an administrative boundary, where the delegating router does not
   require knowledge about the topology of the links in the network to
   which the prefixes will be assigned.

That said, if people want to write a "IPv6 networks need stable prefixes" document, go ahead.
I'm skeptical that playing with prefix timers and protocol mechanisms will do more than put lipstick on the pig. Iff we wanted to solve ephemeral addressing / connectivity, that's would require something else.

Best regards,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 24 Oct 2019 15:43:27 +0200

Le 24/10/2019 à 15:11, Eric Vyncke (evyncke) a écrit :
>  [...] "Unstable DHCP-PD prefix considered harmful" ?

Risks being shortened to an as harmful 'DHCP-PD considered harmful'.

Alex

---

From: Owen DeLong <[email-masked]>
Date: Thu, 24 Oct 2019 08:57:01 -0700

> On Oct 23, 2019, at 08:08 , Philip Homburg <[email-masked]> wrote:
> 

Isn’t the issue of stale information strictly under the control of the person running
the router(s)?

I mean during normal operations, 1800 seconds seems like a reasonable default
to me. In an environment where you are depending on routers advertising different
prefixes on the same network for redundancy (you’ve kind of cobbled things
poorly to begin with), you’ll want to select a shorter time, certainly, but then you
have that option. In a more traditional environment where you have multiple
routers announcing the same prefix providing redundancy, then it seems to me
that the prefix only goes stale during a renumber event.

The procedure for renumbering a SLAAC network should be relatively straightforward…

1.	Configure and test new prefix on routers and perhaps a few test hosts with manual
	configuration.

2.	Begin announcing new prefix via RAs.

3.	Note the Valid Lifetime for the old prefix. (Tvold).

4.	Take the old prefix out of the RAs (leave it fully configured on the routers).

5.	Wait some time greater than Tvold for the old prefix to expire.

6.	Remove the old prefix from the routers.

> and at the same time responsive enough to deal with the issue at hand.

Any tying of them to AdvDefaultLifetime should be merely for the purpose of
establishing a default, which seems a reasonable process. Certainly there
is a need for the Valid and Preferred lifetimes to be ≥ MaxRtrAdvInterval
which must be ≤ AdvDefaultLifetime for things to function at all.

> they are set to a couple of hours.

Shouldn’t this be an individual administrative decision on a site-by-site
basis?

If we’re looking to set more rational defaults or provide advice on better
defaults to administrators and/or product developers, then perhaps we
should provide a context-aware set of rational defaults for these variables.

IMHO, there are a number of contexts each of which would likely need
different values to achieve an optimum balance:

	Single-homed household or SMB end-user
	Multi-homed multi-prefix household or SMB end-user
	Multi-homed single-prefix (BGP) end site
	Enterprise Environment
	Transit Network (would you even use SLAAC here?)
	Others?

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 24 Oct 2019 09:52:31 -0700

> note, would help against build up of stale prefixes.

I do agree that 7 and 30 days, respectively are absurd timer default values.

I think we can take some lessons from IPv4 and DHCP here. A fairly common
lease time in the DHCP world is 3600 seconds (1 hour). This seems like a
reasonable default preferred lifetime and I would propose that 1 day (86400)
seconds may well be a reasonable default valid lifetime.

It is worth noting that these values are tunable by the administrator and the
RFC suggested defaults should never be a hard-coded value.

With the following exception, I don’t advocate modifying this on the client
side:
	+	Section 5.5.3 of RFC4862 should be amended to specifically
		allow the immediate deprecation of a prefix by sending a valid
		lifetime of 0 seconds. Hosts should be required to honor
		this as a signal that the prefix is no longer valid.

I do think that generally speaking, your proposed modifications to CPE and
router behavior should be standardized and implemented.

> additional RAs, reduce the valid lifetime.

In the crash scenarios you describe, you’re assuming a single router on the network or
at least only one router announcing the prefix(es) in question with no persistent
memory of the prefixes it was announcing across a reboot. In such a scenario,
it seems to me that the following are also likely valid assumptions:

	+	The network has significant excess bandwidth compared to demand.
	+	The small overhead of frequent RAs and short lifetimes is probably
		an acceptable tradeoff in this environment.

However, there are lots of other scenarios in the world where those assumptions
won’t hold true and we should not seek to solve this problem (which is generally
applicable to residential and SMB environments) at the expense of all of those
other professionally administered environments.

For

For the busy wifi scenario, the preferred lifetime of zero for the old PIO should be
sent many times and should be maintained in the configuration for at least
OldPreferredLifetime seconds. At the end of OldPreferredLifetime seconds,
if a host hasn’t seen the new RA, it will no longer matter as the last RA it saw
will have expired. It’s not ideal, but there really aren’t a lot of good options here
other than getting WiFi vendors to improve multicast reliability.

In your automated configuration management scenario, IMHO, the people
driving the automation have erred. The related case is, IMHO, a variant
of the exact same case and represents the same error. It is still operator
error regardless of whether the operator is driving an automation system,
or is directly configuring a router. At a certain point, we need to accept that
there is a limit to the acceptable gymnastics for the prevention of operator
error. The best colloquialism here is “If you make something completely
idiot proof, the world will invent a better idiot.”

In section 3.2.1, you advocate setting the A and L bits to their previous values
for prefixes which are being deprecated. IMHO, this is incorrect and the
announcements calling for immediate deprecation should also indicate that
the prefix should no longer be auto-configured and should no longer be
considered on-link.

Is there some unfortunate widely deployed behavior that interacts poorly
with setting A and L to 0 for these previously valid prefixes?

Finally, An editorial note… In Section 3, you state “Finally, Section 2.5 analyzes…”
I believe this is intended to be a reference to section 3.2.2.

Owen

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Oct 2019 08:38:42 +1300

> Would a new document say anything new and more useful?

I doubt it, although we did leave many dangling problems in
https://tools.ietf.org/html/rfc7010

     Brian

> .

---

From: Mark Smith <[email-masked]>
Date: Fri, 25 Oct 2019 08:47:09 +1100

> Risks being shortened to an as harmful 'DHCP-PD considered harmful'.

If you're going to suggest that, you better say why.

DHCPv6-PD has facilitated residential IPv6 deployment. There would have
been no practical way to do it otherwise.

> > On 24/10/2019, 12:47, "v6ops on behalf of Ole Troan" <
> [email-masked] on behalf of [email-masked]> wrote:
> >
> >      Mark,
> >

---

From: Philip Homburg <[email-masked]>
Date: Fri, 25 Oct 2019 10:36:44 +0200

>I'm skeptical that playing with prefix timers and protocol mechanisms will do m
>ore than put lipstick on the pig. Iff we wanted to solve ephemeral addressing /
> connectivity, that's would require something else.

A typical home situation today has almost exclusively outbound connections.
People also accept that if you reboot a home router, a video stream may
be interrupted.

Where general problem of renumbering is hard to solve, the more limited 
home use case is not. For IPv4 all of this is hidden by NAT in the CPE.

After the previous discussion, I updated my IPv6 stack to do detect prefixes
that are no longer announced in RAs. This does solve the problem at hand.

Previously, AVM CPEs (Fritz!Box) would actively kill weird prefixes used
by hosts. That was quite effective, though has some weird side effects.
So a CPE solution is likely to solve this problem as well.

This is problem that can be solved both in the host and in the CPE.

Of course, we can also wait for ISPs to start shipping CPEs with NAT66.

Reality is that ISPs do flash renumbering for IPv4 customers. We can tell them 
that they cannot do that for IPv6, but that will result either in a delay
of IPv6 deployment, or they will find a hack (such as NAT66) to make it 'work'.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 25 Oct 2019 10:42:51 +0200

>to start with a problem statement, as with this document?

The current draft is not a problem statement. From Section 3 it describes
potential solutions.

I'm not sure a separate problem statement is needed. The relevant
documents can start with a description of what is happening today.
In perfect world, bad things do not happen, but we don't live in a 
perfect world. Most customers don't have the luxury position to change ISPs
just because their ISP does flash renumbering.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 25 Oct 2019 12:53:46 +0200

Le 24/10/2019 à 23:47, Mark Smith a écrit :
> 
> 
> On Fri, 25 Oct 2019, 00:43 Alexandre Petrescu, 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 

BEcause people take DHCPv6 for DHCPv4.

I'd rather say:

'linux lack of a light kernel built-in DHCPv6 client is considered
  harmful'
'sticked addresses on interfaces after prefix expiration is considered
  harmful'
'lack of DHCPv6-delegated prefix presence in RA is considered
  harmful'
...

> been no practical way to do it otherwise.

Probably DHCPv6-PD has facilitated residential IPv6 deployment.  I will
not argue about the practicability of other ways, but while my ISP
(Free) delivers /56s w/o DHCPv6-PD since many years (supposedly w/
'6rd') it also engaged on a migration path to 'native IPv6' since 2017,
that I do not really understand whether or not it uses DHCPv6-PD.

Alex

>      > On 24/10/2019, 12:47, "v6ops on behalf of Ole Troan"
>     <[email-masked] <mailto:[email-masked]> on behalf of
>     [email-masked] <mailto:[email-masked]>> wrote:
>      >
>      >      Mark,
>      >
>      >      IPv6 does nothing to help with this, well, assuming a
>     network hiding behind NAT, it makes it harder.
>      > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 25 Oct 2019 12:56:35 +0200

As usual, I think one wants to make sure about which link layer does one 
talk in the Problem Statement and Operational workarounds.

It might very well be that this DHCPv6-PD usefulness pertains to certain 
links (optical, in this case) and not in others (ADSL, or 4G).

This relates directly to many ISPs.

Alex

Le 25/10/2019 à 12:53, Alexandre Petrescu a écrit :
>>      >  [...] "Unstable DHCP-PD prefix considered harmful" ?
>>
>> DHCPv6-PD has facilitated residential IPv6 deployment. There would 
>> have been no practical way to do it otherwise.
> 
>>      >
>>      > -éric (enjoying my 3-year old /48 or is it 5 years?)
>>      >
>>      >
>>      > On 24/10/2019, 12:47, "v6ops on behalf of Ole Troan"
>>      >
>>      >      Mark,
>>      >
>>      >      Right. Instant/flash renumbering is not supported in IP
>>     networks.
>>      >      IPv6 does nothing to help with this, well, assuming a
>>      >      Apart from "does not work", what more can the IETF say or do
>>     here?
>>      >
>>      >      Cheers,
>>      >      Ole
>>      >
>>      >
>>      > _______________________________________________
>>      > v6ops mailing list
>>      > [email-masked] <mailto:[email-masked]>
>>      > https://www.ietf.org/mailman/listinfo/v6ops
>>      >
>>

---

From: Ole Troan <[email-masked]>
Date: Fri, 25 Oct 2019 14:22:20 +0200

> of IPv6 deployment, or they will find a hack (such as NAT66) to make it 'work'.

a home network with ephemeral addressing stuck behind a firewall.
what is the point of IPv6 over IPv4+NAT? what value does IPv6 bring?

exposing external addressing in the internal network, combined with exposing network layer addressing to the transport and application layers is one of the bigger short-comings of IPv6.

Cheers,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Fri, 25 Oct 2019 14:43:54 +0200

>what is the point of IPv6 over IPv4+NAT? what value does IPv6 bring?

In the case of, for example, youtube and netflix, the advantage is that
high volume flows are not going through the ISP's CGNAT.

In the case of certain banks that support IPv6, the advantage is that
there is no risk that multiple households will share a single IPv4 address.

In any case, it doesn't matter how much benefit IPv6 brings over IPv4. We
are out of IPv4 addresses. Time to get rid of IPv4.

>exposing external addressing in the internal network, combined with 
>exposing network layer addressing to the transport and application 
>layers is one of the bigger short-comings of IPv6.

There are all kinds of problems with IPv6. But I don't think we want to wait
for a resign of IPv6 or the transport and application layers.

---

From: Ole Troan <[email-masked]>
Date: Fri, 25 Oct 2019 14:53:43 +0200

> high volume flows are not going through the ISP's CGNAT.

how is that an advantage for the end user?
it might be for the ISP. but that's the entity that cannot give stable addressing in the first place...

> there is no risk that multiple households will share a single IPv4 address.

that's a solved problem. security is done at a higher layer regardless.

> are out of IPv4 addresses. Time to get rid of IPv4.

if IPv6 provides no benefit over IPv4 then why?
32 + 16 > 128.
or if we allow IPv6 to have no benefit over IPv4 I could rather say.

> for a resign of IPv6 or the transport and application layers.

The changes in the transport and application layers are already happening (e.g. QUIC).
There are already "redesigns" of IPv6. Take ILNP.

I'm not the one proposing an IPv6 redesign. This is a response to the proposals of violating a fundamental expectation of stable addressing in IPv6.

cheers,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Fri, 25 Oct 2019 15:14:59 +0200

>addressing in the first place...

If routing IPv6 is cheaper than CGNAT IPv4 then either the ISP can offer
higher bandwidth for the same price or reduce prices.

In any case, very often the user doesn't have a choice. I would like to
have reverse DNS delegated for all my IPv6 prefixes. That is just not going
to happen.

>that's a solved problem. security is done at a higher layer regardless.

Not for that particular bank. They are very much interested in IP addresses.

>if IPv6 provides no benefit over IPv4 then why?

The benefit of IPv6 is that IPv6 addresses are almost for free, whereas a
single IPv4 address costs a significant chunk of money (compared to other
costs).

>The changes in the transport and application layers are already 

If QUIC can deal with this flash renumbering problem then it would be nice
to see a report on that. I'm very curious how to would work.

In any case, there will continue to be a lot of TCP and non-QUIC UDP in
the coming years. Are you saying that it will be cheaper to modify all
transport protocols than to fix it in the IPv6 stack?

>There are already "redesigns" of IPv6. Take ILNP.

As far as I know ILNP never got any traction. Do propose we hold off on 
deplying IPv6 until ILNP is mature?

>I'm not the one proposing an IPv6 redesign. This is a response to the 
>proposals of violating a fundamental expectation of stable addressing in 
>IPv6.

The current reality is that IPv6 addresses are not stable in many deployments.
Yes, that's a pity. I'm personnaly very happy with my stable prefixes.

But we have to adapt IPv6 to the real world. Everybody who has stable
prefixes today benefits from having more IPv6 in the world.

Keeping IPv6 restrict to a small, pure corner of the world provides no
benefits.

---

From: Mark Smith <[email-masked]>
Date: Sat, 26 Oct 2019 00:16:35 +1100

On Fri, 25 Oct 2019 at 19:37, Philip Homburg <[email-masked]> wrote:

<snip>

>
> Reality is that ISPs do flash renumbering for IPv4 customers.

Why?

Between 2005 and 2011, I worked for two residential ISPs, one state
based with 80 000 customers, and another national one, with 160 000
customers. In all that time, I never needed to or saw anybody
intentionally "flash renumber" as far as I can remember.

The only time I can see a need to purposefully "flash renumber" would
be if you want to shift around IP address pools across to different
BRASes. I don't think that is a common event. (The common event was
adding new IP addresses to existing per-BRAS pools, as customer
numbers grew.)

So I would like to hear from ISPs that purposely "flash renumber" why
they do so, and how often.

People are trying to continue to use the decades old dial up model.
That's understandable - "if it ain't broke, don't fix it". It could be
carried over from dial to residential broadband IPv4+NAT, because
there were enough similarities. The problem is that it is broken when
applied to IPv6.

You don't keep using old solutions and ideas when they start to cause
too many problems, and require too many work arounds to keep using
them. Too many problems caused by the old method and too many work
arounds to overcome them is a sign the old solution is really beyond
its useful life and a new solution is necessary.

>We can tell them

---

From: Clark Gaylord <[email-masked]>
Date: Fri, 25 Oct 2019 09:24:46 -0400

Note: that makes your sample size 2, not 240,000....

Renumbering is not "common" but it certainly happens. With that said,
"flash renumber" could reasonably be considered a "high support risk"
operation.. IPv6 is supposed to accommodate renumbering *more* gracefully,
not less, than legacy IP, but it is still supposed to be a planned event.

--
Clark Gaylord
[email-masked]
... autocorrect may have improved this message ...

---

From: Ole Troan <[email-masked]>
Date: Fri, 25 Oct 2019 15:25:36 +0200

> transport protocols than to fix it in the IPv6 stack?

It can't be fixed in the IPv6 stack.
The only thing you can do is to make the IPv6 network not work significantly worse than a flash renumbered IPv4 + NAT network.

My argument is that if you do that, as in add support for ephemeral addressing / flash renumbering at the network layer, without doing anything at upper layers, then for an end-user, IPv6 will provide no value or more likely negative value compared to IPv4 + NAT.

Cheers,
Ole

---

From: Gert Doering <[email-masked]>
Date: Fri, 25 Oct 2019 15:28:22 +0200

Hi,

> My argument is that if you do that, as in add support for ephemeral addressing / flash renumbering at the network layer, without doing anything at upper layers, then for an end-user, IPv6 will prov…

Nothing in the lower layers of the IP stack provides any "value" to the 
end-user.

Which is why they are not banging at our doors demanding "TCP!" or
"DNS!" or "IPv4".  Or, "IPv6", for that matter.

Applications need to work, and applications have learned how to survive
NAT breakage, so applications need to learn how to do deal with non-stable
IPv6 addresses.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 25 Oct 2019 15:27:03 +0100

Ole Troan wrote on 25/10/2019 13:53:
> This is a response to the proposals of violating a fundamental
> expectation of stable addressing in IPv6.
is that a fundamental design principle of ipv6?  This is news.

Nick

---

From: Richard Patterson <[email-masked]>
Date: Fri, 25 Oct 2019 17:07:51 +0100

> they do so, and how often.

I wouldn't say purposely, we've gone to a lot of effort to keep them as
stable as possible, however, there are times where network events could
cause a current lease to become stale (or invalid), and for the new lease
to contain a different prefix.
i.e.  If our transmission team decide to re-home a metro area, or if the
capacity planning team decides to rebalance between BNGs.

We don't offer truly static PD assignments as we don't have to build and
maintain a topology aware IPAM <-> RADIUS service, when we can simply let
the BNG/DHCPv6 server deal with assignments dynamically.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 25 Oct 2019 13:58:29 -0300

On 25/10/19 09:22, Ole Troan wrote:
>> Reality is that ISPs do flash renumbering for IPv4 customers. We
>> can tell them that they cannot do that for IPv6, but that will
>> result either in a delay of IPv6 deployment, or they will find a
>> hack (such as NAT66) to make it 'work'.
> 

That if you *want* to do something else, you *can*.

> layers is one of the bigger short-comings of IPv6.

Not sure what you mean.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 25 Oct 2019 14:19:16 -0300

>    which the prefixes will be assigned.

Long-lived != immortal. As long as a prefix eventually changes, that is
when the problem may be experienced.

> I'm skeptical that playing with prefix timers and protocol mechanisms will do more than put lipstick on the pig.

It's not putting lipstick on a pig. In the current situation, hosts
essentially do not react to prefixes that fade away. This is something
that can be easily improved.

> Iff we wanted to solve ephemeral addressing / connectivity, that's would require something else.

Could you please elaborate on what you mean by ephemeral addressing /
connectivity?

Thanks,

---

From: Ole Troan <[email-masked]>
Date: Fri, 25 Oct 2019 19:40:46 +0200

> On 25 Oct 2019, at 19:34, Fernando Gont <[email-masked]> wrote:
> 

Not if renumbering of the network is done according to specification. 
Flash renumbering is not defined so no-one should be surprised that you get undefined behavior. 

O.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 25 Oct 2019 14:45:15 -0300

> I do agree that 7 and 30 days, respectively are absurd timer default values.

Exactly. *That* is the point.

> seconds may well be a reasonable default valid lifetime.

That's certainly an improvement wrt what we have right now.

> +Section 5.5.3 of RFC4862 should be amended to specifically

Could you please elaborate on this one?

> +The network has significant excess bandwidth compared to demand.
> +The small overhead of frequent RAs and short lifetimes is probably

Even with the default RA frequency, if you were to unprefer a prefix
upon, say, second RA that doesn't advertise it, and say, remove the
prefix after many other RAs are received, that would be a *big*
improvement to what we have now.

> the prefix should no longer be auto-configured and should no longer be

Not sure I follow. Could you please elaborate?

> I believe this is intended to be a reference to section 3.2.2.

Nope. Section 3.2.2 talks about the interaction between dhcpv6-pd and
slaac. BUt it is section 2.5 that discusses other considerations for
dynamic/stable prefixes. For example, stable prefixes are not nice for
privacy.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 25 Oct 2019 14:49:17 -0300

> The current draft is not a problem statement. From Section 3 it describes

It does contain a problem statement. And I think it would be nice if the
problem statement could highlight, at a high-level, the possible ways to
address the problem. The current document does elaborate quite a bit on
some of them. Such parts could be removed and put into a separate
document, though.

> just because their ISP does flash renumbering.

Exactly. THe original draft had *everything* in the document, including
protocol updates. THis one has limited to the problem statement plus
operational mitigations. Maybe the text that gets too specific (.e.g the
CPE behavior could be removed and made into a stand alone document).

THoughts?

---

From: Fernando Gont <[email-masked]>
Date: Fri, 25 Oct 2019 14:52:26 -0300

> Flash renumbering is not defined so no-one should be surprised that you get undefined behavior. 

The "flash renumbering" could also happen if the CPE was trying to kind
of the right thing, the ISP does not employ stable prefixes, and the CPE
happens to crash and reboot. Some CPEs also reportedly do a "release"
when rebooted.

At the end of the day, what you get is a brittle network. And what we're
trying to do is exactly improving the robustness of the network.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 25 Oct 2019 13:59:11 -0400

> happens to crash and reboot. Some CPEs also reportedly do a "release"

That’s probably a bug.   If the CPE has a valid lease, and the prefix is still working, it should continue to advertise it until its valid lifetime expires.   The ISP DHCP server should be giving the router two prefixes if it’s being renumbered: the preferred one, and the one that’s still valid but not preferred anymore.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 25 Oct 2019 14:55:57 -0300

On 25/10/19 09:53, Ole Troan wrote:
[....]
> I'm not the one proposing an IPv6 redesign. This is a response to the proposals of violating a fundamental expectation of stable addressing in IPv6.

Could you please point to an RFC that documents such expectation?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 25 Oct 2019 14:59:13 -0300

> to see a report on that. I'm very curious how to would work.

THe best they could do is to try to *circumvent* the problem while
keeping all the mess in the network layer. That'd certainly be a bad option.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 25 Oct 2019 15:04:23 -0300

> It can't be fixed in the IPv6 stack.

When what you call "flash-renumbering" happens, hosts continue employing
addresses and network configuration that is stale incorrect. That's the
problem. As soon as you are able to detect that and unprefer/remove such
addresses/configuration, you've solved the problem.

That's what we're trying to do here.

> My argument is that if you do that, as in add support for ephemeral addressing / flash renumbering at the network layer, without doing anything at upper layers, then for an end-user, IPv6 will prov…

The two are orthogonal. Upper-layers can/should do better. That doesn't
mean that we shouldn't improve robustness at the network layer.

---

From: Ole Troan <[email-masked]>
Date: Fri, 25 Oct 2019 20:10:23 +0200

> On 25 Oct 2019, at 20:05, Fernando Gont <[email-masked]> wrote:
> 
> When what you call "flash-renumbering" happens, 

Yes, because what you call “renumbering “ is not specified anywhere. 

O

---

From: Fernando Gont <[email-masked]>
Date: Fri, 25 Oct 2019 15:10:55 -0300

On 25/10/19 14:59, Ted Lemon wrote:
> On Oct 25, 2019, at 1:52 PM, Fernando Gont <[email-masked]
> That’s probably a bug.   If the CPE has a valid lease, and the prefix is
> still working, it should continue to advertise it until its valid
> lifetime expires. 

Normally CPEs keep no state in stable storage about that.

> The ISP DHCP server should be giving the router two
> prefixes if it’s being renumbered: the preferred one, and the one that’s
> still valid but not preferred anymore.

The reality is that, we have all sort of things in the echosystem. So if
the network is to be robust, while we can and do improvements were
possible/needed. That said, there should be smarts on the hosts to cope
with these scenarios gracefully (hope for the best, plan for the worst).

Thanks,

---

From: Ted Lemon <[email-masked]>
Date: Fri, 25 Oct 2019 14:14:49 -0400

> with these scenarios gracefully (hope for the best, plan for the worst).

I agree.   But if an ISP’s DHCP server is not doing this, I would say that it’s a bug, and we should make sure that we are at least giving them correct advice about what DHCP’s behavior should be.   Similarly with the CPE: if it asks for e.g. a /64, and gets two, one with a preferred lifetime of zero, does it advertise both?

---

From: Fernando Gont <[email-masked]>
Date: Fri, 25 Oct 2019 15:16:39 -0300

> Yes, because what you call “renumbering “ is not specified anywhere. 

THat's why we explain and describe it in our I-D.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 25 Oct 2019 15:22:31 -0300

On 25/10/19 15:14, Ted Lemon wrote:
> On Oct 25, 2019, at 2:10 PM, Fernando Gont <[email-masked]
> I agree.   But if an ISP’s DHCP server is not doing this, I would say
> that it’s a bug, and we should make sure that we are at least giving
> them correct advice about what DHCP’s behavior should be. 

I fully agree. Indeed, we did include a bit of that in our I-D.

>  Similarly
> with the CPE: if it asks for e.g. a /64, and gets two, one with a
> preferred lifetime of zero, does it advertise both?

This is largely unspecified. So, yes, it should be better specified.

Thanks,

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Oct 2019 08:47:39 +1300

> is that a fundamental design principle of ipv6?  This is news.

Not that I'm aware of, but (as the 6renum WG showed) that doesn't
mean that planned renumbering is easy; and unplanned renumbering
is still a bug.

Mitigations needed.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Fri, 25 Oct 2019 15:26:14 -0300

> -éric (enjoying my 3-year old /48 or is it 5 years?)

The EFF might have some concerns about that ;-)

---

From: Mark Smith <[email-masked]>
Date: Sat, 26 Oct 2019 11:41:07 +1100

> Note: that makes your sample size 2, not 240,000....

I think the volume of users is an indication of the likelihood of
encountering it, in the context of rapid broadband adoption at the time.

When I started at the smaller ISP in 2005, we had 6000 customers. When I
left in November of 2009, we had 80 000 customers.

During that time the network was also entirely rebuilt, including going
from 2 LNSes and a single BRAS to 2 new LNSes and 6 BRASes, on a new
network core with an entirely new routing architecture (i.e. BGP for
everything, OSPF carrying loopbacks and link addressing) . The rebuild
included unavoidable redistribution of routes back and forth between and
new network instances of BGP and OSPF (and the risk of BGP -> OSPF -> BGP).

So given the growth, and the complexity of what we had to do to deploy a
new network during that growth, while continuing to providing legacy
network connectivity, I think if flash renumbering was a common thing that
needed to be done, I think I should have encountered it often given my
experience.

> Renumbering is not "common" but it certainly happens.
>

I didn't say it didn't happen.

People imply it is a regular and routine event that then justifies a lot if
effort to work around its consequences to IPv6.

I don't agree, because I don't think it is a common and routine event, and
with the right address provisioning system and routing architecture,
customers don't get flash renumbered even when, e.g. a BRAS is rebooted.

With that said, "flash renumber" could reasonably be considered a "high
> support risk" operation.. IPv6 is supposed to accommodate renumbering
> *more* gracefully, not less, than legacy IP, but it is still supposed to be
> a planned event.
>

If you use IPv6's graceful renumbering mechanisms i.e. multi-addressing and
preferred and valid lifetimes, then it won't be flash renumbering.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 Oct 2019 14:30:12 +1300

>>     Renumbering is not "common" but it certainly happens.
...> People imply it is a regular and routine event...

Sadly, it is. For example, at my previous apartment there was a badly waterproofed joint somewhere between me and the nearest street cabinet, so for months I frequently lost ADSL synch... and when it came back, I got new IPv6 prefix. After a heavy rainstorm, this would happen many times a day.

Yes, OK, there was a copper cable fault and it took <unmentionable company> many months to fix it. OK, maybe the ISP shouldn't regenerate a prefix every time. But that's real life and I suspect I am one of millions.

Regards
   Brian

---

From: Mark Smith <[email-masked]>
Date: Sat, 26 Oct 2019 12:59:32 +1100

On Sat, 26 Oct 2019, 12:30 Brian E Carpenter, <[email-masked]>
wrote:

> Sadly, it is. For example, at my previous apartment there was a badly
> waterproofed joint somewhere between me and the nearest street cabinet, so
> for months I frequently lost ADSL synch... and when it came back, I got new
> IPv6 prefix. After a heavy rainstorm, this would happen many times a day.
>
> Yes, OK, there was a copper cable fault and it took <unmentionable
> company> many months to fix it. OK, maybe the ISP shouldn't regenerate a
> prefix every time. But that's real life and I suspect I am one of millions.
>

This smells of the local BRAS pool dial up model.  In the same situation,
that wouldn't happen to me because I have a stable /56 associated with my
user account.

If you're using PPPoE, you can specify the access concentrator you want to
(re)attach to.

One common AC/BRAS/NAS implementation caches IPv4 pool assignments to user
accounts, so that if the same account re-attaches, the same IPv4 pool
address is given back to it. I wouldn't be surprised if that also occurs
with IPv6 pool delegated prefix assignments.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 26 Oct 2019 00:16:00 -0300

On 25/10/19 22:30, Brian E Carpenter wrote:
> ....> People imply it is a regular and routine event...
> 

Indeed you are. In fact, I presented this topic at a recent LACNOG
meeting, and we had at least three guys, from different countries,
coming to the mike, noting they have experienced this, noting that they
wished we did something about it. The document itself is a product of a
conversation with an ISP (from a completely different geographical zone).

Particularly when it's the user that experiences the problem, I think we
are not of much help when instead of improving robustness, we complain
about how the world should be a different places.

Thanks,

---

From: Owen DeLong <[email-masked]>
Date: Sat, 26 Oct 2019 21:48:10 -0700

> Could you please elaborate on this one?

I’m not sure what I could do to elaborate. The addition of a specific call-out that
even if the current behavior of ≤2 hours = 2 hours is to be preserved, there should
be a special case for “0 seconds” which causes the prefix to be immediately
deprecated with extreme prejudice.

Hosts should be required to treat an RA containing a prefix with a 0 second
valid lifetime as an invalid prefix and immediately deprecate it from the interface
if it is in use.

> improvement to what we have now.

I don’t like this idea because I can think of some scenarios where you
may receive multiple RAs from router A not containing the prefix in the
same time frame that router B has not sent an additional RA containing
the prefix, but it will do so in its next RA.

There is no requirement for all routers on the same link to provide the
same set of PIOs, nor are they required to use the same advertisement
timers.

I agree that it’s a bit of a corner case and it’s certainly not an ideal way
to configure a network, but it is not entirely unlikely to happen in the
real world, it is within the current RFCs, it is valid functionality and it
is not broken by the expected behaviors today.

> Not sure I follow. Could you please elaborate?

Sure… In section 3.2.1 of your document, you advocate that if the previously
valid PIOs were set A=1 and/or L=1, then those values of the A and L bits
should be preserved in the RAs sent to deprecate them.

My argument is that since you are attempting to make this a prefix that hosts
will no longer autoconfigure (A) and will no longer consider on-link (L), that
in reality, regardless of the previous state of the A and L bits in the RAs
announcing the prefix in a valid PIO, the new RAs since the prefix has been
deprecated should be sent with A=0, L=0 in order to signal the host
that this prefix should not be auto configured and should no longer be
considered on-link.

> dynamic/stable prefixes. For example, stable prefixes are not nice for

Fair enough, but in that case, I don’t think I would put it after the description of section 3.2,
nor would I use the word “Finally” as a lead-in to a back-reference.

Owen

---

From: Mark Smith <[email-masked]>
Date: Sun, 27 Oct 2019 18:57:55 +1100

So in summary, the proposal is to update RFCs, change 100s of millions
of CPE implementations, and billions of IPv6 host implementations, to
accommodate some ISPs who want to cling to an obsolete dynamic and
dial up origin address provisioning model for always on Internet
connections?

Robustness is useful, however there needs to be a determined threshold
where, beyond that, the cost of adding robustness exceeds the cost of
properly fixing the problem that created the need for additional
robustness in the first place.

Making all CPE and all IPv6 hosts more robust to work around a problem
caused by some ISPs' address provisioning systems and models is going
to be far more expensive and incur costs on everybody (IETF, CPE
vendors and host vendors, and their customers who indirectly pay CPE
and host implementation costs), compared to those ISPs accepting that
IPv6 customers require persistent prefixes and paying the costs of
making changes to their own address provisioning systems.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 27 Oct 2019 08:02:40 -0400

Indeed, this would also not actually solve the problem.   At present, the ISPs are doing something that is out of spec and causes problems.   If we “fix” this by accommodating what they do, does that help, or does it just encourage them to continue doing it?

What should be happening on the host with a prefix that’s deprecated is that TCP connections should be timing out.   This doesn’t take very long.   And if there is a new prefix being advertised on the link, that address should have a valid lifetime newer than the old prefix, meaning that the next TCP connection should come from that new prefix, not the old one.

I think Fernando’s plan to shorten some timers makes sense, but shortening the minimum really doesn’t—it just opens up an opportunity for an easy DoS, since I can now just send out death packets to the local network and break everything all at once.

If you Really Really want to be able to have the routers send out RAs that deprecate the default route, and, as Mark is saying here, to upgrade millions or perhaps billions of hosts, why not ask for something that’s a real improvement?

First of all, fix CPEs so that they definitely support clean deprecation of prefixes using PD.  Second, fix RA so that it’s non-repudiable by a device that doesn’t have the secret key.

SEND does this, sort of.  Nobody uses SEND because it tries to solve a too-big problem and does it using obsolete technology.   But the basic idea is good: include a public key in every RA that can be used to validate that the RA was signed with the corresponding private key. 

When another RA arrives, see if it was signed with the same key.   If so, it came from the same router, and can be trusted to update whatever information that router sent, including flash-deprecating a prefix.   If not, ignore it.

This avoids the problem of validating which RAs are good RAs: you just do what you’re doing now with RAs.  But if an RA goes out that supersedes a previous RA, you don’t let it supersede it unless it’s provably from the same source.  I’m currently doing something similar with DNSSD Service Registration Protocol, using ECDSA, and the implementation has a small enough footprint to run on IoT devices.  Something like this would make SEND/CGA a bit more useful, I think.

Note that this would not be required for hosts, and hence would not create unwanted privacy properties for host addresses.   Also, when used e.g. in a hotspot setting where it might be desirable to vary addresses, that’s okay, because a new key can be generated regularly as long as the prefix on the local link doesn’t need to be deprecated.

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 27 Oct 2019 12:33:53 +0000

Ted Lemon wrote on 27/10/2019 12:02:
> If you Really Really want to be able to have the routers send out RAs
> that deprecate the default route, and, as Mark is saying here, to
> upgrade millions or perhaps billions of hosts, why not ask for
> something that’s a real improvement?
> 
> First of all, fix CPEs so that they definitely support clean
> deprecation of prefixes using PD.  Second, fix RA so that it’s
> non-repudiable by a device that doesn’t have the secret key.
you mean, turn it into stateful address autoconfiguration? :-)

This isn't a criticism of what you're suggesting btw. It's an 
observation that the design philosophy behind SLAAC has intrinsic 
problems that cannot be resolved without dealing with state and state 
transfer, and that maybe we need to take a critical look at SLAAC and 
make potentially difficult decisions about whether or not it's fit for 
purpose for common deployment situations.

Nick

---

From: Philip Homburg <[email-masked]>
Date: Sun, 27 Oct 2019 14:41:54 +0100

> problems that cannot be resolved without dealing with state and
> state transfer, and that maybe we need to take a critical look at
> SLAAC and make potentially difficult decisions about whether or
> not it's fit for purpose for common deployment situations.

In this particular case (a CPE rebooting and getting a different prefix from
the ISP), SLAAC has for the most part what we need.

The little bit missing is that the CPE should write prefixes advertised using
SLAAC to persistent storage which allows the CPE to invalidate stale prefixes
after a reboot.

Note that we could change SLAAC to allow the lifetime of a prefix to be
set to zero, instead of having to wait for 2 hours. That might be an
improvement but requires careful analsysis.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 27 Oct 2019 09:54:36 -0400

> SLAAC to persistent storage which allows the CPE to invalidate stale prefixes

Actually I do not believe this is correct behavior.   Let us assume prefix delegation.   If we have prefix delegation, then when the CPE comes back from a power cycle, it should reconfirm the prefix it had previously; the assumption is that that prefix is still valid.  This can be handled in infrastructure—the ISP edge router should know whether the prefix is still valid, because if it is it should be advertising a route for it.   If it is not still valid, then the CPE router should attempt to renew it, which would go to the DHCP server (possibly both messages would).  If the lease on the address is still valid, the ISP should renew the lease and not issue a new one.   It is a misconfiguration for some other thing to happen in this case.   This would then re-establish the route in the ISP edge router.

If the ISP wants to deprecate the old prefix, the thing to do is not to fail to renew it, but rather to renew it with a preferred lifetime of zero and offer another prefix with a preferred lifetime that is not zero.   The CPE router should in this case advertise both prefixes, with the applicable lifetimes.  Using my limited SEND proposal, the advertisement with a preferred lifetime of zero would be immediately seen by all hosts that implement limited SEND, and they would start using the new preferred prefix.  Hosts that don’t implement limited SEND would still behave correctly, but might take longer to stop using the old prefix.  This should be okay because the old valid lifetime is still valid.

That’s the way things should go when everything is working correctly.   If however the ISP’s DHCP server loses its cookies and can’t renew the old prefix, then we’d see the new behavior where hosts that implement limited SEND could immediately see that the old prefix was no longer usable, and would stop using it in preference to the new prefix.   Hosts that don’t implement limited SEND would behave as they behave today.

And in the DoS attack case, because the attacker doesn’t have the limited SEND key that was used to advertise the prefix that it is attacking, only hosts that don’t implement limited SEND would even see the attack.  These hosts would reject any RA proposing a lifetime shorter than two hours.   So the DoS attack would be useless both for hosts that implement limited SEND and hosts that don’t.

---

From: Philip Homburg <[email-masked]>
Date: Sun, 27 Oct 2019 15:07:26 +0100

>    Actually I do not believe this is correct behavior.   Let us
>    assume prefix delegation.   If we have prefix delegation, then
>    when the CPE comes back from a power cycle, it should reconfirm
>    the prefix it had previously; the assumption is that that prefix
>    is still valid.  

This is not required behavior for a DHCP client. Traditionally, a client
does not have to write a lease it received in persistent storage. In 
fact, in the case of DHCPv6-PD in some cases that actually triggers bugs
on the ISP side and delays obtaining a new lease.

Now I'm not opposed to trying to renew the previous lease. It makes the
whole thing more complex and probably more fragile, but it is the right
thing to do.

However, the thing that actuualy makes it work (and no need for SEND there)
is to have the CPE to advertise a stale prefix with lifetimes zero to
inform hosts that this prefix no long works.

---

From: Ole Troan <[email-masked]>
Date: Sun, 27 Oct 2019 16:03:38 +0100

> On 27 Oct 2019, at 14:42, Philip Homburg <[email-masked]> wrote:
> 
> 
>> 

Can you explain how operating a public service should work on this type of network?

Cheers 
Ole

---

From: Philip Homburg <[email-masked]>
Date: Sun, 27 Oct 2019 16:05:35 +0100

> Indeed, this would also
> not actually solve the problem.   At present, the ISPs are doing
> something that is out of spec and causes problems.   If we fix this
> by accommodating what they do, does that help, or does it just
> encourage them to continue doing it?

At the moment, ISPs are doing something that sort of works in IPv4 because
of NAT. It causes significant issues in IPv6.

Of course, can we can tell ISPs that they are doing it wrong and that they
should not deploy IPv6 until they have fixed their networks.

I would like to have IPv6 now. And if that requires some tweaks to deal with
broken behavior then so be it.

> If you Really Really want to be able to have the routers send out
> RAs that deprecate the default route, and, as Mark is saying here,
> to upgrade millions or perhaps billions of hosts, why not ask for
> something thats a real improvement?

Because bundling features is a good way to ensure that nothing gets done.

Dealing with flash renumbering in the CPE is a relatively small tweak that
can be implemented at any time.

> Second, fix RA so that its
> non-repudiable by a device that doesnt have the secret key.

If you think that this is an important thing to fix, feel free to 
talk about it. But why in this discussion? SEND doesn't do anything for
flash renumbering. From an operational point of view, RA-guard is much
more attractive then SEND. So it is not clear to me that there is any
need for SEND. But I could be wrong. In any case, if there is a need
to discuss SEND we could do that separately.

This discussion is on how to deal with flash renumbering.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 27 Oct 2019 13:29:32 -0300

> dial up origin address provisioning model for always on Internet

Once more: the CPE router case is just *one of many* scenarios that may
lead to the problem described in the document.

The discussion about CPEs has to do with the CPEs doing what is right --
regardless of whether the ISP renumbers or not.

Robustness has a lot to do with being able to gracefully handle the case
when others screw up.

> robustness in the first place.

Could you please point at any specific part of the document that you
object to?

> Making all CPE and all IPv6 hosts more robust to work around a problem

What we describe is what CPEs should be doing to respect the protocol
semantics.

Thanks,

---

From: Ted Lemon <[email-masked]>
Date: Sun, 27 Oct 2019 13:14:59 -0400

> to discuss SEND we could do that separately.

I think you missed my point.  You can’t do flash renumbering by advertising a prefix with a valid lifetime of zero, because that will be ignored by hosts.   If it were not ignored by hosts, it would be a very effective DoS vector.    And so if you want to be able to flash deprecate a route, you need some way to validate that the deprecation is coming from the same source as the route.   Hence my suggested “limited SEND”.

Limited SEND would not be hard to implement.   Yes, it would be marginally harder than just saying that hosts should accept flash deprecation of prefixes.   But nobody with any sense is going to implement that in their IP stack, so in practice if you want this to work, you need some way to do flash deprecations that doesn’t create a massive attack vector.

---

From: Philip Homburg <[email-masked]>
Date: Sun, 27 Oct 2019 20:04:45 +0100

> Can you explain how operating a public service should work on this

Could you be more specific what you consider a 'public service' and what
you expect to break?

What I described is basically what happens on IPv4 when a CPE uses NAT 
and gets a new IPv4 address from the ISP.

Flash renumbering is far from ideal, but a reality on the current internet.
Any application that is suitable for home use is expected to deal with that
scenario.

Note that with automatic DNS updates, you can probably run a mail server (or
your personal 'cloud') on such a link. But that is not a common use case
at the moment.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 28 Oct 2019 08:06:12 +1300

On 28-Oct-19 05:29, Fernando Gont wrote:
...
> Robustness has a lot to do with being able to gracefully handle the case

This. We can't make the world perfect, but we can make individual components
that expect imperfection.

    Brian

---

From: Owen DeLong <[email-masked]>
Date: Sun, 27 Oct 2019 12:31:14 -0700

> On Oct 27, 2019, at 07:07 , Philip Homburg <[email-masked]> wrote:
> 

How does the CPE identify a stale prefix if it hasn’t written its previous prefixes
to persistent storage?

Owen

---

From: Owen DeLong <[email-masked]>
Date: Sun, 27 Oct 2019 12:35:54 -0700

> On Oct 27, 2019, at 10:14 , Ted Lemon <[email-masked]> wrote:
> 
> On Oct 27, 2019, at 11:05 AM, Philip Homburg <[email-masked] <mailto:[email-masked]>> wrote:

It’s only a DOS vector if the attacker is already on-LAN.

I recognize that there are environments where that is expected behavior (e.g. Coffee Shop Wifi, University networks, etc.),but
it’s not the case for the average residential CPE and residential LAN segments.

In the vast majority of situations where I would expect hostile hosts to be likely to be on LAN, I don’t think I’d be using
SLAAC for address assignment in the first place. Most likely, I’d want stateful DHCP in such instances.

Owen

---

From: Ted Lemon <[email-masked]>
Date: Sun, 27 Oct 2019 15:44:43 -0400

On Oct 27, 2019, at 3:30 PM, Owen DeLong <[email-masked]> wrote:
> So this still requires that the CPE has written the lease to persistent storage. Currently many CPE do not do this.

Strictly speaking, if the CPE asks for a PD, and the server had already given it a prefix, it should get the same prefix, even if renumbering is happening; in the case of renumbering, it should get two prefixes, and should use one as the preferred prefix and the other as a deprecated prefix.   There is actually no need to write the prefix to stable storage if the DHCP server is behaving correctly.

However, in the case of incorrect behavior, end users will see more stable behavior in the case that the CPE remembers the old prefix.

> I don’t know of a single DHCPv6 server which operates that way currently. Can you point to a working example?

Honestly, I have no idea.  But that is what the RFC says you should do.   If existing DHCP servers aren’t doing this, they are not fully implementing the specification.  I think in general, current DHCP servers just don’t allow you to cleanly deprecate a prefix, because nobody asked for this capability.   DHCP servers I know of will not renumber at all.   You can trick them into forcing a flash renumber by hacking the lease database, but that’s not correct behavior.

> While there may be advantages to limited SEND, I don’t see that as a reason not to implement this particular fix across the board since it would benefit both hosts implementing limited SEND as well as hosts not implementing it.

To which fix are you referring?

---

From: Ted Lemon <[email-masked]>
Date: Sun, 27 Oct 2019 15:46:13 -0400

> SLAAC for address assignment in the first place. Most likely, I’d want stateful DHCP in such instances.

Hostile hosts happen when you get hit with malware, e.g. ransomware.   Being resilient in situations like this is important, even if they aren’t all that common, because the cost of non-resilience is so high.

---

From: Philip Homburg <[email-masked]>
Date: Sun, 27 Oct 2019 21:02:24 +0100

>    I think you missed my point.  You can't do flash renumbering by
>    advertising a prefix with a valid lifetime of zero, because that
>    will be ignored by hosts.   If it were not ignored by hosts, it
>    would be a very effective DoS vector.    And so if you want to
>    be able to flash deprecate a route, you need some way to validate
>    that the deprecation is coming from the same source as the route.
>    Hence my suggested "limited SEND".

Today, you can deprecate a prefix by sending an RA with the preferred lifetime
set to zero. That is enough to get IPv6 at the same level as IPv4.

Without RA-guard or SEND there are already quite a lot of opportunities to
perform both a denial of service attack and a man in the middle attack
on a local LAN.

I'm not sure if the protection against advertising a zero valid lifetime
is actually worth it. Any network that worries about local malicious 
hosts probably already uses RA-guard (or possibly SEND). 

In any case, it doesn't matter to the CPE whether the host will accept
zero valid time or not. The CPE can just send them and then a separate
document can either instruct hosts to accept all RAs with zero valid time
or require some for of SEND.

The key thing is that without any protocol modifications we can get IPv6
at the same level as IPv4. 

If we make more extensive modifications to the host, then there is no 
reason to rely on RA timers and the host could handle unmodified CPEs.

---

From: Philip Homburg <[email-masked]>
Date: Sun, 27 Oct 2019 21:11:19 +0100

> How does the CPE identify a stale prefix if it hasnt written its
> previous prefixes to persistent storage?

Writing prefixes to persistent storage is a key element in letting the
CPE deal with this issue.

---

From: Owen DeLong <[email-masked]>
Date: Sun, 27 Oct 2019 12:30:04 -0700

> On Oct 27, 2019, at 06:54 , Ted Lemon <[email-masked]> wrote:
> 
> On Oct 27, 2019, at 9:41 AM, Philip Homburg <[email-masked] <mailto:[email-masked]>> wrote:

I agree that the CPE should attempt to reconfirm/renew the existing prefix lease. However, if that fails for some reason (and there are multiple scenarios which present valid reasons this could fail without misconfiguration on either side), I think that the behavior described is preferable to simply removing the old prefix from RAs and waiting for them to time out on the unsuspecting hosts. Especially in the case of 1 week preferred and 1 month valid lifetime timers.

> If the ISP wants to deprecate the old prefix, the thing to do is not to fail to renew it, but rather to renew it with a preferred lifetime of zero and offer another prefix with a preferred lifetime…

Can you point to any authoritative document which supports this particular mechanism?

Owen

---

From: Philip Homburg <[email-masked]>
Date: Sun, 27 Oct 2019 21:21:24 +0100

>    Hostile hosts happen when you get hit with malware, e.g.
>    ransomware.  Being resilient in situations like this is important,
>    even if they aren't all that common, because the cost of
>    non-resilience is so high.

As far as I know, nobody (in a home situation) is worried about malware
performing ARP spoofing.

If there is a variant of SEND that is both easy to deploy and can effectively
prevent denial of service by a malicious local host, then it is certainly
worth discussing. But I still think it should a separate discussion and
not as part of dealing with flash renumbering.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 27 Oct 2019 22:03:53 +0000

>I don’t know of a single DHCPv6 server which operates that way currently. Can you point to a working example?

That is actually the RFC8415 specified behavior … the DHCP server I work on (Cisco Prime Network Registrar) will do this if steps are taken to “invalidate” a lease.

See RFC 8415, Section 18.3.4:

   If the server finds that any of the addresses in the IA are not
   appropriate for the link to which the client is attached, the server
   returns the address to the client with lifetimes of 0.

   If the server finds that any of the delegated prefixes in the IA are
   not appropriate for the link to which the client is attached, the
   server returns the delegated prefix to the client with lifetimes
   of 0.

  *   Bernie

From: v6ops <[email-masked]> on behalf of Owen DeLong <[email-masked]>
Date: Sunday, October 27, 2019 at 4:18 PM
To: Ted Lemon <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

On Oct 27, 2019, at 06:54 , Ted Lemon <[email-masked]<mailto:[email-masked]>> wrote:

On Oct 27, 2019, at 9:41 AM, Philip Homburg <[email-masked]<mailto:[email-masked]>> wrote:
The little bit missing is that the CPE should write prefixes advertised using
SLAAC to persistent storage which allows the CPE to invalidate stale prefixes
after a reboot.

Owen

---

From: Mark Smith <[email-masked]>
Date: Mon, 28 Oct 2019 09:37:01 +1100

> that expect imperfection.

This is not what I said, as it is implying that I said there is no need for
robustness.

Robustness suffers from the law of diminishing returns. At some point the
cost to design and implement robustness exceeds the either the likelihood
it will be needed or the benefit it returns if needs to be used.

Sugar is sometimes poured into the fuel tanks of cars, which will destroy
the engine. It is not common and is done maliciously. If robustness should
be universal, does that mean car engines should be made impervious to
sugar, at great expense to everybody, despite the need for that robustness
being rare?

Some ISPs are shifting the cost and consequences of their design decision,
which they can change, onto the IETF, CPE vendors and host implementers,
and indirectly their customers'. Are they willing to pay these other
parties to fix a problem that they are both causing and could fix
themselves?

(Can I bill these ISPs for the time I spent implementing the
'DeprecatePrefix' and 'DecrementLifetimes' options in 'radvd' in 2011 that
address this problem? Those options have limitations that I still don't
think are acceptable, which is why ISPs fixing their backend systems is
still the best solution.)

---

From: Ole Troan <[email-masked]>
Date: Sun, 27 Oct 2019 23:52:15 +0100

> Could you be more specific what you consider a 'public service' and what

The (only) value (sic) of IPv6 to end-users is retoration of end to end connectivity at the network layer.

I challenge you to find in the "real world" of end-users many with much trust in the ad-based "you are the product" centralised services in the current Internet.
IPv6 was meant to allow end-users to run decentralized services.

- hidden primary DNS
- mail
- web
- home-automation
- video conferencing
- jabber

All of those have great open source software.
To use Owen's paragraph:
"I don’t know of a single server which operates that way currently. Can you point to a working example?"

Assuming all the moving parts required were updated to support flash renumbering (I have little proof they even support graceful renumbering), 
if the end-user cannot trust the lifetimes in the delegated prefix, DNS with TTL=1s is presumably the only choice?

> and gets a new IPv4 address from the ISP.

If making IPv6 no better than IPv4 + NAT, then stick with IPv4 + NAT.
IPv4 NAT scales very well as it turns out.

> Any application that is suitable for home use is expected to deal with that

We don't need IPv6 to maintain the status quo.

> your personal 'cloud') on such a link. But that is not a common use case

And don't get me wrong, I'm all for making IPv6 addressing / onlink behaviour more robust.
But not justified in this way that can be seen to allow for practices that removes any benefit of IPv6 over IPv4/NAT.

Ole

---

From: Philip Homburg <[email-masked]>
Date: Mon, 28 Oct 2019 09:52:02 +0100

> The (only) value (sic) of IPv6 to end-users is retoration of end
> to end connectivity at the network layer.

End users at not really part of the equation at the moment. Many people have
tried to convince their ISPs to provide IPv6 and failed.

For home use, IPv6 is what you get when the ISP has decided that providing 
IP services over IPv6 instead of or next to IPv4 is worth it.

This is not my ideal world. But realistically, we live in a world that still
has to transition away from IPv4. 

> I challenge you to find in the "real world" of end-users many with
> much trust in the ad-based "you are the product" centralised services
> in the current Internet.  IPv6 was meant to allow end-users to run
> decentralized services.

This is a separate issue. The problem started when people paid for
connectivity but assumed they paid for internet services. There are plenty
of providers for mail, messaging, etc. where you are not the product. But
very few customers are willing to pay extra for such services.

At the same time, where an ISP does provide stable addresses,
most people find it hard to run services at home.

> - hidden primary DNS - mail - web - home-automation - video
> conferencing - jabber

Many people have a more or less fixed IPv4 address. Setting up a few port
forwards in a CPE is not that hard (and with IPv6, you have to do the same
for the firewall in the CPE).

Yet very few people run these services at home.

Basically, the market value for those service at a residential home is zero.

> Assuming all the moving parts required were updated to support
> flash renumbering (I have little proof they even support graceful
> renumbering), if the end-user cannot trust the lifetimes in the
> delegated prefix, DNS with TTL=1s is presumably the only choice?

ISPs that do flash renumbering, typically do that after a link down event.
Assuming those events are rare (and ISPs have an incentive to make them
rare because it interferes with watching video), then a TTL of a few
minutes should work.

> If making IPv6 no better than IPv4 + NAT, then stick with IPv4 +
> NAT.  IPv4 NAT scales very well as it turns out.
 
IPv4 NAT doesn't scale very well when law enforcement wakes up and find out
that a single IP address means lots of different people at the same time.

IPv4 NAT also doesn't scale very well when it comes to bandwidth.

For large ISPs, IPv4 NAT is also annoying from a network management point of
view because it is not possible to uniquely number all devices in the 
network.

Plenty of reasons for an ISP to move to IPv6 even if they don't care about
providing end-to-end connectivity.

> We don't need IPv6 to maintain the status quo.

We are out of IPv4 addresses. There is a lot of demand for IPv4 addresses
and the lack of them is a barrier against entry.

> And don't get me wrong, I'm all for making IPv6 addressing / onlink
> behaviour more robust.  But not justified in this way that can be
> seen to allow for practices that removes any benefit of IPv6 over
> IPv4/NAT.

The current internet has moved to lots of short lived flows. If we can
tune systems that new address information propagates quickly, both on the
local network and in DNS, then unstable prefixes could very well something
we can live with.

In fact, we can also use the letsencrypt argument: by having short lived
certificates letencrypt strongly encourages automating the whole process.
Lots of tooling popped up to support that model.

Right now we are stuck in a model where too many files are hand edited with
address and prefix information. At the same time, everybody expects
phones and laptops to seemlessly move between networks, picking up new
addresses and removing stale ones as they move around.

---

From: Kristian McColm <[email-masked]>
Date: Mon, 28 Oct 2019 09:18:03 +0000

> For large ISPs, IPv4 NAT is also annoying from a network management point of view because it is not possible to uniquely number all devices in the network.

For cellular networks, NAT is also very expensive when we talk about CGN (both NAT44 and NAT64) and by simply deploying dual-stacked connectivity to your users you can immediately reduce CG-NAT requirement by around 60%, due to most cellular data traffic being to native IPv6 enabled sites like YouTube, Facebook, Instagram etc.

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Philip Homburg
Sent: October 28, 2019 04:52
To: [email-masked]
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

> end connectivity at the network layer.

End users at not really part of the equation at the moment. Many people have tried to convince their ISPs to provide IPv6 and failed.

For home use, IPv6 is what you get when the ISP has decided that providing IP services over IPv6 instead of or next to IPv4 is worth it.

This is not my ideal world. But realistically, we live in a world that still has to transition away from IPv4. 

> in the current Internet.  IPv6 was meant to allow end-users to run 

This is a separate issue. The problem started when people paid for connectivity but assumed they paid for internet services. There are plenty of providers for mail, messaging, etc. where you are not the product. But very few customers are willing to pay extra for such services.

At the same time, where an ISP does provide stable addresses, most people find it hard to run services at home.

> - hidden primary DNS - mail - web - home-automation - video 

Many people have a more or less fixed IPv4 address. Setting up a few port forwards in a CPE is not that hard (and with IPv6, you have to do the same for the firewall in the CPE).

> Assuming all the moving parts required were updated to support flash 
> renumbering (I have little proof they even support graceful 

ISPs that do flash renumbering, typically do that after a link down event.
Assuming those events are rare (and ISPs have an incentive to make them rare because it interferes with watching video), then a TTL of a few minutes should work.

> IPv4 NAT scales very well as it turns out.
 
IPv4 NAT doesn't scale very well when law enforcement wakes up and find out that a single IP address means lots of different people at the same time.

For large ISPs, IPv4 NAT is also annoying from a network management point of view because it is not possible to uniquely number all devices in the network.

Plenty of reasons for an ISP to move to IPv6 even if they don't care about providing end-to-end connectivity.

> We don't need IPv6 to maintain the status quo.

We are out of IPv4 addresses. There is a lot of demand for IPv4 addresses and the lack of them is a barrier against entry.

> behaviour more robust.  But not justified in this way that can be seen 
> to allow for practices that removes any benefit of IPv6 over IPv4/NAT.

The current internet has moved to lots of short lived flows. If we can tune systems that new address information propagates quickly, both on the local network and in DNS, then unstable prefixes could very well something we can live with.

In fact, we can also use the letsencrypt argument: by having short lived certificates letencrypt strongly encourages automating the whole process.
Lots of tooling popped up to support that model.

Right now we are stuck in a model where too many files are hand edited with address and prefix information. At the same time, everybody expects phones and laptops to seemlessly move between networks, picking up new addresses and removing stale ones as they move around.

---

From: Ole Troan <[email-masked]>
Date: Mon, 28 Oct 2019 10:21:57 +0100

Philip,

I didn't see your answer to:
"I don’t know of a single server which operates that way currently. Can you point to a working example?"

I take it the answer is: "currently none"?

Ole

> On 28 Oct 2019, at 09:52, Philip Homburg <[email-masked]> wrote:
>

---

From: Philip Homburg <[email-masked]>
Date: Mon, 28 Oct 2019 10:50:38 +0100

> I didn't see your answer to:  "I dont know of a single server which
> operates that way currently. Can you point to a working example?"
> 

Is the question whether people are running services on home networks where
the ISP uses flash renumbering?

If so, the answer is yes. There are a number of 'dynamic DNS' providers.
People use those to keep DNS up-to-date when their public IPv4 address changes.

All of this is small scale hobbyist usage (and most likely only IPv4) but
it does exist.

---

From: Ole Troan <[email-masked]>
Date: Mon, 28 Oct 2019 10:58:29 +0100

Philip,

> All of this is small scale hobbyist usage (and most likely only IPv4) but

No, the question is if there is any host stack + server software that deals with flash renumbering deployed.
And that is deployable without coding.

It's the same question Owen posed for the ISP side, when challenged with how DHCP behaves.
The point here is that we as the IETF must also consider the end-user here. Not that I don't think ISPs do that too, but so far this debate has largely been on the premise of the opertor with little concern of the consequences for the user.

Cheers,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Mon, 28 Oct 2019 15:04:36 +0100

> No, the question is if there is any host stack + server software
> that deals with flash renumbering deployed.  And that is deployable
> without coding.

Flash renumbering is by and large not a server problem. If a request
reaches the server, then the server typically can reply. Any flow that
spans the renumbering event will be affected, but there are lots of 
other issues that also affect established flows.

If you renumber the network that contains mail servers, web servers,
xmpp servers, etc., then the servers don't really notice.

Of course, a renumbering event requires DNS to be updated, possibly changes
to firewalls, etc. But that is no different from a proper renumbering event.

---

From: Ole Troan <[email-masked]>
Date: Mon, 28 Oct 2019 15:10:53 +0100

Philip,

> to firewalls, etc. But that is no different from a proper renumbering event.

And this is something you have tested and verified works?
For a set of typical open source packages?
See Bjørn's message as well.
And try to see what happens when you do this for a hidden primary DNS server...

The world just isn't ready for flash renumbering of networks, likely not graceful renumbering either.
There are not many sensible responses the end-users can come up with to a service provider with a network behaving this way, apart from isolating addressing. Aka NAT.

Cheers,
Ole

---

From: Jen Linkova <[email-masked]>
Date: Tue, 29 Oct 2019 08:57:13 +1100

> Right. Instant/flash renumbering is not supported in IP networks.

Oh. Surprise. After I've been doing it all the time....;)

Actually it would be helpful  to define requirements/expectations. I read it as:
R1: [MUST HAVE] after the renumbering host is able to open new connections
R2: [NICE TO HAVE] old connections survive the renumbering.

IMHO we shall at least enumerate the most common scenarios where R1 is
not happening and look what can be done here.
If we have a scenario when hosts end up with totally broken connectivity we can:
1) say 'oh just don't do that' - however before we do this (== produce
some BCPs) it's worth analysing if it's feasible and, more
importantly:
  --- is the party affected by the issue is the same party which is
supposed to follow the BCP?
  --- are we talking about 'fix all hosts'? (when did we deal last
time with the scenario 'a machine re-authenticated via 802.1x
successfully, changed the VLAN but kept the old IPv6 prefix'?
2) See if there is a way to mitigate at least part of the problem by
making the protocol more robust (isn't all DNA work is actually in the
same problem space?)

> Apart from "does not work", what more can the IETF say or do here?

Try to make the Internet work better, maybe? :)

-- 
SY, Jen Linkova aka Furry

---

From: Ole Troan <[email-masked]>
Date: Mon, 28 Oct 2019 23:36:24 +0100

> Oh. Surprise. After I've been doing it all the time....;)

Oh great. So which services do you run in the network? Any issue with short DNS ttls?
Or do you only do this with MP-TCP / QUIC or only mosh style applications with a built in session layer?
I presume you have a routed network with multiple routers and links as well?

Ole, not sarcastic at all. ;-)

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Oct 2019 14:22:35 +1300

> R1: [MUST HAVE] after the renumbering host is able to open new connections

How long after? Milliseconds, seconds, or minutes? It makes a lot of difference to the solution.

> R2: [NICE TO HAVE] old connections survive the renumbering.

I believe that when the operators refused to consider SHIM6 ten years ago, they were telling us that they really, truly do not care about that. So this becomes an application layer robustness issue.

    Brian

---

From: Owen DeLong <[email-masked]>
Date: Mon, 28 Oct 2019 19:53:37 -0700

> On Oct 27, 2019, at 1:11 PM, Philip Homburg <[email-masked]> wrote:
> 

That’s what I thought, but someone called it “incorrect behavior”, so I asked the question.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Mon, 28 Oct 2019 19:58:26 -0700

> On Oct 27, 2019, at 1:02 PM, Philip Homburg <[email-masked]> wrote:
> 

No, this only deprecates it for new sessions. Existing sessions will still need to time
out before they stop trying to use the old prefix. In an ideal world, a mechanism to
signal the need to immediately error out such existing sessions is preferable.

> perform both a denial of service attack and a man in the middle attack

This is equally true in both IPv4 and IPv6.

> hosts probably already uses RA-guard (or possibly SEND). 

One would certainly hope so.

Agreed.

> reason to rely on RA timers and the host could handle unmodified CPEs.

I don’t think such a solution is as likely to succeed or be widely deployed in the
near term.

Updating CPEs is generally a much more dependable and faster process than
updating all hosts.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Mon, 28 Oct 2019 20:00:17 -0700

> On Oct 27, 2019, at 12:46 PM, Ted Lemon <[email-masked]> wrote:
> 
> On Oct 27, 2019, at 3:35 PM, Owen DeLong <[email-masked] <mailto:[email-masked]>> wrote:

There’s a difference between networks where hostile hosts can occur in extreme circumstances (what you describe) and networks where hostile hosts are expected as a normal occurrence (what I was intending to describe).

The type of attack and type of resilience required vary between these two situations as well.

Owen

---

From: Ted Lemon <[email-masked]>
Date: Tue, 29 Oct 2019 05:43:48 -0400

> There’s a difference between networks where hostile hosts can occur in extreme circumstances (what you describe) and networks where hostile hosts are expected as a normal occurrence (what I was int…

I’m not following your distinction.   Bot infections can happen at any time, on any network.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 29 Oct 2019 14:15:40 +0100

> No, this only deprecates it for new sessions. Existing sessions
> will still need to time out before they stop trying to use the old
> prefix. In an ideal world, a mechanism to signal the need to
> immediately error out such existing sessions is preferable.

For IPv4 + NAT, if you flash renumber the upstream address then existing
connections will be stuck.

I'm not aware of any IPv4 signalling that could even tell a host behind NAT
that the upstream address changed (with the exception of bringing the link
down).

Maybe you can be more specific why deprecating the old IPv6 prefix does not 
give the same effect as on IPv4 + NAT?

> Updating CPEs is generally a much more dependable and faster process
> than updating all hosts.

Updating CPEs should make general web browsing work after flash renumbering.
That should be enough for most users.

---

From: Owen DeLong <[email-masked]>
Date: Tue, 29 Oct 2019 10:20:26 -0700

> On Oct 29, 2019, at 6:15 AM, Philip Homburg <[email-masked]> wrote:
> 

Not exactly… They do fairly quickly get sent TCP RSTs in most cases.

> that the upstream address changed (with the exception of bringing the link

Bringing the link down quickly and resetting the session allows for the connection
to be re-established and continue in most cases. OTOH, leaving the connection
hung until it times out at the application or host TCP stack level creates huge
delays in service restoration.

> give the same effect as on IPv4 + NAT?

Because the IPv4 host fairly quickly receives an RST packet when the outbound
packet hits a non-existent state table entry or a state table entry marked as dead.

OTOH, the IPv6 host doesn’t (currently) get any signaling from the local router
indicating that anything is amiss. It continues to treat the prefix as valid for existing
flows (and depending on the level of deprecation, i.e. whether or not a preferred
lifetime 0 was received) perhaps for new flows as well.

> That should be enough for most users.

Unless the CPE knows to send out an RA with a preferred lifetime of 0 for the now
deprecated prefix, then you are mistaken in the actual systemic behavior.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Tue, 29 Oct 2019 10:31:25 -0700

> On Oct 29, 2019, at 2:43 AM, Ted Lemon <[email-masked]> wrote:
> 

Bot infections are only one kind of hostile host.

The other kind is malicious actors who have hosts that are permitted on your network.

The former can occur anywhere.

The latter is less common on enterprise networks and more common on university networks and coffee shop networks and other public access networks.

I thought this was pretty clear from my original post.

Owen

---

From: Jen Linkova <[email-masked]>
Date: Wed, 30 Oct 2019 09:29:14 +1100

> Oh great. So which services do you run in the network? Any issue with short DNS ttls?

Well, I'm quite lucky. First of all, I'm mostly renumbering networks
containing "clients" - networks which rarely need incoming
connections.

> I presume you have a routed network with multiple routers and links as well?

Boring topologies mostly - two routers to provide first-hop
redundancy, two uplinks.
And - after I've done quite a bit of renumbering both dual-stack and
single-stack segments - IPv4 renumbering is much, much worse.
Sometimes you have to flap switchports.

---

From: Jen Linkova <[email-masked]>
Date: Wed, 30 Oct 2019 11:55:11 +1100

> How long after? Milliseconds, seconds, or minutes? It makes a lot of difference to the solution.

As soon as the host gets the new address configured.
If the address is assigned to the host interface and applications can
use that address to send packets - then those packets (and return
traffic) should  not be dropped by the network unless it's an explicit
(e.g. security) policy.

> I believe that when the operators refused to consider SHIM6 ten years ago, they were telling us that they really, truly do not care about that. So this becomes an application layer robustness issue.

Actually I kind of agree. I mean - there are many reasons why a
connection might get stuck/interrupted.
Devices can fail, can be rebooted etc. It would be nice if
applications could take care of this (and some of them do..)
In 'home CPE, DHCP-PD' case we are talking about renumbering happening
as a result of a CPE reboot/failure. So connections would suffer
anyway. Other flash renumbering cases are smth which is not happening
to the network on regular basis - so (IMHO) it's OK for it to be
slightly intrusive.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 30 Oct 2019 11:37:57 +0100

> Not exactly They do fairly quickly get sent TCP RSTs in most cases.

That's not my experience. I hardly ever see a CPE generate a RST when a flow
doesn't exist. 

> OTOH, leaving the connection hung until it times out at the
> application or host TCP stack level creates huge delays in service
> restoration.

This is exactly what happens today in many cases. Of course, where developers
get annoyed by this behaviour, they implement shorter timeout at the 
application level. I.e., a typical webbrowser doesn't wait for the host to
report an error on a TCP connection.

> Because the IPv4 host fairly quickly receives an RST packet when
> the outbound packet hits a non-existent state table entry or a
> state table entry marked as dead.

My experience is different. In any case, if we want the CPE to send a RST
when it upstream prefix changes, then of course that can be coded as well.
I very much doubt that we really want to go there. Changing the host
would be better.

> Unless the CPE knows to send out an RA with a preferred lifetime
> of 0 for the now deprecated prefix, then you are mistaken in the
> actual systemic behavior.

The whole point of this discussion is to write a draft that requires the CPE
to do so. Probably with a companion of recommended host changes.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 30 Oct 2019 06:46:22 -0400

> On Oct 30, 2019, at 6:38 AM, Philip Homburg <[email-masked]> wrote:
> 
> doesn't exist

To be clear, the issue is that in order for a TCP RST to be sent, the TCP message has to be delivered to the endpoint in the first place.   The CPE isn’t going to randomly send TCP RSTs to flows that don’t terminate on it.   That is, it is not going to watch TCP traffic through it, notice that the source address on a particular message is not on the prefix it is currently advertising, and then construct a TCP RST to break that connection.

So in practice, if a renumbering has happened in this way, what is going to happen is that that TCP connection is going to time out for ninety seconds.

> report an error on a TCP connection.

This should not be happening often enough that application developers are adding shorter timeouts to their code.  A CPE reboot is an exceptional event, and a deliberate renumbering by the ISP ought to be as well.   If they are doing that, I suspect it’s independent of the renumbering problem.

It would not surprise me if there are CPEs that behave badly when the ISP renumbering, and ISPs that behave badly when a prefix that is still valid is, from their perspective, no longer on offer. We ought to characterize that problem and propose solutions to this.   By “characterize,” I mean look at what actual CPEs do, not theorize, although I think theorizing isn’t bad either.

---

From: Ole Troan <[email-masked]>
Date: Wed, 30 Oct 2019 12:01:45 +0100

> So in practice, if a renumbering has happened in this way, what is going to happen is that that TCP connection is going to time out for ninety seconds.

What a CPE does do, is to send an ICMP destination unreachable (5 - Source address failed ingress/egress policy) as the source address would violate the unicast RPC check. RFC7084, L-14.

> It would not surprise me if there are CPEs that behave badly when the ISP renumbering, and ISPs that behave badly when a prefix that is still valid is, from their perspective, no longer on offer. W…

You can generalise the renumbering problem to a multi-prefix multi-homing problem. Whenever a host has multiple addresses the application must continuously evaluate all possible paths and react to path failures. An invalidated prefix is just a reachability problem close to the host, and theoretically no different than a path failure multiple hops away.

In the case when a requesting router loses a prefix, it can of course signal that to the hosts as proposed in Fernando's draft. But that doesn't solve the general problem, and I'm skeptical to using addressing as a reachability signal. E.g. if the CPE's upstream link flaps, is that enough to trigger deprecation of the prefix? Of course it shouldn't.

Ole

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 30 Oct 2019 11:26:39 +0000

Ole Troan wrote on 30/10/2019 11:01:
> What a CPE does do, is to send an ICMP destination unreachable (5 -
> Source address failed ingress/egress policy) as the source address
> would violate the unicast RPC check. RFC7084, L-14.
what many, if not most, CPEs do is drop the flow on the ground and move 
on with life.

Nick

---

From: Timothy Winters <[email-masked]>
Date: Wed, 30 Oct 2019 08:29:44 -0400

Hi Ted,

Yes we have a couple of test cases for IPv6 Ready CE Router Logo that
confirms this behavior.  One focuses on "Prefix Change" or what your
calling Flash renumber.  I will note this is a common failure the first
time devices fail.

Regards,
Tim

---

From: Ted Lemon <[email-masked]>
Date: Wed, 30 Oct 2019 08:32:59 -0400

On Oct 30, 2019, at 08:30, Timothy Winters <[email-masked]> wrote:
> Yes we have a couple of test cases for IPv6 Ready CE Router Logo that confirms this behavior.  One focuses on "Prefix Change" or what your calling Flash renumber.  I will note this is a common failure the first time devices fail.

Thanks for the info!  Which behavior do you mean?  There’s the handling of pd, and then there’s the icmp response.

---

From: Timothy Winters <[email-masked]>
Date: Wed, 30 Oct 2019 08:40:38 -0400

Hi Ted,

We check both, the handling of the IA_PD and the error message.

~Tim

---

From: Ted Lemon <[email-masked]>
Date: Wed, 30 Oct 2019 08:58:59 -0400

> We check both, the handling of the IA_PD and the error message.

And to be clear, you mean that if the CPE asks for a prefix delegation and doesn’t get the prefix it previously had, it deprecates it as described in L-14?  When this deprecation happens, what ways are being tested for it to happen?

E.g., is it the case that the client sends an IA PD containing an IA Prefix option, is the server returning the IA Prefix option containing the same prefix, with a status code encapsulated in it?   What status code?   Or is it returning an IA Prefix option with a different prefix?   Or is it doing both?

---

From: Timothy Winters <[email-masked]>
Date: Wed, 30 Oct 2019 09:14:29 -0400

Hi Ted,

We test it four different ways.
A: Lifetimes set to zero (First IA_PD gets to zero, New IAPD as a lifetime)
B: Prefix Timeout (First IA_PD never gets renewed)
C: Reconfigure (Send Reconfigure responding Renew message has first IA_PD
to zero, second IA_PD valid)
D: Change Prefix Length

Details are located here
<https://www.iol.unh.edu/sites/default/files/testsuites/hnc/IPv6_Ready_Specification_CE_Router_Conformance.pdf>
for
test 2.7.5.

~Tim

On Wed, Oct 30, 2019 at 8:59 AM Ted Lemon <[email-masked]> wrote:

> And to be clear, you mean that if the CPE asks for a prefix delegation and
> doesn’t get the prefix it previously had, it deprecates it as described in
> L-14?  When this deprecation happens, what ways are being tested for it to
> happen?
>
> E.g., is it the case that the client sends an IA PD containing an IA
> Prefix option, is the server returning the IA Prefix option containing the
> same prefix, with a status code encapsulated in it?   What status code?
> Or is it returning an IA Prefix option with a different prefix?   Or is it
> doing both?
>
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 30 Oct 2019 13:24:35 +0000

While I haven’t followed this discussion in detail, I do wonder if the SP DHCP server could provide some assistance to CPEs that don’t have storage …

When a CPE boots and does a Solicit / Request, it could include a new option that tells the DHCP server that it has no storage and therefore no knowledge of any “past” leases. The DHCP server in this case could include any “old” leases it still has a record of (i.e., that have not expired but are no longer “valid” in terms of the configuration because of renumbering or other conditions) with 0 lifetimes. That would allow a rebooting CPE to learn old delegated prefixes that it might have advertised to its clients and initiate deprecation of these prefixes (and any addresses generated from them).

This would improve the situation when the CPE has no storage and reboots (whether customer or SP initiated).

Note: There could be conditions in which this would fail (such as if SP removed all configuration related to the older prefixes from the DHCP server), but in many cases it would allow for clean renumbering. Of course, it requires updating the DHCP software (on the SP servers and in the CPEs), but it probably easier to accomplish than requiring use of storage on the CPE device.

Be a relative easy draft to write up (at least in theory).

  *   Bernie

From: v6ops <[email-masked]> on behalf of Ted Lemon <[email-masked]>
Date: Wednesday, October 30, 2019 at 9:00 AM
To: Timothy Winters <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

On Oct 30, 2019, at 8:40 AM, Timothy Winters <[email-masked]<mailto:[email-masked]>> wrote:
We check both, the handling of the IA_PD and the error message.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 30 Oct 2019 14:33:08 +0100

Hi Bernie,

I think RFC4649, option 37, provides that option.

Regards,

Jordi

@jordipalet

El 30/10/19 14:25, "v6ops en nombre de Bernie Volz (volz)" <[email-masked] en nombre de [email-masked]> escribió:

-          Bernie

_______________________________________________ v6ops mailing list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 30 Oct 2019 13:46:09 +0000

I don’t really think so as this is a relay agent option – not a CPE option. For the SP, the CPE is a DHCP client.

If you are trying to simply say that a relayed packet may be the trigger, one could certainly consider doing that in all those cases but it is not clear if that could cause some problems (if theory it should not … but you never know). Certainly, one could consider a DHCP server configuration knob that says “do this” (for some part or all of the configuration).

  *   Bernie

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wednesday, October 30, 2019 at 9:33 AM
To: Bernie Volz <[email-masked]>, Ted Lemon <[email-masked]>, Timothy Winters <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

Hi Bernie,

Regards,
Jordi
@jordipalet

El 30/10/19 14:25, "v6ops en nombre de Bernie Volz (volz)" <[email-masked]<mailto:[email-masked]> en nombre de [email-masked]<mailto:[email-masked]>> escribió:

-          Bernie

---

From: Ted Lemon <[email-masked]>
Date: Wed, 30 Oct 2019 09:51:06 -0400

> When a CPE boots and does a Solicit / Request, it could include a new option that tells the DHCP server that it has no storage and therefore no knowledge of any “past” leases. The DHCP server in th…

I don’t see any reason why this should not just be the default behavior.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 30 Oct 2019 14:03:06 +0000

Ted:

A Solicit kind of means “start from scratch”. So that’s why the current RFC8415 specification does not require sending information related to “old” leases. The text also does not provide for sending 0 lifetimes in an Advertise which is where this would first appear – and then also in the Reply to the Request. Perhaps there is an argument that these leases should not be added to the Advertise, but be in the Reply to the Request.

So, it does get a bit more complex and needs to be worked out.

> I don’t see any reason why this should not just be the default behavior.

As I said that as this is a change in behavior, we don’t know what the consequences for existing devices may be – and in some cases, if the device does have storage, would this confuse it? I’m not against having this be a configuration knob in the server which can be applied at various “levels” (perhaps even globally).

  *   Bernie

From: Ted Lemon <[email-masked]>
Sent: Wednesday, October 30, 2019 9:51 AM
To: Bernie Volz (volz) <[email-masked]>
Cc: Timothy Winters <[email-masked]>; IPv6 Operations <[email-masked]>
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

On Oct 30, 2019, at 9:24 AM, Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>> wrote:
When a CPE boots and does a Solicit / Request, it could include a new option that tells the DHCP server that it has no storage and therefore no knowledge of any “past” leases. The DHCP server in this case could include any “old” leases it still has a record of (i.e., that have not expired but are no longer “valid” in terms of the configuration because of renumbering or other conditions) with 0 lifetimes. That would allow a rebooting CPE to learn old delegated prefixes that it might have advertised to its clients and initiate deprecation of these prefixes (and any addresses generated from them).

---

From: Ole Troan <[email-masked]>
Date: Wed, 30 Oct 2019 15:07:11 +0100

Ted,

> E.g., is it the case that the client sends an IA PD containing an IA Prefix option, is the server returning the IA Prefix option containing the same prefix, with a status code encapsulated in it?…

You are thinking about this wrong.
The simple implementation of uRPF/BCP38 is: on LAN ingress to do a lookup in the FIB of the SA, if the resulting adjacency/interface matches the ingress interface allow packet otherwise drop packet and send ICMP message. This behaviour is required regardless of renumbering or not.
The ISP is required to do this on their ingress interfaces too.

Cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 30 Oct 2019 10:15:58 -0400

> As I said that as this is a change in behavior, we don’t know what the consequences for existing devices may be – and in some cases, if the device does have storage, would this confuse it? I’m not…

There are a lot of assumptions you’ve stated here that as far as I know do not appear in the standard.   E.g., you may think that a solicit kind of means “start from scratch,” but is it not okay for the DHCP server to send 0 lifetimes in the Advertise?  Or is it just not suggested?

I agree that it needs to be worked out.   As for existing devices, I think that at this point a scorched earth policy is not unreasonable: if there are devices out there that have firmware that can’t be updated to fix problems like this, it’s probably good if they stop working and have to be “recycled.”   I hope that number is zero; if for some ISP it’s sufficiently more than zero that this isn’t the right solution, then they may have to wait until those routers EOL before deploying this “new" behavior.

However, I think in practice this simply wouldn’t cause a problem, and complexifying things to prevent such a problem seems unnecessary in the absence of data.

Do we test for the case where the DHCP server sends back two IA Prefix options in an IA_PD?   I think that’s allowed, isn’t it?   Maybe the right behavior is to leave the Advertise unchanged, but send to IA Prefixes in the Reply.

---

From: "Radu-Adrian Feurdean" <[email-masked]>
Date: Wed, 30 Oct 2019 15:27:49 +0100

> Such a case could be mentioned, as not being a problem described in this 

If you are talking about residential service (not business/enterprise-class), I would like to know who your service provider is.

> exist as open source or some other available package.

Dibbler-client does that by default. Once the delegated prefix (shorter than /64) is obtained, a /64 from that prefix is assigned to each interface. With proper radvd.conf configuration (prefix ::/64), RAs will be sent for those prefixes.

A lot (?? most ??) of CPEs implementing DHCPv6-PD client do this in some form or another. Some do this automatically (take prefixes and assign them to interfaces), other need manual configuration (n-th prefix go to interface ZZZ).

> deployment scenario'.  Is this a scenario that is _expected_ to be 'common'?

"Expected enough" to warrant a device to be disqualified as "CPE that supports IPv6" if it doesn't work this way. In an ISP environment.

> several computers in the car that need IPv6 addresses.

Like : you have a mobile phone on a network doing IPv6+NAT64, you pout it in tethering/mobile-hotspot mode, and connect several other devices (usually laptops) to that hotspot - they all get IPv6 addresses (in the same single /64 that the phone obtained via SLAAC or something else). It is clear that getting a /56 (even a /60 or /62 would do it) via DHCPv6-PD would be a nicer solution, but when your mobile device runs android....

-- 
R-A.F.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 30 Oct 2019 17:29:48 +0100

Le 30/10/2019 à 15:27, Radu-Adrian Feurdean a écrit :
>> First, I must say that the home network that I use uses a fixed
>> /56 allocated by my ISP.  In this, the prefix never changes, and it
>> is not obtained by DHCPv6-PD - it is guaranteed by contract signed
>> by hand. Such a case could be mentioned, as not being a problem 
>> described in this draft.
> 
> If you are talking about residential service (not 
> business/enterprise-class), I would like to know who your service 
> provider is.

(my correction: I am not at all good at bit fiddling, sorry.  What I get
at home is a /60, I think, not a /56.  Because the CPE GUI proposes me
to split it into 8 /64s).

YEs, it is at home, probably you mean it is residential.  The payment is
a flat 35eur/month.  No special QoS commitments from them, other than a
'noise level' of 55dbm due to the length of the line.

The service provider is Free. ('Free' is its name; it was the first
callable at gratuitous phone numbers when all others requested a payment
in exchange; later they were the first to offer flat rates when the
others were per-connection time; because of that it called itself so).

>> I must say that this kind of software (request a prefix with 
>> DHCPv6-PD, form sub-prefixes, and put them in RAs on the other 
>> interfaces) does not exist as open source or some other available 
>> package.
> 
> Dibbler-client does that by default. Once the delegated prefix 
> (shorter than /64) is obtained, a /64 from that prefix is assigned to
> each interface. With proper radvd.conf configuration (prefix ::/64),
> RAs will be sent for those prefixes.

I did not know.  The difficulty I talked about is to maintain what's in
that radvd.conf in sync with what is dhcpd.conf.  Maybe some software
packages already do it.

Also, because you talk about deriving /64s out of /56: I am not sure
there is a standard way to do it.  Maybe dibbler does it, but I doubt it
is the best way.

> A lot (?? most ??) of CPEs implementing DHCPv6-PD client do this in 
> some form or another. Some do this automatically (take prefixes and 
> assign them to interfaces), other need manual configuration (n-th 
> prefix go to interface ZZZ).

It's good to know.

But again, I doubt these CPEs derive prefixes in the manner that _I_
want it.

For example, I want the /60 to be derived into one /64 and a single
other set of /64s.  I dont want the /60 to be derived into 8 /64s.

I do that to help aggregation and speed up the forwarding process.

Other times I might want to derive that /60 differently.

I dont think there is a standard way to do it.

> "Expected enough" to warrant a device to be disqualified as "CPE that
> supports IPv6" if it doesn't work this way. In an ISP environment.

Well.

A CPE that supports IPv6 should run DHCPv6.  A CLient and a Server?
Both?  Just one?

How does CPE propagate the prefixes learned with its CLient to its Server?

>> - an IoT scenario, in which an IoR Router connects several sensors
>>  to the Internet.  For example, an IoT Router is deployed in a box
>>  at a traffic lights.  The IoT device is the Traffic Lights 
>> Controller connected on Ethernet to the IoT Router.  The IoT Router
>> is connected on 4G.
>> 
>> - a vehicular networks scenario: the On-Board Unit is deployed in a
>> car. This OBU has a 4G interface and an Ethernet interface. There
>> are several computers in the car that need IPv6 addresses.
> 
> Like : you have a mobile phone on a network doing IPv6+NAT64,

My CPE is not doing NAT64, I think.

I dont want NAT64.

> you pout it in tethering/mobile-hotspot mode, and connect several 
> other devices (usually laptops) to that hotspot - they all get IPv6 
> addresses (in the same single /64 that the phone obtained via SLAAC 
> or something else). It is clear that getting a /56 (even a /60 or /62
> would do it) via DHCPv6-PD would be a nicer solution, but when your
> mobile device runs android....

Well.  Android is good in many places and for many goals.

I agree that tethering/mobile-hotspot mode is a good solution in certain
circumstances, like sharing one's smartphone connection to tablets nearby.

However, tethering in IPv6 ('64share' RFC) has some drawbacks: (1) it
does not support more than the WiFi tethered to the cellular (doesnt
support an additional subnet like Ethernet) and (2) the incoming
interface must be cellular (cant be another wifi).

In a car, one has a WiFi hotspot but also lots of Ethernets and CANs.
It's not possible to use 64share to accomodate all that.

Hence, there DHCPv6-PD is not just a nicer solution - it is a requirement.

Other than cars, even at home, one may want a DHCPv6-PD Server on the
CPE for similar reasons.

If one wants to run tethering on a device at home that has no cellular
connection (e.g. a WiFi<->USB, or a USB<->Ethernet device) to extend to
other devices then one cant use tethering ('64share'), must use DHCPv6-PD.

Alex

---

From: Mark Smith <[email-masked]>
Date: Thu, 31 Oct 2019 10:38:41 +1100

On Wed, 30 Oct 2019 at 22:02, Ole Troan <[email-masked]> wrote:
<snip>

> In the case when a requesting router loses a prefix, it can of course signal that to the hosts as proposed in Fernando's draft. But that doesn't solve the general problem, and I'm skeptical to usin…

Exactly. Transient network faults are supposed to be survived - that's
why TCP makes quite a number of attempts at re-transmitting when
packet loss occurs, rather than just immediately terminating the
connection.

When an ISP "flash renumbers" a customer what's really happening is
that the customer's network layer point of attachment to the network
is being changed - the customer is being abruptly disconnected, moved
and re-connected. Possibly that is easy to overlook because the
customers physical location and their physical link to the network
doesn't change.

I think Ole observed that this is contrary to what the PD prefix's
Valid Lifetime said would be the case. The ISP supplied a PD Prefix
with a Valid Lifetime of X seconds, and then broke that promise by
abruptly changing addressing before X seconds. ISPs should be expected
to live up to their Valid Lifetime promises.

Regards,
Mark.

---

From: Owen DeLong <[email-masked]>
Date: Wed, 30 Oct 2019 20:05:16 -0700

8 /64s is a /61.
16 /64s is a /60.
256 /64s is a /56.
You should be getting 65,536 /64s (a /48) and if I were you, I would complain to any ISP that gave me less.

Owen

> On Oct 30, 2019, at 9:29 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
>>> by hand. Such a case could be mentioned, as not being a problem described in this draft.
>>> I must say that this kind of software (request a prefix with DHCPv6-PD, form sub-prefixes, and put them in RAs on the other interfaces) does not exist as open source or some other available package.
>> Dibbler-client does that by default. Once the delegated prefix (shorter than /64) is obtained, a /64 from that prefix is assigned to
>>> Because of that, I am surprised that you call it 'the most common deployment scenario'.  Is this a scenario that is _expected_ to be
>>> 'common'?
>>> at a traffic lights.  The IoT device is the Traffic Lights Controller connected on Ethernet to the IoT Router.  The IoT Router
>>> is connected on 4G.
>> you pout it in tethering/mobile-hotspot mode, and connect several other devices (usually laptops) to that hotspot - they all get IPv6 addresses (in the same single /64 that the phone obtained via SLAAC or something else). It is clear that getting a /56 (even a /60 or /62

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 31 Oct 2019 11:02:33 +0100

> 8 /64s is a /61.

Right, I guess 8 /64s is a /61 because 2^3 is 8, and 3+61 is 64.

Yet in the hextet notation, I get ce10, ce11 ... ce17 (see an annotated 
figure of GUI below).  They are 8 /64s.  I dont see ce18, neither ce19 
in the GUI.  Might it be that my neighbor gets ce18 and ce19, but it 
would mean s/he cant get more than 2 /64s.  Might it be that free hides 
ce18 and ce19 for something else inside my home that they dont tell me 
what.  Might it be they expect me to ask them for more addresses later.

Whether I get a /61 or a /60 at home is still a valid question for me.

> 16 /64s is a /60.
> 256 /64s is a /56.
> You should be getting 65,536 /64s (a /48) and if I were you, I would complain to any ISP that gave me less.I

I keep the /48 request in mind for my next interaction with their 
service, because I have many things to ask.

I suppose they will ask me, in return, if I already spent the 2^61 
addresses they already gave me.

Alex

PS:

For information, see below an annotated copy of the GUI listing the form 
of the 8 prefixes I see in GUI on CPE.

One may notice things to complain about: the use of ff:fe in the LL, the 
way they call it 'Prefix Delegation' without using DHCPv6-PD and the 
optional firewall IPv6 activation (off by default - they dream :-)

You may understand why I say I have many things to ask them.

---

From: Owen DeLong <[email-masked]>
Date: Thu, 31 Oct 2019 07:16:57 -0700

> On Oct 31, 2019, at 3:02 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
Well, a /60 would include not only ce10..ce17, but also ce18, ce19, ce1a, ce1b, ce1c, ce1d, ce1e, and ce1f.

I’m not familiar with your particular router or its GUI, so I can’t explain why it displays what it does.

It may simply be limited to 8 subnets that it can handle. It may be something else.

I doubt that it has anything to do with your neighbor as your neighbor would get their own separate PD. They might have the opposing /61 (ce18..ce1f), but in that case they would still also have 8 subnets in that case.
> Yet in the hextet notation, I get ce10, ce11 ... ce17 (see an annotated figure of GUI below).  They are 8 /64s.  I dont see ce18, neither ce19 in the GUI.  Might it be that my neighbor gets ce18 and ce19, but it would mean s/he cant get more than 2 /64s.  Might it be that free hides ce18 and ce19 for something else inside my home that they dont tell me what.  Might it be they expect me to ask them for more addresses later.
> 
> I keep the /48 request in mind for my next interaction with their service, because I have many things to ask.
> 
> I suppose they will ask me, in return, if I already spent the 2^61 addresses they already gave me.
> 
This is IPv4think. In the IPv6 world, the intent is to provide large blocks to avoid future need to renumber and routing table pollution.

Owen

> Alex
> 
> 
> 
> 
> 
> PS:
> 
> For information, see below an annotated copy of the GUI listing the form of the 8 prefixes I see in GUI on CPE.
> 
> One may notice things to complain about: the use of ff:fe in the LL, the way they call it 'Prefix Delegation' without using DHCPv6-PD and the optional firewall IPv6 activation (off by default - they dream :-)
> 
>>> On Oct 30, 2019, at 9:29 AM, Alexandre Petrescu <[email-masked]> <mailto:[email-masked]> wrote:
>>> 
>>> 
>>> 
>>> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 31 Oct 2019 15:50:03 +0100

Le 31/10/2019 à 15:16, Owen DeLong a écrit :
>
>
>> On Oct 31, 2019, at 3:02 AM, Alexandre Petrescu 
> I doubt that it has anything to do with your neighbor as your neighbor 
> would get their own separate PD. They might have the opposing /61 
> (ce18..ce1f), but in that case they would still also have 8 subnets in 
> that case.

I think that's right.

I think I conclude I get a /61 at home from Free.  I will try to not 
forget this number in future conversations.

(remark, a private email also challenged me on the stability and 
contractuability of this prefix: I must say I dont know; I just know it 
did not change in several years)

>> Yet in the hextet notation, I get ce10, ce11 ... ce17 (see an 
>> annotated figure of GUI below).  They are 8 /64s.  I dont see ce18, 
>> neither ce19 in the GUI.  Might it be that my neighbor gets ce18 and 
>> ce19, but it would mean s/he cant get more than 2 /64s.  Might it be 
>> that free hides ce18 and ce19 for something else inside my home that 
>> they dont tell me what.  Might it be they expect me to ask them for 
>> more addresses later.
>>
> This is IPv4think. In the IPv6 world, the intent is to provide large 
> blocks to avoid future need to renumber and routing table pollution.

Noted the IPv4think.

Alex

>
> Owen
>
>> Alex
>>
>>
>>
>> PS:
>>
>> For information, see below an annotated copy of the GUI listing the 
>> form of the 8 prefixes I see in GUI on CPE.
>>
>> One may notice things to complain about: the use of ff:fe in the LL, 
>> the way they call it 'Prefix Delegation' without using DHCPv6-PD and 
>> the optional firewall IPv6 activation (off by default - they dream :-)
>>
>>>> On Oct 30, 2019, at 9:29 AM, Alexandre Petrescu<[email-masked]>  wrote:
>>>>
>>>>
>>>>

---

From: Naveen Kottapalli <[email-masked]>
Date: Thu, 31 Oct 2019 23:09:44 +0530

+1

The problem I feel is mainly because of the the middle boxes sitting
between the devices which are using the prefix and the one who delegated
the prefixes.  I believe in most of the deployed implementations like the
BNG or any DHC server will have a record of the prefixes being delegated
and lifetimes will be honored till lease time expires.  As a matter of fact
in the cases listed, prefixes are be valid for the given lifetimes at both
the device and the delegating router.  Just because the CPE got rebooted or
lost the context of the prefixes, the middle boxes deprecating or
suggesting a whole set of new prefixes towards the devices might not be the
solution to the actual problem.

Yours,
Naveen.

On Thu, 31 Oct 2019 at 05:09, Mark Smith <[email-masked]> wrote:

> > In the case when a requesting router loses a prefix, it can of course
> signal that to the hosts as proposed in Fernando's draft. But that doesn't
> solve the general problem, and I'm skeptical to using addressing as a
> reachability signal. E.g. if the CPE's upstream link flaps, is that enough
> to trigger deprecation of the prefix? Of course it shouldn't.
> >
>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 31 Oct 2019 15:47:54 -0300

On 27/10/19 19:37, Mark Smith wrote:
> 
> 
> On Mon, 28 Oct 2019, 06:06 Brian E Carpenter,
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> This is not what I said, as it is implying that I said there is no need
> for robustness.
> 
> Robustness suffers from the law of diminishing returns. At some point
> the cost to design and implement robustness exceeds the either the
> likelihood it will be needed or the benefit it returns if needs to be used.

Could you please argue against any specific text in our document?

> Sugar is sometimes poured into the fuel tanks of cars, which will
> destroy the engine. It is not common and is done maliciously. If
> robustness should be universal, does that mean car engines should be
> made impervious to sugar, at great expense to everybody, despite the
> need for that robustness being rare?
> 
> Some ISPs are shifting the cost and consequences of their design
> decision, which they can change, onto the IETF, CPE vendors and host
> implementers, and indirectly their customers'. Are they willing to pay
> these other parties to fix a problem that they are both causing and
> could fix themselves?

Is there anything that we are recommending CPEs to do that shouldn't be
there (anyway) to comply with the semantics of the protocols?

That said, I will repeat that the home network/cpe case is only one of
the scenarios in which this problem may be faced.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 31 Oct 2019 16:13:34 -0300

> valid lifetime as an invalid prefix and immediately deprecate it from

OK, so you do agree with the proposed change? (in
draft-gont-6man-slaac-renum, not in *this* document)

> the prefix, but it will do so in its next RA.

Maybe it wasn't clear in the I-D, but the basic idea is:
If you receive multiple RAs from router A that do not advertise the
prefix, then you disassociate such prefix with router A. If nobody else
is advertising the prefix, you'd deprecate it. If other routers are
advertising it, this would not change the status quo of the prefix wrt
such other routers.

> same set of PIOs, nor are they required to use the same advertisement

Agreed. Please see above.

> that this prefix should not be auto configured and should no longer be

You really make a good point. I will go through RFC4861 and see what's
the current expected behaviour in such case.

> nor would I use the word “Finally” as a lead-in to a back-reference.

Will tweak the text accordingly.

Thanks!

Cheers,

---

From: "Radu-Adrian Feurdean" <[email-masked]>
Date: Thu, 31 Oct 2019 20:15:19 +0100

> ce1a, ce1b, ce1c, ce1d, ce1e, and ce1f.

They DO provision a /60 per customer, they just keep half of it for their own use. The separate STB box was known to make use of it at some moment on the past. It may still be the case... probably... 

> complain to any ISP that gave me less.I 

Legacy of their past 64rd deployment. 

-- 
R-A.F.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 31 Oct 2019 16:21:04 -0300

Hello, Ted,

On 27/10/19 09:02, Ted Lemon wrote:
> Indeed, this would also not actually solve the problem.   At present,
> the ISPs are doing something that is out of spec and causes problems.
> If we “fix” this by accommodating what they do, does that help, or
> does it just encourage them to continue doing it?

Did happy eyeballs encourage broken IPv6 connectivity, or did it
actually help IPv6 deployment?

> What should be happening on the host with a prefix that’s deprecated
> is that TCP connections should be timing out.   This doesn’t take
> very long.  

~9 minutes, IIRC.

> And if there is a new prefix being advertised on the
> link, that address should have a valid lifetime newer than the old
> prefix, meaning that the next TCP connection should come from that
> new prefix, not the old one.

That's not correct. Neither the Valid Lifetime nor the Preferred
Lifetime affect address selection.

> I think Fernando’s plan to shorten some timers makes sense, but
> shortening the minimum really doesn’t—it just opens up an opportunity
> for an easy DoS, since I can now just send out death packets to the
> local network and break everything all at once.

The reality with ND attacks are (modulo sanity checks on the packets):
you enforce FHS, or you don't.

> something that’s a real improvement?

Every piece helps.

> deprecation of prefixes using PD.

But robustness cannot rely on any of these specific bits.

>  Second, fix RA so that it’s
> SEND does this, sort of.  Nobody uses SEND because it tries to solve
> a too-big problem and does it using obsolete technology.   But the
> basic idea is good: include a public key in every RA that can be used
> to validate that the RA was signed with the corresponding private
> key.

What's the practical difference between that, an a network that supports
RA-Guard?

> When another RA arrives, see if it was signed with the same key.   If
> so, it came from the same router, and can be trusted to update
> whatever information that router sent, including flash-deprecating a
> prefix.   If not, ignore it.

In the non-SEND trust model, you do trust the local router. Why did you
trust the local router to configure your network, but not for
deprecating the prefix?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 31 Oct 2019 16:25:23 -0300

On 27/10/19 10:54, Ted Lemon wrote:
> On Oct 27, 2019, at 9:41 AM, Philip Homburg <[email-masked]
> <mailto:[email-masked]>> wrote:
> Actually I do not believe this is correct behavior.   Let us assume
> prefix delegation.   If we have prefix delegation, then when the CPE
> comes back from a power cycle, it should reconfirm the prefix it had
> previously; the assumption is that that prefix is still valid.  This can
> be handled in infrastructure—the ISP edge router should know whether the
> prefix is still valid, because if it is it should be advertising a route
> for it.   If it is not still valid, then the CPE router should attempt
> to renew it, which would go to the DHCP server (possibly both messages
> would).

That assues the CPE has stored the previously-leased prefix on stable
storage -- which does not need to be the case. Hence the related text in
our I-D.

Thanks,

---

From: Owen DeLong <[email-masked]>
Date: Thu, 31 Oct 2019 12:27:30 -0700

> On Oct 31, 2019, at 12:13 PM, Fernando Gont <[email-masked]> wrote:
> 

From the context of my thinking at the time of writing the original reply,
“this document” referred to draft-gont-6man-slaac-renum. Apolgies
for my lack of clarity as you have apparently interpreted it differently.

> advertising it, this would not change the status quo of the prefix wrt

That’s definitely not how I interpreted the I-D and I would strongly encourage
you to review and update the I-D for clarity in this area. I’m actually still not
100% convinced that this is correct behavior. It also places additional burdens
on hosts to track all routers associated with a given prefix rather than merely
tracking candidate default gateways, RIO data, and one set of prefix timers
utilizing the most recently received timer refreshes.

> Agreed. Please see above.

With the above clarification, I think it can be done and is less likely to break
things. However, it does place a significant additional tracking burden on the
host which I’m not entirely convinced is a desirable situation. Especially in the
case of a resource-constrained host which is using SLAAC to avoid the overhead
of DHCP.

Thanks!

Owen

---

From: Ted Lemon <[email-masked]>
Date: Thu, 31 Oct 2019 15:34:02 -0400

> actually help IPv6 deployment?

Don’t get me wrong—I’m not saying we shouldn’t do things to improve the situation.   I am saying that we should be strategic about it.

>> is that TCP connections should be timing out.   This doesn’t take

Should be 90 seconds.

> Lifetime affect address selection.

Okay, there’s something to fix.  Why would these not affect source address selection?

> you enforce FHS, or you don't.

What is “FHS”?

>> something that’s a real improvement?

Right, but if the effort involved in two different options differs by epsilon, you should always choose the option that produces the better outcome, shouldn’t you?

> What's the practical difference between that, an a network that supports

On a network that supports RA guard, there probably is no difference, but RA guard on some networks, as we’ve discussed in the past, will actually make the network not work.   RA guard requires an active administrator.   So the CPE case we’re talking about isn’t relevant.

> trust the local router to configure your network, but not for

In the non-SEND trust model, you trust the local network.   You hope that the RA you get “from the router” is actually from the router.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 31 Oct 2019 16:38:39 -0300

> of NAT. It causes significant issues in IPv6.

Note that this is *one* of the network scenarios that may lead to this
problematic scenario.

> broken behavior then so be it.

Indeed. Besides, the patch increases robustness overall.

> Because bundling features is a good way to ensure that nothing gets done.

Indeed.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 31 Oct 2019 16:41:28 -0300

On 27/10/19 14:14, Ted Lemon wrote:
> On Oct 27, 2019, at 11:05 AM, Philip Homburg <[email-masked]
> I think you missed my point.  You can’t do flash renumbering by
> advertising a prefix with a valid lifetime of zero, because that will be
> ignored by hosts.   If it were not ignored by hosts, it would be a very
> effective DoS vector. 

As someone that has played a lot with ND-based DoS vectors, I should say
that you trust RAs, or you don't. If you do, all bets are off. ("sudo
apt-get install ipv6toolkit;man ra6" and you'll get examples of a bunch
of other DoS attacks that an attacker can perform).

>From an attacker's point of view, you just need one that works.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 31 Oct 2019 16:43:08 -0300

On 27/10/19 16:35, Owen DeLong wrote:
> 
> 
>> On Oct 27, 2019, at 10:14 , Ted Lemon <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> On Oct 27, 2019, at 11:05 AM, Philip Homburg
>> <[email-masked] <mailto:[email-masked]>> wrote:
>> advertising a prefix with a valid lifetime of zero, because that will
>> be ignored by hosts.   If it were not ignored by hosts, it would be a
>> very effective DoS vector.    And so if you want to be able to flash
>> deprecate a route, you need some way to validate that the deprecation
>> is coming from the same source as the route.   Hence my suggested
>> “limited SEND”.
>>
>> Limited SEND would not be hard to implement.   Yes, it would be
>> marginally harder than just saying that hosts should accept flash
>> deprecation of prefixes.   But nobody with any sense is going to
>> implement that in their IP stack, so in practice if you want this to
>> work, you need some way to do flash deprecations that doesn’t create a
>> massive attack vector.
> 
> I recognize that there are environments where that is expected behavior
> (e.g. Coffee Shop Wifi, University networks, etc.),but
> In the vast majority of situations where I would expect hostile hosts to
> be likely to be on LAN, I don’t think I’d be using

You can do SLAAC as long as you do FHS. At which point the issue raised
by Ted is a non-issue.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 31 Oct 2019 15:47:18 -0400

> of other DoS attacks that an attacker can perform).

As an end user, I don’t have this experience.   If someone is spamming my network with RAs, I can find out who and disconnect them.   A DoS attack based on massive quantities of RAs is a lot different than an attack that shuts my network off with one multicast.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 31 Oct 2019 15:49:24 -0400

On Oct 31, 2019, at 3:47 PM, Owen DeLong <[email-masked]> wrote:
> RA Guard could be default configured on switches with particular default “plug router in here” (uplink) ports, eliminating the need for an active administrator. This could be a useful specification in the HomeNet documents, perhaps.

This would be disastrous.   It pretty much makes permissionless networking impossible in exchange for solving a security problem no-one has.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 31 Oct 2019 16:47:43 -0300

On 27/10/19 19:03, Bernie Volz (volz) wrote:
>>I don’t know of a single DHCPv6 server which operates that way
> currently. Can you point to a working example?
> 
>  
> 
> That is actually the RFC8415 specified behavior … the DHCP server I work
> on (Cisco Prime Network Registrar) will do this if steps are taken to
> “invalidate” a lease.
> 
>  
> 

Doesn't the above imply that the client remembers the addresses?

---

From: Fernando Gont <[email-masked]>
Date: Thu, 31 Oct 2019 16:58:32 -0300

On 27/10/19 19:52, Ole Troan wrote:
>>>> Note that we could change SLAAC to allow the lifetime of a
>>>> prefix to be set to zero, instead of having to wait for 2
>>>> hours. That might be an improvement but requires careful
>>>> analsysis.
>>> 
>> Could you be more specific what you consider a 'public service' and
>> what you expect to break?
> 

That's know how IPv6 is being deployed in many places. It's quite common
that the CPE implements a Diode firewall. And what's worse, the CPE
doesn't have the appropriate support in UPnP for punching holes in it.

> in the current Internet.

Isn't that how/why Google, Facebook, and others make money?

> All of those have great open source software. To use Owen's
> paragraph: "I don’t know of a single server which operates that way
> currently. Can you point to a working example?"
> 

I'm not saying you don't raise a valid question. However, in the context
of this discussion there's a difference between being able to graceully
handle the scenario when it happens, vs planning for it to happen
deterministically.

(FWIW, I have a bunch of services running behind NATs, where the
addresses get rotated. Yes, I do use small lifetimes (< 1 minute).
That's not uncommon nowadays, anyway)

>> What I described is basically what happens on IPv4 when a CPE uses
>> NAT and gets a new IPv4 address from the ISP.
> 

IPv6 could allow you to host services in a better way.

(In my example above, I just *can't* leverage IPv6 because of the
firewall and CPEs with no UPnP support for IPv6)

>> Flash renumbering is far from ideal, but a reality on the current
>> internet. Any application that is suitable for home use is expected
>> to deal with that scenario.
> 

We need IPv6 to actually work. There are networks nowadays in which it
is breaking badly. IN some cases it's preventing deployment. In others,
users are falling back to IPv4.

> 
>> Note that with automatic DNS updates, you can probably run a mail
>> server (or your personal 'cloud') on such a link. But that is not a
>> common use case at the moment.
> 

The benefits are in global addressing. As noted abouve, there are many
scenarios where "global connectivity" is worse for IPv6. Not that I like
it (but that doesn't change facts).

P.S.: I reiterate that the home network/cpe case is only *one* of the
scenarios where this problem may be faced.

Thanks,

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 31 Oct 2019 20:26:22 +0000

> Doesn't the above imply that the client remembers the addresses?

You are quoting from section 18.3.4 which is Renew processing.

There is no requirement as far as I recall in RFC8415 that requires a client to remember anything across a reboot.

And in most cases, there are no issues because the client will get the same lease (and in many cases with proper renumbering), the server should provide both the old and new leases.

It would be nice to better understand exactly what SPs are doing at their end to cause the issues with servers where they are not providing for graceful renumbering (when the CPE is rebooted to either trigger the renumbering or during the renumbering). Or is this an issue with the server they are using (whether a limitation, bug, or possibly broken feature [in this use case]).

Certainly if the SP removes the "old" prefix from the configuration and replaces with a new, that would mean that the old lease is likely "gone" and hence cannot be provided. But that's really not graceful renumbering.

- Bernie

-----Original Message-----
From: Fernando Gont <[email-masked]> 
Sent: Thursday, October 31, 2019 3:48 PM
To: Bernie Volz (volz) <[email-masked]>; Owen DeLong <[email-masked]>; Ted Lemon <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] SLAAC renum: Problem Statement & Operational workarounds

On 27/10/19 19:03, Bernie Volz (volz) wrote:
> That is actually the RFC8415 specified behavior … the DHCP server I 
> work on (Cisco Prime Network Registrar) will do this if steps are 
> taken to “invalidate” a lease.
> 
>  
>

---

From: Owen DeLong <[email-masked]>
Date: Thu, 31 Oct 2019 12:38:04 -0700

> On Oct 31, 2019, at 12:21 PM, Fernando Gont <[email-masked]> wrote:
> 
> Hello, Ted,
> 
> 

Considering these mutually exclusive is a false dichotomy.

It did both.

>> is that TCP connections should be timing out.   This doesn’t take

Somewhat variable, but yes, can be as long as ~15 minutes in some cases.

> But robustness cannot rely on any of these specific bits.

Perhaps not, but this is the lowest hanging fruit and the cleanest set of changes.

Certainly you have to admit that the proposed CPE changes would yield the greatest improvement
in robustness at the lowest cost of any of the proposed solutions in the I-D in question.

> trust the local router to configure your network, but not for

Trusting the local router to configure the network to add a previously non-operational host to the network has a somewhat different set of consequence for failure than trusting whatever on-link host wishes to tell you to effectively shut down your currently operating network connection.

Especially when you consider that such an announcement can be sent to the all nodes on link multicast address, effectively dropping them all at once.

I agree it’s not a huge difference, but, it is a difference and certainly the scope of the resulting problem can be much larger than the case of individual host configuration.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 31 Oct 2019 12:58:00 -0700

> On Oct 31, 2019, at 12:49 PM, Ted Lemon <[email-masked]> wrote:
> 
> On Oct 31, 2019, at 3:47 PM, Owen DeLong <[email-masked] <mailto:[email-masked]>> wrote:
Huh?

How’s that?

If I have two default uplink ports on a switch and the default configuration on the switch is that those are the “router” ports and everything else is treated as a “host” port for RA Guard on by default, how does that render anything “impossible”?

If you don’t want RA Guard, turn it off. It’s just a default setting.

If you want a different RA Guard configuration, the set it as you like.

I’m not proposing hard-coding anything. I’m proposing an RA-Guard friendly set of defaults that actually solve a common security problem in administrator-less networks, whether they’ve suffered from it yet or not.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 31 Oct 2019 12:47:42 -0700

> On Oct 31, 2019, at 12:34 PM, Ted Lemon <[email-masked]> wrote:
> 
> On Oct 31, 2019, at 3:21 PM, Fernando Gont <[email-masked] <mailto:[email-masked]>> wrote:

That’s for the three-way handshake… For an existing established flow, it can be much MUCH longer.

> Okay, there’s something to fix.  Why would these not affect source address selection?

Because there are other things that do which are much better reasons for address selection.

There are enough problems with address selection (especially on platforms like MacOS
where they’ve chosen to eliminate the ability to configure SAS) as it is. Adding this as an
additional variable (let alone making it override the other tie-breakers) is not, IMHO, an
actual improvement.

>> you enforce FHS, or you don't.

First Hop Security (e.g. RA Guard, SEND, etc.)

> Right, but if the effort involved in two different options differs by epsilon, you should always choose the option that produces the better outcome, shouldn’t you?

Yes, but the better outcome must be defined not only in terms of the ideal end result if/when implemented, but also in terms of the probability of widespread implementation and the time delay between now and said wide deployment.

> On a network that supports RA guard, there probably is no difference, but RA guard on some networks, as we’ve discussed in the past, will actually make the network not work.   RA guard requires an…

RA Guard as implemented today in most existing platforms requires an active administrator.

> In the non-SEND trust model, you trust the local network.   You hope that the RA you get “from the router” is actually from the router.

That doesn’t answer the question. It merely describes the model. The question was why is bind trust in a prefix deprecation message any worse than blind trust in a network configuration message.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 31 Oct 2019 12:50:03 -0700

> On Oct 31, 2019, at 12:43 PM, Fernando Gont <[email-masked]> wrote:
> 

I’ve looked at what it takes to deploy SEND and I’ve met some of the people
that support the networks in places like McDonald’s and Starbucks…

I’m thinking that successful, reliable FHS in those environments is a rather
humorous concept.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 31 Oct 2019 12:39:35 -0700

> On Oct 31, 2019, at 12:25 PM, Fernando Gont <[email-masked]> wrote:
> 

IMHO, the CPE requirements should be increased and the CPE should be required
to store the prefix and it’s expected valid and preferred expiration times in persistent
storage. I would like to see the text in the I-D updated accordingly.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Thu, 31 Oct 2019 12:54:47 -0700

> On Oct 31, 2019, at 12:47 PM, Ted Lemon <[email-masked]> wrote:
> 
> On Oct 31, 2019, at 3:41 PM, Fernando Gont <[email-masked] <mailto:[email-masked]>> wrote:

There are a variety of attacks in Fernando’s documentation which do not require large numbers of Gas.

A few multicast RAs well timed can, for example, change everyone’s default gateway for MITM games.

Another thing you often seem to miss, Ted, is that not everyone’s environment is necessarily similar to yours.

When developing I-Ds and RFCs, care must be taken to consider that the internet is an extremely diverse set of networks in an even more diverse set of environments.

Owen

---

From: Mark Smith <[email-masked]>
Date: Fri, 1 Nov 2019 11:20:27 +1100

On Fri, 1 Nov 2019, 06:34 Ted Lemon, <[email-masked]> wrote:

> Don’t get me wrong—I’m not saying we shouldn’t do things to improve the
> situation.   I am saying that we should be strategic about it.
>

You've got no more than 10 seconds unless you want end users to actively
try to do something to recover, which can include calling their ISP's
helpdesk.

A short presentation on some user experience factors for network engineers.

"A bit of UX for NEs"
https://www.slideshare.net/markzzzsmith/ausnog-2019-lightning-talk-a-bit-of-ux-for-nes

> Right, but if the effort involved in two different options differs by
> epsilon, you should always choose the option that produces the better
> outcome, shouldn’t you?
>
> On a network that supports RA guard, there probably is no difference, but
> RA guard on some networks, as we’ve discussed in the past, will actually
> make the network not work.   RA guard requires an active administrator.
> So the CPE case we’re talking about isn’t relevant.
>
>
> In the non-SEND trust model, you trust the local network.   You *hope* that
> the RA you get “from the router” is actually from the router.
>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 31 Oct 2019 23:04:47 -0300

Hello, Owen,

On 31/10/19 16:27, Owen DeLong wrote:
[....]
> for my lack of clarity as you have apparently interpreted it differently.

Ok. BUt, double-checking: DO you agree with the proposed behaviour?

[....]
> utilizing the most recently received timer refreshes.

Thanks for the feedback! I will definitely clarify the text. FWIW, in
the context of RFC8028, you already need to keep prefixes associated
with routers....

> case of a resource-constrained host which is using SLAAC to avoid the overhead

In the context of RFC8028, you don't have much of an option -- otherwise
you run the risk of being egress filtered.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 31 Oct 2019 23:27:19 -0300

> situation.   I am saying that we should be strategic about it.

For the home network case, the situation right now is that there are
deployments that break, and ISPs meaning to deploy IPv6 that can't do
stable prefixes. Certainly, that's a very bad strategy on our side.

That said, and as noted, the home network case is just *one* scenario
where this problem may be faced. And a subset of the mitigations for
this scenarios are useful for the general case.

>>> is that TCP connections should be timing out.   This doesn’t take

Nope. The default user timeout is 5 minutes as per RFC793. (The first
para of the second page of RFC5482 provides a summary wrt the
specification of the user timeout).

> Okay, there’s something to fix.  Why would these not affect source

For many reasons: one of them: two different routers might be using
different values for these timers, in an un-coordinated manner. And
there's not reason for which the smaller or larger lifetimes should
imply an address is preferred.

OTOH, you might thing about preferring "the last advertised prefix". BUt
that would mean that src address would flap, which is bad for
trouble-shooting.

>> you enforce FHS, or you don't.

Sorry, for that: First Hop Security, Cisco's speak for RA-Guard, ND
inspeaction, and so on...

> epsilon, you should always choose the option that produces the better

Is there any of the proposed fixes that we shouldn't be doing, already,
anyway?

> On a network that supports RA guard, there probably is no difference,
> but RA guard on some networks, as we’ve discussed in the past, will
> actually make the network not work.   RA guard requires an active
> administrator.   So the CPE case we’re talking about isn’t relevant.

The point is: in a network where you do not employ RA-Guard, you are
already trusting the router. Actually, it's worse: you trust all local
systems.

> In the non-SEND trust model, you trust the local network.   You
> /hope/ that the RA you get “from the router” is actually from the router.

Exactly: that's the point: you already trust the local network. What's
the rationale for trusting one of the RAs, but not the others?

---

From: Fernando Gont <[email-masked]>
Date: Fri, 1 Nov 2019 00:02:30 -0300

> Considering these mutually exclusive is a false dichotomy.

It's hard for me to believe that folks were breaking stuff on purpose.

In any case, I would assume and expect that helping IPv6 deployment was
more of a priority at the time. IN fact, we wouldn't be talking about
"google seeing 25% of IPv6" if there wasn't a way to circumvent
brokenness, I'd assume.

[...]
> Trusting the local router to configure the network to add a previously non-operational host to the network has a somewhat different set of consequence for failure than trusting whatever on-link hos…

We'll that's the SLAAC model.

> I agree it’s not a huge difference, but, it is a difference and certainly the scope of the resulting problem can be much larger than the case of individual host configuration.

Hosts trust a lot of other crap. e.g., feel free to advertising a Cur
Hop Limit of 1. Is that any different?

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 1 Nov 2019 00:06:56 -0300

> storage. I would like to see the text in the I-D updated accordingly.

It's already there (draft-gont-v6ops-slaac-renum-00):

3.2.1.  Signaling Stale Configuration Information

   In order to phase-out stale configuration information:

   o  A CPE router sending RAs that advertise dynamically-learned
      prefixes (e.g. via DHCPv6-PD) on an interface MUST record, on
      stable storage, the list of prefixes being advertised on each
      network segment.

Thanks!

Cheers,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 1 Nov 2019 00:11:23 -0300

On 31/10/19 16:47, Ted Lemon wrote:
> As an end user, I don’t have this experience.   If someone is spamming
> my network with RAs, I can find out who and disconnect them.   A DoS
> attack based on massive quantities of RAs is a lot different than an
> attack that shuts my network off with one multicast. 

Meta:
The regular non-technical user has no clue about RAs or the like. So,
the network works, or it doesn't. Normally, if things do not work, thye
will unplug and re-plug the router, ironically triggering this problem
in many cases.

That said: There are plenty of one-plenty of one-packet DoS vectors in
SLAAC. e.g., sen an RA with a Cur Hop Limit of 0, send an RA that
advertises a default router with highes priority, or simply advertise
RIOs as ::/1 and 8000::/1, overriding default routers.

Any clueful attacker will use any that works, rather than sticking to a
specific one.

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 1 Nov 2019 00:13:29 -0300

On 31/10/19 16:49, Ted Lemon wrote:
>> RA Guard could be default configured on switches with particular
>> default “plug router in here” (uplink) ports, eliminating the need for
>> an active administrator. This could be a useful specification in the
>> HomeNet documents, perhaps.
> 
> This would be disastrous.   It pretty much makes permissionless
> networking impossible in exchange for solving a security problem no-one has.

Then, what's the big deal to honor PIOs that advertise a lifetime of 0? ;-)

---

From: Fernando Gont <[email-masked]>
Date: Fri, 1 Nov 2019 00:18:40 -0300

On 31/10/19 21:20, Mark Smith wrote:
> 
> 
> On Fri, 1 Nov 2019, 06:34 Ted Lemon, <[email-masked]
>     Don’t get me wrong—I’m not saying we shouldn’t do things to improve
>     the situation.   I am saying that we should be strategic about it.
> 

I'd argue the opposite. But, anyway, for the most part the user timeout
is not under the control of the user.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 1 Nov 2019 00:28:30 -0300

> The point here is that we as the IETF must also consider the end-user here. Not that I don't think ISPs do that too, but so far this debate has largely been on the premise of the opertor with littl…

No, that's in correct. This document was, in fact, triggered by an
operator that does care.

And both here and on the ipv6-ops there have been statements noting that
they have these scenarios in their networks. And not because they don't
care about their users.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 1 Nov 2019 00:31:10 -0300

> There are not many sensible responses the end-users can come up with to a service provider with a network behaving this way, apart from isolating addressing. Aka NAT.

We did in fact propose several. (draft-gont-6man-slaac-renum).

It would be amusing for v6ops' response to this case that folks should
be doing NAT.

---

From: Mark Smith <[email-masked]>
Date: Fri, 1 Nov 2019 17:49:17 +1100

On Fri, 1 Nov 2019, 14:31 Fernando Gont, <[email-masked]> wrote:

> I'd argue the opposite..

I wouldn't argue with research from 1968, referenced in an article from
1993, by an expert in usability, cited in my slides.

Response Times: The 3 Important Limits
https://www.nngroup.com/articles/response-times-3-important-limits/

But, anyway, for the most part the user timeout
> is not under the control of the user.

I don't understand this.

It not being in control of the user is the point of knowing UX/HCI factors
so the good default response times can be chosen.

TCP's default timeouts are way too large for a good end user experience. I
don't know what criteria were used to select them, but it certainly wasn't
human usability factors.