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

From: Dan Lanciani <[email-masked]>
Date: Sat, 15 Oct 2005 17:11:37 -0400 (EDT)

Eliot Lear <[email-masked]> wrote:

| (I wrote)
|> 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.
|
|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.

I'm not sure what you mean by ``would be.''  The argument has already been
made.  See, e.g., 

http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-48boundary-00.txt

In any case, I agree completely that the IETF cannot legislate prefix lengths
and that providers can still find "revenue opportunity" in address rental.
That was exactly the point I was trying to make in responding to the previous
comment which you snipped (and which has nothing to do with shim6 per se):

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

[...]
|The smallest allocation granularity for IPv6 is supposed to be a prefix,
|not an address, for that reason.

(end quote)

|> 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).)
|
|This is a matter of timescale.  Prefixes should be expected to change. 

Exactly.  And thus you have another "revenue opportunity" (I like that
phrase):  charge more for stable addresses.

|In fact, SHIM6 should be able to provide equivalent of SCTP's ADD-IP to 
|*devalue* prefix stability.

Shim6 should be able to do a lot of things.  Since it requires insertion
of a mapping layer into all existing stacks that are to participate, its
deployment already represents a retrofit on the same level as would a
more general solution.  But shim6 is not (at the moment) a general solution;
it's a multi-homing solution with some constraints on the underlying PA
addresses.

|> 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.
|
|The whole point of SHIM6 from my point of view is quite the opposite by 
|providing a means to advertise access via other prefixes.

Except that shim6 is not a general PI solution.  It is only a multi-homing
quasi-solution.  As currently proposed it does nothing to replace the other
desirable attributes of PI addresses/identifiers.  I would be delighted with
a shim6-like solution that allows stable identifiers to be built atop one or
more unstable locators.  In fact, I've proposed such approaches on several
occasions over the years.

|So could you 
|please justify your above statement?

I thought I made this pretty clear in the portions of my note which you
snipped, but I'll try to run through it one more time.

-Scalable PI space without distributed routing tables probably requires
a full identifier/locator split.

-An identifier/locator split almost certainly requires changes to existing
code to accommodate a mapping layer.

-Shim6 provides a replacement for one useful attribute of PI space (multi-
homing) by leveraging a partial identifier/locator split.

-Shim6 requires changes to existing code to accommodate a mapping layer.

If shim6 is deployed then one of the problems caused by the lack of a general
PI solution will be "solved" thus reducing the impetus to find that general
solution.  Deployment of shim6 requires changing a lot of existing code.
Convincing the world to change all the code a *second* time is going to be
a much harder sell.  Implementing a general solution in the presense of
deployed shim6 would itself be more difficult because of the interaction
of two very similar mapping layers.

				Dan Lanciani
				ddl@danlan.*com

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

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 16 Oct 2005 14:25:19 -0700

> of two very similar mapping layers.

Dan,

The issue I have with your description is that you assume that the 
"mapping layers" are actually of similar complexity, and AFAICT they are 
quite different; the shim uses a "re-mapping" layer (which remaps the 
ULIDs to alternative locators it has exchanged with the peer). But for a 
generalized identifier/locator split you need a mechanism to *lookup* an 
identifier to find some working locators.

The complexities of defining such a lookup mechanism is nothing that the 
shim needs; the complexity is closely tied to what the identifier name 
space looks like (hierarchical allocation, and HIP-style hashes are two 
examples).

A complete identifier/locator split would also need to redefine what 
information goes in the DNS (e.g., should we have some form of ID RRs or 
not?).

If and when we have workable solutions for those pieces, we can still 
reuse the shim as the mechanism for providing failover between different 
locator pairs. So I don't see how *technically* doing the shim prevents 
people from working on the above, hard problems.
We already have HIP exploring one way to do this (based on a flat ID 
space). If folks want to explore doing it based on a hierarchical ID 
name space as well.

    Erik

---

From: Julien Laganier <[email-masked]>
Date: Tue, 18 Oct 2005 11:34:37 +0200

On Sunday 16 October 2005 23:25, Erik Nordmark wrote:
> "mapping layers" are actually of similar complexity, and AFAICT
> they are quite different; the shim uses a "re-mapping" layer (which
> remaps the ULIDs to alternative locators it has exchanged with the
> peer). But for a generalized identifier/locator split you need a
> mechanism to *lookup* an identifier to find some working locators.
>
> The complexities of defining such a lookup mechanism is nothing
> that the shim needs; the complexity is closely tied to what the
> identifier name space looks like (hierarchical allocation, and
> HIP-style hashes are two examples).
>
> A complete identifier/locator split would also need to redefine
> what information goes in the DNS (e.g., should we have some form of
> ID RRs or not?).

FWIW, there is a HIP WG I-D proposing to define a new RR to store HIP 
identifiers.

> If and when we have workable solutions for those pieces, we can
> still reuse the shim as the mechanism for providing failover
> between different locator pairs. So I don't see how *technically*
> doing the shim prevents people from working on the above, hard
> problems.
> We already have HIP exploring one way to do this (based on a flat
> ID space). If folks want to explore doing it based on a
> hierarchical ID name space as well.

HIP had, some revisions ago, two types of identifiers: flat (public 
key hash) and hierarchical (concatenation of prefix and public key 
hash). We chose to drop the hierarchical flavor because at that time 
there was no strong support to keep them. If there is now interest 
one can try to revive them. 

--julien

-- 
julien