NETLMM G. Giaretta Internet-Draft Telecom Italia Expires: December 21, 2006 K. Leung Cisco M. Liebsch NEC P. Roberts Motorola K. Nishida NTT DoCoMo Inc. H. Yokota KDDI Labs M. Parthasarathy Nokia H. Levkowetz Ericsson June 19, 2006 NetLMM Protocol draft-giaretta-netlmm-dt-protocol-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 21, 2006. Copyright Notice Giaretta, et al. Expires December 21, 2006 [Page 1] Internet-Draft NetLMM Protocol June 2006 Copyright (C) The Internet Society (2006). Abstract This document specifies a network protocol that allows mobile nodes to move around in a localized 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 ever changed, and maintaining seamless communication in the presence of such mobility events. 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. Giaretta, et al. Expires December 21, 2006 [Page 2] Internet-Draft NetLMM Protocol June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Functional Entities . . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 5. Message Types . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. LMA Allocation Request / Reply messages . . . . . . . . 10 5.2. Association Request / Reply messages . . . . . . . . . . 10 5.3. Disassociation Request / Reply messages . . . . . . . . 11 5.4. Location Registration / Ack messages . . . . . . . . . . 11 5.5. Location Deregistration / Ack messages . . . . . . . . . 11 5.6. MN Address Setup / Ack messages . . . . . . . . . . . . 12 5.7. MN Address Remove / Ack messages . . . . . . . . . . . . 12 5.8. Routing Setup / Ack messages . . . . . . . . . . . . . . 12 5.9. Routing Remove / Ack messages . . . . . . . . . . . . . 13 5.10. Heartbeat / Ack messages . . . . . . . . . . . . . . . . 13 5.11. Message Transport . . . . . . . . . . . . . . . . . . . 13 5.12. Message Optimization . . . . . . . . . . . . . . . . . . 14 6. Protocol Extensibility . . . . . . . . . . . . . . . . . . . . 14 7. Message and Message Option Formats . . . . . . . . . . . . . . 15 7.1. Message Formats . . . . . . . . . . . . . . . . . . . . 15 7.2. Options . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Protocol Specification . . . . . . . . . . . . . . . . . . . . 26 8.1. Mobile Access Gateway Operation . . . . . . . . . . . . 26 8.2. Local Mobility Anchor Operation . . . . . . . . . . . . 32 9. Data Transport . . . . . . . . . . . . . . . . . . . . . . . . 38 9.1. Forwarding of Unicast Data Packets . . . . . . . . . . . 38 9.2. Forwarding of Multicast Data Packets . . . . . . . . . . 40 9.3. Forwarding of Broadcast Data Packets . . . . . . . . . . 41 10. Protocol Constants and Configuration Variables . . . . . . . . 41 11. Security Considerations . . . . . . . . . . . . . . . . . . . 41 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 15.1. Normative References . . . . . . . . . . . . . . . . . . 43 15.2. Informative References . . . . . . . . . . . . . . . . . 44 Appendix A. TODO (Things that remain to be specified...) . . . . 44 Appendix B. Using GRE Tunnels with NetLMM . . . . . . . . . . . . 45 Appendix C. Using MPLS with NetLMM . . . . . . . . . . . . . . . 46 Appendix D. TTL Handling . . . . . . . . . . . . . . . . . . . . 46 Appendix E. MN-AR Interface considerations . . . . . . . . . . . 46 Appendix F. Out of scope . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 Intellectual Property and Copyright Statements . . . . . . . . . . 49 Giaretta, et al. Expires December 21, 2006 [Page 3] Internet-Draft NetLMM Protocol June 2006 1. Introduction This document specifies a protocol that allows nodes to move around in an access network attaching to various points of the access 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 perhaps of mobile QoS, power management and paging, and management of changing network conditions in the face of various mobility events. This protocol is developed in response to the problem statement for network-based localized mobility [I-D.ietf-netlmm-nohost-ps] and this protocol 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 productively 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 is similar and different to 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 changes 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 Giaretta, et al. Expires December 21, 2006 [Page 4] Internet-Draft NetLMM Protocol June 2006 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 [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. 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 Giaretta, et al. Expires December 21, 2006 [Page 5] Internet-Draft NetLMM Protocol June 2006 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 on the MN inside the NetLMM domain. For IPv6 it is assumed that this is an invariant routable IP address with global scope. NetLMM Network Prefix The NetLMM Network Prefix (NNP) is the IPv6 link prefix of the NetLMM address. Giaretta, et al. Expires December 21, 2006 [Page 6] Internet-Draft NetLMM Protocol June 2006 Routing Tag An opaque identifier that is signaled between MAGs and LMAs and that can be used to distinguish traffic inside packets when the contents inside those packets cannot be inspected due to some operations such as encryption or header compression. It could be used, for example, in a GRE key field if GRE tunneling were being used to distinguish internal packets destined for a mobile when the internal packets headers have been compressed. 3. Functional Entities The principal functional entities in a NetLMM infrastructure are the Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA). There are other entities that will make up a mobile access network that are used to support various kinds of functionality (mobile nodes, AAA, routing, DNS, etc.) whose basic functionality may be used by the MAG and the LMA but whose operation is not changed in any way for the proper operation of the NetLMM protocol. Include a diagram. The diagram should show: 1. multiple MAGs 2. multiple LMAs 3. their interconnectivity Should it show? 4. mobile nodes moving around the edge 5. the possibility of link layer access technologies beneath MAGs 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 to maintain forwarding information for the mobile nodes which includes a set of mappings to associate mobile nodes by their Giaretta, et al. Expires December 21, 2006 [Page 7] Internet-Draft NetLMM Protocol June 2006 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 major phases, an initiation phase and an operational phase. During the initiation phase the MAGs and an LMA (or multiple LMAs) establish connectivity between them. Although this document describes this phase of the protocol operation as an initiation phase there is no restriction on the ability of adding new MAGs or new LMAs to a NetLMM infrastructure while other nodes are already in operation. During the operational phase the MAGs and LMAs provide mobile connectivity service to mobiles nodes that are attaching to the infrastructure, leaving the infrastructure, and moving around within the infrastructure. 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. The NetLMM infrastructure uses 6 messages to establish and maintain associations between the MAGs and the LMAs: Association Request, Associate Reply, Disassociation Request, Disassociate Reply, Heartbeat, and Heartbeat Ack. A MAG associates itself with an LMA by sending an Association Request message that includes its MAG ID 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 its LMA ID and 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 a Disassociate Reply. Heartbeat messages are 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. The NetLMM infrastructure uses 14 messages to manage the attachment, departure, mobility, and other activities of mobile nodes within the infrastructure: LMA Allocation Request, LMA Allocation Reply, Location Registration and Acknowledge, Location Deregistration and Acknowledgment, Routing Setup and Acknowledgement, Routing Removal and Acknowledgement, MN Address Setup and Acknowledgement, MN Address Giaretta, et al. Expires December 21, 2006 [Page 8] Internet-Draft NetLMM Protocol June 2006 Removal and Acknowledgement. When a mobile node is to receive service, a policy decision point entity may send an LMA Allocation Request to the LMA creating state for the mobile node. The LMA allocation request authorizes service for a particular Mobile Node ID. This message may contain policy information for the mobile node. The LMA acknowledge the request with an LMA allocation reply. It is possible that an LMA is configured to authorize service for any mobile node and in such a situation the LMA Allocation Request and reply messages are not necessary. When a mobile node connects to the NetLMM infrastructure, it first needs to configure an address. Whether it is using stateful or stateless address configuration, the serving LMA needs to be involved in the address allocation process. So when a mobile node connects, the MAG sends a location registration message to the LMA containing its own ID and the Mobile Node's ID. The LMA responds to the message with a a Location Registration Ack message that includes the NetLMM prefix that the MAG is to use in its router advertisement toward the Mobile Node. The MAG in turn sends a router advertisement to the attached mobile. Once address configuration is complete (through either stateful or stateless address configuration) the MAG registers the mobile node's address with the LMA by sending an MN Address Setup message to the LMA including the MAG's ID, the MN's ID, the NetLMM address, and a tunnel ID. The LMA creates forwarding state for packets in response to this message and sends a MN address reply to the MAG acknowledging the packet setup. The MAG, in receiving a successful MN Address Setup Reply, creates forwarding state for packets destined to the mobile node. When a mobile node then leaves the NetLMM infrastructure, the MAG sends a Location Deregistration message to the LMA including the Mobile Node's ID and the MAG's ID. The LMA cleans up all state for the mobile node identified in the message and sends a Location Deregistration Acknowledgement message. It is also 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 same two messages are used, Location Deregistration and Local Deregistration Acknowledgement, but they are initiated by the LMA and acknowledged by the MAG in this case. 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, the new MAG (nMAG) sends a Location Registration Message to the LMA with the MAG ID and the MN ID. The LMA responds by sending a Routing Setup Giaretta, et al. Expires December 21, 2006 [Page 9] Internet-Draft NetLMM Protocol June 2006 message to the nMAG that includes the MN ID, the MAG ID, the LMA ID, NetLMM addresses. The new MAG acknowledges this information with a Routing Setup Ack message and the LMA responds with a Location Registration Ack message containing the NetLMM prefix that the nMAG uses in the router advertisement for the MN. The mobile node can at any time configure new IP addresses for itself using stateless address auto-configuration and this operation is supported in NetLMM. When the mobile issues a new address DAD request, the MAG sends a MN Address Setup Request to the LMA with the mobile node's ID and the new NetLMM address. The LMA validates the usability of the address, updates forwarding state, and acknowledges the request with the MN Address Setup Reply message to the serving MAG which then replies to the MN DAD operation. The means through which the NetLMM infrastructure knows that the mobile node is attached, leaving, or moving is beyond the scope of this protocol specification. It is envisioned that this information is largely access network specific and that the MAG uses an API to trigger much of the operation described herein. 5. Message Types This document defines a set of control messages and options for the NetLMM protocol. The control messages are carried by the User Datagram Protocol, using a well known port number, as described in Section 5.11. The messages are presented in this section, and the message format and option formats are defined later, in Section 7. 5.1. LMA Allocation Request / Reply messages The LMA Allocation Request message is used to allocate an LMA for the MN that is initially attached to the network and to validate the Location Registration message coming later from the MAG to which the MN is attached. This message containing the MN ID is sent to the selected LMA and may come from various nodes such as the MAG to which the MN is attached or the PDP that is involved in the authentication of the MN. The LMA Allocation Request is optional and the LMA may be allocated by other means (e.g., static allocation) and can be configured to serve the MN without this message. The LMA Allocation Reply message is sent from the LMA to the source of the LMA Allocation Request message to notify the status of the request (success or error code). 5.2. Association Request / Reply messages The Association Request is used to set up the control and data plane Giaretta, et al. Expires December 21, 2006 [Page 10] Internet-Draft NetLMM Protocol June 2006 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 and Routing Setup. 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. The Associate Reply message is sent from the LMA to the MAG to notify the status of the request (success or error code). If the request is successful, the receiver of the request also sends its capabilities (e.g., the receiver's ID, agreed-upon data forwarding mode, etc.) on this message. 5.3. Disassociation Request / Reply messages 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 ID and LMA ID. The Disassociate Reply message is sent from the LMN to the MAG or vice versa to inform the status of the request (success or error code). 5.4. Location Registration / Ack messages 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. By this message, the MAG and LMA create the mobility state of the MN. The IP address of the MN is not known at this point and the MN Address Setup message must follow to update the mobility state and to set up the routing for the MN. This message contains the MN ID, MAG ID and LMA ID. The Location Registration Ack message 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. 5.5. Location Deregistration / Ack messages The Location Deregistration message is sent from the MAG to the LMA or vice versa to delete the mobility state of the MN. The MAG sends this message when the MN is detected to have moved away. On the other hand, the LMA sends this message when it determines that the MN Giaretta, et al. Expires December 21, 2006 [Page 11] Internet-Draft NetLMM Protocol June 2006 is at a new location. This message contains the MN ID, MAG ID, LMA ID and the requested revocation time. The Location Deregistration Ack is sent back to the source of the Location Deregistration message to acknowledge the receipt of the Location Deregistration message. This message contains the agreed revocation time. 5.6. MN Address Setup / Ack messages When the MAG determines that the MN has obtained its NetLMM address by for example the neighbor advertisement (the DAD procedure) or the DHCP server, the MAG sends he MN Address Setup message to the LMA to update the mobility state and to create a routing entry for the MN on the LMA. This message contains the MAG ID, LMA ID and one or more MN ID(s) and NetLMM address(es) assigned to the MN(s). Optionally, the Routing Tag(s) for the MN(s) may be included. The MN Address Setup Ack is sent from the LMA to the MAG to acknowledge the receipt of the MN Address Setup message and to notify the MAG if the NetLMM address(es) contained in the MN Address Setup message are accepted (the DAD procedure). If the Routing Tag is contained in the Routing Setup message, a corresponding Routing Tag is returned by the Routing Setup Ack message. 5.7. MN Address Remove / Ack messages When the MAG determines that one of the MN's NETLMM address(es) is no longer valid or used, the MAG sends the MN Address Remove message to the LMA to delete the corresponding mobility state and routing entry in the LMA. This message contains the MN ID, MAG ID, LMA ID and corresponding NETLMM address. The MN Address Remove Ack is sent from the MAG to the LMA to acknowledge the receipt of the MN Address Remove message. 5.8. Routing Setup / Ack messages When the MN moves from the previous MAG to the new MAG (inter-MAG handover), the LMA, which already has the mobility state for the MN, sends the Routing Setup message to the new MAG in response to the Location Registration message from the new MAG. This message is used to update the routing on the new MAG and contains the MN ID, MAG ID, LMA ID and one or more NetLMM address(es) assigned to the MN. Optionally, the Routing Tag for the MN may be included. The Routing Setup Ack message is sent from the MAG to the LMA to acknowledge the receipt of the Routing Setup message. If the Routing Giaretta, et al. Expires December 21, 2006 [Page 12] Internet-Draft NetLMM Protocol June 2006 Tag is included in the Routing Setup message, the corresponding Routing Tag is returned by the Routing Setup Ack message. 5.9. Routing Remove / Ack messages When the LMA determines that one or more NetLMM address(es) is/are no longer valid by for example the DHCP server, the LMA sends the Routing Remove message to the MAG to delete the corresponding routing entry/entries on the MAG. This message contains the MN ID, MAG ID, LMA ID and NetLMM address(es) of the MN. The Routing Remove Ack is sent from the MAG to the LMA to acknowledge of the receipt of the Routing Remove message. 5.10. Heartbeat / Ack messages The Heartbeat message is sent from the MAG to LMA or vice versa to obtain the connectivity status. This message contains the MAG ID, LMA ID and the heartbeat number that is separated from the message sequence number. The Heartbeat Ack is sent back from the node that received the Heartbeat message to its peer. This message contains the MAG ID, LMA ID and the corresponding heartbeat number. These messages are suppressed when there is data traffic between the two nodes. 5.11. Message Transport The new NetLMM control messages defined in this document are carried by the User Datagram Protocol RFC 768 [RFC0768] using well known port number TBD (assigned by IANA). 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: TBD (Assigned by IANA) In case the recipient of a NETLMM message has to reply, the following UDP ports MUST be used: Giaretta, et al. Expires December 21, 2006 [Page 13] Internet-Draft NetLMM Protocol June 2006 * Source Port: variable * Destination Port: Copied from the source port of the received message. 5.12. Message Optimization In order to minimize routing establishment delays, e.g., handover times, it may be important to achieve routing setup or routing changes with an absolute minimum number of messaging roundtrips between the MAG and the LMA. However, given the messages described earlier in this section, there are several cases where 2 messaging round-trips are needed in order to complete a routing setup. Future versions of this document will propose optimizations which reduce the number of messages that must be sent in order to achieve routing setup or routing changes. It is however deemed important to have agreement on the base functionality and the base messages before such optimizations are discussed. 6. Protocol Extensibility NetLMM consists of a set of new control messages, described in Section 5 in this document. Up-to-date values for the message types are maintained in the online IANA registry of assigned numbers. NetLMM defines a general extension mechanism using options to allow optional information to be carried in the control messages. The options are encoded in the Type-Length-Value format, and are described in detail in Section 7.2. 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. 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. The Sub-Type field provides efficient use of the option type numbering space. Format: Giaretta, et al. Expires December 21, 2006 [Page 14] Internet-Draft NetLMM Protocol June 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Data . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type This field identifies the particular type of option serving a specified function. 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. 7. Message and Message Option Formats 7.1. Message Formats 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 8byte aligned, though Type field divided into two parts; Option Type and Option Sub-Type. The length field indicates the exact length of the following value fields in units of 8 octets. All option payloads whose length is not a unit of 8 octets must be padded to the correct alignment. 7.1.1. Message Header All NetLMM messages start with the following common header. Parameters for each message are contained in the option format (see following sections). Giaretta, et al. Expires December 21, 2006 [Page 15] Internet-Draft NetLMM Protocol June 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 | Status | Type | Sub-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version An 8-bit number, indicating the NetLMM protocol version. The version of the NetLMM protocol specified in this document is 1. Status An 8-bit number, which indicates the status of the message. When used for request messages, e.g., Location Registration, the status code is normally set to 0, indicating 'Not Applicable'. When used for reply and acknowledgement messages, the status code indicates the result of processing the associated request message. The following values are defined by this document: 0: Not Applicable (N/A) The status code is not applicable for the message. This is normally the case for request messages. 1: Success Acknowledgement 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: Unauthorized MN Used by the LMA in response to Location Registration or Routing Setup, to notify the MAG of the MN not being authorized for service. Giaretta, et al. Expires December 21, 2006 [Page 16] Internet-Draft NetLMM Protocol June 2006 6: Duplicate Address Used by the LMA when an MN Address Setup contains an IP address that is duplicated in the same NetLMM domain. The specific invalid addresses MUST be specified in Address Options with Sub-Type TBD, Duplicate Address. 5: Invalid Address Used by the LMA when an MN Address Setup contains an IP address that is invalid. The specific invalid addresses MUST be specified in Address Options with Sub-Type TBD, Invalid Address. 7: Over IP Address Limit Used by the LMA on receipt of a Routing Setup or MN Address Setup message, if the maximum number of IP addresses allowed for a MN has been exceeded. 8: Invalid Tunnelling Method The proposed tunnel method is not supported or unavailable. 9: Invalid Message The NetLMM Request Message was invalid or malformed. 10: Already Associated The LMA already had the requesting MAG listed as associated. Type 8-bit indicator, shows NetLMM message types. The message types are specified in section 5. The values for messages are defined as follows; 0: LMA Allocation Request/Reply 1: Association Request/Reply 2: Disassociation Request/Reply 3: Location Registration/Ack 4: Location Deregistration/Ack 5: MN Address Setup/Ack 6: MN Address Remove/Ack Giaretta, et al. Expires December 21, 2006 [Page 17] Internet-Draft NetLMM Protocol June 2006 7: Routing Setup/Ack 8: Routing Remove/Ack 9: Heartbeat/Ack Sub-Type 8-bit indicator, this indicator is Type dependent field and can use to add extra information for the message. Sub-types defined in this document, valid for all message types defined in this document: 0: Request This is the Request message of the given type, with semantics and format as specified in this document. When message variations with other semantics or formats are required in the future, new subtypes should be allocated for them. 1: Ack/Reply This is the Acknowledgement (or Reply) message to be sent in response to request messages of the given type. It is seen as less likely that it will be necessary to allocate new sub-types for new Ack/Reply messages, but there is no restriction on doing so. Sequence Number 16-bit length, used to ensure the correspondence of the request and ack/reply pair of the same message 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/Reply 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'. Reserved 16-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Giaretta, et al. Expires December 21, 2006 [Page 18] Internet-Draft NetLMM Protocol June 2006 Options 8 byte aligned field, and can add multiple options. See following sections for options. 7.2. Options 7.2.1. 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. In addition to that for the MN ID there might for instance be ID options for the MAG ID and for the LMA ID in a Location Registration. 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]. This option can also contain Routing Tag which is an identifier specified by each tunnel method for data transport. The existence or use of the Routing Tag is also dependent on the tunnel method to use. 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... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | . . . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type 0 Option Sub-Type This field indicates what the ID in this option refers to. It is expected that additional Sub-Types may be defined in the future. 0: MN ID Giaretta, et al. Expires December 21, 2006 [Page 19] Internet-Draft NetLMM Protocol June 2006 1: LMA ID 2: MAG ID 3: Routing Tag Length Variable. The value indicates exact 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: 128-bit opaque cryptographically generated identifier (such as proposed ORCHID IDs 1: NAI according to [RFC4282] 2: Ethernet MAC Address 3: IPv6 Address Identifier This is a variable-length octet sequence, which is expected to hold an identifier of the type indicated by the ID-Type field. 7.2.2. NetLMM Address Option This option conveys NetLMM IP address and the prefix that LMA advertise for MNs. The NetLMM address can be both IPv4 and IPv6. This option can also inform LMA prefix only. Giaretta, et al. Expires December 21, 2006 [Page 20] Internet-Draft NetLMM Protocol June 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 Length | 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 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. 2: Indicates that the data in the Address field is an IPv6 network prefix information. 3: Indicates that the data in the Address field is an IPv4 network prefix information. 4: Indicates that the address in the Address field is a duplicate IPv6 address. 5: Indicates that the address in the Address field is a duplicate IPv4 address. 6: Indicates that the address in the Address field is an invalid IPv6 address. Giaretta, et al. Expires December 21, 2006 [Page 21] Internet-Draft NetLMM Protocol June 2006 7: Indicates that the address in the Address field is an invalid IPv4 address. Length Variable. The value indicates exact length of the option in octets, excluding the Type, Sub-Type and Length fields. Prefix Length Variable. The value indicates the number of leadings bits in the Address that are valid (as a network prefix). If the Sub-Type value indicates an invalid or duplicate address, this field must be set to zero when sending, and ignored on receipt. Reserved 16-bit field 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 or 2, the value in the IPv6 address appears, while the type is 1 or 3, the value in the IPv4 address is presented. 7.2.3. Data Transport Option This option contains data transport methods capabilities that the MAG or LMA has. This option is used by Association request/reply messages 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. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Giaretta, et al. Expires December 21, 2006 [Page 22] Internet-Draft NetLMM Protocol June 2006 Option Type 2 Option Sub-Type This field is reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Length Variable. The value indicates exact 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 Present the data transport methods available at the sender of the Association request/Reply message, i.e., LMA and MAG. The methods presented in this option are listed in order of the preference. 0: IPv6-in-IPv6 1: GRE 2: IPv4-in-IPv6 7.2.4. Revocation Timer Option This option indicates the length, by milliseconds, to keep the forwarding state of a given MN at previous MAG in handover scenario. This option is included in Location Deregistration and its acknowledgement. The Revocation Time in the Location Deregistration Ack is copied from that presented in the receipt option of the Location Deregistration. If the MAG can not keep the MN state as LMA has requested for some reason, MAG can input preferable Revocation time or error code instead of copying 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Revocation Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Giaretta, et al. Expires December 21, 2006 [Page 23] Internet-Draft NetLMM Protocol June 2006 Option Type 3 Option Sub-Type This field is reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Length 4. The value indicates exact length of data shown in Revocation Time field. Shown in octets, network byte order Revocation Time Variable. Indicate the preferred delay to delete the MN forwarding state from previous MAG to LMA in handover. The value shows in millisecond unit. 7.2.5. Timestamp Option This option contains the timestamp value in the format of NTP timestamp, and records the time when the message is sent. This option can be attached to any message and used to detect an overtaking message in race condition by comparing the timestamp values of messages. Especially in handover scenario, 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 is network administrator dependent, and needs some of the time distribution methods, (e.g., NTP or GPS time synchronization system), with the high accuracy enough to support fast moving MNs. 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 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type 4 Giaretta, et al. Expires December 21, 2006 [Page 24] Internet-Draft NetLMM Protocol June 2006 Option Sub-Type This field is reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Length 8. The value indicates exact length of Timestamp field Shown in octets, network byte order. Timestamp Follows the 64bit length format of the NTP timestamp [RFC4330] 7.2.6. 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 This field is reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. 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. Length Variable. The value indicates exact length of the option in octets, excluding the Type, Sub-Type and Length fields. Giaretta, et al. Expires December 21, 2006 [Page 25] Internet-Draft NetLMM Protocol June 2006 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. 8. Protocol Specification 8.1. Mobile Access Gateway Operation 8.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: * MN ID of the attached MN. This identifier is learned from 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 of an attached MN. Each IP address is learned from an LMA through the Routing Setup message from an LMA or my means of local operation. According to the context of the received message or local indication, an IP address is set up, updated or removed from the Routing Cache. * Routing Tag for the attached MN. Creating the entry and use of this tag is optional and might support identification of the MN in the data plane at the LMA and the MAG. In case the LMA and MAG specify asymmetric tags for the MN, this field MUST draw a distinction. * LMA ID of the LMA serving an attached MN. The serving LMA and its LMA ID is learned 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 ID to the associated LMA's IP address(es). The LMA List also supports the procedure of bulk de- registrations at all or a subset of LMAs. The LMA List conceptually contains the following fields for each LMA Giaretta, et al. Expires December 21, 2006 [Page 26] Internet-Draft NetLMM Protocol June 2006 entry: * LMA ID of the LMA. * One or more IP address(es) of the LMA. The LMA's IP address information is learned 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. * 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. * Forwarding capabilities of the LMA. In case the LMA attaches a list of its own capabilities to the Associate Reply message, the MAG SHOULD store them in this field of the LMA List. Each MAG MIGHT 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: * LMA ID 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. 8.1.2. Processing NetLMM Headers * The Type and Sub-Type fields MUST have a known value (Section 7.1.1). Otherwise, the node MUST discard the message and issue a an Error message with Status field set to 7 ("INVALID MESSAGE"). 8.1.3. Processing NetLMM Messages 8.1.3.1. 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 Giaretta, et al. Expires December 21, 2006 [Page 27] Internet-Draft NetLMM Protocol June 2006 peculiarities. For example, the Association Request message may be sent during the MAG start up procedure. The Association Request message MUST include: * the MAG identifier 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. When sending an Association Request, the MAG MAY create a tentative entry in its LMA List, including the LMA ID, 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 Reply from the peer LMA with STATUS 1. 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 Association Reply. The MAG MUST also update the forwarding method pre 8.1.3.2. 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 with the 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 a Disassociation Reply 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 Giaretta, et al. Expires December 21, 2006 [Page 28] Internet-Draft NetLMM Protocol June 2006 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 a Disassociate Reply with Status 1 "SUCCESS". As in all NetLMM messages, the MAG MUST include the ID option with its identity. 8.1.3.3. 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 that carries the MN identifier (e.g., MAC address of the MN, NAI) and the LMA identifier. Upon the API notification, the MAG MUST send a Location Registration message to the LMA including three different ID options, containing its own identity, the identity of the MN and the identity of the LMA. How the MAG resolves the LMA ID 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 ID 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 a Location Registration Acknowledge message from the LMA with Status value 1 "SUCCESS". This message includes also a NetLMM Network Prefix that the MAG MUST advertise to the MN. For this purpose, the MAG takes the prefix parameters from the NetLMM Address Option in the Location Registration Acknowledge and creates a Router Advertisement with a correspondent Prefix Option. It then sends a unicast Router Advertisement to the MN. (Note: how about the parameters that are carried in a Prefix Option but are not present in the NetLMM Address Option? e.g., lifetimes?). In the Prefix Option sent to the MN the L flag MUST be unset and the A flag MUST be set or unset, depending on the possibility to perform stateless auto- configuration in the local domain. 8.1.3.4. MN IP address notification procedure The NetLMM protocol specification is agnostic of how the IP address is assigned to the MN in the local domain. However, the MAG needs to know the IP address assigned or auto-configured by the MN in order to update the routing at the LMA. For this purpose, the MAG needs to play an active role in the DHCP exchange or needs to receive a trigger after the MN has configured an IP address via stateless auto- Giaretta, et al. Expires December 21, 2006 [Page 29] Internet-Draft NetLMM Protocol June 2006 configuration. How this is done is described later in this section. As soon as the MAG knows that a specific IP address has been assigned to a MN, it MUST send a MN Address Setup message to the serving LMA, including three ID options (MN ID, MAG ID, LMA ID), a NetLMM Address option containing the address assigned to (or configured by) the MN. This message is a request to the LMA to start forwarding the packets destined to that IP address to the MAG. The MAG MAY also add the new IP address to the Routing Cache entry related to that MN. When it receives a MN Address Setup Acknowledgement message with Status 1 "SUCCESS", the MAG MUST add the new IP address to the Routing Cache entry of the MN (or set it as non tentative if previously updated) and update its forwarding state. In case the message contains a different Status value (Values 5 or 6), it MUST reject the assignment of the IP address to the MN, depending on the method used by the MN to request the address (i.e., DHCP or stateless auto-configuration). In case DHCP is used, the MAG MUST act as DHCP Relay Agent in order to have an active role in the DHCP exchange. The MAG then receives from the DHCP server the IP address assigned to the MN in a DHCP Relay-reply message and updates the routing at the LMA and at the same time can send a DHCP Reply message to the MN with the assigned address. It is important that in the DHCP-Relay-forward message, the MAG includes the identifier of the LMA that is in charge of serving that MN so that the DHCP server can select the IP address accordingly (i.e., from the IP subnet of the LMA). In case the MAG receives a MN Address Setup Acknowledgement message with Status 5 or 6, it MUST send a DHCP Reply message, refusing the IP address assignment to the MN. In case stateless auto-configuration is performed, the trigger to update the routing at the LMA is the DAD procedure. The DAD procedure is performed on the MAG link, but the MAG needs to verify the address uniqueness at the LMA; for this purpose, it sends the MN Address Setup message. If the LMA replies with a Status value equal to 5 or 6, the MAG MUST send a Neighbor Advertisement in order to fake an IP address duplication. 8.1.3.5. 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 of 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 as a Giaretta, et al. Expires December 21, 2006 [Page 30] Internet-Draft NetLMM Protocol June 2006 MN_Access_Network API carries the MN ID and the LMA ID. As mentioned above, this API can be for example based on an AAA exchange. After receiving this API, the MAG performs the same procedure described for network access (see section Section 8.1.3.3): it sends a Location Registration message including three different ID options, containing the MN ID, the MAG ID and the LMA ID. In this handover handover case, the MAG does not receive immediately a Location Registration Acknowledgement message; instead it receives a Routing Setup message from the LMA that includes all IP addresses that are assigned to the MN. These addresses are included in one or more NetLMM Address options. The message contains also some forwarding state, based on the tunneling mechanism used. (Note: how the tunnel ID is carried in the message? Is it really needed at this step?). When the MAG receives this message, it MUST create a new entry in its Routing Cache for the specific MN and MUST update its forwarding state. In case no errors occur, the MAG sends back to the LMA a Routing Setup Acknowledgement message with Status value set to 1 "SUCCESS" and including the forwarding state information. After that, the MAG receives the Location Registration Acknowledgement message that includes the NetLMM prefix to be delivered to the MN. The procedure is the same as described for network attach in section Section 8.1.3.3. 8.1.3.6. 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 a Location Deregistration Acknowledgement to the LMA with Status 1 "SUCCESS". In case the Location Deregistration contains a Timer attribute (Note: it seems to me the Timer option has not been defined yet), 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 timer cannot be greater than the one suggested by the LMA and MUST be sent back to the LMA in the Location Deregistration message acknowledgement. 8.1.3.7. Network Detachment In case the MAG has an indication that the MN has detached from the network (e.g., via AAA architecture), the MAG MUST (Note: if the protocol is stateful and we do not have a lifetime in the location Giaretta, et al. Expires December 21, 2006 [Page 31] Internet-Draft NetLMM Protocol June 2006 registration, this is a MUST, otherwise it can be a SHOULD) send a Location Deregistration message with an ID option including the MN ID. After receiving the Location Deregistration Acknowledgement, the MAG MUST remove any mobility and forwarding state in its Routing Cache related to that MN. 8.1.3.8. IP address no longer in use In case the MAG has an indication that an IP address is no longer used by the MN, it MUST send a MN Address Remove message to the LMA, including the MN ID and the NetLMM Address that needs to be removed in a NetLMM Address option. How the MAG detects that an IP address is no longer used is out of the scope of this document. 8.1.3.9. Link availability test MAGs should ensure availability of their link to LMAs. To test link availability, each MAG should periodically send a Heartbeat message to each LMA with which it has associated according to the entries in the LMA List. If the Heartbeat Ack message from the LMA is received within HEARTBEAT_TIMEOUT seconds, availability of the link to the LMA is proven. If the MAG does not receive the Heartbeat Ack message within HEARTBEAT_TIMEOUT seconds, the MAG should send HEARTBEAT_RETRY_MAX further Heartbeat messages with incremented sequence number. In case none of these Heartbeat messages is acknowledged by the LMA, the MAG should raise an alarm. Optionally, the MAG can inform an external OAM function about the broken link. To avoid superfluous bandwidth consumption, MAGs should send Heartbeat messages to an LMA only in case there was no traffic on the associated link for LINK_ACTIVITY_TIMEOUT seconds. MAGs should perform Heartbeat tests according to the following rule: In case there was no signaling activity on a link to an LMA for LINK_ACTIVITY_TIMEOUT seconds, the MAG waits for an additional random delay time between HEARTBEAT_DELAY_MIN and HEARTBEAT_DELAY_MAX seconds. After the delay has expired, the MAG sends the Heartbeat message to the LMA. In case the MAG receives a Heartbeat message from the LMA while waiting for the additional random delay, the MAG should reset the delay timer and refrain from sending the Heartbeat message, but MUST acknowledge the Heartbeat message using the same sequence number as in the received message. 8.2. Local Mobility Anchor Operation 8.2.1. Conceptual Data Structures Each LMA MUST maintain a NetLMM Routing Cache and a MAG List. Giaretta, et al. Expires December 21, 2006 [Page 32] Internet-Draft NetLMM Protocol June 2006 Each LMA Routing Cache entry conceptually contains the following fields for each MN: * MN ID of the registered MN. This Identifier is learned through the Location Registration message, which registers an attached MN. Optionally, the MN ID is learned though the LMA Allocation message beforehand, which could enable service authorization for this particular MN ID at the LMA. * Routing Tag for the registered MN. Creating the entry and use of this tag is optional and might support identification of the MN in the data plane at the LMA and the MAG. In case the LMA and MAG specify asymmetric tags for the MN, this field MUST draw a distinction. * MAG ID of the registered MN's serving MAG. This identifier is learned through the Location Registration message, which registers an attached MN. Dependent on the context of this message, the MAG ID entry is either initialized or updated in case of the MN's handover. The MAG ID can be linked to the associated MAG's IP address With the help of the MAG List. * One or more global IP addresses of a registered MN. Each IP address is learned from an MN Address Setup message. According to the context of the received message, the IP address is set up, updated or removed from the Routing Cache. 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 ID entries to the associated MAG's IP address(es). The MAG List also supports the procedure of bulk de-registrations at all or a subset of associated MAGs. The MAG List conceptually contains the following fields for each associated MAG: * MAG ID of the associated MAG. * One or more IP address(es) of the associated MAG. The MAG's IP address information is learned through the Associate message. * Forwarding capabilities of the associated MAG. This capability list is learned from a particular MAG through the Associate message. From the list of supported forwarding approaches, the LMA enters only these approaches to the capabilities, which are supported by the LMA. Giaretta, et al. Expires December 21, 2006 [Page 33] Internet-Draft NetLMM Protocol June 2006 * Forwarding setting for the associated MAG. This field is needed in case the LMA configures a single forwarding approach per MAG association. * Capability list of the associated MAG. These capabilities are learned from a particular MAG through the Associate message. 8.2.2. Processing NetLMM Headers All NetLMM local mobility anchors MUST observe the rules described in Section 8.1.2 when processing NetLMM Headers. 8.2.3. Processing NetLMM Messages 8.2.3.1. Associate Procedure When a LMA receives an Association Request message, it MUST look up into its MAG list based on the MAG identifier contained in the ID option included in the request. If an entry for that MAG ID is already present in the MAG list, the LMA MUST send an Associate Reply message to the MAG with STATUS 10 "Already Associated" (note: an alternative may be that the LMA silently discards the message) (note: another alternative is that the new association request is an association update, e.g., in order to propose a new forwarding method. I would keep things simple and not include this case, not allowing an Association Request if the MAG is already associated). If an entry for the MAG identifier contained in the ID option does not exist, the LMA MUST create it, including the parameters contained in the Association Request message (MAG ID, MAG IP address). Based on internal policy (e.g., pre-configuration) the LMA MAY accept the data forwarding method proposed by the MAG or MAY propose other methods in Access Reply. After creating the entry, the LMA MUST send an Associate Reply message with STATUS value 1 ("Success"), including its ID in an ID option. Optionally, it MAY include also a Data Transport Option included the data forwarding method to be used. (Note: don't we need a message ID in order to bind the request with the reply?) The Association Request message MUST include: * the LMA identifier 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 LMA's capabilities in terms of support of data transport methods included in a NetLMM Data Transport Option. The LMA MUST insert in this option all possible tunneling methods that can be Giaretta, et al. Expires December 21, 2006 [Page 34] Internet-Draft NetLMM Protocol June 2006 used with the peer MAG Based on configuration, it is possible that some tunneling methods are used only with some MAGs: in this case, the Association Request message MUST contain only the tunneling methods that are administratively permitted with that specific MAG. 8.2.3.2. Disassociate Procedure In case the Disassociate procedure is initiated by the MAG, when the LMA receives a Disassociation Request message, the LMA MUST validate it. If it is correct, it MUST delete the related entry in its MAG List and send a Disassociate Reply with Status 1 "SUCCESS". As in all NetLMM messages, the LMA MUST include the ID option with its identity. 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 a Disassociation Reply with Status 1 "SUCCESS", the LMA MUST delete the correspondent entry in its MAG List. 8.2.3.3. MN network access procedure When the local mobility anchor receives a Location Registration message, it MUST validate it (note: what does it mean? should it check if the MAG ID in the message is in the MAG List). 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 8.2.3.5. If an entry for that MN identifier is not present, the LMA MUST create a new entry with the MN ID, the MAG ID (?) and the MAG IP address (?). (Note: the two latter parameters are not present in the Routing Cache description. How the protocol works without them?). After creating the entry, it MUST send a Location Registration Acknowledgement with STATUS 1, including three ID options (MN ID, LMA ID, MAG ID) and the NetLMM prefix in a NetLMM Address option. The NetLMM prefix is then forwarded in a Router Advertisement to the MN by the MAG and used by the MN to auto-configure an IP address using stateless auto-configuration and/or to detect a change of local domain. In case the Location Registration is not valid or the registration procedure cannot be completed successfully, the LMA MUST send a Location Registration Acknowledgement with an appropriate Status Giaretta, et al. Expires December 21, 2006 [Page 35] Internet-Draft NetLMM Protocol June 2006 value. 8.2.3.4. MN IP address notification procedure When the MN tries to configure a new IP address on the local domain, the local mobility anchor receives a MN Address Setup message from the MAG which the MN is connected to. This message contains the IP address the MN is trying to configure in a NetLMM Address option. (Note: in the slides there is also a tunnel ID but I am not sure this is actually needed). When it receives this message, the LMA MUST check if the IP address in the NetLMM Address option is already assigned to another MN. If the address is a duplicated one, it MUST send a MN Address Setup Acknowledgement message with Status 5 "INVALID IP ADDRESS". If the address is not assigned to any other MN, the LMA MUST check if the number of addresses assigned to that MN does not exceed the maximum number of addresses that the MN can configure. This check is performed in the LMA Routing Cache; the maximum number of allowed IP addresses is a per MN variable that is pre-configured at the LMA. If the number of IP addresses exceeds the allowed one, the LMA MUST send a MN Address Setup Acknowledgement message with Status 6 "OVER IP ADDRESS LIMIT". (Note: the first check is mainly performed for the stateless configuration case and may be skipped in case DHCP is used. However the LMA does not know if the address is configured using DHCP or stateless so I would keep this check in any case) If the IP address is not a duplicated one and the maximum number of allowed IP addresses is not reached, the LMA MUST update the Routing Cache entry indexed by the MN ID contained in the MN Address Setup message with the new IP address and MUST update its forwarding state, depending on the tunneling mechanism used. 8.2.3.5. 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 Section 8.2.3.3). If an entry is already present in the Routing Cache, a handover has occurred. In this case the LMA MUST send a Routing Setup message to the MAG, including three ID options (MN ID, MAG ID, LMA ID), one or more NetLMM Address options containing all NetLMM addresses configured to the MN and some forwarding state information that depends on the tunneling method used (e.g., tunnel ID).(Note: what it the behavior of the LMA during this time interval when packets arrive? Should it already update the Routing Cache entry or should it wait for an ack?) Giaretta, et al. Expires December 21, 2006 [Page 36] Internet-Draft NetLMM Protocol June 2006 After that the LMA receives a Routing Setup Acknowledgement message; if the Status of this message is set to SUCCESS, the LMA MUST update the Routing Cache with the new location of the MN, updating the MAG ID. The LMA MUST then send back to the MAG a Location Registration Acknowledgement message with Status value set to 1 "SUCCESS", including in a NetLMM Address option the NetLMM prefix to be sent to the MN. 8.2.3.6. Resource Revocation There are case (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 ID and the MAG ID. Optionally, the LMA MAY include a Timer attribute specifying the remaining time to keep the state of the MN in the MAG. The revocation procedure terminates when the LMA receives a Resource Revocation Acknowledgement with Status 1. 8.2.3.7. Network Detachment When the LMA receives a Location Deregistration message from the peer MAG, it MUST remove in its Routing Cache the entry of the MN indicated by the MN ID in the Location Deregistration message. After that, it MUST send a Location Deregistration Acknowledgement with Status 1, including the MN ID, the MAG ID and the LMA ID. 8.2.3.8. IP address no longer in use When the LMA receives a MN Address Remove message, it MUST remove the NetLMM Address included in the NETLMM Address option from the entry in its Routing Cache related to the MN indicated in the message. After that, the LMA MUST respond with a MN Address Remove Acknowledgement with Status 1. 8.2.3.9. Link availability test LMAs should ensure availability of their link to MAGs. To test link availability, each LMA should periodically send a Heartbeat message to each associated MAG according to the entries in the MAG List. If the Heartbeat Ack message from the MAG is received within HEARTBEAT_TIMEOUT seconds, availability of the link to the MAG is proven. If the LMA does not receive the Heartbeat Ack message within HEARTBEAT_TIMEOUT seconds, the LMA should send HEARTBEAT_RETRY_MAX further Heartbeat messages with incremented sequence number. In case none of these Heartbeat messages is acknowledged by the MAG, the LMA Giaretta, et al. Expires December 21, 2006 [Page 37] Internet-Draft NetLMM Protocol June 2006 should raise an alarm. Optionally, the LMA can inform an external OAM function about the broken link. To avoid superfluous bandwidth consumption, LMAs should send Heartbeat messages to a MAG only in case there was no traffic on the associated link for LINK_ACTIVITY_TIMEOUT seconds. LMAs should perform Heartbeat tests according to the following rule: In case there was no signaling activity on a link to a MAG for LINK_ACTIVITY_TIMEOUT seconds, the LMA waits for an additional random delay time between HEARTBEAT_DELAY_MIN and HEARTBEAT_DELAY_MAX seconds. After the delay has expired, the LMA sends the Heartbeat message to the MAG. In case the LMA receives a Heartbeat message from a MAG while waiting for the additional random delay, the LMA should reset the delay timer and refrain from sending the Heartbeat message, but MUST acknowledge the Heartbeat message using the same sequence number as in the received message. 9. 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 0 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. 9.1. Forwarding of Unicast Data Packets 9.1.1. Handling of hop limit field in IPv6 data packets According to the NetLMM default mechanism to forward data packets between a particular LMA and 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 Giaretta, et al. Expires December 21, 2006 [Page 38] Internet-Draft NetLMM Protocol June 2006 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. 9.1.2. IPv6-in-IPv6 tunnel LMA and MAG nodes MUST support IPv6-in-IPv6 encapsulation to forward 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 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. 9.1.3. Future extensions Future extensions might support other approaches to forward data packets between LMA and MAG nodes. Such extensions could include IPv4-in-IPv6 encapsulation to forward IPv4 data packets of dual stack hosts within the NetLMM domain. Operators might prefer the use of other flexible forwarding approaches, such as Generic Routing Encapsulation (GRE) [RFC2784] or Multi-Protocol Label Switching (MPLS), and follow [RFC3031] and associated mechanisms to forward data packets between LMA and MAG nodes. Details about the use of such extensions are out of scope of this specification. For now, some suggestions of how GRE tunnelling could be used with NetLMM can be found in Appendix B, and similarly use with MPLS is described in Appendix C. Giaretta, et al. Expires December 21, 2006 [Page 39] Internet-Draft NetLMM Protocol June 2006 9.2. Forwarding of Multicast Data Packets 9.2.1. Link Local Multicast The scope of link local multicast packets is confined to the link between MNs and the associated MAG node. MAG nodes process but do not forward link local multicast packets. To support some functions, such as for Duplicate Address Detection (DAD), MAGs might proxy associated Neighbor Discovery messages to perform DAD procedure with LMA nodes. 9.2.2. IP Multicast Three options have been identified to support IP multicast within a NetLMM domain. Option 1 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. Option 2 implies that MAG nodes are multicast-enabled routers and IP multicast traffic is tunnelled via the NetLMM domain's LMA nodes. Option 3 implies that an NetLMM domain's LMA nodes are multicast- enabled routers. LMA nodes join a multicast-tree and forward IP multicast packets to MAG nodes according to the selected forwarding approach. MAG nodes must coordinate multicast listeners according to IGMP operation [RFC3376] and communicate with LMA nodes using PIM control messages [RFC2362] to control IP multicast forwarding path between LMA nodes and respective MAG nodes, which have multicast listeners attached. LMA nodes coordinate multicast listener registration with other multicast routers, which are outside of an NetLMM domain, by means of PIM control messages. An exemplary IP multicast join procedure is illustrated in Fig. *MCJOIN* The specification of default operation for IP multicast support and optional enhancements is for further study and t.b.d. Giaretta, et al. Expires December 21, 2006 [Page 40] Internet-Draft NetLMM Protocol June 2006 +--+ +---+ +---+ +--+ |MN| |MAG| |LMA| |MR| +--+ +---+ +---+ +--+ | | | | | | | | |----IGMP---->| | | | |----PIM Join--->| | | | |----PIM Join----->| / / / / / / / / |<------------|<===============|<-----------------|<--MC Data | | | forward to group | |-- MC Data-->|===============>|----------------->|--> Figure *MCJOIN*: IP multicast join procedure for the case that LMA nodes and MAG nodes are multicast routers. 9.3. Forwarding of Broadcast Data Packets Version 0 of the NetLMM protocol specification does not consider forwarding of broadcast data packets. 10. Protocol Constants and Configuration Variables 11. Security Considerations The NetLMM protocol is executed between the MAG and LMA. The messages are used to create, update and delete mobility state in MAG and LMA. If the NetLMM signalling messages are not authenticated, following attacks are possible. * A malicious node can pretend to be MAG and associate with the LMA. This in itself may not create any harm if subsequent messages are authenticated. But it does allow for the attacker to learn the capabilities of the LMA which in turn may be used to exploit the specific weaknesses. * A malicious node can pretend to be MAG and send a location registration message to LMA. There are a couple of variants of this attack. - The MN is currently attached to MAG-1 and the IP address of the MN is known. A malicious node MAG-2 sends the location registration message to redirect all the traffic destined for the MN to itself. This enables the attacker to steal the MN's Giaretta, et al. Expires December 21, 2006 [Page 41] Internet-Draft NetLMM Protocol June 2006 traffic. This attack may be detected by MAG-1 when it receives the location de-registration message from LMA while the MN is still attached. The detection of the attack depends on the security of mechanism used to detect the MN's attachment. - The MN is currently attached to MAG-1 and the IP address of the MN is not known. A malicious node MAG-2 sends the location registration message to redirect all the traffic destined for the MN to itself. The LMA would update the mobility state for MN with the ID of MAG-2. Later when the MN-address-setup messages comes from MAG-1, it would fail because the MAG IDs don't match. * A malicious man-in-the-middle node can alter the messages sent between MAG and LMA that can result in random attacks. For example, the attacker can modify the MN Identifier in the location registration message of MN-1 to that of MN-2. When MN-2 moves to a new link, it results in a new location registration message to be sent with MN-2 ID. This will cause the traffic destined to MN-1 address to be destined to the current link causing disruption for both MN-1 and MN-2. These attacks can be prevented by providing data origin authentication for the messages exchanged between LMA and MAG. This can be achieved by using IPsec ESP [RFC4303] with null-encryption and non-null authentication between MAG and 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. Hence, 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 be used to protect the signalling messages. Anomalous events should be logged. For example, once an address is assigned to the Mobile node, MN address setup message should appear at the LMA sooner or later. If it does not appear within a certain period of time, it should be considered as an error and logged. [TBD: May be document more of such events]. NetLMM messages are triggered by MN attachment and detachment to the MAG. The threats specific to MN-MAG interface are discussed in [I-D.ietf-netlmm-threats]. When neighbor discovery messages [I-D.ietf-ipv6-2461bis] are used as triggers, it should be secured using [RFC3971]. Giaretta, et al. Expires December 21, 2006 [Page 42] Internet-Draft NetLMM Protocol June 2006 12. IANA Considerations 13. 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. 14. Acknowledgments 15. References 15.1. Normative References [I-D.ietf-ipv6-2461bis] Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", draft-ietf-ipv6-2461bis-07 (work in progress), May 2006. [I-D.ietf-netlmm-nohost-ps] Kempf, J., "Problem Statement for Network-based Localized Mobility Management", draft-ietf-netlmm-nohost-ps-04 (work in progress), June 2006. [I-D.ietf-netlmm-nohost-req] Kempf, J., "Goals for Network-based Localized Mobility Management (NETLMM)", draft-ietf-netlmm-nohost-req-01 (work in progress), April 2006. [I-D.ietf-netlmm-threats] Kempf, J. and C. Vogt, "Security Threats to Network-based Localized Mobility Management", draft-ietf-netlmm-threats-00 (work in progress), April 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. [RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., and V. Jacobson, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998. Giaretta, et al. Expires December 21, 2006 [Page 43] Internet-Draft NetLMM Protocol June 2006 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [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. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 4330, January 2006. 15.2. Informative References [ENTERPRISE-NUM] IANA, "IANA Enterprise Numbers Registry"", 2006. [RFC4064] Patel, A. and K. Leung, "Experimental Message, Extensions, and Error Codes for Mobile IPv4", RFC 4064, May 2005. Appendix A. TODO (Things that remain to be specified...) This is a short list of things that remain to be specified in future revisions of this document: * Describe the re-send mechanism for control messages, in order to provide reliable delivery. Giaretta, et al. Expires December 21, 2006 [Page 44] Internet-Draft NetLMM Protocol June 2006 * Add an "LMA Announce message" which can be multicast from a newly connected LMA to trigger listening MAGs to send it Association Requests. * Add the capability to do bulk MN de-registrations and possibly registrations. * A review to ensure that all aspects of the protocol permits operation with both single /128 addresses and for instance /64 prefix allocations to mobile nodes. * Add reserved status ranges (Section 7.1.1) for vendor-specific status, LMA status?, MAG status?. * Add experimental message, option and status values, in accordance with [RFC4064]. * Add a Heartbeat Sequence Number Option, to hold heartbeat-specific sequence numbers needed by algorithms for reacting to missed heartbeats. Write up suggested algorithm. * Make sure the use of the identity / locator split paradigm is consistent and workable throughout the document. Cover resolution of ID to locator. * Define how capability exchanges are handled, and how a unique common capability is derived, for instance to find the tunnelling method to be used as a result of the Association Request and Reply. * Add message and signalling optimization according to Section 5.12. * Maybe change the range-based skippable or non-skippable nature of Options to be indicated by a bit instead? * Point out somewhere that although a NetLMM Domain may have multiple LMAs, a MN is always served by the same LMA once an LMA has been assigned. * Appendix B. Using GRE Tunnels with NetLMM ** Text to be written ** Giaretta, et al. Expires December 21, 2006 [Page 45] Internet-Draft NetLMM Protocol June 2006 Appendix C. Using MPLS with NetLMM ** Text to be written ** Appendix D. TTL Handling ** Text to be written ** Appendix E. 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 F. Out of scope - Inter-MAP handover - Fast handover - Hierarchical MAP Giaretta, et al. Expires December 21, 2006 [Page 46] Internet-Draft NetLMM Protocol June 2006 Authors' Addresses 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 Phil Roberts Motorola 1301 E Algonquin Rd Schaumberg, IL 60196 USA Email: phil.roberts@motorola.com Giaretta, et al. Expires December 21, 2006 [Page 47] Internet-Draft NetLMM Protocol June 2006 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 Henrik Levkowetz Ericsson Torsgatan 71 Stockholm S-113 37 SWEDEN Phone: +46 708 32 16 08 Email: henrik@levkowetz.com Giaretta, et al. Expires December 21, 2006 [Page 48] Internet-Draft NetLMM Protocol June 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Giaretta, et al. Expires December 21, 2006 [Page 49]