GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5454

Network Working Group G. Tsirtsis Request for Comments: 5454 V. Park Category: Standards Track Qualcomm

                                                            H. Soliman
                                                  Elevate Technologies
                                                            March 2009
                       Dual-Stack Mobile IPv4

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (c) 2009 IETF Trust and the persons identified as the
 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.

Abstract

 This specification provides IPv6 extensions to the Mobile IPv4
 protocol.  The extensions allow a dual-stack node to use IPv4 and
 IPv6 home addresses as well as to move between IPv4 and dual stack
 network infrastructures.

Tsirtsis, et al. Standards Track [Page 1] RFC 5454 Dual-Stack Mobile IPv4 March 2009

Table of Contents

 1. Introduction ....................................................3
    1.1. Requirements Notation ......................................3
    1.2. Goals ......................................................3
    1.3. Non-Goals ..................................................4
    1.4. Implicit and Explicit Modes ................................4
 2. Extension Formats ...............................................4
    2.1. IPv6 Prefix Request Extension ..............................4
    2.2. IPv6 Prefix Reply Extension ................................5
    2.3. IPv6 Tunneling Mode Extension ..............................7
 3. Mobile IP Registrations .........................................8
    3.1. Registration Request .......................................8
    3.2. Registration Reply .........................................8
    3.3. Home Agent Considerations ..................................9
         3.3.1. IPv6 Reachability ..................................10
         3.3.2. Processing Intercepted IPv6 Packets ................10
         3.3.3. IPv6 Multicast Membership Control ..................12
    3.4. Foreign Agent Considerations ..............................12
    3.5. Mobile Node Considerations ................................12
    3.6. Tunneling Impacts .........................................13
    3.7. IPv6 Prefixes .............................................14
         3.7.1. Dynamic IPv6 Prefix Delegation .....................14
    3.8. Deregistration of IPv6 Prefix .............................15
    3.9. Registration with a Private CoA ...........................15
 4. Security Considerations ........................................15
 5. IANA Considerations ............................................16
 6. Acknowledgements ...............................................16
 7. References .....................................................16
    7.1. Normative References ......................................16
    7.2. Informative References ....................................17

Tsirtsis, et al. Standards Track [Page 2] RFC 5454 Dual-Stack Mobile IPv4 March 2009

1. Introduction

 Mobile IPv4 [RFC3344] allows a mobile node with an IPv4 address to
 maintain communications while moving in an IPv4 network.
 Extensions defined in this document allow a node that has IPv4 and
 IPv6 addresses [RFC2460] to maintain communications through any of
 its addresses while moving in IPv4 or dual stack networks.
 Essentially, this specification separates the Mobile IPv4 signaling
 from the IP version of the traffic it tunnels.  Mobile IPv4 with the
 present extensions remains a signaling protocol that runs over IPv4,
 and yet can set up both IPv4 and IPv6 tunnels over IPv4.
 The aim is two-fold:
    On one hand, Mobile IPv4 with the present extensions becomes a
    useful transition mechanism, allowing automated but controlled
    tunneling of IPv6 traffic over IPv4 tunnels.  Dual-stack nodes in
    dual-stack home networks can now roam to and from legacy IPv4
    networks, while IPv4 mobile nodes and networks can migrate to IPv6
    without changing mobility management, and without upgrading all
    network nodes to IPv6 at once.
    On the other hand, and more importantly, it allows dual-stack
    mobile nodes and networks to utilize a single protocol for the
    movement of both IPv4 and IPv6 stacks in the network topology.
 Note that features like Mobile IPv6 [RFC3775] style route
 optimization will not be possible with this solution as it still
 relies on Mobile IPv4 signaling, which does not provide route
 optimization.

1.1. Requirements Notation

 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 [RFC2119].

1.2. Goals

 a.  The solution supports the registration of IPv6 home prefix(es) in
     addition to regular IPv4 home address (HoA) registration.
 b.  The solution supports static and dynamic IPv6 prefix delegation.

Tsirtsis, et al. Standards Track [Page 3] RFC 5454 Dual-Stack Mobile IPv4 March 2009

1.3. Non-Goals

 a.  The solution does not provide support for IPv6 care-of address
     (CoA) registration.

