Subject: [rrg] Changing the Net so renumbering is easy enough to be routine (it will never happen)

From: Robin Whittle <[email-masked]>
Date: Wed, 29 Oct 2008 12:28:53 +1100

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-masked]
https://www.irtf.org/mailman/listinfo/rrg