Hi.
Responses and comments/thoughts below.
Regards,
Elwyn
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]
> Sent: 16 August 2004 09:46
> To: Davies, Elwyn [HAL02:0S00:EXCH]
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: I-D ACTION:draft-ietf-ipv6-rfc2462bis-05.txt
>
>
> 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).
The thinking (admittedly very late in the day) is that a large part of the document is actually about processes common to stateless and stateful (global) address auto-config - DAD, link local address auto-config and address lifetime management are all common and the 'other config' stuff is orthogonal to both - only a relatively small part is about global address stateless auto-config. I am happy to accept the concensus but maybe it is getting time for an overview of ICMPv6 tied in the with M/O policy stuff.
Might I suggest as a compromise, altering the first sentence of s5.5.4 (5.5.4 and subsequent sections apply to all addresses):
A preferred address, whether created by stateless or stateful autoconfiguration, becomes deprecated...
>
> > 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 point was that this stuff has already been discussed in another email thread and I believe some fixup is needed but this was not the place to put more about that discussion]
>
> > 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).
Elsewhere refers to S 5.5 which says (referring to creation of Global Addresses from info in RAs '...the processing described below MUST be enabled by default'. I think this is sufficiently important (it goes to the heart of plug and play operation) that it is worth a sentence in the Protocol Overview - the words on M and O in previous versions didn't allow any ambiguity. How about adding a sentence after the para at the top of page 10 (ending '...in a separate document.'):
However a host uses the M and O flags, and local configuration to control autoconfiguration, the default setting will result in received Router Advertisements being processed.
>
> > ==============================================================
>
> > 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"?)
Changing s.5.1 to multicast-capable is good. The problem is actually in 2461bis - multicast-capable should be defined there and referenced in 2462bis - I put in a comment on 2461bis suggesting that this needs to be clarified. The problem is that the whole of the ND and RD process (and hence by implication Stateless autoconfig) was intended to be revisited on links that are not 'multicast-capable': the understanding appears (at least at some stage)to have been that multicast-capable means that the underlying link layer support multicast natively but the term is not defined to mean exactly that. On the other hand, the note in 2461bis specifies that every IPv6 link must offer a multicast service so it should (or might) be possible to use this service to do all the things (such as ND) that need link local multicast. 2462bis needs at least some weasel words along the same lines as the second paragraph of the Introduction (s.1) of 2461bis to say t! hat some other mechanism might be used on NBMA etc.
>
> > 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.
Suggest adding to the end of the first para of s.5.4.2:
For an interface to join a multicast address, it has to do two things:
o Configure the interface to receive packets sent to the multicast address
o Send an MLD Listener Report message for the address unless it is the all-nodes
address [RFC2710], [RFC3810]
The interface has to use the unspecified address as the source address for the MLD
Listener Report as it does not have an address when the message is sent.
Two further thoughts here:
- Ought to reference RFC3810 (MLDv2)in addition whereever RFC2710 is referenced at present (or as an alternative?)
- Should interfaces resend the MLD Reports as soon as they get a valid address?
- Should reference RFC3810 wherever
>
> > 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.
Sorry - you are right. I had forgotten the special rules for the all-nodes address - just have to hope snooping switches do the right thing;-) Clearly all-routers is generally not a big problem.
>
> > 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?
The first sentence of s5.5 implies that the only way to get a Global Address is the Stateless Autoconfig way.
How about:
Once an interface has a link local address it can additionally acquire one or more local use or global scope addresses
either through stateful or stateless autoconfiguration. In stateless address autoconfiguration, global and local use addresses are formed by appending...
>
> > 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?
Section 5.5.2 suggests that there needs to be a way to manually configure a router/packet forwarder address (sorry I didn't mean prefix) in case a link has no advertising routers. 2461bis doesn't mention such a capability - the default routers list is built exclusively from RAs at present. Should we ask for it to be added?
>
> > 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".
You are quite right - the DHCPv6 Reconfigure messages are required to be authenticated which reduces the risk here. Incidentally, I was not suggesting that all of 5.5.3 was applicable to DHCP-acquired addresses, only that it might be sensible to apply the Valid Lifetime constraints to other addresses than those constructed by stateless autoconfig.
>
> 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 --------------------------------------------------------------------
