Hello Brian,
As I wrote before, but perhaps buried in other text, I think that IP should only be concerned about the "subnet-local" concept, not the "link-local" concept, if we are to use those terms as distinguishable concepts. When the link-local addresses were being first discussed, I don't remember any discussion that suggested that a "link" should have a different extent than a "subnet". It seems to me that all IP-level protocols need to have "subnet-local" addressing, not the newer proposed definition for "link-local". As I tried to point out in my previous message, IP doesn't have any business messing around with details about how the subnet is actually constructed. Thus, to restate, I believe that "link-local" addresses are not required to traverse the entire extent of the physical medium on which a subnet is defined, then they are useless for IP protocols. Perhaps it would be better to rename these addresses (FE80::/10) to be called "subnet-local". Do you have examples of protocols that properly use "link-local" addresses instead of "subnet-local" protocols? It seems to me that DAD, multicast, router advertisements, and Mobile IP all need to have the "subnet-local" property, and I can't think of any network-layer use for the non-network-layer definition of "link-local". Regards, Charlie P. Brian Zill wrote: > > Hi Charlie, > > > I haven't studied the multi-link subnet draft. But, in order > > to be responsive to your note before taking that time... > > I guess we're just going to have to disagree about link-local vs. > subnet-local. These are two distinct scopes and should be treated as > such by the architecture. One shouldn't assume that because you can > reach a node via a global address in the same subnet prefix as you that > you can also reach it via a link-local address. "DIID" breaks this by > making the false assumption that these scopes are equivalent. > > The whole point of multi-link subnet routers is to allow multiple links, > of possibly different physical characteristics, MTUs, etc, to belong to > the same subnet. And to do it in an architecturally consistent way. A > multi-link subnet router is a real router that drops the hop count > between links. It leaves link-local addresses as unique on their link, > as it should. > > Maybe we should define unicast address prefixes for each scope as we > have for multicast, so there would be subnet-local unicast addresses. > That would allow people who want to do things on a subnet, rather than > link, basis to do so. > > > And, please don't forget the negative impact on home agent operation. > > You would have the same problem with "DIID" if the mobile node has a > large number of home addresses that differed in the IID part. As I > noted in my earlier mail, there are plenty of creative proposals for > using lots of IIDs per node, just as I suspect there are some for using > lots of prefixes per subnet. Let's not break the architecture here over > a optimization that has a lot of questionable assumptions in it. > > If we can't live with "DAD", then I'd much prefer we revise the whole > duplicate address detection mechanism. Currently DAD has two serious > flaws and one major inconvienience: It doesn't protect against duplicate > addresses on reconnected networks (something I would think would happen > a lot on some types of wireless links), it doesn't document a recourse > to take when your only address is a duplicate (retry with a random > address is the obvious solution, but that isn't standardized like EUI-64 > is), and it takes longer than we would like. > > --Brian -------------------------------------------------------------------- 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] --------------------------------------------------------------------
