"Soliman, Hesham" <hsoliman@xxxxxxxxxxxx> writes: > > I'll start with my protocol question: > > > > 7.2.7 Anycast neighbor announcements > > > > - "Second, the Override flag in Neighbor Advertisements SHOULD be > > set to 0, so that when multiple advertisements are > > received, the > > first received advertisement is used rather than the most > > recently received advertisement." > > > > How does the Override flag work when you advertise an included > > prefix? > => I don't understand the question. The NA can only include a unicast > address. You can't include a prefix in the NA. I also don't understand the question. The override flag is only carried in NA messages, and thus refers to the target address (i.e., one unicast address). > > 4.1 router solicitation message > > > > - Source link-layer address > > > > "The link-layer address of the sender, if known. MUST NOT be > > included if the Source Address is the unspecified address. > > Otherwise it SHOULD be included on link layers that have > > addresses." There is no reason to include it if the source address if the RS is an unspecified address. By definition, the unspecified address is never used as a destination address. Thus, the router can't just insert the source address of an RS into the destination address of an Ra and send the packet directly. Morever, since there is no source address, there is no updating of the neighbor cache. I suspect (but have forgotten) that the MUST NOT is to preclude some mischief from happening if the router actually did try to use that link-layer address in conjunction with an unspecified address. It is also not a MUST to include on link layers that have addresses because a router doesn't have to respond with a unicast RA back to the requestor. It can multicast to the all nodes address instead. So the SHOULD is to give the router the option of sending back a unicast RA. If there was a more specific reason why the SHOULD was not a MUST, I don't recall any more why that was. Now whether any of the above needs to go into the document explicitely, I have my doubts... > > 4.2 router advertisement > > > > - "Note: If neither M nor O flags are set this indicates that no > > information is available via DHCPv6." > > > > This means that the responding router always knows if DHCPv6 is > > definitely available or definitely not available. Is there any > > possibility that the responding router might not know? yes. But there is little we can do about this. In hindsight, the M&O bits (IMO) should probably never have been defined at all. Indeed, they are classic case of "define the field first, figure out later how to make it useful". The M&O bits were defined long before we had DHCPv6 in place. As James Carlson has also observed, life would be simpler if there were no (protocol) distinction in DHCPv6 between asking for "all" parameters and asking for "other" parameters. Then we wouldn't need two bits. And life would be simple if all nodes just invoked DHC (regardless of what the M&O bits said -- precisely so that the router wouldn't have to worry about setting them correctly). But some folk did/will complain about always invoking DHC. On wireless WAN links, where "every packet costs someone money", folks have made a lot of noise about NOT having nodes invoke DHC if there is no DHC server available. In those (heavily managed infrastructures) it is no problem having the DHC story and the M&O settings on routers be consistent. However, for home networks, it's less clear how to ensure things are in sync... So, no solution is perfect. If you assume a managed infrastructure, setting the bits correctly is pretty easy. If always invoke DHC, and DHC isn't actually present, there is an associated inefficiency. > => I don't think so. It should always know. > > - "SHOULD be sent on links that have a variable MTU (as > > specified in > > the document that describes how to run IP over the > > particular link > > type). MAY be sent on other links." > > > > Same comment on undocumented SHOULD. How about changing it to > > "MUST be sent ... (where specified ...)"? > => I have to give the same answer here. I don't think it's appropriate > to put MUST instead of the SHOULD above. The flexibility provided by the > SHOULD is important given the variety of link layers and *systems* (e.g. > 3GPP, WiMAX ...etc) out there that define how IPv6 is used in their > environments. I'll also note that the above SHOULD is to some extent an operational statement, not a protocol statement. If it is an implementation statement, it would be far more appropriate to say SHOULD or MUST in the specific IPv6 over FOO document, rather than this one. Thomas _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf