[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 RFC 5454

Network Working Group                                        G. Tsirtsis
Internet-Draft                                                   V. Park
Intended status: Standards Track                                Qualcomm
Expires: May 5, 2007                                          H. Soliman
                                                              Consultant
                                                           November 2006


                         Dual Stack Mobile IPv4
                     draft-ietf-mip4-dsmipv4-01.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 May 5, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).












Tsirtsis, et al.           Expires May 5, 2007                  [Page 1]

Internet-Draft           Dual Stack Mobile IPv4            November 2006


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.


Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Goals  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Non-Goals  . . . . . . . . . . . . . . . . . . . . . . . .  5
     2.3.  Implicit and Explicit Modes  . . . . . . . . . . . . . . .  5
   3.  Extension Formats  . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  IPv6 Prefix Extension  . . . . . . . . . . . . . . . . . .  6
     3.2.  IPv6 Code Extension  . . . . . . . . . . . . . . . . . . .  7
     3.3.  IPv6 Tunneling Mode Extension  . . . . . . . . . . . . . .  8
   4.  Mobile IP Registrations  . . . . . . . . . . . . . . . . . . . 10
     4.1.  Registration Request . . . . . . . . . . . . . . . . . . . 10
     4.2.  Registration Reply . . . . . . . . . . . . . . . . . . . . 10
     4.3.  Home Agent Considerations  . . . . . . . . . . . . . . . . 11
       4.3.1.  IPv6 Packet Processing . . . . . . . . . . . . . . . . 12
       4.3.2.  Processing intercepted IPv6 Packets  . . . . . . . . . 12
       4.3.3.  IPv6 Multicast Membership Control  . . . . . . . . . . 14
     4.4.  Foreign Agent Considerations . . . . . . . . . . . . . . . 14
     4.5.  Mobile Node Considerations . . . . . . . . . . . . . . . . 15
     4.6.  Dynamic IPv6 Prefix allocation . . . . . . . . . . . . . . 16
       4.6.1.  Mobile IP Style Address Allocation . . . . . . . . . . 16
       4.6.2.  Prefix Delegation  . . . . . . . . . . . . . . . . . . 17
     4.7.  Deregistration of IPv6 Prefix  . . . . . . . . . . . . . . 17
     4.8.  Registration with a private CoA  . . . . . . . . . . . . . 17
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   6.  Changes since v00  . . . . . . . . . . . . . . . . . . . . . . 19
   7.  Aknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 20
   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
   Intellectual Property and Copyright Statements . . . . . . . . . . 23












Tsirtsis, et al.           Expires May 5, 2007                  [Page 2]

Internet-Draft           Dual Stack Mobile IPv4            November 2006


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














































Tsirtsis, et al.           Expires May 5, 2007                  [Page 3]

Internet-Draft           Dual Stack Mobile IPv4            November 2006


2.  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 with 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 any combination of IPv4 and/or IPv6 over IPv4
   tunnels.

   The aim is two-fold:

      On one hand, Mobile IPv4 with the present extensions becomes a
      powerful 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.

2.1.  Goals

   a.  The solution supports the registration of IPv6 home address(es)
       and/or prefix(s) in addition to regular IPv4 home address
       registration

   b.  The solution supports static and dynamic IPv6 home address(s)/
       prefix(s) allocations

   c.  The solution supports the above registrations with and without FA
       support






Tsirtsis, et al.           Expires May 5, 2007                  [Page 4]

Internet-Draft           Dual Stack Mobile IPv4            November 2006


2.2.  Non-Goals

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

2.3.  Implicit and Explicit Modes

   As defined in 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 a IPv6 Prefix
   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 tunneled over the mobile node to home agent
   tunnel and MUST be transparent to any foreign agent in the path.

   In the explicit mode, the mobile node includes one or more IPv6
   Prefix extensions in the Registration Request.

   The rest of this specification is primarely defining the explicit
   mode.




























Tsirtsis, et al.           Expires May 5, 2007                  [Page 5]

Internet-Draft           Dual Stack Mobile IPv4            November 2006


3.  Extension Formats

   The following extensions are defined according to this specification.

3.1.  IPv6 Prefix Extension

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

   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      |   Sub-Type    | Prefix Length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                   Mobile IPv6 Network Prefix                  +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 1: IPv6 Prefix Extension

   Type

      DSMIPv4 Extensions (skippable type range to be assigned by IANA)

   Length

      20

   Sub-Type

      1 (IPv6 Prefix)

   Prefix Length

      Indicates the prefix length of the prefix included in the Mobile
      Network IPv6 Prefix Field

   Mobile IPv6 Network Prefix





Tsirtsis, et al.           Expires May 5, 2007                  [Page 6]

Internet-Draft           Dual Stack Mobile IPv4            November 2006


      A sixteen-byte field containing the Mobile IPv6 Network Prefix

3.2.  IPv6 Code Extension

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

   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      |   Sub-Type    |     Code      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Prefix Length |    Reserved   |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
      |                                                               |
      +                                                               +
      |                                                               |
      +                   Mobile IPv6 Network Prefix                  +
      |                                                               |
      +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 2: IPv6 Code Extension

   Type

      DSMIPv4 Extensions (skippable type range to be assigned by IANA)

   Length

      22

   Sub-Type

      2 (IPv6 Prefix Acknowledgment)

   Code

      A value indicating the result of the registration request with
      respect to the IPv6 home address registration.  See below for
      currently defined Codes.

   Prefix Length




Tsirtsis, et al.           Expires May 5, 2007                  [Page 7]

Internet-Draft           Dual Stack Mobile IPv4            November 2006


      Indicates the prefix length of the prefix included in the Mobile
      Network IPv6 Prefix Field

   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

   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

      10 registration rejected, not home subnet

      11 registration rejected, Duplicate Address Detection failed

   Note that a registration reply that does not include an IPv6 code
   extension indicates that the home agent does not support IPv6
   extensions and thus has ignored such extensions in the registration
   request.

3.3.  IPv6 Tunneling Mode Extension

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

   The presence of this extension in a registration request message
   indicates that the sender supports the IPv6 extensions specified in
   this document.  By including this extension in a registration request
   the sender indicates that IPv6 traffic can be tunneled to the
   mobile'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      |    Sub-Type   |   Reserved    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Tsirtsis, et al.           Expires May 5, 2007                  [Page 8]

Internet-Draft           Dual Stack Mobile IPv4            November 2006


                  Figure 3: IPv6 Tunneling Mode Extension

   Type

      DSMIPv4 Extensions (skippable type range to be assigned by IANA)

   Length

      4

   Sub-Type

      3 (IPv6 Tunneling Mode Extension)

   Reserved

      Set to 0 by the sender, ignored by the receiver


































Tsirtsis, et al.           Expires May 5, 2007                  [Page 9]

Internet-Draft           Dual Stack Mobile IPv4            November 2006


4.  Mobile IP Registrations

4.1.  Registration Request

   A mobile node MAY include one or more IPv6 prefix extensions defined
   in this specification in a registration request.

   A mobile node MAY include exactly one IPv6 tunneling mode extension
   when it uses the collocated 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.

   A foreign agent MAY include exactly one IPv6 tunneling mode extension
   defined in the specification in a registration request when a mobile
   node registered via that foreign agent.

   When the IPv6 tunneling mode extension is used by a foreign agent it
   MUST be placed after the mobile - home authentication extensions and
   before the foreign - home authentication extension so they MUST be
   included in the computation of the foreign - home authentication
   extension when one exists.

4.2.  Registration Reply

   The mechanism described in the specification depends on skippable
   extensions.  For that reason, a registration reply that does not
   include an IPv6 code extension, in response to a registration request
   that included an IPv6 prefix extension, indicates that the home agent
   does not support IPv6 extensions and has ignored the request.

   If an IPv6 code extension is included in a registration reply then,
   the extension indicates the success or failure of the IPv6 prefix
   registration.  The IPv6 code extension does NOT affect in any way,
   the code value in the registration reply header.

   Note that a negative IPv6 code extension has the same effect with not
   including such extension at all in the sense that in both cases the
   mobile node and foreign agent must act as if the corresponding
   request of IPv6 prefix registration was rejected.  Of course, the
   inclusion of the IPv6 code extension allows the home agent to
   indicate why a given request was rejected.






Tsirtsis, et al.           Expires May 5, 2007                 [Page 10]

Internet-Draft           Dual Stack Mobile IPv4            November 2006


4.3.  Home Agent Considerations

   The dual stack home agent defined in this specification is a Mobile
   IPv4 [RFC3344] Home Agent, in that it MUST operate as defined in
   MIPv4 [RFC3344].  In addition to that the following mechanism are
   defined in this specification.

   For each IPv6 prefix extension included in a valid registration
   request, a home agent that supports this specification SHOULD include
   a corresponding IPv6 code extension in the registration reply
   message.  For each accepted IPv6 prefix the home agent MUST decide
   the tunneling mode that it is going to use and set the Code field of
   the IPv6 code extension to the appropriate value.  The omission of a
   given code extension is equivalent to the rejection of the
   corresponding IPv6 prefix extension.  The IPv6 prefix field of each
   of the IPv6 code extensions included in the registration reply MUST
   match a corresponding IPv6 prefix field of the IPv6 prefix extension
   included in the corresponding registration request message.

   If the IPv6 home address included in a IPv6 Prefix Extension is not
   an on-link IPv6 address with respect to the home agent's current
   Prefix List or a prefix it is configured to serve, the home agent
   MUST reject the IPv6 Prefix Extension and SHOULD return an IPv6 Code
   Extension with rejection code "not home subnet" in the Registration
   Reply to the mobile node.

   Else, if the home agent chooses to reject the Registration Request
   for any other reason (e.g., insufficient resources to serve another
   mobile node as a home agent), then the home agent SHOULD return a
   Registration Reply to the mobile node, in which the Code field is set
   to an appropriate value to indicate the reason for the rejection,
   according to MIPv4 [RFC3344].

   Unless this home agent already has a binding for the given IPv6 home
   address, the home agent MUST perform Duplicate Address Detection
   [draft-ietf-ipv6-rfc2462bis-08.txt] on the mobile node's home IPv6
   link before returning the Registration Reply.  This ensures that no
   other node on the home link was using the mobile node's IPv6 home
   address when the Registration Request arrived.  If this Duplicate
   Address Detection fails for the given IPv6 home address or an
   associated link local address, then the home agent MUST reject the
   IPv6 Prefix Extension and SHOULD return a Registration Reply to the
   mobile node, in which the Code field of a corresponding IPv6 Code
   Extension is set to "Duplicate Address Detection failed".  When the
   home agent sends a successful Registration Reply to the mobile node,
   with the Code field of a corresponding IPv6 Code Extension set to one
   of the "registration accepted" values, the home agent assures to the
   mobile node that its IPv6 address(es) will be kept unique by the home



Tsirtsis, et al.           Expires May 5, 2007                 [Page 11]

Internet-Draft           Dual Stack Mobile IPv4            November 2006


   agent for as long as the lifetime was granted for the binding.

   Note that for IPv6 prefixes (rather than addresses), the home agent
   does not have to perform Duplicate Address Detection.

4.3.1.  IPv6 Packet Processing

   Dual stack home agents MUST use Proxy Neighbor Discovery
   [draft-ietf-ipv6-2461bis-09.txt]on behalf of the nodes they serve.
   This allows the home agent to receive IPv6 packets addressed to the
   mobile node's registered IPv6 address(es).

   The dual stack home agent MUST act as defined in MIPv6 [RFC3775],
   Section 10.4.1. in order to intercept IPv6 packets for the mobile
   nodes it serves.

   The home agent MUST advertise reachability for the registered
   prefixes as defined in NEMO [RFC3963], section 6.3.

4.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 what state is
   defined in [RFC3344].

   - Registered IPv6 prefix(es) and prefix length(s)

   - Tunneling mode for IPv6 traffic:

      - Tunnel to IPv4 HoA and accept IPv6 tunneled from IPv4 HoA

      - Tunnel to CoA and accept IPv6 tunneled from CoA

   Even if the tunnel for IPv4 traffic terminates at a different point
   than the tunnel for IPv6 traffic (mobile node's CoA vs HoA), both
   tunnels MUST use the tunneling mechanism negotiated by the Mobile IP
   header as defined in MIPv4 [RFC3344].

   A home agent that supports this specification MUST be able to defend
   IPv4 and IPv6 packets destined to registered mobile nodes according
   to mechanisms described in MIPv4 [RFC3344] and MIPv6 [RFC3775]
   specifications.

   Tunneling mode selection for IPv6 traffic depends on the following
   parameters in a successful registration request:

   1) Registration request is received with one or more IPv6 prefix



Tsirtsis, et al.           Expires May 5, 2007                 [Page 12]

Internet-Draft           Dual Stack Mobile IPv4            November 2006


   extensions.  An IPv6 tunneling mode extension is not included.

      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.  Additionally, the home agent MUST be prepared to
      accept reverse tunneled packets from the IPv4 home address of the
      mobile encapsulating IPv6 packets sent by that mobile.

   2) Registration request is received with one or more IPv6 prefix
   extensions.  An IPv6 tunneling mode extension is included.

      All IPv6 packets destined to the registered IPv6 home address(s)
      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 encapsulating IPv6 packets sent by that
      mobile.  The home agent MAY ignore the presence of the IPv6
      tunneling mode extension and act as in case (1) above.

   Packets addressed to the mobile node's IPv6 link-local address MUST
   NOT be tunneled to the mobile node.  Instead, these packets MUST be
   discarded and the home agent SHOULD return an ICMPv6 Destination
   Unreachable, Code 3, message to the packet's Source Address (unless
   this Source Address is a multicast address).

   The home agent SHOULD check that all IPv6 packets received from the
   mobile client over a tunnel from the home address or the care-of
   address, include a source address that falls under the registered
   IPv6 prefix(es) for that mobile node.  If the source address of the
   tunnel is not the registered IPv4 care-off address or the registered
   IPv4 home addresses, the packet SHOULD be dropped.  If the source
   address of the encapsulated packet does not match any of the
   registered home addresses and/or prefixes the packet SHOULD be
   dropped.

   Interception and tunneling IPv6 multicast addressed packets on the
   home network are only done if the home agent supports multicast group
   membership control messages from the mobile node as described in the
   next section.  Multicast IPv6 packets addressed to a multicast
   address with link-local scope [RFC4291], to which the mobile node is
   subscribed, MUST NOT be tunneled to the mobile node.  These packets
   SHOULD be silently discarded (after delivering to other local
   multicast recipients).  Multicast packets addressed to a multicast
   address with a scope larger than link-local, but smaller than global
   (e.g., site- local and organization-local [RFC4291], to which the
   mobile node is subscribed, SHOULD NOT be tunneled to the mobile node.
   Multicast packets addressed with a global scope, to which the mobile
   node has successfully subscribed, MUST be tunneled to the mobile



Tsirtsis, et al.           Expires May 5, 2007                 [Page 13]

Internet-Draft           Dual Stack Mobile IPv4            November 2006


   node.

4.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 MLD [RFC2710] or MLDv2
   [RFC3810] messages between the mobile node and the home agent MUST be
   tunneled between the mobile node and the home agent, bypassing the
   foreign agent.

4.4.  Foreign Agent Considerations

   A dual stack foreign agent that supports the IPv6 extensions defined
   in this specification MUST keep track of the following IPv6 related
   state for the mobile IP clients it supports in addition to what state
   is defined in [RFC3344].

   - IPv6 Prefix(es) and Prefix Length(s)

   - Tunneling mode for IPv6 traffic:

      - accept IPv6 encapsulated in IPv4 and reverse tunnel IPv6

      - IPv6 is tunneled directly to the IPv4 HoA so the foreign agent
      will not provide encapsulation/decapsulation services for IPv6
      traffic for this mobile.

   When a foreign agent receives a registration request with IPv6 prefix
   extension(s) it has the following choices:

   1) Ignore the extension(s).  The registration request is forwarded as
   is to the home agent.

      The foreign agent SHOULD operate according to MIPv4 [RFC3344]

   2) Attach an IPv6 tunneling mode extension to the registration
   request sent to the home agent.

      The foreign agent MUST be prepared to de-capsulate and deliver
      IPv6 packets, in addition to the IPv4 packets, sent to it in the
      home agent to foreign agent tunnel for that mobile node.  The
      foreign agent MUST be prepared to receive IPv6 packets from the
      mobile node, in addition to IPv4 packets.  All IPv6 traffic MUST
      be reverse tunneled to the home agent by the foreign agent
      irrespectively from the reverse tunneling setting negotiated for
      IPv4 packets by mechanisms in [RFC3024]




Tsirtsis, et al.           Expires May 5, 2007                 [Page 14]

Internet-Draft           Dual Stack Mobile IPv4            November 2006


   If the foreign agent sets the R flag included in the mobility agent
   advertisement [RFC3344] and a mobile node uses the collocated address
   mode of operation, the foreign agent MUST NOT include an IPv6
   tunneling mode extension in the registration request messages sent
   from that mobile node.

4.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 home
   address(es) and/or prefix(es) while moving between access routers.

   The mobile node MAY include one or more IPv6 Prefix extension(s) in
   the registration request.

   In this case the mobile 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 code extensions.

      The mobile node SHOULD 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 code extensions.

      The mobile node MUST match each IPv6 code extension with one of
      the IPv6 prefix extensions earlier included in the corresponding
      registration request message.

      If a matching IPv6 code extension is not included for one or more
      of corresponding IPv6 prefix extensions included in the
      registration request message, the mobile node SHOULD assume that
      these IPv6 prefixes are rejected.

      For each matching IPv6 code extensions 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.





Tsirtsis, et al.           Expires May 5, 2007                 [Page 15]

Internet-Draft           Dual Stack Mobile IPv4            November 2006


      If the Code field is set to "1" then the mobile node MUST act as
      follows:

      - If the care-of address mode of operation is used, the mobile
      node MUST be prepared to send/receive IPv6 traffic on its
      interface natively, unless reverse tunnel has been negotiated in
      which case both IPv4 and IPv6 traffic MUST be reverse tunneled
      [RFC3024].  IPv6 traffic is reverse tunneled over the same tunnel
      used by IPv4 traffic.

      - If the collocated 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
      collocated care-of address.

   The mobile node SHOULD include exactly one IPv6 tunneling mode
   extension if it uses the collocated care-of address model and it
   wants to request that IPv6 packets are tunneled to its collocated
   care-of address.  If the mobile node uses the collocated care-of
   address model but it does not include the IPv6 tunneling mode
   extension the home agent will tunnel IPv6 traffic to the mobile
   client's home address.  The mobile node MUST NOT include an IPv6
   tunneling mode extension if it uses the care-of address mode of
   operation.  Note that if the mobile 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.

4.6.  Dynamic IPv6 Prefix allocation

4.6.1.  Mobile IP Style Address Allocation

   A mobile node may include one or more IPv6 prefix extensions with the
   IPv6 prefix field set to zero.  The mobile node MAY set the prefix
   length field of such extensions to zero or to a length of its choice
   as a hint to the home agent.  Such IPv6 prefix extensions indicate
   that the mobile client requests IPv6 address(es) and prefix(es) to be
   assigned to it by the home agent.

   A home agent receiving an IPv6 prefix extension with the IPv6 prefix
   field set to zero MAY return an IPv6 Code extension with the IPv6
   prefix field set to the IPv6 prefix allocated to the mobile node.
   The length of that prefix is at the discretion of the home agent.
   The home agent may take into account the prefix length hint if one is
   included in the IPv6 prefix extension.

   A mobile node MAY include one or more IPv6 prefix extensions with the
   IPv6 Prefix field set to ::interface_identifier, where



