Subject: RE: I-D ACTION:draft-ietf-ipv6-rfc2462bis-05.txt

From: "Elwyn Davies" <[email-masked]>
Date: Fri, 13 Aug 2004 22:24:01 +0100

Its hard to keep up with the versions of this draft;-)
I take it that -05 is merely the complete version of -04 - I can't see any
difference.

So here goes with my comments that were intended for -04.

===============================================================
General issue with title and the general words on (address)
auto-configuration vs the specifics of stateless auto-config:

A considerable amount of this proposal is actually about what has to be done
in all cases to achieve address auto-configuration. These parts apply
equally to stateless and stateful processes.

The title is therefore misleading.  Is it too late to rename it something
like:
'IPv6 Address Autoconfiguration and Management incorporating Stateless
Autoconfiguration'?

I think it would make the document a lot more useful/readable if the
generally applicable pieces were clearly separated from the stateless
specific parts.

In s.5 everything except ss. 5.5,5.5.1-5.5.3 applies generally to all
auto-configured addresses; ss 5.5-5.5.3 form the stateless address config
part. The protocol overview s.4 could be split up correspondingly.

It should be made clearer in S.4 (in the para on prefix information options
on p.10) and in s5.2 (or maybe in s5.5/5.5.4) that however an address is
auto-configured or manually configured, it must be configured with preferred
and valid lifetimes.

==============================================================

The confusion around stateful, 3315 and 3736 has been discussed at length
elsewhere.

The last sentence of s.3 ("Router advertisements include flags specifying
which mechanisms a host can use.") is possibly too prescriptive now - how
about "RAs include flags which can be used to indicate which mechanisms are
available."

As mentioned elsewhere the para on the use of the M and O flags in s.4
should reiterate the requirement that hosts have stateless autoconfiguration
enabled by default when thay come out of the box to ensure full
'plug-and-play' behaviour.

==============================================================

Other comments:

[Throughout: Reference to RFC2461 should be to I-D 2461bis (to be updated
eventually)]

s.4 and s.5.1: In line with comments I made on 2461bis, there is a problem
with the phrases 'multicast-capable' (s.4) and 'each multicast interface'
(s.5.1).  According to the note after the definition of NBMA links in s.2.1
of 2461bis, all Ipv6 links are 'expected to provide multicast services for
IP'.  This can be interpreted as meaning that *all* IPv6 capable links are
also multicast-capable.  Since the term multicast-capable is not explicitly
defined, it is either a tautology or we need to define which link types are
actually multicast-capable, as opposed to having multicast services.  s.5.1
should either use multicast-capable or (if it actually means all links)
remove the qualifier.

s.4.1 (last para): A reference to the default address selection RFC3484
might be helpful.

s.5.3: Putting the value of the link local prefix in explicitly makes a
potential double maintenance problem.

s.5.4 (first two sentences):  The meaning is not very easy to parse - on
coming back to them I at first thought they conflicted.  How about:

   Duplicate Address Detection MUST be performed on all unicast addresses
prior to assigning them 
   to an interface, regardless of whether they are obtained through
stateful, stateless or manual 
   configuration, with the following exceptions:

   - An interfaces whose DupAddrDetectTransmits variable is set to zero does
not perform Duplicate 
     Address Detection,

   - Where a unicast format address is being used as an anycast address,
Duplicate Address 
     Detection MUST NOT be performed on the anycast address (interfaces
providing anycast services
     know which addresses are being used for anycast services although the
addresses are not 
     a priori distinguishable from other unicast addresses), and

   - Each individual... [as before]

s.5.4.2: In my comments on 2461bis I noted that the phrase 'join a multicast
address' is not defined anywhere.  In 2462bis there is quite a lot of
discussion of MLD joins but it would be useful to either define the term in
the definitions or explain what it means at the top of 5.4.2 before suddenly
starting talking about MLD.

s.5.4.2 (1st para): Since it is later admitted that the DAD process is not
totally reliable, the last sentence  of the first para should end
'simultaneously should detect each other's presence'. (explicitly a lower
case 'should').

