[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-kurtis-multihoming-longprefix comments
On Tuesday, January 7, 2003, at 06:29 PM, Tony Li wrote:
Perhaps I misunderstand, but I don't see why this is the case.
16+16 would be very visible to the apps. In fact, any change that has
independent identifiers and locators would be a change to the apps.
If you assume a border between the part of the network that cares about
topological significance (that is, the core) and the part that does
(that is, the end points), then doing mapping/unmapping at that border
would be invisible to the applications -- the core only cares about the
locator, not the end point identifier.
For example, assume you throw out the current IPv6 address architecture
and instead say that the lower 4 bytes of an IPv6 address is an IPv4
address. Now, assume reality in the on the non-core side of the border
gateway, end users use IPv4. When a packet needs to transit the (IPv6
using) core, the border gateway does (the moral equivalent of) a
(dnssec signed, of course) AAAA in-addr-style DNS lookup of the
destination IPv4 address and synthesizes an IPv6 destination address
composed of the destination IPv6 prefix returned by the DNS lookup (in
the top half) and the destination IPv4 address (in the bottom half).
When the packet hits the destination border, an IPv4 packet is
synthesized from the lower 4 bytes of the IPv6 address. If you don't
want to assume reality, use up to 8 bytes (or more, since we've agreed
to throw out the existing IPv6 addressing architecture) for the end
point identifier -- the in-addr-style lookup wouldn't care.
Site multi-homing becomes trivial -- simply add additional prefixes in
the RR set referenced by the in-addr-style lookup of the IPv4 host. If
you want to get tricky, the border gateway could keep information about
which prefix is best among the ones returned. Renumbering also becomes
essentially a non-issue as it can be made transparent to the end users
since end users are dealing with non-hierarchical identifiers.
Mobility might also be simplified, although I think there are some
issues wrt trust boundaries that need more thought.
Of course, this is just an example of how one could implement a
locator/identifier mapping mechanism that doesn't require apps to
understand that mapping -- the key is to have a way of doing an