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]