resending because my message did not submitted to ipng. -- inoue
Pekka, Just a quick answers except for relating to MIPv6 and security issues. >On Fri, 1 Mar 2002 [EMAIL PROTECTED] wrote: >> Title : Minimum Requirement of IPv6 for Low Cost Network >> Appliance >> Author(s) : N. OKABE et al. >> Filename : draft-okabe-ipv6-lcna-minreq-01.txt >> Pages : 20 >> Date : 28-Feb-02 > >A few comments in addition to ones I sent for -00.. > > Table 1. Resource restrictions of LCNA > > ===============+===============+==================+======= > Memory CPU Performance OS > ===============+===============+==================+======= > PC >64MB Pentium/64bits Windows > ---------------+---------------+------------------+------- > PDA 2-8MB RISC/32bits(50MHz) WinCE > VxWorks > PalmOS > >==> I think it'd be policitally correct to _at least_ change 'Windows' >there to 'Any', and possibly add 'Others' to PDA section (e.g. I like >Linux and NetBSD on PDA's :-). The footprint of WinCE is 1MB as announced, but the CPU performance of pocket PC becomes higher and higher. So, as you suggested we should replace winCE with embedded Linux or others if we keep on this device class. >2.7 Security > In Section 4 "Security for LCNA", we will regulate a baseline for > guaranteeing that a minimum host can communicate securely. However, > Denial of Service (DoS) and intrusion are out of scope. So, we have > to consider defending from DoS and/or intrusion in another place. > Also, the authentication of users is out of scope, because some > minimum hosts can omit a mechanism of user accounts. > >==> intrusion out of scope? What do you mean by that? >Auth? Here, we mention about intrusion as a typical case that LCNA and other device (such as firewall) work togather in order to provide specific security solution. "Intrusion out of scope" simply means that our spec only treats the end node itself and the security functionality provided by node and other network devices is not considered yet. > - When it can recognize the extension header but does not support > the options in it, it MUST perform error processing according to > the option number. > >==> you mean s/extension header/destination options header/? There is no >processing defined by option number for extension headers. This is our typo. The correct description is as follows: When it can recognize the extension options headers but does not support the options in it, it MUST perform error processing according to the option type. (as secified in section 4.2 of RFC2460) > [Receiving] > A minimum host SHOULD recognize it as a Hop-by-Hop Options Header, > and perform the processing according to the option and option > number in it. Because this option is used for signaling and router > alert, in order to control routers on the path, all nodes on the > transmission path have to interpret this header but do not need to > interpret all options in it. > >==> I don't understand your reasoning for router alert; LCNA's aren't >routers by definition :-) RFC2460 says, "The Hop-by-Hop Options header is used to carry optional information that must be examined by every node along a packet's delivery path." so we regulated that the examination of Hop-by-Hop option have to be performed even on LCNA. Is it too redundant ? > >3.1.2 Routing Header > [Sending] > Following 3.1, minimum hosts do not send packets with this extension > header. > > [Receiving] > RFC regulates that if the Segment Left field has non-zero value in > this header, the node has to forward the packet to the next > intermediate node, even when the node is a host. But in the case of > a minimum host, this forwarding MAY be omitted and be treated as an > unsupported extension header, because only intermediate nodes (such > as routers) and the destination node have to interpret this header. > >==> please see draft-savola-ipv6-rh-hosts-00.txt Basically agree with your draft, if there can implement an user interface (or other methods) to switch the behavior of routing header. >3.1.3 Fragment Header > > If a minimum host satisfies the following conditions, the host MAY > not send this extension header, and MAY treat one as an unsupported > header when receiving it. > >==> I'm not sure what the robustness principle would say about hosts that >cannot defragment. What do you mean for "the robustness principle" ? >3.3 Neighbor Discovery for IP Version 6 (IPv6) (RFC2461) [22] > In this draft, we assume that an LCNA has only one network > Interface, but it does not inhibit multiple interfaces. When > an LCNA is assumed to have multiple interfaces, the following > considerations are necessary, which requires more resources. > > - Source address selection > >==> even with one interface, the LCNA has multiple addresses, so it >obviously still needs source address selection (consider e.g. the case >with link-local, site-local, 6to4 address, and native address). It may >not necessarily need to be as complex though. Agree. We have made separate section of default address selection as 3.8, so we can cut of the descrition here now. > >3.5 Internet Control Message Protocol (ICMPv6) for the Internet Protocol > Version 6 (IPv6) Specification (RFC2463) [24] > > On minimum hosts, ICMP used only by a router MAY be omitted (Table > 2). ICMPs for Echo Request/Reply and minimum error reporting MUST be > supported. > >==> this MUST includes rate-limiting of error replies, I hope? Agree. But we cannot describe LCNA-specific example of rate-limitation. > > Table 2. Mandatory ICMP messages for LCNA > ===============+===============================+========== > Type Code Necessary? > ===============+===============================+========== > 1: 0: No route to destination No > Destination 1: Administratively Prohibited No > Unreachable 3: Address unreachable No > Message 4: port unreachable Yes > >==> depending on how MIPv6 goes, some of these (e.g. admin prohibit) >might become necessary too. Agree. >3.7 DNS Extensions to support IP version 6 (RFC1886) [26] and IPv6 > Stateless DNS Discovery (draft-ietf-ipngwg-dns-discovery-02.txt) > [27] > > The only function that is not supported in the current IPv6 > autoconfiguration is automatic discovery of DNS server. On this > topic discussions are ongoing in IETF IPNG WG. If a standard is > fixed, it might become a mandatory item for minimum hosts. > AAAA record is defined for transform from IPv6 name to IPv6 > address. So, AAAA is currently mandatory for minimum host name > resolution. Also, A6 record is currently proposed and discussed in > IETF for an alternative of AAAA record. We need to check the > progress. > >==> What about reverse lookups? nibble-style, probably? ip6.int or >ip6.arpa, or both? On which case the reverse lookup is necessary in LCNA usage? We complete neglect that. >6.2 Management facilities for LCNAs > >==> personally I think being able to remotely monitor the status of the >system is a rather necessary feature. We want to discuss about which functionality might be important for monitoring LCNA type of devices. > >7. Security Consideration > As mentioned in 2.7, DOS and intrusion are out of the scope of this > draft. > >==> you cannot specify requirements while leaving these features out of >scope. As mentioned above, this simply notes that our focus is only on LCNA node implementation, so the collaborative work with other network devices is omitted on this draft, which should be treated in other places. >10 Appendix: Example of IPSEC minimum requirements specification >[...] > We believe that IPsec is an effective technology in order to > guarantee security of communication. That is the reason why we > regulate the minimum IPsec specification in this draft. > >==> this needs editing as the last sentence is obviously false. Agree. We bring the original description of draft-00 but we should rewrite them because out treatment of IPsec has almost changed. We will send answers for rest of questions later. -- inoue -- Atsushi INOUE mailto:[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] --------------------------------------------------------------------