1.4. Implicit and Explicit Modes

 As defined in Network Mobility (NEMO) [RFC3963], this specification
 also supports two modes of operation; the implicit mode and the
 explicit mode.
 In the implicit mode, the mobile node does not include any IPv6
 prefix request extensions in the registration request.  The home
 agent can use any mechanism (not defined in this document) to
 determine the IPv6 prefix(es) owned by the mobile node and to set up
 forwarding for these prefixes.  In this mode of operation, all
 traffic to and from the IPv6 prefixes MUST be encapsulated over the
 IPv4 tunnel between the mobile node's IPv4 home address and the IPv4
 address of the home agent, and as such, it is transparent to any
 foreign agent in the path.  This IPv4 tunnel is established by
 mechanisms that are out of the scope of this document on both the
 mobile node and home agent when operating in the implicit mode.
 In the explicit mode, IPv6 bindings are signaled explicitly.  The
 mobile node includes one or more IPv6 prefix request extensions in
 the registration request, while the home agent returns corresponding
 IPv6 prefix reply extensions to accept/reject the IPv6 bindings.
 Additionally, in the explicit mode, the mobile node (when co-located
 mode of operation is used) can indicate whether IPv6 traffic should
 be tunneled to the care-of address or the home address of the mobile
 node.
 The rest of this specification is primarily defining the explicit
 mode.

2. Extension Formats

 The following extensions are defined according to this specification.

2.1. IPv6 Prefix Request Extension

 A new skippable extension to the Mobile IPv4 registration request
 message in accordance to the short extension format of [RFC3344] is
 defined here.

Tsirtsis, et al. Standards Track [Page 4] RFC 5454 Dual-Stack Mobile IPv4 March 2009

 This extension contains a Mobile IPv6 network prefix and its prefix
 length.
     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      |   Subtype     | Prefix Length |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +                   Mobile IPv6 Network Prefix                  +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               Figure 1:  IPv6 Prefix Request Extension
 Type
    152 (Dual-Stack Mobile IPv4 (DSMIPv4) Extension)
 Length
    18
 Subtype
    1 (IPv6 Prefix Request)
 Prefix Length
    A sixteen-byte field containing the Mobile IPv6 Network Prefix;
    all insignificant (low-order) bits (beyond the Prefix Length) MUST
    be set to 0 by the originator of the option and ignored by the
    receiver.
 Mobile IPv6 Network Prefix
    A sixteen-byte field containing the Mobile IPv6 Network Prefix

2.2. IPv6 Prefix Reply Extension

 A new skippable extension to the Mobile IPv4 registration reply
 message in accordance to the short extension format of [RFC3344] is
 defined here.

Tsirtsis, et al. Standards Track [Page 5] RFC 5454 Dual-Stack Mobile IPv4 March 2009

 This extension defines a Mobile IPv6 Network Prefix and its prefix
 length, as well as a code.
     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      |   Subtype     |     Code      |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Prefix Length |    Reserved   |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
    |                                                               |
    +                                                               +
    |                                                               |
    +                   Mobile IPv6 Network Prefix                  +
    |                                                               |
    +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 Figure 2: IPv6 Prefix Reply Extension
 Type
    152 (DSMIPv4 Extension)
 Length
    20
 Subtype
    2 (IPv6 Prefix Reply)
 Code
    A value indicating the result of the registration request with
    respect to the IPv6 home prefix registration.  See below for
    currently defined Codes.
 Prefix Length
    Indicates the prefix length of the prefix included in the Mobile
    IPv6 Network Prefix field.  A value of 255 indicates that a link-
    local address is included in the Mobile IPv6 Network Prefix field.

Tsirtsis, et al. Standards Track [Page 6] RFC 5454 Dual-Stack Mobile IPv4 March 2009

 Reserved
    Set to 0 by the sender, ignored by the receiver
 Mobile IPv6 Network Prefix
    A sixteen-byte field containing the Mobile IPv6 Network Prefix;
    all insignificant (low-order) bits (beyond the Prefix Length) MUST
    be set to 0 by the originator of the option and ignored by the
    receiver.
 The following values are defined for use as a Code value in the above
 extension:
    0 registration accepted, IPv6 to be tunneled to HoA
    1 registration accepted, IPv6 to be tunneled to CoA
    8 registration rejected, reason unspecified
    9 registration rejected, administratively prohibited
 Note that a registration reply that does not include an IPv6 prefix
 reply extension, when received in response to a registration request
 carrying at least one instance of the IPv6 prefix request extension,
 indicates that the home agent does not support IPv6 extensions and
 thus has ignored such extensions in the registration request.

2.3. IPv6 Tunneling Mode Extension

 A new skippable extension to the Mobile IPv4 registration request
 message in accordance to the short extension format of [RFC3344] is
 defined here.
 By including this extension in a registration request, the sender
 indicates that IPv6 traffic can be tunneled to the mobile node's CoA.
 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      |    Subtype    |   Reserved    |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Figure 3: IPv6 Tunneling Mode Extension
 Type
    152 (DSMIPv4 Extension)

Tsirtsis, et al. Standards Track [Page 7] RFC 5454 Dual-Stack Mobile IPv4 March 2009

 Length
    2
 Subtype
    3 (IPv6 Tunneling Mode)
 Reserved
    Set to 0 by the sender, ignored by the receiver

3. Mobile IP Registrations

3.1. Registration Request

 A mobile node MAY include in a registration request one or more IPv6
 prefix request extensions defined in this specification.
 A mobile node MAY also include exactly one IPv6 tunneling mode
 extension when it uses the co-located care-of address mode of
 [RFC3344].
 When IPv6 prefix and/or IPv6 tunneling mode extensions are used by
 the mobile IP client, they MUST be placed after the registration
 request header and before the mobile -- home authentication extension
 so they MUST be included in the computation of any authentication
 extension.

3.2. Registration Reply

 The mechanism described in this specification depends on skippable
 extensions.  For that reason, a registration reply that does not
 include an IPv6 prefix reply extension, in response to a registration
 request including an IPv6 prefix request extension, indicates that
 the home agent does not support IPv6 extensions and has ignored the
 request.
 If an IPv6 prefix reply extension is included in a registration
 reply, then the extension indicates the success or failure of the
 IPv6 prefix registration.  The IPv6 prefix reply extension does not
 affect, in any way, the code value in the registration reply header
 but it is superseded by it.  In other words, if the code field in the
 registration reply header is set to a reject code, then all IPv6
 prefix request extensions are also rejected.  If the code field in
 the registration reply header, however, is set to an accept code,

Tsirtsis, et al. Standards Track [Page 8] RFC 5454 Dual-Stack Mobile IPv4 March 2009

 then an IPv6 prefix reply extension with a code field set to a reject
 code only rejects the binding for the specific IPv6 prefix indicated
 in the same extension.
 Note that a rejecting IPv6 prefix reply extension has the same effect
 as not including such an extension at all, in the sense that, in both
 cases, the mobile node must act as if the corresponding IPv6 prefix
 request extension included in the registration request was rejected.
 Of course, the inclusion of the IPv6 prefix reply extension allows
 the home agent to indicate why a given IPv6 prefix request extension
 was rejected.  A detailed description of how the mobile node handles
 different IPv6 prefix reply extension code values and the absence of
 IPv6 prefix reply extensions is given in Section 3.5.

3.3. Home Agent Considerations

 The dual-stack home agent defined in this specification is a Mobile
 IPv4 home agent in that, it MUST operate as defined in MIPv4
 [RFC3344].  In addition to that, the following mechanisms are defined
 in this specification.
 For each IPv6 prefix request extension included in a valid
 registration request, a home agent that supports this specification
 SHOULD include a corresponding IPv6 prefix reply extension in the
 registration reply message.  The home agent MUST NOT include more
 than one IPv6 prefix reply extension for the same prefix.  For each
 accepted IPv6 prefix, the home agent MUST decide the tunneling mode
 it is going to use and set the code field of the IPv6 prefix reply
 extension to the appropriate value.  The IPv6 prefix field of each of
 the IPv6 prefix reply extensions included in the registration reply
 MUST match the IPv6 prefix field of an IPv6 prefix request extension
 included in the corresponding registration request message.
 When the home agent sends a successful registration reply to the
 mobile node, with the code field of a corresponding IPv6 prefix reply
 extension set to one of the "registration accepted" values, the home
 agent indicates that the IPv6 prefix is registered for the lifetime
 granted for the binding.  It also indicates the tunneling mode used
 i.e., tunneling to home address or care-of address, based on the
 value of the code field used in the IPv6 prefix reply extension.
 Note that since only IPv6 prefixes (and not addresses) are supported
 by this specification, there is no need for Duplicate Address
 Detection.  The home agent, however, MUST check that registered
 prefixes are not overlapping so that all addresses under each
 registered prefix belong to a single mobile node at any one time.
 These prefixes MUST NOT appear as on-link to any other node (e.g.,
 via Router Advertisements).

