David Conrad <[EMAIL PROTECTED]> wrote:
|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?.
|> 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.
|
|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".
I was actually referring to the practice of inserting 48-bit (or even 64-bit)
hardware identifiers into the address in the name of easy configuration.
|> |No translation would be necessary.
|> You have to translate somewhere, if not at the bottom of the host's
|> stack
|> then at what you are calling edge routers.
|
|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.
Even if you don't consider the zeroing a translation (and I would probably
debate this if it made any difference), the mapping of (0, 64-bit identifier)
to (64-bit locator, 64-bit identifier) is certainly a translation as much
as the mapping of (128-bit identifier) to (128-bit locator). The property
of being able to encode the identifier into higher-layer protocols without
the need for NAT gymnastics is a function of hiding the translation from
all the higher layers, not of the simplicity of the translation function.
My proposal also hides the locator and thus has the same property.
|> |> With a little care, multi-homing could be supported.
|> |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 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'.
I would not want to depend on the edge router's having that kind of knowledge
of the locator routing system just to make multi-homing work for other sites.
(It would be one thing to require multi-homed sites to do this, but you are
talking about making everybody do it.) I think it would be better to explicitly
track only those targets that are being used. Hopefully icmp messages could do
most of the work along with something akin to stale route discovery.
|> I proposed to short-circuit the timeout by having nodes try where
|> possible
|> 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.
|
|Right (I think -- I had suggested the edge routers act as forwarding
|agents for a TTL, is this what you mean by short-circuiting?)
I'm not sure what you meant by forwarding. I simply meant that a node
or edge router that is renumbered can send an alert to its known peers
suggesting that they dump their cached data even though its TTL has not
expired.
|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.
My proposal can definitely work (and was originally intended to work) directly
on end nodes. It can be pushed into edge routers as well, but it doesn't have
to be. But it isn't obvious to me why your version can't work on an end node
too.
|Oh yeah, and traceroute
|from the end points would be useless.
If the translation happens at the end nodes I would obviously propose an
escape mechanism in the API to deal with locators instead of identifiers.
Obviously we would want to discourage use of this escape by other than
debugging programs. :)
|However, this (and similar) approaches have the advantage that we
|continue to use known technology (CIDR,BGP4+,etc) in the core where it
|matters...
That advantage makes for a good thought experiment, i.e., to show anyone with
an open mind that it can be done. Whether we really want to help perpetuate
the current archaic routing system by building a layer like this is still open
to debate. Clearly adding a layer is better than doing nothing; however, I'd
like to think that we can ascertain a pure routing solution that is isomorphic
to the split solution. Again, we are really talking about source routing and
there are quite a few ways to implement source routing.
Dan Lanciani
ddl@danlan.*com
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