s.5.4.2: Should the random delay mechanism introduced for the MLD be applied
to all nodes joining the all nodes multicast group (and less likely) to
routers joing the all routers group? [Comment for 2461bis also]

s.5.4.2 (last para on p15): [editorial] s/while the delaying period./during
the delay period./ at end of first sentence.

s.5.5: prefix Info options are not necessarily the only source of prefixes
for auto-configuration.

s.5.5.2: the second para implies that 2461bis should mention the ability to
manually configure a prefix in the default routers list (not currently
mentioned).

s.5.5.3: Should the logic on updating address lifetimes in item (e) be
applied to addresses configured by stateful and/or other means?  Equivalent
DOS attacks could come from (bogus)server initiated DHCP updates as
described in the Security considerations of RFC3315 .

Regards,
Elwyn

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: 12 August 2004 20:31
> To: [email-masked]
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-ipv6-rfc2462bis-05.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> This draft is a work item of the IP Version 6 Working Group 
> Working Group of the IETF.
> 
> 	Title		: IPv6 Stateless Address Autoconfiguration
> 	Author(s)	: S. Thomson, et al.
> 	Filename	: draft-ietf-ipv6-rfc2462bis-05.txt
> 	Pages		: 31
> 	Date		: 2004-8-12
> 	
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Mon, 16 Aug 2004 17:45:52 +0900

Hello,

Thanks for the careful reading and the detailed comments.

I'd first like to make sure about the next steps.  This document has
already passed a wg last call, and I've asked the chairs for
submitting it to the IESG.  While I see some valid points in the
comments that would require modifications to the document, I
personally do not think those are too substantial to block the action.
That is, I think we can address the points in parallel of IESG
evaluation.  If anyone of you disagrees with this, please speak up
right now (then I'll try to address the issues quickly and revise the
draft once again).

>>>>> On Fri, 13 Aug 2004 22:24:01 +0100, 
>>>>> "Elwyn Davies" <[email-masked]> said:

> 'IPv6 Address Autoconfiguration and Management incorporating Stateless

I personally do not think changing the title at this stage helps much.
Very roughly speaking, this document describes:

  - stateless autoconfiguration of a link-local address
  - stateless autoconfiguration of global addresses
  - duplicate address detection (DAD) for all kinds of unicast
    addresses

whereas the document also talks about the relationship between the RA
M/O flags and DHCPv6 to some extent, it's now a minor issue IMO.

Regarding DAD, RFC3315 explicitly mentions it with referring to
RFC2461/2462 as normative references.  So, I don't think the title of
rfc2462(bis) obfuscates the point that DAD should be performed on
statefully configured addresses as well.

Meanwhile, the title of this specification has not changed since
RFC1971.  IMO, changing the title at this stage without clear benefit
could even cause unnecessary confusion.

Opinions may still vary on this point.  However, I'm quite sure that
this is at least not very substantial, and, considering the document
status, I would basically like to keep it as is unless reasonably many
people want the change.

> part. The protocol overview s.4 could be split up correspondingly.

For the same reason, I personally don't see the need for these
changes (unless many others want these).

> auto-configured or manually configured, it must be configured with preferred

I personally don't see the need for this either (in other words, the
current text already contains necessary information for implementors).
But if you could provide concrete text and the necessary change is
small, I think we can add that.

> The confusion around stateful, 3315 and 3736 has been discussed at length

Sorry, I don't understand the point.  Could you be more specific on
what you want?

> about "RAs include flags which can be used to indicate which mechanisms are

Hmm, the current text is a result of an attempt to make the
specification not prescriptive...but I don't have a problem to change
the sentence, so I'll use the suggested text unless others object to
that.

> 'plug-and-play' behaviour.

