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

Versions: 00 01 02

NetLMM                                                 H. Levkowetz, Ed.
Internet-Draft                                                  Ericsson
Expires: April 8, 2007                                       G. Giaretta
                                                          Telecom Italia
                                                                K. Leung
                                                                   Cisco
                                                              M. Liebsch
                                                                     NEC
                                                              P. Roberts
                                                                Motorola
                                                              K. Nishida
                                                         NTT DoCoMo Inc.
                                                               H. Yokota
                                                               KDDI Labs
                                                        M. Parthasarathy
                                                                   Nokia
                                                         October 5, 2006


                          The NetLMM Protocol
                  draft-giaretta-netlmm-dt-protocol-02

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

Copyright Notice



Levkowetz, et al.         Expires April 8, 2007                 [Page 1]

Internet-Draft             The NetLMM Protocol              October 2006


   Copyright (C) The Internet Society (2006).

Abstract

   This document specifies an Internet protocol that allows mobile nodes
   to move around in a local mobility domain, changing their point of
   attachment within the domain, but without ever being aware at the IP
   layer that their point of attachment has changed, and maintaining
   seamless communication in the presence of such changes.  It defines
   two protocol entities, a Mobile Access Gateway and a Local Mobility
   Anchor, and a set of messages between them, that together make these
   mobility events transparent to the mobile nodes at the IP layer, as
   long as they remain within the local mobility domain.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Functional Entities  . . . . . . . . . . . . . . . . . . . . .  7
   4.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  8
       4.1.  Mobility Management  . . . . . . . . . . . . . . . . . .  9
       4.2.  Setup and Node Association . . . . . . . . . . . . . . . 12
       4.3.  Message Transport  . . . . . . . . . . . . . . . . . . . 13
       4.4.  Identity - Locator Split . . . . . . . . . . . . . . . . 16
       4.5.  Handling of Link-Local Addresses . . . . . . . . . . . . 16
   5.  Message Format and Message Types . . . . . . . . . . . . . . . 17
       5.1.  Message Format . . . . . . . . . . . . . . . . . . . . . 17
       5.2.  Location Registration  . . . . . . . . . . . . . . . . . 19
       5.3.  Location Deregistration  . . . . . . . . . . . . . . . . 20
       5.4.  Association Request  . . . . . . . . . . . . . . . . . . 20
       5.5.  Disassociation Request . . . . . . . . . . . . . . . . . 21
       5.6.  Heartbeat  . . . . . . . . . . . . . . . . . . . . . . . 21
       5.7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . 23
       5.8.  Message Status Codes . . . . . . . . . . . . . . . . . . 23
   6.  Option Format and Option Types . . . . . . . . . . . . . . . . 25
       6.1.  Option Format  . . . . . . . . . . . . . . . . . . . . . 25
       6.2.  Option Alignment . . . . . . . . . . . . . . . . . . . . 26
       6.3.  ID Option  . . . . . . . . . . . . . . . . . . . . . . . 27
       6.4.  Handle Option  . . . . . . . . . . . . . . . . . . . . . 28
       6.5.  Prefix Allocation Option . . . . . . . . . . . . . . . . 30
       6.6.  Prefix Delegation Option . . . . . . . . . . . . . . . . 31
       6.7.  Data Transport Option  . . . . . . . . . . . . . . . . . 33
       6.8.  Deregistration Timeout Option  . . . . . . . . . . . . . 34
       6.9.  Timestamp Option . . . . . . . . . . . . . . . . . . . . 35
       6.10. Vendor-Specific Option . . . . . . . . . . . . . . . . . 36
       6.11. Registration Lifetime Option . . . . . . . . . . . . . . 37
       6.12. Status Option  . . . . . . . . . . . . . . . . . . . . . 38



Levkowetz, et al.         Expires April 8, 2007                 [Page 2]

Internet-Draft             The NetLMM Protocol              October 2006


   7.  Protocol Specification . . . . . . . . . . . . . . . . . . . . 38
       7.1.  Mobile Access Gateway Operation  . . . . . . . . . . . . 38
       7.2.  Local Mobility Anchor Operation  . . . . . . . . . . . . 43
   8.  Data Transport . . . . . . . . . . . . . . . . . . . . . . . . 48
       8.1.  Forwarding of Unicast Data Packets . . . . . . . . . . . 48
       8.2.  Forwarding of Multicast Data Packets . . . . . . . . . . 49
       8.3.  Forwarding of Broadcast Data Packets . . . . . . . . . . 51
   9.  Protocol Constants and Configuration Variables . . . . . . . . 51
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 51
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 53
   12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53
   13. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 54
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
       14.1. Normative References . . . . . . . . . . . . . . . . . . 54
       14.2. Informative References . . . . . . . . . . . . . . . . . 55
   Appendix A.  MN-AR Interface considerations  . . . . . . . . . . . 56
   Appendix B.  Issues with omitting the MN Address Setup and
                Routing Setup . . . . . . . . . . . . . . . . . . . . 56
   Appendix C.  Out of scope  . . . . . . . . . . . . . . . . . . . . 57
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58
   Intellectual Property and Copyright Statements . . . . . . . . . . 60






























Levkowetz, et al.         Expires April 8, 2007                 [Page 3]

Internet-Draft             The NetLMM Protocol              October 2006


1.  Introduction

   This document specifies a protocol that allows nodes to move around
   in an access network, attaching to various points of the network
   while maintaining an IP layer configuration that does not change as
   the mobile nodes' points of attachment change.

   This protocol is not intended to solve all the problems of network-
   based IP mobility.  Over the past decade many companies and forums
   have provided many, many staff years of research, development, and
   standardization to realize all IP mobile networks and no doubt many
   more years of effort are ahead to deliver improvements to realize all
   the envisioned usage of such technology.  Such systems have added
   technology for specific link layers, and carrying IP packets over
   those link layers, support for AAA infrastructures, and mobile
   security to name a few.  Challenges still lie ahead in the form of
   for instance mobile QoS, power management and paging, and management
   of changing network conditions in the face of various mobility
   events.

   The protocol described in this memo is developed in response to the
   problem statement for network-based localized mobility [I-D.ietf-
   netlmm-nohost-ps] and attempts to satisfy the goals in the NetLMM
   goals document [I-D.ietf-netlmm-nohost-req].  It is intended
   basically to solve the problem of packet forwarding to nodes that
   change their point of attachment to the network without the use of
   any protocol support at the IP layer on the mobile node to support
   that mobility.

   This document defines operation of the protocol for use in an IPv6
   infrastructure and in support of IPv6 nodes, but the authors envision
   that with modifications the protocol could be used with an IPv4
   infrastructure or to support IPv4 nodes.  The document refers
   conscientiously to mobile nodes rather than mobile hosts because its
   operation is not limited in any way to host only support.

   This protocol has both some similarities and some clear differences
   with various IP mobility protocols the IETF has standardized in the
   past.  It is similar in that it continues the tradition of
   maintaining address continuity to mobile nodes regardless of the fact
   that those nodes have changed their points of attachment in the
   network.  It differs in that it does not require any operational
   changes in protocol operation between the mobile node and the network
   at the IP layer, in that it supports an infrastructure that embraces
   network controlled mobility operation, and in that its operation is
   limited in scope rather than globally applicable.

   The differences between this protocol and previous mobility protocols



Levkowetz, et al.         Expires April 8, 2007                 [Page 4]

Internet-Draft             The NetLMM Protocol              October 2006


   are complementary rather than contradictory.  It is quite possible to
   conceive of deployments in which mobile IP is used in a wide area to
   provide mobility services across multiple interface types or separate
   local mobility domains while NetLMM is used within a single type of
   access network or a single local mobility domain to facilitate
   mobility without involving the mobile.


2.  Terminology

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.  The key
   words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
   "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
   are to be interpreted as described in [RFC2119].

   Mobility terminology in this document follows that in RFC 3753,
   "Mobility Related Terminology" [RFC3753], with the added
   specification of some terms as they are used in this particular
   document:

   IP Link
      A set of routers, mobile nodes, and wireless access points that
      share link broadcast capability or its functional equivalent.
      This definition covers one or multiple access points under one or
      several access routers.  In the past, such a set has been called a
      subnet, but this term is not strictly correct for IPv6, since
      multiple subnet prefixes can be assigned to an IP link in IPv6.

   Access Network (revised)
      An Access Network consists of following three components: wireless
      or other access points, access routers, access network gateways
      which form the boundary to other networks and may shield other
      networks from the specialized routing protocols (if any) run in
      the Access Network; and (optionally) other internal access network
      routers which may also be needed in some cases to achieve a
      specialized routing protocol.

   Local Mobility (revised)
      Local Mobility is mobility over a restricted area of the network
      topology.  Note that, although the area of network topology over
      which the mobile node moves may be restricted, the actual
      geographic area could be quite large, depending on the mapping
      between the network topology and the wireless coverage area.







Levkowetz, et al.         Expires April 8, 2007                 [Page 5]

Internet-Draft             The NetLMM Protocol              October 2006


   Localized Mobility Management
      Localized Mobility Management is a generic term for protocols
      dealing with IP mobility management confined within the access
      network.  Localized Mobility Management signaling is not routed
      outside the access network, although a handover may trigger Global
      Mobility Management signaling.  Localized Mobility Management
      protocols exploit the locality of movement by confining movement
      related changes to the access network.

   Localized Mobility Management Protocol
      A protocol that supports localized mobility management.

   Intra-Link Mobility
      Intra-Link Mobility is mobility between wireless access points
      within an IP Link.  Typically, this kind of mobility only involves
      Layer 2 mechanisms, so Intra-Link Mobility is often called Layer 2
      mobility.  No IP link configuration is required upon movement
      since the link does not change, but some IP signaling may be
      required for the mobile node to confirm whether or not the change
      of wireless access point also resulted in a change of IP link.  If
      the IP link consists of a single access point/router combination,
      then this type of mobility is typically absent.

   Mobile Access Gateway (MAG)
      A Mobile Access Gateway (MAG) is a router embedded in a device
      that terminates a specific link layer technology to which mobile
      nodes attach themselves.  It terminates one end of the MAG of the
      connection to one or more Local Mobility Anchors and participates
      in the NetLMM protocol exchange.

   Local Mobility Anchor (LMA)
      A local mobility anchor (LMA) is a router that terminates
      connections to multiple Mobile Access Gateways, services mobility
      requests for mobile nodes moving within a NetLMM system, and
      participates in the NetLMM protocol exchange.

   NetLMM Domain
      A NetLMM domain is a set of multiple MAGs and a set of one or more
      LMAs interconnected within an access network that provides
      mobility operations for attached mobile nodes through the
      execution of the NetLMM protocol.

   NetLMM Address
      The invariant IP address of the MN inside the NetLMM domain.  For
      IPv6 it is assumed that this is an invariant routable IP address
      with global scope.





Levkowetz, et al.         Expires April 8, 2007                 [Page 6]

Internet-Draft             The NetLMM Protocol              October 2006


   NetLMM Network Prefix
      The NetLMM Network Prefix (NNP) is the IPv6 link prefix of the
      NetLMM address.


3.  Functional Entities

   The principal functional entities in a NetLMM infrastructure are the
   Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA).  An
   access network with NetLMM based mobility support may also have other
   nodes which support various other functionality such as AAA, routing,
   DNS, etc., and the functionality of these nodes may be used by the
   MAG and the LMA, but the operation of such additional nodes need not
   be changed in any way for the proper operation of the NetLMM
   protocol.


              +---------+                    +---------+
              | LMA La1 | (other LMAs)       | LMA Lb1 | (other LMAs)
              +---------+                    +---------+
                @    @                           @
               @      @                          @
              @        @                         @   (other routers)
             @          @                        @
            @            @                       @
           @              @                      @
       +-------+       +-------+             +-------+
       |MAG Ra1|       |MAG Ra2|(other MAGs) |MAG Rb1|  (other MAGs)
       +-------+       +-------+             +-------+
           *             *                       *
          * *            *                      * *
         *   *           *                     *   *
        *     *          *                    *     *
       *       *         *                   *       *
      *         *        * (other APs)      *         * (other APs)
     /\         /\       /\                /\         /\
    /AP\       /AP\     /AP\              /AP\       /AP\
   / Pa1\     / Pa2\   / Pa3\            / Pb1\     / Pb2\
   ------     ------   ------            ------     ------

      +--+      +--+      +--+            +--+
      |MN|----->|MN|----->|MN|----------->|MN|
      +--+      +--+      +--+            +--+
    Intra-link      Local        Global
    (Layer 2)      Mobility     Mobility
     Mobility





