"Soliman, Hesham" <hsoliman(_at_)qualcomm(_dot_)com> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf