Subject: [homenet] Orchestration of renumbering

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Mar 2015 08:00:14 +1300

As I said at the microphone today, I think that the explanations of
how the prefix-assignment and naming proposals will handle renumbering
are convincing. I also agree that there is no real distinction between
renumbering and a change of ISP (as far as prefixes and addresses are
concerned, of course), and that break-before-make renumbering could
come at any time due to an outage or ISP behaviour. Make-before-break
renumbering (a.k.a. planned renumbering) is preferable but we can't
rely on it. (I also try to never forget Fred Baker's observation that
there is no such thing as renumbering: there is only numbering.)

However, I am fairly convinced that this is not the whole story and that
in the ideal world some sort of orchestration process is needed. I did
look through the issues in RFC 7010 and RFC 5887, and fortunately most
of them are beside the point for homenets. However, Dave Taht told us
recently that renumbering *is* currently broken, and I'd like to see his
list of issues. For now, here are the issues that I see:

0. Make sure that nobody ever even thinks about configuring
an IPv6 address manually (unless it's link-local, I suppose).

1. Warn users that renumbering is planned/has started.
(because long-living sessions will be affected, even in make-before-break)

2. We assume that a prefix delegation or withdrawal from above
by DHCPv6-PD will trigger the appropriate actions by
draft-ietf-homenet-prefix-assignment. But I can't tell from the draft
how that happens. Presumably some process in the relevant CPE does it.

3. We also assume that a delegation or withdrawal will trigger the
appropriate action according to the future renumbering text in
the naming-architecture documents. Daniel's draft text says "This section
details how the CPE is expected to handle renumbering..."
Indeed, that is part of the orchestration process, but something
in the CPE is needed to trigger this (after triggering the PA process).

4. Hosts need new DNS server addresses. I'm not sure who causes
that to happen.

5. There may be unavoidable special cases (like informing firewalls
of new and deleted prefixes).

99. Inform users that renumbering has finished.

   Brian

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 24 Mar 2015 14:09:41 -0500

> On 24.3.2015, at 14.00, Brian E Carpenter <[email-masked]> wrote:

I am not sure this is really useful - ‘red alert, ISP is about to renumber!’? Although, for _general IPv6 case_, perhaps some advanced^2 IPv6 socket API might have notification on this as well as e.g. missing lifetime information from address information etc.

Speaking of which, cross-platform IPv6 APIs are trainwreck currently if you care about e.g. preferred+valid lifetimes of addresses.

> how that happens. Presumably some process in the relevant CPE does it.

Final withdrawal should just remove the DP (=‘remove ISP’). Before that, new DP with better pref value should be available..

> 4. Hosts need new DNS server addresses. I'm not sure who causes

If they happen to support reconfigure, we could push it over that. It can also come via RA, or plain old DHCP will work (because it is NATted address and not affected by renumberings). I guess DHCPv6 without reconfigure can be considered harmful in this case..

(Or we could just give ULA address of the first-hop router always, and not renumber the ULA. *wink*)

Cheers,

-Markus

---

From: JF Tremblay <[email-masked]>
Date: Tue, 24 Mar 2015 14:47:41 -0500

> On Mar 24, 2015, at 2:00 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> [...] Make-before-break

Any reference for reading (on Fred’s principle)?

> [...] However, Dave Taht told us

I’ll let Dave answer for himself, but my personal experience at home currently is that it breaks quite often. As soon as the home network gets renumbered, new RAs are flooded, but no RAs are sent to de-prefer the current prefix (as specified in RFC7084 L-13). I’ve seen this happen both with 6RD and in native, with two home router vendors. I usually flap my link physically to flush old addresses. 

Btw, I didn’t raise this morning, but I believe smooth renumbering from an ISP is possible, at least for cable ISPs (costly, but possible). This requires support for multiple concurrent prefix delegations on home routers, which I haven’t seen yet in the wild. This requirement isn’t explicitly mentioned in RFC7084, only indirectly through the support for DHCPv6-PD (WPD-1). 

So on the short term, proper implementation of RFC7084 L-13 is required for smoother unplanned renumbering. For smooth planned renumbering, support for multiple concurrent PDs is required. It’s too bad that the homenet architecture doc (RFC7368 section 3.4.1) does not even mentions this possibility. 

JF

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Mar 2015 15:01:18 +1300

> Any reference for reading (on Fred’s principle)?

I'm not aware of a written version; it's something I've heard him say
more than once. Of course there is RFC 4192, but it isn't in that.

     Brian

---

From: Tim Chown <[email-masked]>
Date: Wed, 25 Mar 2015 10:18:51 +0000

> On 25 Mar 2015, at 02:01, Brian E Carpenter <[email-masked]> wrote:
> 

And it’s very true. A point made several times through 6renum’s lifetime.

For one, it’s in the introduction here:
https://tools.ietf.org/html/draft-baker-6renum-oss-renumbering-00 <https://tools.ietf.org/html/draft-baker-6renum-oss-renumbering-00>

Tim

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 25 Mar 2015 15:20:33 +0100 (CET)

On Wed, 25 Mar 2015, Brian E Carpenter wrote:

> 2. We assume that a prefix delegation or withdrawal from above by 
> DHCPv6-PD will trigger the appropriate actions by 

At this time, I do not understand the DHCPv6-PD state machinery to enable 
temporal overlap of prefixes so one can achieve a graceful renumbering 
event. I wrote this text a while back but never sent it to DHC. Could 
someone please help by explaining how to do this temporal overlap using 
DHCPv6-PD?

Hi,

For several reasons, there is a need to have overlapping IPv6 addressing 
space, both delegated to devices (PD) or addresses (IA_NA), when doing 
graceful renumbering. Let's take the following network:

ISP - CPE - HOST1

The CPE requests a prefix using PD, and is delegated 
2001:DB8:100:100::/56. it then configures 2001:DB8:100:101::X/64 on its 
LAN interface. HOST1 uses DHCPv6 and asks for IA_NA and is assigned 
2001:DB8:100:101::Y/128
IA_NA by CPE.

Now, after a while, the customer decides he wants to change the addressing 
space, but he wants to do this gracefully, basically along the lines of 
RFC4192. So for a certain amount of time, he wants to have two PDs,
and these need to be distinct.

What would need to happen, is that the customer needs to signal to the ISP 
that he needs a second PD, that this should be distinct from the first 
one, and that he wants to keep both for a certain amount of time, but
understands that the initial PD is not going to be refreshed/extended in 
time and will be removed.

What needs to happen is that the CPE needs to get a new /60, it needs to 
allocate a /64 out of this in addition to the existing /64, HOST1 needs to 
understand that it should ask for a new IA_NA and that it should stop
using the existing IA_NA for new connections. I don't know if this 
automatically happens if the RA for the old prefix shows up with a lower 
preferred timer set.

So there are two issues here (I guess):

How can the CPE indicate that it doesn't want the original prefix any 
more, request a new one, and let old one expire after a period of overlap?

How will HOST1 understand that it needs to request a new IA_NA while still 
keeping the old IA_NA until it expires, and de-preferring the old IA_NA in 
the meantime?

Also, how can the ISP initiate this kind of graceful renumbering event? 
The only way I can think of would be some kind of intent flag to say "the 
lease time of this resource will not be extended and you should ask for
a new one" or something to that effect.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: JF Tremblay <[email-masked]>
Date: Wed, 25 Mar 2015 10:57:20 -0500

Thanks for the pointer to draft-baker-6renum-oss-renumbering, Tim. It’s true that renumbering is only a sequence of numbering actions. 

> On Mar 25, 2015, at 9:20 AM, Mikael Abrahamsson <[email-masked]> wrote:

> At this time, I do not understand the DHCPv6-PD state machinery to enable temporal overlap of prefixes so one can achieve a graceful renumbering event. I wrote this text a while back but never sent it to DHC. Could someone please help by explaining how to do this temporal overlap using DHCPv6-PD?

I can take a shot at this. I’ve done it in a production-like lab with cable equipment. I believe it was with an experimental OpenWRT or D-Link that supported dual-PD.  

> Now, after a while, the customer decides he wants to change the addressing space, but he wants to do this gracefully, basically along the lines of RFC4192. So for a certain amount of time, he wants to have two PDs,

This is where your example stops working. At “the customer decides”. IMHO there’s no way to make this work purely as a customer-triggered sequence of event. 

Actually, why would the customer trigger this? Is there a good use case for this? In my mind, this is purely triggered from the ISP side, when a network event is planned to happen.

Here’s a cable-oriented scenario (sorry, this is my background). In the cable world, providing a perfectly stable prefix for home customers is quite challenging, because the underlying physical network changes on a regular basis to accommodate physical network growth and changes (usually once or twice a year per user). It’s possible to provide stable prefixes, but it involves significant engineering and operational effort (hence a cost). 

An alternative for cable operators is to provide smooth IPv6 renumbering. Here’s how it could work. This is basically a simpler flavor of RFC4192. 
1. The customer gets PD1 from CMTS A. (a /56 out a /40 for example). Stable operation. 
2. A week in advance of a network change, a move from CMTS A to CMTS B, the customer gets a reduced DHCPv6 lease time to 24h. 
3. 24h before the change, the client gets two prefixes PD1 and PD2, out of A and B /40s respectively. PD1 has a preferred lifetime of 0 and a valid lifetime of 24h.
    At this point, clients start using PD2 gradually as leases expire and get renewed. The number of disjoint routes in the ISP network raises (deaggregation happens)
4. The change is made overnight. At this point, all clients should already be using PD2.
5. Most clients will redo DHCPv6 (depending if they saw a link-down event, ymmv). 
    PD2 is used everywhere and get re-aggregated in the original /40. 
    PD1 should no longer be used, but is still routed (through B) and deaggregated. 
6. PD1 is removed on the DHCPv6 server and lease time restored to its original value. 
    After another 24h, PD1 is no longer present in home networks, no longer routed and no deaggregation remains. 

The only missing part to make this happen is for home routers to support multiple PDs. The specific DHCPv6 servers and CMTSes implementations I used already supported multi-PD years ago. The big advantage of this for cable operators is to keep user routes aggregated.

JF

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 25 Mar 2015 17:15:32 +0100 (CET)

On Wed, 25 Mar 2015, JF Tremblay wrote:

> Actually, why would the customer trigger this? Is there a good use case 
> for this? In my mind, this is purely triggered from the ISP side, when a 
> network event is planned to happen.

Because some customers feel that changing addresses is a privacy thing. 
They might want their ISP to provide a CPE with a button that says "change 
home prefix now".

> 3. 24h before the change, the client gets two prefixes PD1 and PD2, out of A and B /40s respectively. PD1 has a preferred lifetime of 0 and a valid lifetime of 24h.

How does it "get" PD2? This is what I don't understand. You just all of a 
sudden next time the DHCPv6-PD communication happens, send two prefixes 
and then the client will accept these and start using them? The home 
gateway doesn't actually have to ask for it, you can just send it a bunch 
of prefixes?

---

From: Steven Barth <[email-masked]>
Date: Wed, 25 Mar 2015 11:23:05 -0500

>gateway doesn't actually have to ask for it, you can just send it a

In general the cpe asks for an "identity association for prefix delegation" (ia_pd). The server can include as many prefixes with individual lifetimes into that ia_pd as it likes.

Taking 6204 / 7084 into account the cpe even must support dynamic reconfiguration meaning the server can at any point in time tell the client to renew and doesn't need to wait for a renew.

That all of course is given compliant cpes...

Cheers, 

Steven

---

From: Timothy Winters <[email-masked]>
Date: Wed, 25 Mar 2015 12:26:37 -0400

Hi,
	For the IPv6 Ready/UNH-IOL testing that we have done, both an Interoperability and Conformance, there is a test  makes sure a Router supports getting multiple IA_PDs for Prefix Change.

~Tim

> On Mar 25, 2015, at 12:23 PM, Steven Barth <[email-masked]> wrote:
> 
> 
> 
>

---

From: Ian Farrer <[email-masked]>
Date: Wed, 25 Mar 2015 11:31:06 -0500

Hi,

> Actually, why would the customer trigger this? Is there a good use case for this? In my mind, this is purely triggered from the ISP side, when a network event is planned to happen.

In some countries (e.g. Germany), operators provide customer’s with the ability to request a change of IP address via a reset button in the web interface of the HGW. This is based on privacy requirements (which seem dated, but exist).

Ian

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 25 Mar 2015 11:31:20 -0500

Le 24/03/2015 21:01, Brian E Carpenter a écrit :
>>> [...] Make-before-break renumbering (a.k.a. planned renumbering)
>>> is preferable but we can't rely on it. (I also try to never
>>> forget Fred Baker's observation that there is no such thing as
>>> renumbering: there is only numbering.)
>>
> I'm not aware of a written version; it's something I've heard him
> say more than once. Of course there is RFC 4192, but it isn't in
> that.

