NETLMM WG                                                  S. Gundavelli
Internet-Draft                                                  K. Leung
Intended status: Standards Track                                   Cisco
Expires: December 20, 2007 March 7, 2008                                    V. Devarapalli
                                                         Azaire Networks
                                                            K. Chowdhury
                                                        Starent Networks
                                                                B. Patil
                                                  Nokia Siemens Networks
                                                           June 18,
                                                       September 4, 2007

                           Proxy Mobile IPv6
                   draft-ietf-netlmm-proxymip6-01.txt
                   draft-ietf-netlmm-proxymip6-02.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 December 20, 2007. March 7, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   Host based IPv6

   This specification describes a network-based mobility management
   protocol.  It is specified in called Proxy Mobile IPv6 base
   specification [RFC3775].  In that model, the mobile node and is
   responsible for doing the signaling based on Mobile IPv6
   Protocol [RFC-3775].  This protocol enables mobility support to a
   host within a domain and without requiring its home agent to enable
   session continuity as it moves between subnets. participation in any
   mobility related signaling.  The design principle in the case of host-based
   network-based mobility management protocol relies on the mobile node network
   being in control of the mobility management.  Network based mobility allows IP
   session continuity for a mobile node without its involvement in
   mobility management.  This specification describes a protocol
   solution for network based mobility management that relies on Mobile
   IPv6 signaling and reuse of home agent functionality.  A proxy
   mobility agent in the network which manages the mobility for a mobile
   node is the reason for referring to this protocol as Proxy Mobile
   IPv6.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Conventions & Terminology  . . . . . . . . . . . . . . . . . .  5
     2.1.  Conventions used in this document  . . . . . . . . . . . .  5
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Proxy Mobile IPv6 Protocol Overview  . . . . . . . . . . . . .  7  8
   4.  Proxy Mobile IPv6 Protocol Security  . . . . . . . . . . . . . 11
     4.1.  Peer Authorization Database Entries  . . . . . . . . . . . 11 12
     4.2.  Security Policy Database Entries . . . . . . . . . . . . . 12 13
   5.  Local Mobility Anchor Operation  . . . . . . . . . . . . . . . 13
     5.1.  Extensions to Binding Cache Conceptual Entry Data Structure . . 14
     5.2.  Bi-Directional Tunnel Management . . . 14
     5.2.  Supported Home Network Prefix Models . . . . . . . . . . . 14
     5.3.  Routing  Signaling Considerations . . . . . . . . . . . . . . . . . . 15
     5.4.  Local Mobility Anchor Address Discovery
       5.3.1.  Processing Binding Registrations . . . . . . . . . 16
     5.5.  Sequence Number and Time-Stamps . . 15
     5.4.  Timestamp Option for Message Ordering  . . . 16
     5.6.  Route Optimizations Considerations . . . . . . . 19
     5.5.  Routing Considerations . . . . . 17
     5.7.  Mobile Prefix Discovery Considerations . . . . . . . . . . 18
     5.8.  Signaling Considerations . . . 21
       5.5.1.  Bi-Directional Tunnel Management . . . . . . . . . . . 21
       5.5.2.  Forwarding Considerations  . . . 18
       5.8.1.  Initial Proxy Binding Registration . . . . . . . . . . 18
       5.8.2.  Extending the binding lifetime . 22
     5.6.  Local Mobility Anchor Address Discovery  . . . . . . . . . 23
     5.7.  Mobile Prefix Discovery Considerations . . 20
       5.8.3.  De-registration of the binding . . . . . . . . 23
     5.8.  Route Optimizations Considerations . . . . 20
     5.9.  Local Mobility Anchor Operational Summary . . . . . . . . 20 24
   6.  Mobile Access Gateway Operation  . . . . . . . . . . . . . . . 21 24
     6.1.  Supported Access Link Types  Extensions to Binding Update List Entry Data Structure . . 25
     6.2.  Mobile Node's Policy Profile . . . . . . . . . . . . . 21
     6.2. . . 26
     6.3.  Supported Home Network Prefix Models Access Link Types  . . . . . . . . . . . 22
     6.3. . . . . 26
     6.4.  Supported Address Configuration Models . . . . . . . . . . 22
     6.4. 26
     6.5.  Access Authentication & Mobile Node Identification . . . . 23
     6.5. 27
     6.6.  Acquiring Mobile Node's Policy Profile . . . . . . . . . . . . . . . 23
     6.6.  Conceptual Data Structures . . . . Identifier . . . . . . . . . . . . 24 27
     6.7.  Home Network Emulation . . . . . . . . . . . . . . . . . . 24
       6.7.1.  Home Network Prefix Renumbering  . . . . . . . . . . . 25 28
     6.8.  Link-Local and Global Address Uniqueness . . . . . . . . . 26 28
     6.9.  Signaling Considerations . . . . . . . . . . . . . . . . . 27
       6.9.1.  Initial Attachment and binding registration  . . . . . 27
       6.9.2.  Extending the binding lifetime . . . . . . . . . . . . 28
       6.9.3.  De-registration of the binding . . . . . . . . . . . . 28 30
     6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 28 32
       6.10.1. Transport Network  . . . . . . . . . . . . . . . . . . 29 32
       6.10.2. Tunneling & Encapsulation Modes  . . . . . . . . . . . 29 32
       6.10.3. Routing State  . . . . . . . . . . . . . . . . . . . . 30 33
       6.10.4. Local Routing  . . . . . . . . . . . . . . . . . . . . 31 34
       6.10.5. Tunnel Management  . . . . . . . . . . . . . . . . . . 31 35
       6.10.6. Forwarding Rules . . . . . . . . . . . . . . . . . . . 31 35
     6.11. Interaction with DHCP Relay Agent  . . . . . . . . . . . . 32 35
     6.12. Home Network Prefix Renumbering  . . . . . . . . . . . . . 36
     6.13. Mobile Node Detachment Detection and Resource Cleanup  . . 32
     6.13. 36
     6.14. Allowing network access to other IPv6 nodes  . . . . . . . 33 37
   7.  Mobile Node Operation  . . . . . . . . . . . . . . . . . . . . 34 37
     7.1.  Booting up in  Moving into a Proxy Mobile IPv6 Domain . . . . . . . . . 34 . 38
     7.2.  Roaming in the Proxy Mobile IPv6 Network Domain  . . . . . . . . . 35 39
     7.3.  IPv6 Host Protocol Parameters  . . . . . . . . . . . . . . 36 39
   8.  Message Formats  . . . . . . . . . . . . . . . . . . . . . . . 37 40
     8.1.  Proxy Binding Update . . . . . . . . . . . . . . . . . . . 37 41
     8.2.  Proxy Binding Acknowledgment . . . . . . . . . . . . . . . 38 42
     8.3.  Home Network Prefix Option . . . . . . . . . . . . . . . . 39 42
     8.4.  Time Stamp  Link-local Address Option  . . . . . . . . . . . . . . . . 43
     8.5.  Timestamp Option . . . . . . 40
     8.5.  Status Codes . . . . . . . . . . . . . . . 44
     8.6.  Status Values  . . . . . . . . 41 . . . . . . . . . . . . . . 45
   9.  Protocol Configuration Variables . . . . . . . . . . . . . . . 42 46
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 42 47
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 42 47
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 48
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 49
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 44 49
     13.2. Informative References . . . . . . . . . . . . . . . . . . 45 50
   Appendix A.  Proxy Mobile IPv6 interactions with AAA
                Infrastructure  . . . . . . . . . . . . . . . . . . . 46 51
   Appendix B.  Supporting Shared-Prefix Model using DHCPv6 . . . . . 46 51
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 52
   Intellectual Property and Copyright Statements . . . . . . . . . . 49 54

1.  Introduction

   Mobile IPv6 [RFC-3775] is the enabler for IPv6 mobility.  It requires
   Mobile IPv6 client functionality in the IPv6 stack of a mobile node.
   Signaling between the mobile node and home agent enables the creation
   and maintenance of a binding between the mobile node's home address
   and care-of-address.  Mobile IPv6 has been designed to be an integral
   part of the IPv6 stack in a host.  However there exist IPv6 stacks
   today that do not have Mobile IPv6 functionality and there would
   likely be IPv6 stacks without Mobile IPv6 client functionality in the
   future as well.  It is desirable to support IP mobility for all hosts
   irrespective of the presence or absence of mobile IPv6 functionality
   in the IPv6 stack.

   It is possible to support mobility for IPv6 nodes by extending Mobile
   IPv6 [RFC-3775] signaling and reusing the home agent via a proxy
   mobility agent in the network.  This approach to supporting mobility
   does not require the mobile node to be involved in the signaling
   required for mobility management.  The proxy mobility agent in the
   network performs the signaling and does the mobility management on
   behalf of the mobile node.  Because of the use and extension of
   Mobile IPv6 signaling and home agent functionality, it this protocol is
   referred to as Proxy Mobile IPv6 (PMIP6) in the context of this document. (PMIPv6).

   Network deployments which are designed to support mobility would be
   agnostic to the capability in the IPv6 stack of the nodes which it
   serves.  IP mobility for nodes which have mobile IP client
   functionality in the IPv6 stack as well as those hosts which do not,
   would be supported by enabling Proxy Mobile IPv6 protocol
   functionality in the network.  The advantages of developing a network
   based mobility protocol based on Mobile IPv6 are:

   o  Reuse of home agent functionality and the messages/format used in
      mobility signaling.  Mobile IPv6 is a mature protocol with several
      implementations that have been through interoperability testing.

   o  A common home agent would serve as the mobility agent for all
      types of IPv6 nodes.

   o  Addresses a real deployment need.

   The problem statement and the need for a network based mobility
   protocol solution has been documented in [RFC-4830].  Proxy Mobile
   IPv6 is a solution that addresses these issues and requirements.

2.  Conventions & Terminology

2.1.  Conventions used in this document

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" used in
   this document are to be interpreted as described in RFC 2119.

2.2.  Terminology

   All the general mobility related terms used in this document are to
   be interpreted as defined in the Mobile IPv6 base specification [RFC-
   3775].

   This document adopts the terms, Local Mobility Anchor (LMA) and
   Mobile Access Gateway (MAG) from the NETLMM Goals document [RFC-
   4831].  This document also provides the following context specific
   explanation to the following terms used in this document.

   Proxy Mobile IPv6 Domain (PMIPv6-Domain)

      Proxy Mobile IPv6 domain refers to the network where the mobility
      management of a mobile node is handled using Proxy Mobile IPv6
      protocol as defined in this specification.  The Proxy Mobile IPv6
      domain includes local mobility anchors and mobile access gateways
      between which security associations can be setup and authorization
      for sending Proxy Binding Updates on behalf of the mobile nodes
      can be ensured.

   Local Mobility Anchor (LMA)

      Local Mobility Anchor is the home agent for the mobile node in the
      Proxy Mobile IPv6 domain.  It is the topological anchor point for
      the mobile node's home network prefix and is the entity that
      manages the mobile node's reachability state.  It is important to
      understand that the local mobility anchor has the functional
      capabilities of a home agent as defined in Mobile IPv6 base
      specification [RFC-3775] and with the additional required
      capabilities for supporting Proxy Mobile IPv6 protocol as defined
      in this specification.

   Mobile Access Gateway (MAG)
      Mobile Access Gateway is a function that manages the mobility
      related signaling for a mobile node that is attached to its access
      link.  It is responsible for tracking the mobile node's attachment
      to the link and for signaling the mobile node's local mobility
      anchor.

   Mobile Node (MN)

      Through out this document, the term mobile node is used to refer
      to an IP node whose mobility is managed by the network.  The
      mobile node may be operating in IPv6 mode, IPv4 mode or in IPv4/
      IPv6 dual mode.  The mobile node is not required to participate in
      any mobility related signaling for achieving mobility for an IP
      address that is obtained in that local domain.  This document
      further uses explicit text when referring to a mobile node that is
      involved in mobility related signaling as per Mobile IPv6
      specification [RFC-3775].

   LMA Address (LMAA)

      The address that is configured on the interface of the local
      mobility anchor and is the transport endpoint of the tunnel
      between the local mobility anchor and the mobile access gateway.
      This is the address to where the mobile access gateway sends the
      Proxy Binding Update messages.  When supporting IPv4 traversal,
      i.e. when the network between the local mobility anchor and the
      mobile access gateway is an IPv4 network, this address will be an
      IPv4 address and will be referred to as IPv4-LMAA, as specified in
      [ID-IPV4-PMIP6].

   Proxy Care-of Address (Proxy-CoA)

      Proxy-CoA is the address configured on the interface of the mobile
      access gateway and is the transport endpoint of the tunnel between
      the local mobility anchor and the mobile access gateway.  The
      local mobility anchor views this address as the Care-of Address of
      the mobile node and registers it in the Binding Cache entry for
      that mobile node.  When the transport network between the mobile
      access gateway and the local mobility anchor is an IPv4 network
      and if the care-of address that is registered at the local
      mobility anchor is an IPv4 address, the term, IPv4-Proxy-CoA is
      used, as defined specified in [ID-IPV4-PMIP6].

   Mobile Node's Home Address (MN-HoA)
      MN-HoA is the home address of a mobile node in a Proxy Mobile IPv6
      domain.  It is an address from its home network prefix obtained by the
      a mobile node in that a Proxy Mobile IPv6 domain.  The mobile node can
      continue to use this address as long as it is attached to the
      network that is in the scope of that Proxy Mobile IPv6 domain.

   Mobile Node's Home Network Prefix (MN-HNP)

      This is the on-link IPv6 prefix that the mobile node is always sees present in the Proxy Mobile IPv6 domain.  The
      Router Advertisements that the mobile node receives on any of the
      access links in that Proxy Mobile IPv6 domain.  This home network
      prefix is topologically anchored at the mobile node's local
      mobility anchor.  The mobile node configures its interface with an
      address from this prefix.

   Mobile Node's Home Link

      This is the link on which the mobile node obtained its initial
      address configuration after it moved into that Proxy Mobile IPv6
      domain.  This is the link that conceptually follows the mobile
      node.  The network will ensure the mobile node always sees this
      link with respect to the layer-3 network configuration, on any
      access link that it attaches to in that proxy mobile IPv6 domain.

   Mobile Node Identifier (MN-Identifier)

      The identity of the a mobile node that in the Proxy Mobile IPv6 domain.
      This is presented to the network
      as part stable identifier of a mobile node that the access authentication. mobility
      entities in a Proxy Mobile IPv6 domain can always acquire and
      using which can predictably identify a mobile node.  This is
      typically an identifier such as Mobile Node NAI [RFC-4283], or any other type
      of identifier which may be specific to the access technology. [RFC-4282].

   Proxy Binding Update (PBU)

      A signaling request message sent by the a mobile access gateway to a mobile
      node's local mobility anchor for establishing a binding between
      the mobile node's MN-HoA MN-HNP and the Proxy-CoA.

   Proxy Binding Acknowledgement (PBA)

      A response message sent by a local mobility anchor in response to
      a Proxy Binding Update message that it received from a mobile
      access gateway.