Levkowetz, et al.         Expires April 8, 2007                 [Page 7]

Internet-Draft             The NetLMM Protocol              October 2006


   Figure 1

   The Mobile Access Gateway
      The Mobile Access Gateway (MAG) is a router that a mobile node is
      attached to as the first hop router in the NetLMM infrastructure.
      The MAG is connected to the mobile node over some specific link
      provided by a link layer but the NetLMM infrastructure is agnostic
      about the link layer technology that is used.  Each MAG has its
      own identifier used in NetLMM protocol messaging between the MAG
      and the LMA.  The important interfaces between link layer specific
      functions and the NetLMM function reside on the MAG.  There are
      multiple MAGs in a NetLMM infrastructure.

   The Local Mobility Anchor
      The local mobility anchor (LMA) is a router that maintains
      reachability to a mobile node's address while the mobile node
      moves around within the NetLMM infrastructure.  It is responsible
      for maintaining forwarding information for the mobile nodes which
      includes a set of mappings to associate mobile nodes by their
      identifiers with their address information, associating the mobile
      nodes with their serving MAGs and the relationship between the LMA
      and the MAGs.  There may be one or more LMAs in a NetLMM
      infrastructure.


4.  Protocol Overview

   The protocol consists of two groups of messages.  The first group
   provides the basic mobility support, which is the end purpose of the
   protocol, while the second group provides necessary support for
   maintaining and managing association and connectivity between the
   LMAs and MAGs.

   It is not assumed that a MAG is associated with only a single LMA.
   If there exists multiple LMAs in a NetLMM Domain, each MAG would most
   likely be associated with, and potentially communicate with all the
   LMAs rather than only a single LMA.

   However, the same is not true for mobile nodes.  As they move around,
   and their traffic is routed through various MAGs, their routing state
   is handled by one specific LMA; the serving LMA does not change.  As
   for the relationship between an MN and a MAG, this should preferably
   be seen as a relationship between the MN's identity (ID) or IDs and
   the MAG or MAGs.  From the viewpoint of the NetLMM protocol, each MN
   ID, rather than each MN, is treated as a separate entity.  Normally,
   each MN ID is associated with one MAG, and traffic related to that MN
   ID is routed through one MAG; but during handover, especially in the
   case of make-before-break handover, an MN ID may be associated with



Levkowetz, et al.         Expires April 8, 2007                 [Page 8]

Internet-Draft             The NetLMM Protocol              October 2006


   multiple MAGs.

   Note that the MN ID used by the NetLMM protocol is not necessarily or
   maybe not even mostly the same as the ID the MN uses when
   authenticating.  It could be a technology-specific ID assigned by the
   network, or it could be something like the SEND key.

4.1.  Mobility Management

   The NetLMM infrastructure uses 3 messages pairs to manage the
   attachment, departure, mobility, and other activities of mobile nodes
   within the infrastructure:

   *  Location Registration / Ack
   *  Location Deregistration / Ack

   When a mobile node first attaches to a NetLMM enabled network, the
   network needs to determine if the mobile node should be provided
   service.  This can be a pre-set policy of providing service to all
   attaching nodes, or it could be a more selective policy requiring
   some authentication and authorization.  The mechanics of
   authentication and authorization is out of scope for this document.

   In order not to keep state in the network, the LMA does no AAA access
   to verify whether it may provide service or not - that is done at the
   time of authentication, and the information goes to the MAG, not to
   the LMA.  The MAG is the gateway to netlmm service, and screens for
   authorization; if authorization is given, it signals the LMA, which
   simply effectuates the commands from the MAG.

   The mobile node then needs to acquire an address (see Figure 2).
   Whether it is using stateful or stateless address configuration, the
   serving LMA needs to be involved in the address allocation process.

   This specification assumes that a separate subnet prefix is allocated
   to each mobile node, and does not cover the case of the whole NetLMM
   domain being organized as a multi-link subnet common to all mobile
   nodes in the domain.

   As a result of the mobile node connecting, the MAG sends a Location
   Registration message to an LMA containing its own ID, the LMA's ID
   and the Mobile Node's ID.  If no error is found, the LMA responds to
   the message with a Location Registration Ack message.  If the MAG
   obtains a NetLMM subnet prefix for the MN first, the MAG transfers
   this prefix to the LMA via the Location Registration message.  This
   can happen for instance if the MN acquires its address or delegated
   prefix through the use of DHCP, with the MAG acting as a DHCP relay.
   The MAG would then see the DHCP response, whereas the LMA would not.



Levkowetz, et al.         Expires April 8, 2007                 [Page 9]

Internet-Draft             The NetLMM Protocol              October 2006


   On the other hand, if the LMA obtains the NetLMM subnet prefix for
   the MN, the LMA transfers the prefix to the MAG via the Location
   Registration Ack.  The LMA creates forwarding state for packets based
   on the subnet prefix allocated to the MN.

   This document assumes that the NetLMM prefix is unique to each MN
   (per-MN subnet); therefore, the MAG and the LMA can route packets
   destined for the MN by the NetLMM subnet prefix.  The case for the
   shared prefix mode requires additional messages which are not
   specified in this memo.

   At any time while it is attached to the network, the MN may acquire
   additional addresses, through DHCP or link-specific means.  If this
   occurs, the MAG needs to update the routing state by sending a new
   Location Registration message to inform the LMA about the current set
   of addresses and prefixes allocated and / or delegated to the MN.
   Such a Location Registration message MUST contain all the valid
   addresses and prefixes associated with the MN, not only the newly
   acquired address or prefix.

   The MAG, when receiving a successful Acknowledgement to the Location
   Registration message, creates forwarding state for packets destined
   to the mobile node, also based on the subnet prefix.  In the case of
   stateless address configuration being used, the MAG also sends a
   router advertisement to the attached mobile.


























Levkowetz, et al.         Expires April 8, 2007                [Page 10]

Internet-Draft             The NetLMM Protocol              October 2006


     +-----+             +-----+             +-----+             +-----+
     | MN  |             | MAG |             | LMA |             | PDP |
     +-----+             +-----+             +-----+             +-----+
        |                   |                   |                   |
        * 1.MN Attachment   |                   |                   |
        |                   |                   |                   |
        |        2."MN_Access_Network API"      |                   |
        |        (MN ID,LMA handle)             |                   |
        |                   |                   |                   |
        |                   *                   |                   |
        |                   |                   |                   |
        |                   |3.Location Reg.    |                   |
        |                   |(MN ID,MAG handle,LMA handle,{Prefix}) |
        |                   |------------------>|                   |
        |                   |                   |                   |
        |                   |4.Acknowledgement  |                   |
        |                   |(MN ID,MAG handle,LMA handle,          |
        |                   | Prefix, Status)   |                   |
        |                   |<------------------|                   |
        .                   .                   .                   .
        .                   .                   .                   .
        .                   .                   .                   .
        |                   |                   |                   |
        |5.Router Advertisement                 |                   |
        |  (Prefix)         |                   |                   |
        |<==================|                   |                   |
        |                   |                   |                   |
        |6.IP Address DAD   |                   |                   |
        |  (Address)        |                   |                   |
        |==================>|                   |                   |

         -----  NetLMM signalling
         =====  Link-Layer signalling
         {Xxxx} Optional parameter


   Figure 2

   It is possible for the LMA to remove a mobile node from the network.
   This could be done for a number of policy specific reasons in the
   network.  The two messages used are Location Deregistration and the
   associated Acknowledgement, initiated by the LMA and acknowledged by
   the MAG.  The MAG disconnects the mobile and removes all mobile state
   in response to this message.

   When a mobile node moves from one MAG to another MAG (see Figure 3),
   the new MAG (nMAG) sends a Location Registration message to the LMA
   with the MAG handle, LMA handle and the MN ID.  The LMA responds by



Levkowetz, et al.         Expires April 8, 2007                [Page 11]

Internet-Draft             The NetLMM Protocol              October 2006


   sending an acknowledgement to the nMAG that includes the MN ID, the
   MAG handle, the LMA handle, and prefix information that the nMAG uses
   in the router advertisement for the MN, and then sends a Location
   Deregistration message to the old MAG to have it remove the state it
   has which is related to the MN.

     +-----+            +-------+           +-------+            +-----+
     | MN  |            |old MAG|           |new MAG|            | LMA |
     +-----+            +-------+           +-------+            +-----+
        |                   |                   |                   |
        * 1.MN Attachment   |                   |                   |
        |                   |                   |                   |
        |                   |       2."MN_Access_Network API"       |
        |                   |        (MN ID,LMA handle,Prefix)      |
        |                   |                   |                   |
        |                   |                   *                   |
        |                   |                   |                   |
        |                   |                   |3.Location Registration
        |                   |              (MN ID,MAG handle,LMA handle,
        |                   |                   |  {Prefix} )       |
        |                   |                   |------------------>|
        |                   |                   |                   |
        |                   |                   |4.Acknowledgement  |
        |                   |              (MN ID,MAG handle,LMA handle,
        |                   |                   |  Prefix,Status)   |
        |                   |                   |<------------------|
        |                   |                   |                   |
        |                   | 5.Location Deregistration             |
        |                   |   (MN ID, MAG handle,LMA handle)      |
        |                   |<--------------------------------------|
        |                   |                   |                   |
        |                   | 6.Acknowledgement |                   |
        |                   | (MN ID,MAG handle,LMA handle,Status)  |
        |                   |-------------------------------------->|
        |                   |                   |                   |


   Figure 3

4.2.  Setup and Node Association

   The NetLMM infrastructure uses 3 message pairs to establish and
   maintain associations between the MAGs and the LMAs:

   *  Association Request / Ack
   *  Disassociation Request / Ack





Levkowetz, et al.         Expires April 8, 2007                [Page 12]

Internet-Draft             The NetLMM Protocol              October 2006


   *  Heartbeat / Ack

   A MAG associates itself with an LMA by sending an Association Request
   message (see Figure 4) that includes its MAG handle and the supported
   data forwarding modes (such as IPv6-in-IPv6) [RFC2473].  In response
   the LMA creates an association with the MAG and populates state
   information about the association.  The LMA responds, providing an
   agreed upon data forwarding mode to the MAG.  The MAG can undo the
   relationship with the LMA through sending a Disassociation Request,
   to which the LMA responds with an acknowledgement.  Heartbeat
   messages MAY be sent between the MAG and LMA to determine the current
   status of the reachability of the other entity.  All of these
   messages may be sent optionally over an IPsec connection if
   additional security is desired.

      +-----+                                   +-----+
      | MAG |                                   | LMA |
      +-----+                                   +-----+
         |                                         |
         | Association Request                     |
         | (MAG handle, LMA handle, DataTransport) |
         |---------------------------------------->|
         |                                         |
         | Acknowledgement                         |
         | (MAG handle,LMA handle, DataTransport, Status)
         |<----------------------------------------|
         .                                         .
         .                                         .
         .    (Regular operation message flows,    .
         .     optionally Heartbeats)              .
         .                                         .
         | Disssociation Request                   |
         | (MAG handle, LMA handle)                |
         |---------------------------------------->|
         |                                         |
         | Acknowledgement                         |
         | (MAG handle,LMA handle, Status)         |
         |<----------------------------------------|


   Figure 4

