First, my thanks to Jari for agreeing to the second last call. Some further
comments below.
At 12:38 AM +0200 10/30/06, Jari Arkko wrote:
We are last calling this document for the second time, for
two reasons. The first reason is to make sure that the
last call has been circulated widely enough in the
community.
The second reason is that we want to call the attention
of the IETF community on the specific issue of using
IPv6 addresses as identifiers in this manner. To summarize
the background, the document suggests the allocation
of a temporary experimental block out of the IPv6
address space for the purposes of easing experiments
that deal with identity-locator split. In particular the
HIP community wants this in order to be able to run
unmodified applications. The allocated address space
would be used to represent identifiers in the place
of addresses in the existing APIs. While the long-term plan is
to use new APIs that reflect the semantics appropriate
for identifiers, the ability to experiment without having
to upgrade all applications is important.
I strongly suggest folks actually read the document,
rather than relying on the summary above.
In my own reading, there were a couple of issues that
struck me as potential problems. The first is that this draft
has a view of how applications interact with IPv6
addresses that it somewhat unidimensional. It presumes
that the application always passes IPv6 addresses "down" the stack
where a routing layer takes care of them. That leads to the idea
that inserting a shim between the application layer and the
routing layer can introduce new functionality without
changing the way in which addresses pass across those APIs.
That may be true, but it is certainly not the only way in
which applications pass IPv6 addresses. Two trivial examples
which do not pass that way are the IPv6 addresses given in
SDP packets and the IPv6 addresses which may appear in
URIs. By choosing to retain the same syntax (but not the
same semantics) as the basic IPv6 address, the draft may
be making it possible to pass them "down" through shims,
but it is also guaranteeing that if they leak out through
application-layer pointers, that non-participating hosts
will not know that they cannot be passed to the routing
system. Once there, they will (hopefully, anyway) not
be routable, which will give some pretty hard to diagnose
errors for the non-participating users. The draft is careful
to note that this should be used only among consenting
hosts, but there is no clear way to determine if a host
is participating.
It is also somewhat problematic that the range set aside
may be used for *any* experimental use of this type
(not just, say, HIP). I encourage folks to read the draft
and see if they believe it would be possible for a host to
participate in multiple experiments of this type, or if it
would be effectively limited to a single shim. In that same vein,
imagine the case where an application layer pointer is sent
to a host that is participating in a *different* experiment
from the one originally meant.
Stepping up a few thousands of feet, I believe that the
draft's setting aside these syntactically-but-not-semantically-equal
addresses is implying a value judgement that this is the
appropriate way to conduct experiments of this type. While
it *may* be true for one or more experiments, that meta-statement
is not yet born out by experience, and encouraging that choice
seems to run ahead of our facts. Though this draft discusses
"overlays", there is no requirement that these systems be overlays in the sense
of the term I see used most commonly; they do not have to fit into the
same class as one-to-many VPNs, MPLS LSPs, or any of the
overlay-as-tunnel mechanisms we commonly see. Instead,
they may rely on the resolution of one class of identifier before using
the common routing system (and there is no guarantee that any
of what was present before the shim did the resolution will be
present after). There may well be resolution mechanisms to be
tested here which would be much more effective if they did not
presume that the input syntax and output syntax had to be the
same. Setting aside the range in the way this draft does
seems to imply that the answer *should* lie in the class of resolutions
where the syntax is the same on both sides of the resolution.
Fundamentally, these identifiers are not v6 addresses at all. Setting
aside a portion of the v6 address space in this way risks, in my
mind, pushing us further down a bad road, where that syntax
is fundamentally meaningless without a context. This is bad because we have
not successfully designed a mechanism for indicating that context.
Leaving the semantics of these identifiers reliant on inference is
a recipe for poor performance and, possibly, outright failure.
regards,
Ted Hardie
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf