One document matched: draft-wakikawa-netext-pmip6-nemo-support-00.txt
NETLMM Working Group(NetEXT) R. Wakikawa
Internet-Draft Toyota ITC
Intended status: Standards Track S. Gundavelli
Expires: October 8, 2009 Cisco
Y. Zhao
Huawei Tech.
April 6, 2009
NEtwork MObility (NEMO) Support for Proxy Mobile IPv6
draft-wakikawa-netext-pmip6-nemo-support-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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 October 8, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
Wakikawa, et al. Expires October 8, 2009 [Page 1]
Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Wakikawa, et al. Expires October 8, 2009 [Page 2]
Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009
Abstract
This document specifies an extension to Proxy Mobile IPv6 protocol
for supporting network mobility. The solution leverages the
extensions defined in [RFC3963], [ID-DHCPPD-NEMO] and [RFC3633]
specification for achieving this.
Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 5
3. Network Mobility Support . . . . . . . . . . . . . . . . . . . 6
3.1. Mobile Network Prefix Option . . . . . . . . . . . . . . . 6
3.2. Mobile Network Prefix Delegation . . . . . . . . . . . . . 7
3.3. Mobile Access Gateway Considerations . . . . . . . . . . . 9
3.3.1. Extensions to Binding Update List Entry . . . . . . . 9
3.3.2. Signaling Considerations . . . . . . . . . . . . . . . 9
3.4. Local Mobility Anchor Considerations . . . . . . . . . . . 12
3.4.1. Extensions to Binding Cache Entry . . . . . . . . . . 12
3.4.2. Prefix Management . . . . . . . . . . . . . . . . . . 12
3.4.3. Signaling Considerations . . . . . . . . . . . . . . . 13
3.4.4. Routing Considerations . . . . . . . . . . . . . . . . 14
3.5. Mobile Router Considerations . . . . . . . . . . . . . . . 14
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Normative References . . . . . . . . . . . . . . . . . . . 18
6.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Wakikawa, et al. Expires October 8, 2009 [Page 3]
Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009
1. Overview
Figure 1 illustrates a Proxy Mobile IPv6 domain supporting network
mobility features. The mobile routers, MR1 and MR2 can obtain a
mobile network prefix(es) in addition to a home address (i.e. Home
Network Prefix in Proxy Mobile IPv6) from the network.
+----+ +----+
|LMA1| |LMA2|
+----+ +----+
LMAA1 -> | | <-- LMAA2
| |
\\ //\\
\\ // \\
+---\\------------- //------\\----+
( \\ // \\ )
( \\ Network // \\ )
+------\\--------//------------\\-+
\\ // \\
\\ // \\
\\ // \\
Proxy-CoA1--> | | <-- Proxy-CoA2
+----+ +----+
|MAG1| |MAG2|
+----+ +----+
| |
HoA --> | | <-- HoA
{MR1} {MR2}
IPv6 MNP --> ____|____ ____|____ <-- IPv6 MNP
| | | |
MNN MNN MNN MNN
Figure 1: Network Mobility support for Proxy Mobile IPv6
Wakikawa, et al. Expires October 8, 2009 [Page 4]
Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009
2. Conventions & Terminology
The key words "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].
All the mobility related terms used in this document are to be
interpreted as defined in Mobile IPv6 [RFC-3775], Network Mobility
Basic Support protocol [RFC-3963], Proxy Mobile IPv6 specification
[RFC-5213], DHCPv6 Prefix Delegation for NEMO [ID-DHCPPD-NEMO], DHCP
Prefix Delegation [RFC3633] and Mobility Related Terminology [RFC-
3753]. This document does not define any new terms.
Wakikawa, et al. Expires October 8, 2009 [Page 5]
Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009
3. Network Mobility Support
The NEMO Basic protocol [RFC3963] extends Mobile IPv6 [RFC3775] to
enable network mobility. This specification extends Proxy Mobile
IPv6 to assign not only a home address but also a mobile network
prefix(es) to a mobile router with mobility support.
This specification assumes that a mobile router is a regular IPv6
router and is not extensible for mobility managements. The
modifications introduced in this specification are limited only to
the operations of the mobile access gateway and the local mobility
anchor. This specification does not require any dynamic routing
protocols' interaction between a mobile router and the Proxy Mobile
IPv6 domain. The mobile router transmits the packets from its mobile
network to the attached mobile access gateway and the mobile access
gateway delivers the packets to the mobile network via the mobile
router.
When a mobile router first connects to a Proxy Mobile IPv6 domain, it
runs DHCP Prefix Delegation [RFC3633] to get a mobile network prefix.
This mobile network prefix is different from the Mobile Node's home
network prefix assigned by local mobility anchor. After getting the
mobile network prefix from a designated router, the mobile router
assigns the prefix to its mobile network. The attached mobile access
gateway becomes a default router of the mobile router. Meanwhile,
the mobile access gateway detects the attachment of the mobile router
and sends a proxy binding update to the local mobility anchor. The
mobile access gateway, then, tunnels the packets to the local
mobility anchor and the local mobility anchor routes the packets to
the destination. In order to setup a tunnel between the local
mobility anchor and the mobile access gateway for the mobile network
prefix, the mobile network prefix mobility option [RFC3963] is
carried in a proxy binding update message.
This specification does not support the nested configuration of
mobile routers operated by this specification, because a mobile
router attached to another mobile router cannot obtain its home
address. The Proxy Mobile IPv6 specification requires the direct
connectivity (point-to-point link) between a mobile router and a
mobile access gateway. The RFC3963-compliant mobile router can
attach to mobile networks operated by this specification, but no
special operation for the RFC3963-compliant mobile router is
introduced in this specification.
3.1. Mobile Network Prefix Option
The Mobile Network Prefix Option is defined in [RFC-3963]. This
specification adds a new bit for the purpose of the prefix delegation
Wakikawa, et al. Expires October 8, 2009 [Page 6]
Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009
as follows.
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 |R| Reserved | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Mobile Network Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Modified Mobile Network Prefix Option
Requesing (R) flag
A flag indicating that the mobile access gateway requests a mobile
network prefix for the a mobile router. When this flag is set,
the mobile network prefix stored in the Mobile Network Prefix
field is ignored and overwritten by the newly assigned prefix by
the local mobility anchor. This flag can be set for new request
and binding refreshes, too. If a mobile router changes the
attached mobile access gateway, the new mobile access gateway can
retrieve the mobile network prefix previously assigned to the
mobile router.
Reserved
7 bits reserved field
3.2. Mobile Network Prefix Delegation
A mobile router SHOULD dynamically obtain a mobile network prefix by
DHCP Prefix Delegation [RFC3633] or MAY be statically configured with
the assigned prefix.
When DHCP Prefix Delegation is used, a mobile router MUST act as a
requesting router [RFC3633] and a mobile access gateway MUST be a
DHCP relay agent. The delegating router [RFC3633] can be located
either at a local mobility anchor or some other device in a Proxy
Mobile IPv6 domain. In Proxy Mobile IPv6, a mobile access gateway
can intercept all the DHCP related packets from a mobile router as a
Wakikawa, et al. Expires October 8, 2009 [Page 7]
Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009
DHCP relay.
MR(RR) MAG(DHCP-R) LMA DR
|------>| | | 1. DHCP solicit
| |------->| | 2. Proxy Binding Update
| |<-------| | 3. Proxy Binding Acknowledgement (MNP)
| |========| | 4. Tunnel/Route Setup*
| |---------------->| 5. DHCP (including IA_PD)
|<------|<----------------| 6. DHCP advertise
| | | |
* DHCP solicit (1) and PBU (2) are operated in parallel.
* Tunnel/Route setup(4) and DHCP message exchange (5 and 6)
are processed in parallel.
Figure 3: Prefix Delegation
After attaching to the Proxy Mobile IPv6 domain, if a mobile router
does not have any active delegated prefix for its mobile network, it
sends a DHCPv6 Solicit message as shown in Figure 3-1). The message
is intercepted by the DHCPv6 relay agent located at the mobile access
gateway. Before relaying this message, the mobile access gateway
should obtain a mobile network prefix delegated for the mobile router
by using the proxy binding registration. It sends a Proxy Binding
Update with a Mobile Network Prefix option [RFC-3963] with the
requesting bit set (Figure 3-2)). The local mobility anchor returns
the assigned prefix in the Mobile Network Prefix option carried by a
Proxy Binding Acknowledgment (Figure 3-3)). This proxy binding
registration is to guarantee that the local mobility anchor controls
the prefix assignment on behalf of the DHCP Prefix Delegation
protocol. This document recommends that Proxy Mobile IPv6 controls
the prefix management and DHCP Prefix Delegation is used to deliver
the assigned prefix to a requesting router (i.e. mobile router).
Otherwise, the Proxy Mobile IPv6 requires certain interactions with
the DHCP Prefix Delegation protocol to verify whether the prefix
notified by a Proxy Binding Update is surely assigned to the
requesting mobile router or not. This protocol interface has not
been standardized at IETF yet and is out of scope in this document.
If the mobile access gateway obtains the assigned prefix for the
mobile router by receiving the Mobile Network Prefix option in the
Proxy Binding Acknowledgement, it contains the assigned prefix in the
IA_PD Prefix option [RFC3633] encapsulated in the IA_PD-options as a
hint and sends the DHCPv6 message to the delegating router
(Figure 3-4)). The delegating router MUST choose to use the
information in that hint to select the prefix(es) or prefix size to
be delegated to the requesting router. The delegating router, then,
Wakikawa, et al. Expires October 8, 2009 [Page 8]
Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009
sends an Advertise message to the requesting router as described in
[RFC3315] and [RFC3633] (Figure 3-5) and 6)). On the other hand, if
the mobile access gateway fails to have the mobile network prefix
from its local mobility anchor, it MUST discard any DHCPv6 messages
of the requesting mobile router.
If the mobile router has already had one or more active delegated
prefixes, it sends DHCPv6 Renew messages to extend the lifetimes of a
delegated prefix. The messages are also intercepted by the mobile
access gateway and relayed to the delegating router. The delegating
router replies with DHCPv6 reply message to the requesting router.
The mobile access gateway acting as a DHCP relay SHOULD check all the
DHCPv6 reply message. If zero is set to the lifetime of a mobile
network prefix stored in the IA_PD Prefix option carried by a DHCPv6
reply message, the mobile access gateway SHOULD triggers a Proxy
Binding Update to remove the binding for that mobile network prefix.
If the mobile router has multiple network interfaces attached to the
same Proxy Mobile IPv6 domain, it should be able to use all the
active interfaces to transmit the packets from its mobile network.
To do so, the local mobility anchor MUST always return the mobile
network prefix assigned to the mobile router by the Mobile Network
Prefix option in the Proxy Binding Acknowledgement if the mobile
network prefix is already assigned to that mobile router. Even
though a mobile router does not initiate the prefix delegation
procedure from the newly attached interface, the mobile access
gateway can learn the assigned prefix. The local mobility anchor and
the mobile access gateways can setup a route of the mobile network
prefix for all the active interfaces of the mobile router in the
Proxy Mobile IPv6 domain. A mobile router can utilize all the active
interfaces as an exit interface of the mobile network.
3.3. Mobile Access Gateway Considerations
3.3.1. Extensions to Binding Update List Entry
This document introduces a new Prefix Information field in the
Binding Update list structure as [RFC3963] does. This field is used
to store the mobile network prefix information that the local
mobility anchor notified during the proxy binding registration.
3.3.2. Signaling Considerations
The detail operation of prefix delegation is described in Section 3.2
Mobile Router Initial Attachment
Wakikawa, et al. Expires October 8, 2009 [Page 9]
Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009
o After detecting a new mobile router on its access link, the mobile
access gateway MUST identify the mobile router and acquire the MN-
Identifier of the mobile router as [RFC-5213]. It SHOULD
determine whether the network mobility service needs to be offered
to the mobile node or not by checking the policy profile.
Proxy Binding Registration:
o The mobile access gateway triggers a Proxy Binding Update with a
Mobile Network Prefix mobility option defined in [RFC3963]. It
MUST uses the Mobile Network Prefix option in the following cases:
1. A mobile access gateway requests a mobile network prefix
assigned to the mobile router. (i.e. the mobile router does
not have any prefix yet)
2. A mobile access gateway asks the assigned mobile network
prefix to the mobile router. (i.e. the mobile router has
already had the mobile network prefix)
3. A mobile access gateway renews the binding cache for the home
network prefix and the mobile network prefix.
o The proxy binding registration process is same as [RFC-5213]
except that the Mobile Network Prefix mobility option MUST be
presented.
o The Mobile Router flag (R) defined in [RFC3963] MUST be set in the
Proxy Binding Update for a mobile router
o For the scenarios-1) and -2), the mobile access gateway MUST set
the requesting bit in the Mobile Network Prefix option.
o For the scenario-3), the mobile access gateway SHOULD NOT set the
requesting flag and MUST set the mobile network prefix to the
mobile router in the Mobile Network Prefix option.
o The mobile access gateway can use both implicit or explicit the
mobile network prefix registration as [RFC3963] defined. The
implicit registration MUST NOT be used if the mobile access
gateway does not know the mobile network prefix assigned to the
mobile router
o When the requesting bit is set in the Mobile Network Prefix
option, the local mobility anchor will return the assigned prefix
by the Mobile Network Prefix option stored in the Proxy Binding
Acknowledgement. If the Mobile Network Prefix option does not
Wakikawa, et al. Expires October 8, 2009 [Page 10]
Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009
present or does not have a valid IPv6 prefix, the mobile access
gateway MUST NOT enable Network Mobility support for the mobile
router.
DHCPv6 Prefix Management
o The mobile access gateway MUST intercept all the DHCPv6 related
messages and SHOULD verify all the DHCPv6 messages before relaying
to either a requesting router or a delegating router.
o If the mobile access gateway detects a DHCPv6 solicit message from
the mobile router, it should intercept it and caches it until it
learns an assigned mobile network prefix from local mobility
anchor.
o If network mobility service is not enabled for the mobile router
in the policy profile, the mobile access gateway MUST ignores the
DHCPv6 solicit message.
o After the mobile access gateway obtains an assigned mobile network
prefix(es), it includes the information in an IA_PD Prefix option
of DHCPv6 messages initiated by the requesting router (mobile
router) and relays the messages to the delegating router.
o The delegating router MUST return a DHCPv6 reply message including
the assigned prefix to the mobile router via the mobile access
gateway (DHCP relay agent). However, if the different prefix from
the one in the hint is assigned by the delegating router, the
mobile access gateway MUST discard the message and SHOULD re-relay
the DHCPv6 message to the delegating router. After a few retries,
it SHOULD give up replaying the messages.
o If the lifetime of the assigned prefix is set to zero, the mobile
access gateway MUST sends a de-registration Proxy Binding Update
to the local mobility anchor.
Mobile Router's Handover:
o As the mobile router moves from one mobile access gateway to
another, the new mobile access gateway MAY know the assigned
prefix to the mobile router by mechanisms such as context transfer
between the mobile access gateways. However, such mechanisms are
not defined in this specification.
o If no context transfer mechanism is available, the mobile access
gateway sends a Proxy Binding Update message with a Mobile Network
Wakikawa, et al. Expires October 8, 2009 [Page 11]
Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009
Prefix option with the requesting bit set. The local mobility
anchor MUST return the same assigned prefix by the Mobile Network
Prefix option stored in a Proxy Binding Acknowledgement so that
the new mobile access gateway can obtain the assigned prefix.
o After the mobile router's first attachment to a Proxy Mobile IPv6
domain, the DHCP Prefix Delegation protocol might not always run
as a mobile router changes its attached mobile access gateway.
Mobile Router's Multihoming Support:
o Even if the mobile router attaches to the Proxy Mobile IPv6 domain
by multiple interfaces, it SHOULD be capable of using all the
interfaces as external paths for the mobile network.
o A home network prefix is assigned per interface in Proxy Mobile
IPv6, but a mobile network prefix is assigned per a mobile router.
Therefore, all the mobile access gateway to which a mobile router
is attached can get the same prefix from the local mobility
anchor.
o The mobile access gateways setup a route for the mobile network
prefix as soon as it receives the proxy binding Acknowledgement.
3.4. Local Mobility Anchor Considerations
3.4.1. Extensions to Binding Cache Entry
This document introduces a new Prefix Information field in the
Binding Cache structure as [RFC3963] does. This field is used to
store any prefix information that the mobile access gateway includes
in the Binding Update. In the multihoming scenario, the local
mobility anchor may have two different binding cache entries per
mobile node's identifier. The mobile network prefix information of
two binding caches must be same, because the prefix is assigned per a
mobile router.
3.4.2. Prefix Management
A local mobility anchor manages the prefix pool for mobile network
prefixes assigned to a mobile router. Assigned prefix is tied to a
mobile router. The local mobility anchor should manage the mobile
network prefix with the mobile node identifier. If the requesting
router has the same mobile node identifier and a prefix is already
assigned to that router, the local mobility anchor MUST return the
same assigned prefix to the requesting router.
Wakikawa, et al. Expires October 8, 2009 [Page 12]
Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009
3.4.3. Signaling Considerations
All the considerations explained in Section 5.3 [RFC-5213] apply
here. For supporting network mobility feature, the following
additional considerations MUST be applied.
Processing Binding Registrations:
o If there is a Mobile Network Prefix option in a Proxy Binding
Update message, the local mobility anchor MUST proceed the
following instructions.
o If the requesting bit is set in the Mobile Network Prefix option,
the local mobility anchor SHOULD look for the prefix assigned to
the mobile router. If there is no previously assigned prefix, the
local mobility anchor MUST allocate a new mobile network prefix to
the mobile router. Otherwise, it SHOULD continue using the same
assigned prefix for the mobile router.
o The assigned prefix MUST be returned with the Mobile Network
Prefix option in a Proxy Binding Acknowledgement message.
o If the local mobility anchor is unable to allocate a Mobile
Network Prefix for the mobile router, it MUST reject the Proxy
Binding Update and send a Proxy Binding Acknowledgement message
with Status field set to 130 (Insufficient resources).
o Upon accepting the request, the local mobility anchor MUST create
a Binding Cache entry for the mobile router. It must set the
fields in the Binding Cache entry to the accepted values for that
binding. The assigned prefix is also stored as the mobile network
prefix in the binding cache entry of the mobile router.
o It MUST also establish a bi-directional tunnel to the mobile
access gateway, as described in [RFC-2473]. Considerations from
Section 5.6 [RFC-5213] MUST be applied. The local mobility anchor
MUST add a network route for that allocated mobile network prefix
over the tunnel to the mobile access gateway.
o The local mobility anchor MUST use the identifier from the Mobile
Node Identifier Option [RFC-4283] present in the Proxy Binding
Update request and MUST apply multihoming considerations specified
in Section 5.4 [RFC-5213] and from this section for performing the
Binding Cache entry existence test.
Wakikawa, et al. Expires October 8, 2009 [Page 13]
Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009
3.4.4. Routing Considerations
Forwarding Considerations for the mobile router's mobile network
prefix traffic.
Intercepting Packets Sent to the mobile network:
o When the local mobility anchor is serving a mobile router, it MUST
be able to receive packets that are sent to the mobile router's
mobile network. In order for it to receive those packets, it MUST
advertise a connected route in to the Routing Infrastructure for
the mobile router's mobile network prefix or for an aggregated
prefix with a larger scope.
Forwarding Packets to the Mobile Router:
o On receiving a packet from a correspondent node with the
destination address matching a mobile router's mobile network
prefix, the local mobility anchor MUST forward the packet through
the bi- directional tunnel setup for that mobile router. The
format of the tunneled packet is the same as [RFC-5213] except
that the destination address of the inner packet header is the
IPv6 address of the mobile network node attached to the mobile
network.
Forwarding Packets Sent by the Mobile Router:
o All the reverse tunneled packets that the local mobility anchor
receives from the mobile access gateway, after removing the tunnel
header MUST be routed to the destination specified in the inner
IPv6 packet header.
3.5. Mobile Router Considerations
A mobile router has two interfaces such as an ingress interface and
an egress interface according to [RFC3963]. The prefix assigned by
the DHCP prefix delegation protocol is configured to the mobile
network (i.e. ingress interface). The mobile router configures its
home address to the egress interface.
The default route of the mobile router SHOULD be the attached mobile
access gateway. The mobile router also has the connected route to
the mobile network. These routes can be statically configured at the
mobile router. On the other hand, if the mobile router needs to run
any dynamic routing protocols [RFC3963], it runs a routing protocol
by sending routing updates through its egress interface. The mobile
Wakikawa, et al. Expires October 8, 2009 [Page 14]
Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009
router is always attached to the home network in the Proxy Mobile
IPv6 specification, all the routing updates are sent to the attached
mobile access gateway. However, most routing protocols use link-
local addresses as source addresses for the routing information
messages. The mobile access gateway MUST intercept these link-local
packets and tunneled to the local mobility anchor. Since the Proxy
Mobile IPv6 [RFC-5213] prohibits routing the packets sent with the
link-local source address over the tunnel. we need to relax this
limitation for routing updates messages. This specification does not
recommend to run routing protocols on a mobile router.
Wakikawa, et al. Expires October 8, 2009 [Page 15]
Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009
4. IANA Considerations
This document requires to allocate the new requesting (R) flag in the
Mobile Network Prefix option from IANA.
Wakikawa, et al. Expires October 8, 2009 [Page 16]
Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009
5. Security Considerations
The security mechanisms specified for Proxy Mobile IPv6 protocol are
used when using the extensions defined in this document.
When supporting mobile network prefix assignment from a DHCP-PD
server, all the mobile network prefixes managed in the DHCP-PD server
must be reachable via local mobility anchor so that local mobility
anchor intercepts packets meant for a mobile network prefix and
tunnels them to the mobile router via corresponding mobile access
gateway. Moreover, all the DHCPv6 messages between a DHCP relay and
the DHCP-PD server SHOULD be securely exchanged.
Wakikawa, et al. Expires October 8, 2009 [Page 17]
Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009
6. References
6.1. Normative References
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC-3775] Johnson, D., Perkins, C., Arkko, J., "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.
[RFC-4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Mobile Node Identifier Option for Mobile IPv6", RFC 4283,
November 2005.
[RFC-5213] Gundavelli, S., et.al, "Proxy Mobile IPv6", RFC 5213,
August 2008.
[ID-DHCPPD-NEMO] R. Droms and P. Thubert, "DHCPv6 Prefix Delegation
for NEMO", draft-ietf-nemo-dhcpv6-pd-03, December 2007.
6.2. Informative References
[RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC-3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January 2001.
Wakikawa, et al. Expires October 8, 2009 [Page 18]
Internet-Draft NEMO Support for Proxy Mobile IPv6 April 2009
Authors' Addresses
Ryuji Wakikawa
Toyota ITC/KEIO U.
6-6-20 Akasaka, Minato-ku
Tokyo 107-0052
Japan
Phone: +81-3-5561-8276
Fax: +81-3-5561-8292
Email: ryuji.wakikawa@gmail.com
Sri Gundavelli
Cisco
170 West Tasman Drive
San Jose, CA 95134
USA
Email: sgundave@cisco.com
Yuankui zhao
Huawei Technologies Co.,LTD
Email: john.zhao@huawei.com
Wakikawa, et al. Expires October 8, 2009 [Page 19]
| PAFTECH AB 2003-2026 | 2026-04-24 13:30:36 |