Subject: [Mip6] Proxy Mobile IPv6 - I-D Submission

From: Sri Gundavelli <[email-masked]>
Date: Mon, 16 Oct 2006 05:36:41 -0700

Attached is the draft on Proxy Mobile IPv6 that we have
posted today. Please review and comment on this work.

Regards
Sri

-------- Original Message --------
Subject: I-D Submission: draft-sgundave-mip6-proxymip6-00.txt
Date: Mon, 16 Oct 2006 05:25:39 -0700
From: Sri Gundavelli <[email-masked]>
To: [email-masked]

Hi,

Please find the attached internet-draft

   draft-sgundave-mip6-proxymip6-00.txt

This is an individual submission for the Mobile IPv6 working group.
Please post this to the archives.

Thanks
Sri

MIP6 WG                                                    S. Gundavelli
Internet-Draft                                                  K. Leung
Expires: April 19, 2007                                    Cisco Systems
                                                          V. Devarapalli
                                                         Azaire Networks
                                                        October 16, 2006

                           Proxy Mobile IPv6
                   draft-sgundave-mipv6-proxymipv6-00

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 April 19, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This specification describes a network-based mobility management
   protocol.  It is called Proxy Mobile IPv6 (PMIPv6) and is based on
   Mobile IPv6.  This protocol is for enabling any IPv6 host to achieve
   protocol mobility with out requiring the host to participate in any
   mobility related signaling.

Gundavelli, et al.       Expires April 19, 2007                 [Page 1]

Internet-Draft              Proxy Mobile IPv6               October 2006

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions used in this document  . . . . . . . . . . . . . .  3
   3.  Proxy Mobile IPv6 Protocol Overview  . . . . . . . . . . . . .  4
   4.  Message Formats  . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Proxy Binding Update . . . . . . . . . . . . . . . . . . .  9
     4.2.  Proxy Binding Acknowledgment . . . . . . . . . . . . . . .  9
     4.3.  Home Network Prefix Option . . . . . . . . . . . . . . . . 10
     4.4.  Error Codes  . . . . . . . . . . . . . . . . . . . . . . . 11
   5.  Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 11
     5.1.  Extensions to conceptual data structures . . . . . . . . . 11
     5.2.  Processing a Proxy Binding Update Request  . . . . . . . . 12
     5.3.  Packet Routing . . . . . . . . . . . . . . . . . . . . . . 12
   6.  Proxy Mobile Agent Operation . . . . . . . . . . . . . . . . . 13
     6.1.  Conceptual Data Structures . . . . . . . . . . . . . . . . 13
     6.2.  Access Authentication and obtaining the profile  . . . . . 14
     6.3.  Sending Proxy Binding Update request to the home agent . . 14
     6.4.  Processing Proxy Binding Acknowledgment message  . . . . . 14
     6.5.  Emulating the Mobile Station's home link . . . . . . . . . 15
     6.6.  Tunnel Lifetime Management . . . . . . . . . . . . . . . . 15
     6.7.  Packet Routing . . . . . . . . . . . . . . . . . . . . . . 15
   7.  Mobile Station Operation . . . . . . . . . . . . . . . . . . . 16
     7.1.  Booting for the first time . . . . . . . . . . . . . . . . 16
     7.2.  Roaming in the Network . . . . . . . . . . . . . . . . . . 17
     7.3.  IPv6 Host Protocol Parameters  . . . . . . . . . . . . . . 17
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 20
   11. Normative References . . . . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
   Intellectual Property and Copyright Statements . . . . . . . . . . 22

Gundavelli, et al.       Expires April 19, 2007                 [Page 2]

Internet-Draft              Proxy Mobile IPv6               October 2006

1.  Introduction

   The IP Mobility protocols designed in the IETF so far involve the
   host in mobility management.  There are some deployment scenarios
   where a network-based mobility management protocol is considered
   appropriate.  The advantages to using a network-based mobility
   protocol include avoiding tunneling overhead over the air and support
   for hosts that do not implement any mobility management protocol.

   The document describes a network-based mobility management protocol
   based on Mobile IPv6. it is called Proxy Mobile IPv6 (PMIPv6).  One
   of the most important design considerations behind PMIPv6 has been to
   re-use as much as possible from the existing mobility protocols.

   There are many advantages to develop a protocol based on Mobile IPv6.
   Mobile IPv6 is a very mature mobility protocol for IPv6.  There have
   been many implementations and inter-operability events where Mobile
   IPv6 has been tested.  There also numerous specifications enhancing
   Mobile IPv6 that can be re-used.  Further, the Proxy MIPv6 solution
   described in this document allows the same Home Agent to provide
   mobility to hosts that use Mobile IPv6 and hosts that do not use any
   mobility management protocol.  Proxy Mobile IPv6 provides solution to
   a real deployment problem.

2.  Conventions used in this document

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

      The following new terminology and abbreviations are introduced in
      this document and all other general mobility related terms as
      defined in Mobile IPv6 specification [2].

      Proxy Mobile Agent (PMA)

         The proxy mobile agent is a functional element on the access
         router.  This is the entity that makes the mobile station
         believe it is at its home link, by emulating the home link
         properties.  It registers the location of the mobile station to
         the home agent and establishes a tunnel for receiving packets
         sent to the mobile station's home address.

      Mobility Station (MS)

Gundavelli, et al.       Expires April 19, 2007                 [Page 3]

Internet-Draft              Proxy Mobile IPv6               October 2006

         Any IPv6 host that has the ability to physically roam across
         different networks.  A Mobile Station is not required to have
         the Mobile IPv6 protocol stack.

3.  Proxy Mobile IPv6 Protocol Overview

   Every mobile station that roams in a PMIPv6 network, would typically
   be identified by an identifier, such as NAI and that identifier will
   have an associated policy profile that identifies the mobile's home
   network prefix, permitted address configuration modes, roaming policy
   and other parameters that are essential for providing mobility
   services.  This information is typically configured in a policy
   store, such as AAA.  It is possible the home network prefix is
   dynamically allocated for the mobile station when it boots up for the
   first time in the network, or it could be a statically configured
   value on per mobile station basis.  However, for all practical
   purposes, the PMIP network entities while serving a mobile station
   will have access to its profile.

   Once a mobile station enters its PMIPv6 network and performs the
   access authentication, the network will ensure the mobile station is
   always on its home network and further ensures it always gets its
   home address when using any of the address configuration procedures.
   In other words, there is home address/prefix that is specifically
   assigned for a mobile station and that prefix always follows the
   node, where ever it goes with in that PMIP domain.  From the
   perspective of the mobile station, the entire PMIP domain appears as
   a home link.

   When the mobile station attaches to a link on the access router
   running proxy mobile agent, the mobile station will present its
   identity to the network in the form of NAI as part of the access
   authentication procedure.  After a successful authentication, the
   proxy mobile agent will have the mobile station's profile.  The proxy
   mobile agent will have enough information to ensure the mobile
   station is at its home link.  It sends Router Advertisements with
   parameters that are specified for the mobile station's home link.  It
   is possible, this Router Advertisement may be in result to Router
   Solicitation message that the mobile proxy agent received from that
   mobile station.  The parameters in the Router Advertisement,
   including Link Prefix, MTU, Hop Limit, .etc., will be consistent with
   what the mobile station saw, when it previously attached to the
   network.  However, the link local address in the received Router
   Advertisement will be different from the link local address in the
   previously received Router Advertisement, making the mobile station
   believe that there is a new default router on the home link.  The