Tsirtsis, et al. Standards Track [Page 9] RFC 5454 Dual-Stack Mobile IPv4 March 2009

3.3.1. IPv6 Reachability

 For each registered IPv6 prefix, the home agent MUST advertise its
 reachability as defined in NEMO Section 6.3 of [RFC3963].

3.3.2. Processing Intercepted IPv6 Packets

 A dual-stack home agent that supports the IPv6 extensions defined in
 this specification MUST keep track of the following IPv6 related
 state for the mobile nodes it supports, in addition to the state
 defined in [RFC3344].
  1. Registered IPv6 prefix(es) and prefix length(s).
  1. Tunneling mode for IPv6 traffic:
  1. Tunnel to IPv4 HoA and accept IPv6 tunneled from IPv4 HoA.
  1. Tunnel to CoA and accept IPv6 tunneled from CoA.
 When IPv6 traffic is encapsulated over the tunnel between the home
 agent (HA) and the mobile node's care-of address, the tunneling
 mechanism used should be the same as the mechanism negotiated by the
 Mobile IP header as defined in MIPv4 [RFC3344].  In that case, when
 IPinIP encapsulation is negotiated, IPv6 is tunneled over IPv4
 according to [RFC4213].  Generic Routing Encapsulation (GRE) also
 allows tunneling of IPv6 packets by setting the Protocol Type
 [RFC2784] field, to the appropriate payload type defined for IPv6 by
 IANA.  Minimal Encapsulation [RFC2004] cannot be used, since the
 second (inner) IP header is IPv6, which is not supported by
 [RFC2004].
 When IPv6 traffic is encapsulated over the tunnel between the HA and
 the mobile node's home address, IPv6 is always tunneled over IPv4
 according to [RFC4213].  The resulting IPv4 packet is then delivered
 just like any other IPv4 packet addressed to the IPv4 HoA (using the
 tunneling for normal IPv4 traffic, possibly going via the foreign
 agent (FA)).
 Tunneling mode selection for IPv6 traffic depends on the following
 parameters in a successful registration request:
 1)  A registration request is received with one or more IPv6 prefix
     request extensions.  An IPv6 tunneling mode extension is not
     included.

Tsirtsis, et al. Standards Track [Page 10] RFC 5454 Dual-Stack Mobile IPv4 March 2009

        All IPv6 packets destined to the registered IPv6 prefix(es)
        MUST be tunneled by the home agent to the registered IPv4 home
        address of the mobile node.  The home agent first encapsulates
        the IPv6 packet, addressing it to the mobile node's IPv4 home
        address, and then tunnels this encapsulated packet to the
        foreign agent.  This extra level of encapsulation is required
        so that IPv6 routing remains transparent to a foreign agent
        that does not support IPv6.  When received by the foreign
        agent, the unicast encapsulated packet is de-tunneled and
        delivered to the mobile node in the same way as any other
        packet.  The mobile node must decapsulate the received IPv4
        packet in order to recover the original IPv6 packet.
        Additionally, the home agent MUST be prepared to accept
        reverse-tunneled packets from the IPv4 home address of the
        mobile node encapsulating IPv6 packets sent by that mobile
        node.
 2)  A registration request is received with one or more IPv6 prefix
     request extensions.  An IPv6 tunneling mode extension is
     included.
        All IPv6 packets destined to the registered IPv6 prefix(es)
        SHOULD be tunneled by the home agent to the registered care-of
        address of the mobile node.  Additionally, the home agent
        SHOULD be prepared to accept reverse-tunneled packets from the
        care-of address of the mobile node encapsulating IPv6 packets
        sent by that mobile node.  The home agent MAY ignore the
        presence of the IPv6 tunneling mode extension and act as in
        case (1) above.
 The home agent MUST check that all inner IPv6 packets received from
 the mobile node over a tunnel with the mobile node's home address or
 the care-of address as the outer source address, include a source
 address that falls under the registered IPv6 prefix(es) for that
 mobile node.  If the source address of the outer header of a tunneled
 packet is not the registered IPv4 care-of address or the registered
 IPv4 home addresses, the packet SHOULD be dropped.  If the source
 address of the inner header of an tunneled packet does not match any
 of the registered prefixes, the packet SHOULD be dropped.
 Multicast packets addressed to a group to which the mobile node has
 successfully subscribed, MUST be tunneled to the mobile node.

