NetLMM H. Levkowetz, Ed. Internet-Draft Ericsson Expires: March 22, 2007 G. Giaretta Telecom Italia K. Leung Cisco M. Liebsch NEC P. Roberts Motorola K. Nishida NTT DoCoMo Inc. H. Yokota KDDI Labs M. Parthasarathy Nokia September 18, 2006 The NetLMM Protocol draft-giaretta-netlmm-dt-protocol-01 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 March 22, 2007. Copyright Notice Levkowetz, et al. Expires March 22, 2007 [Page 1] Internet-Draft The NetLMM Protocol September 2006 Copyright (C) The Internet Society (2006). Abstract This document specifies an Internet protocol that allows mobile nodes to move around in a local mobility domain, changing their point of attachment within the domain, but without ever being aware at the IP layer that their point of attachment has changed, and maintaining seamless communication in the presence of such changes. It defines two protocol entities, a Mobile Access Gateway and a Local Mobility Anchor, and a set of messages between them, that together make these mobility events transparent to the mobile nodes at the IP layer, as long as they remain within the local mobility domain. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Functional Entities . . . . . . . . . . . . . . . . . . . . . 7 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Mobility Management . . . . . . . . . . . . . . . . . . 8 4.2. Setup and Node Association . . . . . . . . . . . . . . . 12 4.3. Message Transport . . . . . . . . . . . . . . . . . . . 13 5. Message Format and Message Types . . . . . . . . . . . . . . . 15 5.1. Message Format . . . . . . . . . . . . . . . . . . . . . 15 5.2. LMA Allocation Request . . . . . . . . . . . . . . . . . 17 5.3. Location Registration . . . . . . . . . . . . . . . . . 17 5.4. Location Deregistration . . . . . . . . . . . . . . . . 18 5.5. Association Request . . . . . . . . . . . . . . . . . . 18 5.6. Disassociation Request . . . . . . . . . . . . . . . . . 19 5.7. Heartbeat . . . . . . . . . . . . . . . . . . . . . . . 19 5.8. Acknowledgements . . . . . . . . . . . . . . . . . . . . 21 5.9. Message Status Codes . . . . . . . . . . . . . . . . . . 21 6. Option Format and Option Types . . . . . . . . . . . . . . . . 23 6.1. Option Format . . . . . . . . . . . . . . . . . . . . . 23 6.2. Option Alignment . . . . . . . . . . . . . . . . . . . . 24 6.3. ID Option . . . . . . . . . . . . . . . . . . . . . . . 25 6.4. Prefix Option . . . . . . . . . . . . . . . . . . . . . 26 6.5. Data Transport Option . . . . . . . . . . . . . . . . . 28 6.6. Deregistration Timeout Option . . . . . . . . . . . . . 29 6.7. Timestamp Option . . . . . . . . . . . . . . . . . . . . 30 6.8. Vendor-Specific Option . . . . . . . . . . . . . . . . . 31 6.9. Registration Lifetime Option . . . . . . . . . . . . . . 32 6.10. Status Option . . . . . . . . . . . . . . . . . . . . . 32 7. Protocol Specification . . . . . . . . . . . . . . . . . . . . 33 7.1. Mobile Access Gateway Operation . . . . . . . . . . . . 33 7.2. Local Mobility Anchor Operation . . . . . . . . . . . . 38 Levkowetz, et al. Expires March 22, 2007 [Page 2] Internet-Draft The NetLMM Protocol September 2006 8. Data Transport . . . . . . . . . . . . . . . . . . . . . . . . 41 8.1. Forwarding of Unicast Data Packets . . . . . . . . . . . 42 8.2. Forwarding of Multicast Data Packets . . . . . . . . . . 43 8.3. Forwarding of Broadcast Data Packets . . . . . . . . . . 45 9. Protocol Constants and Configuration Variables . . . . . . . . 45 10. Security Considerations . . . . . . . . . . . . . . . . . . . 45 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 46 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 47 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47 14.1. Normative References . . . . . . . . . . . . . . . . . . 47 14.2. Informative References . . . . . . . . . . . . . . . . . 48 Appendix A. TODO (Things that remain to be specified...) . . . . 48 A.1. Montreal DT Meeting Todo List . . . . . . . . . . . . . 49 A.2. Montreal DT Meeting issues list . . . . . . . . . . . . 50 Appendix B. MN-AR Interface considerations . . . . . . . . . . . 51 Appendix C. Issues with omitting the MN Address Setup and Routing Setup . . . . . . . . . . . . . . . . . . . . 52 Appendix D. Out of scope . . . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54 Intellectual Property and Copyright Statements . . . . . . . . . . 56 Levkowetz, et al. Expires March 22, 2007 [Page 3] Internet-Draft The NetLMM Protocol September 2006 1. Introduction This document specifies a protocol that allows nodes to move around in an access network, attaching to various points of the network while maintaining an IP layer configuration that does not change as the mobile nodes' points of attachment change. This protocol is not intended to solve all the problems of network- based IP mobility. Over the past decade many companies and forums have provided many, many staff years of research, development, and standardization to realize all IP mobile networks and no doubt many more years of effort are ahead to deliver improvements to realize all the envisioned usage of such technology. Such systems have added technology for specific link layers, and carrying IP packets over those link layers, support for AAA infrastructures, and mobile security to name a few. Challenges still lie ahead in the form of for instance mobile QoS, power management and paging, and management of changing network conditions in the face of various mobility events. The protocol described in this memo is developed in response to the problem statement for network-based localized mobility [I-D.ietf- netlmm-nohost-ps] and attempts to satisfy the goals in the NetLMM goals document [I-D.ietf-netlmm-nohost-req]. It is intended basically to solve the problem of packet forwarding to nodes that change their point of attachment to the network without the use of any protocol support at the IP layer on the mobile node to support that mobility. This document defines operation of the protocol for use in an IPv6 infrastructure and in support of IPv6 nodes, but the authors envision that with modifications the protocol could be used with an IPv4 infrastructure or to support IPv4 nodes. The document refers conscientiously to mobile nodes rather than mobile hosts because its operation is not limited in any way to host only support. This protocol has both some similarities and some clear differences with various IP mobility protocols the IETF has standardized in the past. It is similar in that it continues the tradition of maintaining address continuity to mobile nodes regardless of the fact that those nodes have changed their points of attachment in the network. It differs in that it does not require any operational changes in protocol operation between the mobile node and the network at the IP layer, in that it supports an infrastructure that embraces network controlled mobility operation, and in that its operation is limited in scope rather than globally applicable. The differences between this protocol and previous mobility protocols Levkowetz, et al. Expires March 22, 2007 [Page 4] Internet-Draft The NetLMM Protocol September 2006 are complementary rather than contradictory. It is quite possible to conceive of deployments in which mobile IP is used in a wide area to provide mobility services across multiple interface types or separate local mobility domains while NetLMM is used within a single type of access network or a single local mobility domain to facilitate mobility without involving the mobile. 2. Terminology In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Mobility terminology in this document follows that in RFC 3753, "Mobility Related Terminology" [RFC3753], with the added specification of some terms as they are used in this particular document: IP Link A set of routers, mobile nodes, and wireless access points that share link broadcast capability or its functional equivalent. This definition covers one or multiple access points under one or several access routers. In the past, such a set has been called a subnet, but this term is not strictly correct for IPv6, since multiple subnet prefixes can be assigned to an IP link in IPv6. Access Network (revised) An Access Network consists of following three components: wireless or other access points, access routers, access network gateways which form the boundary to other networks and may shield other networks from the specialized routing protocols (if any) run in the Access Network; and (optionally) other internal access network routers which may also be needed in some cases to achieve a specialized routing protocol. Local Mobility (revised) Local Mobility is mobility over a restricted area of the network topology. Note that, although the area of network topology over which the mobile node moves may be restricted, the actual geographic area could be quite large, depending on the mapping between the network topology and the wireless coverage area. Levkowetz, et al. Expires March 22, 2007 [Page 5] Internet-Draft The NetLMM Protocol September 2006 Localized Mobility Management Localized Mobility Management is a generic term for protocols dealing with IP mobility management confined within the access network. Localized Mobility Management signaling is not routed outside the access network, although a handover may trigger Global Mobility Management signaling. Localized Mobility Management protocols exploit the locality of movement by confining movement related changes to the access network. Localized Mobility Management Protocol A protocol that supports localized mobility management. Intra-Link Mobility Intra-Link Mobility is mobility between wireless access points within an IP Link. Typically, this kind of mobility only involves Layer 2 mechanisms, so Intra-Link Mobility is often called Layer 2 mobility. No IP link configuration is required upon movement since the link does not change, but some IP signaling may be required for the mobile node to confirm whether or not the change of wireless access point also resulted in a change of IP link. If the IP link consists of a single access point/router combination, then this type of mobility is typically absent. Mobile Access Gateway (MAG) A Mobile Access Gateway (MAG) is a router embedded in a device that terminates a specific link layer technology to which mobile nodes attach themselves. It terminates one end of the MAG of the connection to one or more Local Mobility Anchors and participates in the NetLMM protocol exchange. Local Mobility Anchor (LMA) A local mobility anchor (LMA) is a router that terminates connections to multiple Mobile Access Gateways, services mobility requests for mobile nodes moving within a NetLMM system, and participates in the NetLMM protocol exchange. NetLMM Domain A NetLMM domain is a set of multiple MAGs and a set of one or more LMAs interconnected within an access network that provides mobility operations for attached mobile nodes through the execution of the NetLMM protocol. NetLMM Address The invariant IP address on the MN inside the NetLMM domain. For IPv6 it is assumed that this is an invariant routable IP address with global scope. Levkowetz, et al. Expires March 22, 2007 [Page 6] Internet-Draft The NetLMM Protocol September 2006 NetLMM Network Prefix The NetLMM Network Prefix (NNP) is the IPv6 link prefix of the NetLMM address. 3. Functional Entities The principal functional entities in a NetLMM infrastructure are the Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA). An access network with NetLMM based mobility support may also have other nodes which support various other functionality such as AAA, routing, DNS, etc., and the functionality of these nodes may be used by the MAG and the LMA, but the operation of such additional nodes need not be changed in any way for the proper operation of the NetLMM protocol. +---------+ +---------+ | LMA La1 | (other LMAs) | LMA Lb1 | (other LMAs) +---------+ +---------+ @ @ @ @ @ @ @ @ @ (other routers) @ @ @ @ @ @ @ @ @ +-------+ +-------+ +-------+ |MAG Ra1| |MAG Ra2|(other MAGs) |MAG Rb1| (other MAGs) +-------+ +-------+ +-------+ * * * * * * * * * * * * * * * * * * * * * * * * * * (other APs) * * (other APs) /\ /\ /\ /\ /\ /AP\ /AP\ /AP\ /AP\ /AP\ / Pa1\ / Pa2\ / Pa3\ / Pb1\ / Pb2\ ------ ------ ------ ------ ------ +--+ +--+ +--+ +--+ |MN|----->|MN|----->|MN|----------->|MN| +--+ +--+ +--+ +--+ Intra-link Local Global (Layer 2) Mobility Mobility Mobility Levkowetz, et al. Expires March 22, 2007 [Page 7] Internet-Draft The NetLMM Protocol September 2006 Figure 1 The Mobile Access Gateway The Mobile Access Gateway (MAG) is a router that a mobile node is attached to as the first hop router in the NetLMM infrastructure. The MAG is connected to the mobile node over some specific link provided by a link layer but the NetLMM infrastructure is agnostic about the link layer technology that is used. Each MAG has its own identifier used in NetLMM protocol messaging between the MAG and the LMA. The important interfaces between link layer specific functions and the NetLMM function reside on the MAG. There are multiple MAGs in a NetLMM infrastructure. The Local Mobility Anchor The local mobility anchor (LMA) is a router that maintains reachability to a mobile node's address while the mobile node moves around within the NetLMM infrastructure. It is responsible for maintaining forwarding information for the mobile nodes which includes a set of mappings to associate mobile nodes by their identifiers with their address information, associating the mobile nodes with their serving MAGs and the relationship between the LMA and the MAGs. There may be one or more LMAs in a NetLMM infrastructure. 4. Protocol Overview The protocol consists of two groups of messages. The first group provides the basic mobility support, which is the end purpose of the protocol, while the second group provides necessary support for maintaining and managing association and connectivity between the LMAs and MAGs. It is not assumed that a MAG is associated with only a single LMA. If there exists multiple LMAs in a NetLMM Domain, each MAG would most likely be associated with, and potentially communicate with all the LMAs rather than only a single LMA. However, the same is not true for mobile nodes. As they move around, and their traffic is routed through various MAGs, their routing state is handled by one specific LMA; the serving LMA does not change. 4.1. Mobility Management The NetLMM infrastructure uses 3 messages pairs to manage the attachment, departure, mobility, and other activities of mobile nodes within the infrastructure: Levkowetz, et al. Expires March 22, 2007 [Page 8] Internet-Draft The NetLMM Protocol September 2006 * LMA Allocation * Location Registration * Location Deregistration 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 acknowledges the request with an Acknowledgement. It is possible that an LMA is configured to authorize service for any mobile node and in such a situation the LMA Allocation Request message is not necessary. When a mobile node connects to the NetLMM infrastructure (see Figure 2), 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. This specification assumes that a separate subnet prefix is allocated to each mobile node, and does not cover the case of the whole NetLMM domain being organized as a multi-link subnet common to all mobile nodes in the domain. As a result of the mobile node connecting, the MAG sends a Location Registration message to the LMA containing its own ID, the LMA's ID and the Mobile Node's ID. If no error is found, the LMA responds to the message with a Location Registration Ack message. If the MAG obtains the NetLMM subnet prefix for the MN first, the MAG transfers this prefix to the LMA via the Location Registration message. On the other hand, if the LMA obtains the NetLMM subnet prefix for the MN, the LMA transfers the prefix to the MAG via the Location Registration Ack. The LMA creates forwarding state for packets based on the subnet prefix allocated to the MN. At this point, it is assumed that the NetLMM prefix is unique to each MN (per-MN subnet); therefore, the MAG and the LMA can route packets destined for the MN by the NetLMM subnet prefix. The case for the shared prefix mode requires additional messages which are not specified in this memo. The MAG, when receiving a successful Acknowledgement to the Location Registration message, creates forwarding state for packets destined to the mobile node, also based on the subnet prefix. In the case of stateless address configuration being used, the MAG also sends a router advertisement to the attached mobile. Levkowetz, et al. Expires March 22, 2007 [Page 9] Internet-Draft The NetLMM Protocol September 2006 +-----+ +-----+ +-----+ +-----+ | MN | | MAG | | LMA | | PDP | +-----+ +-----+ +-----+ +-----+ | | | | * 0.MN Attachment | | | | | | | | | |2.LMA Allocation | | | | (MN ID) | | | |<- - - - - - - - - | | | | | | | |3.Acknowledgement | | | | (MN ID,Status) | | | |- - - - - - - - - >| | | | | | 4."MN_Access_Network API" | | | (MN ID,LMA ID) | | | | | | | * | | | | | | | |5.Location Reg. | | | |(MN ID,MAG ID,LMA ID) | | |------------------>| | | | | | | |6.Acknowledgement | | | |(MN ID,MAG ID,LMA ID,Prefix, Status) | | |<------------------| | . . . . . . . . . . . . | | | | |7.Router Advertisement | | | (Prefix) | | | |<==================| | | | | | | |8.IP Address DAD | | | | (Address) | | | |==================>| | | ..... Non-NetLMM signalling - - - Optional NetLMM signalling ----- NetLMM signalling ===== Link-Layer signalling Figure 2 When a mobile node then leaves the NetLMM infrastructure, the MAG sends a Location Deregistration message to the LMA including the Levkowetz, et al. Expires March 22, 2007 [Page 10] Internet-Draft The NetLMM Protocol September 2006 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 an acknowledgement. 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 the associated 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 (see Figure 3), 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 an acknowledgement to the nMAG that includes the MN ID, the MAG ID, the LMA ID, and prefix information that the nMAG uses in the router advertisement for the MN. Levkowetz, et al. Expires March 22, 2007 [Page 11] Internet-Draft The NetLMM Protocol September 2006 +-----+ +-------+ +-------+ +-----+ | MN | |old MAG| |new MAG| | LMA | +-----+ +-------+ +-------+ +-----+ | | | | * 0.MN Attachment | | | | | | | | | 1."MN_Access_Network API" | | | (MN ID,LMA ID,Prefix) | | | | | | | * | | | | | | | |2.Location Registration | | | (MN ID,MAG ID,LMA ID) | | |------------------>| | | | | | | |3.Acknowledgement | | | | (MN ID,MAG ID,LMA ID, | | | Prefix,Status) | | | |<------------------| | | | | | | 4.Location Deregistration | | | (MN ID, MAG ID,LMA ID) | | |<--------------------------------------| | | | | | | 5.Acknowledgement | | | | (MN ID,MAG ID,LMA ID,Status) | | |-------------------------------------->| | | | | Figure 3 4.2. Setup and Node Association The NetLMM infrastructure uses 3 message pairs to establish and maintain associations between the MAGs and the LMAs: * Association Request / Ack * Disassociation Request / Ack * Heartbeat / Ack A MAG associates itself with an LMA by sending an Association Request message (see Figure 4) that includes its MAG ID and the supported data forwarding modes (such as IPv6-in-IPv6) [RFC2473]. In response the LMA creates an association with the MAG and populates state information about the association. The LMA responds, providing an agreed upon data forwarding mode to the MAG. The MAG can undo the relationship with the LMA through sending a Disassociation Request, Levkowetz, et al. Expires March 22, 2007 [Page 12] Internet-Draft The NetLMM Protocol September 2006 to which the LMA responds with an acknowledgement. Heartbeat messages MAY be sent between the MAG and LMA to determine the current status of the reachability of the other entity. All of these messages may be sent optionally over an IPsec connection if additional security is desired. +-----+ +-----+ | MAG | | LMA | +-----+ +-----+ | | | Association Request | | (MAG ID, LMA ID, DataTransport) | |---------------------------------------->| | | | Acknowledgement | | (MAG ID,LMA ID, DataTransport, Status) | |<----------------------------------------| . . . . . (Regular operation message flows, . . optionally Heartbeats) . . . | Disssociation Request | | (MAG ID, LMA ID) | |---------------------------------------->| | | | Acknowledgement | | (MAG ID,LMA ID, Status) | |<----------------------------------------| Figure 4 4.3. Message Transport The NetLMM control messages defined in this document are carried by the User Datagram Protocol RFC 768 [RFC0768] using well known port number NETLMM_UDP_PORT (TBD -- assigned by IANA -- please replace 'NETLMM_UDP_PORT with the actual port number here and below). Any implementation of the NetLMM protocol MUST include support for IPsec protected transport, using Encapsulating Security Payload [RFC4303] in transport mode. IPsec SHOULD be used unless other means of protecting the NetLMM control signalling provide enough security within the NETLMM domain. If IPsec is used, it MUST use a non-NULL authentication algorithm to provide data origin authentication. The message sender SHOULD include a non-zero UDP Checksum. The Levkowetz, et al. Expires March 22, 2007 [Page 13] Internet-Draft The NetLMM Protocol September 2006 recipient of the message MUST process and check the UDP checksum. A Zero checksum SHOULD be accepted by the recipient. The sender and initiator of a message exchange MUST use the following UDP ports: * Source Port: variable * Destination Port: NETLMM_UDP_PORT When the recipient of a NetLMM message sends an Acknowledgement, the following UDP ports MUST be used: * Source Port: variable * Destination Port: Copied from the source port of the received message. 4.3.1. Message Retransmission To ensure reliable delivery of control messages, NetLMM requires a positive acknowledgement from the receiver and retransmission by the sender for an unacknowledged message. Each request message has a corresponding acknowledgement message, which must be used to acknowledge receipt of the request message. In the acknowledgements, NetLMM entities can append message options (defined in Section 6) according to the protocol operation (Section 4 and Section 5). NetLMM entities maintain a retransmission timer T-rtx and MUST support the basic back-off scheme described below for the retransmission timeout (RTO). After a NetLMM control message has been sent, the NetLMM entity initializes T-rtx with an RTO value of RTO_INIT. If the acknowledgement of the associated NetLMM control message is received before T-rtx has expired, T-rtx is stopped. If T-rtx expires before the acknowledgement is received, the NetLMM entity retransmits the packet using the same sequence number as for the original packet. For each retransmission, the NetLMM entity should set the new RTO value to twice the previous RTO duration (e.g. new_RTO = 2 * previous_RTO). The RTO value SHOULD not exceed the limit of RTO_MAX seconds. The value for RTO_INIT and RTO_MAX should be configurable, with a resolution better than 1 second (such as 1 ms, for instance). In case a NetLMM entity has multiple associations, an individual RTO Levkowetz, et al. Expires March 22, 2007 [Page 14] Internet-Draft The NetLMM Protocol September 2006 must be maintained for each associated NetLMM peer entity. Optionally, NetLMM entities MAY use more enhanced schemes to dynamically re-calculate and adjust the RTO. As an example, the RTO could be derived from periodic round trip time (RTT) measurements and RTT deviations, as utilized by the Stream Control Transport Protocol (SCTP) [RFC2960]. If no enhanced approach for RTO derivation is supported, NetLMM entities MUST use the basic approach as described above. Heartbeat messages are not considered NetLMM control messages in the context of this section; they are handled according to Section 5.7.1 and are not re-transmitted. The default values for RTO_INIT and RTO_MAX are defined as follows: RTO_INIT = 1 second RTO_MAX = 64 seconds 5. Message Format and Message Types 5.1. Message Format An NetLMM message consists of a header followed by one or more options. The message header is common and messages are distinguished by Type field in the header. NetLMM options are in TLV format and 8-octet aligned, with a Type field divided into two parts; Option Type and Option Sub-Type. All option payloads whose length is not a unit of 8 octets must be padded to the correct alignment. All NetLMM messages start with the following common header. Parameters for each message are contained in the option format (see following sections). Levkowetz, et al. Expires March 22, 2007 [Page 15] Internet-Draft The NetLMM Protocol September 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Type | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . Src ID Option . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . Dst ID Option . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Version An 8-bit number, indicating the NetLMM protocol version. The version of the NetLMM protocol specified in this document is 1. Type 8-bit value indicating the NetLMM message type. The message types are specified below, in following sections. Sequence Number 16-bit length, used to ensure the correspondence of request and acknowledgement messages between the MAG and the LMA. The sequence number is exchanged between given MAG and LMA, and configured when MAG has joined to a NetLMM domain through the exchange of Association Request/Acknowledgement messages. Sequence Number comparisons MUST be performed modulo 2^16, i.e., the number is a free running counter represented modulo 65536. A Sequence Number in a received message is considered less than or equal to the last received number if its value lies in the range of the last received number and the preceding 32768 values, inclusive. For instance, if the last received sequence number was 15, then messages with sequence numbers 0 through 15, as well as 32783 through 65535, would be considered 'less than or equal'. Reserved 32-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Levkowetz, et al. Expires March 22, 2007 [Page 16] Internet-Draft The NetLMM Protocol September 2006 Src ID Option An ID Option (Section 6.3) giving the ID of the source of the message Dst ID Option An ID Option giving the ID of the destination of the message. 5.2. LMA Allocation Request Request Message Type: 0 Required options: Sender ID, LMA ID, MN ID Acknowledgement Message Type: 64 Required options: Status Implementation: Mandatory Use: Optional The LMA Allocation Request message MAY be used to allocate an LMA for the MN that is initially attached to the network so that subsequent Location Registration messages from MAGs to which the MN is attached can be validated. 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. An Acknowledgement of the The LMA Allocation message is sent from the LMA to the source of the LMA Allocation Request message to indicate the status of the request (success or error code). 5.3. Location Registration Request Message Type: 1 Required options: MAG ID, LMA ID, MN ID Acknowledgement Message Type: 65 Required options: MAG ID, LMA ID, MN ID, Status Implementation: Mandatory Use: Mandatory The Location Registration message is sent from the MAG to the LMA when the MAG detects the MN having accessed the network without an IP address. The mobility state of the MN, in the MAG and LMA, is created or updated using this message. The Location Registration Acknowledgement is sent from the LMA to the Levkowetz, et al. Expires March 22, 2007 [Page 17] Internet-Draft The NetLMM Protocol September 2006 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.4. Location Deregistration Request Message Type: 2 Required options: MAG ID, LMA ID, MN ID Acknowledgement Message Type: 66 Required options: MAG ID, LMA ID, MN ID, Status Implementation: Mandatory Use: Mandatory 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 is at a new location. This message contains the MN ID, MAG ID, LMA ID and may contain a Deregistration Timeout option, providing a delayed de-registration. An Acknowledgement message is sent back to the source of the Location Deregistration message to acknowledge the receipt of the Location Deregistration message. This message may contain the applied de- registration delay time. 5.5. Association Request Request Message Type: 16 Required options: MAG ID, LMA ID, Data Transport Acknowledgement Message Type: 80 Required options: MAG ID, LMA ID, Data Transport, Status Implementation: Mandatory Use: Mandatory The Association Request is used to set up the control and data plane relationship between the MAG and LMA. This message is sent from the MAG to the LMA in the MAGs initiation phase, before it enters the operational phase and handles MN Location Registration. The message contains the sender's ID, its functional capabilities and supported data forwarding modes. The data forwarding mode specifies the tunnel method of the data plane (e.g., IP-in-IP). The tunnel between the MAG and LMA is bidirectional, which is achieved by establishing two Levkowetz, et al. Expires March 22, 2007 [Page 18] Internet-Draft The NetLMM Protocol September 2006 unidirectional tunnels in opposite directions. An acknowledgement to the the Associate Request message is sent from the LMA to the MAG to indicate the status of the request (success or error code). If the request is successful, the receiver of the request also sends back one choice from each set of capabilities specified in the Association Request, indicating for each capability the method which will be used by the two nodes. 5.6. Disassociation Request Request Message Type: 17 Required options: MAG ID, LMA ID Acknowledgement Message Type: 81 Required options: MAG ID, LMA ID, Status Implementation: Mandatory Use: Mandatory The Disassociation Request message is sent from the MAG to the LMA or vice versa to tear down the control and data plane relationship between them. This message contains the MAG ID and LMA ID. An acknowledgement of the the Disassociate Request message is sent from the LMN to the MAG or vice versa to indicate the status of the request (success or error code). 5.7. Heartbeat Request Message Type: 18 Required options: MAG ID, LMA ID Acknowledgement Message Type: 82 Required options: MAG ID, LMA ID Implementation: Mandatory Use: Optional The Heartbeat message is sent from the MAG to LMA or vice versa to obtain the connectivity status. This message contains the MAG ID and the LMA ID. It MAY contain other options, such as a Timestamp Option. Contrary to the case for other NetLMM messages, Heartbeat messages are never re-transmitted. The Heartbeat Ack is sent back from the node that received the Heartbeat message to its peer. This message contains the MAG ID and the LMA ID. It MAY contain other options, such as a Timestamp Levkowetz, et al. Expires March 22, 2007 [Page 19] Internet-Draft The NetLMM Protocol September 2006 Option. 5.7.1. Heartbeat Handling If used, Heartbeats are sent at a fixed, configurable rate, determined by the HEARTBEAT_SEND_INTERVAL, and a history is kept for the last HEARTBEAT_HISTORY_SIZE heartbeats. The history has a number of slots (equal to HEARTBEAT_HISTORY_SIZE), and each slots holds the Sequence Number of the Heartbeat message sent in that time-slot, the time at which the Heartbeat message was sent, and the number of Heartbeat Acknowledgements that were received during that time-slot. The following algorithm is used to detect connectivity and load problems: Each time a Heartbeat message is sent, the message sequence number is registered in the heartbeat history. A count is also made of the number of received Heartbeat Acknowledgements recorded in the heartbeat history. Except during startup, when the number of heartbeats recorded in the history is less than HEARTBEAT_HISTORY_SIZE, the heartbeat loss ratio is calculated as (heartbeats_sent - received_acks) / (hearbeats_sent). If the ratio is larger than a configurable value HEARTBEAT_LOSS_THRESHOLD, an alarm should be raised, and the event MUST be logged. (The heartbeat loss rate can be derived from the heartbeat loss ratio as loss_rate = loss_ratio / HEARTBEAT_SEND_INTERVAL). When a Heartbeat message is received by the destination node, it MUST respond with a Heartbeat Ack with the same Sequence Number as the received Heartbeat message. When a Heartbeat Ack is received, the count of received acknowledgements is increased for the current history time-slot and the time since the corresponding Heartbeat message was sent is calculated. If the corresponding heartbeat's Sequence Number is no longer on record in the heartbeat history, the value (HEARTBEAT_SEND_INTERVAL * HEARTBEAT_HISTORY_SIZE is used). If this calculated delay is larger than a configurable value HEARTBEAT_DELAY_THRESHOLD, an alarm should be raised, and the event MUST be logged. The Heartbeat loss rate is primarily an indication of the quality of the communication link, while the Heartbeat delay is primarily an indication of the load of the peer. A sudden overload situation can also manifest as an apparent sudden in crease in loss rate, but in the absence of link problems, a steady state high load situation will show an acceptable loss rate, but a large heartbeat delay. Levkowetz, et al. Expires March 22, 2007 [Page 20] Internet-Draft The NetLMM Protocol September 2006 An implementation of the NetLMM protocol may adjust its resend timeout value (RTO) based on both the heartbeat loss rate and the average heartbeat delay. For instance, a RTO which is lower than the average heartbeat delay will result in unnecessary re-sends and added load in a high-load situation. 5.8. Acknowledgements An acknowledgement MUST be sent in response to any non- Acknowledgement message. It is sent from the node that received the initial message to the originator of that message. It indicates that the initial message has been received, and also carries a status value which indicates the result of the operation requested by the initial message. The Sequence Number field of an acknowledgement message MUST be set to the same value as the Sequence Number of the message which it acknowledges, in order to support the message re-send mechanism described in Section 4.3. The acknowledgement message MUST contain at least the Status Option (Section 6.10) except in the case of the Heartbeat Acknowledgement, but may also contain other options which are appropriate in response to the initial message. 5.9. Message Status Codes The status codes used by the NetLMM protocol are used when acknowledging a message, to indicate the result of processing the associated request message. The status code is carried in the Status Option (Section 6.10). The status codes are allocated in ranges, depending on their usage. The defined ranges are as follows: 0 - 63: Generic Status This range is used for status codes which are of a generic nature, and not specific to MAG or LMA. 64 - 127: LMA-specific Status This range is used for status codes which are specific to the LMAs. 128 - 191: MAG-Specific Status This range is used for status codes which are specific to the LMAs. Levkowetz, et al. Expires March 22, 2007 [Page 21] Internet-Draft The NetLMM Protocol September 2006 192 - 255: Reserved This range is reserved for future use. The following values are defined by this document: 0: Not Applicable (N/A) The status code is not applicable for the message. 1: Success The associated request message was successfully processed. 2: Administratively Prohibited An action was refused due to administrative policy reasons. 3: Lack of Resources The resources needed to provide the requested service was not available. 4: Invalid Message The NetLMM Request message was invalid or malformed. 62: Vendor-Specific Status (Generic) For use with vendor-specific messages. Additional status detail may be provided for instance in vendor-specific options. 63: Experimental Status (Generic) For use during experimental implementation of new protocol features, according to "Assigning Experimental and Testing Numbers Considered Useful" [RFC3692] 64: Unauthorized MN Used by the LMA in response to Location Registration, to notify the MAG of the MN not being authorized for service. 65: Duplicate Prefix Used by the LMA when an Location Registration contains an IP address or prefix that is duplicated in the same NetLMM domain. The specific invalid addresses/prefixes MUST be specified in Address Options. 66: Invalid Prefix Used by the LMA when an Location Registration contains an IP address or prefix that is invalid in the same NetLMM domain. The specific invalid addresses/prefixes MUST be specified in Address Options. Levkowetz, et al. Expires March 22, 2007 [Page 22] Internet-Draft The NetLMM Protocol September 2006 67: Over IP Address Limit Used by the LMA on receipt of a Location Registration message, if the maximum number of IP addresses or prefixes allowed for a MN has been exceeded. The specific addresses/prefixes which were disallowed MUST be specified in Address Options. 68: Invalid Tunnelling Method The proposed tunnel method is not supported or unavailable. 69: Already Associated The LMA already had the requesting MAG listed as associated. 126: Vendor-Specific Status (LMA-specific) For use with vendor-specific messages. Additional status detail may be provided for instance in vendor-specific options. 127: Experimental Status (LMA-specific) For use during experimental implementation of new protocol features, according to RFC 3692. 190: Vendor-Specific Status (MAG-Specific) For use with vendor-specific messages. Additional status detail may be provided for instance in vendor-specific options. 191: Experimental Status (MAG-specific) For use during experimental implementation of new protocol features, according to RFC 3692. 6. Option Format and Option Types 6.1. Option Format NetLMM defines a general extension mechanism using options to allow optional information to be carried in the control messages. The options are encoded in a Type-Length-Value format, and are described in detail in the following. The options carry additional information used for processing the message. Up-to-date values for the option types are maintained in the online IANA registry of assigned numbers. Format: Levkowetz, et al. Expires March 22, 2007 [Page 23] Internet-Draft The NetLMM Protocol September 2006 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type |Option Sub-Type| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option-specific data | . (up to option length) . . . . . . . . . Option Type This field identifies the particular type of option serving a specified function. The Type field in the NetLMM option is split into two ranges: Type values of 0 through 127 (inclusive) for not skippable options and 128 through 255 (inclusive) for skippable options. The recipient of a message with an unrecognized non-skippable option MUST silently discard the message. Otherwise, if no unrecognized non- skippable options are found, the message MUST be processed with any unrecognized skippable option bypassed (i.e. move to next option using the Length field of the unrecognized option) during processing by the receiver. Option Sub-Type This field indicates the sub-type of the option, and provides for up to 256 related Option Sub-Types with the same Option Type field. Length The value represents the length of the "Data" portion of the option, in unit of octets. 6.2. Option Alignment Options are always aligned to start on an 8-octet aligned boundary, relative to the start of the message header. The first 4 octets of an option has a fixed format, giving the Option type, sub-type, and length in octets. When assembling a message, for an option which has a length in octets which is not a multiple of 8, zero octets are added after the option up to the next 8-octet-aligned boundary. The option length is not adjusted to include the padding. When parsing the options of a message, any octets between the end of one option and the next 8-octet-aligned boundary are discarded. In other words, if we include the padding in the figure showing Levkowetz, et al. Expires March 22, 2007 [Page 24] Internet-Draft The NetLMM Protocol September 2006 option field layout, we get the following for an option of total length N*8+3. (Total length N*8+3 implies that the Length field has the value (N*8+3)-4, as the length field indicates the length of the option data, i.e., does not include the first 4 octets): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type |Option Sub-Type| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option-specific data | . (up to option length) . . . . +-+-+-+-+-+-+-+-+ | | Padding... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6.3. ID Option The ID option carries various types of identifiers. All messages related to a specific MN must include an ID option providing the MN ID. Multiple ID options can be included in an message. 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]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type |Option Sub-Type| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ID-Type | Identifier... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | . . . . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Levkowetz, et al. Expires March 22, 2007 [Page 25] Internet-Draft The NetLMM Protocol September 2006 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 1: LMA ID 2: MAG ID Length The length of the option in octets, excluding the Type, Sub-Type and Length fields. ID-Type This field indicates the type of ID carried in the remainder of the option. *** Note: Check whether there already exists an applicable IANA registry for ID types which we could use here *** 0: 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. 6.4. Prefix Option This option defines the address or prefix which has been allocated or delegated to a mobile node. If the address prefix length is the same as the full address length, it describes a single address, otherwise it describes a prefix delegated to the MN. The NetLMM address can be both IPv4 and IPv6. Levkowetz, et al. Expires March 22, 2007 [Page 26] Internet-Draft The NetLMM Protocol September 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subnet Prefix | Address Prefix| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Address (IPv6 case) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type 1 Option Sub-Type 0: Indicates that the data in the Address field is an IPv6 address or address range. If the Address Prefix Length is 128 this is an address, otherwise it is an address range with span determined by the given prefix length. 1: Indicates that the data in the Address field is an IPv4 address. Length The length of the option in octets, excluding the Type, Sub-Type and Length fields. Subnet Prefix The number of leadings bits in the Address that are valid as a subnet prefix. Address Prefix Variable. The value indicates the prefix length of the prefix or address delegated or allocated to the mobile node. If the prefix length is equal to the full address length, the option describes an address allocation, otherwise it describes a prefix delegation. 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. Levkowetz, et al. Expires March 22, 2007 [Page 27] Internet-Draft The NetLMM Protocol September 2006 Address: If the Option Sub-Type is 0, the value is an IPv6 address, while if the type is 1, the value is an IPv4 address. 6.5. Data Transport Option This option contains data transport methods capabilities that the MAG or LMA has. This option is used by Association Request message and Acknowledgement to negotiate the data transport method between MAG and LMA. Multiple methods can be contained in the field with the order of preference. The mandatory transport method is IPv6-in-IPv6 [RFC2473], which must be listed. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type |Option Sub-Type| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Transport Method 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data Transport Method n | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type 2 Option Sub-Type 0 Length The length of the option in octets, excluding the Type, Sub-Type and Length fields. The number of Data Transport Method fields is equal to the Length divided by the size, in octets, of the Data Transport Method field. Data Transport Method Indicates the data transport methods available at the sender in the case of the Association Request message. The methods are listed in order of preference. In the case of the Association Request Acknowledgement, only one method would be listed, indicating the chosen data transport method. Levkowetz, et al. Expires March 22, 2007 [Page 28] Internet-Draft The NetLMM Protocol September 2006 The following values are defined for the data transport method field by this memo: 0: IPv6-in-IPv6 1: GRE 2: IPv4-in-IPv6 6.6. Deregistration Timeout Option This option indicates the length, in milliseconds, to keep the forwarding state of a given MN active after a handover. When used, this option is included in the Location Deregistration message and its acknowledgement. The timeout time in the Location Deregistration Ack is copied from that given in the Timeout Option of the Location Deregistration. If the MAG can not keep the MN state alive as long as the LMA has requested for some reason, the MAG can indicate the preferred timeout time and return an error code instead of copying the original value. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type |Option Sub-Type| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timeout Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type 3 Option Sub-Type 0 Length 4. The length of the option in octets, excluding the Type, Sub- Type and Length fields. Timeout Time Indicates the preferred delay before deleting the MN forwarding state from the previous MAG during handover. The value is in milliseconds. Levkowetz, et al. Expires March 22, 2007 [Page 29] Internet-Draft The NetLMM Protocol September 2006 6.7. Timestamp Option This option contains the timestamp value in the format of an NTP timestamp (RFC 4330, Section 3 [RFC4330]), and records the time when the message is sent. This option can be used to detect an overtaking message in a race condition by comparing the timestamp values of messages. Especially during handovers, if the network suffers from a sudden propagation delay for some reason or the MN moves rapidly between MAGs, the timestamp may be used to facilitate in-order messages processing regardless of message arrival order. The use of this option is network administrator dependent, and needs a reliable time distribution method, such as NTP or GPS time synchronization, with sufficient accuracy to support fast moving MNs. LMA and MAG nodes SHOULD support and MAY use message timestamps. To resolve race conditions, in particular during handover, and for message synchronization beyond the scope of a particular MAG, the timestamp option may be attached to the following messages: * Location Registration * Location Deregistration Acknowledgements of these messages should not carry a timestamp option. Heartbeat messages and acknowledgements may optionally contain a timestamp option for informational or diagnostic purposes. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type |Option Sub-Type| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type 4 Option Sub-Type 0 Levkowetz, et al. Expires March 22, 2007 [Page 30] Internet-Draft The NetLMM Protocol September 2006 Length 8. The length of the option in octets, excluding the Type, Sub- Type and Length fields. Timestamp A timestamp in the 64 bit format defined for NTP timestamps [RFC4330]. 6.8. Vendor-Specific Option This option can be used by any vendor or organization that has an IANA-allocated SMI Network Management Private Enterprise Code. Details of the meaning of value field is entirely up to the defining vendor or organization. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type |Option Sub-Type| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor/Org-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Value . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type 5 Option Sub-Type 0. This field may not be assigned any value different from zero by the organizations using the option; only the Value field may be freely used. Length The length of the option in octets, excluding the Type, Sub-Type and Length fields. Vendor/Org-ID The high-order octet is 0 and the low-order 3 octets are the SMI Network Management Private Enterprise Number [RFC2578], [ENTERPRISE-NUM], of the Vendor in network byte order. Levkowetz, et al. Expires March 22, 2007 [Page 31] Internet-Draft The NetLMM Protocol September 2006 Value Variable. Details defined by individual Vendors / Organizations. 6.9. Registration Lifetime Option This option MAY be used to indicate a limited lifetime for the state created as a result of Location Registration (Section 5.3) messages. If no Registration Lifetime Option is used, the lifetime of the state is to be taken as "Infinite", but with the reservation that in cases where a node experiences an impending lack of resources, the Least Recently Used (LRU) states may be removed (garbage collected), to recover resources for continued operation. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type |Option Sub-Type| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type 6 Option Sub-Type 0 Length 4. The length of the option in octets, excluding the Type, Sub- Type and Length fields. Lifetime The lifetime in seconds, with a value between 1 and 2^32 - 2. The values 0 and 2^32 - 1 are reserved, and may not be used. 6.10. Status Option This option MUST be used in Acknowledgements to indicate the status result of the acknowledged message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type |Option Sub-Type| Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Levkowetz, et al. Expires March 22, 2007 [Page 32] Internet-Draft The NetLMM Protocol September 2006 Option Type 7 Option Sub-Type 0 Length 8. The length of the option in octets, excluding the Type, Sub- Type and Length fields. Status An 8-bit number, which indicates the Status result of handling the acknowledged message. Individual status codes are defined in Section 5.9. Reserved 24-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. 7. Protocol Specification 7.1. Mobile Access Gateway Operation 7.1.1. Conceptual Data Structures Each MAG MUST maintain a NetLMM Routing Cache and an LMA List. Each MAG Routing Cache entry conceptually contains the following fields for each attached MN: * The MN ID of the attached MN. This identifier is acquired during the attach procedure and is used from the MAG to identify the attached MN in the Location Registration message, which is sent to the selected LMA. * One or more global IP addresses or address prefixes of an attached MN. Each IP address or prefix is acquired from an LMA through the Location Registration Acknowledgement or by means of local operation. According to the context of the received message or local indication, an IP address is set up, updated or removed from the Routing Cache. * The LMA ID of the LMA serving an attached MN. The serving LMA and its LMA ID is acquired from the LMA selection policy, which is out of scope of this specification. Levkowetz, et al. Expires March 22, 2007 [Page 33] Internet-Draft The NetLMM Protocol September 2006 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 also indicates the forwarding approach which has been selected for an association between the MAG and a particular LMA. During the association procedure, an LMA selects a forwarding approach from the MAG's full set of forwarding capabilities. For this the MAG appends a Data Transport option, which indicates its supported forwarding capabilities in decreasing order of preference, to the Association message. The Data Transport option received back from the LMA in the resulting Association Acknowledgement indicates a single, selected forwarding approach in one Data Transport Method field. The LMA List conceptually contains the following fields for each LMA entry: * The LMA ID of the LMA. * One or more IP address(es) of the LMA. The LMA's IP address information is acquired through the LMA selection policy, which is out of scope of this specification. Availability of multiple LMA IP addresses could support operation of multi-homed LMAs. Details about how to handle multiple LMA IP addresses is out of scope of this specification. * The selected forwarding approach for the association with an LMA. This field is needed in case a single forwarding approach is set up for the association with an LMA. Each MAG MAY maintain a list of available LMAs. Such a list can support the LMA selection procedure and the MAG's association procedure. The list of available LMAs comprises conceptually the following fields for each LMA: * The LMA 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. Levkowetz, et al. Expires March 22, 2007 [Page 34] Internet-Draft The NetLMM Protocol September 2006 7.1.2. Processing NetLMM Headers * The Type field MUST have a known value (Section 5.1). Otherwise, the receiving node MUST discard the message and respond with an Error message with Status field set to "Invalid Message" ). 7.1.3. Processing NetLMM Messages 7.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 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 Acknowledgement from the peer LMA with status 1, "Success". In this case, the MAG MUST create an entry in its LMA List (or update the tentative entry created earlier), with the messages sent by the LMA in the acknowledgement. The MAG MUST also update the forwarding method to the one indicated in the acknowledgement. Levkowetz, et al. Expires March 22, 2007 [Page 35] Internet-Draft The NetLMM Protocol September 2006 7.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 between MAG and LMA. The event that triggers this message is out of the scope of this specification; for example, the MAG may send a Disassociation Request to all the LMAs present in its LMA List just before shutting down. In case the Disassociate Procedure is initiated by the MAG, the MAG MUST include an ID Option with the its identity in the Disassociation Request. When sending the Disassociation Request, the MAG MAY set the LMA entry related to the specific LMA as tentative. When it receives an acknowledgement with status 1, "Success", the MAG MUST delete the correspondent entry in its LMA List. In case the Disassociate Procedure is initiated by the LMA, when the MAG receives a Disassociation Request message, it MUST validate it. If it is correct, it MUST delete the related entry in its LMA List and send an acknowledgement with status 1, "Success". As in all NetLMM messages, the MAG MUST include the ID option with its identity. 7.1.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 event 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 an Location Registration Acknowledgement message from the LMA with Status 1, "Success". This message also includes a NetLMM Network Prefix that the MAG MUST use for any mechanism it provides for MN address allocation, e.g., when building a Router Advertisement Levkowetz, et al. Expires March 22, 2007 [Page 36] Internet-Draft The NetLMM Protocol September 2006 if IPv6 stateless address configuration is used. (See [I-D.ietf- netlmm-mn-ar-if] for a more detailed description of this case). 7.1.3.4. MAG to MAG handover procedure When a MN hands over from one MAG to another, the new MAG may not know if the event occurred is a handover or a network attach. This is because the base protocol specified in this document is agnostic with respect to any MAG to MAG communication that may be in place. Due to this reason, as for network attach, the MAG will just receive a trigger that a new MN has attached to the link; this trigger, referred to as a MN_Access_Network API event carries the MN ID and the LMA ID. As mentioned above, this API event can be for example based on an AAA exchange. After receiving this API event, the MAG performs the same procedure as described for network access (see section Section 7.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 and receives the Acknowledgement of the Location Registration message, which includes the NetLMM prefix to be used by the MN. 7.1.3.5. Resource Revocation If the MAG receives a Location Deregistration message from the LMA, it MUST delete the entry related to the MN specified in the MN ID Option in its Routing Cache. Moreover, the MAG MUST remove any forwarding state for the MN. After doing that, the MAG MUST send an acknowledgement of the Location Deregistration message to the LMA with Status 1, "Success". In case the Location Deregistration contains a Deregistration Timeout option, the MAG MAY keep forwarding uplink packets to the LMA for the MN. This may be useful in case of make before break link layer technologies. The adopted timeout cannot be greater than the one suggested by the LMA and MUST be sent back to the LMA in the Location Deregistration message Acknowledgement. 7.1.3.6. 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 registration, this is a MUST, otherwise it can be a SHOULD) send a Location Deregistration message with an ID option containing the MN ID. After receiving the Acknowledgement of the Location Deregistration message, the MAG MUST remove any mobility and forwarding state in its Routing Cache related to that MN. Levkowetz, et al. Expires March 22, 2007 [Page 37] Internet-Draft The NetLMM Protocol September 2006 7.2. Local Mobility Anchor Operation 7.2.1. Conceptual Data Structures Each LMA MUST maintain a NetLMM Routing Cache and a MAG List. Each LMA Routing Cache entry conceptually contains the following fields for each MN: * The MN ID of the registered MN. This Identifier is acquired through the Location Registration message, which registers an attached MN. Optionally, the MN ID is acquired though the LMA Allocation message beforehand, which could enable service authorization for this particular MN ID at the LMA. * The MAG ID of the registered MN's serving MAG. This identifier is acquired through the Location Registration message, which registers an attached MN. Dependent on the context of this message, the MAG ID entry is either initialized, or updated in case of a 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 or address prefixes of a registered MN. Each IP address or prefix is allocated by the LMA or on request of the LMA. The MAG is informed about the allocated address or prefix in the Location Registration Ack message. Each LMA MUST maintain a MAG List, which refers to associated MAG entities. The list of associated MAGs is used to perform heartbeat tests and to map the Routing Cache's MAG ID entries to the associated MAG's IP address(es). The MAG List also supports the procedure of bulk de-registrations towards all or a subset of associated MAGs. The MAG List also indicates the forwarding approach which has been selected for the association between the LMA and a particular MAG. During the association procedure, an LMA selects a forwarding approach from the MAG's full set of forwarding capabilities. The LMA receives a MAG's full set of forwarding capabilities in decreasing order of preferences in a Data Transport option with the Association message. The LMA could selects the first forwarding approach which suits the LMA's forwarding capabilities, starting with the MAG's most preferable forwarding approach as indicated in the first Data Transport Method field of the Data Transport option. Other selection schemes are allowed and optional. The LMA indicates the selected forwarding approach back to the MAG in the Association Acknowledgement, which carries a Data Transport option with a single Data Transport Method field. Levkowetz, et al. Expires March 22, 2007 [Page 38] Internet-Draft The NetLMM Protocol September 2006 The MAG List conceptually contains the following fields for each associated MAG: * The MAG ID of the associated MAG. * One or more IP address(es) of the associated MAG. The MAG's IP address information is acquired through the Associate message. * The forwarding capabilities of the associated MAG. This capability list is acquired from a particular MAG through the Associate message. From the list of supported forwarding approaches, the LMA enters only the approaches to the capabilities which are supported by the LMA. * The forwarding setting for the associated MAG. This field is needed in case the LMA configures a single forwarding approach per MAG association. 7.2.2. Processing NetLMM Headers All NetLMM local mobility anchors MUST observe the rules described in Section 7.1.2 when processing NetLMM Headers. 7.2.3. Processing NetLMM Messages 7.2.3.1. Association Procedure When a LMA receives an Association Request message, it MUST look up in its MAG list 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 acknowledgement to the MAG with status "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. We should 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 methods proposed by the MAG or MAY indicate a specific method in the Acknowledgement. After creating the entry, the LMA MUST send an acknowledgement with STATUS value 1 ("Success") with the content described below. The Acknowledgement to the received Association Request message MUST Levkowetz, et al. Expires March 22, 2007 [Page 39] Internet-Draft The NetLMM Protocol September 2006 include: * the LMA ID included in a NetLMM ID option. This identifier is used by the peer to identify the LMA and is included in all subsequent messages. * the MAG ID as received from the requesting MAG in the Association Request message. * the Data Transport option with the selected data transport method. The LMA MUST select one forwarding approach from the list of capabilities as received in the Association Request message. * the Status option, indicating the result of processing the Association Request message. 7.2.3.2. Disassociation Procedure In case the Disassociate procedure is initiated by the MAG, the LMA MUST validate any Disassociation Request message it receives. If it is correct, it MUST delete the related entry in its MAG List and send an Acknowledgement 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 an acknowledgement with status 1, "Success", the LMA MUST delete the correspondent entry in its MAG List. 7.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 7.2.3.4. 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. After creating the entry, it MUST send an acknowledgement of the Location Registration message, with status 1, "Success", including three ID options (MN ID, LMA ID, MAG ID) and the NetLMM prefix in a NetLMM Address option. The NetLMM prefix MUST be used by the MAG for Levkowetz, et al. Expires March 22, 2007 [Page 40] Internet-Draft The NetLMM Protocol September 2006 any mechanism it provides for MN address allocation, e.g., when building a Router Advertisement if IPv6 stateless address configuration is used. (See [I-D.ietf-netlmm-mn-ar-if] for a more detailed description of this case). In case the Location Registration is not valid or the registration procedure cannot be completed successfully, the LMA MUST send a Acknowledgement with an appropriate Status value. 7.2.3.4. 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 7.2.3.3). If an entry is already present in the Routing Cache, a handover has occurred. In either case, the LMA MUST send back an Acknowledgement of the Location Registration message with Status value set to 1, "Success", including a Prefix option which specifies the NetLMM prefix to be sent to the MN. 7.2.3.5. Resource Revocation There are cases (e.g., due to administrative reasons) where the forwarding state of a specific MN must be purged so that the MN is no more able to use the resources provided by the network. In this case, based on a trigger received from the network (e.g. AAA), the LMA MUST send a Location Deregistration message to the peer MAG, including the MN ID, the LMA ID and the MAG ID. Optionally, the LMA MAY include a Deregistration Timeout option specifying the remaining time to keep the state of the MN in the MAG. The revocation procedure terminates when the LMA receives an Acknowledgement of the Resource Revocation message with status 1, "Success". 7.2.3.6. 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 an Acknowledgement of the Location Deregistration message with status 1, "Success", including the MN ID, the MAG ID and the LMA ID. 8. Data Transport Levkowetz, et al. Expires March 22, 2007 [Page 41] Internet-Draft The NetLMM Protocol September 2006 As soon as a particular MAG has associated with an LMA and an attached MN has been registered with the LMA, the LMA node and the MAG node are responsible for forwarding the MN's data traffic correctly within the NetLMM domain. Associated location and forwarding information is maintained within the LMA's and the MAG's Routing Cache. Different forwarding mechanisms between the LMA node and a particular MAG node might be supported and set up during the MAG's association procedure. Network entities which have Version 1 of the NetLMM protocol implemented, MUST support IPv6-in-IPv6 encapsulation [RFC2473] to tunnel data packets between an LMA node and an associated MAG node. Support of other forwarding approaches are for future extensions. 8.1. Forwarding of Unicast Data Packets 8.1.1. Handling of hop limit field in IPv6 data packets According to the NetLMM default mechanism for forwarding data packets between a particular LMA and a MAG by means of encapsulation, LMA nodes and MAG nodes serve as tunnel entry-points and tunnel exit- points respectively. LMAs and MAGs have to decrement the hop limit field of the encapsulated IPv6 header properly. The MAG serves as the default gateway for an attached MN and forwards all packets from the MN into the tunnel, which in turn encapsulates the packet towards the LMA. The LMA on receiving the packet from the MAG decapsulates and forwards the packet using normal forwarding procedures. The packets destined towards the MN are forwarded in a similar fashion. The procedure of forwarding the packet decrements the hop limit. Hence, the hop limit will get decremented twice for any packet traversing the tunnel between LMA and MAG, once at the LMA and once at the MAG. 8.1.2. IPv6-in-IPv6 tunnel LMA and MAG nodes MUST support IPv6-in-IPv6 encapsulation according to RFC 2473 [RFC2473] for forwarding packets within the NetLMM domain. Support of other forwarding schemes is optional. When an LMA node receives an IPv6 packet destined for a registered MN and IPv6-in-IPv6 tunneling has been selected as forwarding approach, it 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 Levkowetz, et al. Expires March 22, 2007 [Page 42] Internet-Draft The NetLMM Protocol September 2006 node forwards the data packet towards the MN after decapsulation. To forward uplink packets, the MAG node serves as tunnel entry-point and decrements the data packet's hop limit field by one before it encapsulates the packet in the tunnel IPv6 header. The tunnel IPv6 header might carry one or more extension headers. The MAG node forwards the tunnel packet to the LMA node, using its own address as source address and the LMA node's address as destination address in the outer IPv6 header. The LMA node terminates the tunnel and MUST process relevant Extension Headers, which might follow the encapsulating IPv6 header. The LMA node forwards the data packet towards its final destination after decapsulation. 8.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 [RFC2473] 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. 8.2. Forwarding of Multicast Data Packets 8.2.1. Link Local Multicast The scope of link local multicast packets is confined to the link between MNs and the associated MAG node. 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. (See [I-D.ietf-netlmm-mn-ar-if]). 8.2.2. IP Multicast The following options have been identified to support IP multicast within a NetLMM domain. Native mode: This option implies that MAG nodes are multicast- enabled routers and support for IP multicast is orthogonal to the NetLMM protocol operation. According to native multicast support, access routers terminate a multicast tree and the LMA node does not play any multicast-specific role in forwarding of IP multicast traffic. Levkowetz, et al. Expires March 22, 2007 [Page 43] Internet-Draft The NetLMM Protocol September 2006 Tunnel mode: This option implies that MAG nodes and LMA nodes are both multicast-enabled routers and the IP multicast traffic is tunnelled via the two NetLMM nodes. IP Multicast protocol is used on the tunnel between the MAG nodes and LMA nodes to set up the multicast forwarding path. MAG nodes must coordinate multicast listeners according to IGMP operation [RFC3376] and communicate with other multicast-enabled routers using IP Multicast protocol (e.g. PIM, based on RFC 2362). The MAG nodes send multicast control messages in the tunnel or on the connected interface to reach the LMA nodes or other routers, respectively. This establishes the multicast forwarding path for directing multicast packets to the listeners. An example of a IP multicast join procedure is illustrated in Figure 5. By default, the native mode of operation is REQUIRED. +--+ +---+ +---+ +--+ |MN| |MAG| |LMA| |MR| +--+ +---+ +---+ +--+ | | | | | | | | |-IGMP Report->| | | | |====PIM Join===>| | | | |----PIM Join----.>| / / / / / / / / |<-------------|<===============|<-----------------|<--MC Data | | | | Figure 5: Example of IP multicast join procedure for the Tunnel Mode. The MR is a multicast-enabled router between the multicast source and the LMA node. The mobile node may be a multicast sender. The MAG nodes allow multicast packets to be received on the interface of the mobile node by successfully passing any Reverse Path Forwarding (RPF) check. All multicast packets that are sourced from the mobile node are tunneled to the LMA nodes. The RPF check on the LMA nodes should allow these packets to be received on the tunnel as well. The multicast packets are forwarded by the LMA nodes based on the multicast forwarding table, set up by IP Multicast protocol used among the routers. An example of a IP multicast source sending multicast packet to the group is illustrated in Figure 6. Levkowetz, et al. Expires March 22, 2007 [Page 44] Internet-Draft The NetLMM Protocol September 2006 +--+ +---+ +---+ +--+ |MN| |MAG| |LMA| |MR| +--+ +---+ +---+ +--+ | | | | | | |<----PIM Join-----| / / / / / / / / | | | forward to group | |-- MC Data--.>|===============>|----------------.>|--.> | | | | Figure 6: Example of a mobile node sourcing multicast packets to the group. 8.3. Forwarding of Broadcast Data Packets Version 1 of the NetLMM protocol specification does not consider forwarding of broadcast data packets. 9. Protocol Constants and Configuration Variables 10. Security Considerations The NetLMM protocol 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 a MAG and associate with an LMA. This in itself may not create any harm if subsequent messages are authenticated. But it does allow 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 a MAG and send a location registration message to an 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 traffic. This attack may be detected by MAG-1 when it receives the Location Deregistration message from LMA while the MN is still attached. The detection of the attack depends on the Levkowetz, et al. Expires March 22, 2007 [Page 45] Internet-Draft The NetLMM Protocol September 2006 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, if an MN Address Setup messages are used and one 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, which 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. If this is done, any messages exchanged between the MAG and LMA can only come from within the network. This level of security may be sufficient for some deployments, precluding the need for protecting the signalling messages. In such cases, IPsec may not need to be used to protect the signalling messages. Anomalous events should be logged. [TBD: Add examples 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]. 11. IANA Considerations 12. Contributors This contribution is a joint effort of the NetLMM design team of the Levkowetz, et al. Expires March 22, 2007 [Page 46] Internet-Draft The NetLMM Protocol September 2006 NetLMM WG. The members include Kent Leung, Gerardo Giaretta, Phil Roberts, Marco Liebsch, Katsutoshi Nishida, Hidetoshi Yokota, Henrik Levkowetz, and Mohan Parthasarathy. 13. Acknowledgments 14. References 14.1. Normative References [I-D.ietf-ipv6-2461bis] Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", draft-ietf-ipv6-2461bis-08 (work in progress), September 2006. [I-D.ietf-netlmm-mn-ar-if] Laganier, J., "Network-based Localized Mobility Management Interface between Mobile Node and Access Router", draft-ietf-netlmm-mn-ar-if-01 (work in progress), June 2006. [I-D.ietf-netlmm-nohost-ps] Kempf, J., "Problem Statement for Network-based Localized Mobility Management", draft-ietf-netlmm-nohost-ps-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-04 (work in progress), August 2006. [I-D.ietf-netlmm-threats] Kempf, J. and C. Vogt, "Security Threats to Network-Based Localized Mobility Management", draft-ietf-netlmm-threats-04 (work in progress), September 2006. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. Levkowetz, et al. Expires March 22, 2007 [Page 47] Internet-Draft The NetLMM Protocol September 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. 14.2. Informative References [ENTERPRISE-NUM] IANA, "IANA Enterprise Numbers Registry"", 2006. [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004. Appendix A. TODO (Things that remain to be specified...) Levkowetz, et al. Expires March 22, 2007 [Page 48] Internet-Draft The NetLMM Protocol September 2006 A.1. Montreal DT Meeting Todo List a. ***Done*** Describe the re-send mechanism for control messages, in order to provide reliable delivery. ==> Marco look at SCTP and DCCP b. ***Later*** Add an "LMA Announce message" which can be multicast from a newly connected LMA to trigger listening MAGs to send it Association Requests. ==> Not included in base spec. c. Add the capability to do bulk MN de-registrations and possibly registrations. ==> Henrik write up per-LMA ID, per-MAG ID de-registration sub- type. Also query Ericsson internally about exact needs. ==> Also add text to each message indicating whether it can be used with multiple entities (often MN IDs) d. 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. ==> Phil will review for prefix e. ***Done*** Add reserved status ranges (Section 7.1.1) for vendor- specific status, LMA status?, MAG status?. ==> Single number for vendor-specific status, ranges for LMA and MAG status codes -- Henrik f. ***Done*** Add experimental message, option and status values, in accordance with RFC 4064. ==> Henrik g. ***Skip*** Add a Heartbeat Sequence Number Option, to hold heartbeat-specific sequence numbers needed by algorithms for reacting to missed heartbeats. Write up suggested algorithm. ==> Henrik. h. Make sure the use of the identity / locator split paradigm is consistent and workable throughout the document. Cover resolution of ID to locator. ==> [Later?] Henrik write up a proposal. Gerardo writes up a proposal. i. ***Done*** 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 Acknowledgement. ==> The MAG sends a prioritized list of capabilities, the LMA Levkowetz, et al. Expires March 22, 2007 [Page 49] Internet-Draft The NetLMM Protocol September 2006 chooses one and sends that one back. -- Marco j. ***Done*** Add message and signalling optimization according to Section 5.12. ==> Wait with this till we have a clear defined functionality. k. ***Leave*** Maybe change the range-based skippable or non- skippable nature of Options to be indicated by a bit instead? ==> Leave as-is. l. ***Done*** Point out somewhere that although a NetLMM Domain may have multiple LMAs, an MN is always served by the same LMA once an LMA has been assigned. ==> Phil adds text update. A.2. Montreal DT Meeting issues list Additional issues brought up and discussed during the Montreal DT meeting: a. ***Settled*** One prefix per MN, or common prefix? ==> DT leaning towards per-MN prefix. b. Given a MN with multiple interfaces, what is the relationship between MN ID and prefix? One prefix per MN ID, or multiple prefixes, one per interface? ==> With multiple simultaneous interfaces the interfaces should have individual prefixes c. Add options to transfer multicast state from MAG to LMA (when a MN joins a multicast group) and from the LMA to the MAG (when a MN moves to a new MAG and the MAG needs the multicast group membership)? ==> Not in base - in base, query the MN for the multicast group membership) d. ***Later*** Handle multiple MAGs on the same link ==> [Ignore the issue for now?] e. Should we reserve the zero type and sub-type values, generally? ==> Henrik's proposal: No f. Do we have magic which lets us send the LMA allocate message at the right time? ==> Maybe not? The charging system may know - can/should we get that information down? Levkowetz, et al. Expires March 22, 2007 [Page 50] Internet-Draft The NetLMM Protocol September 2006 g. We need one or more applicability descriptions which show how to resolve all Magic and shows how the base protocol should interface with surrounding protocols. ==> Write an applicability description for 802.11, resolving all the Magic ==> Go through the document and mark all Magic so we can see what needs to be resolved. h. ***Done*** What about GRE, MPLS and Routing Tag? ==> Drop from from text and appendices. i. ***Done*** Get the correct RFC to reference for IPv6 in IPv6 tunnelling ==> Kent looks this up. j. ***Fixed*** Appendix D text ==> Already covered in 9.1.1. k. Replace all the individual Ack messages with a single Ack message? ==> ***Done*** Change the names to consistently use 'Ack' for the return message -- Henrik l. We're not sure about the details of using the timestamp - should specify which messages contain a timestamp, and whether the conceptual data structure should contain the timestamp of the last message received ==> Marco verifies that it is clearly indicated which messages MUST contain the timestamp option. ==> We need to describe when and how the timestamp option is to be used. m. From Kevin Grace 24 Jun 2006, email item G) Proper MAG/LMA behavior for reacting to a Disassociation Acknowledgement message containing an error code is unspecified; is there a recommended reaction? More generally, should the handling of different error codes each acknowledgement be documented? Appendix B. 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 Levkowetz, et al. Expires March 22, 2007 [Page 51] Internet-Draft The NetLMM Protocol September 2006 * - 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 C. Issues with omitting the MN Address Setup and Routing Setup The design team currently considers optimization of the handover related signaling. This focuses in particular on reducing the handover signaling from two handshakes to one handshake between the nMAG and the LMA. The 00 version of the draft specifies different messages to notify the arrival of an MN to the LMA by means of indicating the MNID (Location Registration) and to setup routing states by means of indicating the MN's IP address information (MN Address Setup and Routing Setup). In most handover cases, explicit signaling of the MN's IP address by means of the MN Address Setup and Routing Setup is not required in case the Location Registration Req/Ack could append IP Address options. This brings up the question whether or not NetLMM operation needs the MN Address Setup message at all. The MN Address Setup has been specified in particular to notify an MN's IP address from a MAG to the LMA, which includes adding new IP addresses to an existing state at the LMA. Referring to the agreed per-MN Prefix addressing model for NetLMM, the LMA and MAG could take routing decisions solely based on the MN's prefix. Since delegation of the MN's prefix is performed through the LMA, which notifies the MN through the MAG about the assigned prefix, the LMA is aware of the MN's (delegated) prefix after having sent the Location Registration Acknowledgement. Sending the MN's full IP address back to the LMA by means of the MN Address Setup message is required only if the LMA takes routing decisions on the full IP address. Other reasons might exist. As taking routing decisions on the LMA based on the full IP address is only mandatory for the shared prefix addressing model, which is not supported in the base NetLMM protocol, the design team considers omitting the MN Address Setup message. However, explicit notification of the MN's full IP address could still be done by means of appending the NetLMM Address option to an existing message, such as the Location Registration message. Such an approach conceptually Levkowetz, et al. Expires March 22, 2007 [Page 52] Internet-Draft The NetLMM Protocol September 2006 overloads the Location Registration message and eliminates the conceptual split between messages handling IDs and routing information. The design team should take a decision from the following approaches: 1. Keep MN Address Setup and Routing Setup messages and specify an approach to piggyback these messages with a Location Registration Req/Ack. 2. Keep MN Address Setup and Routing Setup messages to be flexible for specific scenarios, such as notification of the full MN IP address to the LMA, but allow overloading the Location Registration (append NetLMM Address options). 3. Omit the MN Address Setup message and allow overload the Location Registration message (append NetLMM Address options). 4. Other alternatives. Appendix D. Out of scope * Inter-MAP handover * Fast handover * Hierarchical MAP Levkowetz, et al. Expires March 22, 2007 [Page 53] Internet-Draft The NetLMM Protocol September 2006 Authors' Addresses Henrik Levkowetz (editor) Ericsson Torsgatan 71 Stockholm S-113 37 SWEDEN Phone: +46 708 32 16 08 Email: henrik@levkowetz.com Gerardo Giaretta Telecom Italia via Reiss Romoli 274 Torino 10148 Italy Phone: +39 011 228 6904 Email: gerardo.giaretta@telecomitalia.it Kent Leung Cisco 170 W. Tasman Drive San Jose, CA 95134 USA Phone: +1 408 853 9580 Email: kleung@cisco.com Marco Liebsch NEC Network Laboratories Kurfuersten-Anlage 36 Heidelberg, 69115 Germany Phone: +49 6221-90511-46 Email: marco.liebsch@netlab.nec.de Levkowetz, et al. Expires March 22, 2007 [Page 54] Internet-Draft The NetLMM Protocol September 2006 Phil Roberts Motorola 1301 E Algonquin Rd Schaumberg, IL 60196 USA Email: phil.roberts@motorola.com Katsutoshi Nishida NTT DoCoMo Inc. 3-5 Hikarino-oka, Yokosuka-shi Kanagawa, Japan Phone: +81 46 840 3545 Email: nishidak@nttdocomo.co.jp Hidetoshi Yokota KDDI R&D Laboratories, Inc. 2-1-15 Ohara, Fujimino Saitama, 356-8502 Japan Phone: +81 49 278 7894 Email: yokota@kddilabs.jp Mohan Parthasarathy Nokia Email: mohan.parthasarathy@nokia.com Levkowetz, et al. Expires March 22, 2007 [Page 55] Internet-Draft The NetLMM Protocol September 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Levkowetz, et al. Expires March 22, 2007 [Page 56]