Gundavelli, et al.       Expires April 19, 2007                 [Page 4]

Internet-Draft              Proxy Mobile IPv6               October 2006

   Neighbor unreachability detection procedures will kick-in and the
   previous default Router entry will be removed from the mobile
   station's cache.  As explained in the later sections of the document,
   the mobile proxy agent can apply certain techniques to remove the
   previous default router entry from the mobile station's cache.

   The proxy mobile agent tries to register the mobile station's new
   point of attachment with its home agent.  In the PMIPv6 model, the
   home interface is a virtual interface and thus there is only one home
   agent that is anchoring the home prefix and so the mobile proxy agent
   can predictably locate the home agent that is anchoring the mobile
   station's home prefix, typically this would be the configured
   information in the mobile's policy profile.

   The proxy mobile agent sends a Proxy Binding Update message to the
   mobile station's home agent.  The message will have the mobile node's
   NAI identifier option.  The source address of that message will be
   the IPv6 address of the proxy mobile agent on the out going
   interface.  The contents of the message include the Mobile Node NAI
   option, Alternate Care-of Address option (optionally) and a NAI
   identifier of the proxy mobile node that is sending this request.
   After validating the request and upon accepting this binding update
   request, the home agent sets up a tunnel with encapsulation of Ipv6/
   IPv6 and with the source address of the tunnel fixed to its own
   address and the destination address of the proxy mobile agent,
   obtained from the Binding Update message.  This step of tunnel
   creation is not required, if there is an existing tunnel to the same
   mobile proxy agent.

   Further, the home agent will create a route entry pointing the home
   prefix of the mobile agent as reachable over the tunnel to the proxy
   mobile agent.  This route is not redistributed in the IGP.  The home
   agent will also send a Binding Acknowledgment accepting the binding
   update request.  The proxy mobile agent on receiving this Binding
   Acknowledgment will create a tunnel pointing to the home agent and
   will add a default route over the tunnel to the home agent.  All
   traffic from the mobile station that the proxy mobile agent receives
   in the role of a default router will route the traffic to the home
   agent over the tunnel.

   The mobile station on receiving this Router Advertisement will try to
   configure its interface either using stateful or stateless address
   configuration modes.  Either way, the mobile station will be able to
   obtain its home address for configuring on the interface.

   When using stateful address configuration, the proxy mobile agent
   will function as a DHCP relay agent.  It will set the giaddr field in
   the DHCP request from the mobile station to a random address in the

Gundavelli, et al.       Expires April 19, 2007                 [Page 5]

Internet-Draft              Proxy Mobile IPv6               October 2006

   mobile station's home prefix, forcing the DHCP server to allocate an
   address from that prefix and the tunnel route entry at the home agent
   will ensure the DHCP reply packet will get routed correctly to the
   proxy mobile agent.

   At this point, the mobile station has a valid home address at the
   point of current attachment, the serving proxy mobile agent and the
   home agent have proper routing states for handling the traffic sent
   by the mobile node and also for the incoming traffic to the mobile
   station.

   Call flow detailing the PMIPv6 protocol operation

      Mobile       Proxy       Home       Policy
     Station    Mobile Agent   Agent      Store (AAA)
        +           +           +           +
        |           |           |           |
        |Access     |           |           |
        |Initiation |           |           |
      1)o---------->|           |           |
        |           |           |           |
        |           |      AAA request      |
      2)|           o---------------------->|
        |           |           |           | Mobile Station
      3)|           |           |           o Authenticated
        |           |           |           |
        |           |       AAA reply       |
      4)|           |<----------------------o
        |           |           |           |
        |           |PMA obtains|           |
      5)|           | mobile's  |           |
        | Access    | profile   |           |
        | Auth      |           |           |
        | Complete  |           |           |
      6)|<----------o           |           |
        |           | Proxy     |           |
        |           | Binding   |           |
        |           | Update    |           |
      7)|           o---------->|           |
        |           |           |           |
        |           |           | AAA Query |
        |           |           |---------->|
        |           |           |           |
        |           |           | AAA Reply |

Gundavelli, et al.       Expires April 19, 2007                 [Page 6]

Internet-Draft              Proxy Mobile IPv6               October 2006

        |           |           |<----------|
        |           |           |           |
      8)|           |           o HA has the|
        |           |           | MS profile|
        |           |           |           |
        |           |           |           |
      9)|           |           o Creates   |
        |           |           | the HA-PMA|
        |           |           | routing   |
        |           |           | context   |
        |           |           | for the MS|
        |           |           | home prefx|
        |           |           |           |
        |           |           |           |
        |           | Proxy     |           |
        |           | Binding   |           |
        |           | Ack       |           |
     10)|           o<----------|           |
        |           |           |           |
        |           | Emulates  |           |
        |           | the mobile|           |
     11)|           o station's |           |
        |           | home link,|           |
        |           | if BU     |           |
        |           | accepted  |           |
        |           |           |           |
     12)o MS does   |           |           |
        | address   |           |           |
        | config    |           |           |
        |           |           |           |
     13)o  Mobile station can now use its   |
        |  home address for all protocol    |
        |  communication                    |
        |                                   |
        +                                   +

   Figure 1: PMIPv6 Protocol Operation

   Access Authentication:

   The network access authentication and authorization procedure ensures
   a valid mobile station is connected to the network.  Upon successful

Gundavelli, et al.       Expires April 19, 2007                 [Page 7]

Internet-Draft              Proxy Mobile IPv6               October 2006

   authentication by the policy server, the proxy mobile agent retrieves
   the mobile station's profile using the presented NAI.

   Proxy Binding Update:

   The proxy mobile agent sends a binding update request to the home
   agent on behalf of the mobile station registering the current anchor
   point and for creating a binding cache entry and a tunnel route for
   the mobile station's home prefix.

   Binding State at the Home Agent:

   The home agent creates a binding cache entry, tunnel towards the
   proxy mobile agent, a route for the mobile station's home prefix as
   reachable over the tunnel.

   Home Link Emulation:

   The proxy mobile agent emulates the mobile station's home interface
   on the access interface, making the mobile believe that it is
   connected to its home link.  The proxy mobile agent sends Router
   Advertisements with the mobile's home prefix and other attributes
   that are defined for the mobile station's home link.

   Address Configuration:

   Based on the flags specified in the Router Advertisements, the mobile
   station will use stateful or stateless address configuration methods
   for configuring its interface.  If stateful mode is chosen for
   address configuration, the proxy mobile agent on the access link will
   function as a relay agent and will set the giaddr field to the mobile
   station's home prefix.  Further, the proxy mobile agent will act as a
   default router for the mobile station.

   Packet Routing:

   The home agent is the anchor point for the mobile station's home
   prefix and thus it will receive all packets sent to the mobile
   station's home address/prefix.  The home agent will route all the
   received packets over the tunnel to the mobile proxy agent and in
   turn will route it on the access link.  For the packets originating
   from the mobile station, the proxy mobile agent will act as a default
   router and will route all the received packets over the tunnel to the
   home agent and in turn will route it to the destination.

