Subject: Re: IPv6 Multi-homing BOF at NANOG 35

From: Dan Lanciani <[email-masked]>
Date: Fri, 14 Oct 2005 16:55:39 -0400 (EDT)

Brian E Carpenter <[email-masked]> wrote:

| (I wrote)
|> My concern is that adoption of shim6 will be an impediment to development
|> of a more general locator/identifier separation solution both because the
|> mapping functions might clash and because many will object to changing
|> existing implementations a *second* time for what might be perceived to be
|> only a marginal gain for users (and possibly even a loss for providers).
|
|I believe that a true id/loc split is a much more fundamental change
|than IPv4 to IPv6 and on a completely different scale of cost and decade.

That may or may not be true, but it isn't the relevant comparison.  The
first comparison I would make is between the difficulty of retrofitting
a partial separation of identifier and locator in the form of shim6 and
the difficulty of doing it right instead.  The disruption to existing code
would appear to be on a similar scale as either approach would involve a
relatively thin mapping layer.  That leaves the difficulty of solving the
underlying problem.  I happen to believe that solving the general problem
is not significantly harder than solving the limited one via shim6.  I
also believe that shim6 (by mixing locator and identifier usage for the
same address) may raise some issues of its own that would not exist in the
general solution.

The second relevant comparison is the difficulty of doing it right at
some later time in a world where shim6 has been deployed versus the
difficulty of doing it right in a world without shim6.  My concern is
that the former is far greater than the latter, i.e., we probably get
at most one shot at this.  At the very least I would like to see the shim6
layer designed to support a more general separation of locator and identifier
in the future, even if we decide that we don't yet know how to build the
required mapping infrastructure.

|> Indeed.  NAT is simply a response to the economic models of address
|> allocation.  Any technical "solutions" that perpetuate those models
|> will also perpetuate the demand for NAT.
|
|The smallest allocation granularity for IPv6 is supposed to be a prefix,
|not an address, for that reason.

Unfortunately, that does not address most of the problems that drive the
demand for NAT.  The current economic model is:

1) Pay for addresses
2) Pay more for stable addresses
3) Pay much more for portable stable addresses

With more address space available, IPv6 may help with (1) if providers play
along.  But as we have recently seen, customer prefix lengths are already
under attack by perfectly reasonable-sounding conservation arguments.  A
need to conserve always justifies a need to charge.

IPv6 does nothing good for (2).  In fact it makes the situation worse by
making renumbering "easier" without making it less disruptive.  Assuming I
understand the protocol correctly, shim6 increases the premium on stable
addresses since they will be necessary for its version of PA multi-homing.
(Shim6 seems to let you build stable quasi-identifiers on top of two or
more stable locators.  I would prefer a solution that lets you build stable
identifiers on top of one or more unstable locator(s).)

IPv6 itself does nothing good for (3).  PI allocations may well be available
to some set of entities for a while to ease the transition, but that just
brings us back to routing table concerns.  There is no general PI solution
on the horizon, and shim6 may make such a solution less likely to appear.

				Dan Lanciani
				ddl@danlan.*com

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Eliot Lear <[email-masked]>
Date: Sat, 15 Oct 2005 11:34:52 +0200

Hi,

> need to conserve always justifies a need to charge.

The IETF cannot legislate prefix lengths, but the argument behind 
conservation beyond /48 would be utterly silly and demonstrates a 
"revenue opportunity", plain and simple.

> identifiers on top of one or more unstable locator(s).)

This is a matter of timescale.  Prefixes should be expected to change. 
In fact, SHIM6 should be able to provide equivalent of SCTP's ADD-IP to 
*devalue* prefix stability.

> on the horizon, and shim6 may make such a solution less likely to appear.

The whole point of SHIM6 from my point of view is quite the opposite by 
providing a means to advertise access via other prefixes.  So could you 
please justify your above statement?

Eliot

---

From: David Conrad <[email-masked]>
Date: Sat, 15 Oct 2005 23:03:46 -0700

Eliot,

> "revenue opportunity", plain and simple.

When multiple /19s and /20s have been allocated and there are rumors  
of much shorter prefixes which can be justified under the current  
rules, I'm not so sure discussions about conservation can be  
classified as "utterly silly".

> This is a matter of timescale.  Prefixes should be expected to  
> change. In fact, SHIM6 should be able to provide equivalent of  
> SCTP's ADD-IP to *devalue* prefix stability.

