Hi, Again, in the vein of willing suspension of disbelief...
On Friday, January 31, 2003, at 04:55 PM, Dan Lanciani wrote:
Using name strings may be no more difficult with respect to the implementation
of the name service, but it leverages far less existing code than would a fixed-
length binary identifier.
Right.
Consider the advantages of using an identifier that
has exactly the same format as what we currently call an address, i.e., 128
bits.
Or, better yet, 64 bits. Say, the lower 64 bits of a 128 bit value?.
With translation happening near the bottom of the IP layer, no changes would be necessary in tcp or in applications.
No translation would be necessary.
The problem of tcp connections
(not) surviving renumbering would disappear. The DNS would work just the way
it is, so no duplicate effort would be required.
Yup.
Multi-homing would be trivial.With a little care, multi-homing could be supported.
Assume at the end point an address consists of a 64 bit value stuffed into the lower 8 bytes of an IPv6 address with the upper 64 bits 0.
The lower 64 bits of the destination would be put into an in-addr.arpa-like tree, mapping that end point into multiple AAAAs (which have their lower 64 bits set to 0) that correspond to the edge routers associated with the multiple paths to the destination.
Packet hits the source edge router for the first time, a DNS lookup occurs fetching the multiple locators and caching them. The edge router then bitwise ORs one of the locators (how the locator is chosen is left to the reader as an exercise) with the end point address, forming a full 128 bit address. Obviously, you'd want to have the source edge router keep the cache entry up to date as long as packets are flowing to the destination (e.g., re-fetch at TTL/2 or whatever).
On the receiving end, the destination edge router receives the packet, zeros out the top 64 bits of the destination address (thereby avoiding NAT nightmares) and forwards the packet on to the destination.
Renumbering thereby becomes merely an exercise in modifying the end point 64 bit in-addr.arpa-like entry and waiting for the cache entry to time out.
End point identifiers would be non-topologically sensitive and could be permanently assigned with absolutely no hierarchy (if desired). Locators would still be topologically sensitive, but end users would never see them or know about them, thus topology changes can be done transparently.
Even more fun: assume that the first four bytes of the end point address aren't used during a transition period and the last four bytes encodes (say) an IPv4 address....
Mobility is a bit trickier due to the DNS security and caching model. However, I believe it may be possible with the use of SIG(0) and having destination edge routers act as forwarding agents for a TTL. This bit needs more thought...I suspect that mobile IP would be a lot easier as well.
In contrast, if we fix the DNS to track the topology, names would have
to replace addresses in tcp control blocks (and packets and many other places)
before we would start to see the aforementioned benefits.
Ick. Rgds, -drc -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