4.  Message Formats

Gundavelli, et al.       Expires April 19, 2007                 [Page 8]

Internet-Draft              Proxy Mobile IPv6               October 2006

   This section defines extensions to the MIPv6 Binding Update message.

4.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 2: Proxy Binding Update Message

   A new flag, the 'P' flag, is added to the Binding Update message.
   The P flag indicates that the registration is a Proxy registration.
   When a proxy mobile agent sends a registration to the home agent, the
   P flag MUST be set to 1 indicate to the home agent that this
   registration is a proxy registration sent by a proxy mobile agent on
   behalf of a mobile station.

4.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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Gundavelli, et al.       Expires April 19, 2007                 [Page 9]

Internet-Draft              Proxy Mobile IPv6               October 2006

   Figure 3: Proxy Binding Acknowledgment Message

   Proxy Registration Flag (P)

   The Proxy Registration Flag is set to indicate that the home agent
   that processed the Proxy Binding Update supports Proxy Registration.
   It is set to 1 only if the corresponding Proxy Binding Update had the
   Proxy Registration Flag set to 1.

4.3.  Home Network Prefix Option

   A new option, Home Network Prefix Option is defined for using it in
   the Binding Acknowledgment sent from the home agent to the proxy
   mobile agent.  This option can be used for notifying the assigned
   Home network prefix for the mobile station.  The proxy mobile agent
   can use this prefix information in Router Advertisements sent to the
   mobile station and also in the Address Pool Identifier option in the
   DHCP messages sent to the DHCP Server.

   The Home Network Prefix Option is only valid in the Proxy Binding
   Acknowledgments that are sent from the proxy mobile agent to the home
   agent in reply to a Proxy Binding Update request.  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 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                   Local Network Prefix                        +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 4: Home Network Prefix Option

Gundavelli, et al.       Expires April 19, 2007                [Page 10]

Internet-Draft              Proxy Mobile IPv6               October 2006

4.4.  Error Codes

   Binding Acknowledgment Status Values

   The following status code values are defined for using them in the
   Binding Acknowledgment message when using PMIPv6 protocol.

   140: Proxy Registration not supported

   141: Proxy Registration from this proxy mobile agent not allowed

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

5.  Home Agent Operation

   For supporting this scheme, the home agent MUST satisfy all the
   requirements listed in Section 8.4 of [1].  The key differences of
   this scheme when compared to the base protocol is as follows:

   o  The mobile station is not anchored on any physical interface on
      the home agent.  Thus the home agent is not required to perform
      any proxy ND operations for defending the home address on the home
      link.  The home agent is required to manage a binding cache entry
      for managing the session state and a routing state for properly
      routing the packets destined to the mobile station.

   o  Each mobile station has a home address in a prefix that is created
      exclusively for that mobile station and no other mobile station
      will share its home address from this prefix.

   o  The route entry specifying that the mobile station's home prefix
      is reachable via the tunnel is created as supposed to creating an
      route entry just for the mobile node's home address.

   o  If multiple mobile stations are currently visiting the same proxy
      mobile agent, all the binding updates will share the same care-of
      address and possibly the same tunnel.

5.1.  Extensions to conceptual data structures

   The home agent maintains a binding cache entry for each currently
   registered mobile node.  The Binding Cache is a conceptual data
   structure described in detail in [1].  For supporting this

Gundavelli, et al.       Expires April 19, 2007                [Page 11]

Internet-Draft              Proxy Mobile IPv6               October 2006

   specification, the home agent will continue to create binding cache
   entries for each mobile station that gets proxy registered by a proxy
   mobile agent.  In addition, the home agent may have to add an
   additional flag to this conceptual data structure indicating that the
   entry is a proxy registration.  This proxy registration flag may be
   turned off for all the usual direct registrations.

5.2.  Processing a Proxy Binding Update Request

   After receiving a Proxy Binding Update request from a proxy mobile
   agent on behalf of a mobile station, the home agent must process the
   request as defined Section 10, of the base Mobile IPv6 specification
   [1], with one exception that this request is a proxy request and
   proper authorization checks have to be enforced.

   The home agent has to verify the policy to ensure the proxy mobile
   agent that is sending this request has the right to do so, else it
   MUST reject the request and send a Proxy Binding Acknowledgment with
   the proper status code.

   Upon accepting this request, the home agent must create a Binding
   Cache entry, a tunnel to the proxy mobile agent adding the mobile
   station's home prefix route over the tunnel and should send a Binding
   Acknowledgment with the successful status code.

5.3.  Packet Routing

   After sending a successful Proxy Binding Acknowledgment for the Proxy
   Binding Acknowledgment reply, the home agent must set up a tunnel to
   the proxy mobile agent serving the mobile station.

   The bi-directional tunnel between the home agent and the proxy mobile
   agent is used for routing the packets sent by the mobile station and
   also for routing the packets that are sent to the mobile station.

   The following are the details of the tunnel.

   o  Tunnel Source Address is the home agent's address

   o  Tunnel Destination Address is the proxy mobile agent's address

   o  Tunnel Encapsulation Mode is IPv6/IPv6

Gundavelli, et al.       Expires April 19, 2007                [Page 12]

Internet-Draft              Proxy Mobile IPv6               October 2006

   The home agent functions as an anchor point for the mobile station's
   home prefix.  When the home agent receives a data packet destined for
   the mobile station's home prefix, it MUST forward the packet to the
   mobile station through the bi-directional tunnel established between
   itself and the serving proxy mobile agent.  The home agent typically
   can use the routing table for routing the packet to the mobile
   station through the established tunnel.

   All the reverse tunneled packets that the home agent receives from
   the tunnel, after removing the tunnel encapsulation should route them
   the destination specified in the inner packet header.  These routed
   packets will have the source address field set to the mobile
   station's home address.

6.  Proxy Mobile Agent Operation

   The Proxy Mobile Agent has the following functional roles.  It will
   emulate the mobile station's home network on the access link, will
   update the home agent about the current location of the mobile
   station, will setup data path for enabling the mobile station to use
   its home address for communication and to some extent the role of the
   proxy mobile agent is comparable to that of the foreign agent in
   Mobile IPv4.

   The link connecting the proxy mobile agent and the mobile station
   should be considered as a multicast enabled point to point link.  It
   is not a shared link and hence any neighbor discovery messages with
   link scope are seen only by the specific mobile station and the proxy
   mobile agent.

6.1.  Conceptual Data Structures

   Every proxy mobile agent must maintain a Visitor List.  It is a list
   of mobile stations that the proxy mobile agent is currently serving.
   This MAY be implemented in any manner keeping the consistency with
   the external behaviour described in this section.

   The Visitor List entry has the following fields:

   o  The NAI of the mobile station.  This is obtained as part of the
      network access authentication procedure.  This identifier is
      required for downloading the mobile station's profile from the
      policy store.

