Dan,
On Saturday, February 1, 2003, at 09:35 AM, Dan Lanciani wrote:
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.
One allocation mechanism is pretty much as good as any other. Doesn't
matter how those 48 or 64 bit numbers are allocated, the EUI registry
would be fine. What matters is there is a separation and a mapping
between those identifiers and locators.
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).
I agree that the terminology doesn't matter (I actually viewed it more
along the lines of pushing a locator onto the address at ingress,
popping it off at egress -- I liked the x-kernel work of long ago).
What is important is the separation of the locator from the end point
and the ability to map between the two.
My proposal also hides the locator and thus has the same property.
Yup. I was merely making the assumption that zero'ing would be faster
than table lookup and copying. However, given this is an edge
function, it probably doesn't matter all that much.
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.
Hmmm. Multiple ways to solve this, of course. E.g.: the source edge
router does a lookup, gets back a bunch of locators. A naive
implementation could simply pick one and forward to the core via
default. Getting back a network unreachable could trigger the naive
implementation to pick a different locator. The more elaborate the
edge router gets in terms of routing system knowledge, the more
effective the multi-homing would be.
I'm not sure what you meant by forwarding.
The old destination edge router gets a packet for an end point
identifier that has left the network the old edge router is responsible
for. The old edge router does a lookup of the destination identifier,
gets the new locator (if it doesn't already have it), and forwards to
the new edge router. It would need to do this for the TTL of the old
locator. This is why I believe this approach would work with mobility
-- in this context, mobility is just a more dynamic form of
renumbering. Yes there may be security issues here in the general case
-- need to think about it more.
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.
It would. The reason I favor the edge router approach is that I wanted
something that would work with IPv4 as a transition aide...
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.
Baby steps...
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]
--------------------------------------------------------------------