4.3.  Message Transport

   The NetLMM control messages defined in this document are carried by
   the User Datagram Protocol RFC 768 [RFC0768] using well known port
   number NETLMM_UDP_PORT (TBD -- assigned by IANA -- please replace
   'NETLMM_UDP_PORT with the actual port number here and below).



Levkowetz, et al.         Expires April 8, 2007                [Page 13]

Internet-Draft             The NetLMM Protocol              October 2006


   Any implementation of the NetLMM protocol MUST include support for
   IPsec protected transport, using Encapsulating Security Payload
   [RFC4303] in transport mode.  IPsec SHOULD be used unless other means
   of protecting the NetLMM control signalling provide enough security
   within the NETLMM domain.  If IPsec is used, it MUST use a non-NULL
   authentication algorithm to provide data origin authentication.

   The message sender SHOULD include a non-zero UDP Checksum.  The
   recipient of the message MUST process and check the UDP checksum.  A
   Zero checksum SHOULD be accepted by the recipient.

   The sender and initiator of a message exchange MUST use the following
   UDP ports:

   *  Source Port: variable

   *  Destination Port: NETLMM_UDP_PORT

   When the recipient of a NetLMM message sends an Acknowledgement, the
   following UDP ports MUST be used:

   *  Source Port: variable

   *  Destination Port: Copied from the source port of the received
      message.

4.3.1.  Message Retransmission

   To ensure reliable delivery of control messages, NetLMM requires a
   positive acknowledgement from the receiver and retransmission by the
   sender for an unacknowledged message.

   Each request message has a corresponding acknowledgement message,
   which must be used to acknowledge receipt of the request message.  In
   the acknowledgements, NetLMM entities can append message options
   (defined in Section 6) according to the protocol operation (Section 4
   and Section 5).

   NetLMM entities maintain a retransmission timer T-rtx and MUST
   support the basic back-off scheme described below for the
   retransmission timeout (RTO).

   After a NetLMM control message has been sent, the NetLMM entity
   initializes T-rtx with an RTO value of RTO_INIT.  If the
   acknowledgement of the associated NetLMM control message is received
   before T-rtx has expired, T-rtx is stopped.  If T-rtx expires before
   the acknowledgement is received, the NetLMM entity retransmits the
   packet using the same sequence number as for the original packet.



Levkowetz, et al.         Expires April 8, 2007                [Page 14]

Internet-Draft             The NetLMM Protocol              October 2006


   For each retransmission, the NetLMM entity should set the new RTO
   value to twice the previous RTO duration (e.g. new_RTO = 2 *
   previous_RTO).  The RTO value SHOULD not exceed the limit of RTO_MAX
   seconds.  The value for RTO_INIT and RTO_MAX should be configurable,
   with a resolution better than 1 second (such as 1 ms, for instance).

   In case a NetLMM entity has multiple associations, an individual RTO
   must be maintained for each associated NetLMM peer entity.

   Optionally, NetLMM entities MAY use more enhanced schemes to
   dynamically re-calculate and adjust the RTO.  As an example, the RTO
   could be derived from periodic round trip time (RTT) measurements and
   RTT deviations, as utilized by the Stream Control Transport Protocol
   (SCTP) [RFC2960].  If no enhanced approach for RTO derivation is
   supported, NetLMM entities MUST use the basic approach as described
   above.

   Heartbeat messages are not considered NetLMM control messages in the
   context of this section; they are handled according to Section 5.6.1
   and are not re-transmitted.

   The default values for RTO_INIT and RTO_MAX are defined as follows:

      RTO_INIT = 1 second

      RTO_MAX = 64 seconds

4.3.2.  Message Re-ordering

   If messages from a MAG regarding a specific MN are received out-of-
   order, there are cases where an MN may be left without service unless
   care is taken to ensure processing of messages in the correct order.

   One example of such a situation is if a mobile node acquires multiple
   prefixes through DHCP, but the initial Location Registration message,
   indicating only one allocated prefix, is lost and subsequently re-
   transmitted.  Another Location Registration message, generated after
   a second prefix allocation or delegation has taken place, will
   indicate both prefixes.  If the initial Location Registration message
   is processed after the second Location Registration message, the
   Routing Cache at the LMA will only contain routing information for
   the initial prefix, not for the later prefix.

   To avoid problems due to out-of-order processing of messages, the MAG
   MUST ensure that no message pertaining to a given MN or sets of MNs
   are sent until any previous message pertaining to the same MN or MNs
   has been acknowledged by the LMA.




Levkowetz, et al.         Expires April 8, 2007                [Page 15]

Internet-Draft             The NetLMM Protocol              October 2006


4.3.3.  Message Rate-Limitation

   In addition to the retransmission mechanism, NetLMM entities MUST
   implement a configurable rate limitation, so that situations where
   message storms may occur, there is an upper limit on the number of
   messages per second that may be originated by an entity towards
   another.  The message rate limitation SHOULD be dynamic, so that when
   for instance the heartbeat mechanism indicates that the peer is
   heavily loaded, the rate limit is lowered.

4.4.  Identity - Locator Split

   The protocol has been explicitly designed to support the use of
   NetLMM node identifiers which are separate from the node locators
   (addresses).  In addition to what some may claim is a philosophically
   pleasing separation of distinct and separate functions, this provides
   some direct practical benefits:

      With nodes always being identified by their identities (called
      handles in this document) rather than by their address, the
      protocol has the potential of running unchanged on infrastructure
      using different IP addresses types, or even mixing multiple
      address types.

      A node identified by one identifier may have multiple addresses,
      belonging to multiple interfaces.  This makes it easier to design
      high-availability and high-performance hardware for the NetLMM
      nodes, without the nodes having to be individually configured with
      knowledge of the multiple interfaces and addresses which may
      belong to each of its peers.

   Note that this document does not prescribe which kind of identifiers
   should be used as LMA and MAG identifiers, and does not prescribe a
   mechanism to resolve identifiers to addresses.  By default, the
   simplest possible resolver mechanism and identifier choice is
   assumed: The use of a node's global IPv6 address as identifier, with
   the identity to location resolver function being to use the identity
   as locator.

4.5.  Handling of Link-Local Addresses

   Depending on how link-local addresses are handled, their existence
   may cause trouble for applications.

   There are a number of different ways that link-local addresses could
   be handled within a network with NetLMM mobility support:





Levkowetz, et al.         Expires April 8, 2007                [Page 16]

Internet-Draft             The NetLMM Protocol              October 2006


   a.  Link-local addresses may have network-wide scope.  This is
       discussed at length in [I-D.thaler-intarea-multilink-subnet-
       issues], and is not to be recommended.

   b.  Link-local addresses may have MAG-wide scope; i.e., all MNs
       attached to the same MAG will have link-local reachability to
       each other.  The consequence of this is that nodes may discover
       they have link-local reachability at one instant in time, but be
       deprived of it at the next instant.  In other words, because of
       node movements, nothing can really be assumed about the
       reachability of other nodes through link-local addresses from one
       moment to another.

   c.  Link-local addresses have MN-scope only, or put in a different
       way, the MN has a point-to-point link with the MAG.  In this
       case, the MN will never discover link-local addresses belonging
       to other MNs, and applications on the MN will not be in a
       position of being able to make erroneous assumptions about link-
       local reachability of other nodes.

   This document also assumes that link-local addresses are handled
   according to method c. above, which is effectively the same manner as
   global addresses are handled: The link-local addresses are unique to
   each MN, or expressed with different words, the link between the MN
   and the MAG is effectively a point-to-point link, with no other nodes
   than the MN and the MAG on the link.


5.  Message Format and Message Types

5.1.  Message Format

   An NetLMM message consists of a header followed by one or more
   options.  The message header is common and messages are distinguished
   by Type field in the header.  NetLMM options are in TLV format and
   8-octet aligned, with a Type field divided into two parts; Option
   Type and Option Sub-Type.  All option payloads whose length is not a
   unit of 8 octets must be padded to the correct alignment.

   All NetLMM messages start with the following common header.
   Parameters for each message are contained in the option format (see
   following sections).









Levkowetz, et al.         Expires April 8, 2007                [Page 17]

Internet-Draft             The NetLMM Protocol              October 2006


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Version   |      Type     |         Sequence Number       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Reserved                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                         Src ID Option                         .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                         Dst ID Option                         .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      .                                                               .
      .                            Options                            .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Version
      An 8-bit number, indicating the NetLMM protocol version.  The
      version of the NetLMM protocol specified in this document is 1.

   Type
      8-bit value indicating the NetLMM message type.  The message types
      are specified below, in following sections.

   Sequence Number
      16-bit length, used to ensure the correspondence of request and
      acknowledgement messages between the MAG and the LMA.  The
      sequence number is exchanged between given MAG and LMA, and
      configured when MAG has joined to a NetLMM domain through the
      exchange of Association Request/Acknowledgement messages.
      Sequence Number comparisons MUST be performed modulo 2^16, i.e.,
      the number is a free running counter represented modulo 65536.  A
      Sequence Number in a received message is considered less than or
      equal to the last received number if its value lies in the range
      of the last received number and the preceding 32768 values,
      inclusive.  For instance, if the last received sequence number was
      15, then messages with sequence numbers 0 through 15, as well as
      32783 through 65535, would be considered 'less than or equal'.

      Sequence numbers are unique to a MAG-LMA association, based on the
      MAG handle and LMA handle.  If a MAG or an LMA has multiple IP
      addresses, they all share one sequence number series.





Levkowetz, et al.         Expires April 8, 2007                [Page 18]

Internet-Draft             The NetLMM Protocol              October 2006


   Reserved
      32-bit field reserved for future use.  The value MUST be
      initialized to zero by the sender, and MUST be ignored by the
      receiver.

   Src ID Option
      An ID Option (Section 6.3) giving the ID of the source of the
      message

   Dst ID Option
      An ID Option giving the ID of the destination of the message.

   Options
      Any other options associated with the message.

5.2.  Location Registration

      Request Message Type: 1
      Required options: MAG handle, LMA handle, MN ID, Timestamp

      Acknowledgement Message Type: 65
      Required options: MAG handle, LMA handle, MN ID, Status

      Implementation: Mandatory
      Use: Mandatory

   The Location Registration message is sent from the MAG to the LMA
   when the MAG detects the MN having accessed the network without an IP
   address, or when an MN obtains another prefix/IP address.  The
   mobility state of the MN, in the MAG and LMA, is created or updated
   using this message.  The message may contain multiple Prefix
   Allocation (Section 6.5) and Prefix Delegation (Section 6.6) Options.

   The forwarding state for a MN is fully defined by the Prefix
   Allocation and Delegation Options if any are present.  On receipt of
   a Location Registration message containing one or more Prefix
   Allocation and / or Prefix Delegation Options, any old forwarding
   state is replaced by the forwarding state defined by the latest
   received prefix options.  If the Location Registration does not
   contain any Prefix Allocation or Prefix Delegation Option, the
   forwarding state is unchanged, and Prefix Allocation and Prefix
   Delegation Options describing the state are returned from the LMA to
   the MAG in the Location Registration Acknowledgement.

   The Location Registration Acknowledgement is sent from the LMA to the
   MAG to acknowledge the receipt of the Location Registration message.
   If the registration is successful, the LMA sends the NetLMM prefix on
   this message, which in turn is used for the Router Advertisement sent



Levkowetz, et al.         Expires April 8, 2007                [Page 19]

Internet-Draft             The NetLMM Protocol              October 2006


   by the MAG.

5.3.  Location Deregistration

      Request Message Type: 2
      Required options: MAG handle, LMA handle, MN ID

      Acknowledgement Message Type: 66
      Required options: MAG handle, LMA handle, MN ID, Status

      Implementation: Mandatory
      Use: Mandatory

   The Location Deregistration message is sent from the LMA to a MAG to
   delete the mobility state of the MN.  The LMA sends this message when
   it determines that the MN is at a new location.  This message
   contains the MN ID, MAG handle, LMA handle and may contain a
   Deregistration Timeout option, providing a delayed deregistration.

   An Acknowledgement message is sent back to the source of the Location
   Deregistration message to acknowledge the receipt of the Location
   Deregistration message.  This message may contain the applied
   deregistration delay time.

5.4.  Association Request

      Request Message Type: 16
      Required options: MAG handle, LMA handle, Data Transport

      Acknowledgement Message Type: 80
      Required options: MAG handle, LMA handle, Data Transport, Status

      Implementation: Mandatory
      Use: Mandatory

   The Association Request is used to set up the control and data plane
   relationship between the MAG and LMA.  This message is sent from the
   MAG to the LMA in the MAGs initiation phase, before it enters the
   operational phase and handles MN Location Registration.  The message
   contains the sender's ID, its functional capabilities and supported
   data forwarding modes.  The data forwarding mode specifies the tunnel
   method of the data plane (e.g., IP-in-IP).  The tunnel between the
   MAG and LMA is bidirectional, which is achieved by establishing two
   unidirectional tunnels in opposite directions.

   An acknowledgement to the the Associate Request message is sent from
   the LMA to the MAG to indicate the status of the request (success or
   error code).  If the request is successful, the receiver of the



Levkowetz, et al.         Expires April 8, 2007                [Page 20]

Internet-Draft             The NetLMM Protocol              October 2006


   request also sends back one choice from each set of capabilities
   specified in the Association Request, indicating for each capability
   the method which will be used by the two nodes.

5.5.  Disassociation Request

      Request Message Type: 17
      Required options: MAG handle, LMA handle

      Acknowledgement Message Type: 81
      Required options: MAG handle, LMA handle, Status

      Implementation: Mandatory
      Use: Mandatory

   The Disassociation Request message is sent from the MAG to the LMA or
   vice versa to tear down the control and data plane relationship
   between them.  This message contains the MAG handle and LMA handle.

   An acknowledgement of the the Disassociate Request message is sent
   from the LMN to the MAG or vice versa to indicate the status of the
   request (success or error code).

5.6.  Heartbeat

      Request Message Type: 18
      Required options: MAG handle, LMA handle

      Acknowledgement Message Type: 82
      Required options: MAG handle, LMA handle

      Implementation: Mandatory
      Use: Optional

   The Heartbeat message is sent from the MAG to LMA or vice versa to
   obtain the connectivity status.  This message contains the MAG handle
   and the LMA handle.  It MAY contain other options, such as a
   Timestamp Option.  Contrary to the case for other NetLMM messages,
   Heartbeat messages are never re-transmitted.

   The Heartbeat Ack is sent back from the node that received the
   Heartbeat message to its peer.  This message contains the MAG handle
   and the LMA ID.  It MAY contain other options, such as a Timestamp
   Option.

5.6.1.  Heartbeat Handling

   If used, Heartbeats are sent at a fixed, configurable rate,



Levkowetz, et al.         Expires April 8, 2007                [Page 21]

Internet-Draft             The NetLMM Protocol              October 2006


   determined by the HEARTBEAT_SEND_INTERVAL, and a history is kept for
   the last HEARTBEAT_HISTORY_SIZE heartbeats.  The history has a number
   of slots (equal to HEARTBEAT_HISTORY_SIZE), and each slots holds the
   Sequence Number of the Heartbeat message sent in that time-slot, the
   time at which the Heartbeat message was sent, and the number of
   Heartbeat Acknowledgements that were received during that time-slot.

   The following algorithm is used to detect connectivity and load
   problems:

   Each time a Heartbeat message is sent, the message sequence number is
   registered in the heartbeat history.  A count is also made of the
   number of received Heartbeat Acknowledgements recorded in the
   heartbeat history.  Except during startup, when the number of
   heartbeats recorded in the history is less than
   HEARTBEAT_HISTORY_SIZE, the heartbeat loss ratio is calculated as
   (heartbeats_sent - received_acks) / (heartbeats_sent).  If the ratio
   is larger than a configurable value HEARTBEAT_LOSS_THRESHOLD, an
   alarm should be raised, and the event MUST be logged.  (The heartbeat
   loss rate can be derived from the heartbeat loss ratio as loss_rate =
   loss_ratio / HEARTBEAT_SEND_INTERVAL).

   When a Heartbeat message is received by the destination node, it MUST
   respond with a Heartbeat Ack with the same Sequence Number as the
   received Heartbeat message.

   When a Heartbeat Ack is received, the count of received
   acknowledgements is increased for the current history time-slot and
   the time since the corresponding Heartbeat message was sent is
   calculated.  If the corresponding heartbeat's Sequence Number is no
   longer on record in the heartbeat history, the value
   (HEARTBEAT_SEND_INTERVAL * HEARTBEAT_HISTORY_SIZE is used).  If this
   calculated delay is larger than a configurable value
   HEARTBEAT_DELAY_THRESHOLD, an alarm should be raised, and the event
   MUST be logged.

   The Heartbeat loss rate is primarily an indication of the quality of
   the communication link, while the Heartbeat delay is primarily an
   indication of the load of the peer.  A sudden overload situation can
   also manifest as an apparent sudden in crease in loss rate, but in
   the absence of link problems, a steady state high load situation will
   show an acceptable loss rate, but a large heartbeat delay.

   An implementation of the NetLMM protocol may adjust its resend
   timeout value (RTO) based on both the heartbeat loss rate and the
   average heartbeat delay.  For instance, a RTO which is lower than the
   average heartbeat delay will result in unnecessary re-sends and added
   load in a high-load situation.



Levkowetz, et al.         Expires April 8, 2007                [Page 22]

Internet-Draft             The NetLMM Protocol              October 2006


5.7.  Acknowledgements

   An acknowledgement MUST be sent in response to any non-
   Acknowledgement message.  It is sent from the node that received the
   initial message to the originator of that message.  It indicates that
   the initial message has been received, and also carries a status
   value which indicates the result of the operation requested by the
   initial message.

   The Sequence Number field of an acknowledgement message MUST be set
   to the same value as the Sequence Number of the message which it
   acknowledges, in order to support the message re-send mechanism
   described in Section 4.3.

   The acknowledgement message MUST contain at least the Status Option
   (Section 6.12) except in the case of the Heartbeat Acknowledgement,
   but may also contain other options which are appropriate in response
   to the initial message.

5.8.  Message Status Codes

   The status codes used by the NetLMM protocol are used when
   acknowledging a message, to indicate the result of processing the
   associated request message.  The status code is carried in the Status
   Option (Section 6.12).

   The status codes are allocated in ranges, depending on their usage.
   The defined ranges are as follows:

   0 - 63: Generic Status
      This range is used for status codes which are of a generic nature,
      and not specific to MAG or LMA.

   64 - 127: LMA-specific Status
      This range is used for status codes which are specific to the
      LMAs.

   128 - 191: MAG-Specific Status
      This range is used for status codes which are specific to the
      LMAs.

   192 - 255: Reserved
      This range is reserved for future use.

   The following values are defined by this document:






Levkowetz, et al.         Expires April 8, 2007                [Page 23]

Internet-Draft             The NetLMM Protocol              October 2006


      0: Not Applicable (N/A)
         The status code is not applicable for the message.

      1: Success
         The associated request message was successfully processed.

      2: Administratively Prohibited
         An action was refused due to administrative policy reasons.

      3: Lack of Resources
         The resources needed to provide the requested service was not
         available.

      4: Invalid Message
         The NetLMM Request message was invalid or malformed.

      62: Vendor-Specific Status (Generic)
         For use with vendor-specific messages.  Additional status
         detail may be provided for instance in vendor-specific options.

      63: Experimental Status (Generic)
         For use during experimental implementation of new protocol
         features, according to "Assigning Experimental and Testing
         Numbers Considered Useful" [RFC3692]

      65: Duplicate Prefix
         Used by the LMA when an Location Registration contains an IP
         address or prefix that is duplicated in the same NetLMM domain.
         The specific invalid addresses/prefixes MUST be specified in
         Address Options.

      66: Invalid Prefix
         Used by the LMA when an Location Registration contains an IP
         address or prefix that is invalid in the same NetLMM domain.
         The specific invalid addresses/prefixes MUST be specified in
         Address Options.

      67: Over IP Address Limit
         Used by the LMA on receipt of a Location Registration message,
         if the maximum number of IP addresses or prefixes allowed for a
         MN has been exceeded.  The specific addresses/prefixes which
         were disallowed MUST be specified in Address Options.

      68: Invalid Tunnelling Method
         The proposed tunnel method is not supported or unavailable.






Levkowetz, et al.         Expires April 8, 2007                [Page 24]

Internet-Draft             The NetLMM Protocol              October 2006


      69: Already Associated
         The LMA already had the requesting MAG listed as associated.

      70: Not Associated
         The LMA received a Disassociate request from a MAG which was
         not in its MAG list.

      126: Vendor-Specific Status (LMA-specific)
         For use with vendor-specific messages.  Additional status
         detail may be provided for instance in vendor-specific options.

      127: Experimental Status (LMA-specific)
         For use during experimental implementation of new protocol
         features, according to RFC 3692.

      128: Requested Timeout Modified
         Indicates that MAG could not comply with the timeout time
         indicated by the LMA in a Location Deregistration message.  A
         message containing this error code should also contain a
         Deregistration Timeout Option indicating the timeout that will
         be applied.

      190: Vendor-Specific Status (MAG-Specific)
         For use with vendor-specific messages.  Additional status
         detail may be provided for instance in vendor-specific options.

      191: Experimental Status (MAG-specific)
         For use during experimental implementation of new protocol
         features, according to RFC 3692.


6.  Option Format and Option Types

6.1.  Option Format

   NetLMM defines a general extension mechanism using options to allow
   optional information to be carried in the control messages.  The
   options are encoded in a Type-Length-Value format, and are described
   in detail in the following.  The options carry additional information
   used for processing the message.  Up-to-date values for the option
   types are maintained in the online IANA registry of assigned numbers.
   Each option is uniquely identified by its combination of Option Type
   and Option Sub-Type.

   Format:






Levkowetz, et al.         Expires April 8, 2007                [Page 25]

Internet-Draft             The NetLMM Protocol              October 2006


       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 Sub-Type|           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Option-specific data                      |
      .                     (up to option length)                     .
      .                                                               .
      .                                                               .
      . . . .


   Option Type
      This field identifies the particular type of option serving a
      specified function.

      The Type field in the NetLMM option is split into two ranges: Type
      values of 0 through 127 (inclusive) for not skippable options and
      128 through 255 (inclusive) for skippable options.  The recipient
      of a message with an unrecognized non-skippable option MUST
      silently discard the message.  Otherwise, if no unrecognized non-
      skippable options are found, the message MUST be processed with
      any unrecognized skippable option bypassed (i.e. move to next
      option using the Length field of the unrecognized option) during
      processing by the receiver.

   Option Sub-Type
      This field indicates the sub-type of the option, and provides for
      up to 256 related Option Sub-Types with the same Option Type
      field.

   Length
      The value represents the length of the "Data" portion of the
      option, in unit of octets.

6.2.  Option Alignment

   Options are always aligned to start on an 8-octet aligned boundary,
   relative to the start of the message header.  The first 4 octets of
   an option has a fixed format, giving the Option type, sub-type, and
   length in octets.  When assembling a message, for an option which has
   a length in octets which is not a multiple of 8, zero octets are
   added after the option up to the next 8-octet-aligned boundary.  The
   option length is not adjusted to include the padding.  When parsing
   the options of a message, any octets between the end of one option
   and the next 8-octet-aligned boundary are discarded.

   In other words, if we include the padding in the figure showing



Levkowetz, et al.         Expires April 8, 2007                [Page 26]

Internet-Draft             The NetLMM Protocol              October 2006


   option field layout, we get the following for an option of total
   length N*8+3.  (Total length N*8+3 implies that the Length field has
   the value (N*8+3)-4, as the length field indicates the length of the
   option data, i.e., does not include the first 4 octets):


       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 Sub-Type|           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Option-specific data                      |
      .                     (up to option length)                     .
      .                                                               .
      .                                               +-+-+-+-+-+-+-+-+
      |                                               |   Padding...  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         ...Padding                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



6.3.  ID Option

   The ID option carries various types of identifiers.  All messages
   related to a specific MN must include an ID option providing the MN
   ID.  Multiple ID options can be included in an message.  For the
   purpose of the ID option, the ID itself is viewed as an octet
   sequence, but to avoid ID collisions, the ID is prefixed with an ID
   type.  An example for the MN ID is a NAI [RFC4282].


       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 Sub-Type|           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            ID-Type            |          Identifier...        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
      |                                                               |
      .                                                               .
      .                                                               .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+






Levkowetz, et al.         Expires April 8, 2007                [Page 27]

Internet-Draft             The NetLMM Protocol              October 2006


   Option Type
      0

   Option Sub-Type
      0

   Length
      The length of the option in octets, excluding the Type, Sub-Type
      and Length fields.

   ID-Type
      This field indicates the type of ID carried in the remainder of
      the option.
      *** Note: Check whether there already exists an applicable IANA
      registry for ID types which we could use here ***

      0: SEND [RFC3971] public key.

      1: NAI according to [RFC4282]

      2: Ethernet MAC Address

      Additional ID-Types based on cryptographically generated
      identifiers are expected to be used, but in order to allocate ID-
      Type values for such identifiers it must be clearly specified
      exactly what goes into the Identifier field in each case, to
      ensure interoperability.

   Identifier
      This is a variable-length octet sequence, which is expected to
      hold an identifier of the type indicated by the ID-Type field.

6.4.  Handle Option

   The handle option carries LMA and MAG handle entities called handles.
   For the purpose of the handle option, the handle itself is viewed as
   an octet sequence, but to avoid handle collisions, the handle is
   prefixed with an handle type.













Levkowetz, et al.         Expires April 8, 2007                [Page 28]

Internet-Draft             The NetLMM Protocol              October 2006


       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 Sub-Type|           Length              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Handle-Type          |          Identifier...        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
      |                                                               |
      .                                                               .
      .                                                               .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Option Type
      0

   Option Sub-Type
      This field indicates what the handle in this option refers to.  It
      is expected that additional Sub-Types may be defined in the
      future.

      1: LMA handle

      2: MAG handle

   Length
      The length of the option in octets, excluding the Type, Sub-Type
      and Length fields.

   Handle-Type
      This field indicates the type of handle carried in the remainder
      of the option.
      *** Note: Check whether there already exists an applicable IANA
      registry for handle types which we could use here ***

      0: SEND [RFC3971] public key.

      1: NAI according to [RFC4282]

      2: Ethernet MAC Address

      3: IPv6 Address

      Additional Handle-Types based on cryptographically generated
      identifiers are expected to be used, but in order to allocate
      Handle-Type values for such identifiers it must be clearly



Levkowetz, et al.         Expires April 8, 2007                [Page 29]

Internet-Draft             The NetLMM Protocol              October 2006


      specified exactly what goes into the Identifier field in each
      case, to ensure interoperability.

   Identifier
      This is a variable-length octet sequence, which is expected to
      hold an identifier of the type indicated by the Handle-Type field.

6.5.  Prefix Allocation Option

   This option defines the address or prefix which has been allocated to
   a mobile node.  If the address prefix length is the same as the full
   address length, it describes a single address, otherwise it describes
   a prefix allocated to the MN.  The address or prefix can be either
   IPv4 and IPv6.

      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 Sub-Type|             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Prefix    |                    Reserved                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                      Address (IPv6 case)                      +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Option Type
      1

   Option Sub-Type

      0: Indicates that the data in the Address field is an IPv6 address
         or address range.  If the Address Prefix Length is 128 this is
         an address, otherwise it is an address range with span
         determined by the given prefix length.

      1: Indicates that the data in the Address field is an IPv4
         address.







Levkowetz, et al.         Expires April 8, 2007                [Page 30]

Internet-Draft             The NetLMM Protocol              October 2006


   Length
      The length of the option in octets, excluding the Type, Sub-Type
      and Length fields.  When the Option Sub-Type is 0, the Length is
      20, and when the Sub-Type is 1, the length is 8.

   Prefix
      The number of leading bits in the Address that are valid as a
      subnet prefix.

   Address Prefix
      Variable.  The value indicates the prefix length of the prefix or
      address allocated to the mobile node.  If the prefix length is
      equal to the full address length, the option describes an address
      allocation, otherwise it describes a prefix allocation.

   Reserved
      Reserved for future use.  The value MUST be initialized to zero by
      the sender, and MUST be ignored by the receiver.

   Address:
      If the Option Sub-Type is 0, the value is an IPv6 address, while
      if the type is 1, the value is an IPv4 address.

6.6.  Prefix Delegation Option

   This option defines a prefix which has been delegated to a mobile
   node.  It is used by the MAG to inform the LMA about a prefix
   delegation to the MN which has been done through for instance DHCP.
   The prefix can be either IPv4 and IPv6.

   Typically, there will be one address or prefix allocation
   (communicated by the presence of the Prefix Allocation Option,
   (Section 6.5) taking place when a mobile node first attaches to the
   network through a MAG), with address delegations acquired later, for
   instance by the use of DHCP, and communicated by the use of the
   Prefix Delegation Option.  The LMA handles routing in the same way
   for allocated and delegated prefixes, but needs to correctly
   communicate to a new MAG the allocated and delegated prefixes so that
   the MAG can construct its Routing Advertisements correctly, if such
   are used.











Levkowetz, et al.         Expires April 8, 2007                [Page 31]

Internet-Draft             The NetLMM Protocol              October 2006


      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 Sub-Type|             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Prefix    |                    Reserved                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                      Address (IPv6 case)                      +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Option Type
      1

   Option Sub-Type

      2: Indicates that the data in the Address field is an IPv6 address
         or address range.

      3: Indicates that the data in the Address field is an IPv4
         address.

   Length
      The length of the option in octets, excluding the Type, Sub-Type
      and Length fields.  When the Option Sub-Type is 2, the Length is
      20, and when the Sub-Type is 3, the length is 8.

   Prefix
      The number of leading bits in the Address that are valid as a
      subnet prefix.

   Address Prefix
      Variable.  The value indicates the prefix length of the prefix
      delegated to the mobile node.

   Reserved
      Reserved for future use.  The value MUST be initialized to zero by
      the sender, and MUST be ignored by the receiver.







Levkowetz, et al.         Expires April 8, 2007                [Page 32]

Internet-Draft             The NetLMM Protocol              October 2006


   Address:
      If the Option Sub-Type is 2, the value is an IPv6 address, while
      if the type is 3, the value is an IPv4 address.

6.7.  Data Transport Option

   This option contains data transport methods capabilities that the MAG
   or LMA has.  This option is used by Association Request message and
   Acknowledgement to negotiate the data transport method between MAG
   and LMA.  Multiple methods can be contained in the field with the
   order of preference.  The mandatory transport method is IPv6-in-IPv6
   [RFC2473], which must be listed.

      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 Sub-Type|             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Data Transport Method 1                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                                                               ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Data Transport Method n                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Option Type
      2

   Option Sub-Type
      0

   Length
      The length of the option in octets, excluding the Type, Sub-Type
      and Length fields.

      The number of Data Transport Method fields is equal to the Length
      divided by the size, in octets, of the Data Transport Method
      field.

   Data Transport Method
      Indicates the data transport methods available at the sender in
      the case of the Association Request message.  The methods are
      listed in order of preference.  In the case of the Association
      Request Acknowledgement, only one method would be listed,
      indicating the chosen data transport method.



Levkowetz, et al.         Expires April 8, 2007                [Page 33]

Internet-Draft             The NetLMM Protocol              October 2006


      The following values are defined for the data transport method
      field by this memo:

      0: IPv6-in-IPv6

      1: GRE

      2: IPv4-in-IPv6

6.8.  Deregistration Timeout Option

   This option indicates the length, in milliseconds, to keep the
   forwarding state of a given MN active after a handover.  When used,
   this option is included in the Location Deregistration message and
   its acknowledgement.  The timeout time in the Location Deregistration
   Ack is copied from that given in the Timeout Option of the Location
   Deregistration.  If the MAG can not keep the MN state alive as long
   as the LMA has requested for some reason, the MAG can indicate the
   preferred timeout time and return error code "Requested Timeout
   Modified" instead of copying the original value.

      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 Sub-Type|             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Timeout Time                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Option Type
      3

   Option Sub-Type
      0

   Length
      4.  The length of the option in octets, excluding the Type, Sub-
      Type and Length fields.

   Timeout Time
      Indicates the preferred delay before deleting the MN forwarding
      state from the previous MAG during handover.  The value is in
      milliseconds.







Levkowetz, et al.         Expires April 8, 2007                [Page 34]

Internet-Draft             The NetLMM Protocol              October 2006


6.9.  Timestamp Option

   This option contains the timestamp value in the format of an NTP
   timestamp (RFC 4330, Section 3 [RFC4330]), and records the time when
   the message is sent.  This option can be used to detect an overtaking
   message in a race condition by comparing the timestamp values of
   messages.  Especially during handovers, if the network suffers from a
   sudden propagation delay for some reason or the MN moves rapidly
   between MAGs, the timestamp may be used to facilitate in-order
   messages processing regardless of message arrival order.  The use of
   this option requires a reliable time distribution method, such as NTP
   or GPS time synchronization, with sufficient accuracy to support fast
   moving MNs.

   If a Location Registration message received from a MAG has a
   timestamp which is earlier than the timestamp of the most recently
   received message pertaining to the same MN, special processing has to
   be done.  If the two messages are from the same MAG it indicates an
   error condition, as the lock-step message sending described in
   Section 4.3.2 should prevents this from happening.  If the two
   messages are from different MAGs, the most recently received message,
   which has a timestamp older than some previously received message
   pertaining to the same mobile node, MUST be discarded and the event
   logged.

   LMA and MAG nodes MUST support and use message timestamps in the
   Location Registration messages.

   Acknowledgements of these messages should however not carry a
   timestamp option.

   Heartbeat messages and acknowledgements may optionally contain a
   timestamp option for informational or diagnostic purposes.


      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 Sub-Type|             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Timestamp                           |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+








Levkowetz, et al.         Expires April 8, 2007                [Page 35]

Internet-Draft             The NetLMM Protocol              October 2006


   Option Type
      4

   Option Sub-Type
      0

   Length
      8.  The length of the option in octets, excluding the Type, Sub-
      Type and Length fields.

   Timestamp
      A timestamp in the 64 bit format defined for NTP timestamps
      [RFC4330].

6.10.  Vendor-Specific Option

   This option can be used by any vendor or organization that has an
   IANA-allocated SMI Network Management Private Enterprise Code.
   Details of the meaning of value field is entirely up to the defining
   vendor or organization.

      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 Sub-Type|             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Vendor/Org-ID                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                             Value                             .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Option Type
      5

   Option Sub-Type
      0.

      This field may not be assigned any value different from zero by
      the organizations using the option; only the Value field may be
      freely used.






Levkowetz, et al.         Expires April 8, 2007                [Page 36]

Internet-Draft             The NetLMM Protocol              October 2006


   Length
      The length of the option in octets, excluding the Type, Sub-Type
      and Length fields.

   Vendor/Org-ID
      The high-order octet is 0 and the low-order 3 octets are the SMI
      Network Management Private Enterprise Number [RFC2578],
      [ENTERPRISE-NUM], of the Vendor in network byte order.

   Value
      Variable.  Details defined by individual Vendors / Organizations.

6.11.  Registration Lifetime Option

   This option MAY be used to indicate a limited lifetime for the state
   created as a result of Location Registration (Section 5.2) messages.
   If no Registration Lifetime Option is used, the lifetime of the state
   is to be taken as "Infinite", but with the reservation that in cases
   where a node experiences an impending lack of resources, the Least
   Recently Used (LRU) states may be removed (garbage collected), to
   recover resources for continued operation.

      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 Sub-Type|             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Lifetime                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Option Type
      6

   Option Sub-Type
      0

   Length
      4.  The length of the option in octets, excluding the Type, Sub-
      Type and Length fields.

   Lifetime
      The lifetime in seconds, with a value between 1 and 2^32 - 2.  The
      values 0 and 2^32 - 1 are reserved, and MUST NOT be used.







Levkowetz, et al.         Expires April 8, 2007                [Page 37]

Internet-Draft             The NetLMM Protocol              October 2006


6.12.  Status Option

   This option MUST be used in Acknowledgements to indicate the status
   result of the acknowledged message.

      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 Sub-Type|             Length            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Status     |                    Reserved                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Option Type
      7

   Option Sub-Type
      0

   Length
      8.  The length of the option in octets, excluding the Type, Sub-
      Type and Length fields.

   Status
      An 8-bit number, which indicates the Status result of handling the
      acknowledged message.  Individual status codes are defined in
      Section 5.8.

   Reserved
      24-bit field reserved for future use.  The value MUST be
      initialized to zero by the sender, and MUST be ignored by the
      receiver.


7.  Protocol Specification

7.1.  Mobile Access Gateway Operation

7.1.1.  Conceptual Data Structures

   Each MAG MUST maintain a NetLMM Routing Cache and an LMA List.

   Each MAG Routing Cache entry conceptually contains the following
   fields for each attached MN:






Levkowetz, et al.         Expires April 8, 2007                [Page 38]

Internet-Draft             The NetLMM Protocol              October 2006


   *  The MN ID of the attached MN.  This identifier is acquired during
      the attach procedure and is used from the MAG to identify the
      attached MN in the Location Registration message, which is sent to
      the selected LMA.

   *  One or more global IP addresses or address prefixes of an attached
      MN.  Each IP address or prefix is acquired from an LMA through the
      Location Registration Acknowledgement or by means of local
      operation, such as when acting as a DHCP relay (see Section 4.1
      and Section 4.3.2).  According to the context of the received
      message or local indication, an IP address is set up, updated or
      removed from the Routing Cache.

   *  The LMA handle of the LMA serving an attached MN.  The serving LMA
      and its LMA handle is acquired from the LMA selection policy,
      which is out of scope of this specification.

   Each MAG MUST maintain an LMA List, which identifies all LMAs with
   which the MAG is associated.  The LMA List is used to perform
   heartbeat tests and to map an LMA handle to the associated LMA's IP
   address(es).  The LMA List also supports the procedure of bulk
   deregistrations at all or a subset of LMAs.

   The LMA List also indicates the forwarding approach which has been
   selected for an association between the MAG and a particular LMA.
   During the association procedure, an LMA selects a forwarding
   approach from the MAG's full set of forwarding capabilities.  For
   this the MAG appends a Data Transport option, which indicates its
   supported forwarding capabilities in decreasing order of preference,
   to the Association message.  The Data Transport option received back
   from the LMA in the resulting Association Acknowledgement indicates a
   single, selected forwarding approach in one Data Transport Method
   field.

   The LMA List conceptually contains the following fields for each LMA
   entry:

   *  The LMA handle of the LMA.

   *  One or more IP address(es) of the LMA.  The LMA's IP address
      information is acquired through the LMA selection policy, which is
      out of scope of this specification.  Availability of multiple LMA
      IP addresses could support operation of multi-homed LMAs.  Details
      about how to handle multiple LMA IP addresses is out of scope of
      this specification.  Message sequence numbers are per MAG - LMA
      association, based on MAG and LMA handles, not per IP address.





Levkowetz, et al.         Expires April 8, 2007                [Page 39]

Internet-Draft             The NetLMM Protocol              October 2006


   *  The selected forwarding approach for the association with an LMA.
      This field is needed in case a single forwarding approach is set
      up for the association with an LMA.

   Each MAG MAY maintain a list of available LMAs.  Such a list can
   support the LMA selection procedure and the MAG's association
   procedure.

   The list of available LMAs comprises conceptually the following
   fields for each LMA:

   *  The LMA handle of the LMA.

   *  One or more IP address(es) of the LMA.  Availability of multiple
      IP addresses could support the operation of multi-homed LMAs.
      Details about how to handle multiple IP addresses is out of scope
      of this specification.

7.1.2.  Processing NetLMM Headers

   *  The Type field MUST have a known value (Section 5.1).  Otherwise,
      the receiving node MUST discard the message and respond with an
      Error message with Status field set to "Invalid Message" ).

