Subject: [renum] Unplanned immediate renum make sense??

From: "Leo Liu(bing)" <[email-masked]>
Date: Fri, 02 Sep 2011 03:10:24 +0000

In the gap analysis document, there is an issue that immediate renum is a gap because of the protocol limitation, for example the RA lifetime couldn't be reduced under two hours in some situations.

But after discussing the issue with Brian, we noticed there's another question that even if the hosts/servers addresses could be renumbered immediately, it is impossible to synchronize the DNS TTL instantly, especially for the DNS records in the cache.
So without instant DNS update, the unplanned immediate renum make sense only if there are some hosts which have no domain names and need to renum addresses immediately for some emergency. But I'm wondering whether this kind of scenarios exist in the real networks.

I think we can divide the "unplanned immediate renum" issue into two aspects to discuss:

1)    Starting renum on demand without too much preparation
This means the administrators can "trigger" the renum process immediately once they get the new prefix(es), regardless of whether it can be "completed" immediately. I think this is meaningful for easing renumbering. Of course, we need further investigation whether it is possible and what the gaps are.

2)    Renum "completed" immediately
"Completed" means the new prefix(es)/addresses are available regardless of whether the old ones are withdrawn or not. This involves in the instant DNS update issue discussed above. And I'm wondering whether this is needed.

How do you guys think about the question?

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 02 Sep 2011 04:55:22 +0000

From: [email-masked] [mailto:[email-masked]] On Behalf Of Leo Liu(bing)
Sent: Friday, September 02, 2011 11:10 AM
To: [email-masked]
Subject: [renum] Unplanned immediate renum make sense??

Sheng> this is a real requirement for me. However, I don't see much new technical requirements from normal renum that we have analyzed.

Sheng>  I don't agree your definition of "completed". For me, make the new prefix available in a short time is not that challenge. It is the matter whether the right tool has deployed for updating or not. If there were, the update can be completed quickly. The difficult is to disable the old ones. They cannot expire "immediately" or in short time - say less than two hours.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 02 Sep 2011 09:36:19 +0300

I think renums of the second category are going to be problematic. As you point out, DNS lifetimes, RA lifetimes, and a number of other things can be ongoing. Ongoing long-lifetime TCP sessions.

This is more in the territory of multihoming/mobility/idlocsplit designs, and will require significant changes all over the place to get it working.

I think this working group should focus more on the practical improvements for category 1 renums. And they do happen.

Jari

On 02.09.2011 06:10, Leo Liu(bing) wrote:
>
> In the gap analysis document, there is an issue that immediate renum is a gap because of the protocol limitation, for example the RA lifetime couldn’t be reduced under two hours in some situations.
>
> But after discussing the issue with Brian, we noticed there’s another question that even if the hosts/servers addresses could be renumbered immediately, it is impossible to synchronizethe DNS TTL instantly, especially for the DNS records in the cache.
>
> So without instant DNS update, the unplanned immediate renum make sense only if there are some hosts which have no domain names and need to renum addresses immediately for some emergency. But I’m wondering whether this kind of scenarios exist in the real networks.
>
> I think we can divide the “unplanned immediate renum” issue into two aspects to discuss:
>
> 1)Starting renum on demand without too much preparation
>
> This means the administrators can “trigger” the renum process immediately once they get the new prefix(es), regardless of whether it can be “completed” immediately. I think this is meaningful for easing renumbering. Of course, we need further investigation whether it is possible and what the gaps are.
>
> 2)Renum “completed” immediately
>
> “Completed” means the new prefix(es)/addresses are available regardless of whether the old ones are withdrawn or not. This involves in the instant DNS update issue discussed above. And I’m wondering whether this is needed.
>
> _______________________________________________
> renum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/renum

---

From: "Leo Liu(bing)" <[email-masked]>
Date: Fri, 02 Sep 2011 07:37:00 +0000

