[arin-ppml] Portable address space vs. IPv6 auto-numbering

[Tony Li]

Hi Robin

|The only way these problems can be handled is with portable address
|space - PI space as currently managed by BGP (driving the routing
|scaling problem) or some new kind of PI space such as provided by
|map-encap schemes which does not excessively burden the BGP system.


Or, by some other scheme that we come up with.  For example, in a GSE
approach a host wouldn't need to know about it's routing goop, yet the site
wouldn't need PI space.


|Even if portability wasn't really required by most or all end-user
|networks, IPv6 still doesn't provide the multihoming they need for
|PA prefixes.


Today.  Our goal is to fix that.


| SHIM6 relies on the correspondent host having SHIM6
|and does not provide router-centric, network-centralised,
|multihoming management, since it works at the level of hosts.  Every
|Internet-facing host in the network would need to do SHIM6 and be
|robustly and securely coordinated.


In fact, that's not true.  SHIM6 can cleanly operate with 'legacy' v6 hosts.


|There was some debate about this on the IRTF Routing Research Group
|recently:
|
| Consensus? End-user networks need their own portable address space
| http://psg.com/lists/rrg/2008/msg01310.html


And there was no consensus.


|The RRG is attempting to find and recommend (by 2008-03) a new
|routing and addressing architecture for the Internet so that many
|(millions or potentially billions) of end-user networks can get
|multihomed address space, suitable for traffic engineering in a way
|which makes it relatively easy for them to change ISPs.  This needs
|to be achieved in a scalable way - most likely by creating a new
|form of address space management and associated routing (actually
|tunneling) mechanisms so millions of end-user networks get the kind
|of space they need, without each such network advertising one or
|more prefixes in the global BGP system.


It's actually very unlikely that we will resort to a tunneling/encapsulation
mechanism.  They are too cumbersome, architecturally unclean, and fraught
with MTU issues.  My hope is that we do something better.


|Quite a few folks argued against portable address space.  But I
|think their objections are primarily based on the way portability
|causes scaling problems in today's system.  I think they are highly
|sceptical of map-encap solutions and keen to see everyone on IPv6
|ASAP - where they think portable space isn't required.


Well, think what you like.  Other people have a slightly different
perspective than you as to the urgency of dealing with the issues and the
level of architectural cleanliness that we would like to deliver.  I, for
one, do not want RRG's legacy to be a giant kludge.

Most people object not to the portability of a prefix but to its lack of
aggregatability.  That leads exactly to the scaling issues that we're trying
to solve.  Ideally, we will end up with a routing architecture where there
are no non-aggregatable addresses for end sites and preferably even higher
up the hierarchy.


|None of them convinced me that substantial end-user networks would
|be happy with IPv6 host renumbering as a means of easily changing
|the entire network's prefix when choosing another ISP.  


Is this a comment about the technology?  Or about you?  ;-)


|The fact
|that most RIRs now offer PI space to end-user networks strikes me as
|pretty good proof of my argument that end-user networks typically
|need portability.


In fact, it was intentionally done that way precisely because there is no
decent routing and addressing architecture for the RIRs to follow.  Post
hoc, ergo propter hoc.


|NAT-PT doesn't seem to be a viable transition mechanism by which
|IPv6-only hosts can retain connectivity to the IPv4 Internet, as I
|wrote here:
|
|  http://psg.com/lists/rrg/2008/msg01467.html


Which basically seems to claim that NAT can't work.  I believe that we've
shown the converse.


Tony