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

From: "Elwyn Davies" <[email-masked]>
Date: Mon, 16 Aug 2004 18:43:04 +0100

Hi.

Responses and comments/thoughts below.

Regards,
Elwyn

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: 16 August 2004 09:46
> To: Davies, Elwyn [HAL02:0S00:EXCH]
> Cc: [email-masked]'
> 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-masked]> 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 that 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-masked]
> 
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 17 Aug 2004 22:44:41 +0900

Some quick clarifications:

>>>>> On Mon, 16 Aug 2004 18:43:04 +0100, 

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

I guess you meant the following message:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg03314.html

but I'm still not 100% sure about the point.

I hate to make a wild guess and continue the discussion based on the
assumption, but if you mean it is confusing to tie the M/O flags with
the notion of "stateful" protocols while RFC3736 calls itself
"stateless", I tried to clarify this point in rfc2462bis:

   To obtain other configuration information without configuring
   addresses in the stateful autoconfiguration model, a subset of DHCPv6
   [RFC3736] will be used.  While the model is called "stateful" here in
   order to highlight the contrast to the stateless protocol defined in
   this document, the intended protocol is also defined to work in a
   stateless fashion.  This is based on a result, through operational
   experiments, that all known "other" configuration information can be
   managed by a stateless server, that is, a server that does not
   maintain state of each client that the server provides with the
   configuration information.

Note that this is a compromise with the real world standardization
status.  Perhaps you are not 100% comfortable with the compromise (I'm
not, actually), we needed to face that RFC3736 was already
standardized and people do not want to change the phrase "stateful" in
rfc2461bis/rfc2462bis.  I could not think of better compromise...

> addresses than those constructed by stateless autoconfig. 

So I interpret this to mean this is a non issue in rfc2462bis.

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 18 Aug 2004 22:42:55 +0900

I'm replying to some of the other points you made.  I guess we may
need a separate discussion for the rest, so I'll create dedicated
entries for them in the issue tracker.

> autoconfiguration, global and local use addresses are formed by appending...

First, let's just forget "local use" addresses here (whatever you mean
by this).  Those are not in the scope of rfc2462bis.

Besides, the first sentence is not really accurate since a global
address can be generated in concurrent with the creation of a
link-local address.  So, we can simply say:

  In stateless address autoconfiguration, global addresses are formed by
  appending...

I don't mind to make this modification.

> default routers list is built exclusively from RAs at present. Should we ask

I'm not really sure what you meant by "the default routers list is
built exclusively from RAs at present", but it may make sense to say
in rfc2461bis that there is no other way to configure the "forwarding
node's address" automatically as a (possibly bad) effect of not
sending RAs.

In any event, I interpreted this is not a new issue for rfc2462bis.

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Wed, 18 Aug 2004 23:02:39 +0900

> Advertisements being processed.

Hmm, I still don't see the strong need for this, but it is a minor
change that may help, so I don't mind to add this with a small
modification: "received Router Advertisements being processed" is
ambiguous.  I'd reword this to:

  the default setting will result in received Router Advertisements
  being processed for stateless address autoconfiguration.

					JINMEI, Tatuya