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 PROTECTED]> said:
> 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 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.
> 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.
For the same reason, I personally don't see the need for these
changes (unless many others want these).
> 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.
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
> elsewhere.
Sorry, I don't understand the point. Could you be more specific on
what you want?
> 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."
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.
> 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.
(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).
> ==============================================================
> Other comments:
> [Throughout: Reference to RFC2461 should be to I-D 2461bis (to be updated
> eventually)]
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.
> 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.
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
> might be helpful.
Okay, will do.
> s.5.3: Putting the value of the link local prefix in explicitly makes a
> 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.
> 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:
(snip)
Okay. Thanks for the suggestion.
> 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.
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.
> 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').
Okay, will do.
> 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]
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.
> s.5.4.2 (last para on p15): [editorial] s/while the delaying period./during
> 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
> for auto-configuration.
Sorry, I don't understand the comment. Could you be more specific?
> 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).
Sorry, I don't understand the comment. Could you be more specific?
Is this a comment on rfc2462bis in the first place?
> 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 .
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 PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
