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

[Robin Whittle]

Hi Tony,

You wrote:

> |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.

That might be OK if you are working with a development and
deployment timetable which involves doing nothing to directly help
with the IPv4 routing scaling problem.

Maybe I don't understand enough about GSE, but what about routers
which filter addresses?  That needs to be an IP address as far as I
know.  How can networks be built so that every instance of an IP
address in a config file of some daemon or router can be found and
securely and correctly changed when moving from one or more PA
prefixes given by one or ISPs to the PA prefixes of other ISPs?
Likewise securely and reliably updating the correct entries in DNS
zonefiles?


> |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.

If the RRG decides that it doesn't need to solve the IPv4 routing
scaling problem, then there is plenty of time to come up with an
IPv6 solution with a wider variety of potential techniques and fewer
backward compatibility reasons than would be the case for an IPv4
solution.


> | 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.

I recall that if host A the "correspondent host" and host B is
multihomed with two or more PI prefixes, that both A and B need to
be running additional SHIM6 code in their TCP/IP stack in order that
A can send packets to another prefix when the one it was using
doesn't work for some reason.

If A didn't have the SHIM6 additions, it could operate with B, but
only as long the prefix in which it accesses B still works.  So to
support multihoming, I recall that SHIM6 requires upgrades to both
hosts.

Still, I can't see how a network's multihoming can be reliably and
securely controlled by the administrators if it requires hooks into
all their hosts.

Map-encap portability, multihoming etc. solves that problem without
any host changes or the hosts having to be involved in multihoming
at all.


> |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.

Yes.  There has been virtually no consensus on the RRG.  That is
no-one's fault.  These are difficult issues and it is a
self-selected group.


> |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.

The developers of the map-encap systems - LISP, APT, Ivip and TRRP -
have a different view.  There may be enough active members of the
RRG to form a rough consensus with your view, which is contrary to
the intention of the map-encap developers (as far as I know) to work
on IPv4 first.  In that case, the RRG will proceed to work towards a
more ambitious goal of an architecturally cleaner IPv6-only
solution, over a longish time-span.

But that would involve leaving the IPv4 routing scaling problem to
grow increasingly worse until by some combination of events, enough
end-users decide to adopt IPv6-only addresses sufficient to halt or
reverse the IPv4 problem.  This is why the question of IPv6 adoption
is so crucial to the RRG deciding whether or not to develop a
solution for IPv4 ASAP.

My approach to the MTU problems of map-encap schemes is here:

  http://www.firstpr.com.au/ip/ivip/pmtud-frag/


> |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.

Sure, there are major differences in opinion about this.  I think
what I like and try to learn from others to think better.

Map-encap is giant and it is a kludge to the extent that it adds
stuff to an originally simple Internet.  But that simple Internet
can't scale properly, or support mobility properly.

I think a well designed map-encap system with real-time control
(Ivip) is the best solution for IPv4 and IPv6, not least because it
removes a lot of complexity from the ITRs by having the end-user
directly control the mapping, rather than building in multihoming
restoration decisions into the ITRs and therefore the map-encap
system.  Also, this is the only way I can imagine of supporting
scalable, generally path-optimal, mobility:

  http://www.firstpr.com.au/ip/ivip/#mobile

This looks good for both IPv4 and IPv6.

Still, I can't see how the world is going to break the IPv4 habit
and move to IPv6, since the transition mechanisms are so problematic.

My guess is that IPv4 will persist for at least a decade and
probably more, with or without a routing scalability fix.  Even if
the RRG doesn't recommend one, someone else might be motivated to
create one.  For instance, the Ivip model of providing finely sliced
PI space may well be a promising commercial proposition.  The TTR
mobility extensions should be much more commercially attractive.
All this could be done for IPv4 without IETF involvement.  I am not
suggesting this should happen, but if the IETF remains so focused on
IPv6 it does not develop an IPv4 fix then the rest of the world,
using IPv4, may finds commercial Ivip-like systems attractive for
portability, multihoming and global mobility.


> 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.

Yes, but map-encap removes the aggregatability problem by bundling
potentially thousands of EID-prefixes (micronets) into one
BGP-managed prefix.  It provides portable address space, and with
the TTR extensions to Ivip, global mobility.

The trick is to make the map-encap system much more scalable than
BGP's global system of each DFZ router conversing with its peers.  I
believe this is not hard to do, including with real-time control of
ITRs as in Ivip.


> |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?  ;-)

I was unconvinced by the counterarguments.


> |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.

I don't clearly understand this.

IPv6 was always meant to involve purely PA space for end-user
networks.  End-user network administrators were supposed to be happy
to multihome with SHIM6 and happy to change PA prefixes by the
wonders of host auto-renumbering.

I see no evidence that end-user networks are happy with either
solution.  My understanding is that in order to get end-user network
IPv6 adoption going at all, the RIRs caved in to end-user
requirements and therefore abandoned the purity of the official IPv6
doctrine, by offering PI prefixes for end-user networks.  I
understand that in doing this, they knew that if and when IPv6 is
widely adopted this would replicate the routing swamp of IPv4.  So I
guess the RIRs are relying on the IETF -> IRTF -> RRG to come up
with an architectural fix in time to prevent this getting too bad.


> |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.

NAT-PT was buried last year:

  http://tools.ietf.org/html/rfc4966

I understand that the fear was that these kludges are unacceptable -
especially since they would tend to become part of the network and
so become barriers to the ideal of unencumbered IPv6 end-to-end
connectivity.

   (At least with map-encap, there are no host-level kludges, and
    the BGP system carries on as usual.  It is a relatively clean
    system considering the enormity of what it provides.)

The only replacement I know of is NAT64.  The initial ID, one
version only, in 2002:

  http://tools.ietf.org/html/draft-durand-ngtrans-nat64-nat46-00

In Feb 2008, updated in May, a requirements document:

  http://tools.ietf.org/html/draft-ietf-v6ops-nat64-pb-statement-req

and yesterday a start at the NAT64 and DNS64 protocols:

  http://tools.ietf.org/html/draft-bagnulo-behave-nat64


So is the RRG going to say to today's Internet users something like
this?:

   Don't worry about the IPv4 routing scaling problem.  It will get
   worse, but before it gets too bad we will have IPv6 all sorted
   out, with a transition mechanism which most of you will all be
   happy with, and with a much better solution to the routing
   scaling  problem than we feel like suggesting for IPv4.

Yet 10 or so years of effort at a transition arrangement for IPv6
was junked last year and it is early days for the new plans.  A
quick read of the requirements document made me think the task is
not going to be easy - and can probably be achieved only in ways
which support a subset of the applications and protocols in wide use
today.

 - Robin