On Fri, 18 Apr 2003 [EMAIL PROTECTED] wrote: > I'd be interested in your comments on > http://www.ietf.org/internet-drafts/draft-baker-ipv6-renumber-procedure-00.txt. > > This document grew out of a brief exchange on the IETF list, and an > internal exchange with some operations folks at Cisco. What I'm trying to > explore in the document is why some people say "renumbering is easy" and > others say "renumbering is next to impossible" - the latter often with > expletives added for color. We get a whine from various and sundry saying > "please make renumbering easy to do", but we aren't especially told what to > make easy. > > It turns out that operationally, the best thing we can do to make > renumbering easy is make manual configuration really hard. It is the cases > of manual configuration - things that are not automated in the first place - > that are hard to automate. > > I'll take direction on what to do with the draft. I have had one network > operator (who has to renumber an IPv4 network) tell me that the procedure is > of value to him a it gives him a step in defining things. So it may be of > value as an informational document. But for me, the real value lies in > helping the IPv6 and the operational communities talk with each other.
I think this is certainly something we need to do in the multi6 and even ipv6 wg context. There are two related processes, in my mind: 1) a) documenting best practices to have your network in a state you can renumber it if needed b) practices to use if/when you need to renumber and: 2) developing mechanisms which make the renumbering even a bit more easier. It's difficult, and we shouldn't expect too much of it, but I'm pretty sure there may be ways to at least eliminate the worst quirks. In the "optimal" case these would be tied together in a feedback loop :-) I've had some thoughts on both, but as there has not been a sufficient community interest, I haven't bothered to go deeper into it. ... As to your draft -- I didn't read it properly, but a few comments: - a bit much of too pretty language (e.g. the first paragraph), have to concentrate too much to understand what it means - the claim, originally made in RFC2072 I suppose: RFC 2072 [6] describes the implications of renumbering in an IPv4 network. A number of issues are raised, not the least of which is that while IPv4 in no sense precludes the configuration of more than one prefix on an interface in an equal sense, IPv4 equipment usually does not provide this capability. .. IMO appears to be wrong. The IPv4 equipment I use certainly allows all of this. Typically only those which are restricted anyway (like printers configured from an LCD panel or such!) may only allow one, but this doesn't seem to be an architectural limitation. - you're having (perhaps unintentionally) an ISP-driven perspective or some unstated assumtions; that is: 2.3 Stable routing both prefixes Once the network has been configured with the new prefix and has had sufficient time to stabilize, it becomes a stable platform with two addresses configured on each and every infrastructure component interface (apart from serial interfaces that use only the link local address), and two addresses available for the use of any end system, one in the old prefix and one in the new. However, due to DNS [3][4] advertisement and history, sessions are opened with the addresses in the old prefix; the new is idle. This is a stable configuration. ... in practice there is no such stable state with IPv6, in the generic case. Reason is that if the ISP's use ingress filtering for the site, using both prefixes will result in about 50% of packets getting dropped unless you have something like source-based routing. This problem has been noted earlier in host-centric multihoming, for example. The other explantions why this was overlooked may have been: - if you renumber an ISP or a major customer, there are typically no ingress filtering issues or at least you're in a position to negotiate about them - with IPv4, some get around these issues by using NAT in the border routers - I'd suggest removing the references and assumptions of RFC2894 -- or at least sweeping them up to a corner of a draft, as it seems to be practically useless & unimplemented approach. Nit: "presumes the use of IPv6 Autoconfiguration as described in RFC 2894" seems odd -- the main body of that RFC is *not* about autoconfiguration as we typically understand it (in the RFC2461/2462 sense). - section 3 should more clearly separate (both are mentioned to some extent, but after the mention, you go straight to the first) the cases of "manually configured but local" (in theory, you can keep a better track of these using some methods!) and "manually configured but remote" (e.g. someone else's access lists etc.). These issues have entirely different implications I think. - s/liklihood/likelihood/ - in acknowledgements, s/Michel P/Michel Py p/ ? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