Not sure what the question was but there is a stds track RFC in the 
2000s about IPv6 router renumbering, authored at Fermilab IIRC.

That has a notion of difference between numbering and renumbering.

Numbering is the initial assignment of prefixes on links.  Presumably a 
manual operation.

Re-numbering is propagation of tuples [existing prefix, new prefix] with 
RAs messages between routers.

This technique was used by other protocols such as Hierarchical Mobile 
IPv6 which is an RFC as well, although experimental IIRC.

This of course brings the question of what is renumbering.

Alex

>
> Brian
>>
>>> [...] However, Dave Taht told us recently that renumbering *is*
>>> currently broken, and I'd like to see his list of issues. For
>>> now, here are the issues that I see:
>>
>> I’ll let Dave answer for himself, but my personal experience at
>> home currently is that it breaks quite often. As soon as the home
>> network gets renumbered, new RAs are flooded, but no RAs are sent
>> to de-prefer the current prefix (as specified in RFC7084 L-13).
>> I’ve seen this happen both with 6RD and in native, with two home
>> router vendors. I usually flap my link physically to flush old
>> addresses.
>>
>> Btw, I didn’t raise this morning, but I believe smooth renumbering
>> from an ISP is possible, at least for cable ISPs (costly, but
>> possible). This requires support for multiple concurrent prefix
>> delegations on home routers, which I haven’t seen yet in the wild.
>> This requirement isn’t explicitly mentioned in RFC7084, only
>> indirectly through the support for DHCPv6-PD (WPD-1).
>>
>> So on the short term, proper implementation of RFC7084 L-13 is
>> required for smoother unplanned renumbering. For smooth planned
>> renumbering, support for multiple concurrent PDs is required. It’s
>> too bad that the homenet architecture doc (RFC7368 section 3.4.1)
>> does not even mentions this possibility.
>>
>> JF
>>
>>
>>
>>
>>
>
> _______________________________________________ homenet mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/homenet
>

---

From: JF Tremblay <[email-masked]>
Date: Wed, 25 Mar 2015 11:35:24 -0500

> On Mar 25, 2015, at 11:15 AM, Mikael Abrahamsson <[email-masked]> wrote:
> 
> Because some customers feel that changing addresses is a privacy thing. They might want their ISP to provide a CPE with a button that says "change home prefix now”.

Wasn’t aware of that need. One way to make this happen would be for the CPE to reset its DUID. But it’s no longer smooth renumbering, the prefix will simply change. In this case however, this is a user-triggered action, so immediate renumbering might be acceptable. Support for RFC7084 L-13 would be desirable. 

> How does it "get" PD2? This is what I don't understand. You just all of a sudden next time the DHCPv6-PD communication happens, send two prefixes and then the client will accept these and start using them? The home gateway doesn't actually have to ask for it, you can just send it a bunch of prefixes?

You just configure it in the DHCPv6 server, usually through a script. Same for changing lease lifetime values. Ops people do this on a regular basis. 

JF

---

From: JF Tremblay <[email-masked]>
Date: Wed, 25 Mar 2015 11:37:51 -0500

> On Mar 25, 2015, at 11:26 AM, Timothy Winters <[email-masked]> wrote:
> 
> Hi,

Thanks Tim. 

Two questions: 
1. Can you share any data on how often this requirement was met or not? (like a % of tested routers)
2. Do you also test for L-13? And is that one usually met?

JF

---

From: Ted Lemon <[email-masked]>
Date: Wed, 25 Mar 2015 12:43:30 -0500

> Wasn’t aware of that need. One way to make this happen would be for the CPE to reset its DUID. But it’s no longer smooth renumbering, the prefix will simply change. In this case however, this is a…

Ideally the DHCP client generates a new DUID and does not send the old DUID.   This allows for graceful renumbering, since the old prefix is still valid until it expires.

---

From: Steven Barth <[email-masked]>
Date: Wed, 25 Mar 2015 18:46:51 +0100

> Ideally the DHCP client generates a new DUID and does not send the old DUID.   This allows for graceful renumbering, since the old prefix is still valid until it expires.

Ideally it could use the same DUID and just switch to a different IAID 
for its IA_PD or even keep asking for two IA_PDs with different IAIDs at 
the same time.

---

From: Timothy Winters <[email-masked]>
Date: Wed, 25 Mar 2015 14:13:59 -0400

Hello,

> On Mar 25, 2015, at 12:37 PM, JF Tremblay <[email-masked]> wrote:
> 
> 
Currently we have about 15 to 20 implementations at the IOL that are trying to meet the 7084 Requirements, including L-13.   Most routers address issues when they are made aware of the problem.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 25 Mar 2015 13:24:03 -0500

