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. >