Re: [homenet] Orchestration of renumbering
On 25 Mar 2015, at 02:01, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 25/03/2015 08:47, JF Tremblay wrote: On Mar 24, 2015, at 2:00 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: [...] 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.) 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. 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 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 homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Orchestration of renumbering
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 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. 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 Abrahamssonemail: swm...@swm.pp.se ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Orchestration of renumbering
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. 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. 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? -- Mikael Abrahamssonemail: swm...@swm.pp.se___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Orchestration of renumbering
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 swm...@swm.pp.se 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, and these need to be distinct. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Orchestration of renumbering
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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Orchestration of renumbering
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 cy...@openwrt.org wrote: 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 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Orchestration of renumbering
On Mar 25, 2015, at 11:15 AM, Mikael Abrahamsson swm...@swm.pp.se 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”. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Orchestration of renumbering
On Mar 25, 2015, at 11:26 AM, Timothy Winters twint...@iol.unh.edu wrote: 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. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Orchestration of renumbering
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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Orchestration of renumbering
On 26/03/2015 05:31, Ian Farrer wrote: 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). But presumably, that is only a *request* from the CPE side - the real action is started by the provider edge. Brian ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Orchestration of renumbering
On Mar 25, 2015, at 1:27 PM, STARK, BARBARA H bs7...@att.com wrote: 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. 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? ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Orchestration of renumbering
On Mar 25, 2015, at 12:46 PM, Steven Barth cy...@openwrt.org 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! :) ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Orchestration of renumbering
Hello, On Mar 25, 2015, at 12:37 PM, JF Tremblay jean-francois.tremb...@viagenie.ca wrote: On Mar 25, 2015, at 11:26 AM, Timothy Winters twint...@iol.unh.edu wrote: 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. 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? 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. JF ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Orchestration of renumbering
On Mar 25, 2015, at 2:17 PM, STARK, BARBARA H bs7...@att.com wrote: 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. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Orchestration of renumbering
On Mar 25, 2015, at 2:44 PM, JF Tremblay jean-francois.tremb...@viagenie.ca wrote: 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. 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. ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Orchestration of renumbering
On 25/03/2015 08:47, JF Tremblay wrote: On Mar 24, 2015, at 2:00 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: [...] 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.) 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 [...] 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 homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Orchestration of renumbering
On Mar 24, 2015, at 2:00 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: [...] 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.) Any reference for reading (on Fred’s principle)? [...] 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 homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
[homenet] Orchestration of renumbering
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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
Re: [homenet] Orchestration of renumbering
On 24.3.2015, at 14.00, Brian E Carpenter brian.e.carpen...@gmail.com wrote: 1. Warn users that renumbering is planned/has started. (because long-living sessions will be affected, even in make-before-break) 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. 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. 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 that to happen. 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 ___ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
