I am the assigned Gen-ART reviewer for draft-ietf-ipv6-2461bis-09.txt.
For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>. Please
resolve these comments along with any other Last Call comments you may
receive.
Summary statement: This draft is basically ready for publication, but
has nits that should be fixed before publication.
I have one question on the protocol, and several on documentation.
Since this is a significant protocol, documentation is very important.
For the sake of new implementors I have a number of suggestions for
clarity. Many of them have to do with the use of "SHOULD", since we
have been polishing up its use and advice to implementors.
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? In this case, I'm advertising a single route to you with
the Override flag off. What if you already have a route to a
larger prefix that includes it? Do I punch a hole? Am I
discarded? Is this documented?
OK, onward to non-protocol issues.
3.0 protocol overview
- Duplicate address detection
"Duplicate Address Detection: How a node determines that an
address it wishes to use is not already in use by another node."
should be
"Duplicate Address Detection: How a node determines whether or
not an address it wishes to use is already in use by another
node."
- Router advertisement: the phrase "on-link determination" has not
appeared before. It should be explained.
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."
We've been tightening up "SHOULD"s recently. RFC2119 says:
SHOULD This word, or the adjective "RECOMMENDED", mean that
there may exist valid reasons in particular circumstances to
ignore a particular item, but the full implications must be
understood and carefully weighed before choosing a different
course.
In this draft, "otherwise ... SHOULD" implies that there are
situations in which the link layer address is known, and the
source address is included, but the link layer address may be
omitted. RFC2119 says that deserves explanation. As guidance to
implementors, who are supposed to understand the full implications
and carefully weigh them, when would this be appropriate? For
load balancing? If so just say so. For example down below in
Router Advertisement Message, you say "A router MAY omit this
option in order to enable inbound load sharing across multiple
link-layer addresses." Something like that would work here -- if
nothing else add a pointer to text elsewhere.
There are more issues with SHOULDs not being thoroughly explained
below. I'm only listing the ones where I believe naive
implementors might benefit from explanation.
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? If so, how
about changing the text to "is known to be available"?
- "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 ...)"?
4.3 neighbor solicitation
- "Source link-layer address
The link-layer address for the sender. MUST NOT be included
when the source IP address is the unspecified address.
Otherwise, on link layers that have addresses this option MUST
be included in multicast solicitations and SHOULD be included in
unicast solicitations."
Same thing about SHOULD. If it SHOULD be included, under what
conditions is it expected that it would not be?
4.4 Neighbor advertisement
- Override Flag: "It SHOULD NOT be set in solicited advertisements
for anycast addresses and in solicited proxy advertisements. It
SHOULD be set in other solicited advertisements and in unsolicited
advertisements.
SHOULD and SHOULD NOT without explanation. Should these be MUSTs?
- Target link-layer address: "When responding to a unicast Neighbor
Solicitation this option SHOULD be included."
SHOULD. When would you not?
4.5 Redirect
- "It SHOULD be included (if known).
SHOULD. When would you not?
6.2.1 router config variables
- AdvCurHopLimit
"The value should be set to that current diameter of the
Intern iset."
s/that/the/
6.2.6 processing router solicitations
- "If the router already has a Neighbor Cache entry for the
solicitation's sender, the solicitation contains a Source
Link-Layer Address option, and the received link-layer address
differs from that already in the cache, the link-layer address
SHOULD be updated in the appropriate Neighbor Cache entry, and its
reachability state MUST also be set to STALE."
Unelaborated SHOULD?
6.3.4 processing received router advertisements
- In a paragraph that begins "After extracting information" ...
"If the advertisement contains a Source Link-Layer Address option
the link-layer address SHOULD be recorded in the Neighbor Cache
entry for the router ..."
This seems to be another unexplained SHOULD.
Setting the solicited flag ...
- In 7.2.5, "An advertisement's Solicited flag should only be set if
the advertisement is a response to a Neighbor Solicitation."
However, in 7.2.6, "The Solicited flag MUST be set to zero, in
order to avoid confusing the Neighbor Unreachability Detection
algorithm."
Is there a consistency problem here?
7.3.3
- "When a node needs to perform address resolution on a neighboring
address, it creates an entry in the INCOMPLETE state and initiates
address resolution as specified in Section 7.2. If address
resolution fails, the entry SHOULD be deleted, so that subsequent
traffic to that neighbor invokes the next-hop determination
procedure again."
"SHOULD" again. When would you not delete the entry?
- "In the Target Address field: the address to which subsequent
packets for the destination SHOULD be sent."
That's talking about the recipient of the redirect. It's not
about the sender's behavior, so this SHOULD should not be
capitalized.
8.3
- "A host receiving a valid redirect SHOULD update its Destination
Cache accordingly so that subsequent traffic goes to the specified
target. If no Destination Cache entry exists for the destination,
an implementation SHOULD create such an entry."
Another set of unsupported SHOULDs. What if it doesn't?
9 Options
- "Receivers MUST silently ignore any options they do not recognize
and continue processing the message."
I would add, as has been done in other WGs, that if a new option
is so ignored by the receiver, protocol behavior MUST still
continue as if the option had not been sent. That is, processing
of options is always backward compatible unless the option is
declared as required.
(Did not check state machine)
Thanks.
swb
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf