Dan, On Friday, January 31, 2003, at 11:27 PM, Dan Lanciani wrote:
|Or, better yet, 64 bits. Say, the lower 64 bits of a 128 bit value?.Given there is no need for hierarchy, there is no need for wasteful allocation policies (the end point addresses could be allocated sequentially FCFS or even randomly). I have a bit of trouble believing 18,446,744,073,709,551,616 sequentially assigned addresses would be insufficient for "the foreseeable future".
Sure, this has been proposed before, but I think the main complaint was
that 64 bits is no longer enough for the wasteful allocation policies we
have adopted.
|No translation would be necessary.I guess it is a question of terminology: there is no translation done on the end point identifiers, thus they can be encoded into higher layer protocols (e.g., ftp) without need of NAT gymnastics. The only "translation" done would be the zeroing out of the high order 8 bytes on reception at the destination edge router which would presumably be faster than a table lookup.
You have to translate somewhere, if not at the bottom of the host's stack
then at what you are calling edge routers.
|> With a little care, multi-homing could be supported.I would assume the edge router would 'know' the reachability of the prefixes returned by the DNS query allowing for failover to be handled the same way it is handled today (more or less). Simple AS hop games can be played to pick the 'best'.
|Multi-homing would be trivial.
Some care would be required to get failover to work. This isn't completely
trivial, but it need not be a big deal.
I'd honestly be happy with either. The advantage I see in the DNS is that it exists, is relatively well understood, and has the necessary attributes (global scalability, security (if you believe DNSSEC will ever be deployed), and caching). However, we have learned a lot about what the DNS got wrong and a new mapping service could allow us to finally put a bullet in DNS's head...|The lower 64 bits of the destination would be put into an |in-addr.arpa-like tree, I like my specialized mapping service, but sure...
I proposed to short-circuit the timeout by having nodes try where possibleRight (I think -- I had suggested the edge routers act as forwarding agents for a TTL, is this what you mean by short-circuiting?)
to give a hint to known peers that a renumbering event had occurred. This
can also be handled either at the end points or at the edge routers.
In any event, from my perspective the big problem with this approach, regardless of whether the DNS is used or not, is the need for edge routers at both ends to be involved. This results in a chicken and egg problem that I'm not sure how to get around. Oh yeah, and traceroute from the end points would be useless.
However, this (and similar) approaches have the advantage that we continue to use known technology (CIDR,BGP4+,etc) in the core where it matters...
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]
--------------------------------------------------------------------