Unfortunately, since applications are aware of IP address structures  
(both v4 and, sadly, v6), you'll need to rewrite all applications,  
libraries, and kernels to tolerate changes in those addresses at  
arbitrary times or face broken connections or misdirected packets.   
An apparent base assumption in IPv4 was that addresses were stable  
over a "session" (be it connection-oriented or connectionless).  This  
assumption permeates every IP stack.  Given DNS root server IP  
addresses retired over 10 years ago still get 30 queries per second,  
I doubt prefixes can be expected to change by all applications in   
our lifetimes.

Rgds,
-drc

---

From: Eliot Lear <[email-masked]>
Date: Sun, 16 Oct 2005 10:00:26 +0200

David Conrad wrote:
> When multiple /19s and /20s have been allocated and there are rumors of 
> much shorter prefixes which can be justified under the current rules, 
> I'm not so sure discussions about conservation can be classified as 
> "utterly silly".

Did you see the words "beyond /48" somewhere above, David?  I'm not 
saying we should be blowing allocations like /19s and /20s (although I 
would be interested in data on that and the ).

>> In fact, SHIM6 should be able to provide equivalent of SCTP's ADD-IP 
>> to *devalue* prefix stability.
> 
> arbitrary times or face broken connections or misdirected packets.  An 
> apparent base assumption in IPv4 was that addresses were stable over a 
> "session" (be it connection-oriented or connectionless).  This 
> assumption permeates every IP stack.  Given DNS root server IP addresses 
> retired over 10 years ago still get 30 queries per second, I doubt 
> prefixes can be expected to change by all applications in  our lifetimes.

This is the purpose of SHIM6.  It is not something meant to happen 
overnight.  And it is not something that is meant as a forklift upgrade. 
  And I will be you dollars to doughnuts that those 30q/s are not 
harming any application that anyone cares about (other than generating 
unnecessary load).

Eliot

---

From: "Jason Schiller ([email-masked])" <[email-masked]>
Date: Fri, 14 Oct 2005 17:55:54 -0400 (EDT)

On Fri, 14 Oct 2005, Dan Lanciani wrote:

> Date: Fri, 14 Oct 2005 16:55:39 -0400 (EDT)
> From: Dan Lanciani <[email-masked]>
> To: [email-masked]
> Subject: Re: IPv6 Multi-homing BOF at NANOG 35
> 
[snip]
> on the horizon, and shim6 may make such a solution less likely to appear.
Dan,
You clearly state that PI allocations do not help the concern that
allowing de-aggregates in the IPv6 routing table could easily scale beyond
current hardware limitations.  I think this is what you are referring
to when you say "There is no general PI solution on the horizon..."  

But I want to point out that ARIN does have an IPv6 PI policy proposal on
the table for the end of October.  This policy does not provide a solution
to routing table growth (possibly people believe everyone's hardware will
be capable when the time comes that we need it).  

If the ARIN IPv6 PI policy gets accepted and widely implemented that PI
addresses are more likely to be leveraged by large commercial networks who
are currently doing traditional IPv4 multi-homing and traffic engineering
instead of shim6.  This may greatly decrease the support for and use of a
shim6 solution.

It seems to me that if PI has wide spread adoption then everyone will have
to commit to solving the large routing table problem in hardware.  If we
have already decided to solve the large routing table size in hardware
then why do we need shim6?  

___Jason

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 16 Oct 2005 15:53:34 +0200

David Conrad wrote:
>> change. In fact, SHIM6 should be able to provide equivalent of  SCTP's 
>> ADD-IP to *devalue* prefix stability.
> 
> 
> addresses retired over 10 years ago still get 30 queries per second,  I 
> doubt prefixes can be expected to change by all applications in   our 
> lifetimes.
> 

That is the main driver behind the way shim6 preserves the ULID (i.e.,
the address as seen by the upper layer).

The other main driver is that after 13 years of knowing that a scaleable
PI solution would make this problem set go away, we still don't have one.
(Defining PI address space that can be used by a few tens of thousands
of large companies doesn't have anything to do with IDR scaling to tens of
millions of smaller sites.) The multi6 WG did thrash out all these arguments
before converging on a direction, by the way. The only new argument I've
seen recently is the need for some support of TE functionality in shim6, which
is a very valid point but doesn't belong on this list.

Instead of predicating the future of the network on a non-existent solution,
we're designing one that has a chance of working on the scale of a billion
node Internet.

     Brian