7.1.3.  Association Procedure

   Each Mobile Access Gateway sends an Association Request message in
   order to set up the control and data plane relationship with a given
   local mobility anchor.  The actual trigger for this message is out of
   scope of this document and may depend on network configuration
   peculiarities.  For example, the Association Request message may be
   sent during the MAG start up procedure.

   The Association Request message MUST include:

   *  the MAG handle included in a NetLMM ID option.  This identifier is
      used by the peer to identify the MAG and is included in all
      subsequent messages.

   *  the MAG's capabilities in terms of support of data transport
      methods included in a NetLMM Data Transport Option.  The MAG MUST
      insert in this option all possible tunneling methods that can be
      used with the peer LMA.  Based on configuration, it is possible
      that some tunneling methods are used only with some LMAs: in this
      case, the Association Request message MUST contain only the
      tunneling methods that are administratively permitted with that
      specific LMA.




Levkowetz, et al.         Expires April 8, 2007                [Page 40]

Internet-Draft             The NetLMM Protocol              October 2006


   When sending an Association Request, the MAG MAY create a tentative
   entry in its LMA List, including the LMA handle, IP address of the
   LMA and the proposed forwarding capabilities.  However it may be that
   the MAG does not know these data during the association procedure: in
   this case, it does not create any tentative entry in the LMA List.

   In order to complete the NetLMM association, the MAG MUST receive an
   Association Acknowledgement from the peer LMA with status 1,
   "Success".  In this case, the MAG MUST create an entry in its LMA
   List (or update the tentative entry created earlier), with the
   messages sent by the LMA in the acknowledgement.  The MAG MUST also
   update the forwarding method to the one indicated in the
   acknowledgement.

