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 PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 12 August 2004 20:31
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> 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 PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