Gundavelli, et al.       Expires April 19, 2007                [Page 13]

Internet-Draft              Proxy Mobile IPv6               October 2006

   o  The home address of the mobile station.  This MAY be a configured
      parameter in the mobile station's profile.  This MAY also be an
      address assigned by the DHCP server when the mobile station uses
      stateful address configuration mode for configuring the interface.
      The proxy mobile agent must implement DHCP relay agent function
      and should have the ability to learn the address leased to the
      mobile node for supporting the address allocation modes using DHCP
      server.

   o  The home prefix of the mobile station.  This MUST be a configured
      parameter in the mobile station's profile.

   o  The last sequence number that was sent in the Proxy Binding Update
      request.

6.2.  Access Authentication and obtaining the profile

   When the mobile station attaches to a link on the access router
   running proxy mobile agent, it will present its identity to the
   network in the form of NAI as part of the access authentication
   procedure.  The proxy mobile agent should be able fetch the mobile
   station's profile using the presented NAI.

6.3.  Sending Proxy Binding Update request to the home agent

   After a successful access authentication, the proxy mobile agent
   sends a Proxy Binding Update request to the home agent.  The rules
   around constructing this message will be as defined in the base
   Mobile IPv6 specification [1].  The proxy mobile agent sends a Proxy
   Binding Update to the home agent.  The source address of this message
   will be the configured IPv6 address on the egress interface.  The
   contents of the message include the Mobile Node NAI option, Alternate
   Care-of Address option (optionally) and a NAI identifier of the proxy
   mobile node that is sending this request.  The NAI option for the
   proxy mobile node MAY NOT be required, in some deployments, if the
   home agent has mechanisms to identify the proxy mobile agent and for
   the verification of the mobile station's roaming policy.

6.4.  Processing Proxy Binding Acknowledgment message

   After receiving a Proxy Binding Acknowledgment with the status code
   indicating the acceptance of the Binding Acknowledgment, the proxy
   mobile agent can set up the tunnel to the home agent and add a
   default route to the home agent.

Gundavelli, et al.       Expires April 19, 2007                [Page 14]

Internet-Draft              Proxy Mobile IPv6               October 2006

   If the home agent denies the Proxy Binding Update request, the proxy
   mobile agent MUST NOT advertise the mobile station's home prefix on
   the link and there by denying the mobility service to the mobile
   station.

6.5.  Emulating the Mobile Station's home link

   The mobile proxy agent on the access link emulates the mobile
   station's home link behaviour.  It makes the mobile station believe
   it is on its home link.  The Router Advertisements that the mobile
   proxy agent sends on the access link will contain the mobile
   station's home link prefix.  The other parameters in the Router
   Advertisement with respect to address configuration should be policy
   driven and may be present in the mobile station's profile.

6.6.  Tunnel Lifetime Management

   In the traditional MIPv6 model, there is a separate tunnel from the
   home agent to each mobile node that has a binding entry.  The tunnel
   end-point of each these tunnels is the respective mobile node's
   care-of address and that is unique to that mobile node.  In the
   current context, the care-of address or the tunnel end-point is the
   address of the proxy mobile agent and there could be multiple mobile
   stations attached to the same proxy mobile agent and hence the tunnel
   is a fat tunnel serving multiple mobile stations.  This is identical
   to the Mobile IPv4 model, where a tunnel between the foreign agent
   and the home agent is shared by many visiting mobile nodes.

   The life cycle of the tunnels should not be based on a single binding
   entry.  A tunnel may get created due to a single binding entry and
   later may be shared by many other nodes.  So, the tearing down logic
   of the tunnel has to be based on the number of visitors over that
   tunnel.  Implementations are free to pre-establish tunnels between
   every home agent and every proxy mobile station in the network and
   with out creating and destroying the tunnels on a need basis.

6.7.  Packet Routing

   After receiving a successful Proxy Binding Acknowledgment for the
   Proxy Binding Update request, the proxy mobile agent sets up a tunnel
   to the mobile station's home agent.

   The bi-directional tunnel between the proxy mobile agent and the home
   agent is used for routing the packets sent by the mobile station and
   also the packets that are sent to the mobile station.

Gundavelli, et al.       Expires April 19, 2007                [Page 15]

Internet-Draft              Proxy Mobile IPv6               October 2006

   The following are the details of the tunnel.

   o  Tunnel Source Address is the IPv6 Address on the egress interface

   o  Tunnel Destination Address is the home agent's address

   o  Tunnel Encapsulation Mode is IPv6/IPv6

   The proxy mobile agent functions as a default router to the mobile
   station on the access link.  Any packets that the mobile station
   sends, it will simply route them to the home agent over the tunnel.
   Any packets that the proxy mobile agent receives from this tunnel, it
   will forward them on the access link.

7.  Mobile Station Operation

7.1.  Booting for the first time

   When the mobile station attaches to a link on the access router
   running proxy mobile agent, it will present its identity to the
   network in the form of NAI as part of the access authentication
   procedure.  After performing the required access authentication
   procedures, the mobile station would be assigned a Home Network
   prefix.  Once a prefix is allocated to the mobile station, the prefix
   just follows the mobile as it moves within the network.  The network
   will ensure, the mobile station retains its home prefix and home
   address, and the reachability using its home address, and thus
   providing the required network mobility with in that portion of that
   managed network with deployed proxy mobile agents.

   After a successful access authentication, the mobile station will
   send a Router Solicitation message.  The proxy mobile agent on the
   link will respond to the Router Solicitation message with a Router
   Advertisement.  The Router Advertisement will have the mobile
   station's home prefix, default router and other address configuration
   parameters.  The address configuration parameters such as Managed
   Address Configuration, Stateful Configuration flag values will be
   consistent with the home link policy.

   If the Router Advertisement has the Managed Address Configuration
   flag set, the mobile station, as it would normally do, will send a
   DHCP Request and again the proxy mobile agent on that link will
   ensure, the mobile station gets its home address as a lease from the

Gundavelli, et al.       Expires April 19, 2007                [Page 16]

Internet-Draft              Proxy Mobile IPv6               October 2006

   DHCP server.

   If the Router Advertisement does not have the Managed Address
   Configuration flag set, the mobile station can autoconfigure itself
   by appending its link-layer address (EUI-64 format) to the advertised
   local home network prefix.

   Once the address configuration is complete, the mobile station will
   always be able to use that IPv6 address anywhere with in that managed
   network where proxy mobile agents are deployed.  Further, the mobile
   station will always get the same Address even after a reboot.

7.2.  Roaming in the Network

   As the mobile station roams with in the network, moving from one link
   to the other, it always detects its home prefix.  The proxy mobile
   agent on the attached link emulates the home link behaviour for the
   mobile station.  It makes the mobile station believe it is on its
   home link.  The Router Solicitation messages will result in a Router
   Advertisement with its home prefix, default router and other
   configuration parameters remain consistent with the home link
   properties.

