Network Working Group K. Shima Internet-Draft IIJ Expires: April 24, 2006 October 21, 2005 IPv4 Mobile Host/Network support for NEMO Basic Support Protocol draft-shima-nemo-v4prefix-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on April 24, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo describes the IPv4 Mobile Network Prefix Option which carries IPv4 network prefix information behind a NEMO router. This option makes it possible to support IPv4 mobile networks over the IPv6 network infrastructure. Shima Expires April 24, 2006 [Page 1] Internet-Draft v4prefix option October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Sample scenarios . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. A train company . . . . . . . . . . . . . . . . . . . . . 4 2.2. Site multihoming . . . . . . . . . . . . . . . . . . . . . 5 3. Overview of the approach . . . . . . . . . . . . . . . . . . . 8 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Option format . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. IPv4 Mobile Network Prefix Option . . . . . . . . . . . . 10 5.2. IPv4 Mobile Network Prefix Registration Status Option . . 11 6. Mobile Router operation . . . . . . . . . . . . . . . . . . . 13 7. Mobile Host operation . . . . . . . . . . . . . . . . . . . . 15 8. Home Agent operation . . . . . . . . . . . . . . . . . . . . . 16 9. Choosing a home agent . . . . . . . . . . . . . . . . . . . . 17 10. Relationship with v4traversal . . . . . . . . . . . . . . . . 18 11. Relationship with NAT . . . . . . . . . . . . . . . . . . . . 19 12. Security Considerations . . . . . . . . . . . . . . . . . . . 20 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 14. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 14.1. An unnumbered tunnel for IPv4 . . . . . . . . . . . . . . 22 15. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . . . . 25 Shima Expires April 24, 2006 [Page 2] Internet-Draft v4prefix option October 2005 1. Introduction NEMO (RFC3963) [1] specifies the mechanism to provide mobility functions to IPv6 networks. All IPv6 networks behind a NEMO capable router can move around all over the Internet with the NEMO router, without breaking existing connections between nodes inside the moving network and nodes of the Internet. The NEMO specification mentions only IPv6 networks. In this document, we propose an extension which adds the IPv4 network support to the NEMO specification. With the option we introduce in this document, we can operate IPv4 mobile networks over the IPv6 network infrastructure. Considering the situation that we need to live with both IPv4 and IPv6 networks during the transition period before we have completely shifted to IPv6, many IPv4 devices/networks will be used for a long time. NEMO provides a simple mechanism to enable IPv6 networks move around the Internet. The technology is expected to be used for various scenes, such as implementing car/train networks, a personal area networks, or even providing redundancy to networks of an entire site of an organization(draft-nagami-mip6-nemo-multihome-fixed-network [2]). Supporting only IPv6 devices and dropping IPv4 devices are not good idea especially in the forthcoming long transition period. However defining a new mobile network protocol for IPv4 is not expected, since IPv4 is going to disappear finally. This document defines a mechanism to provide IPv4 mobile network using IPv6 connections. We can use with both protocols with this proposed technology and we also can move to IPv6 only network seamlessly when the IPv4 network completes its role. Shima Expires April 24, 2006 [Page 3] Internet-Draft v4prefix option October 2005 2. Sample scenarios 2.1. A train company Assuming that a train company wants to provide IP connectivity to their passengers. Considering the current Internet situation, they cannot ignore IPv4 networks, but at the same time, they need to support IPv6 for the future. In such a case, the company need to assign both IPv4 and IPv6 networks in each train. The network can be designed as Figure 1. +------------------------------+ | Company network (dual stack) | +---------------+ | +----+ IPv4 Internet | | +------------+ | +---------------+ | | Home Agent | | | +------------+ | +--------------+---------------+ | | +--------------------+--------------------+ | IPv6 Internet | +---+----------------+-----------------+--+ / | \ Train1 / Train2| \ Train3 +-----+--+ +---+----+ +--+-----+ | Mobile | | Mobile | | Mobile | | Router | | Router | | Router | +-+----+-+ +-+----+-+ +-+----+-+ | | | | | | +-+-+ | +-+-+ | +-+-+ | |NAT| | |NAT| | |NAT| | +-+-+ | +-+-+ | +-+-+ | | | | | | | ----+----+---- ----+----+---- ----+----+---- 2001:2DB:1000:1::/64 2001:2DB:1000:2::/64 2001:2DB:1000:3::/64 192.168.1.0/24 192.168.2.0/24 192.168.3.0/24 Figure 1: A sample network for a train company Each train has one IPv6 network and one IPv4 private network for the Internet service to the passengers. Each mobile router in a train works as an IPv6 NEMO router as specified in the NEMO specification. At the same time, each train has a NAT box to translate the internal private addresses to a global address. A mobile router also register the global address using the mechanism described in this document. A home agent located in the train company will create IPv6 tunnel to every mobile routers and forwards all IPv6 traffic from/to the mobile Shima Expires April 24, 2006 [Page 4] Internet-Draft v4prefix option October 2005 routers and also forwards all IPv4 traffic from/to each global address assigned to each train network using the tunnel connections, which tunnels are created by the basic NEMO mechanism. In the above example, a separate NAT box is located to each train, however, the function can be integrated to each mobile router depending on the implementation. 2.2. Site multihoming There is a proposal to provide a site multihoming mechanism using the NEMO technology ([2]). Considering the current Internet situation, we cannot ignore IPv4 connectivity when providing an Internet connection to customers. In this case, the following network design can be applied. Shima Expires April 24, 2006 [Page 5] Internet-Draft v4prefix option October 2005 +---------------------------------+ | Mobile Network Service Provider | | | +---------------+ | +--+ IPv4 Internet | | +------------+ | +---------------+ | | Home Agent | | | +------------+ | +------------+--------------------+ | | +-------+-------+ | IPv6 Internet | ISP/Internet +-+-----+-----+-+ --------------- | | | -------------------------------- Company | | | +---+-----+-----+---+ 2001:2DB:1::/48 | Mobile Router | 202.210.1.0/28 +--+--------+-----+-+ 202.200.1.0/28 | | | | | | ----------+--+- | ---+---+------- 202.200.1.0/28 202.210.1.0/28 | | | 2001:2DB:1:1000::/64 2001:2DB:1:2000::/64 | | | +-+-+ | +---+---+ |NAT| | |servers|+ +-+-+ | +-------+| | | +-------+ | | +========+=====+===============+ | Company internal network | | 192.168.0.0/24 | | 2001:2DB:1:3000::/52 | +==============================+ Figure 2: A sample network for a multihomed site In the above example, a company network has three network prefixes for its site. 2001:2DB:1::/48 for IPv6 and 202.210.1.0/28 and 202.200.1.0/28 for IPv4 networks. The internal network, which usually used for the intranet is NATed. The mobile router placed at the boundary between the Internet and the company network will register those three network prefixes using existing NEMO signaling messages for the IPv6 prefix and the extension described in this document for IPv4 prefixes. All IPv4 traffic which source or destination address is in the range of 202.210.1.0/28 or 202.200.1.0/28 is tunneled between the mobile router and the home agent located in a Mobile Network Service Shima Expires April 24, 2006 [Page 6] Internet-Draft v4prefix option October 2005 Provider using an IPv6 tunnel, which tunnel is created by the basic NEMO mechanism. The example also implies that the mobile router located at the boundary of the company network has multiple IPv6 connectivities to increase redundancy. If we use the multiple care-of addresses registration mechanism as described in [2] and [3], we can also provide a simple NEMO based multihome network, with both IPv6 and IPv4 support. Shima Expires April 24, 2006 [Page 7] Internet-Draft v4prefix option October 2005 3. Overview of the approach It is one way to define a new protocol which supports IPv4 network mobility functions. However, assuming that the Internet shifts from IPv4 to IPv6, it is not a good idea to invent a new protocol for the old IP protocol. We take the following approaches. o Do not define any IPv4 extension protocol, since we will not have IPv4 in the future. o Do not break existing NEMO specification. The basic mechanism of the NEMO specification is a simple signal processing to maintain the location of mobile routers and exchange of moving network information. All traffic from/to the moving networks are tunneled between the mobile router and its home agent. The mechanism is independent of the protocol version transmitted in the tunnel. It is possible to use the tunnel to transmit IPv4 packets, to the condition that we can exchange the IPv4 routing information of the moving network. For example, using a dynamic routing protocol between a home agent and a mobile router makes it possible. We define a new option which provides the way to exchange such information in NEMO signaling messages. Such an option is useful when we are using the explicit mode operation to provide network mobility, since otherwise we cannot know the prefix information behind a mobile router. Shima Expires April 24, 2006 [Page 8] Internet-Draft v4prefix option October 2005 4. Terminology o mobile node An IPv6 host or router which has a Mobile IPv6 or a NEMO function respectively. o mobile host An IPv6 host which has a Mobile IPv6 function. o mobile router An IPv6 router which has a NEMO function. A mobile router is usually able to act as a mobile host. o IPv4 Mobile Network Prefix An IPv4 network prefix which is assigned to the network attached to the ingress interface of a mobile router. o IPv4 Mobile Address An IPv4 address which identify a mobile host. A mobile router also can have an IPv4 Mobile Address, if it needs an IPv4 Mobile Address. A mobile router usually has an IPv4 address on its ingress interface, if it has a IPv4 mobile network. In that case, the IPv4 Mobile Address is the IPv4 address assigned to the ingress interface of the mobile router. A mobile router may need another IPv4 Mobile Address which is not one of the IPv4 address of the mobile network. Shima Expires April 24, 2006 [Page 9] Internet-Draft v4prefix option October 2005 5. Option format 5.1. IPv4 Mobile Network Prefix Option The IPv4 Mobile Network Prefix Option is carried in a Binding Update message, indicating the IPv4 network prefix behind a mobile router. The option may appear multiple times to exchange multiple subnetwork information operated in a single mobile network. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Mobile Network Prefix | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 8 (TBD) Length 8-bit unsigned integer indicating the length of the option in a unit of a octet. The field is always set to 6. I flag The I flag indicates the specified address in the IPv4 Mobile Network Prefix field is used as an IPv4 node identifier. Reserved This field is reserved for future use. A sender MUST clear this field before sending, and a receiver MUST ignore this field. Prefix Length 8-bit unsigned integer indicating the prefix length of the IPv4 Mobile Network Prefix. The value must be a valid prefix length for IPv4 networks. A non-contiguous subnet mask is not supported. Shima Expires April 24, 2006 [Page 10] Internet-Draft v4prefix option October 2005 IPv4 Mobile Network Prefix 4 octets field indicating the IPv4 network prefix of a network behind a mobile router. If the value of the Prefix Length field is 32, the IPv4 Mobile Network Prefix field contains an IPv4 Mobile Address. A home agent may be required some special processing, if an IPv4 Mobile Address is passed. 5.2. IPv4 Mobile Network Prefix Registration Status Option The IPv4 Mobile Network Prefix Registration Status Option is carried in a Binding Acknowledgment message, indicating that the IPv4 Mobile Network Prefix Option has been recognized. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 9 (TBD) Length 8-bit unsigned integer indicating the length of the option in a unit of a octet. The field is always set to 2. Reserved This field is reserved for future use. A sender MUST clear this field before sending, and a receiver MUST ignore this field. Status 8-bit unsigned integer indicating the status of IPv4 mobile network prefix registration status. 0 Success 140 IPv4 prefix registration not permitted Shima Expires April 24, 2006 [Page 11] Internet-Draft v4prefix option October 2005 141 Invalid prefix 142 Not authorized for the prefix 143 IPv4 node identifier registration not permitted 144 Forwarding setup failed Shima Expires April 24, 2006 [Page 12] Internet-Draft v4prefix option October 2005 6. Mobile Router operation A mobile router which has IPv4 networks on its ingress interface can include the IPv4 Mobile Network Prefix option in a Binding Update message to its home agent. After receiving a successful acknowledgment from the home agent, the mobile router adds a route entry which indicates that all traffic from the IPv4 networks is forwarded to the tunnel interface created between the mobile router and its home agent. A mobile router will receive a Binding Acknowledgment message with the IPv4 Mobile Prefix Registration Status Option when a home agent supports this extension. If the Binding Acknowledgment does not include the option, the IPv4 prefix registration cannot be used. After successful registration of IPv4 network prefixes, a mobile router forwards all IPv4 packets which source address is in the range of the registered IPv4 prefix to its home agent using an IPv6 tunnel created between the mobile router and its home agent, when those IPv4 packets are received from the ingress interface of the mobile router. On the other hand, when the mobile router receives IPv4 packets from the tunnel and the destination address of the internal packet is in the range of the registered IPv4 prefix, the mobile router forwards those IPv4 packets to its ingress interface. Figure 3 shows the packet format. Shima Expires April 24, 2006 [Page 13] Internet-Draft v4prefix option October 2005 From a mobile router to a home agent +--------------+ Source: The care-of address of the mobile router | IPv6 header | Dest: The home agent address | | +--------------+ Source: One of IPv4 address registered to the | IPv4 header | home agent | | Dest: An arbitrary IPv4 address in the IPv4 +--------------+ Internet | IPv4 payload | +--------------+ From a home agent to a mobile router +--------------+ Source: The home agent address | IPv6 header | Dest: The care-of address of the mobile router | | +--------------+ Source: An arbitrary IPv4 address in the IPv4 | IPv4 header | Internet | | Dest: One of IPv4 address registered to the +--------------+ home agent | IPv4 payload | +--------------+ Figure 3: Packet format Shima Expires April 24, 2006 [Page 14] Internet-Draft v4prefix option October 2005 7. Mobile Host operation A mobile host can have a fixed IPv4 address, which never change during handover. We call the address as an IPv4 Mobile Address. A mobile host specifies its IPv4 Mobile Address in a Binding Update message. When specifying an IPv4 Mobile Address, a mobile host need to set the Prefix Length field to 32 and put the IPv4 Mobile Address in the IPv4 Mobile Network Prefix field of the IPv4 Mobile Network Prefix Option. A mobile host will receive a Binding Acknowledgment message with the IPv4 Mobile Prefix Registration Status Option when a home agent supports this extension. If the Binding Acknowledgment does not include the option, the IPv4 node identifier registration cannot be used. After successful registration of an IPv4 Mobile Address, the IPv4 node identifier can be used as a source address of IPv4 packets generated at the mobile host. Such packets are forwarded to the home agent of the mobile node using an IPv6 tunnel interface created between those two nodes. If a mobile host receives IPv4 packets which destination address is same with the IPv4 node identifier of the mobile host from the IPv6 tunnel interface, the host accepts the packets as its own packets. Shima Expires April 24, 2006 [Page 15] Internet-Draft v4prefix option October 2005 8. Home Agent operation A home agent which supports the IPv4 Mobile Network Prefix Option will add a route entry for the IPv4 network prefix when it receives a Binding Update message with the option. A Binding Acknowledgment message sent from the home agent must include the IPv4 Mobile Prefix Registration Status Option to indicate the processing status of the received IPv4 Mobile Prefix Option. When a home agent accept the IPv4 Mobile Network Prefix Option, the status field of the IPv4 Mobile Network Registration Status Option must be set to 0 indicating success. Otherwise, the status code must be filled with an error code as described in section Section 5.2. After successful registration of IPv4 prefixes, a home agent start forwarding IPv4 packets which destination address is in the range of registered IPv4 prefix to the tunnel to the mobile router which registered the corresponding IPv4 prefix. At the same time, the home agent also start accepting IPv4 packets sent from the tunnel which source address is in the range of the registered IPv4 prefix and start forwarding to the IPv4 internet. If the Prefix Length field in the incoming IPv4 Mobile Network Prefix Option is equal to 32, a home agent treats the value in the IPv4 Mobile Network Prefix field as an IPv4 Mobile Address. The address must be one of addresses of the IPv4 network that the home agent is attached to. If the validation succeeds, a home agent starts proxying the IPv4 node identifier included in the option (after checking there is no other nodes which is using the IPv4 address). A home agent will intercept all IPv4 packets delivered to the home network if the destination address of the packets is equal to the IPv4 Mobile Address. These intercepted packets will be forwarded to the mobile host using an IPv6 tunnel created between the home agent and the mobile host. If a home agent receives IPv4 packets which source address is the IPv4 Mobile Address from the IPv6 tunnel interface, a home agent will forward the packets to the IPv4 Internet. Figure 3 shows the packet format. Shima Expires April 24, 2006 [Page 16] Internet-Draft v4prefix option October 2005 9. Choosing a home agent A mobile router need to know which home agent supports the option discussed in this document. One possible way to do it is to define a special bit in a Dynamic Home Agent Address Discovery message to indicate that a home agent supports this option. This mechanism requires to modify all home agent to understand the bit even if the home agents does not support the IPv4 prefix option. Another way is to try to register with the option and see what happen. If the home agent to which a mobile router sent a registration message supports the IPv4 Network Prefix Option, it will reply with the IPv4 Network Prefix Registration Status Option. Otherwise, the status option will not be included. If the home agent which the mobile router has tried to register does not support the option, the mobile router can deregister from the home agent and try another home agent. Shima Expires April 24, 2006 [Page 17] Internet-Draft v4prefix option October 2005 10. Relationship with v4traversal This document describes the mechanism to support IPv4 networks located behind a mobile router over the IPv6 network infrastructure. The signaling messages and a tunnel connection between a mobile router and a home agent uses IPv6. The v4traversal mechanism provides the way to use IPv4 as a protocol for signaling messages and tunnel connections. Using the v4traversal mechanism will provide IPv6 mobile network over the IPv4 network infrastructure. These two mechanisms aims the different goals. The combination of these mechanisms are also possible and when we use these two mechanism at the same time, we can operate IPv4 mobile networks over IPv4 network infrastructure. Shima Expires April 24, 2006 [Page 18] Internet-Draft v4prefix option October 2005 11. Relationship with NAT The mechanism described in this document has nothing to do with the NAT mechanism. As described in Figure 1, a NAT box can be located as one of internal nodes of an IPv4 mobile network. We do not need to distinguish the NAT box from other IPv4 nodes. Of course, it is possible to design the NAT feature in a mobile router. Such a design will reduce the number of nodes to be managed in one mobile network. However, the logical network topology is the same with the network when we operate the NAT box and the mobile router in theory. Therefore, there is no need to differentiate the combined case and the separate case. The decision just depends on the policy and available implementation. Shima Expires April 24, 2006 [Page 19] Internet-Draft v4prefix option October 2005 12. Security Considerations The options defined in this document do not introduce any new security vulnerability. Shima Expires April 24, 2006 [Page 20] Internet-Draft v4prefix option October 2005 13. Acknowledgements The author would like to thank Satoshi Uda, Kenichi Nagami, Ryuji Wakikawa, Thierry Ernst and Romain Kuntz for their input. Shima Expires April 24, 2006 [Page 21] Internet-Draft v4prefix option October 2005 14. Appendix 14.1. An unnumbered tunnel for IPv4 Some implementation (for example, *BSD implementation) do not support an unnumbered tunnel for IPv4 communication. In this case, we need to assign a valid (or just a dummy) IPv4 address on both tunnel end points of a mobile router and a home agent side. It is possible to assign non-routable addresses, such as 169.254/16, since the addresses assigned on the both end of the tunnel interface between a mobile router and a home agent never used for real communication in theory. However, an implementor must take care the address selection algorithm for IPv4 used in their implementation. For example, *BSD system choose an IPv4 address of the outgoing interface, if we does not specify the source address explicitly. This makes invalid (which means, the packet has non-routable address in its source address) packet to be sent to the Internet. Shima Expires April 24, 2006 [Page 22] Internet-Draft v4prefix option October 2005 15. History o Revision 01 * Added the IPv4 Mobile Address description to support host mobility. * Added an appendix section which mentions the unnumbered tunnel problem. o Revision 00 * The initial version published on 26th July 2005. 16. References [1] Devarapalli, Wakikawa, Petrescu, and Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963. [2] Nagami, Uda, Ogashiwa, Wakikawa, Esaki, and Ohnishi, "Multi- homing for small scale fixed network Using Mobile IP and NEMO", draft-nagami-mip6-nemo-multihome-fixed-network-03 (work in progress). [3] Wakikawa, Uehara, Ernst, and Nagami, "Multiple Care-of Address Registration", draft-wakikawa-mobileip-multiplecoa-04 (work in progress). Shima Expires April 24, 2006 [Page 23] Internet-Draft v4prefix option October 2005 Author's Address Keiichi Shima Internet Initiative Japan Inc. Jinbo-cho MItsui Bldg. 1-105 Kanda, Jinbo-cho Chiyoda-ku, Tokyo 101-0051 Japan Phone: +81 3 5205 6500 Email: keiichi@iijlab.net URI: http://www.iij.ad.jp/en/ Shima Expires April 24, 2006 [Page 24] Internet-Draft v4prefix option October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Shima Expires April 24, 2006 [Page 25]