Date: Thu, 21 Feb 2002 12:41:50 +1300
From: "Sean Lin" <[EMAIL PROTECTED]>
Message-ID: <005d01c1ba68$2b360450$4e07a8c0@tukia>
I don't think there is a lot of point having this discussion again, so
this will be my last message about it, but ...
| I mean from the other nodes point of view it's
| just another link-local address ( well, as long as
| when it determines what the address type is, it matches for fe80::/10 and
| not fe80::/64
But that, and ...
| using the format fe80::<id>:<interface-id>, would allow a single link-local
| addresses
| to be shared among various interfaces on the node and will also enable the
| node to determine
| which interface a destination link-local address is going out of.
that are incompatible. Either the <id> specifies the interface (and thus
is a part of the prefix, not the per link identifier), or it does not, you
can't really have it both ways.
You also need to consider what happens when the address reaches another
node, consider A which has 5 interfaces (1, 2, 3, 4, 5 are the id's we'll
assign to those), and B which also has 5 interfaces (and big surprise,
since it comes from the same vendor, it also calls them 1 2 3 4 5). Then
know that the link from interface 2 on A connects to interface 4 on B.
Now A sends a packet from its LL addr fe80::2:wwww:xxxx:yyyy:zzzz
B gets that packet and wants to reply to that address, the '2' in there
was A's interface number, means nothing to B at all (certainly sending
out interface 2 won't work).
It is possible to make all of this work (B would see the packet arrived on
the interface it calls 4, and rewrite the address to fe80::4:wwww:xxxx:yyyy:zzzz
but now the nodes need to be aware that the <id> part of the
address is volatile.
The other approach, and the one that was actually suggested when this
was proposed, is for A to actually put fe80::wwww:xxxx:yyyy:zzzz in the
packets it sends. This allows B to just use current methods if it
prefers, and means that everyone can predict what the address on the wire
will be, which simplifies (a little) the protocol implications. That
is, the id in the LL address would be used only in the API, not on the wire.
| Also, why
| not fe80:<zone-id>::<interface-id>
| instead of address%<zone-id>? Then you wouldn't have problems described in
| draft-ietf-ipngwg-scoping-arch-03.txt for URLs
Yes, that was the attraction of this approach, it would simplify the user
interface (and API)_, at the expense of complicating the protocols.
I suspect that the decision is mostly based upon the observation that
the human interface to link local addresses is very rarely ever used,
most applications will be told to use other addresses, most of the time.
Only net manager type people are likely to manually ever use LL addresses
(especially when there is more than one active link to cause confusion).
And most of the API details can be buried inside library routines, so
applications mostly don't have to care wither way.
On the other hand, all protocols have to deal with the possibility that
they might be told to use LL addresses, and so everything is going to have
to deal with the implications of that if the addressses suddenly started
to contain volatile components (something different on the wire, or at
the remote node, from what the application sees).
In any case, you can rest assured that this was all considered in the
past (5-6 years ago now I think) - it isn't just something that no-one
considered.
kre
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
