Hi Scott, You wrote:
> Would making it easy to renumber be easier or harder than changing > the Internet so that that didn't matter? http://www.irtf.org/pipermail/rrg/2008-October/000064.html For the reasons you, Bill Herrin, I and others have mentioned, I think it is impossible to make it "easy to renumber" without completely changing the Internet: changing the transport protocols and therefore all the applications and operating system stacks. So the answer is: "Changing the Internet so renumbering doesn't matter." All communications (including by some magic, DNS) would rely entirely on hostnames. All communication sessions would persist despite the devices and networks at either end changing their IP address arbitrarily. There would have to be some fancy, secure, system of cached lookups for converting hostnames and network names into IP addresses and network address & prefix length numbers for ACLs etc. along the lines suggested by Olivier: http://www.irtf.org/pipermail/rrg/2008-October/000066.html On its own, this would not solve the routing scaling problem. However, some host-based SHIM6-like (or Six/One-like) multihoming and TE arrangement could be built into the new system, and centralised control added to this for those networks which want it. Also - or alternatively - a router based system for multihoming (such as Six/One Router) could be added for router based multihoming and TE in a scalable manner. But I think the attraction of trying to solve the routing scaling problem by making renumbering "routine" is to avoid such things as new router functions in or around the DFZ. The completely revised Internet arrangement would be much more complex and tangled up with security concerns. Authentication would have to remain robust on the shifting sands where an IP address doesn't mean much. There would probably need to be end-to-end crypto to authenticate sessions - to ensure that the host we were communicating with now is the same one we were communicating with a moment ago, despite it having a new IP address we have never heard of. I can't see how all this would fit with the current common, lightweight, practice of sending a single UDP query to a host identified by a previously known IP address, and getting a single UDP packet response, probably with a nonce returned to protect against spoofed response packets. There would have to be a hostname lookup (or reliance on a cached result) to determine the IP address to send any such UDP query to, including for DNS queries. The entire crypto authentication scheme would be based on PKI or "web-of-trust". PKI is fine in theory, but involves immense, gutsy, administrative and technical arrangements - a monolithic solution which requires international cooperation, but is easier for the end-host to handle, via being configured to trust one or a few Certification Authorities. Web-of-trust sounds like it would be messy and scattered, and hard to configure securely for simple hosts. I am sure this will never happen. I don't think the current Internet protocols are so broken that the only solution is to rip up every application and start again with new protocols. A whole new Internet is never going to happen in any time-frame which is relevant to the routing scaling problem. I believe the routing scaling problem is solvable without touching hosts or inventing new transport protocols: core-edge separation is a perfectly good way of solving the problem. The map-encap approaches to core-edge separation could do the job - but they have significant problems with encapsulation overhead and PMTUD problems, requiring more complex ITRs and ETRs. Perhaps, rather than implement map-encap, it would be easier to upgrade DFZ and many, most or all internal routers to add a forwarding function, based on currently underutilized bits in the existing IPv4 and IPv6 headers. These forwarding approaches have no PMTUD or encapsulation overhead problems. The upgrade should be a firmware update only, as far as I know. So it shouldn't involve new hardware - just some programming work by the major router vendors. ETR Address Forwarding (EAF) - for IPv4 http://tools.ietf.org/html/draft-whittle-ivip4-etr-addr-forw Prefix Label Forwarding (PLF) - for IPv6 http://www.firstpr.com.au/ip/ivip/ivip6/ If this could be done in 4 or 5 years or so, then it would make the development of the core-edge separation a lot easier than by using map-encap. Whether core-edge separation proceeds with map-encap (with a long-term transition to Forwarding once the routers are upgraded) or goes straight to Forwarding, this is definitely going to be easier than all the other alternatives to the routing scaling problem. All other alternatives involve changing host stacks and applications to implement some new protocols which are yet to be developed - such as whatever is needed to make renumbering "routine". - Robin _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
