Hi Pekka, Thank you for your feedback.
We talked about the draft with chairs in Yokohama. They gave us the following suggestions: 1) IPv6 WG should not pursue separate requirements documents for different types of IPv6 nodes. 2) Instead, the minimal requirements for all IPv6 nodes to be reflected in the IPv6 Node Requirements effort. We agreed the above, and stopped to update the draft. Sorry for confusing you. From: Pekka Savola <[EMAIL PROTECTED]> Subject: comments on lcna-minreq-02 Date: Sat, 7 Sep 2002 23:02:46 +0300 (EEST) > A few comments on lcna-minreq-02. > > 2.2.3 Anycast > An LCNA might use the anycast address in some instances, e.g. DNS > server discovery, but never assign anycast addresses to its own > interface ([rfc2526]). > > [Note]: > According to [rfc2373] section 2.6, anycast address is not assigned > to a host, but discussion is still going on. > > ==> perhaps note can be removed, as it changes nothing. You can still > specify that lcna does not do anycast even if 2373 was changed. > > 2.3 Examples of LCNA applications > Here are several examples of LCNA usage models, especially for home > network applications. > > ==> these should be moved to an appendix. > > 3.1.2 Routing Header > [Sending] > LCNAs may not originate Routing Header. > > ==> what do you mean by "may not"? (do not have to be able to?) > > [Receiving] > As [rfc2460] regulates, the processing of segment_left as zero is > unconditionally mandatory. > > ==> well, there's nothing to process, but LCNA has to be able to parse > routing header, yes. > > If the Segment Left field has a non-zero > value and RH type is zero, the LCNA SHOULD forward the packet to the > next intermediate node, even when the node is a host. > However, if the LCNA has limited resource, it can respond to this RH > with parameter problem ICMP. > > ==> this has problems, see (hopefully) node reqs draft or > draft-savola-ipv6-rh-hosts-00.txt > > 3.2 Path MTU Discovery for IP version 6 [rfc1981] > When an implementation can guarantee that the sending packet size > can be restricted to less than the IPv6 MINMTU > > ==> s/less than/less than or equal to/ > > 3.3 Neighbor Discovery for IP Version 6 (IPv6) [rfc2461] > > In this document, we assume that an LCNA has only one network > Interface, but it does not prohibit multiple interfaces. When > an LCNA is assumed to have multiple interfaces, the following > must be considered requiring more resources. > - Types of routing information (such as destination cache and > routing table) > - Number of cache entries will increase > * ND cache > * Default router list > * Prefix list > > ==> are you making an implicit assumption that there couldn't be multiple > prefixes advertised over one physical interface? > > 3.5 Internet Control Message Protocol (ICMPv6) for the Internet Protocol > Version 6 (IPv6) Specification [rfc2463] > On LCNAs, ICMP used only by a router MAY be omitted (Table > 2). ICMPs for Echo Request/Reply and minimum error reporting MUST > be implemented. The necessary function for ICMPv6 may be added > depending upon the finalization of Mobile IPv6 specification. > An LCNA MUST have some mechanism for Rate limitation. > > ==> rate limitation of what? ICMP error messages (as noted by ICMPv6 spec) > or for e.g. ICMP echo req/reply too? > > Table 2. Mandatory ICMP messages for LCNA > ===============+===============================+========== > Type Code Necessary? > ===============+===============================+========== > [...] > 2: 0: Packet too big No > Packet > Too Big > Message > > ==> if an LCNA receives a packet that's too big and can't process it, how > would it react (it's able to deal with at least 1500 bytes right?)? > > > 5.1 DNS Extensions to support IP version 6 [rfc1886] and IPv6 > Stateless DNS Discovery [DDIS] > > If an LCNA is a passive node, it will not become an initiator > of communication. This means that name resolution function MAY > be omitted (the implementation of resolver can be omitted on a > > On the other hand, if an LCNA is an active node, DNS name resolution > is necessary. In such cases, automatic DNS server discovery is > important. On this topic, discussions are ongoing in IETF IPv6 > WG. If a standard is finalized, it might become a mandatory item > for LCNAs. > > AAAA is mandatory if an LCNA needs DNS name lookups. A6 record > is currently proposed and discussed in IETF for an alternative to > AAAA record. We need to check the progress. > The IN6.ARPA. domain and nibble-style are mandatory if an LCNA needs > DNS reverse name lookups. However, the IP6.INT. is more widely used > than the IN6.ARPA. at this time. > > ==> I think the first paragraph is a bit out of sync; passive nodes may do > DNS lookups (specifically, often reverse DNS lookups). > > -- > Pekka Savola "Tell me of difficulties surmounted, > Netcore Oy not those you stumble over and fall" > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- ---- nobuo -------------------------------------------------------------------- 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] --------------------------------------------------------------------