7.1.4.  Disassociate Procedure

   The Disassociation Request can be sent both by the MAG and by the LMA
   in order to tear down the control and data plane relationship between
   MAG and LMA.  The event that triggers this message is out of the
   scope of this specification; for example, the MAG may send a
   Disassociation Request to all the LMAs present in its LMA List just
   before shutting down.

   In case the Disassociate Procedure is initiated by the MAG, the MAG
   MUST include an ID Option with the its identity in the Disassociation
   Request.  When sending the Disassociation Request, the MAG MAY set
   the LMA entry related to the specific LMA as tentative.  When it
   receives an acknowledgement with status 1, "Success", the MAG MUST
   delete the correspondent entry in its LMA List.

   In case the Disassociate Procedure is initiated by the LMA, when the
   MAG receives a Disassociation Request message, it MUST validate it.
   If it is correct, it MUST delete the related entry in its LMA List
   and send an acknowledgement with status 1, "Success".  As in all
   NetLMM messages, the MAG MUST include the ID option with its
   identity.

7.1.5.  MN network access procedure

   When a new MN attaches to the network, the Mobile Access Gateway
   receives an indication.  This indication can be received by very
   different means (e.g., L2 mechanisms, AAA infrastructure) that are
   out of scope of this specification.  In any case, regardless how this
   is accomplished, the MAG receives a MN_Access_Network API event that
   carries the MN identifier (e.g., MAC address of the MN, NAI) and the
   LMA handle.

   Upon the API notification, the MAG MUST send a Location Registration