Tsirtsis, et al. Standards Track [Page 11] RFC 5454 Dual-Stack Mobile IPv4 March 2009

3.3.3. IPv6 Multicast Membership Control

 IPv6 multicast membership control is provided as defined in MIPv6
 [RFC3775], Section 10.4.3.  The only clarification required for the
 purpose of this specification is that all Multicast Listener
 Discovery (MLD) [RFC2710] or MLDv2 [RFC3810] messages between the
 mobile node and the home agent MUST be tunneled over an IPv4 tunnel
 between the mobile node's IPv4 home address and the home agent's IPv4
 address, bypassing the foreign agent.  Note that if tunneling to the
 care-of address has been negotiated for other traffic, then the rest
 of the traffic continues using this tunnel.

3.4. Foreign Agent Considerations

 This specification does not affect the operation of the foreign
 agent.

3.5. Mobile Node Considerations

 A dual-stack mobile node that supports the extensions described in
 this document MAY use these extensions to register its IPv6
 prefix(es) while moving between access routers.
 The mobile node MAY include one or more IPv6 prefix request
 extension(s) in the registration request.
 In this case, the mobile node MUST take the following action
 depending on the extensions included in the registration reply it
 receives in response to the registration request:
 1)  The registration reply does not include any IPv6 prefix reply
     extensions.
        The mobile node MUST assume that the home agent does not
        support the extensions defined in this specification.  The
        mobile node SHOULD continue to operate according to MIPv4
        [RFC3344].
 2)  The registration reply includes one or more IPv6 prefix reply
     extensions.
        The mobile node MUST match each IPv6 prefix reply extension
        with one of the IPv6 prefix request extensions included
        earlier in the corresponding registration request message.

Tsirtsis, et al. Standards Track [Page 12] RFC 5454 Dual-Stack Mobile IPv4 March 2009

        If a matching IPv6 prefix reply extension is not included for
        one or more of corresponding IPv6 prefix request extensions
        included in the registration request message, the mobile node
        MUST assume that these IPv6 prefixes are rejected.
        For each matching IPv6 prefix reply extension, the mobile node
        MUST inspect the code field.  If the field is set to a
        rejection code, then the corresponding IPv6 prefix
        registration has been rejected.  If the code field is set to
        an acceptance code, then the corresponding IPv6 prefix
        registration has been accepted.
        If the code field is set to "0", then the mobile node MUST be
        prepared to send/receive IPv6 packets encapsulated in the
        bidirectional tunnel between the home agent address and the
        registered IPv4 home address of the mobile node.
        If the code field is set to "1", then the mobile node MUST act
        as follows:
  1. Assuming the co-located care-of address mode is used, the

mobile node MUST be prepared to send/receive IPv6 packets

           over the bidirectional tunnel between the home agent
           address and its co-located care-of address.  Otherwise, the
           mobile node SHOULD act as in the case where the code field
           is set to "0".
 The mobile node SHOULD include exactly one IPv6 tunneling mode
 extension if it uses the co-located care-of address model and it
 wants to request that IPv6 packets are tunneled to its co-located
 care-of address.  If the mobile node uses the co-located care-of
 address model but it does not include the IPv6 tunneling mode
 extension, the home agent will tunnel IPv6 traffic to the mobile
 node's IPv4 home address.  The mobile node MUST NOT include an IPv6
 tunneling mode extension if it uses the foreign agent care-of address
 mode of operation.  Note that if the mobile node includes an IPv6
 tunneling mode extension in this case, IPv6 packets could be tunneled
 to the FA by the HA.  The FA is then likely to drop them since it
 will not have appropriate state to process them.

3.6. Tunneling Impacts

 When IPv6 runs over an IPv4 tunnel, the IPv6 tunnel endpoints can
 treat the IPv4 tunnel as a single hop link as defined in [RFC4213].
 The two tunnel endpoints, e.g., mobile node and home agent, MUST
 configure link-local IPv6 addresses as defined in Section 3.7 of

Tsirtsis, et al. Standards Track [Page 13] RFC 5454 Dual-Stack Mobile IPv4 March 2009

 [RFC4213], while they MUST also adhere to the neighbor discovery
 requirements of the same specification, Section 3.8, and the hop
 limit requirements of Section 3.3.
 With respect to the Tunnel MTU, an implementation MUST support the
 Static Tunnel MTU approach as defined in Section 3.2 of [RFC4213].
 Implementation and use of the Dynamic Tunnel MTU method defined in
 the same section of [RFC4213] is OPTIONAL.
 To accommodate traffic that uses Explicit Congestion Notification
 (ECN), it is RECOMMENDED that the ECN and Diffserv Code Point (DSCP)
 information is copied between the inner and outer header as defined
 in [RFC3168] and [RFC2983].  It is RECOMMENDED that the full-
 functionality option defined in Section 9.1.1 of [RFC3168] be used to
 deal with ECN.

3.7. IPv6 Prefixes

 An implementation can use any number of mechanisms to allocate IPv6
 prefixes to a mobile node.  Once one or more IPv6 prefixes are
 allocated, they can be registered using the extensions and mechanism
 already described in this specification.
 How a home agent decides to accept an IPv6 prefix for a given mobile
 node is out of scope of this specification.  Local configuration or
 external authorization via an authorization system, e.g., Diameter
 [RFC3588], or other mechanisms may be used to make such
 determination.

3.7.1. Dynamic IPv6 Prefix Delegation

 A dual-stack mobile node MAY use prefix delegation as defined in
 DHCPv6 Prefix Delegation [RFC3633] to get access to IPv6 prefixes.
 In that case, if the mobile node is not directly attached to its home
 agent, the mobile node MUST first register its IPv4 home address as
 per MIPv4 [RFC3344].  When that is done, the mobile node can generate
 a link-local IPv6 address as per Section 3.7 of [RFC4213].  The
 mobile node then sends a registration request to its home agent,
 including an IPv6 prefix request extension with the prefix length
 field set to 255 and setting the Mobile IPv6 Network Prefix field to
 the locally generated link-local address.  If the registration reply
 message includes an IPv6 prefix reply extension with the code field
 set to a success code, the mobile node can use the tunnel to send and
 receive IPv6 link-local packets.  The mobile node can now send DHCPv6
 messages according to [RFC3633].  All IPv6 messages at this stage
 MUST be tunneled over the IPv4 tunnel between the mobile node's IPv4
 home address and the home agent's IPv4 address.

Tsirtsis, et al. Standards Track [Page 14] RFC 5454 Dual-Stack Mobile IPv4 March 2009

 Once prefixes are delegated, and assuming explicit mode is used, the
 mobile node SHOULD send a registration request with the appropriate
 IPv6 prefix request extensions to the home agent to register the
 delegated prefixes.

3.8. Deregistration of IPv6 Prefix

 The mobile IP registration lifetime included in the registration
 request header is valid for all the bindings created by the
 registration request, which may include bindings for IPv6 prefix(es).
 A registration request with a zero lifetime can be used to remove all
 bindings from the home agent.
 A re-registration request with non-zero lifetime can be used to
 deregister some of the registered IPv6 prefixes by not including
 corresponding IPv6 prefix request extensions in the registration
 request message.

3.9. Registration with a Private CoA

 If the care-of address is a private address, then Mobile IP NAT
 Traversal as [RFC3519] MAY be used in combination with the extensions
 described in this specification.  In that case, to transport IPv6
 packets, the next header field of the Mobile Tunnel Data message
 header [RFC3519] MUST be set to the value for IPv6.  Note that in
 that case, the encapsulation field of the UDP Tunnel Request
 Extension defined in [RFC3519] MUST be set to zero.

4. Security Considerations

 This specification operates in the security constraints and
 requirements of [RFC3344].  It extends the operations defined in
 [RFC3344] for IPv4 home addresses to cover home IPv6 prefixes and
 provides the same level of security for both IP address versions.
 Home agents MUST perform appropriate checks for reverse-tunneled IPv6
 packets similar to what is defined in [RFC3024] for IPv4 packets.
 The check defined in [RFC3024] requires that the outer header's
 source address is set to a registered care-of address for the mobile
 node and as such the same check protects from attacks whether the
 encapsulated (inner) header is IPv4 or IPv6.
 In addition to that, the home agent MUST check that the source
 address of the inner header is a registered IPv4 home address or IPv6
 prefix for this mobile node.  If that is not the case, the home agent
 SHOULD silently discard the packet and log the event as a security
 exception.