3.  Proxy Mobile IPv6 Protocol Overview

   This specification describes a network-based mobility management
   protocol.  It is called Proxy Mobile IPv6 and is based on Mobile IPv6
   [RFC-3775].  This

   Proxy Mobile IPv6 protocol is intended for providing network-based
   mobility management support to a mobile node, within a restricted and
   topologically localized portion of the network and with out without requiring the
   participation of the mobile node in any mobility related signaling.

   Every mobile node that roams
   The mobility entities in a Proxy Mobile IPv6 domain, would
   typically be identified by an identifier, MN-Identifier, and using
   that identifier the network will track the mobile node's policy profile can be obtained from
   movements and will initiate the policy store. mobility signaling and setup the
   required routing state.

   The policy profile typically contains core functional entities in the
   provisioned network-based mobility service characteristics NETLMM infrastructure are the
   Local Mobility Anchor and other
   related parameters such as the mobile node's Identifier, Mobile Access Gateway.  The local
   mobility anchor address, permitted address configuration modes,
   roaming policy is responsible for maintaining the mobile node's
   reachability state and other parameters that are essential is the topological anchor point for providing the mobile
   node's home network based prefix.  While the mobile access gateway is the
   entity that performs the mobility service.

   Once management on behalf of a mobile
   node enters its Proxy Mobile IPv6 domain and performs
   access authentication, it resides on the network will ensure that access link where the mobile node is always
   anchored.  The mobile access gateway is responsible for detecting the
   mobile node's movements on its home network and can obtain its home address on any access link using any of the address configuration procedures.  In
   other words, there is a home network prefix that is assigned to a
   mobile node and conceptually that address always follows the mobile
   node, where ever it roams within that Proxy Mobile IPv6 domain.  From
   the perspective of for sending binding
   registrations to the mobile node, the entire Proxy Mobile IPv6
   domain appears as its home link or a single link. node's local mobility anchor.

               +----+                +----+
               |LMA1|                |LMA2|
               +----+                +----+
        LMAA1 -> |                      | <-- LMAA2
                 |                      |
                 \\                    //\\
                  \\                  //  \\
                   \\                //    \\
                +---\\------------- //------\\----+
               (     \\  IPv4/IPv6 //        \\    )
               (      \\  Network //          \\   )
                +------\\--------//------------\\-+
                        \\      //              \\
                         \\    //                \\
                          \\  //                  \\
              Proxy-CoA1--> |                      | <-- Proxy-CoA2
                         +----+                 +----+
                         |MAG1|-----[MN2]       |MAG2|
                         +----+    |            +----+
                           |       |               |
              MN-HoA1 -->  |     MN-HoA2           | <-- MN-HoA3
                         [MN1]                   [MN3]
                    Figure 1: Proxy Mobile IPv6 Domain

   The

   Once a mobile node enters a Proxy Mobile IPv6 scheme introduces a new function, domain and attaches to
   an access network, the mobile access gateway.  It is a function that is gateway on the that access link where network
   after identifying the mobile node is anchored and does the mobility related signaling
   on acquiring its behalf.  From the perspective of the local mobility anchor, identifier, will
   determine if the mobile access gateway node is a special element in authorized for network-based mobility
   management service.

   If the network determines that is
   authorized to send Mobile IPv6 signaling messages on behalf of other
   mobile nodes.

   When the mobile node attaches network-based mobility management
   service needs to an access link connected be offered to the that mobile access gateway, node, the network will
   ensure that the mobile node presents its identity, MN-
   Identifier, as part using any of the access authentication procedure.  After a
   successful access authentication, address configuration
   mechanisms permitted by the network, will be able to obtain an
   address from its home network prefix and move anywhere in that proxy
   mobile access gateway obtains IPv6 domain.  From the mobile node's profile from perspective of the policy store.  The mobile access
   gateway would have all the required information for it to emulate node, the
   entire proxy mobile node's home IPv6 domain appears as a single link, the network on
   ensures that the access link.  It sends Router
   Advertisement messages to the mobile node on the access link
   advertising the mobile node's home network prefix as the hosted on-
   link-prefix.

   The mobile node on receiving these Router Advertisement messages believes it is always on the access same link will attempt to configure its interface either using
   stateful or stateless address configuration modes, based on modes
   that are permitted on that access link.  At the end of a successful
   address configuration procedure, the mobile node would have
   where it obtained
   an address from its home network prefix.  If the mobile node is IPv4
   capable and if network offers IPv4 network mobility for the mobile
   node, the mobile node would have obtained an IPv4 initial address as well. configuration, even after
   changing its point of attachment in that network.

   The mobile node can may be operating in an IPv4-only mode, IPv6-only mode
   or in
   dual-mode and based dual IPv4/IPv6 mode.  Based on the services enabled for that mobile, the
   mobility what is enabled only for those address types.  Also, in the network
   between the local mobility anchor and
   for that mobile node, the mobile access gateway can node will be either able to obtain an IPv4,
   IPv6 or a private IPv4 with NAT translation devices.

   For updating the local mobility anchor about the current location of
   the mobile node, the mobile access gateway sends a dual IPv4/IPv6 addresses and move any where in that Proxy Binding
   Update message
   Mobile IPv6 domain.  However, the specific details related to the mobile node's local mobility anchor.  The
   message will have
   IPv4 addressing or IPv4 transport support is specified in the mobile node's NAI identifier option
   companion document [ID-IPV4-PMIP6].

    +-----+                +-----+                +-----+
    | MN  |                | MAG |                | LMA |
    +-----+                +-----+                +-----+
       |                      |                      |
   MN Attached                |                      |
       |                      |                      |
       |               MN Attached Event             |
       |        (Acquire MN-Id and other
   required options.  Upon accepting the Proxy Binding Update Profile)          |
       |                      |                      |
       |                      |----- PBU ----------->|
       |                      |                      |
       |                      |                  Accept PBU
       |                      |  (Allocate MN-HNP, Setup BCE and Tunnel)
       |                      |                      |
       |                      |<--------- PBA -------|
       |                      |                      |
       |                 Accept PBA                  |
       |          (Setup Tunnel and Routing)         |
       |                      |                      |
       |                      |==== Bi-Dir Tunnel ===|
       |                      |                      |
       |--- Rtr Sol --------->|                      |
       |                      |                      |
       |<------- Rtr Adv -----|                      |
       |                      |                      |
    IP Address                |                      |
   Configuration              |                      |
       |                      |                      |

          Figure 2: Mobile Node Attachment - Signaling Call Flow

   For updating the local mobility anchor about the current location of
   the mobile node, the mobile access gateway sends a Proxy Binding
   Update message to the mobile node's local mobility anchor.  Upon
   accepting this Proxy Binding Update message, the local mobility
   anchor sends a Proxy Binding Acknowledgment message including the
   mobile node's home network prefix option. prefix.  It also sets up a route for the mobile node's home network prefix over creates the binding cache
   entry and establishes a bi-directional tunnel to the mobile access
   gateway.

   The mobile access gateway on receiving this the Proxy Binding
   Acknowledgment message sets up a bi-directional tunnel to the local
   mobility anchor and adds a default route over sets up the tunnel data path for the mobile node's
   traffic.  At this point the mobile access gateway will have all the
   required information for emulating the mobile node's home link.  It
   sends Router Advertisement messages to the local
   mobility anchor.  All traffic from mobile node on the access
   link advertising the mobile node's home network prefix as the hosted
   on-link-prefix.

   The mobile node gets routed on receiving these Router Advertisement messages on
   the access link will attempt to configure its
   local mobility anchor through interface either using
   stateful or stateless address configuration modes, based on the bi-directional tunnel. modes
   that are permitted on that access link.  At this point, the end of a successful
   address configuration procedure, the mobile node will end up with an
   address from its home network prefix.

   Once the address configuration is complete, the mobile node has a
   valid address from its home network prefix, at the current point of
   attachment.  The serving mobile access gateway and the local mobility
   anchor also have proper routing states for handling the traffic sent
   to and from the mobile node using an address from its home network
   prefix.

   The local mobility anchor, being the topological anchor point for the
   mobile node's home network prefix, receives any packet packets that is are sent
   by any corresponding node to the mobile node.  Local mobility anchor
   forwards the these received packet packets to the mobile access gateway through
   the bi-directional tunnel.  The mobile access gateway on other end of
   the tunnel, after receiving the packet, removes the outer header and
   forwards the packet on the access link to the mobile node.

   The mobile access gateway typically acts as a default router on the
   access link and any packet that the mobile node sends to any
   corresponding node is received by the mobile access gateway and it
   forwards the packet to its local mobility anchor through the bi-
   directional tunnel.  The local mobility anchor on the other end of
   the tunnel, after receiving the packet removes the outer header and
   routes the packet to the destination.

   After obtaining the address configuration, if the mobile node changes

4.  Proxy Mobile IPv6 Protocol Security

   The mobile access gateway and the local mobility anchor MUST support
   and SHOULD use IPsec to protect the integrity and authenticity of the
   signaling messages.  The signaling messages, Proxy Binding Update and
   Proxy Binding Acknowledgement, exchanged between the mobile access
   gateway and the local mobility anchor are SHOULD be protected using IPsec
   [RFC-4301] and using the established security association between
   them.  The security association of the specific mobile node for which
   the signaling message is initiated is not required for protecting
   these messages.

   IPsec ESP [RFC-4303] in transport mode with mandatory integrity
   protection is SHOULD be used for protecting the signaling messages.
   Confidentiality protection of these messages is not required.

   IKEv2 is [RFC-4306] SHOULD be used to setup security associations
   between the mobile access gateway and the local mobility anchor to
   protect the Proxy Binding Update and Proxy Binding Acknowledgment
   messages.  The mobile access gateway and the local mobility anchor
   can use any of the authentication mechanisms, as specified in IKEv2,
   for mutual authentication.

   Mobile IPv6 specification [RFC-3775] requires the home agent to
   prevent a mobile node from creating security associations or creating
   binding cache entries for another mobile node's home address.  In the
   protocol described in this document, the mobile node is not involved
   in creating security associations for protecting the signaling
   messages or sending binding updates.  Therefore, this is not a
   concern.  However, the local mobility anchor MUST allow only
   authorized mobile access gateways to create binding cache entries on
   behalf of the mobile nodes.  The actual mechanism by which the local
   mobility anchor verifies if a specific mobile access gateway is
   authorized to send Proxy Binding Updates on behalf of a mobile node
   is outside the scope of this document.  One possible way this could
   be achieved is by sending a query to the policy store store, such as by using AAA
   infrastructure. AAA.

4.1.  Peer Authorization Database Entries

   The following

   This section describes PAD entries on the mobile access gateway and
   the local mobility anchor.  The PAD entries are only example
   configurations.  Note that the PAD is a logical concept and a
   particular mobile access gateway or a local mobility anchor
   implementation can implement the PAD in an any implementation specific
   manner.  The PAD state may also be distributed across various
   databases in a specific implementation.

       mobile access gateway PAD:
         - IF remote_identity = lma_identity_1
              Then authenticate (shared secret/certificate/EAP)
              and authorize CHILD_SA for remote address lma_addres_1

       local mobility anchor PAD:
         - IF remote_identity = mag_identity_1
              Then authenticate (shared secret/certificate/EAP)
              and authorize CHILD_SAs for remote address mag_address_1

   The list of authentication mechanisms in the above examples is not
   exhaustive.  There could be other credentials used for authentication
   stored in the PAD.

4.2.  Security Policy Database Entries

   The following

   This section describes the security policy entries on the mobile
   access gateway and the local mobility anchor required to protect the
   Proxy Mobile IPv6 signaling messages.  The SPD entries are only
   example configurations.  A particular mobile access gateway or a
   local mobility anchor implementation could configure different SPD
   entries as long as they provide the required security.

   In the examples shown below, the identity of the mobile access
   gateway is assumed to be mag_1, the address of the mobile access
   gateway is assumed to be mag_address_1, and the address of the local
   mobility anchor is assumed to be lma_address_1.

      mobile access gateway SPD-S:
        - IF local_address = mag_address_1 &
             remote_address = lma_address_1 &
             proto = MH & local_mh_type = BU & remote_mh_type = BAck
          Then use SA ESP transport mode
          Initiate using IDi = mag_1 to address lma_1

      local mobility anchor SPD-S:
        - IF local_address = lma_address_1 &
             remote_address = mag_address_1 &
             proto = MH & local_mh_type = BAck & remote_mh_type = BU
          Then use SA ESP transport mode

5.  Local Mobility Anchor Operation

   For supporting the Proxy Mobile IPv6 scheme protocol specified in this
   document, the Mobile IPv6 home agent entity, defined function, specified in Mobile IPv6
   specification [RFC-3775], needs some [RFC-3775] requires
   certain functional modifications and enhancements.  The local
   mobility anchor is an entity that has the functional capabilities of
   a home agent and
   with the additional required these modifications and enhanced capabilities for supporting
   Proxy Mobile IPv6 protocol is referred to as defined in this
   specification.  This the local mobility
   anchor.

   The section describes the operational details of the local mobility
   anchor.

   The base Mobile IPv6 specification [RFC-3775], defines home agent and
   the mobile node as the two functional entities.  The Proxy Mobile
   IPv6 scheme introduces a new entity, the mobile access gateway.  This
   is the entity that will participate in the mobility related
   signaling.  From the perspective of the

5.1.  Extensions to Binding Cache Entry Data Structure

   Every local mobility anchor, the anchor MUST maintain a Binding Cache Entry for
   each currently registered mobile access gateway node.  Binding Cache Entry is a special element
   conceptual data structure, described in Section 9.1 [RFC-3775].

   For supporting this specification, the network that has
   the privileges Binding Cache Entry data
   structure needs to send mobility related signaling messages on behalf
   of the mobile node.  Typically, the local mobility anchor is
   provisioned be extended with the list of mobile access gateways authorized following additional fields.

   o  A flag indicating whether or not this Binding Cache entry is
      created due to
   send a proxy registrations.

   When the local mobility anchor receives a Proxy registration.  This flag is enabled for
      Binding Update
   message from a mobile access gateway, the message Cache entries that are proxy registrations and is protected using
   the IPSec Security Association established between turned
      off for all other entries that are created due to the local mobility
   anchor and
      registrations directly sent by the mobile access gateway. node.

   o  The local mobility anchor can
   distinguish between a Proxy Binding Update message received from a
   mobile access gateway from a Binding Update message received directly
   from a identifier of the registered mobile node. node, MN-Identifier.  This distinction is important for using the
   right security association for validating the Binding Update and this
      identifier is achieved by relaxing the MUST requirement for having obtained from the Home
   Address NAI Option presence in Destination Options header and by
   introducing a new flag [RFC-4283] present in
      the received Proxy Binding Update message. request.

   o  The local
   mobility anchor as a traditional IPSec peer can use Link-local address of the SPI in mobile node on the
   IPSec header [RFC-4306] of interface
      attached to the received packet for locating access link.  This is obtained from the
   correct security association and for processing Link-local
      Address option, present in the Proxy Binding Update message in the context of the Proxy Mobile request.

   o  The IPv6 scheme.

   For protocol simplicity, home network prefix of the current specification supports registered mobile node.  The
      home network prefix of the Per-
   MN-Prefix addressing model.  In this addressing model, each mobile node is may have been statically
      configured in the mobile node's policy profile, or, it may have
      been dynamically allocated an exclusively unique by the local mobility anchor.  The IPv6
      home network prefix. prefix also includes the corresponding prefix length.

   o  The interface identifier of the bi-directional tunnel established
      between the local mobility anchor in this model and the mobile access gateway
      where the mobile node is just a topological anchor
   point currently anchored.  The tunnel interface
      identifier is acquired during the tunnel creation.

   o  The 64-bit timestamp value of the most recently accepted Proxy
      Binding Update request sent for that prefix this mobile node.  This is
      obtained from the Timestamp option, present in the request.

5.2.  Supported Home Network Prefix Models

   This specification supports Per-MN-Prefix model and does not support
   Shared-Prefix model.  As per the Per-MN-Prefix model, there will be
   an unique home network prefix assigned to each mobile node and no
   other node shares an address from that prefix.

   The mobile node's home network prefix is physically always hosted on the access
   link where the mobile node is attached. anchored.  Conceptually, the entire
   home network prefix follows the mobile node as it moves within the
   Proxy Mobile IPv6 domain.  The local mobility anchor is not required
   to perform any proxy ND operations [RFC-2461] for defending the
   mobile node's home address on the home link.  However, from the
   routing perspective, the home network prefix is topologically
   anchored on the local mobility anchor and is required to manage the binding
   cache entry gateway to that home
   network prefix.

5.3.  Signaling Considerations

5.3.1.  Processing Binding Registrations

   Upon receiving a Proxy Binding Update request from a mobile access
   gateway on behalf of the a mobile node for managing node, the local mobility session and
   also anchor MUST
   process the routing state for creating request as defined in Section 10.3 [RFC-3775], with one
   exception that this request is a proper route path for traffic
   to/from proxy binding registration request
   and hence the mobile node.

5.1.  Extensions to Binding Cache Conceptual Data Structure following additional considerations must be applied.

   o  The local mobility anchor maintains a Binding Cache entry for each
   currently registered mobile node.  Binding Cache is a conceptual data
   structure, MUST observe the rules described in
      Section 9.1 of [RFC-3775].  For supporting
   this specification, the conceptual Binding Cache entry needs to be
   extended with 9.2 [RFC-3775] when processing Mobility Headers in the following additional fields.

   o  A flag indicating whether or not this Binding Cache entry is
      created due to a proxy registration.  This flag is enabled for
      received Proxy Binding Cache entries that are proxy registrations and is turned
      off for all other entries that are direct registrations from the
      mobile node. Update request.

   o  The identifier of local mobility anchor MUST identify the mobile node, MN-Identifier.  This MN-
      Identifier is obtained node from the NAI Option
      identifier present in the NAI option of the Proxy Binding Update request [RFC-4285].

   o  A flag indicating whether or
      request.  If the NAI option is not present in the Proxy Binding Cache entry has a
      home address that is on virtual interface.  This flag is enabled,
      if
      Update request, the home prefix of local mobility anchor MUST reject the request
      and send a Proxy Binding Acknowledgement message with Status field
      set to MISSING_MN_IDENTIFIER_OPTION (Missing mobile node is configured on a virtual
      interface.  When
      identifier).

   o  If the local mobility anchor cannot identify the configured home prefix of a mobile is on a
      virtual interface, node, from
      the home agent is not required to function as a
      Neighbor Discovery proxy for NAI option present in the mobile node.

   o  The IPv6 home network prefix of request, it MUST reject the mobile node.

   o  The IPv6 Proxy
      Binding Update request and send a Proxy Binding Acknowledgement
      message with Status field set to 133 (Not home network prefix length of the agent for this
      mobile node. node).

   o  The interface id of the bi-directional tunnel between  If the local mobility anchor and determines that the mobile access gateway used node is
      not authorized for sending and
      receiving network-based mobility management service, it
      MUST reject the mobile node's traffic.

5.2.  Bi-Directional Tunnel Management request and send a Proxy Binding Acknowledgement
      message with Status field set to PROXY_REG_NOT_ENABLED (Proxy
      Registration not enabled).

   o  The bi-directional tunnel between the local mobility anchor and the
   mobile access gateway is used for routing MUST ignore the traffic check, specified in
      Section 10.3.1 [RFC-3775], related to and from the
   mobile node.  The tunnel hides the topology and enables a mobile node
   to use an IP address that is topologically anchored at presence of Home Address
      destination option in the Proxy Binding Update request.

   o  The local mobility anchor, from any attached access link anchor MUST authenticate the Proxy Binding
      Update request as described in that proxy mobile
   IPv6 domain.  The base Mobile IPv6 specification [RFC-3775], does Section 4.0.  It MUST use the tunneling scheme for routing traffic to and from the mobile that
   is using its home address.  However, there are subtle differences SPI
      in the way Proxy Mobile IPv6 uses IPSec header [RFC-4306] of the tunneling scheme.

   As in Mobile IPv4 [RFC-3344], received packet for locating
      the tunnel between security association needed for processing the Proxy Binding
      Update request.

   o  The local mobility anchor and MUST apply the mobile access gateway is typically a shared tunnel and
   can be used for routing traffic streams for different mobile nodes
   attached required policy checks,
      as explained in Section 4.0, to verify the same sender is a trusted
      mobile access gateway.  This specification
   extends that 1:1 relation between a tunnel and a binding cache entry gateway, authorized to 1:m relation, reflecting the shared nature send proxy binding
      registration requests on behalf of this mobile node.

   o  If the tunnel.

   The tunnel local mobility anchor determines that the requesting node
      is creating after accepting a not authorized to send proxy binding registration requests, it
      MUST reject the Proxy Binding Update message
   for a mobile node from request and send a mobile access gateway.  The created tunnel
   may be shared Proxy
      Binding Acknowledgement message with other mobile nodes attached Status field set to
      MAG_NOT_AUTHORIZED_FOR_PROXY_REG (Not authorized to send proxy
      registrations).

   o  If the same mobile
   access gateway and with Home Network Prefix option is not present in the Proxy
      Binding Update request, the local mobility anchor having a binding
   cache entry for those mobile nodes.  Some implementations may prefer
   to use static tunnels as supposed to creating MUST reject the
      Proxy Binding Update request and tearing them down
   on send a need basis. Proxy Binding
      Acknowledgement message with Status field set to 129
      (Administratively Prohibited).

   o  The one end point of local mobility anchor MUST apply the tunnel is considerations specified
      in Section 5.4, for processing the address configured on Sequence Number field and the
   interface of
      Timestamp option, in the Proxy Binding Update request.

   o  The local mobility anchor, LMAA.  The other end point of anchor MUST use the tunnel is identifier in the address configured on NAI
      option present in the interface of Proxy Binding Update request for performing
      the mobile
   access gateway, Proxy-CoA.  The details related to Binding Cache entry existence test.  If the supported
   encapsulation modes and transport protocols is covered in detail entry does not
      exist, the local mobility MUST consider this request as an initial
      binding registration request.

   Initial Binding Registration:

   o  If the Home Network Prefix option present in
   Section 6.10.2.

   Implementations typically use the Proxy Binding
      Update request has the value 0::/0, the local mobility anchor MUST
      allocate a software timer prefix for managing the
   tunnel lifetime mobile node and send a counter for keeping a count of all Proxy Binding
      Acknowledgement message with the mobiles
   that are sharing Home Network Prefix option
      containing the tunnel. allocated prefix value.  The timer value will be set to the
   accepted binding life-time and will be updated after each periodic
   registrations for extending specific details on
      how the lifetime.  If local mobility anchor allocates the tunnel home network prefix is shared
   for multiple mobile node's traffic, the tunnel lifetime will be set
   to
      outside the highest binding life time across all scope of this document.  The local mobility anchor
      MUST ensure the binding life time
   that allocated prefix is granted for all the mobiles sharing that tunnel.

5.3.  Routing Considerations

   This section describes how the data traffic to/from the not in use by any other mobile node
   is handled at
      node.

   o  If the local mobility anchor.

   When a local mobility anchor is serving unable to allocate a home network
      prefix for the mobile node, it MUST
   attempt to intercept packets that are sent reject the request and send a
      Proxy Binding Acknowledgement message with Status field set to any address that is 130
      (Insufficient resources).

   o  If the Home Network Prefix option present in the mobile node's home network request has a
      specific prefix address range.  The hint, the local mobility anchor before accepting
      that request, MUST advertise a connected route in to ensure the Routing
   Infrastructure for that mobile node's home network prefix or for an
   aggregated prefix with a larger scope.  This essentially enables
   routers in the IPv6 network to detect is owned by the local
      mobility anchor as and further the last-hop router for mobile node is authorized to use
      that prefix.

   When forwarding any packets that have the destination address
   matching  If the mobile node's home network node is not authorized to use that
      prefix, the local mobility anchor MUST encapsulate reject the packet request and send
      a Proxy Binding Acknowledgement message with Status field set to
      NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (Mobile node not authorized
      to use that prefix).

   o  Upon accepting the outer IPv6 header, as
   specified in Generic Packet Tunneling in IPv6 specification [RFC-
   2473].  If the negotiated encapsulation header is either IPv6-over-
   IPv4 or IPv6-over-IPv4-UDP, as specified in the companion document,
   IPv4 support for Proxy Mobile IP6 [ID-Pv4-PMIP6], the packet must be
   encapsulated and routed as specified in that specification.

   All the reverse tunneled packets that request, the local mobility anchor
   receives from MUST create
      a Binding Cache entry for the tunnel, after removing mobile node.  It must set the outer header MUST be
   routed fields
      in the Binding Cache entry to the destination specified accepted value for that binding.
      If there is a Link-local Address option present in the inner packet header.
   These routed packets will have request,
      the source address field set must be copied to the link-local address from the mobile node's home network prefix.

5.4.  Local Mobility Anchor Address Discovery

   Dynamic Home Agent Address Discovery, as explained field in Section 10.5 of
   [RFC-3775], allows a mobile node to discover all the home agents on
   its home link by sending an ICMP Home Agent Address Discovery Request
   message to
      Binding Cache entry.

   o  Upon accepting the Mobile IPv6 Home-Agents anycast address, derived from
   its home network prefix.

   In Proxy Mobile IPv6, the address of Binding Update request, the local
      mobility anchor
   configured to serve MUST establish a tunnel to the mobile node can access
      gateway, as described in [RFC-2473].  Considerations from Section
      5.5 must be discovered by applied.

   Binding Re-Registration:

   o  If the mobility
   entities requesting prefix in one or more ways.  This MAY be the Home Network Prefix option is a configured entry
      non 0::/0 value and is different from what is present in the
      currently active binding cache entry for that mobile node's policy profile, or it MAY be obtained through
   mechanisms outside node, the scope of this document.  It is important to
   note that there is little value in using DHAAD
      local mobility anchor MUST reject the request and send a Proxy
      Binding Acknowledgement message in with Status field set to 129
      (Administratively Prohibited).

   o  Upon accepting a Proxy Binding Update request for extending the current
   form
      lifetime of a currently active binding for discovering a mobile node, the
      local mobility anchor address dynamically.
   As a mobile node moves from one MUST update the existing Binding Cache entry
      for this mobile access gateway node.  Unless there exists an established tunnel
      to the another,
   the serving mobile access gateway will not predictably be able to
   locate with the same transport and
      encapsulation mode, the serving local mobility anchor for that mobile that has its
   binding cache entry for MUST create a tunnel
      to the mobile node.  Hence, this specification
   does not support Dynamic Home Agent Address Discovery protocol.

5.5.  Sequence Number access gateway, as described in [RFC-2473] and Time-Stamps for Message Ordering

   Mobile IPv6 [RFC-3775] uses also
      delete the Sequence Number field in registration
   messages as existing tunnel established with the previous mobile
      access gateway.  It MUST also send a way Proxy Binding Acknowledgment
      message to ensure the correct packet ordering.  The local
   mobility anchor and the mobile node are required to manage this
   counter over access gateway with the lifetime of a binding.

   In Proxy Mobile IPv6, Status field set to
      0 (Proxy Binding Update Accepted).

   Binding De-Registration:

   o  If the received Proxy Binding Update messages that request with the
   local mobility anchor receives on behalf lifetime
      value of 0, has a specific mobile node
   may not be from Source Address in the same mobile access gateway as IPv6 header, different
      from what is present in the previously
   received message.  It creates certain ambiguity and Proxy-CoA address field in its Binding
      Cache entry, the local mobility anchor will not be predictably order the messages.  This
   could lead to the local mobility anchor processing an older message
   from a mobile access gateway where the mobile node was previously
   attached, while ignoring the latest binding update message.

   In the Proxy Mobile IPv6, the ordering of packets has to be
   established across packets received from multiple senders.  The
   sequence number scheme as specified in [RFC-3775] will not be
   sufficient.  A global scale, such as a time stamp, can be used MAY either choose to
   ensure the correct ordering of the packets.  This document proposes ignore
      the use of request or send a Time Stamp Option, specified in Section 8.4, in all valid Proxy Binding Update messages sent by mobile access gateways.  By
   leveraging the NTP [RFC-1305] service, all Acknowledgement message
      with the entities in Proxy
   Mobile IPv6 domain will be able Status field set to synchronize their respective
   clocks.  Having a time stamp option in Proxy 0 (Proxy Binding Update messages
   will enable the local mobility anchor to predictably identify the
   latest message from a list of messages delivered in an out-of-order
   fashion.

   The Proxy Mobile IPv6 model, defined in this document requires Accepted).

   o  Upon accepting the Proxy Binding Update messages sent by the request for a mobile access gateway to
   have node,
      with the lifetime value of zero, the Time Stamp option.  The local mobility anchor processing a
   proxy registration MUST ignore the sequence number field and MUST the
   value from the Time Stamp option to establish ordering
      wait for MinDelayBeforeBCEDelete [Section 9] amount of time,
      before it deletes the
   received mobile node's Binding Update messages.  If Cache entry.  Within
      this wait period, if the local mobility anchor receives a Proxy
      Binding Update request message with an invalid Time Stamp
   Option, for the Proxy Binding Update MUST be rejected same mobile node and from a Proxy
      different mobile access gateway, with the lifetime value of
      greater than zero, and if that request is accepted, then the
      Binding
   Acknowledgement Cache entry MUST NOT be returned in which deleted, but must be updated with
      the Status field is set to
   148 (invalid time stamp option).

   In new values.  However, the absence of Time Stamp option in local mobile anchor MUST send the
      Proxy Binding Update, Acknowledgment message, immediately upon accepting
      the
   entities can fall back to Sequence Number scheme for message
   ordering, as defined in RFC-3775.  However, request.

   o  Upon accepting the specifics on how
   different mobile access gateways synchronize request, the sequence number is
   outside local mobility anchor MUST delete
      the scope of this document.

   When using mobile node's Binding Cache entry and remove the Time Stamp Option, Routing state
      for the mobile node's home network prefix.

   Constructing Proxy Binding Acknowledgement Message

   o  The local mobility anchor or when sending the Proxy Binding
      Acknowledgment message to the mobile access gateway MUST set construct
      the timestamp field to a 64-bit value
   formatted message as specified by the below.

               IPv6 header (src=LMAA, dst=Proxy-CoA)
                    Mobility header
                        -BA /*P flag is set*/
                       Mobility Options
                          - Home Network Time Protocol [RFC-1305]. Prefix Option
                          - Link-local Address Option (optional)
                          - Timestamp Option (optional)
                          - NAI Option

                Proxy Binding Acknowledgment message contents
   o  The
   low-order 32 bits Source Address field in the IPv6 header of the NTP format represent fractional seconds, and
   those bits which are not available from a time source message SHOULD
      be
   generated from a good source of randomness.

5.6.  Route Optimizations Considerations

   Mobile IPv6 route optimization, as defined in [RFC-3775], enables a
   mobile node set to communicate with a corresponding node directly using
   its care-of the destination address and further of the Return Routability procedure
   enables received Proxy Binding
      Update request.

   o  The Destination Address field in the corresponding node to have reasonable trust that IPv6 header of the
   mobile node owns both message
      SHOULD be set to the home source address and care-of address.

   In of the received Proxy Mobile IPv6 model, Binding
      Update request.

   o  If the mobile is not involved in any
   mobility related signaling and also it does not operate in Status field is set to a value greater less than 128, i.e.
      if the dual-
   address mode.  Hence, binding request was rejected, then the return routability procedure as defined prefix value in
   RFC-3775 is not applicable for the proxy model.

5.7.  Mobile Prefix Discovery Considerations

   The ICMP Mobile
      Home Network Prefix Advertisement message, described in Section
   6.8 and Section 11.4.3 of [RFC-3775], allows a home agent option MUST be set to send a
   Mobile the prefix value from
      the received Home Network Prefix Advertisement option.  For all other cases, the
      prefix value MUST be set to the allocated prefix value for that
      mobile node.

   In Proxy Mobile IPv6, the mobile node's home network prefix is hosted
   on

   o  The Link-local Address option MUST be present in the access link connected to Proxy Binding
      Acknowledgement message, if the mobile access gateway. but
   topologically anchored on same option was present in the local mobility anchor.  Since,
      corresponding Proxy Binding Update request message.  If there is
   no physical home-link
      an existing Binding Cache entry for the mobile node's home network prefix on
   the local mobility anchor and as the that mobile is always on node with the link
   where
      link-local address value of ALL_ZERO (value not set), or if there
      was no existing Binding Cache entry, then the prefix is hosted, any prefix change messages can just link-local address
      MUST be
   advertised by copied from the mobile access gateway on received Link-local Address option in the access link and thus
   there is no applicability of this message for Proxy Mobile IPv6.
   This specification does not use Mobile Prefix Discovery.

5.8.  Signaling Considerations

5.8.1.  Initial Proxy Binding Registration

   Upon receiving a
      received Proxy Binding Update message from a mobile access
   gateway on behalf of mobile node, the local mobility anchor request.  For all other cases, it
      MUST
   process be copied from the request as defined in Binding Cache entry.

   o  Considerations from Section 10, of the base Mobile IPv6
   specification [RFC-3775], with one exception that this request is a
   proxy request, the sender is not the mobile node and so the message
   has to 5.4 must be processed with applied for constructing
      the considerations explained in this
   section. Timestamp option.

   o  The local mobility anchor MUST apply the required policy checks, as
   explained identifier in Section 4.0 of this document to verify the sender is a
   trusted mobile access gateway, authorized to send Proxy Binding
   Updates requests on behalf of that mobile nodes, using its own
   identity.  The local mobility anchor must check the local/remote
   policy store to ensure NAI option MUST be copied from the requesting node is authorized to send received
      Proxy Binding Update messages.

   The local mobility anchor MUST use request.  If the MN-Identifier from Status field value is set to
      MISSING_MN_IDENTIFIER_OPTION, the NAI option of MUST NOT be present
      in the Proxy Binding Update reply message.

   o  The message for identifying SHOULD be protected by using IPsec ESP, using the
      security association existing between the mobile
   node.

   The local mobility anchor MUST ignore
      and the sequence number mobile access gateway, created either dynamically or
      statically.

5.4.  Timestamp Option for Message Ordering

   Mobile IPv6 [RFC-3775] uses the Sequence Number field in binding
   registration messages as a way for the Proxy Binding Updates requests, if home agent to process the Time-Stamp Option is
   present
   binding updates in the message.  It must also skip all order they were sent by a mobile node.  The
   home agent and the checks related mobile node are required to manage this counter
   over the lifetime of a binding.  However, in Proxy Mobile IPv6, as
   the mobile node moves from one mobile access gateway to another and
   in the absence of context transfer mechanism, the serving mobile
   access gateway will be unable to determine the sequence number that are required as per
   it needs to use in the Mobile IPv6
   specification [RFC-3775].  However, signaling messages.  Hence, the received sequence
   number MUST
   be copied and returned scheme as specified in the [RFC-3775], will be insufficient for
   Proxy Binding Acknowledgement message
   sent to Mobile IPv6.

   If the mobile access gateway.

   The local mobility anchor before accepting a Proxy Binding Update
   request containing cannot determine the Home Network Prefix Option with a specific
   prefix, MUST ensure sending order of
   the prefix is owned received binding registration messages, it may potentially
   process an older message sent by the local mobility anchor
   and further a mobile access gateway, where the
   mobile node is authorized to was previously anchored, resulting in an incorrect
   binding cache entry.

   For solving this problem, this specification RECOMMENDS the use of
   Timestamp option [Section 8.4].  The basic principle behind the use
   of timestamps in binding registration messages is that prefix.  If the
   Home Network Prefix Option has node
   generating the value 0::/0, message inserts the local mobility
   anchor current time-of-day, and the node
   receiving the message checks that this timestamp is greater than all
   previously accepted timestamps.

   Alternatively, the specification also allows the use of Sequence
   Number based scheme, as per [RFC-3775].  The sequence number MUST allocate be
   maintained on a prefix for the per mobile node basis and send a Proxy
   Binding Acknowledgement message with MUST be synchronized
   between the Home Network Prefix Option
   containing serving mobile access gateways.  However, the allocated value.  The specific
   details on how the
   local mobility anchor allocates the home network prefix is outside
   the a mobile node's sequence number is synchronized
   between different mobile access gateways is outside the scope of this
   document.

   Upon accepting a

   Using Timestamps based approach:

   o  An implementation MUST support Timestamp option.  If the Timestamp
      option is present in the received Proxy Binding Update request from a mobile access
   gateway,
      message, then the local mobility anchor must check if there exists MUST include a
   binding cache entry for that mobile node, identified using valid
      Timestamp option in the MN-
   Identifier, Proxy Binding Acknowledgment message that was created due
      it sends to a direct registration from the mobile node.  If there exists a binding cache entry with the proxy
   registration flag turned off, access gateway.

   o  All the local mobility anchor MUST NOT
   modify that entities in a Proxy Mobile IPv6 domain,
      exchanging binding state, instead it registration messages using Timestamp option
      must create have adequately synchronized time-of-day clocks.  These nodes
      SHOULD synchronize their clocks to a tentative binding
   cache entry and update the tentative binding cache entry fields of common time source, such as
      using Network Time Protocol [RFC-1305] or in any other ways
      suitable for that binding cache entry. specific deployment.

   o  Upon receiving receipt of a Proxy Binding Update request from a mobile node message with
   lifetime value set to 0, from a tunnel between itself and a trusted
   mobile access gateway, the Timestamp
      option, the local mobility anchor upon accepting that
   de-registration message, MUST forward the Binding Acknowledgement
   message in check the tunnel from where timestamp field
      for validity.  In order for it received to be considered valid, the Binding Update
   request.  It must also replace
      timestamp value contained in the binding cache entry with Timestamp option MUST be close
      enough to the
   tentative binding cache entry local mobility anchor's time-of-day clock and enable routing for the mobile
   node's home network prefix through
      timestamp MUST be greater than all previously accepted timestamps
      in the proxy mobile IPv6 tunnel.

   Upon accepting this Proxy Binding Update message, the local mobility
   anchor must create a Binding Cache entry and must set up a tunnel to
   the mobile access gateway serving the messages sent for that mobile node.  This bi-
   directional tunnel between

   o  If the Timestamp option is present in the received Proxy Binding
      Update message, the local mobility anchor and MUST ignore the mobile
   access gateway is used for routing sequence
      number field in the mobile node's traffic.

   The message.  However, it MUST copy the sequence
      number from the received Proxy Binding Acknowledgment Update message must be constructed as shown
   below.

               IPv6 header (src=LMAA, dst=Proxy-CoA)
                    Mobility header
                        -BA /*P flag is set*/
                       Mobility Options
                          - Home Network Prefix Option
                          - TimeStamp Option (optional)
                          - NAI Option to the Proxy
      Binding Acknowledgment message contents

5.8.2.  Extending Acknowledgement message.

   o  If the binding lifetime

   Upon accepting timestamp value in the received Proxy Binding Update request for extending the
   lifetime of a currently active binding, is
      valid, the local mobility anchor MUST update return the same timestamp
      value in the Timestamp option included in the lifetime for that binding and send a Proxy Binding
      Acknowledgment message that it sends to the mobile access gateway.  The Proxy
   Binding Acknowledgment message MUST be constructed as specified in
   Section 5.8.1.

5.8.3.  De-registration of

   o  If the binding

   Upon accepting timestamp value in the received Proxy Binding Update request sent with the
   lifetime value of zero, is not
      valid, the local mobility anchor MUST delete reject the
   binding from its Proxy Binding Cache
      Update and MUST send a Proxy Binding
   Acknowledgment Acknowledgement message with
      Status field set to the mobile access gateway. TIMESTAMP_MISMATCH (Timestamp mismatch).  The
      message MUST be constructed as specified in Section 6.9.1.

   The local mobility anchor MUST also remove include the prefix route over Timestamp option with the
   tunnel for that mobile node's home network prefix.

5.9.  Local Mobility Anchor Operational Summary

   o  For supporting this scheme, value set
      to the current time-of-day on the local mobility anchor MUST satisfy
      all anchor.

   Using Sequence Number based approach:

   o  If the requirements listed Timestamp option is not present in Section 8.4 of Mobile IPv6
      specification [RFC-3775] with the following considerations.

   o  For supporting the per-MN-Prefix addressing model as defined in
      this specification, received Proxy
      Binding Update request, the local mobility anchor service MUST NOT be
      tied fallback to a specific interface.
      the Sequence Number based scheme.  It SHOULD be able to accept MUST process the sequence
      number field as specified in [RFC-3775].  Also, it MUST NOT
      include the Timestamp option in the Proxy Binding Update requests sent Acknowledgment
      messages that it sends to any of the addresses configured on
      any of its interfaces.

   o  The requirement for a home agent to maintain a list of home agents
      for a mobile node's home link is not applicable for the local
      mobility anchor, when supporting Per-MN-Prefix addressing model. access gateway.

5.5.  Routing Considerations

5.5.1.  Bi-Directional Tunnel Management

   o  The local mobility anchors SHOULD drop all HoTI messages received
      for a home address that has corresponding Binding Cache entry with  A bi-directional tunnel is established between the proxy registration flag set.

   o  The local mobility
      anchor must handle and the mobile node's data
      traffic access gateway with IP-in-IP encapsulation,
      as explained described in the Routing Considerations section of this
      document.

6.  Mobile Access Gateway Operation [RFC-2473].  The Proxy Mobile IPv6 scheme specified in this document, introduces tunnel end points are the Proxy-
      CoA and LMAA.  When using IPv4 transport with a
   new functional entity, specific
      encapsulation mode, the Mobile Access Gateway (MAG).  It is end points of the
   entity that detects tunnel are the mobile node's movements IPv4-LMAA
      and initiates the
   signaling with the mobile node's local mobility anchor IPv4-Proxy-CoA, as specified in [ID-IPV4-PMIP6].

   o  The bi-directional tunnel is used for updating
   the route to routing the mobile node's home address.  In essence,
      data traffic between the mobile access gateway performs and the local
      mobility management on behalf of anchor.  The tunnel hides the mobile
   node.

   From the perspective of the local mobility anchor, the mobile access
   gateway is a special element in the network that sends Mobile IPv6
   signaling messages on behalf of topology and enables a
      mobile node, but using its own
   identity.  It is the entity that binds the mobile node's home address node to use an address on from its own home network prefix from
      any access interface.

   The link attached to the mobile access gateway has the following functional roles. gateway.

   o  Responsible for detecting  The bi-directional tunnel is established after accepting the Proxy
      Binding Update request message.  The created tunnel may be shared
      with other mobile node's attachment or
      detachment on nodes attached to the connected same mobile access link gateway
      and for initiating the
      mobility signaling with the mobile node's local mobility anchor.

   o  Emulation of the mobile node's home link on the access link.

   o  Registering the anchor having a binding state at the mobile node's local mobility
      anchor.

   o  Responsible for setting up the data path cache entry
      for enabling the mobile
      node to use an address from its home network prefix and use it
      from the access link.

   The those mobile access gateway is a function that typically runs on an
   access router.  However, implementations nodes.  Implementations MAY choose to split this
   function use static
      tunnels as supposed to dynamically creating and run it across multiple systems.  The specifics tearing them down
      on how
   that is achieved is beyond the scope of this document.

6.1.  Supported Access Link Types

   This specification supports only point-to-point access link types and
   thus it assumes that the link a need basis.

   o  The tunnel between the mobile node local mobility anchor and the mobile access
      gateway is typically a dedicated link and that the mobile node shared tunnel and the can be used for routing
      traffic streams for different mobile nodes attached to the same
      mobile access gateway are gateway.

   o  Implementations typically use a software timer for managing the only two nodes present on that link.
   The assumed properties
      tunnel lifetime and a counter for keeping a count of all the point-to-point link type
      mobile nodes that are just as
   assumed by sharing the Neighbor Discovery specification [RFC-2461] for that
   link type. tunnel.  The link is assumed to have multicast capability and the
   interfaces connecting timer value will be
      set to the link can accepted binding life-time and will be configured with a link-local
   address.

   Support updated after
      each periodic registrations for shared links or other link types extending the lifetime.  If the
      tunnel is left shared for multiple mobile nodes, the future
   work.

6.2.  Supported Home Network Prefix Models

   This specification supports Per-MN-Prefix model and does not support
   Shared-Prefix model.  As per the Per-MN-Prefix model, there tunnel lifetime
      will be a
   unique home network prefix assigned for each mobile node and no other
   host shares an address from set to the highest binding lifetime that prefix.  The prefix is always hosted
   on the access link where the granted to any
      one of those mobile node is anchored.  Conceptually, nodes sharing that tunnel.

5.5.2.  Forwarding Considerations

   Intercepting Packets Sent to the prefix follows Mobile Node's Home Network

   o  When the local mobility anchor is serving a mobile node as node, it moves within MUST
      be able to receive packets that are sent to the proxy mobile IPv6 domain.  However, from node's home
      network.  In order for it to receive those packets, it MUST
      advertise a connected route in to the routing perspective, Routing Infrastructure for
      the mobile node's home network prefix is topologically anchored on the local mobility
   anchor.

6.3.  Supported Address Configuration Models

   A mobile node in the proxy mobile IPv6 domain can configure one or
   more IPv6 addresses on its interface using Stateless or Stateful
   address autoconfiguration procedures.  The Router Advertisement
   messages sent on the access link, specify the address configuration
   methods permitted on that access link for an aggregated prefix
      with a larger scope.  This essentially enables IPv6 routers in
      that mobile node.  The
   exact semantics of network to detect the flags that are enabled, local mobility anchor as the options last-hop
      router for that are
   carried in these advertisement messages is as per prefix.

   Forwarding Packets Sent by the Neighbor
   Discovery specification [RFC-2461].  However, Mobile Node to the advertised flags Corresponding Node

   o  On receiving a packet from a corresponding node with respect the
      destination address configuration will be consistent for matching a mobile node, on any of node's home network prefix,
      the access links in local mobility anchor MUST forward the packet through the bi-
      directional tunnel setup for that proxy mobile node.  The format of the
      tunneled packet is shown below.

        IPv6
   domain.  Typically, these configuration settings will be based on header (src= LMAA, dst= Proxy-CoA  /* Tunnel Header */
           IPv6 header (src= CN, dst= MN-HNP )  /* Packet Header */
              Upper layer protocols             /* Packet Content*/
                  Figure 6: Tunneled Packets from LMA to MAG

   Forwarding Packets Sent by the
   domain wide policy or based on a policy specific Corresponding Node to each mobile node.
   This specification requires the Mobile Node

   o  All the reverse tunneled packets that all the local mobility anchor
      receives from the mobile access gateways in a
   given proxy mobile IPv6 domain MUST ensure that gateway, after removing the permitted address
   configuration procedures or tunnel
      header MUST be routed to the address configuration parameters that
   are sent destination specified in the Router Advertisements are consistent for a mobile
   node when attached to on any of the access links in inner
      packet header.  These routed packets will have the proxy mobile
   IPv6 domain.

   When stateless source address autoconfiguration is supported on the link,
      field set to the mobile node's home address.

5.6.  Local Mobility Anchor Address Discovery

   Dynamic Home Agent Address Discovery, as explained in Section 10.5
   [RFC-3775], allows a mobile node can generate one or more IPv6 addresses by combining to discover all the network prefix advertised home agents on the access
   its home link with by sending an interface
   identifier, using ICMP Home Agent Address Discovery Request
   message to the techniques described in Stateless
   Autoconfiguration specification [RFC-2462] or Mobile IPv6 Home-Agents anycast address, derived from
   its home network prefix.

   The DHAAD message in Privacy extension
   specification [RFC-3041].

   When stateful address autoconfiguration is supported on the link, the
   mobile node obtains current form cannot be used in Proxy Mobile
   IPv6 for discovering the address configuration from of the DHCPv6 server
   using DHCPv6 client protocol, as specified in DHCPv6 specification
   [RFC-3315]. mobile node's local mobility
   anchor.  In addition Proxy Mobile IPv6, the local mobility anchor will not be
   able to this, other address configuration mechanisms specific receive any messages sent to the access link between Mobile IPv6 Home-Agents
   anycast address corresponding to the mobile node and node's home network
   prefix, as the prefix is not hosted on any of its interfaces.
   Further, the mobile access gateway may also will not predictably be used for pushing the address configuration able to
   locate the
   mobile node.

6.4.  Access Authentication & Mobile Node Identification

   When a mobile node attaches to an access link connected to serving local mobility anchor that has the mobile
   access gateway, the deployed access security protocols on that link
   will ensure that node's
   binding cache entry.  Hence, this specification does not support
   Dynamic Home Agent Address Discovery protocol.

   In Proxy Mobile IPv6, the network-based mobility management service is
   offered only after authenticating and authorizing address of the local mobility anchor
   configured to serve a mobile node for
   that service.  The exact specifics on how this is achieved or can be discovered by the
   interactions between mobility
   entities in other ways.  This may be a configured entry in the mobile access gateway and the access
   security service is
   node's policy profile, or it may be obtained through mechanisms
   outside the scope of this document.  This
   specification goes with the stated assumption of having an
   established trust

5.7.  Mobile Prefix Discovery Considerations

   The ICMP Mobile Prefix Advertisement message, described in Section
   6.8 and Section 11.4.3 of [RFC-3775], allows a secured communication link between home agent to send a
   Mobile Prefix Advertisement to the mobile
   node and mobile access gateway, before the protocol operation begins.
   The specification also requires that node.

   In Proxy Mobile IPv6, the mobile node's home network prefix is hosted
   on the access gateway MUST
   be able link connected to identify the mobile node by its MN-Identifier and access gateway. but it must
   also be able to associate this identity to the sender of any IPv4 or
   IPv6 packets is
   topologically anchored on the access link.  The mobile access gateway MUST also
   be able to obtain local mobility anchor.  Since, there is
   no physical home-link for the mobile node's policy profile using home network prefix on
   the local mobility anchor and as the MN-
   Identifier.

6.5.  Mobile Node's Policy Profile

   A mobile node's policy profile contains node is always on the essential operational
   parameters that are required by the network entities for managing
   link where the
   mobile node's mobility service.  These policy profiles are stored in
   a local or a remote policy store, prefix is hosted, any prefix change messages can just
   be advertised by the mobile access gateway and on the
   local mobility anchor MUST be able to obtain a mobile node's policy
   profile using its MN-Identifier.  The policy profile may also be
   handed over to a serving mobile access gateway as part of a context
   transfer procedure during a handoff.  The exact details on how this
   achieved link and
   thus there is outside the scope no applicability of this document.  However, message for Proxy Mobile IPv6.
   Hence, this specification requires that a mobile access gateway serving does not support Mobile Prefix Discovery.

5.8.  Route Optimizations Considerations

   The Route Optimization in Mobile IPv6, as defined in [RFC-3775],
   enables a mobile node MUST have access to communicate with a corresponding node
   directly using its policy profile.

   The following are care-of address and further the mandatory fields of Return Routability
   procedure enables the corresponding node to have reasonable trust
   that the policy profile:

   o  The mobile node's identifier (MN-Identifier)

   o  The IPv6 node is reachable at both its home address of and
   care-of address.

   In Proxy Mobile IPv6, the local mobile node is not involved in any mobility anchor (LMAA)
   o  Supported address configuration procedures on the link (Stateful,
      Stateless or both)
   related signaling.  The following are mobile node uses only its home address for
   all its communication and the optional fields of Care-of address (Proxy-CoA) is not
   visible to the policy profile:

   o  The mobile node's node.  Hence, the Return Routability procedure
   as defined in Mobile IPv6 home network prefix (MN-HoA)

   o cannot be used in Proxy Mobile IPv6.

6.  Mobile Access Gateway Operation

   The Proxy Mobile IPv6 protocol described in this document, introduces
   a new functional entity, the Mobile Access Gateway (MAG).  The mobile
   access gateway is the entity that is responsible for detecting the
   mobile node's movements on its access link and sending the binding
   registration requests to the local mobility anchor.  In essence, the
   mobile access gateway performs mobility management on behalf of a
   mobile node.

   The mobile access gateway is a function that typically runs on an
   access router.  However, implementations MAY choose to split this
   function and run it across multiple systems.  The specifics on how
   that is achieved is beyond the scope of this document.

   The mobile access gateway has the following key functional roles:

   o  It is responsible for detecting the mobile node's movements on the
      access link and for initiating the mobility signaling with the
      mobile node's local mobility anchor.

   o  Emulation of the mobile node's home link on the access link by
      sending Router Advertisements with the mobile node's IPv6 home network
      prefix length

6.6.  Conceptual information.

   o  Responsible for setting up the data path for enabling the mobile
      node to configure an address from its home network prefix and use
      it from its access link.

6.1.  Extensions to Binding Update List Entry Data Structures Structure

   Every mobile access gateway MUST maintain a Binding Update List.
   Each entry in the Binding Update List for
   each currently attached represents a mobile node. node's
   mobility binding with its local mobility anchor.  The Binding Update
   List is a conceptual data structure, described in Section 11.1 of Mobile IPv6
   base specification [RFC-3775]. [RFC-
   3775].

   For supporting this specification, the conceptual Binding Update List
   entry data structure must needs be extended with the following new additional
   fields.

   o  The Identifier of the attached mobile node, MN-Identifier.

   o  The MAC address of  This
      identifier is acquired during the mobile node's connected interface. attachment to the
      access link or through mechanisms outside the scope of this
      document.

   o  The IPv6 home network prefix Link-layer address of the mobile node.  This address can be
      acquired from the received Router Solicitation messages from the
      mobile node or during the mobile node's attachment to the access
      network.

   o  The IPv6 home network prefix length of the attached mobile node.

   o  The interface identifier
      home network prefix of the point-to-point link to mobile node is acquired from the mobile
      node.
      node's local mobility anchor through the received Proxy Binding
      Acknowledgment messages.  The IPv6 home network prefix also
      includes the corresponding prefix length.

   o  The interface identifier Link-local address of the tunnel between the mobile node on the interface
      attached to the access
      gateway and link.

   o  The IPv6 address of the mobile node's local mobility anchor.

6.7.  Home Network Emulation

   One of anchor serving the key functions of a attached
      mobile access gateway node.  This address is to emulate acquired from the mobile node's home network prefix on
      policy profile.

   o  The interface identifier of the access link.  It must
   ensure, link where the mobile node believes it
      is still connected to its home
   link or on currently attached.  The interface identifier is acquired
      during the link where it obtained its address configuration after
   it moved into that proxy mobile IPv6 domain.

   After detecting new mobile node on its access link and after a
   successful node's attachment to the access authentication and authorization link.

   o  The interface identifier of the bi-directional tunnel between the
      mobile node
   for network-based node's local mobility service, anchor and the mobile access gateway MUST to
   emulate gateway.
      The tunnel interface identifier is acquired during the tunnel
      creation.

6.2.  Mobile Node's Policy Profile

   A mobile node's home link policy profile contains the essential operational
   parameters that are required by sending the Router
   Advertisements with network entities for managing the
   mobile node's home network prefix as the
   hosted on-link prefix.  The Router Advertisement MUST be sent mobility service.  These policy profiles are stored in
   response to
   a Router Solicitation message that it received from the
   mobile node.  The Router Advertisement messages MAY also be sent
   periodically, based on the interface configuration on the mobile
   access gateway.

   For emulating the mobile node's home link on the access link, the
   mobile access gateway must know the home network prefix of the mobile
   node for constructing the Router Advertisement.  Typically and as local or a
   default method, remote policy store, the mobile access gateway learns the mobile node's
   home network prefix information from the Proxy Binding
   Acknowledgement message, it received in response to the Proxy Binding
   Update message that it sent to and the mobile node's
   local mobility anchor for that mobile node.

   However, it is also possible, the mobile node's home network prefix
   information may MUST be statically configured in the able to obtain a mobile node's policy
   profile.  The policy profile or it may also be handed over to the a serving
   mobile access gateway as part of a context transfer procedure.  If procedure during
   a handoff.  The exact details on how this achieved is outside the
   scope of this document.  However, this specification requires that a
   mobile access gateway can
   predictably know the serving a mobile node's home network prefix information,
   it MAY choose to send the Router Advertisement prior node MUST have access to receiving the
   Proxy Binding Acknowledgement message from its
   policy profile.

   The following are the local mobility anchor.
   However, in mandatory fields of the event, policy profile:

   o  The mobile node's identifier (MN-Identifier)

   o  The IPv6 address of the local mobility anchor rejects (LMAA)

   o  Supported address configuration procedures on the Proxy
   Binding Update message, link (Stateful,
      Stateless or if the prefix that is received from both)

   The following are the
   local mobility anchor for optional fields of the policy profile:

   o  The mobile node's IPv6 home network prefix (MN-HNP)

6.3.  Supported Access Link Types

   This specification supports only point-to-point access link types and
   thus it assumes that the mobile node is a different prefix than
   what and the mobile access gateway previously advertised,
   are the only two nodes on the mobile access gateway MUST withdraw link.  The link is assumed to
   have multicast capability.

6.4.  Supported Address Configuration Models

   A mobile node in the prefix by sending a Proxy Mobile IPv6 domain can configure one or
   more IPv6 addresses on its interface using Stateless or Stateful
   address autoconfiguration procedures.  The Router Advertisement message with zero lifetime for
   messages sent on the prior advertised
   prefix.

   If access link, specify the address configuration
   methods permitted on that access link connecting the for that mobile access gateway and node.  However,
   the
   mobile node is a point-to-point link, advertised flags with respect the Router Advertisements
   advertising address configuration will be
   consistent for a specific home network prefix is received only by the
   respective mobile node and hence there is clearly node, on any of the access links in that
   Proxy Mobile IPv6 domain.  Typically, these configuration settings
   will be based on the domain wide policy or based on a unique link for policy specific
   to each mobile node that node.

   When stateless address autoconfiguration is attached to that mobile access gateway.

6.7.1.  Home Network Prefix Renumbering

   If the mobile node's home network prefix gets renumbered or becomes
   invalid during supported on the middle of a mobility session, link,
   the mobile access
   gateway MUST withdraw node can generate one or more IPv6 addresses by combining
   the network prefix by sending a Router Advertisement advertised on the access link with zero prefix lifetime for an interface
   identifier, using the mobile node's home
   network prefix.  Also, techniques described in Stateless
   Autoconfiguration specification [RFC-2462] or as per Privacy
   extension specification [RFC-3041].

   When stateful address autoconfiguration is supported on the local mobility anchor and link, the
   mobile
   access gateway MUST delete node can obtain the routing state for that prefix.
   However, address configuration from the DHCPv6
   server using DHCPv6 client protocol, as specified in DHCPv6
   specification [RFC-3315].

   Additionally, other address configuration mechanisms specific details on how the local mobility anchor
   notifies to the mobile
   access gateway is outside link between the scope of this
   document.

6.8.  Link-Local and Global Address Uniqueness

   A mobile node in and the proxy mobile IPv6 domain, as it moves from one mobile access gateway to may
   also be used for pushing the other, it will continue address configuration to detect its
   home network and thus making the node believe it is still on the same
   link.  Every time the mobile
   node.

6.5.  Access Authentication & Mobile Node Identification

   When a mobile node attaches to a new link, the event
   related an access link connected to the interface state change, will trigger the mobile node
   to perform DAD operation
   access gateway, the deployed access security protocols on that link
   SHOULD ensure that the link-local network-based mobility management service is
   offered only after authenticating and global addresses.
   However, if authorizing the mobile node for
   that service.  The exact specifics on how this is DNAv6 enabled, as specified in [ID-DNAV6], it
   may not detect achieved or the link change due to DNAv6 optimizations and hence
   it will not trigger
   interactions between the duplicate address detection (DAD) procedure
   for establishing mobile access gateway and the link-local address uniqueness on that new link.
   Further, if access
   security service is outside the mobile node uses an interface identifier that is not
   based on EUI-64 identifier, such as specified in IPv6 Stateless
   Autoconfiguration scope of this document.  This
   specification [RFC-2462], there is a possibility, goes with the odds of 1 to billion, stated assumption of a link-local address collision having an
   established trust between the two neighbors, the mobile node and the mobile access
   gateway.

   One of gateway,
   before the workarounds for this issue is to set protocol operation begins.

6.6.  Acquiring Mobile Node's Identifier

   All the DNAv6
   configuration parameter, DNASameLinkDADFlag network entities in a Proxy Mobile IPv6 domain MUST be able
   to TRUE identify a mobile node, using its MN-Identifier.  This identifier
   MUST be stable across the Proxy Mobile IPv6 domain and that will
   force the mobile node entities
   must be able to redo DAD operation every time use this identifier in the interface
   comes up, even when DNAv6 does detect a link change .

   However, signaling messages.
   Typically, this issues will not impact point-to-point links based on
   PPP session.  Each time identifier is obtained as part of the access
   authentication or through other means as specified below.

   o  The identifier of the mobile node moves and attaches to a new that the mobile access gateway, either the PPP session [RFC-1661] is
   reestablished or the PPP session may be moved gateway
      obtains as part of context
   transfer procedures between the old access authentication or from the notified
      network attachment event, can be a temporary identifier and this
      identifier may also change at each re-authentication.  However,
      the new mobile access
   gateway.

   When gateway MUST be able to authenticate the mobile
      node tries based on this identifier and MUST be able to establish a PPP session with obtain the mobile
   access gateway, MN-
      Identifier from the PPP goes through policy store, such as from the Network layer Protocol phase
   and the IPv6 Control Protocol, IPCP6 [RFC-2472] gets triggered.  Both
   the PPP peers negotiate a unique identifier using Interface-
   Identifier option in IPV6CP and the negotiated identifier is used for
   generating a unique link-local address on RADIUS
      attribute, Chargeable-User-Identifier.

   o  The MN-Identifier that link.  Now, if the
   mobile node moves policy store delivers to a new the mobile
      access gateway, gateway MAY NOT be the PPP session
   gets torn down with true identifier of the old mobile node.
      However, the mobility access gateway and a new PPP
   session gets established MUST be able to use this
      identifier in the signaling messages exchanged with the new local
      mobility anchor.

   o  The mobile access gateway, and the
   mobile node obtains a new link-local address.  So, even if the mobile
   node is DNAv6 capable, gateway MUST be able identify the mobile node always configures a new link-
   local address when ever by
      its MN-Identifier and it moves MUST be able to a new link.

   If the PPP session state is moved associate this identity
      to the new mobile access gateway,
   as part sender of context transfer procedures that are in place, there will
   not be any change to IPv4 or IPv6 packets on the interface identifiers access link.

6.7.  Home Network Emulation

   One of the two nodes on
   that point-to-point change.  The whole link is moved to the new key functions of a mobile access gateway and there will not be any need for establishing
   link-local address uniqueness on that link.

   This issue is not relevant to emulate the
   mobile node's global address.
   Since, there is a unique home network prefix for each mobile node, on the uniqueness for access link.  It must ensure, the
   mobile node's global address node believes it is ensured still connected to its home link or on the
   access link.

6.9.  Signaling Considerations

6.9.1.  Initial Attachment and binding registration

   After detecting a new mobile node on its access
   link where it obtained its initial address configuration after a
   successful it
   moved into that Proxy Mobile IPv6 domain.

   For emulating the mobile node's home link on the access authentication and authorization, link, the
   mobile access gateway MUST send a Proxy Binding Update message must be able to send Router Advertisements
   advertising the mobile node's
   local mobility anchor.

   The Proxy Binding Update message must be constructed as shown below.

               IPv6 header (src=Proxy-CoA, dst=LMAA)
                    Mobility header
                        -BU /*P flag is set*/
                       Mobility Options
                          - Home Network Prefix Option*
                          - TimeStamp Option (optional)
                          - NAI Option

   *Home Network Prefix option may contain 0::/0 or a specific prefix.

                   Proxy Binding Update message contents

   The Proxy Binding Update message that home network prefix and other address
   configuration parameters consistent with its home link properties.

   Typically, the mobile access gateway sends
   to learns the mobile node's local mobility anchor MUST have home
   network prefix information from the NAI option,
   identifying received Proxy Binding
   Acknowledgement message or it may be obtained from the mobile node, the Home Network Prefix option and
   optionally the Time Stamp option SHOULD be present.  The Time Stamp
   option is not required if node's
   policy profile.  However, the mobile access gateway can SHOULD send a valid
   sequence number that matches the sequence number maintained by
   Router Advertisements advertising the
   local mobility anchor for that mobile node in its binding cache
   entry.  The message MUST be protected by using IPsec ESP, using node's home network
   prefix only after successfully completing the
   security association existing between binding registration
   with the mobile node's local mobility anchor anchor.

6.8.  Link-Local and Global Address Uniqueness

   A mobile node in the mobile access gateway, created either dynamically or statically.

   If the Proxy Mobile IPv6 domain, as it moves from one
   mobile access gateway learns to the mobile node's other, it will continue to detect its
   home network
   prefix either from its policy store or from other means, and thus making it believe it is still on the same link.
   Every time the mobile
   access gateway MAY choose node attaches to specify a new link, the same in event related
   to the Home Network
   Prefix option for requesting interface state change, will trigger the local mobility anchor mobile node to register
   that prefix.  If
   perform DAD operation on the specified value link-local and global addresses.
   However, if the mobile node is 0::/0, then DNAv6 enabled, as specified in [ID-
   DNAV6], it may not detect the local
   mobility anchor will allocate a prefix link change due to DNAv6 optimizations
   and may not trigger the duplicate address detection (DAD) procedure
   for establishing the link-local address uniqueness on that new link.
   Further, if the mobile node.

   After receiving node uses an interface identifier that is not
   based on EUI-64 identifier, such as specified in IPv6 Stateless
   Autoconfiguration specification [RFC-2462], there is a Proxy Binding Acknowledgment possibility,
   with the status code
   indicating the acceptance odds of the Proxy Binding Update, the mobile
   access gateway MUST setup a tunnel 1 to billion, of a link-local address collision
   between the mobile node's local
   mobility anchor, as explained in section 6.10.  The mobile two neighbors on that access
   gateway MUST also add a policy route link.

   One of the workarounds for tunneling all this issue is to set the packets DNAv6
   configuration parameter, DNASameLinkDADFlag to TRUE and that it receives from will
   force the mobile node to its local mobility anchor.

   If the local mobility anchor rejects redo DAD operation every time the Proxy Binding Update
   message, the mobile access gateways MUST NOT advertise the mobile
   node's home prefix interface
   comes up, even when DNAv6 does detect a link change .

   However, this issues will not impact point-to-point links based on
   PPP session.  Each time the access link mobile node moves and there by denying mobility
   service attaches to the a new
   mobile node.

6.9.2.  Extending access gateway, either the binding lifetime

   For extending PPP session [RFC-1661] is
   reestablished or the lifetime PPP session may be moved as part of a currently existing binding at context
   transfer procedures between the
   local mobility, old and the new mobile access gateway MUST send
   gateway.

   When the mobile node tries to establish a Proxy Binding
   Update message PPP session with a specific lifetime.  The message MUST be
   constructed as specified in Section 6.9.1.

6.9.3.  De-registration of the binding

   At any point, the mobile
   access gateway detects gateway, the PPP goes through the Network layer Protocol phase
   and the IPv6 Control Protocol, IPCP6 [RFC-2472] gets triggered.  Both
   the PPP peers negotiate a unique identifier using Interface-
   Identifier option in IPV6CP and the negotiated identifier is used for
   generating a unique link-local address on that link.  Now, if the
   mobile node
   has moved away from its access link, it MUST send a Proxy Binding
   Update message moves to the a new mobile node's local mobility anchor access gateway, the PPP session
   gets torn down with the
   lifetime value set to zero.  The message MUST be constructed as
   specified in Section 6.9.1.

   The old mobile access gateway MUST also remove the default route over and a new PPP
   session gets established with the
   tunnel for that new mobile node access gateway, and delete the Binding Update List for
   that
   mobile node, either upon receiving an Proxy Binding
   Acknowledgment message from node obtains a new link-local address.  So, even if the mobile
   node is DNAv6 capable, the mobile node always configures a new link-
   local mobility anchor or after address when ever it moves to a
   certain timeout waiting for new link.

   If the acknowledgment message.

6.10.  Routing Considerations

   This section describes how PPP session state is moved to the new mobile access gateway handles gateway,
   as part of context transfer procedures that are in place, there will
   not be any change to the
   traffic to/from interface identifiers of the mobile node two nodes on
   that point-to-point change.  The whole link is attached moved to one of its access
   interface.

                 Proxy-CoA                   LMAA
                    |                          |
    +--+          +---+                      +---+          +--+
    |MN|----------|MAG|======================|LMA|----------|CN|
    +--+          +---+                      +---+          +--+
                            IPv6 Tunnel

6.10.1.  Transport Network

   The transport network between the local mobility anchor and the new
   mobile access can gateway and there will not be either an IPv6 or IPv4 network.  However, any need for establishing
   link-local address uniqueness on that link.

   Alternatively, this specification only deals with the scenario where allows the transport
   network between mobile access gateway to
   upload the mobility entities is IPv6-only and requires
   reachability between mobile node's link-local address to the local mobility
   anchor and using the Link-local Address option, exchanged in the binding
   registration messages.  The mobile access gateway over IPv6 transport.  Just as in Mobile IPv6 specification
   [RFC-3775], can learn the negotiated tunnel transport between
   mobile node's link-local address, by snooping the DAD messages sent
   by the mobile node for establishing the link-local address uniqueness
   on the access link.  Subsequently, at each handoff, the mobile access
   gateway can obtain this address from the local mobility anchor and
   can change its own link-local address, if it detects an address
   collision.

   This issue is not relevant to the mobile access gateway is IPv6, by default.
   The companion document, IPv4 support for Proxy Mobile IPv6 [IPv4-
   PMIP6-SPEC] specifies the required extensions for negotiating IPv4
   tunneling mechanism and a specific encapsulation mode for supporting
   this protocol operation over IPv4 transport network.

6.10.2.  Tunneling & Encapsulation Modes

   The IPv6 address that node's global address.
   Since, there is a mobile node uses from its unique home network prefix for each mobile node,
   the uniqueness for the mobile node's global address is topologically anchored at assured on the local mobility anchor.  For
   access link.

6.9.  Signaling Considerations

   Initial Attachment and binding registration

   o  After detecting a new mobile node to use this address from an on its access network attached to a link, the mobile
      access gateway, proper tunneling techniques have gateway MUST send a Proxy Binding Update message to be in place.
   Tunneling hides the network topology and allows the
      mobile node's
   IPv6 datagrams local mobility anchor.

   o  The Proxy Binding Update message that the mobile access gateway
      sends to be encapsulated as a payload of another IPv6 packet
   and be routed between the mobile node's local mobility anchor MUST have the NAI
      option, identifying the mobile node, the Home Network Prefix
      option and optionally the Timestamp option or a valid sequence
      number.

   o  If the mobile access
   gateway.  The Mobile IPv6 base specification [RFC-3775] defines the
   use of IPv6-over-IPv6 tunneling, between gateway learns the mobile node's home agent and network
      prefix either from its policy store or from other means, the
      mobile node and this specification extends the use of access gateway MAY choose to specify the same
   tunneling mechanism between in the Home
      Network Prefix option for requesting the local mobility anchor and to
      allocate that prefix.  If the mobile
   access gateway.

   On most operating systems, tunnels are implemented as a virtual
   point-to-point interface.  The source and the destination address of
   the two end points of this virtual interface along with the
   encapsulation mode are specified for this virtual interface.  Any
   packet that value is routed over 0::/0, then the
      local mobility anchor will consider this interface, get encapsulated as a request for prefix
      allocation.

   o  If the mobile access gateway receives a Proxy Binding
      Acknowledgment with the
   outer header and Status field value set to 0 (Proxy Binding
      Update accepted), the addresses as specified mobile access gateway MUST create Binding
      Update List entry for that point to point
   tunnel interface.  For creating the mobile node and must setup a point to point tunnel to any
      the mobile node's local mobility anchor, the as explained in section
      6.10.  The mobile access gateway may implement MUST also add a tunnel
   interface with policy route for
      tunneling all the source address field set packets that it receives from the mobile node to
      its Proxy-CoA address
   and local mobility anchor.

   o  If the destination address field set to mobile access gateway receives a Proxy Binding
      Acknowledgment with the LMA address.

   The following are Status field value greater than 128
      (binding request is rejected), the supported packet encapsulation modes that can
   be used by mobile access gateways MUST NOT
      advertise the mobile node's home network prefix on the access gateway link
      and the local there by denying mobility anchor
   for routing service to the mobile node's IPv6 datagrams.

   o  IPv6-In-IPv6 - IPv6 datagram encapsulated in an IPv6 packet.  This
      mechanism is defined in node.

   Extending the Generic Packet Tunneling for IPv6
      specification [RFC-2473]. binding lifetime

   o  IPv6-In-IPv4 - IPv6 datagram encapsulation in an IPv4 packet.  The
      details related to this encapsulation mode and  For extending the specifics on
      how this mode is negotiated is specified in lifetime of a currently existing binding at the companion
      document, IPv4 support for Proxy Mobile IPv6 [ID-IPv4-PMIP6].

   o  IPv6-In-IPv4-UDP - IPv6 datagram encapsulation in an IPv4 UDP
      packet.  The details related to this mode are covered in
      local mobility, the
      companion document, IPv4 support for mobile access gateway MUST send a Proxy Mobile IPv6 [IPv4-
      PMIP6-SPEC].

6.10.3.  Routing State

   The following section explain
      Binding Update message, before the routing state for a mobile node on expiry of the mobile access gateway.  This routing state reflects only one
   specific way currently
      accepted binding.

   De-Registration of implementation and one MAY choose to implement it in
   other ways.  The policy based route defined below acts as a traffic
   selection rule for routing a mobile node's traffic through a specific
   tunnel created between the binding

   o  At any point, the mobile access gateway and detects that the mobile
      node has moved away from its access link, it MUST send a Proxy
      Binding Update message to the mobile node's local mobility anchor and
      with the specific encapsulation
   mode, as negotiated. lifetime value set to zero.

   o  The below example identifies mobile access gateway MUST also remove the routing state default route over
      the tunnel for two visiting that mobile nodes, MN1 and MN2 with their respective local mobility
   anchors LMA1 node and LMA2.

   For all traffic from delete the Binding Update List
      for that mobile node, identified by either upon receiving an Proxy Binding
      Acknowledgment message from the mobile node's
   MAC address, ingress interface local mobility anchor or source prefix (MN-HNP) after a
      certain timeout waiting for the acknowledgment message.

   Constructing Proxy Binding Update Message

   o  The mobile access gateway when sending the Proxy Binding Update
      request to
   _ANY_DESTINATION_ route the local mobility anchor MUST construct the message as
      specified below.

               IPv6 header (src=Proxy-CoA, dst=LMAA)
                    Mobility header
                        -BU /*P & A flags are set*/
                       Mobility Options
                          - Home Network Prefix option
                          - Link-local Address option (Optional)
                          - Timestamp Option (optional)
                          - NAI Option

                    Proxy Binding Update message contents

   o  The Source Address field in the IPv6 header of the message SHOULD
      be set to the address of the mobile access gateway.

   o  The Destination Address field in the IPv6 header of the message
      SHOULD be set to the local mobility anchor address.

   o  The Home Network Prefix option MUST be present.  The prefix value
      may be set 0::/0 or to a specific value.

   o  The Link-local Address option MAY be present.  The value may be
      set to ALL_ZERO or the mobile node's link-local address.

   o  Considerations from Section 5.4 must be applied for constructing
      the Timestamp option.

   o  The NAI option MUST be present, the identifier field in the option
      MUST be set to mobile node's identifier, MN-Identifier.

   o  The message SHOULD be protected by using IPsec ESP, using the
      security association existing between the local mobility anchor
      and the mobile access gateway, created either dynamically or
      statically.

6.10.  Routing Considerations

   This section describes how the mobile access gateway handles the
   traffic to/from the mobile node that is attached to one of its access
   interface.

                 Proxy-CoA                   LMAA
                    |                          |
    +--+          +---+                      +---+          +--+
    |MN|----------|MAG|======================|LMA|----------|CN|
    +--+          +---+                      +---+          +--+
                            IPv6 Tunnel

6.10.1.  Transport Network

   The transport network between the local mobility anchor and the
   mobile access can be either an IPv6 or IPv4 network.  However, this
   specification only deals with the IPv6 transport and the companion
   document [ID-IPV4-PMIP6] specifies the required extensions for
   negotiating IPv4 transport and the corresponding encapsulation mode,
   for supporting this protocol operation.

6.10.2.  Tunneling & Encapsulation Modes

   The IPv6 address that a mobile node uses from its home network prefix
   is topologically anchored at the local mobility anchor.  For a mobile
   node to use this address from an access network attached to a mobile
   access gateway, proper tunneling techniques have to be in place.
   Tunneling hides the network topology and allows the mobile node's
   IPv6 datagrams to be encapsulated as a payload of another IPv6 packet
   and be routed between the local mobility anchor and the mobile access
   gateway.  The Mobile IPv6 base specification [RFC-3775] defines the
   use of IPv6-over-IPv6 tunneling, between the home agent and the
   mobile node and this specification extends the use of the same
   tunneling mechanism between the local mobility anchor and the mobile
   access gateway.

   On most operating systems, tunnels are implemented as a virtual
   point-to-point interface.  The source and the destination address of
   the two end points of this virtual interface along with the
   encapsulation mode are specified for this virtual interface.  Any
   packet that is routed over this interface, get encapsulated with the
   outer header and the addresses as specified for that point to point
   tunnel interface.  For creating a point to point tunnel to any local
   mobility anchor, the mobile access gateway may implement a tunnel
   interface with the source address field set to its Proxy-CoA address
   and the destination address field set to the LMA address.

   The following are the supported packet encapsulation modes that can
   be used by the mobile access gateway and the local mobility anchor
   for routing mobile node's IPv6 datagrams.

   o  IPv6-In-IPv6 - IPv6 datagram encapsulated in an IPv6 packet.  This
      mechanism is defined in the Generic Packet Tunneling for IPv6
      specification [RFC-2473].

   o  IPv6-In-IPv4 - IPv6 datagram encapsulation in an IPv4 packet.  The
      details related to this encapsulation mode and the specifics on
      how this mode is negotiated is specified in the companion
      document, IPv4 support for Proxy Mobile IPv6 [ID-IPV4-PMIP6].

   o  IPv6-In-IPv4-UDP - IPv6 datagram encapsulation in an IPv4 UDP
      packet.  The details related to this mode are covered in the
      companion document, IPv4 support for Proxy Mobile IPv6 [ID-IPV4-
      PMIP6].

6.10.3.  Routing State

   The following section explain the routing state for a mobile node on
   the mobile access gateway.  This routing state reflects only one
   specific way of implementation and one MAY choose to implement it in
   other ways.  The policy based route defined below acts as a traffic
   selection rule for routing a mobile node's traffic through a specific
   tunnel created between the mobile access gateway and that mobile
   node's local mobility anchor and with the specific encapsulation
   mode, as negotiated.

   The below example identifies the routing state for two visiting
   mobile nodes, MN1 and MN2 with their respective local mobility
   anchors LMA1 and LMA2.

   For all traffic from the mobile node, identified by the mobile node's
   MAC address, ingress interface or source prefix (MN-HNP) to
   _ANY_DESTINATION_ route via interface tunnel0, next-hop LMAA.

   +==================================================================+
   |  Packet Source    | Destination Address  | Destination Interface |
   +==================================================================+
   | MAC_Address_MN1,  | _ANY_DESTINATION_    |     Tunnel0           |
   | (IPv6 Prefix or   |----------------------------------------------|
   |  Input Interface) | Locally Connected    |     Tunnel0           |
   +------------------------------------------------------------------+
   | MAC_Address_MN2 MAC_Address_MN2,  | _ANY_DESTINATION_    |     Tunnel1           |
   + (IPv6 Prefix or   -----------------------------------------------|
   |  Input Interface  | Locally Connected    |     direct            |
   +------------------------------------------------------------------+

                    Example - Policy based Route Table

   +==================================================================+
   | Interface | Source Address | Destination Address | Encapsulation |
   +==================================================================+
   | Tunnel0   |   Proxy-CoA    |        LMAA1         | IPv6-in-IPv6 |
   +------------------------------------------------------------------+
   | Tunnel1   |IPv4-Proxy-CoA  |    IPv4-LMA2         | IPv6-in-IPv4 |
   +------------------------------------------------------------------+

                     Example - Tunnel Interface Table

6.10.4.  Local Routing

   If there is data traffic between a visiting mobile node and a
   corresponding node that is locally attached to an access link
   connected to the mobile access gateway, the mobile access gateway MAY
   optimize on the delivery efforts by locally routing the packets and
   by not reverse tunneling them to the mobile node's local mobility
   anchor.  However, this has an implication on the mobile node's
   accounting and policy enforcement as the local mobility anchor is not
   in the path for that traffic and it will not be able to apply any
   traffic policies or do any accounting for those flows.

   This decision of path optimization SHOULD be based on the configured
   policy configured on the mobile access gateway, but enforced by the
   mobile node's local mobility anchor.  The specific details on how
   this is achieved is beyond of the scope of this document.

6.10.5.  Tunnel Management

   All the considerations mentioned in Section 5.2, 5.5.1, for the tunnel
   management on the local mobility anchor apply for the mobile access
   gateway as well.

   As explained in Section 5.2, the life of the Proxy Mobile IPv6 tunnel
   should not be based on a single visiting mobile node's lifetime.  The
   tunnel may get created as part of creating a mobility state for a
   visiting mobile node and later the same tunnel may be associated with
   other mobile nodes.  So, the tearing down logic of the tunnel must be
   based on the number of visitors over that tunnel.

6.10.6.  Forwarding Rules

   Upon receipt of an encapsulated packet sent to its configured Proxy-
   CoA address i.e. on receiving a packet from a tunnel, the mobile
   access gateway MUST use the destination address of the inner packet
   for forwarding it to the interface where the prefix for that address
   is hosted.  The mobile access gateway MUST remove the outer header
   before forwarding the packet.  If the mobile access gateway cannot
   find the connected interface for that destination address, it MUST
   silently drop the packet.  For reporting an error in such scenario,
   in the form of ICMP control message, the considerations from Generic
   Packet Tunneling specification [RFC-2473] apply.

   On receiving a packet from a mobile node connected to its access
   link, the mobile access gateway MUST ensure that there is an
   established binding for that mobile node with its local mobility
   anchor before forwarding the packet directly to the destination or
   before tunneling the packet to the mobile node's local mobility
   anchor.

   On receiving a packet from a mobile node connected to its access
   link, to a destination that is locally connected, the mobile access
   gateway MUST check the configuration variable, EnableMAGLocalRouting,
   to ensure the mobile access gateway is allowed to route the packet
   directly to the destination.  If the mobile access gateway is not
   allowed to route the packet directly, it MUST route the packet
   through the bi-directional tunnel established between itself and the
   mobile's local mobility anchor.

   On receiving a packet from the mobile node to any destination i.e.
   not directly connected to the mobile access gateway, the packet MUST
   be forwarded to the local mobility anchor through the bi-directional
   tunnel established between itself and the mobile's local mobility
   anchor.  However, the packets that are sent with the link-local
   source address MUST not be forwarded.

6.11.  Interaction with DHCP Relay Agent

   If Stateful Address Configuration using DHCP is supported on the link
   on which
   where the mobile node is attached, the DHCP relay agent [RFC-3315]
   needs to be configured on the that access router. link.

   When the mobile node sends a DHCPv6 Request message, the DHCP relay
   agent function on the access router MUST link will set the link-address field in
   the DHCPv6 message to the mobile node's home network prefix, so as to
   provide a prefix hint to the DHCP Server.  Since, Server for the address pool
   selection.

6.12.  Home Network Prefix Renumbering

   If the mobile node's home network prefix gets renumbered or becomes
   invalid during the middle of a mobility session, the mobile access link is
   gateway MUST withdraw the prefix by sending a point-to-point Router Advertisement on
   the access link with zero prefix lifetime for the mobile node's home
   network prefix.  Also, the local mobility anchor and the configured mobile node's prefix as
   access gateway MUST delete the on-link prefix, routing state for that prefix.
   However, the normal DHCP relay agent configuration specific details on how the MAG will ensure local mobility anchor
   notifies the
   prefix hint is set to mobile access gateway about the mobile node's home
   network prefix.

6.12. prefix renumbering is outside the scope of this document.

6.13.  Mobile Node Detachment Detection and Resource Cleanup

   Before sending a Proxy Binding Update message to the local mobility
   anchor for extending the lifetime of a currently existing binding of
   a mobile node, the mobile access gateway MUST make sure the mobile
   node is still attached to the connected link by using some reliable
   method.  If the mobile access gateway cannot predictably detect the
   presence of the mobile node on the connected link, it MUST NOT
   attempt to extend the registration lifetime of the mobile node.
   Further, in such scenario, the mobile access gateway MUST SHOULD terminate
   the binding of the mobile node by sending a Proxy Binding Update
   message to the mobile node's local mobility anchor with lifetime
   value set to 0.  It MUST also remove any local state such as the
   Binding Update List created for that mobile node.

   The specific detection mechanism of the loss of a visiting mobile
   node on the connected link is specific to the access link between the
   mobile node and the mobile access gateway and is outside the scope of
   this document.  Typically, there are various link-layer specific
   events specific to each access technology that the mobile access
   gateway can depend on for detecting the node loss.  In general, the
   mobile access gateway can depend on one or more of the following
   methods for the detection presence of the mobile node on the
   connected link:

   o  Link-layer event specific to the access technology

   o  PPP Session termination event on point-to-point link types
   o  IPv6 Neighbor Unreachability Detection event from IPv6 stack

   o  Notification event from the local mobility anchor

   o  Absence of data traffic from the mobile node on the link for a
      certain duration of time

6.13.

6.14.  Allowing network access to other IPv6 nodes

   In some proxy mobile IPv6 deployments, network operators may want to
   provision the mobile access gateway to offer network-based mobility
   management service only to some visiting mobile nodes and enable just
   regular IPv6/IPv4 access to some other nodes attached to that mobile
   access gateway.  This requires the network to have the control on
   when to enable network-based mobility management service to a mobile
   node and when to enabled a regular IPv6 access.  This specification
   does not disallow such configuration.

   Upon obtaining the mobile node's profile after a successful access
   authentication and after a policy consideration, the mobile access
   gateway MUST determine if the network based mobility service should
   be offered to that mobile node.  If the mobile node is entitled for
   such service, then the mobile access gateway must ensure the mobile
   node believes it is on its home link, as explained in various
   sections of this specification.

   If the mobile node is not entitled for the network-based mobility
   management service, as enforced by the policy, the mobile access
   gateway MAY choose to offer regular IPv6 access to the mobile node
   and hence the normal IPv6 considerations apply.  If IPv6 access is
   enabled, the mobile node SHOULD be able to obtain any IPv6 address
   using normal IPv6 address configuration mechanisms.  The obtained
   address must be from a local visitor network prefix.  This
   essentially ensures, the mobile access gateway functions as any other
   access router and does not impact the protocol operation of a mobile
   node attempting to use host-based mobility management service when it
   attaches to an access link connected service to a mobile access gateway in a
   proxy mobile
   node and when to enable regular IPv6 domain.

7.  Mobile Node Operation access.  This non-normative section discusses specification does
   not disallow such configuration.

   Upon obtaining the mobile node's operation in a
   Proxy Mobile IPv6 domain.

   Once the mobile node enters profile after a Proxy Mobile IPv6 domain and attaches
   to an successful access network
   authentication and after the access authentication, the network
   ensures, a policy consideration, the mobile using any of the address configuration mechanisms
   permitted by access
   gateway MUST determine if the network for that mobile node, will based mobility service should
   be able offered to obtain
   an address and move anywhere in that proxy mobile IPv6 domain.  From
   the perspective of the mobile, node.  If the entire proxy mobile IPv6 domain
   appears as a single link, node is entitled for
   such service, then the network ensures mobile access gateway must ensure the mobile
   node believes it is always on its home link, as explained in various
   sections of this specification.

   If the same link.

   The mobile node can be operating in an IPv4-only mode, IPv6-only mode
   or in dual IPv4/IPv6 mode.  However, the specific details on how is not entitled for the
   IPv4 network-based mobility
   management service is offered to service, as enforced by the
   mobile node is specified in policy, the companion document, IPv4 Support for
   Proxy Mobile mobile access
   gateway MAY choose to offer regular IPv6 [ID-IPV4-PMIP6].

   Typically, the configured policy in the network determines if access to the mobile node is authorized for IPv6, IPv4 or IPv6/IPv4 home address
   mobility.  If
   and hence the configured policy for a mobile node normal IPv6 considerations apply.  If IPv6 access is for IPv6-
   only home address mobility,
   enabled, the mobile node will SHOULD be able to obtain
   its IPv6 home address, any where in that Proxy Mobile IPv6 domain,
   otherwise the address
   using normal IPv6 address configuration mechanisms.  The obtained
   address will must be from a local prefix and not
   from a prefix that is topologically anchored at visitor network prefix.  This
   essentially ensures, the local mobility
   anchor mobile access gateway functions as any other
   access router and hence does not impact the protocol operation of a mobile will loose that address after
   node attempting to use host-based mobility management service when it moves
   attaches to an access link connected to a new link.

7.1.  Booting up mobile access gateway in a
   Proxy Mobile IPv6 domain.

7.  Mobile Node Operation

   This non-normative section explains the mobile node's operation in a
   Proxy Mobile IPv6 domain.

7.1.  Moving into a Proxy Mobile IPv6 Domain

   When

   Once a mobile node moves into enters a proxy mobile Proxy Mobile IPv6 domain and attaches to
   an access link, the mobile node will present its identity, MN-
   Identity, to the network as part of the access authentication
   procedure.  Once the authentication procedure is complete and the
   mobile node is authorized to access the network, the network or
   specifically the mobile access gateway on the access link will have
   detects the mobile node's profile and so it would know attachment of the mobile node's home
   network prefix node and completes the permitted address configuration modes.  The
   mobile node's home network prefix may also be dynamically assigned by binding
   registration with the mobile node's local mobility anchor and anchor.  If the same may be learnt by
   binding update operation is successfully performed, the mobile access gateway.
   gateway will create the required state and setup the data path for
   the mobile node's data traffic.

   If the mobile node is IPv6 enabled, on attaching to the link and
   after access authentication, the mobile node link,
   it will typically would send a Router Solicitation message. message [RFC-2461].  The
   mobile access gateway on the
   attached access link will respond to the Router
   Solicitation message with a Router Advertisement.  The Router
   Advertisement will have the mobile node's home network prefix, default-router address prefix,
   default-router address and other address configuration parameters.

   If the mobile access gateway on the access link, receives a Router
   Solicitation message from the mobile node, before it completed the
   signaling with the mobile node's local mobility anchor, the mobile
   access gateway may not know the mobile node's home network prefix and other address
   configuration parameters.  The address configuration parameters such
   as Managed Address Configuration, Stateful Configuration flag values
   will typically
   may not be consistent through out that domain for that able to emulate the mobile
   node. node's home link on the access
   link.  In such scenario, the mobile node may notice a slight delay
   before it receives a Router Advertisement message.

   If the received Router Advertisement has the Managed Address
   Configuration flag set, the mobile node, as it would normally do,
   will send a DHCPv6 Request and the mobile access gateway [RFC-3315].  The DHCP relay service
   enabled on that access link will
   ensure, ensure the mobile node gets an address from will obtain
   its home network prefix IPv6 address as a lease from the DHCP server. its home network prefix.

   If the received Router Advertisement does not have the Managed
   Address Configuration flag set and if the mobile node is allowed to
   use an autoconfigured address, the mobile node will generate be able to obtain
   an IPv6 address using an interface
   identifier, identifier generated as per the
   Autoconf specification [RFC-2462] or using
   privacy extensions as specified in per the Privacy Extensions
   specification [RFC-3041].

   If the mobile node is IPv4 enabled or IPv4-only enabled, the mobile
   node after and if the access authentication, network permits, it
   will be able to obtain the IPv4 address configuration for the
   connected interface by using DHCPv4. DHCP [RFC-2131].  The details related to
   IPv4 support is specified in the companion document [ID-IPV4-PMIP6].

   Once the address configuration is complete, the mobile node can
   continue to use the obtained this address configuration as long as it is
   with attached
   to the network that is in the scope of that Proxy Mobile IPv6 domain.

7.2.  Roaming in the Proxy Mobile IPv6 Network Domain

   After booting obtaining the address configuration in the Proxy Mobile IPv6 domain and obtaining the
   address configuration,
   domain, as the mobile node as it roams in the network
   between access links, will always detect moves and changes its home network prefix on point of attachment
   from one mobile access gateway to the link, as other, it can still continue to
   use the same address configuration.  As long as the attached access
   network is in the scope of that Proxy Mobile IPv6 domain.  The domain, the mobile
   node can continue to use will always detect the same link, where it obtained its IPv4/IPv6 MN-HoA for sending and receiving packets. initial
   address configuration.  If the mobile node uses performs DHCP for address configuration, operation,
   it will always be
   able to obtain its MN-HoA using DHCP. the same address as before.

   However, the mobile node will always detect a new default-router on
   each connected link, but still advertising the mobile node's home
   network prefix as the on-link prefix and with the other configuration
   parameters consistent with its home link properties.

7.3.  IPv6 Host Protocol Parameters

   This specification does not require any changes to the mobile node's
   IP stack.  It assumes the mobile node to be a normal IPv6 IPv4/IPv6 node,
   with its protocol operation consistent with the base IPv6
   specification [RFC-2460].  All aspects of Neighbor Discovery
   Protocol, including Router Discovery, Neighbor Discovery, Address
   Configuration procedures will just remain consistent with the base
   IPv6 Neighbor Discovery Specification [RFC-2461]. respective
   specifications.

   However, this specification recommends that the following IPv6
   operating parameters on the mobile node be adjusted to the below
   recommended values for protocol efficiency and for achieving faster
   hand-offs.

   Lower Default-Router List Cache Time-out:

   As per the base IPv6 specification [RFC-2460], [RFC-2461], each IPv6 host will is
   required to maintain certain host data structures including a
   Default-Router list.  This is the list of on-link routers that have
   sent Router Advertisement messages and are eligible to be default
   routers on that link.  The Router Lifetime field in the received
   Router Advertisement defines the life of this entry.

   In the case of Proxy Mobile IPv6 scenario, IPv6, when the a mobile node moves from one link
   to another, the source address of the received Router Advertisement
   messages advertising the mobile's mobile node's home network prefix will be
   from a different link-local address and thus making the mobile node
   believe that there is a new default-router on the link.  It is
   important that the mobile node uses the newly learnt default-router
   as supposed to the previously learnt known default-router.  The mobile node
   must update its default-router list with the new default router entry
   and must age out the previously learnt default router entry from its
   cache, just as specified in Section 6.3.5 of the base IPv6 ND specification [RFC-
   2461]. [RFC-2461].  This action is
   critical for minimizing packet losses during a hand off switch.

   On detecting a reachability problem, the mobile node will certainly
   detect the neighbor or the default-router unreachability loss by performing a the Neighbor
   Unreachability Detection procedure, but it is important that the
   mobile node times out the previous default router entry at the
   earliest.  If a given IPv6 host implementation has the provision to
   adjust these flush timers, still conforming to the base IPv6 ND
   specification, it is desirable to keep the flush-timers to suit the
   above consideration.

   However, if

   In access network where SEND [RFC-3971] is not deployed, the mobile
   access gateway has the ability to may withdraw the previous default-router entry, by
   sending a Router Advertisement using the link-local address that of
   the previous mobile access gateway and with the Router Lifetime field
   set to value 0, then it is
   possible to this will force the flush of the Previous
   Default-Router entry from the mobile node's cache.  This certainly
   requires some context-
   transfer context-transfer mechanisms in place for notifying the link-local link-
   local address of the default-router on the previous link to the
   mobile access gateway on the new link.

   There are other solutions possible for this problem, including the
   assignment of a unique link-local address for all the mobile access
   gateways in a Proxy Mobile IPv6 domain. domain and where SEND [RFC-3971] is
   not deployed.  In any case, such scenario, the mobile node is not required to
   update the default-router entry.  However, this is an implementation
   choice and has no bearing on the protocol interoperability.
   Implementations are free to adopt the best approach that suits their
   target deployments.

8.  Message Formats

   This section defines extensions to the Mobile IPv6 [RFC-3775]
   protocol messages.

8.1.  Proxy Binding Update

       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
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |            Sequence #         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |A|H|L|K|M|R|P|  Reserved       |            Lifetime           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 9: 11: Proxy Binding Update Message

   A Binding Update message that is sent by a mobile access gateway to a
   local mobility anchor is referred to as the Proxy "Proxy Binding Update Update"
   message.

   Proxy Registration Flag  A new flag (P) is included in the Binding Update message.
   The rest of the Binding Update message format remains the same as
   defined in [RFC-3775].

   Proxy Registration Flag (P)

   A new flag (P) is set included in the Binding Update message to indicate
   to the local mobility anchor that the Binding Update message is from a mobile access gateway acting
   as a
   proxy mobility agent. registration.  The flag MUST be set to the value of 1 for proxy
   registrations and MUST be set to 0 for direct registrations sent by a
   mobile node when using host-base mobility. node.

   For descriptions of other fields present in this message, refer to
   the
   section 6.1.7 of Mobile IPv6 specification [RFC3775]. [RFC-3775].

8.2.  Proxy Binding Acknowledgment

       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
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |   Status      |K|R|P|Reserved |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Sequence #            |           Lifetime            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 10: 12: Proxy Binding Acknowledgment Message

   A Binding Acknowledgment Acknowledgement message that is sent by the a local mobility
   anchor to the a mobile access gateway is referred to as the "Proxy
   Binding
   Acknowledgement". Acknowledgement" message.  A new flag (P) is included in the
   Binding Acknowledgment message.  The rest of the Binding
   Acknowledgment message format remains the same as defined in [RFC-
   3775].

   Proxy Registration Flag (P)

   A new flag (P) is included in the Binding Acknowledgement message to
   indicate that the local mobility anchor that processed the
   corresponding Proxy Binding Update message supports Proxy
   Registrations. proxy
   registrations.  The flag is set only if the corresponding Proxy
   Binding Update had the Proxy Registration Flag (P) set to value of 1.
   The rest of the Binding Acknowledgement format remains the same, as
   defined in [RFC-3775].

   For descriptions of other fields present in this message, refer to
   the section 6.1.8 of Mobile IPv6 specification [RFC3775]. [RFC-3775].

8.3.  Home Network Prefix Option

   A new option, Home Network Prefix Option is defined for using it in
   the Proxy Binding Update and Proxy Binding Acknowledgment messages
   exchanged between the a local mobility anchor and the a mobile access
   gateway.  This option can be is used for exchanging the mobile node's home
   network prefix information.

   The home network prefix

   The Home Network Prefix Option has an alignment requirement of 8n+4.
   Its format is 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      |   Reserved    | Prefix Length |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                    Home Network Prefix                        +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Type
           <IANA>

       Length

           8-bit unsigned integer indicating the length in octets of the option, option
           in octets, excluding the type and length fields. This field
           MUST be set to 18.

       Reserved

           This field is unused for now.  The value MUST be initialized
           to 0 by the sender and MUST be ignored by the receiver.

       Prefix Length

           8-bit unsigned integer indicating the prefix length of the
           IPv6 prefix contained in the option.

       Home Network Prefix

           A sixteen-byte field containing the mobile node's IPv6 Home
           Network Prefix.

                   Figure 11: 13: Home Network Prefix Option

8.4.  Time Stamp  Link-local Address Option

   A new option, Time Stamp Link-local Address Option is defined for use using it in
   the Proxy Binding Update and Acknowledgement messages.  This option can be used
   in Proxy Binding Update Acknowledgment messages
   exchanged between a local mobility anchor and Proxy Binding Acknowledgement messages. a mobile access
   gateway.  This option is used for exchanging the mobile node's link-
   local address.

   The Link-local Address option has an alignment requirement of 8n+6.
   Its format is 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
                                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                      |      Option   Type        | Option    Length     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                          Timestamp                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Type
           <IANA>

       Length

           8-bit unsigned integer indicating the length in octets of
           the option, excluding the type and length fields.  This field
           MUST be set to 8.

       Timestamp

           64-bit time stamp

                       Figure 12: Time Stamp Option

8.5.  Status Codes

   This document defines the following new Binding Acknowledgement
   status values:

   145: Proxy Registration not supported by the local mobility anchor

   146: Proxy Registrations from this mobile access gateway not allowed

   147: Home Network prefix for this NAI is not configured and the Home
   Network Prefix Option not present in the Proxy Binding Update.

   148: Invalid Time Stamp Option in the received Proxy Binding Update
   message.

   Status values less than 128 indicate that the Binding Update was
   processed successfully by the receiving nodes.  Values greater than
   128 indicate that the Binding Update was rejected by the local
   mobility anchor.

   The value allocation for this usage needs to be approved by the IANA
   and must be updated in the IANA registry.

9.  Protocol Configuration Variables

   The mobile access gateway MUST allow the following variables to be
   configured by the system management.

   EnableMAGLocalrouting

   This flag indicates whether or not the mobile access gateway is
   allowed to enable local routing of                                                               |
      +                  Link-local Address                           +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       Type
           <IANA>

       Length

           8-bit unsigned integer indicating the traffic exchanged between a
   visiting mobile node and a corresponding node that is locally
   connected to one length of the interfaces of option
           in octets, excluding the mobile access gateway.  The
   corresponding node can type and length fields. This field
           MUST be another visiting mobile node as well, or a
   local fixed node.

   The default value for this flag is set to "FALSE", indicating that
   the mobile access gateway MUST reverse tunnel all the traffic to 16.

       Link-local Address

           A sixteen-byte field containing the mobile node's local mobility anchor.

   When the value of this flag link-local
           address.

                   Figure 14: Link-local Address Option

8.5.  Timestamp Option

   A new option, Timestamp Option is set to "TRUE", the mobile access
   gateway MUST route defined for use in the traffic locally.

   This aspect Proxy
   Binding Update and Proxy Binding Acknowledgement messages.

   The Timestamp option has an alignment requirement of local routing MAY be defined 8n+2.  Its
   format is as policy on a per mobile
   basis and when present will take precedence over this flag.

10.  IANA Considerations

   This document defines a two new Mobility Header Options, the Home
   Network Prefix 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
                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                               |      Option and Type  | Option Length |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                          Timestamp                            +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    Type
        <IANA>

    Length

        8-bit unsigned integer indicating the Time Stamp Option.  These options are
   described length in Sections 8.3 octets of
        the option, excluding the type and 8.5 respectively. length fields.  The Type value
        for
   these options needs to this field MUST be assigned from set to 8.

    Timestamp

      A 64-bit unsigned integer field containing a timestamp.  The value
      indicates the same numbering space as
   allocated for number of seconds since January 1, 1970, 00:00 UTC,
      by using a fixed point format.  In this format, the other mobility options, as defined integer number
      of seconds is contained in [RFC-3775]. the first 48 bits of the field, and the
      remaining 16 bits indicate the number of 1/64K fractions of a
      second.

                        Figure 15: Timestamp Option

8.6.  Status Values

   This document also defines the following new Binding Acknowledgement status Status values
   as described for use in Section 8.5.  The status
   Proxy Binding Acknowledgment message.  These values MUST are to be assigned
   allocated from the same space used for Binding Acknowledgement status values, number space, as defined in Section 6.1.8
   [RFC-3775].

11.  Security Considerations

   The potential security threats against any general network-based

   Status values less than 128 indicate that the Proxy Binding Update
   was processed successfully by the local mobility management protocol are covered in anchor.  Status
   values greater than 128 indicate that the document, Security
   Threats Proxy Binding Update was
   rejected by the local mobility anchor.

   PROXY_REG_NOT_ENABLED:

      Proxy Registration not enabled for the mobile node.

   MAG_NOT_AUTHORIZED_FOR_PROXY_REG:

      The mobile access gateway is not authorized to Network-Based Localized Mobility Management [RFC-4832].
   This section analyses those vulnerabilities send proxy binding.
      updates.

   NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX

      The mobile node is not authorized for the requesting home network
      prefix.

   TIMESTAMP_MISMATCH:

      Invalid Timestamp value in the context of received Proxy
   Mobile IPv6 protocol solution and covers all aspects around those
   identified vulnerabilities.

   A compromised Binding Update
      message.

   MISSING_MN_IDENTIFIER_OPTION:

      Missing mobile node identifier in the Proxy Binding Update
      message.

9.  Protocol Configuration Variables

   The mobile access gateway MUST allow the following variables to be
   configured by the system management.

   EnableMAGLocalrouting

      This flag indicates whether or not the mobile access gateway can potentially send Proxy
   Binding Update messages on behalf is
      allowed to enable local routing of the traffic exchanged between a
      visiting mobile nodes node and a corresponding node that are not
   attached to its access link.  This threat is similar to an attack on
   a typical routing protocol or equivalent locally
      connected to one of the compromise interfaces of an on-
   path router.  This threat exists in the network today and this
   specification does not make mobile access gateway.
      The corresponding node can be another visiting mobile node as
      well, or a local fixed node.

      The default value for this vulnerability any worse than what it
   is.  However, flag is set to eliminate this vulnerability, "FALSE", indicating that
      the local mobility
   anchor before accepting Proxy Binding Update message received from a mobile access gateway, gateway MUST ensure reverse tunnel all the traffic to
      the mobile node node's local mobility anchor.

      When the value of this flag is attached set to "TRUE", the mobile access
      gateway that sent MUST route the Proxy Binding Update message. traffic locally.

      This can be achieved using out aspect of band mechanisms local routing MAY be defined as policy on a per
      mobile basis and the specifics
   of how that is achieved is beyond the scope of when present will take precedence over this document.

   This document does not cover flag.

   The local mobility anchor MUST allow the security requirements for
   authorizing following variables to be
   configured by the mobile node for system management.

   MinDelayBeforeBCEDelete

      This variable specifies the use amount of the access link.  It is
   assumed that there are proper Layer-2/Layer-3 based authentication
   procedures, such as EAP, are time in place and will ensure milli-seconds the
      local mobility anchor MUST wait before it deletes a binding cache
      entry of a mobile node, upon receiving a Proxy Binding Update
      message from a mobile node
   is properly identified and authorized before permitting it to access gateway with a lifetime value of 0.
      During this wait time, if the network.  It is further assumed that local mobility anchor receives a
      Proxy Binding Update for the same security mechanism
   will ensure the mobile session is not hijacked node, identified by malicious nodes on its
      MN-Identifier, with lifetime value greater than 0, then it must
      update the access link.

   This specification requires that all binding cache entry with the signaling messages exchanged
   between accepted binding values.
      At the mobile access gateway and end of this wait-time, if the local mobility anchor did not
      receive any valid Proxy Binding Update message, it MUST
   be authenticated by IPsec [RFC-4301]. delete the
      binding cache entry for that mobile node.

      The use of IPsec to protect
   Mobile IPv6 signaling messages default value for this variable is described in detail in 1000 milli-seconds.

10.  IANA Considerations

   This document defines a three new Mobility Header Options, the HA-MN
   IPsec specification [RFC-3776] Home
   Network Prefix option, Link-local Address option and the applicability of that security
   model Timestamp
   option.  These options are described in Sections 8.3, 8.4 and 8.5
   respectively.  The Type value for these options needs to Proxy Mobile IPv6 protocol is covered be assigned
   from the same numbering space as allocated for the other mobility
   options, as defined in [RFC-3775].

   This document also defines new Binding Acknowledgement status values
   as described in Section 4.0 8.6.  The status values MUST be assigned from
   the same number space used for Binding Acknowledgement status values,
   as defined in [RFC-3775].  The allocated values for each of this
   document.

   As these
   status values MUST be greater than 128.

11.  Security Considerations

   The potential security threats against any network-based mobility
   management protocol are described in the base [RFC-4832].  This section
   explains how Proxy Mobile IPv6 specification [RFC-3775], both
   the mobile node (in case of protocol defends itself against those
   threats.

   Proxy Mobile IPv6, its IPv6 protocol requires the signaling messages, Proxy
   Binding Update and Proxy Binding Acknowledgement, exchanged between
   the mobile access
   gateway) gateway and the local mobility anchor MUST support and SHOULD use to be
   protected using IPsec, using the Encapsulating Security Payload (ESP) header in transport mode and
   MUST use a non-NULL payload authentication algorithm established security association
   between them.  This essentially eliminates the threats related to provide data
   origin authentication, data integrity and optional anti-replay
   protection.

   The proxy solution allows one device creating a routing state for
   some other device at the local mobility anchor.  It is important that
   impersonation of the mobile access gateway or the local mobility anchor has proper authorization services in place
   to ensure
   anchor.

   This specification allows a given mobile access gateway is permitted to be a proxy
   for send binding
   registration messages on behalf of a specific mobile node.  If proper security
   authorization checks are not in place, a malicious node may be able
   to hijack a mobile node's session or may do a
   denial-of-service attacks. denial-of-service
   attacks.  To prevent this attack, this specification requires the
   local mobility anchor to allow only authorized mobile access gateways
   to send binding registration messages on behalf of a mobile node.

   To eliminate the threats on the interface between the mobile access
   gateway and the mobile node, this specification requires an
   established trust between the mobile access gateway and the mobile
   node and to authenticate and authorize the mobile node before it is
   allowed to access the network.

   To eliminate the threats related to a compromised mobile access
   gateway, this specification recommends that the local mobility anchor
   before accepting a Proxy Binding Update message for a given mobile
   node, to reasonably ensure, using some out of band mechanisms, that
   the given mobile node is attached to that mobile access gateway that
   sent the request.

   The issues related to a compromised mobile access gateway in the
   scenario where the local mobility anchor and the mobile access
   gateway in different domains, is outside the scope of this document.
   This scenario is beyond the applicability of this document.

12.  Acknowledgements

   The authors would like to specially thank Julien Laganier, Christian
   Vogt, Pete McCann, Brian Haley, Ahmad Muhanna, JinHyeock Choi for
   their thorough review of this document.

   The authors would also like to thank the Alex Petrescu, Alice Qinxia,
   Alper Yegin, Ashutosh Dutta, Behcet Sarikaya, Fred Templing, Genadi
   Velev, George Tsirtsis, Gerardo Giaretta, Henrik Levkowetz, Hesham
   Soliman, James Kempf, Jari Arkko, Jean-Michel Combes, John Zhao,
   Jong-Hyouk Lee, Jonne Soininen, Jouni Korhonen, Kilian Weniger, Alex Petrescu, Marco
   Liebsch, Mohamed Khalil, Fred Templing, Nishida Katsutoshi, James Kempf, Vidya Narayanan, Henrik Levkowetz, Phil Roberts, Jari Arkko, Ashutosh Dutta, Hesham Soliman, Behcet Sarikaya,
   George Tsirtsis Ryuji
   Wakikawa, Sangjin Jeong, Suresh Krishnan, Vidya Narayanan, Youn-Hee
   Han and many others for their passionate discussions in the working
   group mailing list on the topic of localized mobility management
   solutions.  These discussions stimulated much of the thinking and
   shaped the draft to the current form.  We acknowledge that !

   The authors would also like to thank Ole Troan, Akiko Hattori, Parviz
   Yegani, Mark Grayson, Michael Hammer, Vojislav Vucetic, Jay Iyer and
   Tim Stammers for their input on this document.

13.  References

13.1.  Normative References

   [RFC-1305]

   [RFC-2030] Mills, D., "Network "Simple Network Time Protocol (Version 3)
   Specification, Implementation", RFC 1305, March 1992.

   [RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, (SNTP) Version 6
   (IPv6) Specification", 4
   for IPv4, IPv6 and OSI", RFC 2460, December 1998. 2030, October 1996.

   [RFC-2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
   2131, March 1997.

   [RFC-2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
   Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.

   [RFC-2462] Thompson, S., Narten, T., "IPv6 Stateless Address
   Autoconfiguration", RFC 2462, December 1998.

   [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
   IPv6 Specification", RFC 2473, December 1998.

   [RFC-3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
   M.Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
   RFC 3315, July 2003.

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

   [RFC-3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
   Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents",
   RFC 3776, June 2004.

   [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
   Network Access Identifier", RFC 4282, November 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-4301] Kent, S. and Atkinson, R., "Security Architecture for the
   Internet Protocol", RFC 4301, December 2005.

   [RFC-4303] Kent, S. "IP Encapsulating Security Protocol (ESP)", RFC
   4303, December 2005.

   [RFC-4306] Kaufman, C, et al, "Internet Key Exchange (IKEv2)
   Protocol", RFC 4306, December 2005.

   [RFC-4830] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta,
   G., Liebsch, M., "Problem Statement for Network-based Localized
   Mobility Management", September 2006.

   [RFC-4831] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta,
   G., Liebsch, M., "Goals for Network-based Localized Mobility
   Management", October 2006.

   [RFC-4832] Vogt, C., Kempf, J., "Security Threats to Network-Based
   Localized Mobility Management", September 2006.

   [ID-IPV4-PMIP6] Wakikawa, R.

   [RFC-4877] Devarapalli, V. and Gundavelli, S., "IPv4 Support for
   Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-00.txt, May
   2007.

   [ID-DSMIP6] Soliman, H. et al, Dupont, F., "Mobile IPv6 support for dual stack
   Hosts Operation
   with IKEv2 and Routers (DSMIPv6)",
   draft-ietf-mip6-nemo-v4traversal-03.txt, October 2006. the revised IPsec Architecture", RFC 4877, April 2007.

13.2.  Informative References

   [RFC-1332] McGregor, G., "The PPP Internet Protocol Control Protocol
   (IPCP)", RFC 1332, May 1992.

   [RFC-1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD
   51, RFC 1661, July 1994.

   [RFC-2472] Haskin, D. and Allen, E., "IP version 6 over PPP", RFC
   2472, December 1998.

   [RFC-2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
   IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

   [RFC-3041] Narten, T. and Draves, R., "Privacy Extensions for
   Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.

   [RFC-3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
   August 2002.

   [RFC-3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
   Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.

   [ID-IPV4-PMIP6] Wakikawa, R. and Gundavelli, S., "IPv4 Support for
   Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-00.txt, May
   2007.

   [ID-DNAV6] Kempf, J., et al "Detecting Network Attachment in IPv6
   Networks (DNAv6)", draft-ietf-dna-protocol-03.txt, October 2006.

   [ID-MIP6-IKEV2] Devarapalli, V.

   [ID-MN-AR-INTERFACE] Laganier, J. and Dupont, F., Narayanan, S., "Network-based
   Localized Mobility Management Interface between Mobile Node and
   Mobility Access Gateway", draft-ietf-netlmm-mn-ar-if-02.txt, May
   2007.

   [ID-DSMIP6] Soliman, H. et al, "Mobile IPv6
   Operation with IKEv2 support for dual stack
   Hosts and the revised IPsec Architecture",
   draft-ietf-mip6-ikev2-ipsec-08.txt, December Routers (DSMIPv6)",
   draft-ietf-mip6-nemo-v4traversal-03.txt, October 2006.

Appendix A.  Proxy Mobile IPv6 interactions with AAA Infrastructure

   Every mobile node that roams in a proxy Mobile IPv6 domain, would
   typically be identified by an identifier, MN-Identifier, and that
   identifier will have an associated policy profile that identifies the
   mobile node's home network prefix, permitted address configuration
   modes, roaming policy and other parameters that are essential for
   providing network-based mobility service.  This information is
   typically configured in AAA.  It is possible the home network prefix
   is dynamically allocated for the mobile node when it boots up for the
   first time in the network, or it could be a statically configured
   value on per mobile node basis.  However, for all practical purposes,
   the network entities in the proxy Mobile IPv6 domain, while serving a
   mobile node will have access to this profile and these entities can
   query this information using RADIUS/DIAMETER protocols.

Appendix B.  Supporting Shared-Prefix Model using DHCPv6

   For supporting shared-prefix model, i.e, if multiple mobile nodes are
   configured with a common IPv6 network prefix, as in Mobile IPv6
   specification,

   This specification supports Per-MN-Prefix model.  However, it is
   possible to support that configuration Shared-Prefix model under the following guidelines:
   guidelines.

   The mobile node is allowed to use stateful address configuration
   using DHCPv6 for obtaining its address configuration.  The mobile
   nodes
   node is not allowed to use any of the stateless autoconfiguration
   techniques.  The permitted address configuration models for the
   mobile node on the access link can be enforced by the mobile access
   gateway, by setting the relevant flags in the Router Advertisements,
   as per ND Specification, [RFC-2461].

   The Home Network Prefix Option option that is sent by the mobile access
   gateway in the Proxy Binding Update message, must contain the 128-bit
   host address that the mobile node obtained via DHCPv6.

   Routing state at the mobile access gateway:

   For all IPv6 traffic from the source MN-HoA::/128 to
   _ANY_DESTINATION_, route via tunnel0, next-hop LMAA, where tunnel0 is
   the MAG to LMA tunnel.

   Routing state at the local mobility anchor:

   For all IPv6 traffic to destination MN-HoA::/128, route via tunnel0,
   next-hop Proxy-CoA, where tunnel0 is the LMA to MAG tunnel.

Authors' Addresses

   Sri Gundavelli
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: sgundave@cisco.com

   Kent Leung
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: kleung@cisco.com

   Vijay Devarapalli
   Azaire Networks
   4800 Great America Pkwy
   Santa Clara, CA  95054
   USA

   Email: vijay.devarapalli@azairenet.com
   Kuntal Chowdhury
   Starent Networks
   30 International Place
   Tewksbury, MA

   Email: kchowdhury@starentnetworks.com

   Basavaraj Patil
   Nokia Siemens Networks
   6000 Connection Drive
   Irving, TX  75039
   USA

   Email: basavaraj.patil@nsn.com

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).