Levkowetz, et al.         Expires April 8, 2007                [Page 41]

Internet-Draft             The NetLMM Protocol              October 2006


   message to the LMA including its own handle, the handle of the LMA,
   and the identity of the MN.  How the MAG resolves the LMA handle
   received in the API into the LMA IP address is out of scope of this
   specification and is part of the NetLMM bootstrapping procedure.
   Viable options are pre-configuration or DNS resolution (in case the
   LMA handle is the FQDN of the LMA).  In case there is only one LMA in
   the local domain, this issue does not exist.

   If the location registration is successfully performed, the MAG
   receives an Location Registration Acknowledgement message from the
   LMA with Status 1, "Success".  This message also may include a NetLMM
   Network Prefix that the MAG MUST use for any mechanism it provides
   for MN address allocation, e.g., when building a Router Advertisement
   if IPv6 stateless address configuration is used.  (See [I-D.ietf-
   netlmm-mn-ar-if] for a more detailed description of this case).

   The MN can acquire an address through stateless address assignment,
   or acquire an address or prefix delegation trough stateful address
   assignment, for instance DHCP.  When using DHCP, the MAG SHOULD be
   configured to act as a DHCP relay.  In this case, the MAG may have to
   add DHCP options to ensure that address allocation or prefix
   delegation is done from the correct address pool, and to ensure that
   there is a known binding between the MN ID and the allocated address
   or delegated prefix.  If DHCP address allocation with the MAG as DHCP
   relay occurs after the initial Location Registration message, the MAG
   has to send a supplementary Location Registration message which
   informs the LMA about the additional address allocation or prefix
   delegation received from the DHCP server.

7.1.6.  MAG to MAG handover procedure

   When a MN hands over from one MAG to another, the new MAG may not
   know if the event occurred is a handover or a network attach.  This
   is because the base protocol specified in this document is agnostic
   with respect to any MAG to MAG communication that may be in place.
   Due to this reason, as for network attach, the MAG will just receive
   a trigger that a new MN has attached to the link; this trigger,
   referred to as a MN_Access_Network API event carries the MN ID and
   the LMA handle.  As mentioned above, this API event can be for
   example based on an AAA exchange.

   After receiving this API event, the MAG performs the same procedure
   as described for network access (see Section 7.1.5): it sends a
   Location Registration message containing the MN ID, the MAG handle
   and the LMA handle and receives the Acknowledgement of the Location
   Registration message, which includes the Prefixes allocated to and
   delegated to the MN.




Levkowetz, et al.         Expires April 8, 2007                [Page 42]

Internet-Draft             The NetLMM Protocol              October 2006


7.1.7.  Resource Revocation

   If the MAG receives a Location Deregistration message from the LMA,
   it MUST delete the entry related to the MN specified in the MN ID
   Option in its Routing Cache.  Moreover, the MAG MUST remove any
   forwarding state for the MN.  After doing that, the MAG MUST send an
   acknowledgement of the Location Deregistration message to the LMA
   with Status 1, "Success".

   In case the Location Deregistration contains a Deregistration Timeout
   option, the MAG MAY keep forwarding uplink packets to the LMA for the
   MN.  This may be useful in case of make before break link layer
   technologies.  The adopted timeout cannot be greater than the one
   suggested by the LMA and MUST be sent back to the LMA in the Location
   Deregistration message Acknowledgement.

7.1.8.  Network Detachment

   A MAG does not take any action if it detects that a mobile node
   detaches, but instead waits for a Location Deregistration message
   from the LMA, which will be sent by the LMA once the mobile node has
   attached through another MAG.  There will however be cases where a
   mobile node is taken out of operation, and never re-attaches to
   another MAG.  In order to handle such cases, a MAG MUST implement
   some form of garbage collection of mobile node related state on a
   Least Recently Used (LRU) basis.  This may be done by simply purging
   the oldest mobile node state entries, but this is not recommended.
   It is RECOMMENDED to instead purge state for mobile nodes which has
   least recently sent or received user traffic, and to do this when the
   remaining available resources fall below a threshold, rather than
   after fixed or configurable time has elapsed.

7.2.  Local Mobility Anchor Operation

7.2.1.  Conceptual Data Structures

   Each LMA MUST maintain a NetLMM Routing Cache and a MAG List.

   Each LMA Routing Cache entry conceptually contains the following
   fields for each MN:

   *  The MN ID of the registered MN.  This Identifier is acquired
      through the Location Registration message, which registers an
      attached MN.

   *  The MAG handle of the registered MN's serving MAG.  This
      identifier is acquired through the Location Registration message,
      which registers an attached MN.  Dependent on the context of this



Levkowetz, et al.         Expires April 8, 2007                [Page 43]

Internet-Draft             The NetLMM Protocol              October 2006


      message, the MAG handle entry is either initialized, or updated in
      case of a handover.  The MAG handle can be linked to the
      associated MAG's IP address with the help of the MAG List.

   *  One or more global IP addresses or address prefixes of a
      registered MN.  Each IP address or prefix is allocated by the LMA
      or on request of the LMA.  The MAG is informed about the allocated
      address or prefix in the Location Registration Ack message.

   Each LMA MUST maintain a MAG List, which refers to associated MAG
   entities.  The list of associated MAGs is used to perform heartbeat
   tests and to map the Routing Cache's MAG handle entries to the
   associated MAG's IP address(es).  The MAG List also supports the
   procedure of bulk deregistrations towards all or a subset of
   associated MAGs.

   The MAG List also indicates the forwarding approach which has been
   selected for the association between the LMA and a particular MAG.
   During the association procedure, an LMA selects a forwarding
   approach from the MAG's full set of forwarding capabilities.  The LMA
   receives a MAG's full set of forwarding capabilities in decreasing
   order of preferences in a Data Transport option with the Association
   message.  The LMA could selects the first forwarding approach which
   suits the LMA's forwarding capabilities, starting with the MAG's most
   preferable forwarding approach as indicated in the first Data
   Transport Method field of the Data Transport option.  Other selection
   schemes are allowed and optional.  The LMA indicates the selected
   forwarding approach back to the MAG in the Association
   Acknowledgement, which carries a Data Transport option with a single
   Data Transport Method field.

   The MAG List conceptually contains the following fields for each
   associated MAG:

   *  The MAG handle of the associated MAG.

   *  One or more IP address(es) of the associated MAG.  The MAG's IP
      address information is acquired through the Associate message.
      Availability of multiple MAG IP addresses could support operation
      of multi-homed MAGs.  Details about how to handle multiple MAG IP
      addresses is out of scope of this specification.  Message sequence
      numbers are per MAG - LMA association, based on MAG and LMA
      handles, not per IP address.

   *  The forwarding capabilities of the associated MAG.  This
      capability list is acquired from a particular MAG through the
      Associate message.  From the list of supported forwarding
      approaches, the LMA enters only the approaches to the capabilities



Levkowetz, et al.         Expires April 8, 2007                [Page 44]

Internet-Draft             The NetLMM Protocol              October 2006


      which are supported by the LMA.

   *  The forwarding setting for the associated MAG.  This field is
      needed in case the LMA configures a single forwarding approach per
      MAG association.

7.2.2.  Processing NetLMM Headers

   All NetLMM local mobility anchors MUST observe the rules described in
   Section 7.1.2 when processing NetLMM Headers.

7.2.3.  Association Procedure

   When a LMA receives an Association Request message, it MUST look up
   in its MAG list the MAG handle contained in the ID option included in
   the request.  If an entry for that MAG handle is already present in
   the MAG list, the LMA MUST send an acknowledgement to the MAG with
   status "Already Associated", and log the event.

   If an entry for the MAG handle contained in the ID option does not
   exist, the LMA MUST create it, including the parameters contained in
   the Association Request message (MAG handle, MAG IP address).  Based
   on internal policy (e.g., pre-configuration) the LMA MAY accept the
   data forwarding methods proposed by the MAG or MAY indicate a
   specific method in the Acknowledgement.  After creating the entry,
   the LMA MUST send an acknowledgement with STATUS value 1 ("Success")
   with the content described below.

   The Acknowledgement to the received Association Request message MUST
   include:

   *  the LMA handle included in a NetLMM ID option.  This identifier is
      used by the peer to identify the LMA and is included in all
      subsequent messages.

   *  the MAG handle as received from the requesting MAG in the
      Association Request message.

   *  the Data Transport option with the selected data transport method.
      The LMA MUST select one forwarding approach from the list of
      capabilities as received in the Association Request message.

   *  the Status option, indicating the result of processing the
      Association Request message.







