]> Ericsson

Torsgatan 71 S-113 37 Stockholm SWEDEN +46 708 32 16 08 henrik@levkowetz.com

Motorola

1301 E Algonquin Rd Schaumberg IL 60196 USA phil.roberts@motorola.com

Internet Internet-Draft 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.

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 standardisation 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 was developed in response to the problem statement for network-based localised mobility and attempts to satisfy the goals in the NetLMM goals document. 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 standardised 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 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.

The first version of the protocol described here was developed by the NetLMM working group design team between January and November of 2006, and described in . The continuation of that work, contained in this document, is based squarely on the good work of the design team. The design team members, and authors of the design team protocol document, were: Kent Leung, Cisco, 170 W. Tasman Drive, San Jose, CA 95134, USA. Phone: +1 408 853 9580, Email: kleung@cisco.com Gerardo Giaretta, Telecom Italia, via Reiss Romoli 274, 10148 Torino, Italy. Phone: +39 011 228 6904, Email: gerardo.giaretta@telecomitalia.it Marco Liebsch, NEC Network Laboratories, Kurfuersten-Anlage 36, 69115, Heidelberg Germany. Phone: +49 6221-90511-46, Email: marco.liebsch@netlab.nec.de 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, 356-8502 Saitama, Japan. Phone: +81 49 278 7894, Email: yokota@kddilabs.jp Mohan Parthasarathy, Nokia, Email: mohan.parthasarathy@nokia.com Phil Roberts, Motorola, 1301 E Algonquin Rd, Schaumberg, IL 60196, USA. Email: phil.roberts@motorola.com Henrik Levkowetz (editor), Ericsson, Torsgatan 71, Stockholm S-113 37, Sweden. Phone: +46 708 32 16 08 Email: henrik@levkowetz.com

In this document, several words are used to signify the requirements of the specification. These words are often capitalised. 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 . Mobility terminology in this document follows that in RFC 3753, "Mobility Related Terminology" , with the added specification of some terms as they are used in this particular document: 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. 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 specialised 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 specialised routing protocol. 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. Localised Mobility Management is a generic term for protocols dealing with IP mobility management confined within the access network. Localised Mobility Management signalling is not routed outside the access network, although a hand-over may trigger Global Mobility Management signalling. Localised Mobility Management protocols exploit the locality of movement by confining movement related changes to the access network. A protocol that supports localised mobility management. 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 signalling 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. 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. 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. 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. 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. The NetLMM Network Prefix (NNP) is the IPv6 link prefix of the NetLMM address.

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.

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

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

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 hand-over, especially in the case of make-before-break hand-over, an MN ID may be associated with 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.

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 authorisation. The mechanics of authentication and authorisation 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 authorisation; if authorisation 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 organised 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. 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.

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

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

The NetLMM infrastructure uses 3 message pairs to establish and maintain associations between the MAGs and the LMAs: Association Request / Ack Disassociation Request / Ack 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) . 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.

| | | | Acknowledgement | | (MAG handle,LMA handle, Data-Transport, Status) |<----------------------------------------| . . . . . (Regular operation message flows, . . optionally Heartbeats) . . . | Disssociation Request | | (MAG handle, LMA handle) | |---------------------------------------->| | | | Acknowledgement | | (MAG handle,LMA handle, Status) | |<----------------------------------------| ]]> Figure 4

The NetLMM control messages defined in this document are carried by the User Datagram Protocol RFC 768 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). Any implementation of the NetLMM protocol MUST include support for IPsec protected transport, using Encapsulating Security Payload 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.

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 ) according to the protocol operation ( and ). 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 initialises 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. 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 utilised by the Stream Control Transport Protocol (SCTP) . 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 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

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.

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.

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.

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: Link-local addresses may have network-wide scope. This is discussed at length in , and is not to be recommended. 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. 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.

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

An 8-bit number, indicating the NetLMM protocol version. The version of the NetLMM protocol specified in this document is 1. 8-bit value indicating the NetLMM message type. The message types are specified below, in following sections. 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. 32-bit field reserved for future use. The value MUST be initialised to zero by the sender, and MUST be ignored by the receiver. An ID Option () giving the ID of the source of the message An ID Option giving the ID of the destination of the message. Any other options associated with the message.

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 () and Prefix Delegation () 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 by the MAG.

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.

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

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

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.

If used, Heartbeats are sent at a fixed, configurable rate, 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.

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 . The acknowledgement message MUST contain at least the Status Option () except in the case of the Heartbeat Acknowledgement, but may also contain other options which are appropriate in response to the initial message.

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 (). The status codes are allocated in ranges, depending on their usage. The defined ranges are as follows: This range is used for status codes which are of a generic nature, and not specific to MAG or LMA. This range is used for status codes which are specific to the LMAs. This range is used for status codes which are specific to the LMAs. This range is reserved for future use. The following values are defined by this document: The status code is not applicable for the message. The associated request message was successfully processed. An action was refused due to administrative policy reasons. The resources needed to provide the requested service was not available. The NetLMM Request message was invalid or malformed. For use with vendor-specific messages. Additional status detail may be provided for instance in vendor-specific options. For use during experimental implementation of new protocol features, according to "Assigning Experimental and Testing Numbers Considered Useful" 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. 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. 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. The proposed tunnel method is not supported or unavailable. The LMA already had the requesting MAG listed as associated. The LMA received a Disassociate request from a MAG which was not in its MAG list. For use with vendor-specific messages. Additional status detail may be provided for instance in vendor-specific options. For use during experimental implementation of new protocol features, according to RFC 3692. 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. For use with vendor-specific messages. Additional status detail may be provided for instance in vendor-specific options. For use during experimental implementation of new protocol features, according to RFC 3692.

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:

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 unrecognised non-skippable option MUST silently discard the message. Otherwise, if no unrecognised non-skippable options are found, the message MUST be processed with any unrecognised skippable option bypassed (i.e. move to next option using the Length field of the unrecognised option) during processing by the receiver. 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. The value represents the length of the "Data" portion of the option, in unit of octets.

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

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 .

