Subject: comments on draft-ietf-ipv6-2461bis-01.txt

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 21 Feb 2005 11:57:15 +0900

Hi,

I'm really sorry for not doing this earlier, but I've finally gone
through this one.

I basically do not have significant problems in this document, but
still have some non-trivial comments which would require another
revision (but I'm afraid you cannot address all of them before the
looming cutoff...once again, sorry for the very delayed comments).

I must also confess there may be duplicate comments (with ones that
others already pointed out).  I quickly re-checked the past comments
on the ML, but I won't surprise if I miss something.  I'd apologize in
advance for any duplicates.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

Non-editorial comments

1. (throughout the document)

There is a mixture of
  - how IPv6 operates over different link layers
and
  - how IP operates over different link layers
even though there does not seem to be ambiguity of what "IP" means.
I guess we can simply use "how IP"...for all the cases.

2. (general)

This document hardcodes a constant of "1280" as the minimum link MTU
in some places, but shouldn't we be more flexible and simply refer to
RFC2460?

3. Section 2.2.  (Link Types)
                    Note that all link types (including NBMA) are
                    expected to provide multicast service for IP (e.g.,
                    using multicast servers), but it is an issue for
                    further study whether ND should use such facilities
                    or an alternate mechanism that provides the
                    equivalent ND services.

I cannot parse this sentence, especially the very last part of it.
Does this mean something like this?

                    it is an issue for
                    further study whether ND should use such facilities
                    or an alternate mechanism that provides the
                    equivalent ND services should be used.

4. Section 2.3.  (Addresses)

   Note that this specification does not strictly comply with the
   consistency requirements for the scopes of source and destination
   addresses. It is possible in some cases for hosts to use a source
   address of a larger scope than the destination address in the IPv6
   header.

what's the "consistency requirements"?  What ever they are, should we
bother to mention this in the first place?

5. Section 4.2.  (Router Advertisement Message Format)

      Reserved       A 6-bit unused field.  It MUST be initialized to
                     zero by the sender and MUST be ignored by the
                     receiver.

I'm wondering whether we can be more flexible here, since we've
already had several proposals that use the "Reserved" field.  I know
our consensus is that rfc2461bis itself does not included those
extensions, but I think it is less-confusing to note that the Reserved
field may be used in future extensions.

6. Section 4.6.2.  (Prefix Information)

      Prefix Length  8-bit unsigned integer.  [...
                     ...]. The prefix length field provides
                     necessary information for on-link determination
                     (when combined with other flags in the prefix
                     option).  [...]

what are the "other flags"?  If you mean the on-link (L) flag, I think
we should explicitly say so.

7. Section 4.6.2.  (Prefix Information)

      A              1-bit autonomous address-configuration flag.  When
                     set indicates that this prefix can be used for
                     autonomous address configuration as specified in
                     [ADDRCONF].

=> in this context, I guess it is better to use "stateless address
autoconfiguration" instead of "autonomous address configuration".
(not a strong opinion, though)

8. Section 4.6.2.  (Prefix Information)

      Prefix         An IP address or a prefix of an IP address.  The
                     Prefix Length field contains the number of valid
                     leading bits in the prefix. [...
                     ...] A router SHOULD NOT send a prefix
                     option for the link-local prefix and a host SHOULD
                     ignore such a prefix option.

=> I don't see why we cannot use 'MUST (NOT)' here.  Is there any
scenario where it makes sense for a router to include the link-local
prefix in the prefix information option?  (Perhaps it's too late to
make this comment, and I'm personally fine is the current wording).

9. Section 6.2.3.  (Router Advertisement Message Content)

      - In the M and O flags: the interface's configured AdvManagedFlag
        and AdvOtherConfigFlag, respectively.  See [ADDRCONF].

I've already pointed out that this part is not fully synchronized with
the latest consensus on [ADDRCONF], but I'd like to repeat that here
to make it sure.  In particular, we cannot refer to [ADDRCONF] here,
since it does not mention these flags any more.  Also, if we can refer
to [ADDRCONF] as an informative reference (which I agree with), I
believe we should also refer to draft-ietf-ipv6-ra-mo-flags-00.txt as
an informative reference.  (Basically, we should rather refer to the
ra-mo-flags document when we talk about M/O, AdvManagedFlag, or
AdvOtherConfigFlag).

10. Section 6.3.4.  (Processing Received Router Advertisements)

   [...]  Moreover, information
   may also be obtained through other dynamic means, such as stateful
   autoconfiguration.

I believe we basically agreed (particularly in 2462bis and the recent
M/O flag work) that "stateful configuration" is somewhat confusing and
we should just say DHCPv6 wherever possible.  I think the general
agreement applies here (and, in fact, I don't think using "stateful
autoconfiguration" here is appropriate, since the "information" in
this context can also be provided by the "stateless" subset of
DHCPv6.)

11. Section 6.3.4.  (Processing Received Router Advertisements)

   Stateless address autoconfiguration [ADDRCONF] may in some
   circumstances increase the Valid Lifetime of a prefix or ignore it
   completely in order to prevent a particular denial of service attack.

"the Valid Lifetime of a prefix" is not really correct in the context
of [ADDRCONF]; the lifetime is associated with addresses, not
prefixes.  And [ADDRCONF] does not directly manipulate prefix
lifetimes.  So, I think it's better to say, e.g.:

   Stateless address autoconfiguration [ADDRCONF] may in some
   circumstances use a larger Valid Lifetime of a prefix or ignore the
   Valid Lifetime completely in order to prevent a particular denial
   of service attack.

12. Section 7.2.5.  (Receipt of Neighbor Advertisements)

   If the target's Neighbor Cache entry is in the INCOMPLETE state when
   the advertisement is received, one of two things happens.

I don't understand this sentence; what exactly does "one of two
things" specify?  It's not clear from the succeeding part.

13. Section 11.1 (Threat analysis)

Whereas the third paragraph begins with

   An example of denial of service attacks is that [...] ,

this paragraph also talks about other types of threats, e.g.,

   [...]  That router can then
   selectively examine, modify or drop all packets sent on the link.

where packet modification can also lead to other types of attacks.  I
believe this paragraph needs to be more accurate.

14. Section 11.1 (Threat analysis)

   [...]  It is natural to trust the routers
   on the link.

I'm afraid we cannot justify this statement once we refer to [PSREQ].

15. Section 11.1 (Threat analysis)

2461bis-02 has removed the following part of RFC2461:

   Received Authentication Headers in Neighbor Discovery packets MUST be
   verified for correctness and packets with incorrect authentication
   MUST be ignored.

   It SHOULD be possible for the system administrator to configure a
   node to ignore any Neighbor Discovery messages that are not
   authenticated using either the Authentication Header or Encapsulating
   Security Payload.  The configuration technique for this MUST be
   documented.  Such a switch SHOULD default to allowing unauthenticated
   messages.

But I believe these requirements are still valid and should be
included *when we use IPsec* for ND, even if we note the limitation of
the use of IPsec to secure ND.

16. APPENDIX A (MULTIHOMED HOSTS)

Some of the issued in this appendix are discussed in the "default
router preference" draft.  I believe we should refer to this document
(IMO, it can be an informative reference).

17. APPENDIX A (MULTIHOMED HOSTS)

        [...]  Under
        similar conditions in the non-multihomed host case, a node
        treats all destinations as residing on-link, and communication
        proceeds.  [...]

This is the so-called "on-link" assumption, which was removed in
rfc2461bis.  Note that we cannot simply remove this sentence, since it
would also affect the succeeding sentence.

18. APPENDIX C (STATE MACHINE FOR THE REACHABILITY STATE)

I don't really remember the past discussions, but isn't there an
inconsistency between this table and the specification described in
the document body?

====================================================================
Pure editorial comments

18. (all the per-page headers:)
INTERNET-DRAFT         Neighbor Discovery in IPv6            June, 2004

=> s/June/October/ :-)
(perhaps the problem will automatically be gone in the next rev.)

