MEXT Working Group R. Wakikawa Internet-Draft Toyota ITC Intended status: Informational S. Miyakawa Expires: January 5, 2009 NTT Communications Corporation July 4, 2008 NEMO Basic Support for Fixed Access Networks draft-wakikawa-nemo-fixed-access-network-00.txt 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 5, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Wakikawa & Miyakawa Expires January 5, 2009 [Page 1] Internet-Draft NEMO Applicabiliy to ISP July 2008 Abstract This document describes the usage of Network Mobility (NEMO) for the commercial ISPs. NEMO can be a mechanism to provide IP subscription. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. System Design and Concept . . . . . . . . . . . . . . . . . . 4 2.1. Concept . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. The Advantages of NEMO technology for ISP . . . . . . . . 6 3. Technical Consideration . . . . . . . . . . . . . . . . . . . 9 3.1. Expected Basic Technology . . . . . . . . . . . . . . . . 9 3.2. Security and AAA . . . . . . . . . . . . . . . . . . . . . 9 3.3. Route Optimization Support . . . . . . . . . . . . . . . . 10 3.4. Site Multihoming Support . . . . . . . . . . . . . . . . . 12 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 Appendix A. References . . . . . . . . . . . . . . . . . . . . . 14 A.1. Normative References . . . . . . . . . . . . . . . . . . . 14 A.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Wakikawa & Miyakawa Expires January 5, 2009 [Page 2] Internet-Draft NEMO Applicabiliy to ISP July 2008 1. Introduction Commercial Internet Service Provider (ISP) shifts to IPv6 service due to lack of global IPv4 address. Although there are several ways to provide commercial IP services to customers, this document explains how Network Mobility technology is applicable even for fixed network service. This document shows the possible configuration and operation of Network Mobility (NEMO) for commercial fixed network service. We also describes the missing functionalities of NEMO in terms of the commercial ISP services. Readers are expected to be familiar with all the terms defined in 'Mobility Related Terminology' [RFC-3753] and 'Network Mobility Support Terminology' [RFC-4885]. The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC-2119]. Wakikawa & Miyakawa Expires January 5, 2009 [Page 3] Internet-Draft NEMO Applicabiliy to ISP July 2008 2. System Design and Concept 2.1. Concept NEMO technology might let ISP shift to IP based service from PPP based operation, though there is no mobility involvement. The left figure of Figure 1 shows the typical network configurations of Access Service Provider (ASP) and ISP for commercial network services. There are several access medias between ISP and User's site such as ADSL, Fiber, DSL. In the most deployment case, point-to-point link is established between ISP and user's site by PPPoE, PPPoA and so on. PC1 and PC2 are depicted as user's machines in Figure 1. +--------------+ +--------------+ | ISP | | ISP | +------+-------+ +------+-------+ | | PE: Provider Edge HA: Home Agent ASP | ASP || | point-to-point link || Bi-directional tunnel | || CPE: Customer Premises MR: Mobile Router | Equipment | -+----+----+- -+----+----+- | | | | PC1 PC2 PC1 PC2 (User's Site Network) (Mobile Network) Figure 1: Network Overview The right figure shows the configuration of the NEMO Basic Support Protocol [RFC-3963]. RFC3963 is used to provide a network access to user's site from ISP. Mobile Router acts as CPE and HA takes role of PE as shown in the right figure of Figure 1. ISP operates a home agent and a mobile router is located at each user's home/office. We summarize the configuration in below. o ISP is an operator of Home Agent and Home Network. It provides: 1. IPv6 Home Address to a mobile router 2. IPv6 Mobile Network Prefix(es) to a mobile router 3. IPv4 Home Address(es) to a mobile router Wakikawa & Miyakawa Expires January 5, 2009 [Page 4] Internet-Draft NEMO Applicabiliy to ISP July 2008 o ASP is an operator of Foreign Network and provides: 1. Care-of Address(IPv4 or IPv6) to a mobile router o User is living at a Mobile Network. 1. All the required information is obtained from both ISP and ASP. 2. User's site network is provided as a mobile network of NEMO. The idea is to replace PPP between PE and CPE by IP-in-IP tunnel managed by NEMO. The Home Agent assigns both IPv4 and IPv6 addresses to a mobile router. The mobile router owned by users acquires a care-of address from ASP and registers that care-of address to ISP's home agent as a binding. Figure 2 shows the possible network overview when ASP and ISP commercial services are operated by NEMO. When a user buy IP connectivity service, a MR is installed in each home and obtained IP addressed from respective home agent of which the user subscribes. ASP provides addresses to each MR and IP forwarding capability to and from the MR. Wakikawa & Miyakawa Expires January 5, 2009 [Page 5] Internet-Draft NEMO Applicabiliy to ISP July 2008 Internet /|\ /|\ | | ISP1 ISP2 2001:DB8:1::/48 2001:DB8:2::/48 a.b.c/n d.e.f/n +-+--+ +-+--+ |HA1 | |HA2 | +-++-+ +-++-+ | || | | || | _.---| || |---------| || |---. _.-----'' | || | | || | `-------. ,--'' | || | | || | `---. ,-' ____________| || | | || | IP-in-IP tunnel `-. / / _____________|| | | || |__________ \ ( / / | | | ||__________ | ) \ / / ____| | | | | | / `-. | | | ____| | | | | ,-' `--| | | | | | | | _.--' | |`-------. | | | | _.---| |-'' | | `--| |-------------| |----'' | | | | | | | | | | +-+-+ +-+-+ +-+-+ +-+-+ |MR1| |MR2| |MR3| |MR4| ... +-+-+ +-+-+ +-+-+ +-+-+ | | | | --+-- --+-- --+-- --+-- User's Site1 User's Site2 User's Site3 User's Site4 ... Figure 2: NEMO Network Design 2.2. The Advantages of NEMO technology for ISP NEMO has been standardized for mobility purpose. There are several reasons to use NEMO technology for ISP listed below. IPv4 and IPv6 Connectivity A mobile router obtains an IPv6 home address and more than one IPv6 mobile network prefixes for its mobile network. By using DSMIPv6 extension [ID-DSMIP6], IPv4 home address(es) can also be assigned to a mobile router. Therefore, both IPv4 and IPv6 connectivity can be provided to User's site network. Wakikawa & Miyakawa Expires January 5, 2009 [Page 6] Internet-Draft NEMO Applicabiliy to ISP July 2008 Flexibile Placement of Mobile Router The NEMO needs a care-of address for its binding registration. The original NEMO [RFC-3963] requires IPv6 address as a care-of address. The global address is preferred, but there is not technical limitation for using non-global address. In addition, with DSMIPv6 extension, a mobile router can use any of IP addresses such as IPv4 private address and IPv4 global address as a care-of address. The appropriate tunnel such as UDP-IP tunnel, IPv4-IPv6 tunnel or IPv6-IPv6 tunnel can be established between a mobile router and a home agent. The tunnel is automatically established as long as a mobile router obtains a care-of address at a visiting network. Thanks to NEMO and DSMIP, a mobile router can be attached to any kinds of network and send a binding update to its home agent. Flexible Transition from the current Architecture The NEMO architecture is similar to what the current system is designed with PPP. The ISP and ASP can inherit the current system during this transition period. It is also independent from access media technologies. ASP and ISP Independent Authentication As shown in Section 2.1, ISP and ASP manage the different type of "IP networks". Thus, both ISP and ASP may be able to authenticate each user during the address assignment. For example, ISP authenticate the user when it delegates an IPv6 home address, an IPv6 prefix(es) (mobile network prefix) and an IPv4 home address(es) to a mobile router, while ASP authenticates the user when it provides a care-of address to the mobile router.. Possible Route Optimization The traffic between users' site networks has increased due to deployment of P2P applications. The route optimization inside ASP becomes strong requirements of ASP. Although NEMO does not support route optimization at this moment, it should be extensible to this optimization in the future. The MEXT working group has discussed the route optimization for NEMO. Multihoming Capability NEMO is extensible to support User's site-multihoming. A user can subscribe to the same ISP with multiple ASPs. RFC4908 [RFC-4908] describes the detail of NEMO site-multihoming capability. Wakikawa & Miyakawa Expires January 5, 2009 [Page 7] Internet-Draft NEMO Applicabiliy to ISP July 2008 Movement Transparency Even if a user changes the attachment point or even changes ASP due to the user's moving (ex. moving house), the user can continue using the same ISP configuration. This is also great advantage for ISP to continue serving the user regardless of the user's location. Flexibile Multicast Management and Optimization There are two different way for nodes in a mobile network to subscribe a multicast group. One way is called home subscription where nodes join to the multicast group through ISP. The nodes join the multicast group with an address obtained from the mobile router. The multicast control traffic such as MLD request are captured by the mobile router and tunneled to the Home Agent. Another way is named remote subscription where nodes join to the multicast group at ASP network. The mobile router acts as a proxy MLD and forwards the MLD request from nodes in the mobile network to ASP. As a result, the user's node can join to either ISP or ASP multicast service, or both by using these approaches. The tree can be maintained optimal. Wakikawa & Miyakawa Expires January 5, 2009 [Page 8] Internet-Draft NEMO Applicabiliy to ISP July 2008 3. Technical Consideration 3.1. Expected Basic Technology NEMO and DSMIPv6 are mandatory to provide IPv4 and IPv6 connectivity. DSMIPv6 has two functionalities: providing IPv4 mobility support and IPv4 transport support. ASP can easily transit from IPv4 to IPv6, because a mobile router can place at either IPv4 global/private network, IPv6 network, or mixed of them. It is also benefical for a user to provide both IPv4 and IPv6 connectivity. o [RFC-3963]: Network Mobility (NEMO) Basic Support Protocol o [ID-DSMIP6]: Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6) ISP requires to operate the large number of subscribers. NEMO Working Group summarizes how to manage the home network in several ways. o [RFC-4887]: Network Mobility Home Network Models For the mobile network prefix delegation, the following proposal is available o [ID-NEMOPD]: DHCPv6 Prefix Delegation for NEMO 3.2. Security and AAA NEMO protocol is designed to protect all the signaling by IPsec as same as Mobile IPv6. However, since the access network is securely managed and operated by Access Service Provider (ASP), IPsec is not always necessary for binding signaling. User cannot pull the wired cable in their home or office and cannot activate it without ASP service contract. (i.e. Physical level security is available). Therefore, Authentication Protocol [RFC-4285] is sufficient for securing binding updates in some scenarios although IPsec can be also employed. o [RFC-3776]: Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents o [RFC-4887]: Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture o [RFC-4285]: Authentication Protocol for Mobile IPv6 In NEMO, both IPv4/IPv6 home address and mobile network prefix(es) Wakikawa & Miyakawa Expires January 5, 2009 [Page 9] Internet-Draft NEMO Applicabiliy to ISP July 2008 are provided by ISP after AAA transaction. There are several proposals to authenticate Mobile IPv6 resources such as home address and mobile network prefix: o [ID-AAAGOAL]: AAA Goals for Mobile IPv6 o [ID-MIPRADIUS]: RADIUS Mobile IPv6 Support For an IPv4/IPv6 care-of address, ASP can utilize any kinds of mechanism of address assignment such as DHCP, PPPo{E/A} and address autoconfiguration, etc. The care-of address assignment is exact same as the regular IPv6 address assignment. 3.3. Route Optimization Support ASP has certain needs for Route optimization between User's sites. Several P2P applications exchange traffic between User's site. Without route optimization, all traffic will be routed to the Internet and came back to the same ASP. This is redundant operation and should be avoided. Two scenarios can be considered whether route optimization must be achieved between User's sites operated by either same or different ISPs. Figure 3 shows the example. MR2 and MR3 are operated by different ISPs, while MR3 and MR4 are operated by the same ISP. We also need to consider that the ASP provides non global care-of address as a care-of address. Even for non global care-of address, route optimization can be achieved within the same ASP. Wakikawa & Miyakawa Expires January 5, 2009 [Page 10] Internet-Draft NEMO Applicabiliy to ISP July 2008 Internet /|\ /|\ | | ISP1 ISP2 2001:DB8:1::/48 2001:DB8:2::/48 a.b.c/n d.e.f/n +-+--+ +-+--+ |HA1 | |HA2 | +-+--+ +-+--+ | | _.------+--------------+----. _.-----'' `-------. ,--'' `---. ,-' `-. / \ ( ) \ RO(MR2<->MR3) RO(MR3<->MR4) / `-. _______________ ________________ ,-' `---. | _____________ || _____________ | _.--' |`-------. | | | || | _.----| |'' | `--| |-----------| || |----'' | | | | | | || | | | +-+-+ +-+-+ +-+--+ +-+-+ |MR1| |MR2| |MR3 | |MR4| ... +-+-+ +-+-+ +-+--+ +-+-+ | | | | --+-- --+-- --+-- --+-- User's Site1 User's Site2 User's Site3 User's Site4 ... Figure 3: NEMO Route Optimization NEMO does not support route optimization at this point, but the MEXT working group has discussed the useful scenarios of route optimization. The available documents are: o [RFC-4888]: Network Mobility Route Optimization Problem Statement o [RFC-4889]: Network Mobility Route Optimization Solution Space Analysis o [ID-AEROREQ]: NEMO Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks o [ID-AUTOREQ]: Automotive Industry Requirements for NEMO Route Optimization Wakikawa & Miyakawa Expires January 5, 2009 [Page 11] Internet-Draft NEMO Applicabiliy to ISP July 2008 3.4. Site Multihoming Support Site-multihoming is easily provided with NEMO. There is an extension to register multiple care-of addresses of a mobile router to home agent. The extension is being standardized at MEXT Working Group [ID-MCOA]. A user subscribes multiple ASPs and single ISP. For better optimization, the ISP should have relationship with the ASPs to which user subscribe, but this is not mandatory. o [RFC-4908]: Multihoming for Small-Scale Fixed Networks Using Mobile IP and Network Mobility (NEMO) o [ID-MCOA]: Multiple Care-of Addresses Registration +-------------------------+ | The Internet | +-----------+-------------+ | ISP +-+--+ +--| HA |---+ | +----+ | | | | | ASP-A ASP-B | | | +---+ | +---|MR |---+ CoA1 +---+ CoA2 | -------+--------- Multihomed Network (User's Site) Figure 4: Site Multihoming Wakikawa & Miyakawa Expires January 5, 2009 [Page 12] Internet-Draft NEMO Applicabiliy to ISP July 2008 4. IANA considerations This document does not require any IANA action. Wakikawa & Miyakawa Expires January 5, 2009 [Page 13] Internet-Draft NEMO Applicabiliy to ISP July 2008 5. Security Considerations Security vulnerability is not introduced in this specification. Appendix A. References A.1. Normative References [RFC-3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [ID-DSMIP6] Soliman, H. et al, "Mobile IPv6 support for dual stack Hosts and Routers (DSMIPv6)", draft-ietf-mext-nemo-v4traversal-04.txt, June 2008. A.2. Informative References [ID-MOTIVATION] Ernst, T., Montavont, N., Wakikawa, R., Ng, C., and K. Kuladinithi, "Motivations and Scenarios for Using Multiple Interfaces and Global Addresses", draft-ietf-monami6-multihoming-motivation-scenario-02 (work in progress), July 2007 [ID-MIP6ANALYSIS] Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K. Kuladinithi, "Analysis of Multihoming in Mobile IPv6", draft-ietf-monami6-mipv6-analysis-04 (work in progress), Novemver 2007. [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC-3753] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [RFC-4885] Ernst, T. and H. Lach, "Network Mobility Support Terminology", RFC 4885, July 2007. [RFC-4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture", RFC 4877, April 2007. [RFC-4980] Ng, C., Paik, Ernst, and C. Bagnulo, "Analysis of Multihoming in Network Mobility Support", RFC 4980, October 2007. Wakikawa & Miyakawa Expires January 5, 2009 [Page 14] Internet-Draft NEMO Applicabiliy to ISP July 2008 [RFC-4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route Optimization for Mobile IPv6", RFC 4866, May 2007. [RFC-4908] K. Nagami, et. al, "Multihoming for Small-Scale Fixed Networks Using Mobile IP and Network Mobility (NEMO)", RFC 4908, June 2007. [RFC-4887] P. Thubert, et. al, "Network Mobility Home Network Models", RFC 4887, July 2007. [RFC-4285] A. Patel, et. al,"Authentication Protocol for Mobile IPv6", RFC 4285, January 2006. [ID-AAAGOAL] G. Giaretta, et. al, "AAA Goals for Mobile IPv6", draft-ietf-mext-aaa-ha-goals-01.txt, May 2008. [ID-MIPRADIUS] A. Lior, et. al, "RADIUS Mobile IPv6 Support", draft-ietf-mip6-radius-04.txt, February 2008. [ID-NEMOPD] R. Droms, et. al, "DHCPv6 Prefix Delegation for NEMO", draft-droms-mext-nemo-pd-00.txt, May 2008. [RFC-4888] C. Ng, et. al, "Network Mobility Route Optimization Problem Statement", RFC 4888, July 2007. [RFC-4889] C. Ng, et. al, "Network Mobility Route Optimization Solution Space Analysis", RFC 4889, July 2007. [ID-AEROREQ] W. Eddy, et. al,"NEMO Route Optimization Requirements for Operational Use in Aeronautics and Space Exploration Mobile Networks", draft-ietf-mext-aero-reqs-02.txt, May 2008. [ID-AUTOREQ] R. Baldessari, et. al, "Automotive Industry Requirements for NEMO Route Optimization", draft-ietf-mext-nemo-ro-automotive-req-00.txt, February 2008. [ID-MCOA] R. Wakikawa, et. al, "Multiple Care-of Addresses Registration", draft-ietf-monami6-multiplecoa-08.txt, May 2008. Wakikawa & Miyakawa Expires January 5, 2009 [Page 15] Internet-Draft NEMO Applicabiliy to ISP July 2008 Authors' Addresses Ryuji Wakikawa Toyota ITC / Keio University 6-6-20 Akasaka, Minato-ku Tokyo 107-0052 Japan Phone: +81-3-5561-8276 Fax: +81-3-5561-8292 Email: ryuji@jp.toyota-itc.com Shin Miyakawa Innovative IP Architecture Center, NTT Communications Corporation Tokyo Opera City Tower 21F, 3-20-2 Nishi-Shinjuku, Shinjuku-ku, Tokyo Japan Phone: +81-3-6800-3262 Email: miyakawa@nttv6.jp Wakikawa & Miyakawa Expires January 5, 2009 [Page 16] Internet-Draft NEMO Applicabiliy to ISP July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Wakikawa & Miyakawa Expires January 5, 2009 [Page 17]