INTERNET-DRAFT Nobuo Okabe Internet Engineering Task Force Shoichi Sakane Issued: June 29, 2002 Yokogawa Electric Corporation Expires: December 29, 2002 Atsushi Inoue Masahiro Ishiyama Toshiba Corporation Hiroshi Esaki The Univ. of Tokyo Host Requirements of IPv6 for Low Cost Network Appliances Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as 'work in progress.' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Resource limitations and cost constraints associated with small-embedded devices make it difficult to implement the entire IPv6 specification. We call such non-PC embedded devices (e.g. game-machines, AV devices, sensors, digital cameras, LCD projectors, and home appliances) "Low Cost Network Appliances", and define the IPv6 host requirements for them. In this document, we will also point out several items to be discussed for the deployment of IPv6 on LCNAs. okabe [Page 1] Internet Draft Host Requirements of IPv6 for LCNA June 2002 Table of Contents Abstract ................................................................1 1 Introduction...........................................................3 1.1 Requirement Language ...............................................4 2 Assumption for an LCNA ................................................4 2.1 Hardware configuration .............................................5 2.2 Functions which are Out-of-scope in this document ..................5 2.2.1 Transition technology from IPv4 .................................5 2.2.2 Multicast .......................................................5 2.2.3 Anycast .........................................................5 2.2.4 API .............................................................5 2.2.5 Management functions ............................................6 2.2.6 Mobility support ................................................6 2.3 Examples of LCNA applications ......................................6 2.3.1 Video camera image displayed on TV is recorded on VCR ..........6 2.3.2 The image captured by the home video camera is forwarded to a portable node (such as PDA and cellular phone) ................7 2.3.3 The video camera in the home network pushes the captured image to a portable node ..............................................8 3 IPv6 requirement for LCNA .............................................8 3.1 Internet Protocol, Version 6 (IPv6) Specification ..................8 3.1.1 Hop-by-Hop Options Header ......................................8 3.1.2 Routing Header .................................................9 3.1.3 Fragment Header ................................................9 3.1.4 Destination Options Header .....................................9 3.1.5 No Next Header .................................................9 3.2 Path MTU Discovery for IP version 6 ................................9 3.3 Neighbor Discovery for IP Version 6 ...............................10 3.4 IPv6 Stateless Address Autoconfiguration ..........................10 3.5 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification ...........................10 3.6 IP Version 6 Addressing Architecture ..............................11 3.7 Scope handling ....................................................12 3.8 Default Address Selection for IPv6 ................................12 3.9 Multicast Listener Discovery (MLD) for IPv6 .......................12 4 IPsec for LCNAs ......................................................12 4.1 IPsec specification for LCNA ......................................13 4.1.1 Security Policy Database .......................................13 4.1.2 Security Protocols .............................................13 4.1.3 Transforms and Algorithms ......................................13 4.1.4 SA and Key Management ..........................................13 4.2 Further study for LCNA security ...................................14 5 Miscellaneous items ..................................................14 5.1 DNS Extensions to support IP version 6 and IPv6 Stateless DNS Discovery .........................................................14 5.2 Network-boot devices ..............................................15 5.3 Management facilities for LCNAs ...................................15 6 Security Considerations ..............................................15 7 Contact information ..................................................16 8 Update from Version-01 ...............................................16 9 Appendix: Difficulty of packet size control mechanism ................16 10 Contributors List ...................................................17 11 Acknowledgements ....................................................17 okabe [Page 2] Internet Draft Host Requirements of IPv6 for LCNA June 2002 12 References ..........................................................18 13 Authors' Addresses ..................................................19 1. Introduction Currently, several IPv6-capable commercial end equipments and protocol stacks, which target non-PC embedded systems, have already been announced [INODE][ACCESS]. Also, the deployment of IPv6 for various non-PC platforms is being evaluated [IPv6PC]. There may be other configurations for IPv6 embedded devices, which have different design policies, physical shapes, and restrictions for the implementation. Though current PCs usually support more than 64MB of memory area, typical embedded devices have only limited memory and CPU performance as shown in Table 1. This causes severe technical problems for implementing the entire IPv6/IPsec functionality. In the case of consumer equipment such as home appliances, the network functionality has to be realized with the lowest cost. In this document, our target is non-PC embedded appliances called Low Cost Network Appliances (LCNA) which meet the following requirements. * Devices are not for general purpose, but are targeted at specific tasks. * A device that has network functionality, but has limited resources to dedicate to that. * A device that is a host, not a router. The target of this document is to consider the usages and functions of LCNA in detail and propose which IPv6 specification is essential for meeting LCNA host requirement. There has been discussion relating to whether cellular phones are also a kind of LCNA. However, special cellular networks and richer functionality set the cellular phones apart from our target (consumer) devices. Therefore, we omit them (see [CELLULAR] for IPv6 requirement for cellular hosts). Examples of LCNAs that might be available in the near future are consumer appliances such as game-machines, AV devices, sensors, digital cameras, LCD projectors, and home appliances including refrigerators and microwave ovens. See section 2.3 for application examples of LCNAs. Considering the above, we will propose an IPv6/IPsec specification for LCNA in this document based upon the following conditions. - This requirement regulates the baseline IPv6 specification for guaranteeing that compliant LCNAs can communicate with minimum safety. That is, if it complies with this spec, it is guaranteed that it can communicate with another IPv6 device securely. - We do not assume specific usage models. We will summarize the requirements that are used on various LCNAs in common. okabe [Page 3] Internet Draft Host Requirements of IPv6 for LCNA June 2002 - There are functions that are necessary depending upon specific network topology, communication content, and usage models such as mobility. For these functions, we will evaluate how generic the function is, and if it is necessary it will be included into the requirement, and if not, we will indicate that it is an optional function for a specific usage model. Therefore, in order to adopt this requirement to various implementations, it is necessary to classify usage style, communication mode, communication contents, network mobility, and actual usage model. Then, select the optimal combination of items for each implementation. Currently, the IPv6 Node Requirement Design Team is organized in IPv6 WG for specifying generic IPv6 node requirements. This document respects the result of this design team and conforms to the nodereq specification. When there exists contradictions between nodereq document [NODEREQ] and this document, the nodereq document should take precedence and understand that the description here is dependent to the specific operation mode for LCNAs. Table 1. Resource restrictions of LCNA ===============+===============+==================+======= Memory CPU Performance OS ===============+===============+==================+======= PC >64MB Pentium/64bits Windows ---------------+---------------+------------------+------- PDA 2-8MB RISC/32bits VxWorks (< 50MHz) PalmOS Others ---------------+---------------+------------------+------- AV equipment 512KB ROM RISC/32bits uiTron[ITRON] | 20-64KB RAM (< 20MHz) Monitor | 8-16bit MPU | LCNA ---------------+---------------+------------------+------- | Sensor 512KB ROM 8-16bits MPU Monitor | 512KB RAM | ---------------+---------------+------------------+------- | Home appliance 512KB ROM 8-16bits MPU Monitor | 16-32KB RAM | ===============+===============+==================+======= 1.1 Requirement Language The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [KEYWORD]. 2. Assumption for an LCNA An LCNA MAY omit the functionality that is described as "out of scope" in this document. okabe [Page 4] Internet Draft Host Requirements of IPv6 for LCNA June 2002 2.1 Hardware configuration In this document, the hardware configuration of an LCNA is as follows: - An LCNA can provide sufficient functionality with only one network interface. If the LCNA has multiple network interfaces, it must support additional resources, see 3.3 for detail. - For Layer 2, we will assume Ethernet as typical shared media and PPP as typical point-to-point media. These are minimum interfaces ([rfc2467], [rfc2470], [rfc2497]). The media that is abstracted as Ethernet/PPP from IP layer (such as 802.11 wireless LAN and Bluetooth) are also targeted. - An LCNA can be invoked in stand-alone mode, which indicates booting via the network is not necessary (See 5.2). Several parameters of LCNAs are configured at the time of shipping. For example, hop limit in the IPv6 header, DNS server addresses or security policy database. These parameters are used until the LCNA is disposed or taken out of service. An implementor MUST evaluate whether these parameters are proper for the usage of the LCNA. There are several check points, such as the network topology where the LCNA is placed, the quantity of traffic, strength of cipher algorithm and the lifetime of the LCNA. 2.2 Functions which are Out-of-scope in this document In this section, the Out-of-scope items and their reasons are summarized. 2.2.1 Transition technology from IPv4 Transition from IPv4 is an important topic when deploying an LCNA, but we omit it in this document. Therefore, we will only consider communications over pure IPv6 networks. For the long-term perspective, the goal is to realize the interconnection with IPv4 networks, but it does not mean that the operation of an LCNA relies on the existence of translators and/or NATs. 2.2.2 Multicast Multicast is not addressed in this document, and is a candidate for further study ([rfc2375], [rfc2710]). However, multicast related to neighbor discovery has to be considered. For detailed discussion about MLD see section 3.9. 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. 2.2.4 API The Socket API and IPsec API are implementation dependent. For okabe [Page 5] Internet Draft Host Requirements of IPv6 for LCNA June 2002 example, the Socket API will be expanded in a vendor specific manner, or a Java API layer can abstract them. Therefore, these APIs are out of the scope of this document. 2.2.5 Management functions In this document, the functions for managing LCNAs via the network are out of scope. This is very important and must be listed as a future study item (See 5.3). 2.2.6 Mobility support In this document, we do not assume that an LCNA itself moves on the network as a Mobile Node of Mobile IPv6, but the processing from other Mobile Nodes is mandatory, that is, an LCNA has to operate as a Correspondent Node. Because the Mobile IPv6 is not finalized, we will not discuss the detailed specification until Mobile IPv6 is submitted as an RFC. 2.3 Examples of LCNA applications Here are several examples of LCNA usage models, especially for home network applications. 2.3.1 Video camera image displayed on TV is recorded on VCR (Figure 1) a) The user selects the video camera, starts capturing the video image, and displays it on the TV using a remote control unit. b) The TV sends a command to the video camera in order to start capturing and sending the video image. c) The video camera sends the captured image to the TV, and the TV displays the image. d) The user selects the VCR, and turns on the image from the video camera and records it using the TV remote control. e) The TV sends a command to the video camera to start sending the captured image to the VCR. f) The TV sends a command to the VCR to start recording the received image. g) The video camera sends the captured image to the VCR as content. h) The VCR records the received image from the video camera. (user operation) | V command +---------+ -----------------------> +---------+ | TV set | contents | Camera | +----+----+ <++++++++++++++++++++++ +----+----+ | | +---------+ + | | +------->| VCR |<+++++++++ | | command +----+----+ contents | | | | --------+-----------------+------------------+-------- IPv6 Home network Figure 1 (Example 1) okabe [Page 6] Internet Draft Host Requirements of IPv6 for LCNA June 2002 2.3.2 The image capturedby the home video camera is forwarded to a portable node (such as PDA and cellular phone) (Figure 2) a) The user requests the video camera in the home network to receive the captured image using a cellular phone. b) The cellular phone sends a command to the video camera to request the captured image. c) The video camera forwards the captured image to the cellular phone as content. This application also works browsing the contents of a refriegerator. (user operation) | V command +----------+ -----------------------> +---------+ | portable | | | | node | contents | Camera | +-----+----+ <++++++++++++++++++++++ +----+----+ | | (Wireless | Carrier | Network) | | | | +---------+ | (The Internet)--- + Home GW +----------------+-------- +---------+ IPv6 Home network Figure 2 (Example 2) okabe [Page 7] Internet Draft Host Requirements of IPv6 for LCNA June 2002 2.3.3 The video camera in the home network pushes the captured image to a portable node (Figure 3) a) Detecting unusual events (such as a trespasser) on the video camera on the home network. b) The video camera sends a command to the cellular phone in order to request displaying the captured image as content. c) The video camera sends the image to the cellular phone. And the cellular phone displays the image to the user. detecting an incident | command V +----------+ <---------------------- +---------+ | portable | | | | node | contents | Camera | +-----+----+ <++++++++++++++++++++++ +----+----+ | | (Wireless | Carrier | Network) | | | | +---------+ | (The Internet)--- + Home GW +----------------+-------- +---------+ IPv6 Home network Figure 3 (Example 3) 3. IPv6 requirement for LCNA In the following sections, we will explain LCNA host requirements according to each related RFC and Internet Draft. 3.1 Internet Protocol, Version 6 (IPv6) Specification [rfc2460] As for sending IPv6 extension headers, please refer to each following subsection. On the other hand, an LCNA is able to receive packets with any extension headers and handle them as specified in [rfc2460]. The detail of the extension header receiving process is as follows, - Since it is assumed that an LCNA does not need extension header functions, it MAY omit order check of extension headers. - When an LCNA receives unsupported extension headers, it MUST follow the procedure specified in [rfc2460] section 4. Detailed processing for each extension header is described in the following subsections. 3.1.1 Hop-by-Hop Options Header [Sending] An LCNA MUST be able to send Hop-by-Hop Options headers for MLD okabe [Page 8] Internet Draft Host Requirements of IPv6 for LCNA June 2002 support. [Receiving] An LCNA SHOULD recognize it as a Hop-by-Hop Options Header, and perform the processing according to the option and option number in it. If it does not recognize the option type, it have to perform as specified in [rfc2460] section 4.2. 3.1.2 Routing Header [Sending] LCNAs may not originate Routing Header. [Receiving] As [rfc2460] regulates, the processing of segment_left as zero is unconditionally mandatory. 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. 3.1.3 Fragment Header [Sending] When an LCNA can guarantee the sending packet size is less than or equal to IPv6 MINMTU, it can omit Fragment Header sending function. But in order to guarantee that emitting packet size is less than IPv6 MINMTU, the implementor has to consider an LCNA design carefully. See "Appendix: Difficulty of packet size control mechanism" for detail. [Receiving] An LCNA MUST support re-assembling of fragmented packets. For re-assembly, an LCNA implementation has to satisfy the following conditions, - An implementation MUST be able to perform re-assembly for one packet at a time. - An implementation MUST have a buffer for holding at least two fragments whose size is less than or equal to link MTU. 3.1.4 Destination Options Header [Sending] An LCNA may not originate Destination Options header. [Receiving] An LCNA SHOULD recognize this header as Destination Options Header and perform processing according to the options and option numbers contained in it. If it does not recognize the option type, it has to perform as specified in [rfc2460] section 4.2. 3.1.5 No Next Header This header is only interpreted and requires no action. 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, it can omit this okabe [Page 9] Internet Draft Host Requirements of IPv6 for LCNA June 2002 function. 3.3 Neighbor Discovery for IP Version 6 (IPv6) [rfc2461] Because of the LCNA definition, the following functions for routers can be omitted. - Sending router advertise messages - Receiving router solicitation messages - Sending redirect messages Receiving Redirect messages is a host function but the implementation MAY omit it. If it is omitted, an implementation of the destination cache can be also omitted. Otherwise, the destination cache entry must work with the Neighbor Unreachability Detection (NUD) carefully. If there is an entry in the destination cache that was created by the Redirect message, and if the neighbor where packets are redirected becomes unreachable by NUD, then the entry in the destination cache must be removed. 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 3.4 IPv6 Stateless Address Autoconfiguration [rfc2462] Duplicated address detection (DAD) uses the neighbor discovery function. Neighbor discovery is mandatory in IPv6. Therefore, DAD implementation has almost no impact on resource usage, so all functions of DAD SHOULD be implemented. [rfc2462] does not mention anything about PPP, but everything SHOULD be implemented. Because DAD is heavily dependent on neighbor discovery and neighbor discovery is mandatory for the PPP case. 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. okabe [Page 10] Internet Draft Host Requirements of IPv6 for LCNA June 2002 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 ---------------+-------------------------------+---------- 2: 0: Packet too big No Packet Too Big Message ---------------+-------------------------------+---------- 3: 0: Hop limit exceeded No Time 1: Fragment reassembly No Exceeded time exceeded Message ---------------+-------------------------------+---------- 4: 0: Erroneous header field Yes Parameter 1: Unrecognized next header Yes Problem 2: Unrecognized IPv6 option Yes Message ---------------+-------------------------------+---------- 128: 0: Echo request Yes Echo Request Message ---------------+-------------------------------+---------- 129: 0: Echo reply Yes Echo Reply Message ===============+===============================+========== 3.6 IP Version 6 Addressing Architecture [rfc2373] By default, LCNAs MUST have the following three addresses. - Loopback (::1) - Node-local all nodes multicast (ff01::1) - Link-local all nodes multicast (ff02::1) If address autoconfiguration is performed, the following addresses MUST be supported. - Link-local unicast (fe80/64 host ID) - Solicited-node multicast corresponding to the above - Unicast (prefix/64 host ID) corresponding to the prefix option okabe [Page 11] Internet Draft Host Requirements of IPv6 for LCNA June 2002 of router advertise messages - Solicited-node multicast corresponding to the above If manual configuration is performed, the following addresses MUST be supported. - Arbitrary unicast - Solicited-node multicast corresponding to the above 3.7 Scope handling Even if an LCNA has only one physical interface, it may have multiple logical interfaces, such as loopback. Therefore, it MUST treat scope handling as specified in [rfc2373]. More strict discussion is shown in [SARCH] 3.8 Default Address Selection for IPv6 [ASEL] An LCNA MUST support Default Address Selection for IPv6 [ASEL]. Considering the assumption of an LCNA, it can be simplified as follows: - Section 3 of [ASEL] mentions the check for receiving ICMP REDIRECT messages. As mentioned in section 3.3 of this document, when ICMP REDIRECT message receive processing is omitted, the checking process can also be omitted. - The LCNA SHOULD satisfy RULE 1 to 3 concerning the source address selection rules described in section 4 of [ASEL]. RULE 4 is not necessary when the LCNA itself does not have mobility. RULE 5 is not necessary when the LCNA has only one interface. RULE 6 is not necessary when the LCNA does not implement policy tables. RULE 7 is not mandatory because the LCNA does not mandate [rfc3041]. RULE 8 is not mandatory because it is not mandatory in [ASEL]. - The LCNA SHOULD satisfy RULE 1, 2, 3 and 8 concerning the destination address selection rules described in section 5 of [ASEL]. RULE 4 is not necessary when the LCNA has no mobility. RULE 5 and 6 are not necessary because the LCNA does not implement policy tables. RULE 7 is not necessary when the LCNA implements IPv6 native transport only. RULE 9 and 10 are not mandatory because it is not mandatory in [ASEL]. 3.9 Multicast Listener Discovery (MLD) for IPv6 [rfc2710] Multicast Listener Discovery [rfc2710] is Conditionally Mandatory, where the condition is if the LCNA joins any multicast groups other than the all-nodes-on-link group (which will always be the case if it runs ND or DAD on the link). 4. IPsec for LCNAs We need strong security as [WHYENC] mentions. This principle must work for IPv6. IPv6 relys on IPsec architecture [rfc2401] for its security. The architecture is designed to be suitable for any environments and to be scalable. Thus in some cases, the architecture is too much for a LCNA considering the limitations described the section 2 of this document. The goal of this section is to define IPsec specification for LCNAs. All of what this section describes is a subset of the full okabe [Page 12] Internet Draft Host Requirements of IPv6 for LCNA June 2002 IPsec specification. Specifications which are not explicitly described in this section must be referred to the appropriate IPsec document. IP Security Document Roadmap [rfc2411] is helpful for an implementor who is unfamiliar with IPsec. Some specifications of IPsec architecture are being reviewed at IPsec WG. For example, ESPv3 and revised IPsec architecture. Implementors must follow the activity of IPsec WG. 4.1 IPsec specification for LCNA LCNAs MUST implement IPsec transport mode. IPsec tunnel mode MAY be implemented because LCNAs are always hosts and this document does not assume the communication to a node in corporate network via security gateway. Both IPsec MIB and ICMPv6 related to IPsec are out of scope because they are not yet standardized. Some of parameters of Security Association, defined by [rfc2401] MAY be omitted at an implementor's descretion. For example, if any automated key management is not implemented, the parameters for key lifetime MAY be omitted. An implementor MUST consider IPv6 scope as described [SARCH]. 4.1.1 Security Policy Database The security policy database MUST be implemented. At a minimum, the IP address MUST be used as the selector. Other selectors MAY be implemented. 4.1.2 Security Protocols IP Encapsulating Security Payload (ESP) [rfc2406] MUST be implemented. The padding contents are monotonically increasing sequence when the transform does not define its contents. Variable length padding is implementation dependent. Implementers must be aware of the new version of ESP [ESPv3]. IP Authentication Header (AH) [rfc2402] MUST be implemented. Implementations MUST be able to apply either ESP or AH, or both of them to a packet. If AH is combined with ESP, the order MUST be the case 1-3 of the section 4.5 of [rfc2401]. 4.1.3 Transforms and Algorithms For the encryption algorithm, AES-CBC MUST be implemented. The details are being finalized in the IPsec WG. DES-CBC [rfc2405] and 3DES-CBC [rfc2451] MAY be implemented for backward compatibility. NULL Encryption Algorithm [rfc2410] MAY be implemented for debugging purposes, or for using only integrity of the upper layer payload. These three algorithms are not recommended. For the authentication algorithm, HMAC-SHA-1-96 [rfc2404] MUST be implemented. HMAC-MD5-1-96 [rfc2403] MAY be implemented for backward compatibility. 4.1.4 SA and Key Management Manual key management techniques MUST be implemented. okabe [Page 13] Internet Draft Host Requirements of IPv6 for LCNA June 2002 [rfc3041] proposes the enhancement of privacy by randomizing the interface-ID part of the IPv6 addresses. If this facility is necessary, refreshing SA parameter frequently with the manual techniques is very difficult. An implementor needs to consider alternatives such as automated key management. In this case, the automated key management must use own identifier that is not depended on the IP address. If an implementor requires any automated key management. IKE[rfc2409] MAY be implemented. As of June 2002, new version of IKE is being discussed in IPsec WG. Implementors must be aware of the new work. IESG claims that other key exchange protocol (than IKE) might be possible. Key Distribution Center (KDC) model might be applicable for them. [SCFG] and [STAJANO] might give us hints. 4.2 Further study for LCNA security We need to have further study for security applicable to LCNA. Here are some viewpoints: - Surveying performance and footprint of LCNA systems: CPU performance and memory footprint have impact against LCNA security features because LCNAs have limited resources. However, those factors may be changed by silicon technology and popularization. Regularly surveying these factors should be performed. You can see our current survey at the following URL. http://www.tahi.org/lcna/ - Estimating various encryption methods and security mechanisms: It must be carefully considered whether existing security mechanisms and/or encryption can be implemented on the given resources of LCNAs. Hardware suitability is also important for LCNA security. - Network models of LCNA: Due to IPv6's nature, LCNAs can easily have multiple addresses. At the same time, LCNAs can be put into multi-home networks. How will these factors influence the networks where LCNAs exist? What should the networks be for LCNAs, especially in a home? - Configuring Security parameters: It is very important to configure security parameters. However, current automatic key exchange algorithms seem to be too heavy for LCNA. Manual key exchange is not the correct solution because of inconvenience. [SCFG] and [STAJANO] might give us hints. 5. Miscellaneous items 5.1 DNS Extensions to support IP version 6 [rfc1886] and IPv6 Stateless DNS Discovery [DDIS] okabe [Page 14] Internet Draft Host Requirements of IPv6 for LCNA June 2002 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 passive node). 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. 5.2 Network-boot devices The function for booting from the network with tftp (or else?) is out of scope on this document. This boot code works in a very limited ROM area, and might need a specially limited configuration. Generally such devices are designed for a special purpose and might need another implementation guidelines. 5.3 Management facilities for LCNAs When LCNAs are commonly used, there likely will be many LCNAs on a home network. In such cases, the following management facilities will be usable. - SNMP([rfc2452], [rfc2454], [rfc2465], [rfc2466]) - ICMP name lookup [NIQ] - Vendor-specific management functions (such as Web-based tools) In order to define the management functions suitable for LCNAs, we have to define and analyze the requirements for LCNA management first. Not only the individual method, but the unified maintenance scheme for handling many nodes is expected. On the remote maintenance application as shown in section 2.3, the definition of abstract LCNA functions (for example, MIB definitions) is necessary as well as each management method. 6. Security Consideration There are various security threats to LCNA. For example, - Threats related to human life, property, social infrastructure. If these items face the threat, it "directly" affects human lives, property and social lifelines. - Threats related to the privacy of users If these items face the threat, it "directly" affects human privacy. * Electronic commerce historical data * WEB access history It deeply depends on the functionality, application areas and data handling of LCNAs to determine how serious and likely each attack may be. In order to protect a LCNA from all of security threats, an okabe [Page 15] Internet Draft Host Requirements of IPv6 for LCNA June 2002 implementor has to consider other security mechanisms in addition to IPsec. There are various security mechanisms contained in each communication layer, such as SSL, SSH, etc. An implementor MUST be aware that one security mechanism cannot fulfill the whole security requirements of LCNAs. It is determined by the tradeoff of the objective, target usage, cost, and security threats of the LCNA if multiple security mechanisms, i.e. IPsec, etc., SHOULD be implemented. How to guard from breaking into a LCNA is dependent on the system configuration and cost restrictions. If it is necessary for the LCNA itself to guard itself, the minimum method is to set up IPsec SPD as strict as possible, dropping the packets from unexpected source addresses. If more security is required it may be application dependent. Complete protection from Denial of Service (DoS) Attack is out of scope, although limited protection is provided by IPsec. The authentication of users who use LCNA is also out of scope because some LCNAs can omit mechanisms of user accounts. The interaction with the intrusion detection system is out of scope. 7. Contact information Please contact tiny@tahi.org for questions/comments pertaining to this document. 8. Updates from Version-01 - The term "Minimum Host" is replaced by "LCNA' - Section 2.2 through 2.8 in draft-01 is aggregated to section 2.2 "Functions which are Out-of-scope in this document" - 2.7 Security in draft-01 is now included in Chapter 4. - "2.3 Example if LCNA applications" is appended. - "3.7 DNS Extensions to support IP version 6 and IPv6 Stateless DNS Discovery" is moved to section 5.1. - "3.7 Scope handling" is appended. - "3.9 Multicast Listener Discovery (MLD) for IPv6" is appended. - Section 4 is now modified to IPsec focused description. Non-IPsec description is gathered to 4.2. - "5 Mobility support" in draft-01 is deleted. - "6 Open Issues" in draft-01 is renamed to "5 Miscellaneous items" and DNS related description is included there. - Contents of Appendix is changed to packet size control. - Number of Authors is reduced, instead, "10 Contributors list" is appended. - The notation of Reference is modified. - There are other changes of expression, editorial corrections. 9 Appendix: Difficulty of packet size control mechanism You can only guarantee the size of incoming/outgoing packet if an LCNA is designed for an specific purpose and is also operated under an specific environment. okabe [Page 16] Internet Draft Host Requirements of IPv6 for LCNA June 2002 For TCP, by limiting the max segment size (MSS) advertised by itself to a specific value, the size of incoming IP packet from the correspondent can be limited. Also by replacing the MSS advertised by the correspondent to a specific value, the size of outgoing IP packet to the correspondent can be limited. Therefore, the LCNA can limits the size of transmitting TCP packets for both directions. For UDP, there is no size control mechanism like TCP. Application layer decides UDP packet size. If an LCNA need to control UDP packet size, you must tune applications on the LCNA for this purpose. 10 Contributors List The work for this document was directed by non-PC Network Appliance Committee, organized in Interoperability Technology Association for Information Processing, Japan (INTAP). All the members and their affiliations are as follows: Nobuo Okabe Yokogawa Electric Corporation Shoichi Sakane Yokogawa Electric Corporation Hiroshi Miyata Yokogawa Electric Corporation Jirou Sajiki Yokogawa Electric Corporation Nobumichi Ozoe Yokogawa Electric Corporation Yukiyo Akisada Yokogawa Electric Corporation Masahito Endo Yokogawa Electric Corporation Atsushi Inoue Toshiba Corporation Masahiro Ishiyama Toshiba Corporation Seijirou Yoneyama Toshiba Corporation Masayuki Osajima ACCESS CO., LTD. Yasuharu Yamada ACCESS CO., LTD. Yuko Izuhara ACCESS CO., LTD. Kay Noguchi IP Infusion Inc. Hiroshi Esaki The Univ. of Tokyo Hideki Kamimaki Hitachi, Ltd. Mika Mizutani Hitachi, Ltd. Sunao Sawada Hitachi, Ltd. Atsushi Nakamura Matsushita Electric Industrial Co., Ltd. Fumiaki Suzuki Matsushita Electric Industrial Co., Ltd. Takumi Segawa Matsushita Graphic Communication Systems,Inc. Tadamichi Matsuyama SOUM Corporation Kiyoshi Inoue SOUM Corporation Kazutoshi Fujita SOUM Corporation Nobutake Ishii Seiko EPSON Corporation Matsuhisa Hosokawa Seiko EPSON Corporation Tsukasa Ogino IPv6 Promotion Council of Japan Noriaki Fujiwara Matsushita Electric Works, Ltd. Tomoki Takazoe Matsushita Electric Works, Ltd. Akifumi Kanbara INTAP Tomihiko Kojima INTAP 11 Acknowledgements The authors would like to thank to useful discussions and comments on IPv6 WG mailing list, especially Pekka Savola. Clayton Ware of Maxim/Dallas Semiconductor checked all the versions of this okabe [Page 17] Internet Draft Host Requirements of IPv6 for LCNA June 2002 document and gave us useful suggestion for the contents and expressions. The authors also would like to thank all of the collaboration with IPv6 Promotion Council of Japan, and its Tele-Control sub Working Group. The support of Information-Technology Promotion Agency, Japan and Ministry of Economy, Trade and Industry are gratefully acknowledged. 12 References [rfc1886] DNS Extensions to support IP version 6 (RFC 1886) [rfc1981] Path MTU Discovery for IP version 6 (RFC 1981) [rfc2373] IP Version 6 Addressing Architecture (RFC 2373) [rfc2375] IPv6 Multicast Address Assignments (RFC2375) [rfc2401] Security Architecture for the Internet Protocol (RFC2401) [rfc2402] IP Authentication Header (RFC2402) [rfc2403] The Use of HMAC-MD5-96 within ESP and AH (RFC2403) [rfc2404] The Use of HMAC-SHA-1-96 within ESP and AH (RFC2404) [rfc2405] The ESP DES-CBC Cipher Algorithm With Explicit IV (RFC2405) [rfc2406] IP Encapsulating Security Payload (RFC2406) [rfc2409] The Internet Key Exchange (RFC2409) [rfc2410] The NULL Encryption Algorithm and Its Use With IPsec (RFC2410) [rfc2411] IP Security Document Roadmap (RFC2411) [rfc2451] The ESP CBC-Mode Cipher Algorithms (RFC2451) [rfc2452] IP Version 6 Management Information Base for the Transmission Control Protocol (RFC2452) [rfc2454] IP Version 6 Management Information Base for the User Datagram Protocol (RFC2454) [rfc2460] Internet Protocol, Version 6 (IPv6) Specification (RFC 2460) [rfc2461] Neighbor Discovery for IP Version 6 (IPv6) (RFC 2461) [rfc2462] IPv6 Stateless Address Autoconfiguration (RFC 2462) [rfc2463] Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification (RFC 2463) [rfc2465] Management Information Base for IP Version 6: Textual Conventions and General Group (RFC2465) [rfc2466] Management Information Base for IP Version 6: ICMPv6 Group (RFC2466) [rfc2467] Transmission of IPv6 Packets over FDDI Networks (RFC2467) [rfc2470] Transmission of IPv6 Packets over Token Ring Networks (RFC2470) [rfc2497] Transmission of IPv6 Packets over ARCnet Networks (RFC2497) [rfc2526] Reserved IPv6 Subnet Anycast Addresses (RFC2526) [rfc2710] Multicast Listener Discovery (MLD) for IPv6 (RFC2710) [rfc3041] Privacy Extensions for Stateless Address Autoconfiguration in IPv6 (RFC3041) [INODE] InternetNode Inc. http://www.i-node.co.jp/ [ACCESS] ACCESS CO., LTD. http://www.access.co.jp/ [IPv6PC] IPv6 Promotion Council, Application Working Group, http://www.v6pc.jp/apwg.html [ITRON] http://www.itron.gr.jp/home-e.html [STAJANO] Frank Stajano, Ross Anderson "The Resurrecting Duckling: Security Issues for Ad-hoc Wireless Networks" http://www-lce.eng.cam.ac.uk/~fms27/duckling/ okabe [Page 18] Internet Draft Host Requirements of IPv6 for LCNA June 2002 [CELLULAR] IPv6 for Some Second and Third Generation Cellular Hosts (draft-ietf-ipv6-cellular-host-03.txt) [NIQ] IPv6 Node Information Queries (draft-ietf-ipngwg-icmp-name-lookups-09.txt) [DDIS] IPv6 Stateless DNS Discovery (draft-ietf-ipngwg-dns-discovery-05.txt) [AES] The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec (draft-ietf-ipsec-ciph-aes-cbc-04.txt) [KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [ASEL] Default Address Selection for IPv6 (draft-ietf-ipngwg-default-addr-select-07.txt) [SCFG] Configuring Security Parameters in Small Devices (draft-hanna-zeroconf-seccfg-00.txt) [NODEREQ] IPv6 Node requirements (draft-ietf-ipv6-nodereq-00.txt) [WHYENC] Encryption and Security Requirements for IETF Standard Protocols (draft-ietf-saag-whyenc-00.txt) [SARCH] IPv6 Scoped Address Architecture (draft-ietf-ipngwg-scoping-arch-04.txt) [ESPv3] IP Encapsulating Security Payload (ESP) draft-ietf-ipsec-esp-v3-02.txt 13 Authors' Addresses Nobuo Okabe Yokogawa Electric Corporation IT Product Division 2-9-32 Nakacho, Musashino-shi, Tokyo, 180-8750 Japan Phone: 81-422-52-5298 Fax: 81-422-52-6426 E-Mail: nov@tahi.org Shoichi Sakane Yokogawa Electric Corporation IT Product Division 2-9-32 Nakacho, Musashino-shi, Tokyo, 180-8750 Japan Phone: +81-422-52-6413 Fax: +81-422-52-6426 E-mail: shouichi.sakane@jp.yokogawa.com Atsushi Inoue Toshiba Corp. R&D Center 1 Komukai-Toshiba-cho, Saiwai-ku, Kawasaki 212-8582 JAPAN Phone: 81-44-549-2065 Fax: 81-44-520-1806 E-mail: inoue@isl.rdc.toshiba.co.jp Masahiro Ishiyama Toshiba Corp. R&D Center 1 Komukai-Toshiba-cho, Saiwai-ku, Kawasaki okabe [Page 19] Internet Draft Host Requirements of IPv6 for LCNA June 2002 212-8582 JAPAN Phone: +81-44-549-2238 Fax: +81-44-520-1806 E-mail: masahiro@isl.rdc.toshiba.co.jp Hiroshi Esaki The University of Tokyo 7-3-1, Hongo, Bunkyo-ku, Tokyo, 113-8656, Japan Phone: +81-3-5841-7465 Fax: +81-3-5841-6702 E-mail: hiroshi@wide.ad.jp okabe [Page 20]