On Mar 25, 2015, at 12:46 PM, Steven Barth <[email-masked]> wrote:
> Ideally it could use the same DUID and just switch to a different IAID for its IA_PD or even keep asking for two IA_PDs with different IAIDs at the same time.

Right, sorry, I misspoke.   Thanks for the correction!   :)

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 25 Mar 2015 18:27:34 +0000

> >> Wasn't aware of that need. One way to make this happen would be for
> the CPE to reset its DUID. But it's no longer smooth renumbering, the prefix
> will simply change. In this case however, this is a user-triggered action, so
> immediate renumbering might be acceptable. Support for RFC7084 L-13
> would be desirable.
> > Ideally the DHCP client generates a new DUID and does not send the old
> DUID.   This allows for graceful renumbering, since the old prefix is still valid
> until it expires.
> 
> Ideally it could use the same DUID and just switch to a different IAID for its
> IA_PD or even keep asking for two IA_PDs with different IAIDs at the same
> time.

FYI. RFC 7084 has the following:

   W-5:  The IPv6 CE router MUST use a persistent DHCP Unique Identifier
         (DUID) for DHCPv6 messages.  The DUID MUST NOT change between
         network-interface resets or IPv6 CE router reboots.

This requirement exists because CE routers that changed their DUIDs experienced issues in certain access architectures.
Barbara

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Mar 2015 07:46:36 +1300

> In some countries (e.g. Germany), operators provide customer’s with the ability to request a change of IP address via a reset button in the web interface of the HGW. This is based on privacy requir…

But presumably, that is only a *request* from the CPE side - the real
action is started by the provider edge.

   Brian

---

From: Ted Lemon <[email-masked]>
Date: Wed, 25 Mar 2015 13:47:09 -0500

> This requirement exists because CE routers that changed their DUIDs experienced issues in certain access architectures.

Yup.   Are you aware of similar issues with changing the IAID?   If the ISP has a limit to how many prefixes can be assigned on a particular customer port, that could cause issues, but if it's a supported feature as it would be in Mikael's case, I think it should be OK.   Do you know the details of what was causing the issue?

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Mar 2015 07:50:03 +1300

Regards
   Brian Carpenter
   http://orcid.org/0000-0001-7924-6182

