Pekka, Thanks for the comments. My response inline. If I don't address a comment below, it means I have no problem updating the draft with the comment. Others please take a look and voice opinions if you have them. We should try to make this LC have a deadline :)
> substantial > ----------- > > ==> this spec needs at least an IANA Considerations section, > stating at > least: > 1) the allocation guidelines for ND option types/codes > (Standards Action? > IETF Consensus?) > 2) that no IANA action is required for ICMPv6 types, > beyond updating > the ICMPv6 codepoints to refer to this RFC instead of > RFC2461 in their > registry. => ok. I didn't think IANA sections had to be included but I'll add 2) above. > > AdvValidLifetime > The value to be placed in the Valid > Lifetime in the Prefix Information > option, in seconds. The > designated value > of all 1's (0xffffffff) represents > infinity. Implementations MUST allow > AdvValidLifetime to be specified in two > ways: > > - a time that decrements in > real time, > that is, one that will result in a > Lifetime of zero at the specified > time in the future, or > > - a fixed time that stays the same in > consecutive advertisements. > > ==> AFAIK, the first option has not been implemented; I've > at least not seen > in done. Therefore unless someone shows that there are two > implementations > of this, this must be removed. (The same for > AdvPreferredLifetime, and a bit > in section 6.2.7.) => There are three issues to consider: 1. The second option actually (evidently more implemented) seems strange. If the time is decremented, then why not reflect that in advertisements? 2. One could argue that this is an implementation issue. The receiver will update the Valid Lifetime field each time it gets an adv. So does it matter if it's a different value each time or the same? 3. As Bob mentioned, this is already a DS and I'm not sure if we want to remove this now, especially if we don't know 100 % that it's not implemented. > > Note: Implementations can choose to process the > on-link aspects of > the prefixes separately from the address > autoconfiguration aspects > of the prefixes by, e.g., passing a copy of each valid Router > Advertisement message to both an "on-link" and an "addrconf" > function. Each function can then operate independently on the > prefixes that have the appropriate flag set. > > ==> similar to above, has this been implemented ? Not a as > big issue as > above for me, because this is just an implementation note. => Agreed, this is just an implementation issue. > > A proxy MAY multicast Neighbor Advertisements when its link-layer > address changes or when it is configured (by system management or > other mechanisms) to proxy for an address. If there are multiple > nodes that are providing proxy services for the same set > of addresses > the proxies SHOULD provide a mechanism that prevents > multiple proxies > from multicasting advertisements for any one address, in order to > reduce the risk of excessive multicast traffic. > > ==> does anyone implement this SHOULD? Note that this does > not give hints > how to even go about doing that. If not, remove. => I don't know if anyone implements it, but they SHOULD ;) This is what the spec recommends, is it wise to change the (preumably) reocmmended mechanism because some don't follow it? > > NORMATIVE > > [ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing > Architecture", RFC 2373, July 1998. > > ==>replace with 3513. However, there is one big problem > here. addrarch is > PS, while this is going for DS. DS cannot have normative > ref to PS. It is > not clear whether ADDR-ARCH can be put in as informative > reference, the text > seems to be relying on it pretty heavily. OK with me, but > there may be > problems.. => Agreed. It seems to be normative. I'll change the references and let the WG chairs/ADs provide suggestions on how to handle this. > > [MLD] Deering, S., Fenner, W, and B. Haberman, "Multicast > Listener Discovery for IPv6", RFC 2710, > October 1999. > > ==> this is also PS and cannot be referred to normatively. => This one can be informative. > > [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. > > ==> this must be over at the normative refs => ok. > > semi-editorial > -------------- > > Inbound load balancing - Nodes with replicated > interfaces may want > to load balance the reception of incoming packets across > multiple network interfaces on the same link. Such nodes > have multiple link-layer addresses assigned to the same > interface. For example, a single network driver could > represent multiple network interface cards as a single > logical interface having multiple link-layer addresses. > > Load balancing is handled by allowing routers to omit the > source link-layer address from Router > Advertisement packets, > [...] > > ==> this is conflicting. The first para discusses generic > inbound load > balancing, the second load balancing that applies only to > routers w/ RAs. > How do hosts perform inbound load balancing? Needs text tweaking.. => ok, suggestions are welcome. > > Unlike in IPv4 Router Discovery the Router > Advertisement messages > do not contain a preference field. The preference > field is not > needed to handle routers of different "stability"; > the Neighbor > Unreachability Detection will detect dead routers and > switch to a > working one. > > ==> preference has been plugged back, though not for stability > reasons. I'd suggest just removing this paragraph. => As you said, the preference is not used for stability reasons. I can clarify that it might be used for other reasons and leave it at that because this statement is still correct. The preference is optional in v6. > > Placing address resolution at the ICMP layer makes > the protocol > more media-independent than ARP and makes it possible to use > standard IP authentication and security mechanisms as > appropriate. > > ==> the latter part of this sentence is a bit questionable, > as this probably > referred to using IPsec. Still, there is a benefit of being > able to use a > single SEND mechanism for _all_ link types. Text tweaking needed. > > variable MTU - Neighbor Discovery allows routers to > specify a MTU > for the link, which all nodes then > use. All nodes > on a link must use the same MTU (or Maximum > Receive Unit) in order for multicast to work > properly. Otherwise when > multicasting a sender, > which can not know which nodes will > receive the > packet, could not determine a minimum > packet size > all receivers can process. > > ==> the last sentence is not 100% accurate. It's not MTU at > stake, it's the > receiver's MRU (for processing the packet) or last-hop > router's MTU (for > sending the packet on the last links). Might need minor text tweak. > > If the bridges do not generate ICMP > Packet Too Big messages, communicating > nodes will > be unable to use Path MTU to > dynamically determine > the appropriate MTU on a per-neighbor > basis. In > such cases, routers use the MTU option > to specify > the maximum MTU value that is supported by all > segments. > > ==> s/routers use/routers can be configured to use/ -- there > is no magic to > do this automatically.. > > 6.2.8. Link-local Address Change > > The link-local address on a router SHOULD change rarely, if ever. > > ==> this is an improper use of upper-caps. Just make it lowercase. > > For instance, a > mobile node, using [MIPv6], moving to a new link would need to > discover such movement as soon as possible to minimize > the amount of > packet losses resulting from the change in its > topological movement. > Router Solicitations provide a useful tool for movement > detection in > Mobile IPv6 as they allow mobile nodes to determine > movement to new > links. Hence, if a mobile node received link layer information > indicating that movement might have taken place, it MAY > send a Router > Solicitation immediately, without random delays. The > strength of such > indications should be assessed by the mobile node's > implementation > and is outside the scope of this specification. > > ==> it might not hurt to discuss the potential pitfalls of > this approach > somewhere. For example, n case the link indications are > shaky, or just hints, > and there is a significant number of MNs on a link, this > could result in an > RS storm. > > - The Target Address is a "valid" unicast or anycast address > assigned to the receiving interface [ADDRCONF], > > - The Target Address is a unicast address for which the node is > offering proxy service, or > > - The Target Address is a "tentative" address on which Duplicate > Address Detection is being performed [ADDRCONF]. > [...] > > > If the Target Address is either an anycast address or a unicast > address for which the node is providing proxy service, > or the Target > Link-Layer Address option is not included, the Override > flag SHOULD > be set to zero. [...] > > ==> the middle bullet point appears to be inconsistent with > the further > specification. That is, shouldn't an anycast address also > be acceptable > (not that the node could tell it's anycast address :) > > If the target's Neighbor Cache entry is in the > INCOMPLETE state when > the advertisement is received, one of two things happens. > Otherwise, the receiving node performs the following > steps: > > ==> "one of two" ? You do not specify or clearly refer to either > one of these. Needs rewording. > > If the target's Neighbor Cache entry is in any state other than > INCOMPLETE when the advertisement is received, processing becomes > quite a bit more complex. If the Override flag is clear and the > supplied link-layer address differs from that in the > cache, then one > of two actions takes place: if the state of the entry is > REACHABLE, > set it to STALE, but do not update the entry in any other way; > otherwise, the received advertisement should be ignored > and MUST NOT > update the cache. If the Override flag is set, both the Override > flag is clear and the supplied link-layer address is the > same as that > in the cache, or no Target Link-layer address option was > supplied, > the received advertisement MUST update the Neighbor > Cache entry as > follows: > > ==> AFAICS, you can remove 'both the Override flag is clear > and' here, > because the same result happens if the Override flag is set. > > A router MUST limit the rate at which Redirect messages > are sent, in > order to limit the bandwidth and processing costs incurred by the > Redirect messages when the source does not correctly > respond to the > Redirects, or the source chooses to ignore > unauthenticated Redirect > messages. More details on the rate-limiting of ICMP > error messages > can be found in [ICMPv6]. > > ==> 'or the source chooses to ignore unauthenticated Redirect > messages' smells quite a bit from a leftover of IPsec AH > times. Reword? => Hmm, ok let me take a good look at it. In general, it's an acceptable statement, of course in reality there is no way of securing it for large scale deployment. AFAIK SEND didn't secure redirects. > > An example of denial of service attacks is that a node > on the link > that can send packets with an arbitrary IP source > address can both > advertise itself as a default router and also send > "forged" Router > Advertisement messages that immediately time out all > other default > routers as well as all on-link prefixes. > > ==> 'on-link' is not accurate. Using these mechanisms, you > can't capture > _all_ on-link traffic as that goes between the nodes. You > can capture that > e.g. by advertising more specifics in RAs, with NA/ND > spoofing, etc., but > the sentence does not seem to be 100% correct. > > o Removed the on-link assumption in section 5.2 > > ==> add an informational reference to > draft-ietf-v6ops-onlinkassumption here, as that doc captures the > reasoning for the change. > > editorial > --------- > > link-layer address > - a link-layer identifier for an interface. Examples > include IEEE 802 addresses for Ethernet > links and E.164 > addresses for ISDN links. > > ==> please remove the ISDN E.164 example, that's too crufty > to be here.. > > non-broadcast multi-access (NBMA) > - a link to which more than two > interfaces can attach, > but that does not support a native form > of multicast > or broadcast (e.g., X.25, ATM, frame > relay, etc.). > > > Note that all link types (including NBMA) are > > ==> kill the extra empty line. > > all-nodes multicast address > - the link-local scope address to reach all nodes. > FF02::1 > > ==> s/nodes./nodes,/, s/1/1./ -- the same with all-routers. > > A solicitation that passes the validity checks is called a "valid > solicitation". > .. > An advertisement that passes the validity checks is > called a "valid > advertisement". > .. > A Neighbor Solicitation that passes the validity checks > is called a > "valid solicitation". > .. > A Neighbor Advertisements that passes the validity > checks is called a > "valid advertisement". > > ==> I'd rewrite these to be "valid router solicitation", > "valid router > advertisement", "valid neighbor solicitation", etc. > > 6.3.4. Processing Received Router Advertisements > > When multiple routers are present, the information advertised > collectively by all routers may be a superset of the information > contained in a single Router Advertisement. Moreover, > information > may also be obtained through other dynamic means, such > as stateful > autoconfiguration. Hosts accept the union of all received > information; the receipt of a Router Advertisement MUST NOT > invalidate all information received in a previous > advertisement or > from another source. However, when received information for a > specific parameter (e.g., Link MTU) or option (e.g., > Lifetime on a > specific Prefix) differs from information received > earlier, and the > parameter/option can only have one value, the most > recently-received > information is considered authoritative. > > ==> it might not hurt to add an explicit reference to > section 6.2.7 on the > consistency -- maybe even replacing the duplicate list here.. > > Before a host sends an initial solicitation, it SHOULD delay the > transmission for a random amount of time between 0 and > MAX_RTR_SOLICITATION_DELAY. This serves to alleviate > congestion when > many hosts start up on a link at the same time, such as > might happen > after recovery from a power failure. If a host has > already performed > a random delay since the interface became (re)enabled > (e.g., as part > of Duplicate Address Detection [ADDRCONF]) there is no > need to delay > again before sending the first Router Solicitation > message. In some > cases, the random delay MAY be omitted if necessary. [...] > > ==> please split this ridiculously long paragraph to at > least two -- maybe > before "In some cases,". > > interface should be used. Using the prompting packet's source > address when possible insures that the recipient of the Neighbor > Solicitation installs in its Neighbor Cache the IP > address that is > > ==> s/insures/ensures/ > > [issuing redirects] > - the router determines that a better first-hop node > resides on > the same link as the sending node for the > Destination Address of > the packet being forwarded, and > > ==> maybe s/determines/determines using unspecified > mechanisms/ that this is > out of scope of this spec. > > The trust model for redirects is the same as in IPv4. A > redirect is > accepted only if received from the same router that is currently > being used for that destination. It is natural to trust > the routers > on the link. If a host has been redirected to another > node (i.e., > the destination is on-link) there is no way to prevent the target > from issuing another redirect to some other destination. > However, > this exposure is no worse than it was; the target host, once > subverted, could always act as a hidden router to forward traffic > elsewhere. > > ==> add the empty line before the start of this paragraph > ==> "than it was" --> what does this refer to ? > > On the > other hand, many of the threats discussed in this > section are less > effective, or non-existent, on point-to-point links, or cellular > links where hosts share links with one neighbor, i.e. the default > router. > > ==> s/hosts share links with one/a host shares a link with > only one/ ? > > [ASSIGNED] Reynolds, J. and J. Postel, "ASSIGNED > NUMBERS", STD 2, > RFC 1700, October 1994. See also: > http://www.iana.org/numbers.html > > ==> this should probably be replaced with RFC3232 ("Assigned > Numbers: RFC > 1700 is Replaced by an On-line Database"). > > > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > =========================================================== This email may contain confidential and privileged material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient please contact the sender and delete all copies. =========================================================== -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
