Eliot Lear <[EMAIL PROTECTED]> 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 PROTECTED]> 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 [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
