Jeroen Massar wrote: > [?Does this need to keep going to both ietf@ietf.org & ipng@sunroof?] > Not as far as I am concerned. If we take the suggested path, the work is clearly outside the IPv6 WG, and anyone on the IPv6 list that cares to follow the discussion is now aware of it. I will be dropping ipng from any further responses to this thread. > My current idea puts it at the resolver level. The > application gets the 128bits identifier, which actuall is a > IPv6 address, either given out from a special registry or > simply from an /48 that is already assigned to you. This > address can be used for both routing and identification > purposes and can easily be assigned to hosts by using RA. > > The stack/API then maintains a list of routing IP's that > are associated by that "IdentifierIP" and then replaces it > before it enters the network with the routing IP that is to > be used for actually routing the packet. On initial > communication there could be an extra header sent along which > says "this packet originates from this Identifier IP" along > with a signature, verifyable through eg DNS to check it is > really it. HIP is much further there though. The only issue is the slight of hand in 'The stack/API then maintains a list of routing IP's ...'. It would appear your assumption is that L4 or below would perform the substitution magic, and have a protocol to communicate to the peer what the magic is. I am saying that this should simply be a formal layer between L4 & L7. This avoids messing with existing lower layers which would create compatibility issues both for the peer node, as well as application expectations about what the lower layers do. > > This way apps don't need to know about it, they only need > to know about IPv6. One could also pass this along to IPv4 > except then it needs an extra magic packet for the IDIP. See > HIP again. And I am thinking about using the above for > solving a little problem for dynamic hosts in the SixXS project. So you prove my original point, 'there is a sacred invariant, and we must avoid messing with the app / transport interface at all costs'. Everything you described would fit cleanly in an entity that sat between L4 & L7. In fact from an architectural perspective, the "IdentifierIP" you describe would be the name of the point in the stack shared by all interfaces & transports. It really doesn't matter if that name is variable length ascii, or fixed length binary, but I am sure many will share their favorite opinion. Tony