Network Working Group K. Shima Internet-Draft IIJ Expires: January 27, 2006 July 26, 2005 IPv4 Mobile Network Prefix Option for NEMO Basic Support Protocol draft-shima-nemo-v4prefix-00 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 January 27, 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 January 27, 2006 [Page 1] Internet-Draft v4prefix option July 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. Option format . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1 IPv4 Mobile Network Prefix Option . . . . . . . . . . . . 9 4.2 IPv4 Mobile Network Prefix Registration Status Option . . 9 5. Mobile Router operation . . . . . . . . . . . . . . . . . . . 11 6. Home Agent operation . . . . . . . . . . . . . . . . . . . . . 13 7. Choosing a home agent . . . . . . . . . . . . . . . . . . . . 14 8. Relationship with v4traversal . . . . . . . . . . . . . . . . 15 9. Relationship with NAT . . . . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . 17 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 19 Shima Expires January 27, 2006 [Page 2] Internet-Draft v4prefix option July 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 January 27, 2006 [Page 3] Internet-Draft v4prefix option July 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 network, 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 January 27, 2006 [Page 4] Internet-Draft v4prefix option July 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 January 27, 2006 [Page 5] Internet-Draft v4prefix option July 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 January 27, 2006 [Page 6] Internet-Draft v4prefix option July 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 January 27, 2006 [Page 7] Internet-Draft v4prefix option July 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 January 27, 2006 [Page 8] Internet-Draft v4prefix option July 2005 4. Option format 4.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 7 (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. 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. IPv4 Mobile Network Prefix 4 octets field indicating the IPv4 network prefix of a network behind a mobile router. 4.2 IPv4 Mobile Network Prefix Registration Status Option The IPv4 Mobile Network Prefix Registration Status Option is carried Shima Expires January 27, 2006 [Page 9] Internet-Draft v4prefix option July 2005 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 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 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 141 Invalid prefix 142 Not authorized for the prefix 143 Forwarding setup failed Shima Expires January 27, 2006 [Page 10] Internet-Draft v4prefix option July 2005 5. Mobile Router operation A mobile router which has IPv4 networks on its ingress interface can include the IPv4 Mobile Network Prefix option in its Binding Update message to a home agent. After receiving a successful acknowledgment from the home agent, the mobile router add a route entry which indicates that all traffic from the IPv4 networks are 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 January 27, 2006 [Page 11] Internet-Draft v4prefix option July 2005 From a mobile node to a home agent +--------------+ Source: The care-of address of the mobile node | 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 node +--------------+ Source: The home agent address | IPv6 header | Dest: The care-of address of the mobile node | | +--------------+ 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 January 27, 2006 [Page 12] Internet-Draft v4prefix option July 2005 6. 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 4.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 node 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. Figure 3 shows the packet format. Shima Expires January 27, 2006 [Page 13] Internet-Draft v4prefix option July 2005 7. 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 January 27, 2006 [Page 14] Internet-Draft v4prefix option July 2005 8. 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 January 27, 2006 [Page 15] Internet-Draft v4prefix option July 2005 9. 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 January 27, 2006 [Page 16] Internet-Draft v4prefix option July 2005 10. Security Considerations The options defined in this document do not introduce any new security vulnerability. Shima Expires January 27, 2006 [Page 17] Internet-Draft v4prefix option July 2005 11. Acknowledgements The author would like to thank Satoshi Uda, Kenichi Nagami, Ryuji Wakikawa, Thierry Ernst and Romain Kuntz for their input. 12. 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). 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 January 27, 2006 [Page 18] Internet-Draft v4prefix option July 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 January 27, 2006 [Page 19]