> Still a few questions: > Looking at the documentation I have that Link Local address > is FE80::/64 +64 bits of interface ID. There is no place for > the zone. Do you mean that the zone will be assigned by the > IfIndex of the interface that the message was recieved by?
If I understand your question correctly, then the answer is essentially yes. Packets on the wire do not have a zone field in the header. But an interface is only in a single zone at each scope level (i.e. an interface can only be on one link, or in one site). So a packet received on an interface can be assigned a zone value based on the zone the interface is in (for link-local addresses this is often the interface index, but not necessarily). That zone value is visible to applications via the scope-id field in the sockaddr_in6 structure (assuming an implementation with a socket based API). Going the other way, if you want to send a datagram to a link-local address, the scope-id in the sockaddr_in6 is only used to identify which interface (or set of interfaces) on your machine it is allowed to go out. The zone identifier (scope-id) isn't included in the packet on the wire. > Another question: > MAC address is required to be unique (48 bits) a part of the > interface ID. Thus the Link Local assigned to it is unique... > So why we bother doing DAD? And also If the above is correct > we do not have a problem really... This issue has been long debated in the working group. My impression is that the argument was presented that since (a) there have been cases where the MAC address is not unique (card manufactors have been known to ship NICs which have the same address, for example) and (b) the degree of the problems that result from having duplicate addresses is pretty bad and (c) can be very hard to diagnose, it seemed the safest thing to do was just do DAD anyway. Occasionally various proposals come up to change this in various ways, but we should probably change the subject line before going into that. --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] --------------------------------------------------------------------
