Jeroen Massar wrote:
[?Does this need to keep going to both ietf(_at_)ietf(_dot_)org &
ipng(_at_)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