(I'm not sure what "As mentioned elsewhere" means, but in any event)
I personally do not see the need for this...IMO, this would rather be
a matter of the node requirement document (and, in my understanding,
the node-req document is already pretty clear on this).

> [Throughout: Reference to RFC2461 should be to I-D 2461bis (to be updated

Yes, I've been aware of this throughout the work on rfc2462bis.  I
thought we could do that at the very final stage of the procedure
(otherwise, we'd see a comment like "there's a reference dependency
from an RFC-to-be to an I-D").  But perhaps this is a good chance to
do that.  I don't have a particular preference on this, and would like
to hear from others.

> should either use multicast-capable or (if it actually means all links)

Regarding "multicast interface", I think we can simply replace it with
"multicast-capable interface" if you are happy with that.  Do you
think we need to do more on this? (e.g., do you think we need to define
the term "multicast-capable"?)

> s.4.1 (last para): A reference to the default address selection RFC3484

Okay, will do.

> potential double maintenance problem.

I tend to agree.  I'll try to revise the text without hardcoding the
particular prefix of "FE80::" and the constant length of 10 bits.

> coming back to them I at first thought they conflicted.  How about:

(snip)

Okay.  Thanks for the suggestion.

> starting talking about MLD.

We once discussed a similar point and rejected it.  I personally still
don't see the need for this, but if you strongly want to do something
on this, I think we could try to revise the paragraph in Section
5.4.2 that talks about MLD.

> 'simultaneously should detect each other's presence'. (explicitly a lower

Okay, will do.

> routers joing the all routers group? [Comment for 2461bis also]

We don't need a random delay for the all-nodes multicast group, since
an MLD listener report is not sent in this case.  Regarding the
all-routers group, at least it's not within the scope of rfc2462bis.
I'm even not sure if rfc2461bis (ND update) needs to talk about this,
since it does not cause interaction issue like the first NS and MLD
described in rfc2462bis.

> the delay period./ at end of first sentence.

Okay, will do.

> s.5.5: prefix Info options are not necessarily the only source of prefixes

Sorry, I don't understand the comment.  Could you be more specific?

> manually configure a prefix in the default routers list (not currently

Sorry, I don't understand the comment.  Could you be more specific?
Is this a comment on rfc2462bis in the first place?

> described in the Security considerations of RFC3315 .

We've intentionally eliminated the case of addresses configured by
DHCPv6 for several reasons:

- we basically concentrate on stateless address configuration, and the
  detailed description of the stateful case is left to other
  documents.
- the description of Section 5.5.3 cannot easily apply to DHCPv6,
  since Section 5.5.3 depends on the notion of the "prefix length" of
  an address while DHCPv6 does not convey the information.

One more point.  I'm not sure what you meant by "as described in the
Security considerations of RFC3315", but DHCPv6 has its own security
mechanism, and, in my understanding, the "official" position to DHCPv6
spoofing attacks is "use DHCPv6 authentication".

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 19 Aug 2004 18:08:52 +0900

(Confirming a couple of other minor things)

>>>>> On Mon, 16 Aug 2004 17:45:52 +0900, 
>>>>> JINMEI Tatuya <[email-masked]> said:

> particular prefix of "FE80::" and the constant length of 10 bits.

I'm going to change the part to:

   A link-local address is formed by prepending the well-known
   link-local prefix [RFC3513] (of appropriate length) to the interface
   identifier.  If the interface identifier has a length of N bits, the
   interface identifier replaces the right-most N zero bits of the
   link-local prefix.  If the sum of the link-local prefix length and N
   is larger than 128, autoconfiguration fails and manual configuration
   is required.  [...snip]

> Okay.  Thanks for the suggestion.

In the revised text, I'll simply concentrate on resolving the point
that the original text could be interpreted as conflict:

   Duplicate Address Detection MUST be performed on all unicast
   addresses prior to assigning them to an interface, regardless of
   whether they are obtained through stateful, stateless or manual
   configuration, with the following exceptions:

   -  An interface whose DupAddrDetectTransmits variable is set to zero
      does not perform Duplicate Address Detection,

   -  Duplicate Address Detection MUST NOT be performed on anycast
      addresses, and

   -  Each individual unicast address ...

					JINMEI, Tatuya