19. Table of Contents

  Full Copyright Statement.................Error! Bookmark not defined.

=> seems to be a compilation error or something with your tool to
   generate an I-D.

20. Section 4.4.  (Neighbor Advertisement Message Format)

                     layer address; otherwise it would not have be able
                     to send the unicast solicitation in the first

=> s/have be able/have to be able/

21. Section 7.2.3.  (Receipt of Neighbor Solicitations)

   A valid Neighbor Solicitation that does not meet any the following
   requirements MUST be silently discarded:

=> s/any the following/any of the following/ (?)

22. Section 7.3.1.  (Reachability Confirmation)

   [...]  Receipt
   of unsolicited messages only confirm the one-way path from the sender
   to the recipient node.  [...]

s/confirm/confirms/

23. Section 8.2.  (Router Specification)

      - the Destination Address of the packet is not a multicast
        address, and

It seems to me that ", and" is just redundant.

24. Section 11.1 (Threat analysis)

   - DoS attacks

I believe this should be

   - Denial of Service attacks
or
   - Denial of Service (DoS) attacks

(it's slightly odd to see the acronym first and then its expanded form
in a succeeding sentence)

25. Section 11.1

   - Router spoofing attacks.

It's strange to see a "period" only in this bullet.

26. Section 11.1

   [...] The
   Neighbor Unreachability Detection will not detect such a black hole
   as long as the rogue router politely answers the NUD probes with a
   Neighbor Advertisement with the R-bit set.

I would clarify what "NUD" stands for (although one may think this is
pretty obvious).  e.g.,

   Neighbor Unreachability Detection (NUD) will not ...

(Note that this is the only occurrence of the acronym "NUD")

27. Section 11.1

   victim's traffic to itself.
   The trust model for redirects is the same as in IPv4.  [...]

It seems to me that we need a blank line between these two sentences.

28. Section 12.  (RENUMBERING CONSIDERATIONS)

   valid since the last lifetime they received was 2 months.  Thus if a

   node was unplugged on July 31st it thinks the prefix is valid until

=> there seems to be a redundant blank line.

29. REFERENCES (informative)

   [ADDRCONF]   Thomson, S. Narten, T, and T. Jinmei, "IPv6 Address
                Autoconfiguration", draft-ietf-ipv6-rfc2462bis-02, June

The latest version of this document is 07.  (02 was too old even when
2461bis-01 was submitted:-)

30. APPENDIX A (MULTIHOMED HOSTS)

        [...]  Should the assumption be FALSE,
        communication would fail.

I don't understand why "FALSE" is all-capitalized in this context.  I
think we can simply use "false" here.

Appendix E.1: Reachability confirmations

   [...]  In merely indicates that 30 minutes
   ago the window update reached the peer i.e. the path was working at

s/In merely indicates/It merely indicates/

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Soliman, Hesham" <[email-masked]>
Date: Sun, 20 Feb 2005 22:30:18 -0500

Sigh of agony :/  I guess we both sent emails at the same time. 
Obviously these comments on the eve of the deadline won't make it.
I'm sure you have some good comments too :).
I'll go through them and let you know how they'll be handled. Obviously
others can chime in as well.

Thanks,
Hesham

 > -----Original Message-----
 > From: [email-masked] 
 > [mailto:[email-masked]]
 > Sent: Sunday, February 20, 2005 9:57 PM
 > To: Soliman, Hesham
 > Cc: [email-masked]
 > Subject: comments on draft-ietf-ipv6-2461bis-01.txt
 > 
 > 
 > Hi,
 > 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================