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

Wed Jun 11 02:56:22 EDT 2008

Hi Robin,

|Maybe I don't understand enough about GSE, but what about routers
|which filter addresses? 

Filters would be on the identifier.

Please, please, please go read GSE.  You may not like it, you may not agree
with it, but until you grok it, you haven't seen a big chunk of the solution
space.

 http://www.watersprings.org/pub/id/draft-ietf-ipngwg-gseaddr-00.txt

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

Again, there would be no 'address'.  Only 'routing goop' and 'identifiers'.
Since identifiers are fixed and assigned to hosts, there would no issue with
filtering, config files, DNS, etc.

Or...  If we don't panic, spend the time to come up with a clean solution
that we can all get behind, then we might find that we can apply it to v4 as
well as v6.  Or that once we have it, the thought of transitioning to v6 is
suddenly less distasteful. 

Again, having a mechanism whereby end sites could be multi-homed, not have
to fight and/or pay ARIN, and get reliable routing might well be seen as a
benefit.

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

This is a circular argument.  Yes, to get the benefits of SHIM6, you need to
upgrade the host.  To get maximal benefits, you need to upgrade the hosts at
all multi-homed sites.  Of course, those are also the most technologically
adept sites, best prepared to upgrade, and the costs of upgrading are
aligned with the beneficiaries, so that somehow all is aligned.

Of course, you DO have to run Windows Update/OSX Software Update.  My
recollection is that you believe that won't happen.

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

Control is at the CPE systems/firewalls, just as it is now.

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

Except, of course, MTU issues, still unknown mapping issues, and legacy
interaction issues.  How did that help?

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

Not yet.  ;-(  

As you note, the active members of the RRG are a diverse bunch.

|  But that simple Internet
|can't scale properly, or support mobility properly.

Fine, but that doesn't exclude the remainder of the solution space.

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

Yeah, and we'll never get off of NCP either.

You'd be amazed at what you can do with a little consensus and leadership.

|My guess is that IPv4 will persist for at least a decade and
|probably more, with or without a routing scalability fix. 

Agreed.  We *want* this.  What better way to de-risk transition than to make
it possible to not transition?  What if we simply transitioned because we
*wanted* to?  Because there was compelling value and benefit there?  Much
smoother, yes?

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

Or, we can just keep NATing.  Carrier-class NAT anyone?  ;-)

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

Not at all clear.  If every end site still gets a prefix, don't you end up
with the same problem?  To ensure that you have aggregation, you need to
have a clear plan for aggregated identifier assignment.  I still haven't
found one that I find compelling.

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

Correct, they caved and they knew it.  You can't use this to claim that they
felt it was the right solution.  If there was a solution that meant that end
users didn't have to renumber and yet they weren't given portable addresses,
this would not have been necessary.

As an act of defiance by the NAT-haters.  That doesn't mean that it's
actually dead.  Like Mary Queen of Scots, it will probably live again.  The
market wants it.  The question is who will build it.

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

Yet, if they become a valuable transition tool, they will necessarily
happen.  Anyone remember PIX?

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

Hopefully, the RRG will have something cleaner to say.  In any case, I don't
think that the RRG need address the users of the Internet.  Most of them
won't even care.  As long as the bits flow, it won't matter to them.  In
actuality, the only folks we have to convince are ourselves.  After that, it
steamrolls.

Tony