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