[ppml] [narten at us.ibm.com: PI addressing in IPv6 advances in ARIN]

[Christopher Morrow]

On 4/17/06, David Conrad <drc at virtualized.org> wrote:
> Chris,
>
> On Apr 16, 2006, at 10:10 PM, Christopher Morrow wrote:
> > There is no way to get back the /48's assigned under PI
> > space after a multihoming solution that makes sense arrives, and there
> > is, honestly, no driver to continue working on a multihoming solution
> > now that there is PI space.
>
> I tend to view multi-homing as a subset of a more general problem,
> that of separation of end point identifier and routing locator.
> Renumbering is another aspect of this problem. Mobility too. PI is
> just an attempt to ignore the problem and hope it goes away.
>

That may be, though I think it's being viewed as a way to push forward
ipv6 deployment. I think v6 has a chicken/egg problem from the
deployment perspective: 'there is no call for ipv6 so there is no ipv6
deployment', and 'there is no ipv6 deployment because there is no call
for ipv6'. A catch-22 if you prefer that turn of phrase... Anyway, in
order to deploy v6 'more quickly' someone has to take a leap, content
providers and their associated transit folks can take leap #1, OS
folks can take leap #2 and the end users won't care so long as
google/gnutella/BT still 'work'. This means that isp's and content
providers have to deploy v6.

Content providers need to multihome in a reasonable fashion, today
that means PI space, which is why we have 2 proposals on the table for
v6 PI. There may be, I'm not here to debate it, other fixes for their
problem(s), but none are available 'today' which is the timeframe of
the request/policy :(

So, either the community says: "no ipv6 until multihoming is 'solved'"
or we suck it up and start deploying with PI space for the sake of
deployment of v6. I'm not convinced that routing PI space will be
'short lived'...

> As far as I can tell, there are two solutions to the fact that IPv6
> didn't separate end point identifier from routing locator:
>
> 1) the shim6 approach: create a layer 2.5 solution that separates end
> point identifier and routing locator and re-implement IPv6 on all
> hosts to make use of that layer;
>
> 2) the middlebox approach: separate the end point identifier from the
> routing locator at the core/edge boundary, leaving the IPv6 stacks at
> both the routers in the core and the hosts at the edge untouched, but
> inserting a mapping from end point identifier to routing locator on
> source edge to core and an unmapping the routing locator back to the
> end point identifier from core to destination edge.
>

'middlebox' means 'nat host'...

> (I'm not smart enough to figure out how the geotopo approach would
> work without causing a return to the equivalent of the pre-1994
> international telephony settlements regime, but that's my own lack of
> imagination I suspect).

I'm with you on that, I see telco settlements as the 'only' solution to this...

-Chris