Thanks for your comments Jari. 
That's quite a clear suggestion we can consider to follow.

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Friday, September 02, 2011 2:36 PM
> To: Leo Liu(bing)
> Cc: [email-masked]
> Subject: Re: [renum] Unplanned immediate renum make sense??
> 
> I think renums of the second category are going to be problematic. As you point
> out, DNS lifetimes, RA lifetimes, and a number of other things can be ongoing.
> Ongoing long-lifetime TCP sessions.
> 
> This is more in the territory of multihoming/mobility/idlocsplit designs, and will
> require significant changes all over the place to get it working.
> 
> > In the gap analysis document, there is an issue that immediate renum is a
> gap because of the protocol limitation, for example the RA lifetime couldn't be
> reduced under two hours in some situations.
> >
> > But after discussing the issue with Brian, we noticed there's another
> question that even if the hosts/servers addresses could be renumbered
> immediately, it is impossible to synchronizethe DNS TTL instantly, especially for
> the DNS records in the cache.
> >
> > So without instant DNS update, the unplanned immediate renum make sense
> only if there are some hosts which have no domain names and need to renum
> addresses immediately for some emergency. But I'm wondering whether this
> kind of scenarios exist in the real networks.
> >
> > This means the administrators can "trigger" the renum process immediately
> once they get the new prefix(es), regardless of whether it can be "completed"
> immediately. I think this is meaningful for easing renumbering. Of course, we
> need further investigation whether it is possible and what the gaps are.
> >
> > 2)Renum "completed" immediately
> >
> > "Completed" means the new prefix(es)/addresses are available regardless of
> whether the old ones are withdrawn or not. This involves in the instant DNS
> update issue discussed above. And I'm wondering whether this is needed.
> >

---

From: "Leo Liu(bing)" <[email-masked]>
Date: Fri, 02 Sep 2011 07:36:55 +0000

Thanks for the comments, inline.

From: Sheng Jiang
Sent: Friday, September 02, 2011 12:55 PM
To: Leo Liu(bing); [email-masked]
Subject: RE: Unplanned immediate renum make sense??

[Bing] Section 2.2 of rfc4192 documented some operation to be prepared before renumbering, for example the DNS/DHCP TTL adjustment. I think it worth to have further investigation whether the preparation can be reduced/optimized or even avoided through better operational practice or even protocol change.

[Bing] Thanks for pointing out this. I think you're right, my definition may cause some confusion. If DDNS deployed, the new prefix available in a short time is not that challenge. The real problem is that the old addresses could be deleted at the interfaces immediately while the DNS records may still be available in the zonefiles/cache for some time.

---

From: Sheng Jiang <[email-masked]>
Date: Fri, 02 Sep 2011 07:48:50 +0000

Sheng> I have nothing against your mentioned preparation before renumbering. My point is: they apply to all renumbering events. There is no NEW requirements because "immediate" renumbering.

---

From: Mark Townsley <[email-masked]>
Date: Fri, 2 Sep 2011 11:38:21 +0200

Unplanned immediate renums are common in broadband networks with IPv4 today (though shielded by NAT), and could very well be for a number of IPv6 deployments coming online as well (sadly). 

- Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 03 Sep 2011 08:39:17 +1200

> Unplanned immediate renums are common in broadband networks with IPv4 today (though shielded by NAT), and could very well be for a number of IPv6 deployments coming online as well (sadly). 

Yes, I've said before that renumbering whenever you reboot (either host or CPE)
is normal for domestic setups today, and nobody cares. Our scope is enterprise
networks, however, where some amount of static manual configuration is
normal, so renumbering is a problem.

   Brian

---

From: Roger Jørgensen <[email-masked]>
Date: Sat, 3 Sep 2011 13:51:48 +0200

> normal, so renumbering is a problem.

Hmmm how does firewalls fit into this? Most of the trouble I've got
into with renumbering is related to get the firewalls updated. Both
incoming and outgoing rules. I got a few ASA's and still not found an
easy way of handling renumbering cases there...

I do like the script/iptables options alot, just define a PREFIX and
later just reuse that variable.

_PREFIX_=2a01:c001:1234
And whenever you add a rule you just do
$_PREFIX_:1234::53

renumbering this case only include one change, could easy be automated to.

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 04 Sep 2011 08:42:15 +1200

Hi Roger,

> renumbering this case only include one change, could easy be automated to.

Sure, although I'm wondering whether we shouldn't consider a DNS convention
for naming & storing the prefix. However, I also wonder whether we should
identify a gap here: a standardised solution for communicating a prefix
update to all systems that need to know it. (Another question is whether
that can be NETCONF.)

    Brian