Levkowetz, et al.         Expires April 8, 2007                [Page 45]

Internet-Draft             The NetLMM Protocol              October 2006


7.2.4.  Disassociation Procedure

   In case the Disassociate procedure is initiated by the MAG, the LMA
   MUST validate any Disassociation Request message it receives.  If it
   is correct, it MUST delete the related entry in its MAG List, mark
   related MN entries in its Routing Cache as unroutable, and send an
   Acknowledgement with status 1, "Success".  As in all NetLMM messages,
   the LMA MUST include the ID option with its identity.  If the LMA
   does not have an entry in the MAG list, it MUST respond with status
   "Not Associated", and log the event.

   In case the Disassociate Procedure is initiated by the LMA the LMA
   MUST include an ID Option with the its identity in the Disassociation
   Request.  When sending the Disassociation Request, the LMA MAY set
   the MAG entry related to the specific MAG as tentative.  When it
   receives an acknowledgement with status 1, "Success", the LMA MUST
   delete the correspondent entry in its MAG List, and mark all related
   MN entries in its Routing Cache as unroutable.

7.2.5.  MN network access procedure

   When the local mobility anchor receives a Location Registration
   message, it MUST validate it.  If the LMA does not have an entry the
   MAG list, it MUST respond with status "Not Associated", and log the
   event.  If the message is badly formed, it MUST respond with status
   "Invalid Message" and log the event.  If the message is valid, it
   MUST check if an entry for the MN identifier included in the Location
   Registration is present.  If an entry is already present, it means
   that a MAG to MAG handover has occurred: the detailed procedure for
   this event is described in Section 7.2.7.

   If an entry for that MN identifier is not present, the LMA MUST
   create a new entry with the MN ID and the MAG handle.  After creating
   the entry, it MUST send an acknowledgement of the Location
   Registration message, with status 1, "Success", including MN ID, LMA
   handle, MAG handle.  If the Location Registration message contained
   one or more Prefix Allocation or Prefix Delegation Options the LMA
   registers these in the Routing Cache, otherwise it allocates a prefix
   which it associates with the MN ID and returns this prefix to the MAG
   as part of the Location Registration Acknowledgement.  In this case,
   the returned prefix MUST be used by the MAG for any mechanism it
   provides for MN address allocation, e.g., when building a Router
   Advertisement if IPv6 stateless address configuration is used.  (See
   [I-D.ietf-netlmm-mn-ar-if] for a more detailed description of this
   case).

   In case the Location Registration is not valid or the registration
   procedure cannot be completed successfully, the LMA MUST send a



Levkowetz, et al.         Expires April 8, 2007                [Page 46]

Internet-Draft             The NetLMM Protocol              October 2006


   Acknowledgement with an appropriate Status value.

7.2.6.  MN IP address notification procedure

   At any time while it is attached to the network, the MN may also
   acquire additional addresses, through DHCP or link-specific means.
   If this occurs, the MAG will send a new Location Registration message
   to inform the LMA about the current set of addresses and prefixes
   allocated and / or delegated to the MN.  When receiving such a
   Location Registration message, the LMA replaces the existing set of
   Routing Cache entries for the given MN ID with the new set taken from
   the Location Registration message.

7.2.7.  MAG to MAG handover procedure

   When the LMA receives a Location Registration message, it MUST check
   in its Routing Cache if an entry for the MN ID carried in the message
   is already present.  If it is not, that means that the MN is
   accessing the network for the first time (see Section 7.2.5).  If an
   entry is already present in the Routing Cache, a handover has
   occurred.  In either case, the LMA MUST send back an Acknowledgement
   of the Location Registration message with Status value set to 1,
   "Success", including Prefix options which specifies the prefixes
   allocated and /or delegated to the MN.

7.2.8.  Resource Revocation

   There are cases (e.g., due to administrative reasons) where the
   forwarding state of a specific MN must be purged so that the MN is no
   more able to use the resources provided by the network.  In this
   case, based on a trigger received from the network (e.g.  AAA), the
   LMA MUST send a Location Deregistration message to the peer MAG,
   including the MN ID, the LMA handle and the MAG handle.  Optionally,
   the LMA MAY include a Deregistration Timeout option specifying the
   remaining time to keep the state of the MN in the MAG.

   The revocation procedure terminates when the LMA receives an
   Acknowledgement of the Resource Revocation message with status 1,
   "Success".

7.2.9.  Network Detachment

   If a mobile node is taken out of operation, and never re-attaches to
   another MAG, the routing state of the LMA will by default remain
   unchanged and un-purged.  In order to handle such cases, a LMA MUST
   implement some form of garbage collection of mobile node related
   state on a Least Recently Used (LRU) basis.  This may be done by
   simply purging the oldest mobile node state entries, but this is not



Levkowetz, et al.         Expires April 8, 2007                [Page 47]

Internet-Draft             The NetLMM Protocol              October 2006


   recommended.  It is RECOMMENDED to instead purge state for mobile
   nodes which has least recently sent or received user traffic, and to
   do this when the remaining available resources fall below a
   threshold, rather than after fixed or configurable time has elapsed.


8.  Data Transport

   As soon as a particular MAG has associated with an LMA and an
   attached MN has been registered with the LMA, the LMA node and the
   MAG node are responsible for forwarding the MN's data traffic
   correctly within the NetLMM domain.  Associated location and
   forwarding information is maintained within the LMA's and the MAG's
   Routing Cache.  Different forwarding mechanisms between the LMA node
   and a particular MAG node might be supported and set up during the
   MAG's association procedure.

   Network entities which have Version 1 of the NetLMM protocol
   implemented, MUST support IPv6-in-IPv6 encapsulation [RFC2473] to
   tunnel data packets between an LMA node and an associated MAG node.
   Support of other forwarding approaches are for future extensions.

8.1.  Forwarding of Unicast Data Packets

8.1.1.  Handling of hop limit field in IPv6 data packets

   According to the NetLMM default mechanism for forwarding data packets
   between a particular LMA and a MAG by means of encapsulation, LMA
   nodes and MAG nodes serve as tunnel entry-points and tunnel exit-
   points respectively.  LMAs and MAGs have to decrement the hop limit
   field of the encapsulated IPv6 header properly.  The MAG serves as
   the default gateway for an attached MN and forwards all packets from
   the MN into the tunnel, which in turn encapsulates the packet towards
   the LMA.  The LMA on receiving the packet from the MAG decapsulates
   and forwards the packet using normal forwarding procedures.  The
   packets destined towards the MN are forwarded in a similar fashion.
   The procedure of forwarding the packet decrements the hop limit.
   Hence, the hop limit will get decremented twice for any packet
   traversing the tunnel between LMA and MAG, once at the LMA and once
   at the MAG.

8.1.2.  IPv6-in-IPv6 tunnel

   LMA and MAG nodes MUST support IPv6-in-IPv6 encapsulation according
   to RFC 2473 [RFC2473] for forwarding packets within the NetLMM
   domain.  Support of other forwarding schemes is optional.  When an
   LMA node receives an IPv6 packet destined for a registered MN and
   IPv6-in-IPv6 tunneling has been selected as forwarding approach, it



Levkowetz, et al.         Expires April 8, 2007                [Page 48]

Internet-Draft             The NetLMM Protocol              October 2006


   serves as tunnel entry-point.  The LMA node decrements the hop limit
   of the data packet's IPv6 header by one and encapsulates the packet
   in the tunnel IPv6 header.  The tunnel IPv6 header might carry one or
   more extension headers.  The LMA node forwards the tunnel packet to
   the MAG node, using its own address as source address and the MAG
   node's address as destination address in the outer IPv6 header.  The
   MAG node terminates the tunnel and MUST process relevant Extension
   Headers, which might follow the encapsulating IPv6 header.  The MAG
   node forwards the data packet towards the MN after decapsulation.

   To forward uplink packets, the MAG node serves as tunnel entry-point
   and decrements the data packet's hop limit field by one before it
   encapsulates the packet in the tunnel IPv6 header.  The tunnel IPv6
   header might carry one or more extension headers.  The MAG node
   forwards the tunnel packet to the LMA node, using its own address as
   source address and the LMA node's address as destination address in
   the outer IPv6 header.  The LMA node terminates the tunnel and MUST
   process relevant Extension Headers, which might follow the
   encapsulating IPv6 header.  The LMA node forwards the data packet
   towards its final destination after decapsulation.

8.2.  Forwarding of Multicast Data Packets

8.2.1.  Link Local Multicast

   The scope of link local multicast packets is confined to the link
   between MNs and the associated MAG node.

8.2.2.  IP Multicast

   The following options have been identified to support IP multicast
   within a NetLMM domain.

      Native mode: This option implies that MAG nodes are multicast-
      enabled routers and support for IP multicast is orthogonal to the
      NetLMM protocol operation.  According to native multicast support,
      access routers terminate a multicast tree and the LMA node does
      not play any multicast-specific role in forwarding of IP multicast
      traffic.

      Tunnel mode: This option implies that MAG nodes and LMA nodes are
      both multicast-enabled routers and the IP multicast traffic is
      tunnelled via the two NetLMM nodes.  IP Multicast protocol is used
      on the tunnel between the MAG nodes and LMA nodes to set up the
      multicast forwarding path.

   MAG nodes must coordinate multicast listeners according to MLD
   operation [RFC2710] and communicate with other multicast-enabled



Levkowetz, et al.         Expires April 8, 2007                [Page 49]

Internet-Draft             The NetLMM Protocol              October 2006


   routers using IP Multicast protocol (e.g.  PIM, based on RFC 2362).
   The MAG nodes send multicast control messages in the tunnel or on the
   connected interface to reach the LMA nodes or other routers,
   respectively.  This establishes the multicast forwarding path for
   directing multicast packets to the listeners.  An example of a IP
   multicast join procedure is illustrated in Figure 5.  By default, the
   native mode of operation is REQUIRED.


      +--+          +---+            +---+              +--+
      |MN|          |MAG|            |LMA|              |MR|
      +--+          +---+            +---+              +--+
      |              |                |                  |
      |              |                |                  |
      |-MLD Report-->|                |                  |
      |              |====PIM Join===>|                  |
      |              |                |----PIM Join----.>|
      /              /                /                  /
      /              /                /                  /
      |<-------------|<===============|<-----------------|<--MC Data
      |              |                |                  |


   Figure 5: Example of IP multicast join procedure for the Tunnel Mode.
   The MR is a multicast-enabled router between the multicast source and
   the LMA node.

   The mobile node may be a multicast sender.  The MAG nodes allow
   multicast packets to be received on the interface of the mobile node
   by successfully passing any Reverse Path Forwarding (RPF) check.  All
   multicast packets that are sourced from the mobile node are tunneled
   to the LMA nodes.  The RPF check on the LMA nodes should allow these
   packets to be received on the tunnel as well.  The multicast packets
   are forwarded by the LMA nodes based on the multicast forwarding
   table, set up by IP Multicast protocol used among the routers.  An
   example of a IP multicast source sending multicast packet to the
   group is illustrated in Figure 6.














Levkowetz, et al.         Expires April 8, 2007                [Page 50]

Internet-Draft             The NetLMM Protocol              October 2006


      +--+          +---+            +---+              +--+
      |MN|          |MAG|            |LMA|              |MR|
      +--+          +---+            +---+              +--+
      |              |                |                  |
      |              |                |<----PIM Join-----|
      /              /                /                  /
      /              /                /                  /
      |              |                | forward to group |
      |-- MC Data--.>|===============>|----------------.>|--.>
      |              |                |                  |


   Figure 6: Example of a mobile node sourcing multicast packets to the
   group.

8.3.  Forwarding of Broadcast Data Packets

   Version 1 of the NetLMM protocol specification does not consider
   forwarding of broadcast data packets.


9.  Protocol Constants and Configuration Variables


10.  Security Considerations

   The NetLMM protocol consists of messages between MAG and LMA nodes.
   The messages are used to create, update and delete mobility state in
   MAGs and LMAs.  The threats are described in [I-D.ietf-netlmm-
   threats].  To address these threats, NetLMM protocol must support
   data origin authentication, integrity and replay protection on a per-
   packet basis.  IPsec [RFC2401] MUST be implemented and SHOULD be
   used.

   There are several details that should be considered when IPsec is
   used for protecting the messages.


      The IP addresses and NETLMM-UDP-PORT SHOULD be used as selectors
      for identifying the control messages.  By including the port, only
      control messages are protected with IPsec.


      IPsec MUST be used in transport mode between MAG and LMA.  Though
      AH [RFC4302] provides protection for the addresses in the IP
      header, ESP [RFC4303] provides the same by checking the IP address
      against the selectors in the SAD [RFC2401].  Thus, ESP [RFC4303]
      with non-NULL authentication is sufficient to provide the



