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

From: "Elwyn Davies" <[email-masked]>
Date: Fri, 13 Aug 2004 19:29:40 +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: "Elwyn Davies" <[email-masked]>
Date: Wed, 18 Aug 2004 16:04:27 +0100

OK with me.

Regards,
Elwyn

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: 18 August 2004 15:03
> To: Davies, Elwyn [HAL02:0S00:EXCH]
> Cc: [email-masked]'
> Subject: Re: I-D ACTION:draft-ietf-ipv6-rfc2462bis-05.txt
> 
> 
> One more "easy" point:
> 
> >>>>> On Mon, 16 Aug 2004 18:43:04 +0100, 
> >>>>> "Elwyn Davies" <[email-masked]> said:
> 
> >> (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.
> 
> 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
> 					Communication Platform Lab.
> 					Corporate R&D Center, 
> Toshiba Corp.
> 					[email-masked]
>

---

From: "Elwyn Davies" <[email-masked]>
Date: Mon, 23 Aug 2004 22:51:32 +0100

Ok - that is true - this is a non-issue here at present.

[After some study of the email trails on ULA, I can't see there was
resolution of the discussion of how to handle address selection when ULA and
truly global addresses are available.  This might argue for moving to
non-local anyway.]

Regards,
Elwyn
> From: Vladislav Yasevich [mailto:[email-masked]] 
> Sent: 23 August 2004 19:58
> To: JINMEI Tatuya / ????
> Cc: Davies, Elwyn [HAL02:0S00:EXCH]; [email-masked]'
> Jinmei
> Upon re-reading the ULA spec, I noticed that ULAs are actually
> of 'global' scope, so original wording is OK.  Since 2464bis
> applies to global scope addresses, we are set.
> 
> -vlad
> 
> JINMEI Tatuya / 神明達哉 wrote:
> >>>>>>On Fri, 20 Aug 2004 23:50:51 +0900, 
> >>>>>>JINMEI Tatuya <[email-masked]> said:
> > 
> > 
> >>>Yes - there are 9 instances in the body and 1 in the 
> abstract and non-local
> >>>would be right for all these places I believe.
> > 
> > 
> >>Hmm, the changes are not small and could make the resulting 
> text a bit
> >>vague, but this time I tend to agree on the change.
> > 
> > 
> > On the second thought, I suspect "non-local" is still 
> confusing...even
> > though we are going to define the term as "an address which has a
> > larger scope than link-local," one might wonder if it includes
> > "unique local addresses" (when standardized) in the body of the
> > document.
> > 
> > I can think of two alternatives:
> > 
> > 1. "non-link-local addresses".  This is perhaps verbose, but the
> >    meaning will be clearer.  But one may still wonder if 
> those include
> >    the unspecified address, etc.
> > 2. "large-scope addresses".  On one hand, this is perhaps more vague
> >    than "non-link-local".  But on the other, it will clearly exclude
> >    the unspecified address.
> > 
> > Are either or both alternatives better?  Or can we simply use
> > "non-local"?  Or are there any other options?
> > 
> > 					JINMEI, Tatuya
> -- 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Vladislav Yasevich		Linux and Open Source Lab
> Hewlett Packard 		Tel: (603) 884-1079
> Nashua, NH 03062		ZKO3-3/T07
>