7.3.  IPv6 Host Protocol Parameters

   The specification assumes the mobile station to be a normal IPv6
   host, with its protocol operation consistent with the base IPv6
   specification [1].  All aspects of Neighbor Discovery Protocol,
   including Router Discovery, Neighbor Discovery, Address Configuration
   procedures will just remain the same as to the base IPv6 ND
   Specification [1].  However, the protocol recommends the mobile
   station to adjust the following IPv6 operating parameters to the
   below recommended values for protocol efficiency and for achieving
   faster hand-offs.

   Disabling Duplicate Address Detection:

   As per this specification, the mobile station and the proxy mobile
   agent share a point to point link.  All messages including multicast
   messages with link-local scope scope sent by the mobile station or
   the proxy mobile agent are seen only by those two entities.  Further,
   the prefix that is advertised on this shared link is specific to that
   mobile station and no other node will be on this link.  Thus, the DAD

Gundavelli, et al.       Expires April 19, 2007                [Page 17]

Internet-Draft              Proxy Mobile IPv6               October 2006

   procedures in this operating environment carry very little value and
   MAY NOT be required at all.  The mobile station MAY disable Duplicate
   Address Detection (DAD) procedure on the access link, if it does not
   violate any other specification.

   Lower Default Router List Cache Time-out:

   As per the base IPv6 specification [1], each IPv6 host will 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 a default routers on that link.  The
   Router Lifetime field in the received Router Advertisement defines
   the life of this entry.

   In the current operational scenario, when the mobile station moves
   from one link to another, a new proxy mobile agent will advertise the
   prefix that is assigned for that visiting mobile station.  The mobile
   station thus believes its still on the same link and with the same
   on-link prefix as before.  However, the received Router Advertisement
   messages are from a different link-local address and thus making it
   believe there is a new default router on the link.  It is important
   that the mobile station uses the newly learnt default router as
   supposed to the previous default router.  The mobile station must
   update its default-router list with the new default router entry and
   must age out the previosly default router entry from its cache, just
   as specified in Section 6.3.5 of the base IPv6 ND specification [1].
   This action is critical for minimizing packet losses during a hand
   off period.

   On detecting a reachability problem, the mobile station will
   certainly detect the neighbor or the default router unreachability by
   performing a Neighbor Unreachability Detection procedure, but it is
   important that the mobile station 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 the proxy mobile agent has the ability to with draw the
   previous router entry, by multicasting a Router Advertisement using
   the link-local address that of the previous mobility proxy agent and
   with the Router Lifetime field set to zero, then it is possible to
   force the flush out of the Previous Default Router entry from the
   mobile station's cache.  This certainly requires the proxy mobile
   agent to notify its link-local address to the home agent as part of
   the binding update and the home agent to associate this opaque data
   with the binding cache entry so that a new proxy mobile agent can

Gundavelli, et al.       Expires April 19, 2007                [Page 18]

Internet-Draft              Proxy Mobile IPv6               October 2006

   learn the link-local address of the previous router and send a Router
   Advertisement with that link-local address.

   There are other solutions possible for this problem, including the
   usage of a virtual MAC address and a fixed link-local address for all
   the deployed proxy mobile agents in the network.  In any case, this
   is very much implementation dependent and has no bearing on the
   protocol specification.

8.  IANA Considerations

   This document defines a new flag (P) to the Binding Update message
   specified in [1].

   This document also defines new Binding Acknowledgment status values
   as described in Section 4.5.  The status values MUST be assigned from
   the same space used for Binding Acknowledgment status values in [1].

9.  Security Considerations

   The Mobile IPv6 base specification [1] requires the signaling
   messages between the home agent and the mobile node to be secured by
   the use of IPsec extension headers.

   This document introduces a new functional entity, proxy mobile agent,
   a function that will be implemented in the access routers.  This
   entity is responsible for performing the Mobile IPv6 signaling on
   behalf of the mobile station, also called as Proxy MIPv6 Signaling.

   As described in the base Mobile IPv6 specification [3], Section 5.1
   both the mobile client (in this case, its the proxy mobile agent) and
   the home agent MUST support and SHOULD use the Encapsulating Security
   Payload (ESP) header in transport mode and MUST use a non-NULL
   payload authentication algorithm to provide data origin
   authentication, data integrity and optional anti-replay protection.

   This document does not cover the security requirements for
   authorizing the mobile station for the use of the access link.  It is
   assumed that there are proper Layer-2 based authentication
   procedures, such as EAP, in place and will ensure the mobile station
   is properly identified and authorized before permitting it to access
   the network.  It is further assumed that the same security mechanism

Gundavelli, et al.       Expires April 19, 2007                [Page 19]

Internet-Draft              Proxy Mobile IPv6               October 2006

   will ensure the mobile session is not hijacked by malicious nodes on
   the access link.

   The proxy solution allows one device creating a routing state for
   some other device at the home agent.  It is important that the home
   agent has proper authorization services in place to ensure a given
   proxy mobile agent is permitted to be a proxy for a specific mobile
   station.  If proper security checks are not in place, a malicious
   node may be able to hijack a session or may do a denial-of-service
   attacks.

10.  Acknowledgments

11.  Normative References

   [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
   Specification", RFC 2460, December 1998.

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

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

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

Gundavelli, et al.       Expires April 19, 2007                [Page 20]

Internet-Draft              Proxy Mobile IPv6               October 2006

Authors' Addresses

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

   Email: [email-masked]

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

   Email: [email-masked]

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

   Email: [email-masked]

Gundavelli, et al.       Expires April 19, 2007                [Page 21]

Internet-Draft              Proxy Mobile IPv6               October 2006

Intellectual Property Statement

   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
   [email-masked].

Disclaimer of Validity

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

Copyright Statement

   Copyright (C) The Internet Society (2006).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Gundavelli, et al.       Expires April 19, 2007                [Page 22]


_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 17 Oct 2006 19:22:01 +0200

Sri Gundavelli wrote:
> Attached is the draft on Proxy Mobile IPv6 that we have posted today.
>  Please review and comment on this work.

Hi, thanks for the draft.  I have some comments.

> 4.3.  Home Network Prefix Option [in BAck]
> 

Why isn't the home network prefix sent by the HA to the proxy mobile
agent with 'proxy' Mobile Prefix Discovery, instead of BAck?

If the PMA (Proxy Mobile Agent) sends proxy BU and interprets proxy
BAcks it can also send proxy Mobile Prefix Solicitation and interpret a
proxy Mobile Prefix Advertisement, no?

> default route to the home agent.

If the PMA adds a default route each time it receives a proxy BAck it
may end up with many default routes - there should be only one (only
one is taken into account anyways).

That default route is practically a route for encapsulated packets
coming from the MN for which this proxy BAck corresponds - involves
traffic shaping or IP filters; not default route.  The default route
linking of PMA to HA should be there regardless of mobiles visiting it.

> Implementations are free to pre-establish tunnels between every home
>  agent and every proxy mobile station in the network and with out 
> creating and destroying the tunnels on a need basis.

The routes that should be pre-established (independent of MN movements)
are routes for straight traffic (not tunnel).  I don't think the tunnel
routes should be pre-established, nor post-established, should be
independent of an MN being attached to a PMA.

> The following are the details of the tunnel [on PMA].
> 

And the routing table entr(y)(ies) corresponding to this tunnel?  It's
illustrative to mention it here.

> Any packets that the mobile station sends, it [PMA] will simply route
>  them to the home agent over the tunnel.

How does PMA know to route packets coming from a mobile, to the HA?

>  the home agent MUST support and SHOULD use the Encapsulating 
> Security Payload (ESP) header in transport mode and MUST use a 
> non-NULL payload authentication algorithm to provide data origin 

Is it feasible that a secure connection PMA-HA offers security to MN
whose Home Address is not in these SAs?   Is there any security between
MN and PMA?

Alex

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 17 Oct 2006 11:02:37 -0700 (PDT)

Hi Alex,

Thanks for the review comments .. please see inline ..

On Tue, 17 Oct 2006, Alexandru Petrescu wrote:

>>  A new option, Home Network Prefix Option is defined for using it in the
>>  Binding Acknowledgment sent from the home agent to the proxy mobile agent.
>>  This option can be used for notifying the assigned Home network prefix for
>>  the mobile station.  The proxy mobile agent can use this prefix
>>  information in Router Advertisements sent to the

There is no state at the home agent for the proxy mobile agent. In this
PMIP model, there is a pre-assigned prefix on per MN basis, configured
in the policy store or at the HA. The proxy locates the HA using a AAA
query for the visiting mobile using NAI, sends a proxy binding update
to the HA. The reply has the assigned home prefix that is given for that
mobile.

> proxy Mobile Prefix Advertisement, no?

Sure. The proxy mobile agent is emulating the mobile's home link on
the access link. The home link is physically at the access link and
the home prefix is following the mobile as it roams in the network.
The designated owner of that prefix is the proxy and so I dont see
a need for this message. But, if we want the home agent to control
the life time of this prefix, we can certainly add these messages.

>>  indicating the acceptance of the Binding Acknowledgment, the proxy mobile
>>  agent can set up the tunnel to the home agent and add a default route to
>>  the home agent.
>

There is a tunnel between the home agent and the proxy mobile agent.
At the home agent, the mobile prefix is reachable via this tunnel.
When the mobile to a different link, the proxy mobile agent on that
link will establish a tunnel with the home agent. The home agent will
delete the prefix route from the prev tunnel and add it to the new
tunnel.

>From the proxy routing point of view, the tunnel is the default route.
The proxy is functioning as a default router on the access link
connecting the mobile, any traffic it receives on that link, it just
routes them on the tunnel to the home agent. The home agent after
decaps, will route the packet. So, there should be only one default
route at the proxy for each mobile.

>>  agent and every proxy mobile station in the network and with out creating
>>  and destroying the tunnels on a need basis.
>

Having pre-established tunnels in a closely managed network, avoids the
need for creating/deleting tunnel each time a mobile comes in. These are
fat tunnels supporting many mobiles as in MIPv4, so in some cases it
might be ok to pre-create the tunnel. But, adding a route over that
tunnel is based on MN's visit. But, you raised the issue of default
route, I agree we need to be clear on this as what the defaulr route
means when there are multiple MN's from different HA's.

> illustrative to mention it here.

Ok.

> How does PMA know to route packets coming from a mobile, to the HA?

There is a tunnel from PMA to the HA for each mobile. The routing
state that the PMA creates can be based on the source prefix.

- All traffic from this source prefix, route this over the tunnel t0, with
the destination as the home agent.

or

The link connecting the proxy and the mobile is a point to point link.
Adding a simple VRF for this link and on the tunnel to the home agent,
with a default route over the tunnel, will route all packets from
that link on to the tunnel.

>>  As described in the base Mobile IPv6 specification [3], Section 5.1 both
>>  the mobile client (in this case, its the proxy mobile agent) and
>>  Payload (ESP) header in transport mode and MUST use a non-NULL payload
>>  authentication algorithm to provide data origin authentication, data
>>  integrity and optional anti-replay protection.
>

The messages that the HA and PMA exchange can be secured. So, the MN's
home address is not relevant here. If there is a SA betwen the HA and
PMA, it is sufficient to secure all proxy registration messages.

Access link security is based on Layer-2 mechanisms and this doc does
not cover that. Security Considerations has covered this.

Thanks for the feedback.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 17 Oct 2006 21:12:57 +0200

Hi Sri, thanks for the response.

Sri Gundavelli wrote:
>> Why isn't the home network prefix sent by the HA to the proxy 
>> mobile agent with 'proxy' Mobile Prefix Discovery, instead of BAck?
>> 
>> 
>> 
>> 
> 
> There is no state at the home agent for the proxy mobile agent. In 
> this PMIP model, there is a pre-assigned prefix on per MN basis,

Does PMIPv6 work only with a per-MN prefix model?  Does it work when
there is a home prefix covering several MNs' home addresses?

> configured in the policy store or at the HA. The proxy locates the HA
>  using a AAA query for the visiting mobile using NAI, sends a proxy 
> binding update to the HA. The reply has the assigned home prefix that
>  is given for that mobile.

Does PMIPv6 work when the MN does _not_ use NAI for access control?
Many WiFi deployments and cellular deployments don't use NAI for access
control.

>>  BAcks it can also send proxy Mobile Prefix Solicitation and 
>> interpret a proxy Mobile Prefix Advertisement, no?
>> 
> 
> The designated owner of that prefix is the proxy and so I dont see a 
> need for this message.

Uh?  I was tempted to think the owner of that prefix is the HA and
temporarily by a certain PMA.

>>  coming from the MN for which this proxy BAck corresponds -
>> involves traffic shaping or IP filters; not default route.  The
>> default route linking of PMA to HA should be there regardless of
>> mobiles visiting it.
>> 

Makes sense.

>  routes them on the tunnel to the home agent.

I see, so PMA's default route points to the tunnel interface, and there
is no default route pointing to the egress interface.  There is a
specific route to the HA through PMA's next-hop.

Now, if there are several mobiles under PMA there would be several such
tunnel interfaces, right?  Which one should be the default?

Saying "any traffic PMA receives on its ingress link it forwards to the
tunnel to the home agent" makes probably little sense because normal
simple routing does not happen based on the src address, only on the
destination address.  No?

>>> Implementations are free to pre-establish tunnels between every 
>>> home agent and every proxy mobile station in the network and with
>>>  out creating and destroying the tunnels on a need basis.
>> 
>> The routes that should be pre-established (independent of MN 
>> movements) are routes for straight traffic (not tunnel).  I don't 
>> think the tunnel routes should be pre-established, nor 
>> post-established, should be independent of an MN being attached to 
>> a PMA.
>> 
> 
> Having pre-established tunnels in a closely managed network, avoids 
> the need for creating/deleting tunnel each time a mobile comes in.

I don't understand... the PMA-HA tunnel should exist _only_ when the MN
is under that PMA.  And, since this is prefix-per-mobile there are as
many tunnels as there are mobiles.

> These are fat tunnels supporting many mobiles as in MIPv4,

But you said there is one prefix per mobile?  There should be one tunnel
per mobile no?  No fat tunnels, no?

In MIP4 there isn't this concept of replicating the home link prefix at
each FA MN may visit.

> so in some cases it might be ok to pre-create the tunnel. But, adding
>  a route over that tunnel is based on MN's visit. But, you raised the
>  issue of default route, I agree we need to be clear on this as what 
> the defaulr route means when there are multiple MN's from different 
> HA's.

Yes, I'm interested to understand how the prototype testbed can look,
thanks, ready to read it.

>>> Any packets that the mobile station sends, it [PMA] will simply 
>>> route them to the home agent over the tunnel.
>> 

Ok, so there is prefix per mobile.  What is the PMA routing state based
on the source prefix?  Is it IP filters?  (netfilter?).   Is it traffic
shaping?

> - All traffic from this source prefix, route this over the tunnel t0,
>  with the destination as the home agent.
> 
> or
> 
> The link connecting the proxy and the mobile is a point to point 
> link. Adding a simple VRF for this link and on the tunnel to the home
>  agent, with a default route over the tunnel, will route all packets 
> from that link on to the tunnel.

What is VRF?

Is the point-to-point link an IPv6 PPP link?

>> Is it feasible that a secure connection PMA-HA offers security to 
>> MN whose Home Address is not in these SAs?   Is there any security 
>> between MN and PMA?
> 
> The messages that the HA and PMA exchange can be secured. So, the 
> MN's home address is not relevant here. If there is a SA betwen the 
> HA and PMA, it is sufficient to secure all proxy registration 
> messages.
> 
> 

Ok.  I understand PMIPv6 security itself offers no layer3 security to
the mobile node on the wireless access, and that it relies on AAA
completely to offer that.

Alex

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 17 Oct 2006 14:40:49 -0700 (PDT)

Hi Alex,

On Tue, 17 Oct 2006, Alexandru Petrescu wrote:

>>  PMIP model, there is a pre-assigned prefix on per MN basis,
>

[Sri]
Per prefix model simplifies lot of things. We can relieve the home agent
from all the ND related issues and just make it to deal with the data
path setup. Almost like a NEMO model, imagine access router (Proxy Agent)
as the mobile router and the MN home prefix as a MNP.

However, we can certainly extend this to cover the shared prefix model.
If there is enough interest, we can certainly cover that.

>>  using a AAA query for the visiting mobile using NAI, sends a proxy binding
>>  update to the HA. The reply has the assigned home prefix that

[Sri] There should be a mechanism for the access router (PMA) to identify
the node. It could be NAI, MAC or other identifier. If there is a way to
pull out the profile, it should be sufficient for this protocol to work.

>>  Sure. The proxy mobile agent is emulating the mobile's home link on the
>>  access link. The home link is physically at the access link and the home
>>  prefix is following the mobile as it roams in the network. The designated
>>  owner of that prefix is the proxy and so I dont see a need for this
>>  message.
>

[Sri] Sure. HA is the prefix aggregation point. But, its deployed in the
access network. So, the life of the prefix should be managed by that
PMA. However, I see your point. We can certainly let the HA manage the
life of the prefix.

>>  At the home agent, the mobile prefix is reachable via this tunnel. When
>>  the mobile to a different link, the proxy mobile agent on that link will
>>  establish a tunnel with the home agent. The home agent will
>>  delete the prefix route from the prev tunnel and add it to the new tunnel.
>
> Makes sense.
>
>>  The proxy is functioning as a default router on the access link connecting
>>  the mobile, any traffic it receives on that link, it just

[Sri] Sure.

> simple routing does not happen based on the src address, only on the

[Sri]
We just need to create a routing state, that says, for packets
from this prefix, this is the default route i.e tunnel interface
as the out going interface and the next hop being the home agent.

Ex: MN1 with prefix P1 as the home prefix and HA1 as the home agent
and t0 as the tunnel. MN2 with prefix P2 as the home prefix and HA2
as the home agent and t1 as the tunnel interface.

Routing will say, for all packets:

from P1 use t0 as the interface and
next hop HA1.

from P2 use t1 as the interface and
next hop HA2.

We can also create a routing state using VRF tables.
Almost all routing platforms support this.

But, as Kent says, route setup is implementation specific.

>> > >  agent and every proxy mobile station in the network and with
>>  need for creating/deleting tunnel each time a mobile comes in.
>

[Sri]
Prefix is per mobile. But a given PMA may have many visitors and so many
prefixes on its interfaces. There could multiple visitors from the
prefixes belonging to the same home agent, in that case, we just need
one tunnel. Tunnel is a shared tunnel as in MIP4.

> per mobile no?  No fat tunnels, no?

Why not ? Prefix is per mobile. Take the nemo case. There could be
multiple  MNP's on a given MR. Still there is one tunnel. Just
as you wrote in 3963

>>  the defaulr route means when there are multiple MN's from different HA's.
>

[Sri]
We can certainly add more examples.

>>  There is a tunnel from PMA to the HA for each mobile. The routing state
>>  that the PMA creates can be based on the source prefix.
>

[Sri]
Yes. Routing is based on source prefix or again using VRF's.

>>  Adding a simple VRF for this link and on the tunnel to the home
>>  agent, with a default route over the tunnel, will route all packets from

Virtual Route Forwarding. I'm sure, the terminology could be different
in different implementations. But, routing can always be divided into
domains, a specific route is always in the context of that routing domain.
Ex: MPLS.

>>  home address is not relevant here. If there is a SA betwen the HA and PMA,
>>  it is sufficient to secure all proxy registration messages.
>>
>>

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 18 Oct 2006 07:02:31 -0700 (PDT)

Hi Jean,

Thanks for the review. Comments inline ..

On Wed, 18 Oct 2006, Jean-Mickael Guerin wrote:

> Hello,
> My first idea of PMIP6 is an access router using directly MIP6
> to register multiple home addresses, each home address being
> actually mobile node's address. Assuming no change on Home agent,
> and same prefix sent by PMIP6 to mobiles.
>
> But looking at new PBU/PBA messages you introduced, it looks
> we can't do this way, could you elaborate ?
>

Access router (proxy mobile agent) is the proxy and is the entity
that is doing the binding update and we call this binding update
as proxy binding update (PBU). It is indeed using MIP6. Proxy
Binding Update is the MIP6 BU message with an additional flag
indicating to the home agent that it is a proxy registration and
thus the authorization checks have to be bit different.

The proxy mobile agent will advertise the same home prefix to
the mobile station on the access link. It emulates the home
link behaviour.

The changes in the home agent are semantical, a tunnel between the
home agent and the proxy mobile agent, that has no 1:1 relation
to a mobile station, as the tunnel can now be shared for multiple
mobiles, as in MIP4. The changes in the home agent are just
to support these minor extensions.

Regards
Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 18 Oct 2006 07:34:32 -0700

Jean-Mickael,

the current PMIPv6 draft is an individual submission.
we haven't yet decided on whether there will be per-MN
tunnel between the PMA and the HA or there will be one
tunnel for all mobile nodes, or both. my personal
preference is to allow both (I think there are
deployment scenarios for both).

its the same with per-MN security association or just
one security association between the PMA and the HA.

this will be a WG decision to be made later (once we
figure out how to standardize PMIPv6).

Vijay

Jean-Mickael Guerin wrote:
> Regards,
> Jean-Mickael

---

From: "Mohamed Khalil" <[email-masked]>
Date: Wed, 18 Oct 2006 12:09:57 -0500

I believe we should consider the following as tunnel options:

1- tunnel which could be shared between n MTs (n=1..N).
2- we should consider uni-directional tunnel, since it is needed by some
new wireless technologies.

-----Original Message-----
From: Vijay Devarapalli [mailto:[email-masked]] 
Sent: Wednesday, October 18, 2006 9:35 AM
To: Jean-Mickael Guerin
Cc: [email-masked]; Kent Leung (kleung); Sri Gundavelli
Subject: Re: [Mip6] Proxy Mobile IPv6 - I-D Submission

Jean-Mickael,

Vijay

> My first idea of PMIP6 is an access router using directly MIP6 to 
> register multiple home addresses, each home address being actually 
> mobile node's address. Assuming no change on Home agent, and same 
> prefix sent by PMIP6 to mobiles.
> 
> But looking at new PBU/PBA messages you introduced, it looks we can't 
> do this way, could you elaborate ?
> 
> Regards,
> 
> Jean-Mickael

---

From: Brian Haley <[email-masked]>
Date: Wed, 18 Oct 2006 13:49:35 -0400

Hi Sri,

A few comments on the draft inline.

>    in the role of a default router will route the traffic to the home

Alexandru also brought-up the "default route" text in this paragraph as 
an issue, I'd second a request to change per Sri's/Kent's comments. 
Section 6.4 too.

>    obtain its home address for configuring on the interface.

What Router Advertisement? :)  Assuming it's the same from page 3, maybe 
the simple fix would be to change this to "The mobile station, on 
receiving a Router Advertisement...", but maybe you should say that 
after receiving the BAck and setting up the tunnel, the MPA sends out an 
RA to the MN.