On 26/03/2015 05:31, Alexandru Petrescu wrote:
> Not sure what the question was but there is a stds track RFC in the 2000s about IPv6 router renumbering, authored at Fermilab IIRC.

You mean RFC 2894, I think.

As is written in RFC 5887:
  "An ICMPv6 extension to allow router renumbering for IPv6 is specified
   in [RFC2894], but there appears to be little experience with it.  It
   is not mentioned as a useful mechanism by [RFC4192]."

     Brian

> Numbering is the initial assignment of prefixes on links.  Presumably a manual operation.
> 
> Re-numbering is propagation of tuples [existing prefix, new prefix] with RAs messages between routers.
> 
> This technique was used by other protocols such as Hierarchical Mobile IPv6 which is an RFC as well, although experimental IIRC.
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 25 Mar 2015 19:17:36 +0000

> Yup.   Are you aware of similar issues with changing the IAID?   If the ISP has a
> limit to how many prefixes can be assigned on a particular customer port,
> that could cause issues, but if it's a supported feature as it would be in
> Mikael's case, I think it should be OK.   Do you know the details of what was
> causing the issue?

I don't remember the details. I looked at BBF TR-124, to see if there was something similar there, and there wasn't. Then I looked at eRouter specs, and did see that they are specifically re-iterating the requirement for persistence. So maybe it came from the cable companies. Which could explain why my memory of details is so fuzzy.

As for IAID, TR-124 says:
"The RG IAID value in DHCPv4 and DHCPv6 MUST be a 32 bit number encoded in network byte order. In cases where the RG is functioning with a single DHCP client identity, it MUST use value 1 for IAID for all DHCP interactions. IAID is defined in IETF RFC 3315.
In cases where the RG is functioning with multiple DHCP client identities, the values of IAID have to start at 1 for the first identity and be incremented for each subsequent identity. The RG's mapping of IAID to its physical aspects or logical configuration SHOULD be as non-volatile as possible. For example, the RG MAY use IAID value 1 for the first physical interface and value 2 for the second. Alternatively, the RG MAY use IAID value 1 for the virtual circuit corresponding to the first connection object in the data model and value 2 for the second connection object in the data model."

The TR-124 requirements are used by DSL providers for the CE routers they procure/provide, and aren't expected to apply to "retail" CE routers. The fact that this IAID requirement didn't make it into RFC 7084 leads me to believe that the behavior of retail CE routers wrt IAID is a "don't care".
Barbara

---

From: JF Tremblay <[email-masked]>
Date: Wed, 25 Mar 2015 14:44:19 -0500

> On Mar 25, 2015, at 2:17 PM, STARK, BARBARA H <[email-masked]> wrote:
> 

Yes, it’s very probably coming from the cable side. The first generations of cable modems and eRouters firmware sometimes used non-persistent DUID-LLTs changing at each reboot. We had also seen it from early “retail” CPEs.  It was annoying enough that the persistence requirement was reiterated in some documents.

> The TR-124 requirements are used by DSL providers for the CE routers they procure/provide, and aren't expected to apply to "retail" CE routers. The fact that this IAID requirement didn't make it into RFC 7084 leads me to believe that the behavior of retail CE routers wrt IAID is a "don't care”.

Thanks for checking. Changing the IAID might indeed be a good way to implement the “reset privacy” button. Not sure if this should be added to any specifications and which ones. Is this just a regional regulatory requirement? Looks like there isn’t any action for the IETF to take here. 

JF

---

From: Ted Lemon <[email-masked]>
Date: Wed, 25 Mar 2015 15:56:58 -0500

> Thanks for checking. Changing the IAID might indeed be a good way to implement the “reset privacy” button. Not sure if this should be added to any specifications and which ones. Is this just a regi…

The DHC working group could reasonably document this as a profile.   Or v6ops.   It's apparently non-obvious or nobody would have asked about it, so documenting it might be worthwhile.   I think it would be better to do this in IETF than in Cablelabs or BBF because it's applicable to both.