Levkowetz, et al.         Expires April 8, 2007                [Page 51]

Internet-Draft             The NetLMM Protocol              October 2006


      necessary protection for the control messages.


      IPsec can provide anti-replay protection when dynamic keying is
      used.  IPsec does not guarantee correct ordering of packets, only
      that they have not been replayed.  Hence, when dynamic keying is
      used along with the sequence numbers in the NetLMM messages,
      replay and re-ordering attacks can be prevented.  Note that the
      re-ordering attack makes sense only if the messages that are re-
      ordered relates to the same mobile node.  IKE [RFC2409] MUST be
      used for dynamic keying.  IKEv2 [RFC4306] MAY be supported.


      Dynamic keying [RFC2409], [RFC4306] supports several
      authentication mechanisms.  Pre-shared keys are difficult to
      configure and maintain when the number of nodes (MAG and LMA) are
      large as there needs to be one pre-shared key between any possible
      combination of LMA and MAG.  Hence, certificate based IKE
      authentication SHOULD be supported.  This does not require a
      global PKI.  The certificates may be signed by the local operator
      that deploys the netlmm service.  The use of IKE with certificates
      including the various identities is described in [I-D.ietf-
      pki4ipsec-ikecert-profile]


      MAG can dynamically associate with any LMA in the NetLMM domain.
      If the LMA knows the IP addresses of all the MAG in the NetLMM
      domain a priori before the IKE session is setup, then the
      appropriate SPD entries can be setup beforehand which can be
      consulted before engaging in the IKE session.  Even if the LMA
      does not have any knowledge about the IP addresses of the MAG, it
      can use the named SPD entry [RFC2401] and later when the IKE
      negotiation is successfully completed, the SPD entry can be added.

   IPsec provides data origin authentication based on the identity
   verified when the IPsec security association is setup using IKE.  The
   identity carried within IKE is different from the ID described in
   this document.  As part of IPsec processing, the receiver of an IPsec
   protected datagram verifies that the selectors from the IP header
   matches against the values stored in the SAD that were established
   during IKE.  In the case of NETLMM, the IP address and the port
   number would be verified to be consistent with the ones that was
   presented during SA establishment.  But this verification is not
   sufficient to authorize the node (LMA or MAG) to send arbitrary
   NetLMM messages.

   When the NetLMM message is processed, the source ID should be mapped
   to the corresponding IP address using whatever mechanism available



Levkowetz, et al.         Expires April 8, 2007                [Page 52]

Internet-Draft             The NetLMM Protocol              October 2006


   (not described in this document) and matched against what was
   received in the packet.  If there is a mismatch-match, the packet
   should be dropped.  Additionally, the following checks should be
   performed.

   *  The Location registration can be originated only by the MAG.
      Hence, the MAG MUST drop all Location Registration messages
      originated by the LMA.

   *  The Location deregistration message may be originated by the MAG
      or LMA to delete the forwarding state.  Proper authorization
      checks must be performed to make sure that the forwarding state is
      deleted only by the entity (LMA or MAG) that created it.  There
      are two cases.

      -  In the handover scenario, the deregistration message comes from
         the LMA towards the old/previous MAG.  The MAG MUST check to
         see if the LMA handle in the deregistration request matches the
         value stored in the MAG Routing cache entry for the given
         MN-ID.

      -  In case where the MAG detects that the MN has detached, it
         sends the deregistration message to the LMA.  The LMA MUST
         check to see if the MAG-ID in the deregistration request
         matches the value stored in the LMA Routing cache entry for the
         given MN-ID.

   *  The MAG MUST drop all associate messages coming from LMA.

   *  It is possible to filter the signalling messages at the edge of
      the network so that a rogue MN or rogue node on the Internet
      cannot source such messages.  If this is done, any messages
      exchanged between the MAG and LMA can only come from within the
      network.  This level of security may be sufficient for some
      deployments, precluding the need for protecting the signalling
      messages.  In such cases, IPsec may not need to be used to protect
      the signalling messages.


11.  IANA Considerations


12.  Contributors

   This contribution is a joint effort of the NetLMM design team of the
   NetLMM WG.  The members include Kent Leung, Gerardo Giaretta, Phil
   Roberts, Marco Liebsch, Katsutoshi Nishida, Hidetoshi Yokota, Henrik
   Levkowetz, and Mohan Parthasarathy.



Levkowetz, et al.         Expires April 8, 2007                [Page 53]

Internet-Draft             The NetLMM Protocol              October 2006


13.  Acknowledgments


14.  References

14.1.  Normative References

   [I-D.ietf-netlmm-mn-ar-if]
              Laganier, J., "Network-based Localized Mobility Management
              Interface between Mobile Node and Access Router",
              draft-ietf-netlmm-mn-ar-if-01 (work in progress),
              June 2006.

   [I-D.ietf-netlmm-nohost-ps]
              Kempf, J., "Problem Statement for Network-based Localized
              Mobility Management", draft-ietf-netlmm-nohost-ps-05 (work
              in progress), September 2006.

   [I-D.ietf-netlmm-nohost-req]
              Kempf, J., "Goals for Network-based Localized Mobility
              Management (NETLMM)", draft-ietf-netlmm-nohost-req-04
              (work in progress), August 2006.

   [I-D.ietf-netlmm-threats]
              Kempf, J. and C. Vogt, "Security Threats to Network-Based
              Localized Mobility Management",
              draft-ietf-netlmm-threats-04 (work in progress),
              September 2006.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.

   [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
              (IKE)", RFC 2409, November 1998.

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

   [RFC2578]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Structure of Management Information
              Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.




Levkowetz, et al.         Expires April 8, 2007                [Page 54]

Internet-Draft             The NetLMM Protocol              October 2006


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

   [RFC3753]  Manner, J. and M. Kojo, "Mobility Related Terminology",
              RFC 3753, June 2004.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC4282]  Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
              Network Access Identifier", RFC 4282, December 2005.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
              December 2005.

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

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

   [RFC4330]  Mills, D., "Simple Network Time Protocol (SNTP) Version 4
              for IPv4, IPv6 and OSI", RFC 4330, January 2006.

14.2.  Informative References

   [ENTERPRISE-NUM]
              IANA, "IANA Enterprise Numbers Registry"", 2006.

   [I-D.ietf-pki4ipsec-ikecert-profile]
              Korver, B., "The Internet IP Security PKI Profile of
              IKEv1/ISAKMP, IKEv2, and PKIX",
              draft-ietf-pki4ipsec-ikecert-profile-11 (work in
              progress), September 2006.

   [I-D.thaler-intarea-multilink-subnet-issues]
              Thaler, D., "Issues With Protocols Proposing Multilink
              Subnets", draft-thaler-intarea-multilink-subnet-issues-00
              (work in progress), March 2006.

   [RFC2960]  Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
              Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
              Zhang, L., and V. Paxson, "Stream Control Transmission
              Protocol", RFC 2960, October 2000.

   [RFC3692]  Narten, T., "Assigning Experimental and Testing Numbers
              Considered Useful", BCP 82, RFC 3692, January 2004.



Levkowetz, et al.         Expires April 8, 2007                [Page 55]

Internet-Draft             The NetLMM Protocol              October 2006


Appendix A.  MN-AR Interface considerations

   This document assumes that the MN-AR interface document will describe
   the following in more detail:

   *  - A mechanism for indicating duplicate address to the MN

   *  - No redirects should be sent by MAG to MN even if the destination
      is directly connected to MAG

   *  - Trigger for IP address configuration

   *  - MN Identifier option in the trigger ?

   *  - If SEND is used, Proxy SEND details are needed for defending the
      address in the case of a duplicate

   *  - Router advertisement details : unicast only, what else does it
      contain etc."


Appendix B.  Issues with omitting the MN Address Setup and Routing Setup

   The design team currently considers optimization of the handover
   related signaling.  This focuses in particular on reducing the
   handover signaling from two handshakes to one handshake between the
   nMAG and the LMA.  The 00 version of the draft specifies different
   messages to notify the arrival of an MN to the LMA by means of
   indicating the MNID (Location Registration) and to setup routing
   states by means of indicating the MN's IP address information (MN
   Address Setup and Routing Setup).

   In most handover cases, explicit signaling of the MN's IP address by
   means of the MN Address Setup and Routing Setup is not required in
   case the Location Registration Req/Ack could append IP Address
   options.  This brings up the question whether or not NetLMM operation
   needs the MN Address Setup message at all.

   The MN Address Setup has been specified in particular to notify an
   MN's IP address from a MAG to the LMA, which includes adding new IP
   addresses to an existing state at the LMA.  Referring to the agreed
   per-MN Prefix addressing model for NetLMM, the LMA and MAG could take
   routing decisions solely based on the MN's prefix.  Since delegation
   of the MN's prefix is performed through the LMA, which notifies the
   MN through the MAG about the assigned prefix, the LMA is aware of the
   MN's (delegated) prefix after having sent the Location Registration
   Acknowledgement.  Sending the MN's full IP address back to the LMA by
   means of the MN Address Setup message is required only if the LMA



Levkowetz, et al.         Expires April 8, 2007                [Page 56]

Internet-Draft             The NetLMM Protocol              October 2006


   takes routing decisions on the full IP address.  Other reasons might
   exist.

   As taking routing decisions on the LMA based on the full IP address
   is only mandatory for the shared prefix addressing model, which is
   not supported in the base NetLMM protocol, the design team considers
   omitting the MN Address Setup message.  However, explicit
   notification of the MN's full IP address could still be done by means
   of appending the NetLMM Address option to an existing message, such
   as the Location Registration message.  Such an approach conceptually
   overloads the Location Registration message and eliminates the
   conceptual split between messages handling IDs and routing
   information.  The design team should take a decision from the
   following approaches:

   1.  Keep MN Address Setup and Routing Setup messages and specify an
       approach to piggyback these messages with a Location Registration
       Req/Ack.

   2.  Keep MN Address Setup and Routing Setup messages to be flexible
       for specific scenarios, such as notification of the full MN IP
       address to the LMA, but allow overloading the Location
       Registration (append NetLMM Address options).

   3.  Omit the MN Address Setup message and allow overload the Location
       Registration message (append NetLMM Address options).

   4.  Other alternatives.


Appendix C.  Out of scope

   *  Inter-MAP handover

   *  Fast handover

   *  Hierarchical MAP














Levkowetz, et al.         Expires April 8, 2007                [Page 57]

Internet-Draft             The NetLMM Protocol              October 2006


Authors' Addresses

   Henrik Levkowetz (editor)
   Ericsson
   Torsgatan 71
   Stockholm  S-113 37
   SWEDEN

   Phone: +46 708 32 16 08
   Email: henrik@levkowetz.com


   Gerardo Giaretta
   Telecom Italia
   via Reiss Romoli 274
   Torino  10148
   Italy

   Phone: +39 011 228 6904
   Email: gerardo.giaretta@telecomitalia.it


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

   Phone: +1 408 853 9580
   Email: kleung@cisco.com


   Marco Liebsch
   NEC Network Laboratories
   Kurfuersten-Anlage 36
   Heidelberg,   69115
   Germany

   Phone: +49 6221-90511-46
   Email: marco.liebsch@netlab.nec.de











Levkowetz, et al.         Expires April 8, 2007                [Page 58]

Internet-Draft             The NetLMM Protocol              October 2006


   Phil Roberts
   Motorola
   1301 E Algonquin Rd
   Schaumberg, IL  60196
   USA

   Email: phil.roberts@motorola.com


   Katsutoshi Nishida
   NTT DoCoMo Inc.
   3-5 Hikarino-oka, Yokosuka-shi
   Kanagawa,
   Japan

   Phone: +81 46 840 3545
   Email: nishidak@nttdocomo.co.jp


   Hidetoshi Yokota
   KDDI R&D Laboratories, Inc.
   2-1-15 Ohara, Fujimino
   Saitama,   356-8502
   Japan

   Phone: +81 49 278 7894
   Email: yokota@kddilabs.jp


   Mohan Parthasarathy
   Nokia


   Email: mohan.parthasarathy@nokia.com

















Levkowetz, et al.         Expires April 8, 2007                [Page 59]

Internet-Draft             The NetLMM Protocol              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
   ietf-ipr@ietf.org.


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.










Levkowetz, et al.         Expires April 8, 2007                [Page 60]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/