WG Members, I want to fully support this AD review and feel the node requirements draft is not ready to be published even as informational until this excellent review is answered in detail. I do not believe an informational document should ever override and existing standards track document ever in our community, and that is not a good practice.
My input is this document cannot move forward. If you want to discuss my second sentence above its my opinion and I suggest the WG not focus on that statement because it will slow down the progression of this document. It for now is rhetorical comment. If you want to discuss with me offline that is fine with me. Respectfully, /jim > -----Original Message----- > From: Thomas Narten [mailto:[EMAIL PROTECTED] > Sent: Wednesday, August 27, 2003 5:30 PM > To: [EMAIL PROTECTED] > Subject: AD review of draft-ietf-ipv6-node-requirements-05.txt > > > The WG has asked this be published as an Informational > document. Here are my review comments. I assume some > discussion and a revised ID will be needed before I forward > the document to the IESG as a whole. > > Note: some of these points may best be responded to by > starting a separate thread, so folk can easily follow > individual topics of interest. > > Thomas > > substantative (more or less...): > > General comment. There are places in the document where it is > not immediately clear whether something is required to be > implemented or not. Sometimes the wording is just "support", > and in the context of the wording, this may depend on > deployment considerations. I would except that the purpose of > this document is to make it clear what needs to implemented. > I mention some specific cases below, but may not have caught > them all... It might be good to scan the document for > "support" and check that the intent is clear. > > > Nodes MUST always be able to receive fragment headers. > However, if it > > does not implement path MTU discovery it may not need to send > > fragment headers. However, nodes that do not implement > transmission > > of fragment headers need to impose a limitation to the > payload size > > of layer 4 protocols. > > This would seem inconsistent with the following wording in RFC 2460: > > In response to an IPv6 packet that is sent to an IPv4 destination > (i.e., a packet that undergoes translation from IPv6 to IPv4), the > originating IPv6 node may receive an ICMP Packet Too Big message > reporting a Next-Hop MTU less than 1280. In that case, > the IPv6 node > is not required to reduce the size of subsequent packets > to less than > 1280, but must include a Fragment header in those packets > so that the > IPv6-to-IPv4 translating router can obtain a suitable > Identification > value to use in resulting IPv4 fragments. Note that this > means the > payload may have to be reduced to 1232 octets (1280 minus > 40 for the > IPv6 header and 8 for the Fragment header), and smaller still if > additional extension headers are used. > > > Router Discovery is how hosts locate routers that reside on an > > attached link. Router Discovery MUST be supported for > > implementations. However, an implementation MAY support disabling > > this function. > > Why the MAY above? If there are reasons to allow this, it > would be good to give some examples of the WG's thinking for > calling out such an exception. Also, this is a change to 2461 > I assume? > > > Prefix Discovery is how hosts discover the set of > address prefixes > > that define which destinations are on-link for an attached link. > > Prefix discovery MUST be supported for implementations. > However, the > > implementation MAY support the option of disabling this function. > > same comment with regards to MAY. And also, am I right to > assume that disabling this function would need to be done on > a per-interface basis (in which case the current text isn't > explicit enough)? I.e, is this related to some 3G type deployment? > > > Duplicate Address Detection MUST be supported (RFC2462 > section 5.4 > > specifies DAD MUST take place on all unicast addresses). > > This reference to 2462 section 5.4 is a tad misleading. The > relevant paragraph in 2462 says: > > > 5.4. Duplicate Address Detection > > > > Duplicate Address Detection is performed on unicast > addresses prior > > to assigning them to an interface whose DupAddrDetectTransmits > > variable is greater than zero. Duplicate Address > Detection MUST take > > place on all unicast addresses, regardless of whether they are > > obtained through stateful, stateless or manual > configuration, with > > the exception of the following cases: > > Note that one of the exception cases is stateless addr conf > when configuring multiple addresses using the same IID. Is > node-requirments trying to override this exception? If so, it > should be explicit about it. Otherwise, I'm not sure why the > above sentence is included in node-requirements. > > > 4.5.4 Default Address Selection for IPv6 - RFC3484 > > > > Default Address Selection for IPv6 [RFC-3484] SHOULD be > supported, if > > a node has more than one IPv6 address per interface or a node has > > more that one IPv6 interface (physical or logical) configured. > > > > If supported, the rules specified in the document MUST be > > implemented. A node needs to belong to one site, however > there is no > > requirement that a node be able to belong to more than one site. > > This is really weasle worded. Is 3484 mandatory to > _implement_ or not? You can't make its implementation > dependent on whether there are multiple addresses, since the > number of addresses a node will have is not something an > implementor will know, as it's an operational issue. > > > DNS, as described in [RFC-1034], [RFC-1035], [RFC-1886], > [RFC-3152] > > and [RFC-3363] MAY be supported. Not all nodes will > need to resolve > > names. Note that RFC 1886 is currently being updated > > [RFC-1886-BIS]. > > 1886-bis has been approved by the IESG I believe... > > Also, I suspect this section really needs to talk about > resolvers and resolver behavior, rather than just say DNS. > Most of the server issues do not apply to generic IPv6 nodes. > But almost every node will have some sort of resolver... > > > 5.3.1 Managed Address Configuration > > IMO, it doesn't make sense to talk about "implementing DHC" > without being more specific. I suspect that all of this > section is about the client part of DHC, not the server. It > would be good to make this clear. Ditto for 5.3.2. > > Stateless DHCPv6 [DHCPv6-SL], a subset of DHCPv6, can be used to > obtain configuration information. A node that uses stateless DHCP > must have obtained its IPv6 addresses through some other mechanism, > typically stateless address autoconfiguration. > > Does this even need mentioning? I.e, what are the real > implications for clients? Do they need to implement full > blown dhc (the client part)? Or do they implement some > subset? (Hmm... reading the related draft, clients implement > a subset... And this document has a normative reference to > the other ID, so either this document needs to be more > explicit about what stateless DHCPv6 is, or will have to wait > on the other document.) > > > 6.1 Transition Mechanisms > > > > IPv6 nodes SHOULD use native addressing instead of > transition-based > > addressing (according to the algorithms defined in RFC 3484). > > Is this a statement about what needs to be implemented? Or is > this an operational statement? (This document seems to be > mostly about the former, and this statement seems odd without > more context...) > > > Routers do not need to support route optimization or home agent > > functionality. > > > > Routers SHOULD support the generic mobile IP requirements. > > I think it would be better to replace the above with something like: > > Routers SHOULD support the router-specific extensions defined in > Section 8.3 of MIPv6 > > And include a normative reference to the document. > > > 7.2 Securing Signaling between Mobile Nodes and Home Agents > > > > The security mechanisms described in [MIPv6-HASEC] MUST > be supported > > by nodes implementing mobile node or home agent functionality > > specified in Mobile IP [MIPv6]. > > So would presumably the applicable parts of Section 8 of the > mipv6 spec. Better to cite them explicitely. > > > Generic Packet Tunneling [RFC-2473] MUST be supported for nodes > > implementing mobile node functionality or Home Agent > functionality of > > Mobile IP [MIPv6]. > > This may not need mentioning, as it may already be covered in > Section 8 of the mipv6 spec. > > Actually, this entire section may warrant rethinking given > the existance of Section 8 in the MIPv6 spec. > > Section 9 begins by saying: > > > 9. Router-Specific Functionality > > > > This section defines general host considerations for > IPv6 nodes that > > act as routers. Currently, this section does not discuss routin- > > specific requirements. > > an then immediately says > > > 9.1.1 IPv6 Router Alert Option - RFC2711 > > > > The Router Alert Option [RFC-2711] MUST be supported by > nodes that > > perform packet forwarding at the IP layer (i.e. - the node is a > > router). > > But this seems like a "forwarding-related" requirement. When > do routers send router alerts? They need to process them when > they are received, e.g., as part of MLD stuff. When else are > they used? > > > 11. Security Considerations > > This section seems both too detailed and not detailed enough. > Too detailed in that it talks about security issues related to some > (arbitrary?) protocols like ICMPv6, but not detailed enough > in that it is anywhere complete and doesn't mention many > other protocols that could also be included if one were to > include ICMPv6. My suggestion would be to up-level here and > not talk about detailed security issues of individual > protocols. If you want to do that, point to the security > sections in other documents. But if you do this, you'll have > a hard time deciding whether to mention every document or just some. > > Does _this_ document itself introduce or raise any security > issues not covered elsewhere? That is the question this > document should focus on. The answer may be mostly no. > > Finally, there are an awful lot of references to IDs in the > normative section. That's a problem. See defn. of normative > in draft-rfc-editor-rfc2223bis-06.txt. > > Nits/editorial: > > > The goal of this document is to define the set of functionality > > required for an IPv6 node; the functionality common to > both hosts and > > routers. Many IPv6 nodes will implement optional or additional > > Sentence with semi-colon doesn't parse. :-( > > > 3.1 Transmission of IPv6 Packets over Ethernet Networks - RFC2464 > > > > Transmission of IPv6 Packets over Ethernet Networks > [RFC-2464] MUST > > be supported for nodes supporting Ethernet interfaces. > > I don't quite like the way this (and subsequent) sentences is > worded. We don't want to imply that nodes that support IPv4 > over Ethernet must also support this... > > How about: > > Nodes supporting IPv6 over Ethernet interfaces MUST implement > Transmission of IPv6 Packets over Ethernet Networks [RFC-2464]. > > same applies to remaining LL sub-sections. > > > IPv6 over ATM Networks [RFC2492] MUST be supported for nodes > > supporting ATM interfaces. Additionally, the > specification states: > > what does "the specification" refer to? How about saying > > Additionally, RFC 2492 states: > > > > > option of disabling this function. The ability to > understand specific > > Router Advertisement optionss is dependent on supporting the > s/optionss/options/ > > specification where the RA is specified. > > s/the RA/the particular RA option/ > > > Redirect functionionality SHOULD be supported. If the node is a > spelling > > router, Redirect functionionality MUST be supported. > > > > > Path MTU Discovery [RFC-1981] MAY be supported. It is > expected that > > most implementations will indeed support this, although > the possible > > exception cases are sufficient that the used of "SHOULD" is not > > justified. The rules in RFC 2460 MUST be followed for packet > > fragmentation and reassembly. > > Same comment applies here as mentioned earlier. > > > Nodes that are routers MUST be able to generate link > local addresses > > as described in this specification. > > "this specification" is ambiguious. Do you mean 2460? > > > > If an application is going join any-source multicast, it SHOULD > > support MLDv1. If it is going to support Source-Specific > > Multicast, > > s/join any-source multicast/to join any-source multicast > group addresses/ > > also: > > If an application is going join any-source multicast, it SHOULD > support MLDv1. If it is going to support Source-Specific > Multicast, > it MUST support MLDv2 [MLDv2] and conform to the Source-Specific > Multicast overview document [RFC3569]; refer to Source-Specific > Multicast architecture document for details [SSMARCH]. > > > Is worded oddly. If A, you SHOULD do MLDv1. If B, you MUST > do MLDv2. Shouldn't the first SHOULD be a MUST as well? How > can you not support MLDv1 if you are going to join multicast > groups and not going to do MLDv2? > > > This specification MUST be supported if jumbograms are > implemented > > [RFC-2675]. One open issue is if this document needs to > be updated, > > as it refers to an obsoleted document. > > Drop last sentence? I suspect it's irrelevant, as the updated > that is needed is cosmetic/editorial, not substantative. Right? > > > > This document is currently being updated. > > s/this document/RFC2893/ > > > > 7.3 Generic Packet Tunneling in IPv6 Specification - RFC2473 > > nit: indention is wrong on this heading. > > > > 3DES-CBC does not suffer from the issues related to > DES-CBC. 3DES-CBC > > and ESP CBC-Mode Cipher Algorithms [RFC2451] MAY be > supported. AES- > > 128-CBC [ipsec-ciph-aes-cbc] MUST be supported, as it is > expected to > > be a widely available, secure algorithm that is required for > > interoperability. It is not required by the current IPsec RFCs, > > however. > > Perhaps add to last sentence, "but is expected to become > required in the future" ??? > > act as routers. Currently, this section does not discuss routin- > specific requirements. > > s/routin/routing/ > > > > At least the following two MIBs SHOULD be supported MIBs > SHOULD be > > supported by nodes that support an SNMP agent. > > duplicate words. > > > 10.1.1 IP Forwarding Table MIB > > > > Support for this MIB does not imply that IPv4 or IPv4 specific > > portions of this MIB be supported. > > Which MIB is this? (No reference provided...) > > > 10.1.2 Management Information Base for the Internet Protocol (IP) > > Ditto. > > > 12.1 Normative > > > > [DHCPv6-SL] R. Droms, "A Guide to Implementing > Stateless DHCPv6 > > Service", Work in Progress. > > For all the references, please include the ID name, so folk > can actually figure out which ID it refers to. Also the RFC > editor will want to know this too, so they can put in the > right references, in case any are already RFCs. > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
