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.