Hi Tatuya,
(B
(BThanks for the review, some answers inline.
(B
(B > Non-editorial comments
(B >
(B > 1. (throughout the document)
(B >
(B > There is a mixture of
(B > - how IPv6 operates over different link layers
(B > and
(B > - how IP operates over different link layers
(B > even though there does not seem to be ambiguity of what "IP" means.
(B > I guess we can simply use "how IP"...for all the cases.
(B
(B=> I'd rather use IPv6 if that's ok with everyone since this doc is only
(Bapplicable
(Bto IPv6.
(B
(B >
(B > 2. (general)
(B >
(B > This document hardcodes a constant of "1280" as the minimum link MTU
(B > in some places, but shouldn't we be more flexible and simply refer to
(B > RFC2460?
(B
(B=> ok, I'll take a look.
(B
(B >
(B > 3. Section 2.2. (Link Types)
(B > Note that all link types (including NBMA) are
(B > expected to provide multicast service
(B > for IP (e.g.,
(B > using multicast servers), but it is an issue for
(B > further study whether ND should use such
(B > facilities
(B > or an alternate mechanism that provides the
(B > equivalent ND services.
(B >
(B > I cannot parse this sentence, especially the very last part of it.
(B > Does this mean something like this?
(B
(B=> This was updated based on Elwyn Davies' comment but perhaps I could
(Breword to make it clearer. The aim was to distinguish the provision of multicast
(Bapplications from multicasting messages on the link.
(B
(B >
(B > it is an issue for
(B > further study whether ND should use such
(B > facilities
(B > or an alternate mechanism that provides the
(B > equivalent ND services should be used.
(B >
(B > 4. Section 2.3. (Addresses)
(B >
(B > Note that this specification does not strictly comply with the
(B > consistency requirements for the scopes of source and destination
(B > addresses. It is possible in some cases for hosts to use a source
(B > address of a larger scope than the destination address in the IPv6
(B > header.
(B >
(B > what's the "consistency requirements"? What ever they are, should we
(B > bother to mention this in the first place?
(B
(B=> We can refer to src address selection rules here for the consistency
(Brequirements.
(B
(B >
(B > 5. Section 4.2. (Router Advertisement Message Format)
(B >
(B > Reserved A 6-bit unused field. It MUST be initialized to
(B > zero by the sender and MUST be ignored by the
(B > receiver.
(B >
(B > I'm wondering whether we can be more flexible here, since we've
(B > already had several proposals that use the "Reserved" field. I know
(B > our consensus is that rfc2461bis itself does not included those
(B > extensions, but I think it is less-confusing to note that
(B > the Reserved
(B > field may be used in future extensions.
(B
(B=> It's sort of self explanatory that Reserved can be used in future, the
(Bimportant
(Bthing is that it's set to zero and ignored on reception.
(B
(B >
(B >
(B > 6. Section 4.6.2. (Prefix Information)
(B >
(B > Prefix Length 8-bit unsigned integer. [...
(B > ...]. The prefix length field provides
(B > necessary information for on-link determination
(B > (when combined with other flags in the prefix
(B > option). [...]
(B >
(B > what are the "other flags"? If you mean the on-link (L)
(B > flag, I think
(B > we should explicitly say so.
(B
(B=> ok.
(B
(B >
(B > 7. Section 4.6.2. (Prefix Information)
(B >
(B > A 1-bit autonomous address-configuration
(B > flag. When
(B > set indicates that this prefix can be used for
(B > autonomous address configuration as specified in
(B > [ADDRCONF].
(B >
(B > => in this context, I guess it is better to use "stateless address
(B > autoconfiguration" instead of "autonomous address configuration".
(B > (not a strong opinion, though)
(B
(B=> I don't care either way but if the document is going to be updated anyway I
(Bcan
(Bput that.
(B
(B >
(B > 8. Section 4.6.2. (Prefix Information)
(B >
(B > Prefix An IP address or a prefix of an IP address. The
(B > Prefix Length field contains the number of valid
(B > leading bits in the prefix. [...
(B > ...] A router SHOULD NOT send a prefix
(B > option for the link-local prefix and a
(B > host SHOULD
(B > ignore such a prefix option.
(B >
(B > => I don't see why we cannot use 'MUST (NOT)' here. Is there any
(B > scenario where it makes sense for a router to include the link-local
(B > prefix in the prefix information option? (Perhaps it's too late to
(B > make this comment, and I'm personally fine is the current wording).
(B
(B=> MUSTs are used to indicate that the protocol would break if a certain action]
(Bis taken. In this case the protocol will not break so no need for MUST.
(B
(B >
(B > 9. Section 6.2.3. (Router Advertisement Message Content)
(B >
(B > - In the M and O flags: the interface's configured
(B > AdvManagedFlag
(B > and AdvOtherConfigFlag, respectively. See [ADDRCONF].
(B >
(B > I've already pointed out that this part is not fully
(B > synchronized with
(B > the latest consensus on [ADDRCONF], but I'd like to repeat that here
(B > to make it sure. In particular, we cannot refer to [ADDRCONF] here,
(B > since it does not mention these flags any more. Also, if we
(B > can refer
(B > to [ADDRCONF] as an informative reference (which I agree with), I
(B > believe we should also refer to draft-ietf-ipv6-ra-mo-flags-00.txt as
(B > an informative reference. (Basically, we should rather refer to the
(B > ra-mo-flags document when we talk about M/O, AdvManagedFlag, or
(B > AdvOtherConfigFlag).
(B
(B=> ok, I'll remove the reference to be consistent with other sections, this one
(Bmust
(Bhave slipped.
(B
(B >
(B > 10. Section 6.3.4. (Processing Received Router Advertisements)
(B >
(B > [...] Moreover, information
(B > may also be obtained through other dynamic means, such as stateful
(B > autoconfiguration.
(B >
(B > I believe we basically agreed (particularly in 2462bis and the recent
(B > M/O flag work) that "stateful configuration" is somewhat
(B > confusing and
(B > we should just say DHCPv6 wherever possible.
(B
(B=> Already done in the new rev.
(B
(B
(B > 11. Section 6.3.4. (Processing Received Router Advertisements)
(B >
(B > Stateless address autoconfiguration [ADDRCONF] may in some
(B > circumstances increase the Valid Lifetime of a prefix or ignore it
(B > completely in order to prevent a particular denial of
(B > service attack.
(B >
(B > "the Valid Lifetime of a prefix" is not really correct in the context
(B > of [ADDRCONF]; the lifetime is associated with addresses, not
(B > prefixes. And [ADDRCONF] does not directly manipulate prefix
(B > lifetimes. So, I think it's better to say, e.g.:
(B >
(B > Stateless address autoconfiguration [ADDRCONF] may in some
(B > circumstances use a larger Valid Lifetime of a prefix or
(B > ignore the
(B > Valid Lifetime completely in order to prevent a particular denial
(B > of service attack.
(B
(B=> I don't see how this is different from the above though. Using a larger LT
(Bmeans
(Byou've increased it.
(B
(B >
(B > 12. Section 7.2.5. (Receipt of Neighbor Advertisements)
(B >
(B > If the target's Neighbor Cache entry is in the INCOMPLETE
(B > state when
(B > the advertisement is received, one of two things happens.
(B >
(B > I don't understand this sentence; what exactly does "one of two
(B > things" specify? It's not clear from the succeeding part.
(B
(B=> Already fixed in the new rev, please take a look and let me know.
(B
(B >
(B > 13. Section 11.1 (Threat analysis)
(B >
(B > Whereas the third paragraph begins with
(B >
(B > An example of denial of service attacks is that [...] ,
(B >
(B > this paragraph also talks about other types of threats, e.g.,
(B >
(B > [...] That router can then
(B > selectively examine, modify or drop all packets sent on the link.
(B >
(B > where packet modification can also lead to other types of attacks. I
(B > believe this paragraph needs to be more accurate.
(B >
(B > 14. Section 11.1 (Threat analysis)
(B >
(B > [...] It is natural to trust the routers
(B > on the link.
(B >
(B > I'm afraid we cannot justify this statement once we refer to [PSREQ].
(B
(B=> Yes, it's not something that should be said in a spec anyway. I'll change it.
(B
(B
(B >
(B > 15. Section 11.1 (Threat analysis)
(B >
(B > 2461bis-02 has removed the following part of RFC2461:
(B >
(B > Received Authentication Headers in Neighbor Discovery
(B > packets MUST be
(B > verified for correctness and packets with incorrect authentication
(B > MUST be ignored.
(B >
(B > It SHOULD be possible for the system administrator to configure a
(B > node to ignore any Neighbor Discovery messages that are not
(B > authenticated using either the Authentication Header or
(B > Encapsulating
(B > Security Payload. The configuration technique for this MUST be
(B > documented. Such a switch SHOULD default to allowing
(B > unauthenticated
(B > messages.
(B >
(B > But I believe these requirements are still valid and should be
(B > included *when we use IPsec* for ND, even if we note the
(B > limitation of
(B > the use of IPsec to secure ND.
(B
(B=> Since we removed all reference to IPsec except on its limitations, I don't
(Bthink we should add this one last bit because it might confuse people.
(BRealistically,
(BIPsec is not going to be used with ND in a large network.
(B
(BI haven't reviewed or updaetd the Appendices except for the state machine.
(B
(B >
(B > 16. APPENDIX A (MULTIHOMED HOSTS)
(B >
(B > Some of the issued in this appendix are discussed in the "default
(B > router preference" draft. I believe we should refer to this document
(B > (IMO, it can be an informative reference).
(B
(B=> ok.
(B
(B >
(B > 17. APPENDIX A (MULTIHOMED HOSTS)
(B >
(B > [...] Under
(B > similar conditions in the non-multihomed host case, a node
(B > treats all destinations as residing on-link, and
(B > communication
(B > proceeds. [...]
(B >
(B > This is the so-called "on-link" assumption, which was removed in
(B > rfc2461bis. Note that we cannot simply remove this
(B > sentence, since it
(B > would also affect the succeeding sentence.
(B
(B=> ok I'll reword and send text.
(B
(B >
(B > 18. APPENDIX C (STATE MACHINE FOR THE REACHABILITY STATE)
(B >
(B > I don't really remember the past discussions, but isn't there an
(B > inconsistency between this table and the specification described in
(B > the document body?
(B
(B=> There was, it was fixed in the last update. At least the one that was raised.
(B
(BI'll take care of the editorials, some of them are already done.
(B
(BThanks,
(BHesham
(B
(B===========================================================
(BThis email may contain confidential and privileged material for the sole use
(B of the intended recipient. Any review or distribution by others is strictly
(B prohibited. If you are not the intended recipient please contact the sender
(B and delete all copies.
(B===========================================================
(B
(B
(B--------------------------------------------------------------------
(BIETF IPv6 working group mailing list
(Bipv6@ietf.org
(BAdministrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
(B--------------------------------------------------------------------
