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

[Robin Whittle]

Hi Tony,

You wrote:

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

I understand you are suggesting the RRG consider recommending a
longer-term project of a radical revision of IPv6 along the lines of
GSE:

  http://tools.ietf.org/html/draft-ietf-ipngwg-gseaddr-00

I haven't read this and I don't see anything to do with GSE in the
RRG wiki:
  http://www3.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup

If it is so significant then I would have thought that someone would
have written it up as a proposal and done an 8 page summary and
analysis document for it, as was provided for each of the map-encap
and some other proposals.


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

Without reading further, my impression is that you are proposing to
forget about the routing scaling problem in the IPv4 Internet, and
to forget about existing IPv6 usage, but to change IPv6 to use GSE -
a proposal which seems to have flourished briefly around 1997 and
not been heard of much since then.

This is pretty radical and does not look promising to me.  A quick
scan of gseaddr-00 makes me think this requires major changes in
every IPv6 router and host - both stack and applications.  Is this
the case?

If so, maybe it might be best to fix the IPv4 problem so we have
more time to re-jig IPv6 into something fundamentally better.

I would not want to be on such a high-pressure mission as I think
you are contemplating: let Rome burn while we convert another city
into something very different from what it was meant to be, and by
then the folks from Rome will happily want to come to live in the
new city instead.  Since the folks in Rome gave us the task of
saving them from flames, I think their patience could be rather
strained as the place goes up in smoke while we try to rebuild the
other city.


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

GSE obviously can't be made to work with IPv4, unless you change
IPv4 hosts and routers completely - in which case it is not IPv4 and
is not backwards compatible with IPv4.

I am increasingly perplexed by my understanding of your suggestions,
which I admit may be faulty.


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

Sure, but to radically alter IPv6 . . . when there are already major
problems getting anyone to use it . . .  What would transition
mechanisms look like for IPv4 and GSE-IPv6, or with current IPv6 and
GSE-IPv6?


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

There are many more devices than PCs and servers.  It is hard enough
to update them, but harder still to update embedded devices.

Map-encap doesn't require any host changes at all.


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

Hmm - maybe I need to revise my understanding of SHIM6.


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

I proposed a way around the MTU problems.  I haven't received any
critiques:

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

"Legacy interaction" is handled with Ivip's Open ITRs in the DFZ
(OITRDs).  LISP does the same thing with their "Proxy Tunnel
Routers" (PTRs).

Ivip's fast push mapping system is described in some detail here:

  http://tools.ietf.org/html/draft-whittle-ivip-db-fast-push-00

There's more work to do, but plenty of detail criticise if you think
it can't be robust and be much more scalable than the current BGP
approach.  It is fast push to wherever the operators decide to place
their full database query servers.  Then, past that, to wherever the
ITRs are, it is local fast pull, with fast, robust, notification of
a mapping update from the full database query server to the ITR.


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

Indeed . . .


> |  But that simple Internet
> |can't scale properly, or support mobility properly.
> 
> Fine, but that doesn't exclude the remainder of the solution space.

The solution space is wide open if you ignore IPv4.  You have a
longer time to do all sorts of things to IPv6, which hardly anyone
outside the IETF really cares about compared to how they care about
and rely upon the IPv4 Internet.

We map-encap folk are preparin' to put out the fire where we live
and make sure our potential future abode can't catch fire.

I think you are ignoring the fire and concentrating on constructing
a crystalline future, which I understand the attraction of.


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

Consensus in the RRG to ignore the IPv4 Internet and direct the IETF
to focus only on IPv6 could cause the IETF to further rely on IPv6 -
something the rest of the world has not found it needs so far.  If
so, I predict the IPv4 Internet will be kept alive by hook or by
crook, because most people simply don't want to move to an
alternative Internet which doesn't work for them as well as the one
they are using now.

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

Almost no-one wants to transition to some other Internet which
doesn't work like the current one.  The long-term vision you have
about the benefits is not shared by the great majority of end-users,
who rely on unencumbered communications with all other end-users -
something the IPv4 Internet does fine and which IPv6 won't for a
long time.


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

Sure - better than resolving not to speak English any more and only
communicating directly with folks who speak Esperanto.


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

No.  I have been explaining this for a year now.  The Ivip-arch ID
has been available since July 2007.

In Ivip, a Mapped Address Block is advertised in BGP as a prefix.
OITRDs all advertise this and receive the packets.  They split the
address space up into micronets, according to the mapping
information, and tunnel packets to ETRs.

You could have a single /14 with 2^18 IP addresses.  That could be
as many as 2^18 micronets of one IP address each.  Let's say the
average micronet size was 8 IP addresses, that is still 2^15
micronets, for this many or somewhat fewer separate end-user
networks, all with just a single addition to the DFZ routing table.


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

My Ivip material which explains all this is plenty detailed enough
for you or others to criticise.


> |> |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 I wrote, I figure they knew this would brew trouble - and that
they are surely relying on the IETF to find a solution.


> |> |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
> 
> As an act of defiance by the NAT-haters.  That doesn't mean that it's
> actually dead.  

The IETF assigned it to Historic status.

> Like Mary Queen of Scots, it will probably live again.  The
> market wants it.  The question is who will build it.

Do you need NAT-PT or something similar to ease transition to a new
GSE-IPv6?  Do you think the world will adopt it without a seamless
transition mechanism?

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

Not me.

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

But the bits won't flow the way end-users expect them except on the
unadulterated IPv4 Internet.  Most of them will not pay for a
service which offers less, so there will be a massive financial
pressure on ISPs to get as much IPv4 space as they can and to use it
very efficiently.  I reckon there is a lot of scope to do that in
the next 10 to 20 years, for better or for worse.

> In actuality, the only folks we have to convince are ourselves.
> After that, it steamrolls.

I disagree.  If we want most of the world to use a system with
scalable routing, we need to present it in a way they feel immediate
 and lasting benefits from, since we can't foist them into a new
system and we can't rely on the growing pain of the IPv4 routing
scaling problem causing enough of them to jump ship into a separate,
incompatible and poorly backwards compatible IPv6 Internet.


  - Robin