Tsirtsis, et al. Standards Track [Page 15] RFC 5454 Dual-Stack Mobile IPv4 March 2009

 Security devices should look for IPv6 packets encapsulated over IPv4
 either directly to the mobile node's care-of address or via double
 encapsulation first to the mobile node's IPv4 home address and then
 to the mobile node's care-of address.  Interactions with Mobile IPv4
 and IPsec have been covered elsewhere, for instance in [RFC5265] and
 [RFC5266].

5. IANA Considerations

 A new type number (152) for DSMIPv4 extensions has been registered
 from the space of numbers for skippable mobility extensions (i.e.,
 128-255), defined for Mobile IPv4 [RFC3344].  This registry is
 available from http://www.iana.org under "Extensions appearing in
 Mobile IP control messages".
 A new subtype space for the type number of this extension has been
 created: "DSMIPv4 Extension subtypes".  The subtype values 1, 2, and
 3 are defined in this specification, while the rest of the subtypes
 are reserved and available for allocation based on Expert Review.
 Finally, a new space for the code field of the IPv6 prefix reply
 extension has been created: "IPv6 Prefix Reply Extension Codes".
 Values 0, 1, 8, and 9 are defined in this specification.  Values 2-7
 are reserved for accept codes, and values 10-255 are reserved for
 reject codes.
 Similar to the procedures specified for Mobile IPv4 [RFC3344] number
 spaces, future allocations from the two number spaces require Expert
 Review [RFC5226].

6. Acknowledgements

 Thanks to Pat Calhoun, Paal Engelstad, Tom Hiller, and Pete McCann
 for earlier work on this subject.  Thanks also to Alex Petrescu for
 various suggestions.  Special thanks also to Sri Gundavelli and Kent
 Leung for their thorough review and suggestions.

7. References

7.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
            (IPv6) Specification", RFC 2460, December 1998.

Tsirtsis, et al. Standards Track [Page 16] RFC 5454 Dual-Stack Mobile IPv4 March 2009

 [RFC3024]  Montenegro, G., "Reverse Tunneling for Mobile IP,
            revised", RFC 3024, January 2001.
 [RFC3344]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
            August 2002.
 [RFC3519]  Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of
            Network Address Translation (NAT) Devices", RFC 3519,
            April 2003.
 [RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
            Host Configuration Protocol (DHCP) version 6", RFC 3633,
            December 2003.
 [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
            in IPv6", RFC 3775, June 2004.
 [RFC3963]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
            Thubert, "Network Mobility (NEMO) Basic Support Protocol",
            RFC 3963, January 2005.
 [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
            for IPv6 Hosts and Routers", RFC 4213, October 2005.
 [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 5226,
            May 2008.

7.2. Informative References

 [RFC2004]  Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
            October 1996.
 [RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast
            Listener Discovery (MLD) for IPv6", RFC 2710,
            October 1999.
 [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
            Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
            March 2000.
 [RFC2983]  Black, D., "Differentiated Services and Tunnels",
            RFC 2983, October 2000.
 [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
            of Explicit Congestion Notification (ECN) to IP",
            RFC 3168, September 2001.

Tsirtsis, et al. Standards Track [Page 17] RFC 5454 Dual-Stack Mobile IPv4 March 2009

 [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
            Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
 [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
            Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
 [RFC5265]  Vaarala, S. and E. Klovning, "Mobile IPv4 Traversal across
            IPsec-Based VPN Gateways", RFC 5265, June 2008.
 [RFC5266]  Devarapalli, V. and P. Eronen, "Secure Connectivity and
            Mobility Using Mobile IPv4 and IKEv2 Mobility and
            Multihoming (MOBIKE)", BCP 136, RFC 5266, June 2008.

Authors' Addresses

 George Tsirtsis
 Qualcomm
 EMail: tsirtsis@googlemail.com
 Vincent Park
 Qualcomm
 Phone: +908-947-7084
 EMail: vpark@qualcomm.com
 Hesham Soliman
 Elevate Technologies
 Phone: +614-111-410-445
 EMail: hesham@elevatemobile.com

Tsirtsis, et al. Standards Track [Page 18]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5454.txt · Last modified: 2009/03/06 01:35 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki