Internet DRAFT - draft-wakikawa-netext-pmip6-nemo-support

draft-wakikawa-netext-pmip6-nemo-support






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]