(BSigh of agony :/ I guess we both sent emails at the same time.
(BObviously these comments on the eve of the deadline won't make it.
(BI'm sure you have some good comments too :).
(BI'll go through them and let you know how they'll be handled. Obviously
(Bothers can chime in as well.
(B
(BThanks,
(BHesham
(B
(B
(B > -----Original Message-----
(B > From: [EMAIL PROTECTED]
(B > [mailto:[EMAIL PROTECTED]
(B > Sent: Sunday, February 20, 2005 9:57 PM
(B > To: Soliman, Hesham
(B > Cc: ipv6@ietf.org
(B > Subject: comments on draft-ietf-ipv6-2461bis-01.txt
(B >
(B >
(B > Hi,
(B >
(B > I'm really sorry for not doing this earlier, but I've finally gone
(B > through this one.
(B >
(B > I basically do not have significant problems in this document, but
(B > still have some non-trivial comments which would require another
(B > revision (but I'm afraid you cannot address all of them before the
(B > looming cutoff...once again, sorry for the very delayed comments).
(B >
(B > I must also confess there may be duplicate comments (with ones that
(B > others already pointed out). I quickly re-checked the past comments
(B > on the ML, but I won't surprise if I miss something. I'd
(B > apologize in
(B > advance for any duplicates.
(B >
(B > JINMEI, Tatuya
(B > Communication Platform Lab.
(B > Corporate R&D Center,
(B > Toshiba Corp.
(B > [EMAIL PROTECTED]
(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 > 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 > 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 > 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 > 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 >
(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 > 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 > 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 > 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 > 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. I think the general
(B > agreement applies here (and, in fact, I don't think using "stateful
(B > autoconfiguration" here is appropriate, since the "information" in
(B > this context can also be provided by the "stateless" subset of
(B > DHCPv6.)
(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 > 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 > 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 > 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 > 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 > 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 > 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 >
(B > ====================================================================
(B > Pure editorial comments
(B >
(B > 18. (all the per-page headers:)
(B > INTERNET-DRAFT Neighbor Discovery in IPv6
(B > June, 2004
(B >
(B > => s/June/October/ :-)
(B > (perhaps the problem will automatically be gone in the next rev.)
(B >
(B > 19. Table of Contents
(B >
(B > Full Copyright Statement.................Error! Bookmark
(B > not defined.
(B >
(B > => seems to be a compilation error or something with your tool to
(B > generate an I-D.
(B >
(B >
(B > 20. Section 4.4. (Neighbor Advertisement Message Format)
(B >
(B > layer address; otherwise it would not
(B > have be able
(B > to send the unicast solicitation in the first
(B >
(B > => s/have be able/have to be able/
(B >
(B > 21. Section 7.2.3. (Receipt of Neighbor Solicitations)
(B >
(B > A valid Neighbor Solicitation that does not meet any the following
(B > requirements MUST be silently discarded:
(B >
(B > => s/any the following/any of the following/ (?)
(B >
(B > 22. Section 7.3.1. (Reachability Confirmation)
(B >
(B > [...] Receipt
(B > of unsolicited messages only confirm the one-way path
(B > from the sender
(B > to the recipient node. [...]
(B >
(B > s/confirm/confirms/
(B >
(B > 23. Section 8.2. (Router Specification)
(B >
(B > - the Destination Address of the packet is not a multicast
(B > address, and
(B >
(B > It seems to me that ", and" is just redundant.
(B >
(B > 24. Section 11.1 (Threat analysis)
(B >
(B > - DoS attacks
(B >
(B > I believe this should be
(B >
(B > - Denial of Service attacks
(B > or
(B > - Denial of Service (DoS) attacks
(B >
(B > (it's slightly odd to see the acronym first and then its
(B > expanded form
(B > in a succeeding sentence)
(B >
(B > 25. Section 11.1
(B >
(B > - Router spoofing attacks.
(B >
(B > It's strange to see a "period" only in this bullet.
(B >
(B > 26. Section 11.1
(B >
(B > [...] The
(B > Neighbor Unreachability Detection will not detect such a
(B > black hole
(B > as long as the rogue router politely answers the NUD probes with a
(B > Neighbor Advertisement with the R-bit set.
(B >
(B > I would clarify what "NUD" stands for (although one may think this is
(B > pretty obvious). e.g.,
(B >
(B > Neighbor Unreachability Detection (NUD) will not ...
(B >
(B > (Note that this is the only occurrence of the acronym "NUD")
(B >
(B > 27. Section 11.1
(B >
(B > victim's traffic to itself.
(B > The trust model for redirects is the same as in IPv4. [...]
(B >
(B > It seems to me that we need a blank line between these two sentences.
(B >
(B > 28. Section 12. (RENUMBERING CONSIDERATIONS)
(B >
(B > valid since the last lifetime they received was 2 months.
(B > Thus if a
(B >
(B > node was unplugged on July 31st it thinks the prefix is
(B > valid until
(B >
(B > => there seems to be a redundant blank line.
(B >
(B >
(B > 29. REFERENCES (informative)
(B >
(B > [ADDRCONF] Thomson, S. Narten, T, and T. Jinmei, "IPv6 Address
(B > Autoconfiguration",
(B > draft-ietf-ipv6-rfc2462bis-02, June
(B >
(B > The latest version of this document is 07. (02 was too old even when
(B > 2461bis-01 was submitted:-)
(B >
(B > 30. APPENDIX A (MULTIHOMED HOSTS)
(B >
(B > [...] Should the assumption be FALSE,
(B > communication would fail.
(B >
(B > I don't understand why "FALSE" is all-capitalized in this context. I
(B > think we can simply use "false" here.
(B >
(B > Appendix E.1: Reachability confirmations
(B >
(B > [...] In merely indicates that 30 minutes
(B > ago the window update reached the peer i.e. the path was
(B > working at
(B >
(B > s/In merely indicates/It merely indicates/
(B >
(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--------------------------------------------------------------------
