At 9:59 AM -0400 6/27/00, Jim Bound wrote:
>Also I have no issue of prefixes spanning multiple
>links unless the following happens.
>
>Node A on link1 has fe35::1 as global address.
>
>AND
>
>Node B on link2 has fe35::1 as global address.
>
>Because when the prefix spanned multiple links (link1 and link2) Node A
>and B have the same link-local address 64bit ID in this case Unicast
>Aggregate Format for this discussion.
Part of the (not-yet-written-down) work of supporting multi-link subnets is
making sure that the routers that connect a multi-link subnet ensure that
DAD messages are relayed/proxied to all links in that subnet (or in some
other way detect and prevent duplicate interface IDs being used within the
subnet).
In theory, it would be OK for link-local IPv6 addresses to be duplicated
on different links within the subnet (because they would still be scoped
to a single link); only the site-local and global addresses would
have to be unique across the subnet. But the practice of doing DAD only
on the link-local address and then auto-generating the larger-scope
addresses from that means we'd really want to just do DAD-relaying for
all address types.
>They end up with the same global address meaning they are not global by
>my definition.
Right, that has to be prevented.
>Oh yeah. My assumption of a global address may be different than yours?
It sounds like it's the same. You just didn't explain your specific
concern well enough for me to understand before.
>So ND would have to make sure also that the link-local is unique across
>the multiple links. That could be difficult.
Could be, but I don't think so.
One thing we could have done to make this work more cleanly (i.e.,
eliminate the need for special-case DAD-relay function in the routers
in multi-link subnets) is to define a "subnet-local" multicast scope
(greater than or equal to link-local), and then require DAD to use
subnet-local multicast. But it's not worth trying to change that now,
and the DAD-relay idea should suffice
You still didn't explain what you think is Very Important about any of
this.
Steve
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
