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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf