Subject: Re: [RAM] candidate properties of some new name types

From: [email-masked] (Noel Chiappa)
Date: Tue, 16 Jan 2007 17:52:32 -0500 (EST)

> From: RJ Atkinson <[email-masked]>

    > Locators:
    > - A Locator names a single sub-network, not an interface or node

Ran, I am really unhappy with this, because it means you have to identify the
individual interface on that sub-network (aka physical network) from some
other field/name/bits, which presents a whole host of potential problems.

E.g. if you're on an 801-style network, and you get the interface's 801
address from the identifier, then i) if a host has two interfaces, which have
different 801 names, how/where do you get the bits for the 801 name for the
second one (without having two identifiers, which kind of defeats the whole
point); ii) if you want an identifier which is none of your 801 addresses,
how do you get any of the 801 addresses; etc, etc? And of course all of this
entangles the identifier name with the location name, a bad idea right there.

And on networks which don't use IEEE 801 style addresses, where does the name
of the interface in the local network's namespace go/come from? Are you
assuming some sort of broadcast/database/etc lookup mechanism that you can
use to translate identifiers to local network interface addresses? What do
you do on networks that don't support network-wide broadcast? Use a database?

Etc, etc, etc. Really, not a good idea.

The locator names the interface, and provides in and of itself all the bits
that you need to get the packet to it. End of story.,

    > - A Locator is only used for routing and forwarding packets,
    > except that the last-hop router uses both the Locator and
    > the Identifier to look up the destination link-layer information
    > (e.g. MAC address) in the ARP/ND cache inside the router.

See previous comments, e.g. about why mixing naming and location function in
two names is really not a good idea.

    > Identifiers:

That all sounds OK to me.

	Noel

PS: And why are we discussing this on a routing-specific mailing list, anyway?

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 16 Jan 2007 18:59:30 -0500

On  16 Jan 2007, at 17:52, Noel Chiappa wrote:
> address from the identifier, then i) if a host has two interfaces,  
> which have different 801 names, how/where do you get the bits for  
> the 801
> name for the second one (without having two identifiers, which kind  
> of defeats the whole point);

I think IPv6 ND could almost handle the case you describe right now,
without having to resort to separate IDs for each interface.  I'm
confident that ND could be enhanced (very slightly) to permit that
if it can't already do it today.

> ii) if you want an identifier which is none of your 801 addresses,
> how do you get any of the 801 addresses; etc, etc?

IPv6 ND is an example that works fine.  In IPv6, the low-order 64
bits might or might not actually be the link-layer address for that
interface.  IPv6 ND already handles both cases (that it is and that
it isn't the link-layer address).

> And of course all of this entangles the identifier name with the
> location name, a bad idea right there.

Well, they aren't entangled that way, if you follow my examples above.

> And on networks which don't use IEEE 801 style addresses,
> where does the name of the interface in the local network's
> namespace go/come from?

There are a range of options.  For now, I don't want to close any
doors.  Just to stimulate thinking, HIP derives IDs from hashes
of public keys, IPv6 can derive the ID directly from the link address,
or ...

> Are you assuming some sort of broadcast/database/etc lookup mechanism
> that you can use to translate identifiers to local network interface
> addresses? What do you do on networks that don't support network- 
> wide broadcast? Use a database?

In IPv4, we have an ARP Cache.  In IPv6, we have an ND Cache.
With IPv6, the current practice is to use ND on all link types,
not just those with a link-scope broadcast/multicast capability.
So network::link location resolution really isn't rocket science.

> The locator names the interface, and provides in and of itself all  
> the bits that you need to get the packet to it.

That would be an alternative approach, and a somewhat different
architecture.  It is limiting in various ways, for example with
respect to mobility.

> See previous comments, e.g. about why mixing naming and location  
> function in two names is really not a good idea.

It isn't mixing them.  The Locator names the subnetwork.  The
Identifier names the node.  One merely uses the name of the node
when indexing into the ND/ARP cache -- that is not the same thing
as tying the node name to its location at all.  The node name does
not vary as location changes, only the subnetwork name varies,
and the subnetwork name always follows the topology.

> That all sounds OK to me.

Well, it is reassuring to hear that. :-)

> PS: And why are we discussing this on a routing-specific mailing  

One possible approach to resolving (some, all of) the current
operational routing issues (e.g. table size, mobility, multi-homing)
would be to migrate to a new naming/addressing/routing architecture.

Cheers,

Ran