On 2012-03-22 09:43, Fred Baker wrote: > On Mar 19, 2012, at 11:55 AM, Sabahattin Gucukoglu wrote: > >> I've obviously not been doing all my homework, and RFC 4007 slipped my >> attention. Worse, for all the communication my IPv6 nodes are doing amongst >> themselves using link-local addresses, it's never really been much more than >> a hastily-justified curiosity why, when I ping one from the other using >> link-local-scoped addresses, I have to put in this zone identifier (%ifname >> on BSD and Linux). > > To be honest, I'm still not sure I understand the argument for a zone > identifier.
I've always viewed them as a fault diagnosis tool, mainly. But the first paragraph of section 6 of RFC 4007 makes a stack implementation argument: >> 6. Zone Indices >> >> Because the same non-global address may be in use in more than one >> zone of the same scope (e.g., the use of link-local address fe80::1 >> in two separate physical links) and a node may have interfaces >> attached to different zones of the same scope (e.g., a router >> normally has multiple interfaces attached to different links), a node >> requires an internal means to identify to which zone a non-global >> address belongs. This is accomplished by assigning, within the node, >> a distinct "zone index" to each zone of the same scope to which that >> node is attached, and by allowing all internal uses of an address to >> be qualified by a zone index. In other words if the IETF doesn't define the zone index, every implementor will have to do so anyway. Also, read the last clause carefully: it says the stack MUST allow OPTIONAL use of the zone index internally. > From MIF's perspective, if the same prefix is placed on multiple interfaces, The prefix fe80::/10 is automatically on every interface. That's the only case where I'm certain we need a zone index in practice, but the definition isn't limited to that case. Brian > the system might see peers using a given address on multiple interfaces, and > at least some devices might be expected to route between the interfaces. > Architecturally, this can be easy to solve or hard. We have any number of > cases (think about PPP for example) in which we bundle multiple interfaces > under a common super-interface and "do something". In PPP Multilink, we might > segment messages into smaller frames, distribute them across a number of > interfaces to the same place, and reconstitute the original message on the > other side. In this case, it seems that we want IP to use two layers of > interfaces, a virtual one instantiated by multiple lower layer interfaces, > and place the prefix on the virtual interface. When we are wondering what MAC > address should be associated with a given IP address, we ask each of the > lower layer interfaces, and if we get a result on one of them we know where > we're going. The big issue will be routing among the physical interfaces - > something req uired for it to be seamless and yet not as trivial as it might sound. >
