Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05

[Ole Troan <[e-mail]>]

> Thanks, Tony.
> 
> Let me comment on one point in your review.
> 
> On Aug 20, 2010, at 11:47 AM, Tony Li wrote:
> 
>> 5) The draft misses the opportunity to call for work in v6 renumbering.  The fact of the matter is that sooner or later, sites will need to renumber.  Even given adequate address space, there are other compelling events (e.g., corporate acquisitions) that drive renumbering.  There's much work to do here.  If we make the assumption that renumbering WILL be easy (and make it come to pass), then it's reasonable to argue that renumbering into a larger prefix is easy and thus we can be more conservative in initial site addressing.
> 
> When I sat down to write what is now RFC 4192, I was really scratching my head. Given that an IPv6 (or for that matter, an IPv4) interface can take two or more prefixes, it seemed to me that there was an obvious procedure for renumbering a network:
> 
> 1) start with a working network that you don't like the address plan of
> 2) design a new address plan using a different set of numbers
> 3) configure the network equipment to use the new plan in addition to the old
> 4) test the new plan, fixing whatever needs to be fixed
> ---> you now have two working networks running on the same infrastructure <----
> ---> but you are only using one, the "old" one                            <----
> 5) tell the hosts and their applications to use the new address plan
> 6) verify that the hosts and applications in fact all work using the new plan
> ---> you now have two working networks running on the same infrastructure <----
> ---> and you are actively using both of them                              <----
> 7) stop advertising services using the old address plan
> ---> you now have two working networks running on the same infrastructure <----
> ---> but you are only using one, the "new" one                            <----
> 8) do what you like with the old plan
> 
> Several of those points obviously imply waiting periods - the fact that you removed a resource record in step 7 doesn't mean you're ready for step 8, for example. 
> 
> I then went to the operational community, inside and outside Cisco, and said "OK, I already know I'm insane. What I need to understand is WHY I'm insane."
> 
> I got an education, and much of what I learned wound up explicitly called out in the document. The thing that makes renumbering hard has nothing to do with the procedures for renumbering. It has to do with places where people type in numeric IP addresses, whether in router configurations like interface addresses and route maps or in applications that "Just Know" that the address of some system is 192.0.2.1 or 2001:db8::12. Web pages that refer to other servers by address instead of by name, SIP referrals, FTP (which tops it all by having a different passive mode command and behavior for IPv6 than it has for IPv4), and so on.
> 
> To be really honest, I have concluded that every time we further idiot-proof the world, the world makes better idiots.
> 
> I'm all for improving our ability to renumber, but I'm not sure that's something the IETF can solve technically. Vendors can help, by providing configuration options that associate names with numbers in one common location and then enables the administrator to use the names in configuration files. But even those have issues. Consider this one:
> 
> You have a router configured:
> 
> !
> ipv6 unicast-routing
> ipv6 general-prefix EXAMPLE 2001:0DB8:0:0::/48
> !
> interface foo 1
> ipv6 address EXAMPLE 0:0:0:0::/64 eui-64
> ipv6 enable
> !
> interface foo 2
> ipv6 address EXAMPLE 0:0:0:1::/64 eui-64
> ipv6 enable
> !
> interface foo 3
> ipv6 address EXAMPLE 0:0:0:2::/64 eui-64
> ipv6 enable
> !
> 
> Now, someone decides to renumber the network, and replaces the general-prefix using
> 
> 	ipv6 general-prefix EXAMPLE 2001:0DB8:1:0::/48
> 
> What happens? The network stops working for a period of time, at least through that router; depending on the placement of the router, the outage may prevent access to other routers that happen to be beyond it, and certainly disrupts the operations of hosts on the networks it is attached to. Why? Because the existing routing depended on the old prefix, and in replacing the configuration outright it disrupted the existing routing before the new prefix was stable in the network.
> 
> What should they have done?
> 
> They should have configured
> 
> !
> ipv6 general-prefix EXAMPLE2 2001:0DB8:1:0::/48
> !
> interface foo 1
> ipv6 address EXAMPLE2 0:0:0:0::/64 eui-64
> !
> interface foo 2
> ipv6 address EXAMPLE2 0:0:0:1::/64 eui-64
> !
> interface foo 3
> ipv6 address EXAMPLE2 0:0:0:2::/64 eui-64
> !
> 
> waited and tested, and at some later time when the new prefix and old prefixes provably both worked for everyone concerned, applied
> 
> no ipv6 general-prefix EXAMPLE 2001:0DB8:0:0::/48
> !
> interface foo 1
> no  ipv6 address EXAMPLE 0:0:0:0::/64 eui-64
> !
> interface foo 2
> no  ipv6 address EXAMPLE 0:0:0:1::/64 eui-64
> !
> interface foo 3
> no  ipv6 address EXAMPLE 0:0:0:2::/64 eui-64
> 
> 
> In this case, the "better idiot" worked at a random router vendor of your and my acquaintance. Said person thought that by providing the general-prefix, s/he had made renumbering simple. No, s/he had at most added a level of indirection to the routing configuration.

as said person is one of my better acquaintances, I can with certainty say that said person thought no such thing.
the mechanism above handles indirection via a single "name" to multiple prefixes with differing lifetimes, but only with a dynamically acquired prefix, not with manual configuration. file a bug.

but that fact doesn't matter much, as the IETF hasn't figured out how a network with multiple prefixes should work. i.e multi-prefix multi-homing.

cheers,
Ole

> 
> s/he could be forgiven for the error, though; it is essentially the same as is recommended in RFC 2894, which has the network administrator distribute commands to, in its words
> 
>                       instruct the router to ... remove the prefix
> which matched the Match-Prefix and replace it with the Use-Prefixes,
> or replace all global-scope prefixes with the Use-Prefixes.
> 
> with the effect of disrupting the old prefix at a time that the new prefix is not yet fully deployed or distributed in routing, neighbor discovery, etc. Yes, it also has the option of adding a second prefix, which is what it should have done, but it doesn't have the option of removing a prefix. I guess you're supposed to add new prefixes, and then replace the old prefixes with the already-added new prefixes. Maybe.
> 
> Yes, we need work on renumbering. But I think it will require more than a simple technical solution.