0 0 The length of the option in octets, excluding the Type, Sub-Type and Length fields. 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 *** SEND public key. NAI according to 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. This is a variable-length octet sequence, which is expected to hold an identifier of the type indicated by the ID-Type field.

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.

0 This field indicates what the handle in this option refers to. It is expected that additional Sub-Types may be defined in the future. LMA handle MAG handle The length of the option in octets, excluding the Type, Sub-Type and Length fields. 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 *** SEND public key. NAI according to Ethernet MAC Address 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 specified exactly what goes into the Identifier field in each case, to ensure interoperability. This is a variable-length octet sequence, which is expected to hold an identifier of the type indicated by the Handle-Type field.

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.

1 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. Indicates that the data in the Address field is an IPv4 address. 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. The number of leading bits in the Address that are valid as a subnet 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 for future use. The value MUST be initialised to zero by the sender, and MUST be ignored by the receiver. 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.

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

1 Indicates that the data in the Address field is an IPv6 address or address range. Indicates that the data in the Address field is an IPv4 address. 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. The number of leading bits in the Address that are valid as a subnet prefix. Variable. The value indicates the prefix length of the prefix delegated to the mobile node. Reserved for future use. The value MUST be initialised to zero by the sender, and MUST be ignored by the receiver. 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.

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 , which must be listed.

2 0 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. 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. The following values are defined for the data transport method field by this memo: IPv6-in-IPv6 GRE IPv4-in-IPv6

This option indicates the length, in milliseconds, to keep the forwarding state of a given MN active after a hand-over. 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.

3 0 4. The length of the option in octets, excluding the Type, Sub-Type and Length fields. Indicates the preferred delay before deleting the MN forwarding state from the previous MAG during hand-over. The value is in milliseconds.

This option contains the timestamp value in the format of an NTP timestamp (RFC 4330, Section 3 ), 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 hangovers, 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 synchronisation, 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 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.

4 0 8. The length of the option in octets, excluding the Type, Sub-Type and Length fields. A timestamp in the 64 bit format defined for NTP timestamps .

This option can be used by any vendor or organisation 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 organisation.

5 0. This field may not be assigned any value different from zero by the organisations using the option; only the Value field may be freely used. The length of the option in octets, excluding the Type, Sub-Type and Length fields. The high-order octet is 0 and the low-order 3 octets are the SMI Network Management Private Enterprise Number , , of the Vendor in network byte order. Variable. Details defined by individual Vendors / Organisations.

This option MAY be used to indicate a limited lifetime for the state created as a result of Location Registration 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.

6 0 4. The length of the option in octets, excluding the Type, Sub-Type and Length fields. 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.

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

7 0 8. The length of the option in octets, excluding the Type, Sub-Type and Length fields. An 8-bit number, which indicates the Status result of handling the acknowledged message. Individual status codes are defined in . 24-bit field reserved for future use. The value MUST be initialised to zero by the sender, and MUST be ignored by the receiver.

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

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

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 tunnelling methods that can be used with the peer LMA. Based on configuration, it is possible that some tunnelling methods are used only with some LMAs: in this case, the Association Request message MUST contain only the tunnelling methods that are administratively permitted with that specific LMA. 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.

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.

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

When a MN hands over from one MAG to another, the new MAG may not know if the event occurred is a hand-over 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 ): 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.

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.

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.

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 message, the MAG handle entry is either initialised, or updated in case of a hand-over. 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 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.

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

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.

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.

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 hand-over has occurred: the detailed procedure for this event is described in . 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 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 Acknowledgement with an appropriate Status value.

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.

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 ). If an entry is already present in the Routing Cache, a hand-over 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.

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

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

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 to tunnel data packets between an LMA node and an associated MAG node. Support of other forwarding approaches are for future extensions.

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.

LMA and MAG nodes MUST support IPv6-in-IPv6 encapsulation according to RFC 2473 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 tunnelling has been selected as forwarding approach, it 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.

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

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 and communicate with other multicast-enabled 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.

| | | | |====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 tunnelled 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.

|===============>|----------------.>|--.> | | | | ]]> Figure 6: Example of a mobile node sourcing multicast packets to the group.

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

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 . To address these threats, NetLMM protocol must support data origin authentication, integrity and replay protection on a per-packet basis. IPsec 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 provides protection for the addresses in the IP header, ESP provides the same by checking the IP address against the selectors in the SAD . Thus, ESP with non-NULL authentication is sufficient to provide the 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 MUST be used for dynamic keying. IKEv2 MAY be supported. Dynamic keying , 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 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 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 authorise 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 (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 authorisation 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 hand-over 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.

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.

&rfc768; &rfc2119; &rfc2473; &rfc2578; &rfc2710; &rfc3753; &rfc3971; &rfc4282; &rfc4302; &rfc4303; &rfc4306; &rfc4330; &netlmmps; &netlmmgoals; &rfc2401; &rfc2409; &rfc2960; &rfc3692; &certprofile; &multilink; &netlmmthreats; &netlmmattach; &netlmmproto; IANA

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

The design team currently considers optimisation of the hand-over related signalling. This focuses in particular on reducing the hand-over signalling 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 hand-over cases, explicit signalling 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 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: Keep MN Address Setup and Routing Setup messages and specify an approach to piggyback these messages with a Location Registration Req/Ack. 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). Omit the MN Address Setup message and allow overload the Location Registration message (append NetLMM Address options). Other alternatives.

Inter-MAP hand-over Fast hand-over Hierarchical MAP