Tsirtsis, et al.           Expires May 5, 2007                 [Page 16]

Internet-Draft           Dual Stack Mobile IPv4            November 2006


   interface_identifier is the unique layer 2 address of the client.  In
   this case the prefix length field SHOULD be set to 128.

   The home agent MAY in this case return an IPv6 Code extension with:

      - the IPv6 prefix field set to PREFIX:: and the prefix length
      field set to the desired prefix length value.

      - the IPv6 prefix field set to PREFIX::interface_identifier and
      the prefix length field set to 128.

4.6.2.  Prefix Delegation

   An alternative way of dynamically allocating IPv6 prefixes is
   described in this section.  A dual stack mobile node MAY use Prefix
   Delegation as defined in [draft-ietf-nemo-dhcpv6-pd-01.txt] to get a
   prefix.  In that case the mobile MUST first register its IPv4 home
   address as per MIPv4 [RFC3344].  When that is done the mobile can
   generate a link local IPv6 address and use it to send DHCP messages
   according to [draft-ietf-nemo-dhcpv6-pd-01.txt].  All IPv6 messages
   required for Prefix Delegation MUST be tunneled over the IPv4 tunnel
   between the mobile and the home agent.

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

4.7.  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 address(es)
   and 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 extensions in the registration request
   message.

4.8.  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.




Tsirtsis, et al.           Expires May 5, 2007                 [Page 17]

Internet-Draft           Dual Stack Mobile IPv4            November 2006


5.  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 addresses
   prefixes and provides the same level of security for both address IP
   versions.












































Tsirtsis, et al.           Expires May 5, 2007                 [Page 18]

Internet-Draft           Dual Stack Mobile IPv4            November 2006


6.  Changes since v00

   The Home Agent Considerations section was re-written and expanded
   with a lot more details by adapting text from MIPv6 and NEMO
   specifications.

   New error codes were added to section 3.2

   Allowed for any length prefix, not just 64 and 128.

   Numerous editorial and clarification changes.








































Tsirtsis, et al.           Expires May 5, 2007                 [Page 19]

Internet-Draft           Dual Stack Mobile IPv4            November 2006


7.  Aknowledgements

   Thanks to Pat Calhoun, Paal Engelstad, Tom Hiller and Pete McCann for
   earlier work on this subject.  Thanks also to Alex Petrescu for
   suggesting the use of prefix delegation for dynamic IPv6 address
   allocation.  Special thanks also to Sri Gundavelli for his thorough
   review.












































Tsirtsis, et al.           Expires May 5, 2007                 [Page 20]

Internet-Draft           Dual Stack Mobile IPv4            November 2006


8.  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.

   [RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast
              Listener Discovery (MLD) for IPv6", RFC 2710,
              October 1999.

   [RFC2794]  Calhoun, P. and C. Perkins, "Mobile IP Network Access
              Identifier Extension for IPv4", RFC 2794, March 2000.

   [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,
              May 2003.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

   [RFC3963]  Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
              Thubert, "Network Mobility (NEMO) Basic Support Protocol",
              RFC 3963, January 2005.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.














Tsirtsis, et al.           Expires May 5, 2007                 [Page 21]

Internet-Draft           Dual Stack Mobile IPv4            November 2006


Authors' Addresses

   George Tsirtsis
   Qualcomm

   Phone: +908-947-7059
   Email: tsirtsis@qualcomm.com


   Vincent Park
   Qualcomm

   Phone: +908-947-7084
   Email: vpark@qualcomm.com


   Hesham Soliman
   Consultant

   Phone: +614-111-410-445
   Email: solimanhs@gmail.com






























Tsirtsis, et al.           Expires May 5, 2007                 [Page 22]

Internet-Draft           Dual Stack Mobile IPv4            November 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   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 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).





Tsirtsis, et al.           Expires May 5, 2007                 [Page 23]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/