Hello Brian,
I haven't studied the multi-link subnet draft. But, in order
to be responsive to your note before taking that time...
Brian Zill wrote:
> "DIID":
> - Nodes need to create a link-local address
> corresponding to every IID they use on a given
> link (and perform DAD on it).
> - Nodes don't need to perform DAD for non link-local
> address.
> - Multi-link subnet routers would have to defend
> link-local addresses across links, which could be
> considered confusing and nonsensical.
It seems to me that, if you allow two nodes on the same
subnet to share a link-local address, then you are really
starting to eliminate the usefulness of link-local addressing.
If I think about how a network protocol should work that
would use link-local addresses, I do not want that protocol
to know about the sub-network-layer structure of my network.
It seems to me that up until recently there was always
a (correct!) assumption that the addressability of
a "link" was co-terminous with the addressability
of the subnet using that link. In other words, the
"link-local address" was equally well "subnet-local".
Breaking this characteristic suddenly puts "link-local
addresses" outside the scope of IP, since IP deals with
putting together subnets, not structures with finer
granularity. This idea of having multiple identical
link-local addresses on the same subnet exposes IP
to a level of structure granularity for which it is
poorly equipped.
In summary, I think that the sub-network definition of
"link-local" address muddies the distinction between
network-layer addressing and layer-2 addressing, which
is a bad thing and to be avoided.
I would say that multi-link routers have to defend
link-local addresses across the network extent for which
they were defined, which is a subnet.
> "DAD":
> - Nodes don't need to create otherwise unnecessary
> link-local addresses corresponding to the IIDs they
> use for temporary or public-key-derived addresses.
> - Nodes need to perform DAD on all their addresses.
> - No strange consequences for multi-link subnets.
But I think the strange consequences are not at all strange,
if one takes a layer-3 view of layer-3 addressing concept.
Or, maybe there is a move to demote link-layer addresses
to be sub-network concepts?
And, please don't forget the negative impact on home agent operation.
> As far as implementation complexity goes, it seems to me that "DAD" is
> far simpler, since the rule is the same for all addresses and you don't
> need to create extra addresses only used for doing DAD.
But I have a rule which I think is better, for which DIID is far
simpler. Rewording:
As far as implementation complexity goes, it seems to me that "DIID" is
far simpler, since the rule is the same for all addresses and you don't
need to create extra protocol for coordinating all devices on a subnet.
The rule is that link-local addresses are unique on a subnet. This
disambiguates nodes on a subnet from the perspective of network-layer
protocol, which is an appropriate function for a network-layer address.
> Regarding efficiency, I think it depends upon whether a node has more
> prefixes or IIDs. For nodes on a link with lots of prefixes, "DIID"
> saves a little bandwidth by not having to do as much DAD.
Or, in the case I was discussing, a LOT of bandwidth at an important
time when responsiveness is important for the user experience,
if we get to the point of utilizing IPv6 capabilities for many
subnet prefixes. I'd like to keep that possibility open for the
future.
> For nodes
> with lots of IIDs, "DAD" saves node resources related to configuring
> twice as many addresses. Offhand, I'd be tempted to give the edge to
> "DIID" here, but since I've seen various creative proposals for using
> large numbers of IIDs per node, it's not clear. My machines generally
> have more IIDs then prefixes. But I think the numbers have to get
> pretty significant in either case before these concerns begin to matter.
You are right. And, in fact, my understanding of IID is that each on
gives another (real or virtual) _network interface_. Since multiple
IIDs define multiple network interfaces, a remote node shouldn't be
able to tell whether or not different IIDs belong to the "same" node.
Nodes without a link-local address almost seem to not have a
(real or virtual) network interface. That doesn't seem right
to me. Maybe that is the flip side of an "unnumbered interface",
a sort of "extraneously-numbered non-interface".
> The multi-link subnet router issue is more clear. "DAD" is a better
> architectural fit. Link-local addresses stay link-local and don't
> become these quasi-subnet-local addresses that are unique across the
> subnet but only reachable on-link.
This would be wrong. A link-local address SHOULD be reachable
over all parts of the subnet, and it would be the responsibility
of the multi-link subnet router to make it happen. I don't think
"DAD" is a better architectural fit to the IP model of subnet
addressing, unless you are also willing to jettison the network-layer
significance of what "link-local" address was supposed to mean.
Regards,
Charlie P.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