>    turn will route it on the access link.

s/and in turn/which in turn/

>    prefix Option has an alignment requirement of 8n+4.  Its format is as

s/Local Network Prefix/Home Network Prefix/

>    entries for each mobile station that gets proxy registered by a proxy

s/gets proxy registered/gets registered/

>    turned off for all the usual direct registrations.

That last sentence is kind-of implied and can be removed, right?

>    MUST reject the request and send a Proxy Binding Acknowledgment with

The way this is written, only status code 141 applies, maybe it should read:

     "The home agent MUST verify it's policy before accepting a Proxy
      Binding Update request.  If the home agent is not configured to
      accept proxy registrations, it MUST reject the request and send
      a Proxy Binding Acknowledgement with status code 140 (Proxy
      Registration not supported).  Furthermore, if the proxy mobile
      agent sending the request is not authorized, it MUST reject the
      request and send a Proxy Binding Acknowledgement with status code
      141 (Proxy Registration from this proxy mobile agent not allowed)."

>    proxy mobile agent is comparable to that of the foreign agent in

That's a really long sentence, maybe it should be 3 bullet points 
followed by "The proxy mobile agent is comparable to that of..."

>    station's profile using the presented NAI.

s/be able fetch/be able to fetch/

>    driven and may be present in the mobile station's profile.

I guess it's a policy decision on how the RA info is collected, but 
since you define a Home Network Prefix option above, why wasn't that 
contained in the profile?  Alternately, why doesn't the HA just provide 
the RA settings to the PMA?

Also, does it advertise a smaller MTU so that packets the MS sends don't 
need to get fragmented upon tunnel entry?  Or maybe pmtu discovery will 
take care of this?

>    with out creating and destroying the tunnels on a need basis.

The last part of this sentence is a little confusing, maybe you can just 
delete everything after "network".

General comment:

You use both Mobile Node and Mobile Station when referring to the same 
system in numerous places, most should be Mobile Station since that 
implies a non-MIPv6-aware node.

-Brian

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 18 Oct 2006 13:25:07 -0700

Hi Mohamed,

 > new wireless technologies.

I Agree. The tunnel management is very much implementation specific.
The draft took the same stand as well. Thanks for the feedback.

Regards
Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 18 Oct 2006 13:21:31 -0700 (PDT)

Hi Brian,

Thanks for the review. Response inline ...
with the note that its still an individual submission...

On Wed, 18 Oct 2006, Brian Haley wrote:

> Alexandru also brought-up the "default route" text in this paragraph as an 
> issue, I'd second a request to change per Sri's/Kent's comments. Section 6.4 
> too.
>

Ok. I agree.. we can add some text to be very clear on this.

> What Router Advertisement? :)  Assuming it's the same from page 3, maybe the 
> simple fix would be to change this to "The mobile station, on receiving a 
> Router Advertisement...", but maybe you should say that after receiving the 
> BAck and setting up the tunnel, the MPA sends out an RA to the MN.
>

You know : ) The line before that should have talked about when the PMA
sends the RA and about the RS it received from the MS.

Sure. We should add some text to be clear.

> s/and in turn/which in turn/

my english ! : ) sure. We need to fix the text ..

Ok.

Ok.

> That last sentence is kind-of implied and can be removed, right?

That's true.

>      141 (Proxy Registration from this proxy mobile agent not allowed)."

Thanks for the text. We can certainly incorporate it in to the doc.

> That's a really long sentence, maybe it should be 3 bullet points followed by 
> "The proxy mobile agent is comparable to that of..."
>

Ok.

Ok.

> I guess it's a policy decision on how the RA info is collected, but since you 
> define a Home Network Prefix option above, why wasn't that contained in the 
> profile?  Alternately, why doesn't the HA just provide the RA settings to the 
> PMA?
>

This was discussed. Trying to be more flexible, giving the deployments
the option to preconfigure Prefix or the HA address. Agreed.

> Also, does it advertise a smaller MTU so that packets the MS sends don't need 
> to get fragmented upon tunnel entry?  Or maybe pmtu discovery will take care 
> of this?
>

Sure. The doc will require few edits.

>
> General comment:
>
> You use both Mobile Node and Mobile Station when referring to the same system 
> in numerous places, most should be Mobile Station since that implies a 
> non-MIPv6-aware node.
>

We used the term MN, in the context of Client based MIP and MS as a pure
IPv6 host. Some places, its possible we incorrectly used one for the 
other. Thanks for the detailed comments.

Thanks again for the review.

Sri

---

From: Jean-Mickael Guerin <[email-masked]>
Date: Thu, 19 Oct 2006 10:15:33 +0200

> thus the authorization checks have to be bit different.
I can live with "PBU", simply if PBU is just BU with flag P,
 we could keep on naming it "BU", like NEMO spec and its R flag.

Regards,

Jean-Mickael

---

From: Jean-Mickael Guerin <[email-masked]>
Date: Thu, 19 Oct 2006 10:20:24 +0200

> to support these minor extensions.
We could compare to NEMO as well - a proxy MIP6 looks close to
a NEMO router able to write MN/128 addresses in place of network
prefixes, and HA (with NEMO support) keeps same semantic.

Regards,

Jean-Mickael

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 19 Oct 2006 05:16:11 -0700 (PDT)

> we could keep on naming it "BU", like NEMO spec and its R flag.

Sure. The "R" flag for the NEMO support is a good example.

Thanks
Sri