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

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 22 Feb 2005 13:47:07 -0500

Hi Tatuya, 

Thanks for the review, some answers inline.

 > 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.

=> I'd rather use IPv6 if that's ok with everyone since this doc is only applicable
to IPv6.

 > 
 > 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?

=> ok, I'll take a look.

 > 
 > 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?

=> This was updated based on Elwyn Davies' comment but perhaps I could
reword to make it clearer. The aim was to distinguish the provision of multicast
applications from multicasting messages on the link.

 > 
 >                     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?

=> We can refer to src address selection rules here for the consistency requirements.

 > 
 > 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.

=> It's sort of self explanatory that Reserved can be used in future, the important
thing is that it's set to zero and ignored on reception.

 > 
 > 
 > 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.

=> ok.

 > 
 > 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)

=> I don't care either way but if the document is going to be updated anyway I can
put that.

 > 
 > 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).

=> MUSTs are used to indicate that the protocol would break if a certain action]
is taken. In this case the protocol will not break so no need for MUST.

 > 
 > 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).

=> ok, I'll remove the reference to be consistent with other sections, this one must
have slipped. 

 > 
 > 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. 

=> Already done in the new rev.

 > 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.

=> I don't see how this is different from the above though. Using a larger LT means
you've increased it.

 > 
 > 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.

=> Already fixed in the new rev, please take a look and let me know.

 > 
 > 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].

=> Yes, it's not something that should be said in a spec anyway. I'll change it.

 > 
 > 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.

=> Since we removed all reference to IPsec except on its limitations, I don't
think we should add this one last bit because it might confuse people. Realistically,
IPsec is not going to be used with ND in a large network.

I haven't reviewed or updaetd the Appendices except for the state machine. 

 > 
 > 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).

=> ok.

 > 
 > 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.

=> ok I'll reword and send text.

 > 
 > 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?

=> There was, it was fixed in the last update. At least the one that was raised.

I'll take care of the editorials, some of them are already done. 

Thanks,
Hesham

===========================================================
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.
===========================================================

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 23 Feb 2005 12:24:22 +0900

>>>>> On Tue, 22 Feb 2005 13:47:07 -0500, 
>>>>> "Soliman, Hesham" <[email-masked]> said:

> => I'd rather use IPv6 if that's ok with everyone since this doc is only applicable

Hmm, I actually don't have a strong preference as long as the result
is consistent, but just "IP" seems to be more aligned with the sense
of Section 2.1:

   IP          - Internet Protocol Version 6.  The terms IPv4 and
                 IPv6 are used only in contexts where necessary to avoid
                 ambiguity.

> => We can refer to src address selection rules here for the consistency requirements.

So do you mean RFC3484 here?  Then I guess we should be more generic,
e.g.:

 Note that this specification does not strictly comply with the
 default address selection rules described in [RFC3484].  In
 particular, 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, even if [RFC3484] would not prefer that combination.

> thing is that it's set to zero and ignored on reception.

My concern is that people who read RFC2461bis might see a new
implementation that support the "H" bit of RFC3775 and say "this
implementation does not conform to RFC2461bis because it does not set
the reserved field to zero".  Basically, I'm not intending to insist
on this point, but I think it would not harm to make a note about
future extensions, particularly because we already know we have
extensions.  (I won't defend myself on this more.  If you still think
it's too much, please just ignore this comment).

> is taken. In this case the protocol will not break so no need for MUST.

Hmm, it's different from my view of SHOULD/MUST/etc, but I won't
insist on it.  So please just ignore this comment.

> => I don't see how this is different from the above though. Using a larger LT means

My point was that there's a no notion of "Valid Lifetime of a
**prefix**" in [ADDRCONF].  It only has "Valid (and Preferred)
Lifetime of an address".  That's why I suggested using "use".  I
believe it clarifies the things a bit and is more accurate, but the
original text would not confuse the reader.  So, I'd leave the
decision to you.

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

(snip)

> IPsec is not going to be used with ND in a large network.

Hmm...I agree with the "realistic" view itself, but unless we prohibit
the use of IPsec, I believe it is overkilling to remove requirements
(using RFC2119 keywords) when it is used.

Is it so harmful to revise the paragraph to, e.g., the following?

   In some cases, it may be acceptable to use statically configured
   security associations with either [IPv6-AH] or [IPv6-ESP] to secure
   Neighbor Discovery messages. However, it is important to note that
   statically configured security associations are not scalable
   (especially when considering multicast links) and are therefore
   limited to small networks with known hosts.  In any case, when
   [IPv6-AH] is used, received Authentication Headers in Neighbor
   Discovery packets MUST be verified for correctness and packets with
   incorrect authentication MUST be ignored.

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