idnits 2.17.1 draft-giaretta-netlmm-dt-protocol-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 28. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2187. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2164. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2171. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2177. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 19, 2006) is 6518 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-ietf-ipv6-2461bis-07 == Outdated reference: A later version (-05) exists of draft-ietf-netlmm-nohost-ps-04 ** Downref: Normative reference to an Informational draft: draft-ietf-netlmm-nohost-ps (ref. 'I-D.ietf-netlmm-nohost-ps') == Outdated reference: A later version (-05) exists of draft-ietf-netlmm-nohost-req-01 ** Downref: Normative reference to an Informational draft: draft-ietf-netlmm-nohost-req (ref. 'I-D.ietf-netlmm-nohost-req') == Outdated reference: A later version (-04) exists of draft-ietf-netlmm-threats-00 ** Downref: Normative reference to an Informational draft: draft-ietf-netlmm-threats (ref. 'I-D.ietf-netlmm-threats') ** Obsolete normative reference: RFC 2362 (Obsoleted by RFC 4601, RFC 5059) ** Downref: Normative reference to an Informational RFC: RFC 3753 ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) ** Obsolete normative reference: RFC 4330 (Obsoleted by RFC 5905) Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETLMM G. Giaretta 3 Internet-Draft Telecom Italia 4 Expires: December 21, 2006 K. Leung 5 Cisco 6 M. Liebsch 7 NEC 8 P. Roberts 9 Motorola 10 K. Nishida 11 NTT DoCoMo Inc. 12 H. Yokota 13 KDDI Labs 14 M. Parthasarathy 15 Nokia 16 H. Levkowetz 17 Ericsson 18 June 19, 2006 20 NetLMM Protocol 21 draft-giaretta-netlmm-dt-protocol-00.txt 23 Status of this Memo 25 By submitting this Internet-Draft, each author represents that any 26 applicable patent or other IPR claims of which he or she is aware 27 have been or will be disclosed, and any of which he or she becomes 28 aware will be disclosed, in accordance with Section 6 of BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on December 21, 2006. 48 Copyright Notice 49 Copyright (C) The Internet Society (2006). 51 Abstract 53 This document specifies a network protocol that allows mobile nodes 54 to move around in a localized mobility domain, changing their point 55 of attachment within the domain, but without ever being aware at the 56 IP layer that their point of attachment has ever changed, and 57 maintaining seamless communication in the presence of such mobility 58 events. It defines two protocol entities, a Mobile Access Gateway 59 and a Local Mobility Anchor, and a set of messages between them, that 60 together make these mobility events transparent to the mobile nodes 61 at the IP layer. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3. Functional Entities . . . . . . . . . . . . . . . . . . . . . 7 68 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 69 5. Message Types . . . . . . . . . . . . . . . . . . . . . . . . 10 70 5.1. LMA Allocation Request / Reply messages . . . . . . . . 10 71 5.2. Association Request / Reply messages . . . . . . . . . . 10 72 5.3. Disassociation Request / Reply messages . . . . . . . . 11 73 5.4. Location Registration / Ack messages . . . . . . . . . . 11 74 5.5. Location Deregistration / Ack messages . . . . . . . . . 11 75 5.6. MN Address Setup / Ack messages . . . . . . . . . . . . 12 76 5.7. MN Address Remove / Ack messages . . . . . . . . . . . . 12 77 5.8. Routing Setup / Ack messages . . . . . . . . . . . . . . 12 78 5.9. Routing Remove / Ack messages . . . . . . . . . . . . . 13 79 5.10. Heartbeat / Ack messages . . . . . . . . . . . . . . . . 13 80 5.11. Message Transport . . . . . . . . . . . . . . . . . . . 13 81 5.12. Message Optimization . . . . . . . . . . . . . . . . . . 14 82 6. Protocol Extensibility . . . . . . . . . . . . . . . . . . . . 14 83 7. Message and Message Option Formats . . . . . . . . . . . . . . 15 84 7.1. Message Formats . . . . . . . . . . . . . . . . . . . . 15 85 7.2. Options . . . . . . . . . . . . . . . . . . . . . . . . 19 86 8. Protocol Specification . . . . . . . . . . . . . . . . . . . . 26 87 8.1. Mobile Access Gateway Operation . . . . . . . . . . . . 26 88 8.2. Local Mobility Anchor Operation . . . . . . . . . . . . 32 89 9. Data Transport . . . . . . . . . . . . . . . . . . . . . . . . 38 90 9.1. Forwarding of Unicast Data Packets . . . . . . . . . . . 38 91 9.2. Forwarding of Multicast Data Packets . . . . . . . . . . 40 92 9.3. Forwarding of Broadcast Data Packets . . . . . . . . . . 41 93 10. Protocol Constants and Configuration Variables . . . . . . . . 41 94 11. Security Considerations . . . . . . . . . . . . . . . . . . . 41 95 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 96 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43 97 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 98 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 99 15.1. Normative References . . . . . . . . . . . . . . . . . . 43 100 15.2. Informative References . . . . . . . . . . . . . . . . . 44 101 Appendix A. TODO (Things that remain to be specified...) . . . . 44 102 Appendix B. Using GRE Tunnels with NetLMM . . . . . . . . . . . . 45 103 Appendix C. Using MPLS with NetLMM . . . . . . . . . . . . . . . 46 104 Appendix D. TTL Handling . . . . . . . . . . . . . . . . . . . . 46 105 Appendix E. MN-AR Interface considerations . . . . . . . . . . . 46 106 Appendix F. Out of scope . . . . . . . . . . . . . . . . . . . . 46 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47 108 Intellectual Property and Copyright Statements . . . . . . . . . . 49 110 1. Introduction 112 This document specifies a protocol that allows nodes to move around 113 in an access network attaching to various points of the access 114 network while maintaining an IP layer configuration that does not 115 change as the mobile nodes points of attachment change. 117 This protocol is not intended to solve all the problems of network- 118 based IP mobility. Over the past decade many companies and forums 119 have provided many, many staff years of research, development, and 120 standardization to realize all IP mobile networks and no doubt many 121 more years of effort are ahead to deliver improvements to realize all 122 the envisioned usage of such technology. Such systems have added 123 technology for specific link layers, and carrying IP packets over 124 those link layers, support for AAA infrastructures, and mobile 125 security to name a few. Challenges still lie ahead in the form 126 perhaps of mobile QoS, power management and paging, and management of 127 changing network conditions in the face of various mobility events. 129 This protocol is developed in response to the problem statement for 130 network-based localized mobility [I-D.ietf-netlmm-nohost-ps] and this 131 protocol attempts to satisfy the goals in the NetLMM goals document 132 [I-D.ietf-netlmm-nohost-req]. It is intended basically to solve the 133 problem of packet forwarding to nodes that change their point of 134 attachment to the network without the use of any protocol support at 135 the IP layer on the mobile node to support that mobility. 137 This document defines operation of the protocol for use in an IPv6 138 infrastructure and in support of IPv6 nodes, but the authors envision 139 that with modifications the protocol could be productively used with 140 an IPv4 infrastructure or to support IPv4 nodes. The document refers 141 conscientiously to mobile nodes rather than mobile hosts because its 142 operation is not limited in any way to host only support. 144 This protocol is similar and different to various IP mobility 145 protocols the IETF has standardized in the past. It is similar in 146 that it continues the tradition of maintaining address continuity to 147 mobile nodes regardless of the fact that those nodes have changes 148 their points of attachment in the network. It differs in that it 149 does not require any operational changes in protocol operation 150 between the mobile node and the network at the IP layer, in that it 151 supports an infrastructure that embraces network controlled mobility 152 operation, and in that its operation is limited in scope rather than 153 globally applicable. 155 The differences between this protocol and previous mobility protocols 156 are complementary rather than contradictory. It is quite possible to 157 conceive of deployments in which mobile IP is used in a wide area to 158 provide mobility services across multiple interface types or separate 159 local mobility domains while NetLMM is used within a single type of 160 access network or a single local mobility domain to facilitate 161 mobility without involving the mobile. 163 2. Terminology 165 In this document, several words are used to signify the requirements 166 of the specification. These words are often capitalized. The key 167 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 168 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 169 are to be interpreted as described in [RFC2119]. 171 Mobility terminology in this document follows that in [RFC3753], with 172 the added specification of some terms as they are used in this 173 particular document: 175 IP Link 176 A set of routers, mobile nodes, and wireless access points that 177 share link broadcast capability or its functional equivalent. 178 This definition covers one or multiple access points under one or 179 several access routers. In the past, such a set has been called a 180 subnet, but this term is not strictly correct for IPv6, since 181 multiple subnet prefixes can be assigned to an IP link in IPv6. 183 Access Network (revised) 184 An Access Network consists of following three components: wireless 185 or other access points, access routers, access network gateways 186 which form the boundary to other networks and may shield other 187 networks from the specialized routing protocols (if any) run in 188 the Access Network; and (optionally) other internal access network 189 routers which may also be needed in some cases to achieve a 190 specialized routing protocol. 192 Local Mobility (revised) 193 Local Mobility is mobility over a restricted area of the network 194 topology. Note that, although the area of network topology over 195 which the mobile node moves may be restricted, the actual 196 geographic area could be quite large, depending on the mapping 197 between the network topology and the wireless coverage area. 199 Localized Mobility Management 200 Localized Mobility Management is a generic term for protocols 201 dealing with IP mobility management confined within the access 202 network. Localized Mobility Management signaling is not routed 203 outside the access network, although a handover may trigger Global 204 Mobility Management signaling. Localized Mobility Management 205 protocols exploit the locality of movement by confining movement 206 related changes to the access network. 208 Localized Mobility Management Protocol 209 A protocol that supports localized mobility management. 211 Intra-Link Mobility 212 Intra-Link Mobility is mobility between wireless access points 213 within an IP Link. Typically, this kind of mobility only involves 214 Layer 2 mechanisms, so Intra-Link Mobility is often called Layer 2 215 mobility. No IP link configuration is required upon movement 216 since the link does not change, but some IP signaling may be 217 required for the mobile node to confirm whether or not the change 218 of wireless access point also resulted in a change of IP link. If 219 the IP link consists of a single access point/router combination, 220 then this type of mobility is typically absent. 222 Mobile Access Gateway (MAG) 223 A Mobile Access Gateway (MAG) is a router embedded in a device 224 that terminates a specific link layer technology to which mobile 225 nodes attach themselves. It terminates one end of the MAG of the 226 connection to one or more Local Mobility Anchors and participates 227 in the NetLMM protocol exchange. 229 Local Mobility Anchor (LMA) 230 A local mobility anchor (LMA) is a router that terminates 231 connections to multiple Mobile Access Gateways, services mobility 232 requests for mobile nodes moving within a NetLMM system, and 233 participates in the NetLMM protocol exchange. 235 NetLMM Domain 236 A NetLMM domain is a set of multiple MAGs and a set of one or more 237 LMAs interconnected within an access network that provides 238 mobility operations for attached mobile nodes through the 239 execution of the NetLMM protocol. 241 NetLMM Address 242 The invariant IP address on the MN inside the NetLMM domain. For 243 IPv6 it is assumed that this is an invariant routable IP address 244 with global scope. 246 NetLMM Network Prefix 247 The NetLMM Network Prefix (NNP) is the IPv6 link prefix of the 248 NetLMM address. 250 Routing Tag 251 An opaque identifier that is signaled between MAGs and LMAs and 252 that can be used to distinguish traffic inside packets when the 253 contents inside those packets cannot be inspected due to some 254 operations such as encryption or header compression. It could be 255 used, for example, in a GRE key field if GRE tunneling were being 256 used to distinguish internal packets destined for a mobile when 257 the internal packets headers have been compressed. 259 3. Functional Entities 261 The principal functional entities in a NetLMM infrastructure are the 262 Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA). 263 There are other entities that will make up a mobile access network 264 that are used to support various kinds of functionality (mobile 265 nodes, AAA, routing, DNS, etc.) whose basic functionality may be used 266 by the MAG and the LMA but whose operation is not changed in any way 267 for the proper operation of the NetLMM protocol. 269 Include a diagram. The diagram should show: 270 1. multiple MAGs 271 2. multiple LMAs 272 3. their interconnectivity 274 Should it show? 275 4. mobile nodes moving around the edge 276 5. the possibility of link layer access technologies beneath MAGs 278 The Mobile Access Gateway 279 The Mobile Access Gateway (MAG) is a router that a mobile node is 280 attached to as the first hop router in the NetLMM infrastructure. 281 The MAG is connected to the mobile node over some specific link 282 provided by a link layer but the NetLMM infrastructure is agnostic 283 about the link layer technology that is used. Each MAG has its 284 own identifier used in NetLMM protocol messaging between the MAG 285 and the LMA. The important interfaces between link layer specific 286 functions and the NetLMM function reside on the MAG. There are 287 multiple MAGs in a NetLMM infrastructure. 289 The Local Mobility Anchor 290 The local mobility anchor (LMA) is a router that maintains 291 reachability to a mobile node's address while the mobile node 292 moves around within the NetLMM infrastructure. It is responsible 293 to maintain forwarding information for the mobile nodes which 294 includes a set of mappings to associate mobile nodes by their 295 identifiers with their address information, associating the mobile 296 nodes with their serving MAGs and the relationship between the LMA 297 and the MAGs. There may be one or more LMAs in a NetLMM 298 infrastructure. 300 4. Protocol Overview 302 The protocol consists of two major phases, an initiation phase and an 303 operational phase. During the initiation phase the MAGs and an LMA 304 (or multiple LMAs) establish connectivity between them. Although 305 this document describes this phase of the protocol operation as an 306 initiation phase there is no restriction on the ability of adding new 307 MAGs or new LMAs to a NetLMM infrastructure while other nodes are 308 already in operation. During the operational phase the MAGs and LMAs 309 provide mobile connectivity service to mobiles nodes that are 310 attaching to the infrastructure, leaving the infrastructure, and 311 moving around within the infrastructure. 313 It is not assumed that a MAG is associated with only a single LMA. 314 If there exists multiple LMAs in a NetLMM Domain, each MAG would most 315 likely be associated with, and potentially communicate with all the 316 LMAs rather than only a single LMA. 318 The NetLMM infrastructure uses 6 messages to establish and maintain 319 associations between the MAGs and the LMAs: Association Request, 320 Associate Reply, Disassociation Request, Disassociate Reply, 321 Heartbeat, and Heartbeat Ack. 323 A MAG associates itself with an LMA by sending an Association Request 324 message that includes its MAG ID and the supported data forwarding 325 modes (such as IPv6-in-IPv6). In response the LMA creates an 326 association with the MAG and populates state information about the 327 association. The LMA responds, providing its LMA ID and an agreed 328 upon data forwarding mode to the MAG. The MAG can undo the 329 relationship with the LMA through sending a Disassociation Request, 330 to which the LMA responds with a Disassociate Reply. Heartbeat 331 messages are sent between the MAG and LMA to determine the current 332 status of the reachability of the other entity. All of these 333 messages may be sent optionally over an IPsec connection if 334 additional security is desired. 336 The NetLMM infrastructure uses 14 messages to manage the attachment, 337 departure, mobility, and other activities of mobile nodes within the 338 infrastructure: LMA Allocation Request, LMA Allocation Reply, 339 Location Registration and Acknowledge, Location Deregistration and 340 Acknowledgment, Routing Setup and Acknowledgement, Routing Removal 341 and Acknowledgement, MN Address Setup and Acknowledgement, MN Address 342 Removal and Acknowledgement. 344 When a mobile node is to receive service, a policy decision point 345 entity may send an LMA Allocation Request to the LMA creating state 346 for the mobile node. The LMA allocation request authorizes service 347 for a particular Mobile Node ID. This message may contain policy 348 information for the mobile node. The LMA acknowledge the request 349 with an LMA allocation reply. It is possible that an LMA is 350 configured to authorize service for any mobile node and in such a 351 situation the LMA Allocation Request and reply messages are not 352 necessary. 354 When a mobile node connects to the NetLMM infrastructure, it first 355 needs to configure an address. Whether it is using stateful or 356 stateless address configuration, the serving LMA needs to be involved 357 in the address allocation process. So when a mobile node connects, 358 the MAG sends a location registration message to the LMA containing 359 its own ID and the Mobile Node's ID. The LMA responds to the message 360 with a a Location Registration Ack message that includes the NetLMM 361 prefix that the MAG is to use in its router advertisement toward the 362 Mobile Node. The MAG in turn sends a router advertisement to the 363 attached mobile. Once address configuration is complete (through 364 either stateful or stateless address configuration) the MAG registers 365 the mobile node's address with the LMA by sending an MN Address Setup 366 message to the LMA including the MAG's ID, the MN's ID, the NetLMM 367 address, and a tunnel ID. The LMA creates forwarding state for 368 packets in response to this message and sends a MN address reply to 369 the MAG acknowledging the packet setup. The MAG, in receiving a 370 successful MN Address Setup Reply, creates forwarding state for 371 packets destined to the mobile node. 373 When a mobile node then leaves the NetLMM infrastructure, the MAG 374 sends a Location Deregistration message to the LMA including the 375 Mobile Node's ID and the MAG's ID. The LMA cleans up all state for 376 the mobile node identified in the message and sends a Location 377 Deregistration Acknowledgement message. 379 It is also possible for the LMA to remove a mobile node from the 380 network. This could be done for a number of policy specific reasons 381 in the network. The same two messages are used, Location 382 Deregistration and Local Deregistration Acknowledgement, but they are 383 initiated by the LMA and acknowledged by the MAG in this case. The 384 MAG disconnects the mobile and removes all mobile state in response 385 to this message. 387 When a mobile node moves from one MAG to another MAG, the new MAG 388 (nMAG) sends a Location Registration Message to the LMA with the MAG 389 ID and the MN ID. The LMA responds by sending a Routing Setup 390 message to the nMAG that includes the MN ID, the MAG ID, the LMA ID, 391 NetLMM addresses. The new MAG acknowledges this information with a 392 Routing Setup Ack message and the LMA responds with a Location 393 Registration Ack message containing the NetLMM prefix that the nMAG 394 uses in the router advertisement for the MN. 396 The mobile node can at any time configure new IP addresses for itself 397 using stateless address auto-configuration and this operation is 398 supported in NetLMM. When the mobile issues a new address DAD 399 request, the MAG sends a MN Address Setup Request to the LMA with the 400 mobile node's ID and the new NetLMM address. The LMA validates the 401 usability of the address, updates forwarding state, and acknowledges 402 the request with the MN Address Setup Reply message to the serving 403 MAG which then replies to the MN DAD operation. The means through 404 which the NetLMM infrastructure knows that the mobile node is 405 attached, leaving, or moving is beyond the scope of this protocol 406 specification. It is envisioned that this information is largely 407 access network specific and that the MAG uses an API to trigger much 408 of the operation described herein. 410 5. Message Types 412 This document defines a set of control messages and options for the 413 NetLMM protocol. The control messages are carried by the User 414 Datagram Protocol, using a well known port number, as described in 415 Section 5.11. The messages are presented in this section, and the 416 message format and option formats are defined later, in Section 7. 418 5.1. LMA Allocation Request / Reply messages 420 The LMA Allocation Request message is used to allocate an LMA for the 421 MN that is initially attached to the network and to validate the 422 Location Registration message coming later from the MAG to which the 423 MN is attached. This message containing the MN ID is sent to the 424 selected LMA and may come from various nodes such as the MAG to which 425 the MN is attached or the PDP that is involved in the authentication 426 of the MN. The LMA Allocation Request is optional and the LMA may be 427 allocated by other means (e.g., static allocation) and can be 428 configured to serve the MN without this message. 430 The LMA Allocation Reply message is sent from the LMA to the source 431 of the LMA Allocation Request message to notify the status of the 432 request (success or error code). 434 5.2. Association Request / Reply messages 436 The Association Request is used to set up the control and data plane 437 relationship between the MAG and LMA. This message is sent from the 438 MAG to the LMA in the MAGs initiation phase, before it enters the 439 operational phase and handles MN Location Registration and Routing 440 Setup. The message contains the sender's ID, its functional 441 capabilities and supported data forwarding modes. The data 442 forwarding mode specifies the tunnel method of the data plane (e.g., 443 IP-in-IP). The tunnel between the MAG and LMA is bidirectional, 444 which is achieved by establishing two unidirectional tunnels in 445 opposite directions. 447 The Associate Reply message is sent from the LMA to the MAG to notify 448 the status of the request (success or error code). If the request is 449 successful, the receiver of the request also sends its capabilities 450 (e.g., the receiver's ID, agreed-upon data forwarding mode, etc.) on 451 this message. 453 5.3. Disassociation Request / Reply messages 455 The Disassociation Request message is sent from the MAG to the LMA or 456 vice versa to tear down the control and data plane relationship 457 between them. This message contains the MAG ID and LMA ID. 459 The Disassociate Reply message is sent from the LMN to the MAG or 460 vice versa to inform the status of the request (success or error 461 code). 463 5.4. Location Registration / Ack messages 465 The Location Registration message is sent from the MAG to the LMA 466 when the MAG detects the MN having accessed the network without an IP 467 address. By this message, the MAG and LMA create the mobility state 468 of the MN. The IP address of the MN is not known at this point and 469 the MN Address Setup message must follow to update the mobility state 470 and to set up the routing for the MN. This message contains the MN 471 ID, MAG ID and LMA ID. 473 The Location Registration Ack message is sent from the LMA to the MAG 474 to acknowledge the receipt of the Location Registration message. If 475 the registration is successful, the LMA sends the NetLMM prefix on 476 this message, which in turn is used for the Router Advertisement sent 477 by the MAG. 479 5.5. Location Deregistration / Ack messages 481 The Location Deregistration message is sent from the MAG to the LMA 482 or vice versa to delete the mobility state of the MN. The MAG sends 483 this message when the MN is detected to have moved away. On the 484 other hand, the LMA sends this message when it determines that the MN 485 is at a new location. This message contains the MN ID, MAG ID, LMA 486 ID and the requested revocation time. 488 The Location Deregistration Ack is sent back to the source of the 489 Location Deregistration message to acknowledge the receipt of the 490 Location Deregistration message. This message contains the agreed 491 revocation time. 493 5.6. MN Address Setup / Ack messages 495 When the MAG determines that the MN has obtained its NetLMM address 496 by for example the neighbor advertisement (the DAD procedure) or the 497 DHCP server, the MAG sends he MN Address Setup message to the LMA to 498 update the mobility state and to create a routing entry for the MN on 499 the LMA. This message contains the MAG ID, LMA ID and one or more MN 500 ID(s) and NetLMM address(es) assigned to the MN(s). Optionally, the 501 Routing Tag(s) for the MN(s) may be included. 503 The MN Address Setup Ack is sent from the LMA to the MAG to 504 acknowledge the receipt of the MN Address Setup message and to notify 505 the MAG if the NetLMM address(es) contained in the MN Address Setup 506 message are accepted (the DAD procedure). If the Routing Tag is 507 contained in the Routing Setup message, a corresponding Routing Tag 508 is returned by the Routing Setup Ack message. 510 5.7. MN Address Remove / Ack messages 512 When the MAG determines that one of the MN's NETLMM address(es) is no 513 longer valid or used, the MAG sends the MN Address Remove message to 514 the LMA to delete the corresponding mobility state and routing entry 515 in the LMA. This message contains the MN ID, MAG ID, LMA ID and 516 corresponding NETLMM address. 518 The MN Address Remove Ack is sent from the MAG to the LMA to 519 acknowledge the receipt of the MN Address Remove message. 521 5.8. Routing Setup / Ack messages 523 When the MN moves from the previous MAG to the new MAG (inter-MAG 524 handover), the LMA, which already has the mobility state for the MN, 525 sends the Routing Setup message to the new MAG in response to the 526 Location Registration message from the new MAG. This message is used 527 to update the routing on the new MAG and contains the MN ID, MAG ID, 528 LMA ID and one or more NetLMM address(es) assigned to the MN. 529 Optionally, the Routing Tag for the MN may be included. 531 The Routing Setup Ack message is sent from the MAG to the LMA to 532 acknowledge the receipt of the Routing Setup message. If the Routing 533 Tag is included in the Routing Setup message, the corresponding 534 Routing Tag is returned by the Routing Setup Ack message. 536 5.9. Routing Remove / Ack messages 538 When the LMA determines that one or more NetLMM address(es) is/are no 539 longer valid by for example the DHCP server, the LMA sends the 540 Routing Remove message to the MAG to delete the corresponding routing 541 entry/entries on the MAG. This message contains the MN ID, MAG ID, 542 LMA ID and NetLMM address(es) of the MN. 544 The Routing Remove Ack is sent from the MAG to the LMA to acknowledge 545 of the receipt of the Routing Remove message. 547 5.10. Heartbeat / Ack messages 549 The Heartbeat message is sent from the MAG to LMA or vice versa to 550 obtain the connectivity status. This message contains the MAG ID, 551 LMA ID and the heartbeat number that is separated from the message 552 sequence number. 554 The Heartbeat Ack is sent back from the node that received the 555 Heartbeat message to its peer. This message contains the MAG ID, LMA 556 ID and the corresponding heartbeat number. 558 These messages are suppressed when there is data traffic between the 559 two nodes. 561 5.11. Message Transport 563 The new NetLMM control messages defined in this document are carried 564 by the User Datagram Protocol RFC 768 [RFC0768] using well known port 565 number TBD (assigned by IANA). 567 The message sender SHOULD include a non-zero UDP Checksum. The 568 recipient of the message MUST process and check the UDP checksum. A 569 Zero checksum SHOULD be accepted by the recipient. 571 The sender and initiator of a message exchange MUST use the following 572 UDP ports: 574 * Source Port: variable 576 * Destination Port: TBD (Assigned by IANA) 578 In case the recipient of a NETLMM message has to reply, the following 579 UDP ports MUST be used: 581 * Source Port: variable 583 * Destination Port: Copied from the source port of the received 584 message. 586 5.12. Message Optimization 588 In order to minimize routing establishment delays, e.g., handover 589 times, it may be important to achieve routing setup or routing 590 changes with an absolute minimum number of messaging roundtrips 591 between the MAG and the LMA. However, given the messages described 592 earlier in this section, there are several cases where 2 messaging 593 round-trips are needed in order to complete a routing setup. 595 Future versions of this document will propose optimizations which 596 reduce the number of messages that must be sent in order to achieve 597 routing setup or routing changes. It is however deemed important to 598 have agreement on the base functionality and the base messages before 599 such optimizations are discussed. 601 6. Protocol Extensibility 603 NetLMM consists of a set of new control messages, described in 604 Section 5 in this document. Up-to-date values for the message types 605 are maintained in the online IANA registry of assigned numbers. 607 NetLMM defines a general extension mechanism using options to allow 608 optional information to be carried in the control messages. The 609 options are encoded in the Type-Length-Value format, and are 610 described in detail in Section 7.2. The options carry additional 611 information used for processing the message. Up-to-date values for 612 the option types are maintained in the online IANA registry of 613 assigned numbers. 615 The Type field in the NetLMM option is split into two ranges: Type 616 values of 0 through 127 (inclusive) for not skippable options and 128 617 through 255 (inclusive) for skippable options. The recipient of a 618 message with an unrecognized non-skippable option MUST silently 619 discard the message. Otherwise, if no unrecognized non-skippable 620 options are found, the message MUST be processed with any 621 unrecognized skippable option bypassed (i.e. move to next option 622 using the Length field of the unrecognized option) during processing 623 by the receiver. The Sub-Type field provides efficient use of the 624 option type numbering space. 626 Format: 628 0 1 2 3 629 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 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | Option Type |Option Sub-Type| Length | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | | 634 . . 635 . Data . 636 . . 637 | | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 Option Type 641 This field identifies the particular type of option serving a 642 specified function. 644 Option Sub-Type 645 This field indicates the sub-type of the option, and provides for 646 up to 256 related Option Sub-Types with the same Option Type 647 field. 649 Length 650 The value represents the length of the "Data" portion of the 651 option, in unit of octets. 653 7. Message and Message Option Formats 655 7.1. Message Formats 657 An NetLMM message consists of a header followed by one or more 658 options. The Message header is common and messages are distinguished 659 by Type field in the header. NetLMM options are in TLV format and 660 8byte aligned, though Type field divided into two parts; Option Type 661 and Option Sub-Type. The length field indicates the exact length of 662 the following value fields in units of 8 octets. All option payloads 663 whose length is not a unit of 8 octets must be padded to the correct 664 alignment. 666 7.1.1. Message Header 668 All NetLMM messages start with the following common header. 669 Parameters for each message are contained in the option format (see 670 following sections). 672 0 1 2 3 673 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 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Version | Status | Type | Sub-Type | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Sequence Number | Reserved | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | | 680 . . 681 . Options . 682 . . 683 | | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 Version 687 An 8-bit number, indicating the NetLMM protocol version. The 688 version of the NetLMM protocol specified in this document is 1. 690 Status 691 An 8-bit number, which indicates the status of the message. When 692 used for request messages, e.g., Location Registration, the status 693 code is normally set to 0, indicating 'Not Applicable'. When used 694 for reply and acknowledgement messages, the status code indicates 695 the result of processing the associated request message. The 696 following values are defined by this document: 698 0: Not Applicable (N/A) 699 The status code is not applicable for the message. This is 700 normally the case for request messages. 702 1: Success Acknowledgement 703 The associated request message was successfully processed. 705 2: Administratively Prohibited 706 An action was refused due to administrative policy reasons. 708 3: Lack of Resources 709 The resources needed to provide the requested service was not 710 available. 712 4: Unauthorized MN 713 Used by the LMA in response to Location Registration or Routing 714 Setup, to notify the MAG of the MN not being authorized for 715 service. 717 6: Duplicate Address 718 Used by the LMA when an MN Address Setup contains an IP address 719 that is duplicated in the same NetLMM domain. The specific 720 invalid addresses MUST be specified in Address Options with 721 Sub-Type TBD, Duplicate Address. 723 5: Invalid Address 724 Used by the LMA when an MN Address Setup contains an IP address 725 that is invalid. The specific invalid addresses MUST be 726 specified in Address Options with Sub-Type TBD, Invalid 727 Address. 729 7: Over IP Address Limit 730 Used by the LMA on receipt of a Routing Setup or MN Address 731 Setup message, if the maximum number of IP addresses allowed 732 for a MN has been exceeded. 734 8: Invalid Tunnelling Method 735 The proposed tunnel method is not supported or unavailable. 737 9: Invalid Message 738 The NetLMM Request Message was invalid or malformed. 740 10: Already Associated 741 The LMA already had the requesting MAG listed as associated. 743 Type 744 8-bit indicator, shows NetLMM message types. The message types 745 are specified in section 5. The values for messages are defined 746 as follows; 748 0: LMA Allocation Request/Reply 750 1: Association Request/Reply 752 2: Disassociation Request/Reply 754 3: Location Registration/Ack 756 4: Location Deregistration/Ack 758 5: MN Address Setup/Ack 760 6: MN Address Remove/Ack 761 7: Routing Setup/Ack 763 8: Routing Remove/Ack 765 9: Heartbeat/Ack 767 Sub-Type 768 8-bit indicator, this indicator is Type dependent field and can 769 use to add extra information for the message. 771 Sub-types defined in this document, valid for all message types 772 defined in this document: 774 0: Request 775 This is the Request message of the given type, with semantics 776 and format as specified in this document. When message 777 variations with other semantics or formats are required in the 778 future, new subtypes should be allocated for them. 780 1: Ack/Reply 781 This is the Acknowledgement (or Reply) message to be sent in 782 response to request messages of the given type. It is seen as 783 less likely that it will be necessary to allocate new sub-types 784 for new Ack/Reply messages, but there is no restriction on 785 doing so. 787 Sequence Number 788 16-bit length, used to ensure the correspondence of the request 789 and ack/reply pair of the same message between the MAG and the 790 LMA. The sequence number is exchanged between given MAG and LMA, 791 and configured when MAG has joined to a NetLMM domain through the 792 exchange of Association Request/Reply messages. Sequence Number 793 comparisons MUST be performed modulo 2**16, i.e., the number is a 794 free running counter represented modulo 65536. A Sequence Number 795 in a received message is considered less than or equal to the last 796 received number if its value lies in the range of the last 797 received number and the preceding 32768 values, inclusive. For 798 instance, if the last received sequence number was 15, then 799 messages with sequence numbers 0 through 15, as well as 32783 800 through 65535, would be considered 'less than or equal'. 802 Reserved 803 16-bit field reserved for future use. The value MUST be 804 initialized to zero by the sender, and MUST be ignored by the 805 receiver. 807 Options 808 8 byte aligned field, and can add multiple options. See following 809 sections for options. 811 7.2. Options 813 7.2.1. ID Option 815 The ID option carries various types of identifiers. All messages 816 related to a specific MN must include an ID option providing the MN 817 ID. Multiple ID options can be included in an message. In addition 818 to that for the MN ID there might for instance be ID options for the 819 MAG ID and for the LMA ID in a Location Registration. For the 820 purpose of the ID option, the ID itself is viewed as an octet 821 sequence, but to avoid ID collisions, the ID is prefixed with an ID 822 type. An example for the MN ID is a NAI [RFC4282]. 824 This option can also contain Routing Tag which is an identifier 825 specified by each tunnel method for data transport. The existence or 826 use of the Routing Tag is also dependent on the tunnel method to use. 828 0 1 2 3 829 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 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Option Type |Option Sub-Type| Length | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | ID-Type | Identifier... | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 835 | | 836 . . 837 . . 838 . . 839 | | 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 842 Option Type 843 0 845 Option Sub-Type 846 This field indicates what the ID in this option refers to. It is 847 expected that additional Sub-Types may be defined in the future. 849 0: MN ID 850 1: LMA ID 852 2: MAG ID 854 3: Routing Tag 856 Length 857 Variable. The value indicates exact length of the option in 858 octets, excluding the Type, Sub-Type and Length fields. 860 ID-Type 861 This field indicates the type of ID carried in the remainder of 862 the option. 863 *** Note: Check whether there already exists an applicable IANA 864 registry for ID types which we could use here *** 866 0: 128-bit opaque cryptographically generated identifier (such as 867 proposed ORCHID IDs 869 1: NAI according to [RFC4282] 871 2: Ethernet MAC Address 873 3: IPv6 Address 875 Identifier 876 This is a variable-length octet sequence, which is expected to 877 hold an identifier of the type indicated by the ID-Type field. 879 7.2.2. NetLMM Address Option 881 This option conveys NetLMM IP address and the prefix that LMA 882 advertise for MNs. The NetLMM address can be both IPv4 and IPv6. 883 This option can also inform LMA prefix only. 885 0 1 2 3 886 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 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | Option Type |Option Sub-Type| Length | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | Prefix Length | Reserved | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | | 893 + + 894 | | 895 + Address (IPv6 case) + 896 | | 897 + + 898 | | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 Option Type 902 1 904 Option Sub-Type 906 0: Indicates that the data in the Address field is an IPv6 address 907 or address range. If Prefix Length is 128 this is an address, 908 otherwise it is an address range with span determined by the 909 given prefix length. 911 1: Indicates that the data in the Address field is an IPv4 912 address. 914 2: Indicates that the data in the Address field is an IPv6 network 915 prefix information. 917 3: Indicates that the data in the Address field is an IPv4 network 918 prefix information. 920 4: Indicates that the address in the Address field is a duplicate 921 IPv6 address. 923 5: Indicates that the address in the Address field is a duplicate 924 IPv4 address. 926 6: Indicates that the address in the Address field is an invalid 927 IPv6 address. 929 7: Indicates that the address in the Address field is an invalid 930 IPv4 address. 932 Length 933 Variable. The value indicates exact length of the option in 934 octets, excluding the Type, Sub-Type and Length fields. 936 Prefix Length 937 Variable. The value indicates the number of leadings bits in the 938 Address that are valid (as a network prefix). 940 If the Sub-Type value indicates an invalid or duplicate address, 941 this field must be set to zero when sending, and ignored on 942 receipt. 944 Reserved 945 16-bit field reserved for future use. The value MUST be 946 initialized to zero by the sender, and MUST be ignored by the 947 receiver. 949 Address: 950 If the Option Sub-Type is 0 or 2, the value in the IPv6 address 951 appears, while the type is 1 or 3, the value in the IPv4 address 952 is presented. 954 7.2.3. Data Transport Option 956 This option contains data transport methods capabilities that the MAG 957 or LMA has. This option is used by Association request/reply 958 messages to negotiate the data transport method between MAG and LMA. 959 Multiple methods can be contained in the field with the order of 960 preference. The mandatory transport method is IPv6-in-IPv6, which 961 must be listed. 963 0 1 2 3 964 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 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | Option Type |Option Sub-Type| Length | 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 | Data Transport Method 1 | 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 | | 971 ~ ~ 972 | | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | Data Transport Method n | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 Option Type 978 2 980 Option Sub-Type 981 This field is reserved for future use. The value MUST be 982 initialized to zero by the sender, and MUST be ignored by the 983 receiver. 985 Length 986 Variable. The value indicates exact length of the option in 987 octets, excluding the Type, Sub-Type and Length fields. The 988 number of Data Transport Method fields is equal to the Length 989 divided by the size, in octets, of the Data Transport Method 990 field. 992 Data Transport Method 993 Present the data transport methods available at the sender of the 994 Association request/Reply message, i.e., LMA and MAG. The methods 995 presented in this option are listed in order of the preference. 997 0: IPv6-in-IPv6 999 1: GRE 1001 2: IPv4-in-IPv6 1003 7.2.4. Revocation Timer Option 1005 This option indicates the length, by milliseconds, to keep the 1006 forwarding state of a given MN at previous MAG in handover scenario. 1007 This option is included in Location Deregistration and its 1008 acknowledgement. The Revocation Time in the Location Deregistration 1009 Ack is copied from that presented in the receipt option of the 1010 Location Deregistration. If the MAG can not keep the MN state as LMA 1011 has requested for some reason, MAG can input preferable Revocation 1012 time or error code instead of copying original value. 1014 0 1 2 3 1015 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 1016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1017 | Option Type |Option Sub-Type| Length | 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | Revocation Time | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 Option Type 1023 3 1025 Option Sub-Type 1026 This field is reserved for future use. The value MUST be 1027 initialized to zero by the sender, and MUST be ignored by the 1028 receiver. 1030 Length 1031 4. The value indicates exact length of data shown in Revocation 1032 Time field. Shown in octets, network byte order 1034 Revocation Time 1035 Variable. Indicate the preferred delay to delete the MN 1036 forwarding state from previous MAG to LMA in handover. The value 1037 shows in millisecond unit. 1039 7.2.5. Timestamp Option 1041 This option contains the timestamp value in the format of NTP 1042 timestamp, and records the time when the message is sent. This 1043 option can be attached to any message and used to detect an 1044 overtaking message in race condition by comparing the timestamp 1045 values of messages. Especially in handover scenario, if the network 1046 suffers from a sudden propagation delay for some reason or the MN 1047 moves rapidly between MAGs, the timestamp may be used to facilitate 1048 in-order messages processing regardless of message arrival order. 1049 The use of this option is network administrator dependent, and needs 1050 some of the time distribution methods, (e.g., NTP or GPS time 1051 synchronization system), with the high accuracy enough to support 1052 fast moving MNs. 1054 0 1 2 3 1055 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 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1057 | Option Type |Option Sub-Type| Length | 1058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1059 | Timestamp | 1060 | | 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 Option Type 1064 4 1066 Option Sub-Type 1067 This field is reserved for future use. The value MUST be 1068 initialized to zero by the sender, and MUST be ignored by the 1069 receiver. 1071 Length 1072 8. The value indicates exact length of Timestamp field Shown in 1073 octets, network byte order. 1075 Timestamp 1076 Follows the 64bit length format of the NTP timestamp [RFC4330] 1078 7.2.6. Vendor Specific Option 1080 This option can be used by any vendor or organization that has an 1081 IANA-allocated SMI Network Management Private Enterprise Code. 1082 Details of the meaning of value field is entirely up to the defining 1083 vendor or organization. 1085 0 1 2 3 1086 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 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 | Option Type |Option Sub-Type| Length | 1089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 | Vendor/Org-ID | 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 | | 1093 . . 1094 . Value . 1095 . . 1096 | | 1097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 Option Type 1100 5 1102 Option Sub-Type 1103 This field is reserved for future use. The value MUST be 1104 initialized to zero by the sender, and MUST be ignored by the 1105 receiver. This field may not be assigned any value different from 1106 zero by the organizations using the option; only the Value field 1107 may be freely used. 1109 Length 1110 Variable. The value indicates exact length of the option in 1111 octets, excluding the Type, Sub-Type and Length fields. 1113 Vendor/Org-ID 1114 The high-order octet is 0 and the low-order 3 octets are the SMI 1115 Network Management Private Enterprise Number [RFC2578], 1116 [ENTERPRISE-NUM], of the Vendor in network byte order. 1118 Value 1119 Variable. Details defined by individual Vendors / Organizations. 1121 8. Protocol Specification 1123 8.1. Mobile Access Gateway Operation 1125 8.1.1. Conceptual Data Structures 1127 Each MAG MUST maintain a NetLMM Routing Cache and an LMA List. 1129 Each MAG Routing Cache entry conceptually contains the following 1130 fields for each attached MN: 1132 * MN ID of the attached MN. This identifier is learned from the 1133 attach procedure and is used from the MAG to identify the attached 1134 MN in the Location Registration message, which is sent to the 1135 selected LMA. 1137 * One or more global IP addresses of an attached MN. Each IP 1138 address is learned from an LMA through the Routing Setup message 1139 from an LMA or my means of local operation. According to the 1140 context of the received message or local indication, an IP address 1141 is set up, updated or removed from the Routing Cache. 1143 * Routing Tag for the attached MN. Creating the entry and use of 1144 this tag is optional and might support identification of the MN in 1145 the data plane at the LMA and the MAG. In case the LMA and MAG 1146 specify asymmetric tags for the MN, this field MUST draw a 1147 distinction. 1149 * LMA ID of the LMA serving an attached MN. The serving LMA and its 1150 LMA ID is learned from the LMA selection policy, which is out of 1151 scope of this specification. 1153 Each MAG MUST maintain an LMA List, which identifies all LMAs with 1154 which the MAG is associated. The LMA List is used to perform 1155 heartbeat tests and to map an LMA ID to the associated LMA's IP 1156 address(es). The LMA List also supports the procedure of bulk de- 1157 registrations at all or a subset of LMAs. 1159 The LMA List conceptually contains the following fields for each LMA 1160 entry: 1162 * LMA ID of the LMA. 1164 * One or more IP address(es) of the LMA. The LMA's IP address 1165 information is learned through the LMA selection policy, which is 1166 out of scope of this specification. Availability of multiple LMA 1167 IP addresses could support operation of multi-homed LMAs. Details 1168 about how to handle multiple LMA IP addresses is out of scope of 1169 this specification. 1171 * Selected forwarding approach for the association with an LMA. 1172 This field is needed in case a single forwarding approach is set 1173 up for the association with an LMA. 1175 * Forwarding capabilities of the LMA. In case the LMA attaches a 1176 list of its own capabilities to the Associate Reply message, the 1177 MAG SHOULD store them in this field of the LMA List. 1179 Each MAG MIGHT maintain a list of available LMAs. Such a list can 1180 support the LMA selection procedure and the MAG's association 1181 procedure. 1183 The list of available LMAs comprises conceptually the following 1184 fields for each LMA: 1186 * LMA ID of the LMA. 1188 * One or more IP address(es) of the LMA. Availability of multiple 1189 IP addresses could support the operation of multi-homed LMAs. 1190 Details about how to handle multiple IP addresses is out of scope 1191 of this specification. 1193 8.1.2. Processing NetLMM Headers 1195 * The Type and Sub-Type fields MUST have a known value 1196 (Section 7.1.1). Otherwise, the node MUST discard the message and 1197 issue a an Error message with Status field set to 7 ("INVALID 1198 MESSAGE"). 1200 8.1.3. Processing NetLMM Messages 1202 8.1.3.1. Association Procedure 1204 Each Mobile Access Gateway sends an Association Request message in 1205 order to set up the control and data plane relationship with a given 1206 local mobility anchor. The actual trigger for this message is out of 1207 scope of this document and may depend on network configuration 1208 peculiarities. For example, the Association Request message may be 1209 sent during the MAG start up procedure. 1211 The Association Request message MUST include: 1213 * the MAG identifier included in a NetLMM ID option. This 1214 identifier is used by the peer to identify the MAG and is included 1215 in all subsequent messages. 1217 * the MAG's capabilities in terms of support of data transport 1218 methods included in a NetLMM Data Transport Option. The MAG MUST 1219 insert in this option all possible tunneling methods that can be 1220 used with the peer LMA. Based on configuration, it is possible 1221 that some tunneling methods are used only with some LMAs: in this 1222 case, the Association Request message MUST contain only the 1223 tunneling methods that are administratively permitted with that 1224 specific LMA. 1226 When sending an Association Request, the MAG MAY create a tentative 1227 entry in its LMA List, including the LMA ID, IP address of the LMA 1228 and the proposed forwarding capabilities. However it may be that the 1229 MAG does not know these data during the association procedure: in 1230 this case, it does not create any tentative entry in the LMA List. 1232 In order to complete the NetLMM association, the MAG MUST receive an 1233 Association Reply from the peer LMA with STATUS 1. In this case, the 1234 MAG MUST create an entry in its LMA List (or update the tentative 1235 entry created earlier), with the messages sent by the LMA in the 1236 Association Reply. The MAG MUST also update the forwarding method 1237 pre 1239 8.1.3.2. Disassociate Procedure 1241 The Disassociation Request can be sent both by the MAG and by the LMA 1242 in order to tear down the control and data plane relationship with 1243 the LMA. The event that triggers this message is out of the scope of 1244 this specification; for example, the MAG may send a Disassociation 1245 Request to all the LMAs present in its LMA List just before shutting 1246 down. 1248 In case the Disassociate Procedure is initiated by the MAG, the MAG 1249 MUST include an ID Option with the its identity in the Disassociation 1250 Request. When sending the Disassociation Request, the MAG MAY set 1251 the LMA entry related to the specific LMA as tentative. When it 1252 receives a Disassociation Reply with Status 1 "SUCCESS", the MAG MUST 1253 delete the correspondent entry in its LMA List. 1255 In case the Disassociate Procedure is initiated by the LMA, when the 1256 MAG receives a Disassociation Request message, it MUST validate it. 1257 If it is correct, it MUST delete the related entry in its LMA List 1258 and send a Disassociate Reply with Status 1 "SUCCESS". As in all 1259 NetLMM messages, the MAG MUST include the ID option with its 1260 identity. 1262 8.1.3.3. MN network access procedure 1264 When a new MN attaches to the network, the Mobile Access Gateway 1265 receives an indication. This indication can be received by very 1266 different means (e.g., L2 mechanisms, AAA infrastructure) that are 1267 out of scope of this specification. In any case, regardless how this 1268 is accomplished, the MAG receives a MN_Access_Network API that 1269 carries the MN identifier (e.g., MAC address of the MN, NAI) and the 1270 LMA identifier. 1272 Upon the API notification, the MAG MUST send a Location Registration 1273 message to the LMA including three different ID options, containing 1274 its own identity, the identity of the MN and the identity of the LMA. 1275 How the MAG resolves the LMA ID received in the API into the LMA IP 1276 address is out of scope of this specification and is part of the 1277 NetLMM bootstrapping procedure. Viable options are pre-configuration 1278 or DNS resolution (in case the LMA ID is the FQDN of the LMA). In 1279 case there is only one LMA in the local domain, this issue does not 1280 exist. 1282 If the location registration is successfully performed, the MAG 1283 receives a Location Registration Acknowledge message from the LMA 1284 with Status value 1 "SUCCESS". This message includes also a NetLMM 1285 Network Prefix that the MAG MUST advertise to the MN. For this 1286 purpose, the MAG takes the prefix parameters from the NetLMM Address 1287 Option in the Location Registration Acknowledge and creates a Router 1288 Advertisement with a correspondent Prefix Option. It then sends a 1289 unicast Router Advertisement to the MN. (Note: how about the 1290 parameters that are carried in a Prefix Option but are not present in 1291 the NetLMM Address Option? e.g., lifetimes?). In the Prefix Option 1292 sent to the MN the L flag MUST be unset and the A flag MUST be set or 1293 unset, depending on the possibility to perform stateless auto- 1294 configuration in the local domain. 1296 8.1.3.4. MN IP address notification procedure 1298 The NetLMM protocol specification is agnostic of how the IP address 1299 is assigned to the MN in the local domain. However, the MAG needs to 1300 know the IP address assigned or auto-configured by the MN in order to 1301 update the routing at the LMA. For this purpose, the MAG needs to 1302 play an active role in the DHCP exchange or needs to receive a 1303 trigger after the MN has configured an IP address via stateless auto- 1304 configuration. How this is done is described later in this section. 1306 As soon as the MAG knows that a specific IP address has been assigned 1307 to a MN, it MUST send a MN Address Setup message to the serving LMA, 1308 including three ID options (MN ID, MAG ID, LMA ID), a NetLMM Address 1309 option containing the address assigned to (or configured by) the MN. 1310 This message is a request to the LMA to start forwarding the packets 1311 destined to that IP address to the MAG. The MAG MAY also add the new 1312 IP address to the Routing Cache entry related to that MN. 1314 When it receives a MN Address Setup Acknowledgement message with 1315 Status 1 "SUCCESS", the MAG MUST add the new IP address to the 1316 Routing Cache entry of the MN (or set it as non tentative if 1317 previously updated) and update its forwarding state. In case the 1318 message contains a different Status value (Values 5 or 6), it MUST 1319 reject the assignment of the IP address to the MN, depending on the 1320 method used by the MN to request the address (i.e., DHCP or stateless 1321 auto-configuration). 1323 In case DHCP is used, the MAG MUST act as DHCP Relay Agent in order 1324 to have an active role in the DHCP exchange. The MAG then receives 1325 from the DHCP server the IP address assigned to the MN in a DHCP 1326 Relay-reply message and updates the routing at the LMA and at the 1327 same time can send a DHCP Reply message to the MN with the assigned 1328 address. It is important that in the DHCP-Relay-forward message, the 1329 MAG includes the identifier of the LMA that is in charge of serving 1330 that MN so that the DHCP server can select the IP address accordingly 1331 (i.e., from the IP subnet of the LMA). In case the MAG receives a MN 1332 Address Setup Acknowledgement message with Status 5 or 6, it MUST 1333 send a DHCP Reply message, refusing the IP address assignment to the 1334 MN. 1336 In case stateless auto-configuration is performed, the trigger to 1337 update the routing at the LMA is the DAD procedure. The DAD 1338 procedure is performed on the MAG link, but the MAG needs to verify 1339 the address uniqueness at the LMA; for this purpose, it sends the MN 1340 Address Setup message. If the LMA replies with a Status value equal 1341 to 5 or 6, the MAG MUST send a Neighbor Advertisement in order to 1342 fake an IP address duplication. 1344 8.1.3.5. MAG to MAG handover procedure 1346 When a MN hands over from one MAG to another, the new MAG may not 1347 know if the event occurred is a handover or a network attach. This 1348 is because the base protocol specified in this document is agnostic 1349 of any MAG to MAG communication that may be in place. Due to this 1350 reason, as for network attach, the MAG will just receive a trigger 1351 that a new MN has attached to the link; this trigger, referred as a 1352 MN_Access_Network API carries the MN ID and the LMA ID. As mentioned 1353 above, this API can be for example based on an AAA exchange. 1355 After receiving this API, the MAG performs the same procedure 1356 described for network access (see section Section 8.1.3.3): it sends 1357 a Location Registration message including three different ID options, 1358 containing the MN ID, the MAG ID and the LMA ID. 1360 In this handover handover case, the MAG does not receive immediately 1361 a Location Registration Acknowledgement message; instead it receives 1362 a Routing Setup message from the LMA that includes all IP addresses 1363 that are assigned to the MN. These addresses are included in one or 1364 more NetLMM Address options. The message contains also some 1365 forwarding state, based on the tunneling mechanism used. (Note: how 1366 the tunnel ID is carried in the message? Is it really needed at this 1367 step?). When the MAG receives this message, it MUST create a new 1368 entry in its Routing Cache for the specific MN and MUST update its 1369 forwarding state. In case no errors occur, the MAG sends back to the 1370 LMA a Routing Setup Acknowledgement message with Status value set to 1371 1 "SUCCESS" and including the forwarding state information. 1373 After that, the MAG receives the Location Registration 1374 Acknowledgement message that includes the NetLMM prefix to be 1375 delivered to the MN. The procedure is the same as described for 1376 network attach in section Section 8.1.3.3. 1378 8.1.3.6. Resource Revocation 1380 If the MAG receives a Location Deregistration message from the LMA, 1381 it MUST delete the entry related to the MN specified in the MN ID 1382 Option in its Routing Cache. Moreover, the MAG MUST remove any 1383 forwarding state for the MN. After doing that, the MAG MUST send a 1384 Location Deregistration Acknowledgement to the LMA with Status 1 1385 "SUCCESS". 1387 In case the Location Deregistration contains a Timer attribute (Note: 1388 it seems to me the Timer option has not been defined yet), the MAG 1389 MAY keep forwarding uplink packets to the LMA for the MN. This may 1390 be useful in case of make before break link layer technologies. The 1391 adopted timer cannot be greater than the one suggested by the LMA and 1392 MUST be sent back to the LMA in the Location Deregistration message 1393 acknowledgement. 1395 8.1.3.7. Network Detachment 1397 In case the MAG has an indication that the MN has detached from the 1398 network (e.g., via AAA architecture), the MAG MUST (Note: if the 1399 protocol is stateful and we do not have a lifetime in the location 1400 registration, this is a MUST, otherwise it can be a SHOULD) send a 1401 Location Deregistration message with an ID option including the MN 1402 ID. After receiving the Location Deregistration Acknowledgement, the 1403 MAG MUST remove any mobility and forwarding state in its Routing 1404 Cache related to that MN. 1406 8.1.3.8. IP address no longer in use 1408 In case the MAG has an indication that an IP address is no longer 1409 used by the MN, it MUST send a MN Address Remove message to the LMA, 1410 including the MN ID and the NetLMM Address that needs to be removed 1411 in a NetLMM Address option. How the MAG detects that an IP address 1412 is no longer used is out of the scope of this document. 1414 8.1.3.9. Link availability test 1416 MAGs should ensure availability of their link to LMAs. To test link 1417 availability, each MAG should periodically send a Heartbeat message 1418 to each LMA with which it has associated according to the entries in 1419 the LMA List. If the Heartbeat Ack message from the LMA is received 1420 within HEARTBEAT_TIMEOUT seconds, availability of the link to the LMA 1421 is proven. If the MAG does not receive the Heartbeat Ack message 1422 within HEARTBEAT_TIMEOUT seconds, the MAG should send 1423 HEARTBEAT_RETRY_MAX further Heartbeat messages with incremented 1424 sequence number. In case none of these Heartbeat messages is 1425 acknowledged by the LMA, the MAG should raise an alarm. Optionally, 1426 the MAG can inform an external OAM function about the broken link. 1428 To avoid superfluous bandwidth consumption, MAGs should send 1429 Heartbeat messages to an LMA only in case there was no traffic on the 1430 associated link for LINK_ACTIVITY_TIMEOUT seconds. MAGs should 1431 perform Heartbeat tests according to the following rule: 1433 In case there was no signaling activity on a link to an LMA for 1434 LINK_ACTIVITY_TIMEOUT seconds, the MAG waits for an additional random 1435 delay time between HEARTBEAT_DELAY_MIN and HEARTBEAT_DELAY_MAX 1436 seconds. After the delay has expired, the MAG sends the Heartbeat 1437 message to the LMA. In case the MAG receives a Heartbeat message 1438 from the LMA while waiting for the additional random delay, the MAG 1439 should reset the delay timer and refrain from sending the Heartbeat 1440 message, but MUST acknowledge the Heartbeat message using the same 1441 sequence number as in the received message. 1443 8.2. Local Mobility Anchor Operation 1445 8.2.1. Conceptual Data Structures 1447 Each LMA MUST maintain a NetLMM Routing Cache and a MAG List. 1449 Each LMA Routing Cache entry conceptually contains the following 1450 fields for each MN: 1452 * MN ID of the registered MN. This Identifier is learned through 1453 the Location Registration message, which registers an attached MN. 1454 Optionally, the MN ID is learned though the LMA Allocation message 1455 beforehand, which could enable service authorization for this 1456 particular MN ID at the LMA. 1458 * Routing Tag for the registered MN. Creating the entry and use of 1459 this tag is optional and might support identification of the MN in 1460 the data plane at the LMA and the MAG. In case the LMA and MAG 1461 specify asymmetric tags for the MN, this field MUST draw a 1462 distinction. 1464 * MAG ID of the registered MN's serving MAG. This identifier is 1465 learned through the Location Registration message, which registers 1466 an attached MN. Dependent on the context of this message, the MAG 1467 ID entry is either initialized or updated in case of the MN's 1468 handover. The MAG ID can be linked to the associated MAG's IP 1469 address With the help of the MAG List. 1471 * One or more global IP addresses of a registered MN. Each IP 1472 address is learned from an MN Address Setup message. According to 1473 the context of the received message, the IP address is set up, 1474 updated or removed from the Routing Cache. 1476 Each LMA MUST maintain a MAG List, which refers to associated MAG 1477 entities. The list of associated MAGs is used to perform heartbeat 1478 tests and to map the Routing Cache's MAG ID entries to the associated 1479 MAG's IP address(es). The MAG List also supports the procedure of 1480 bulk de-registrations at all or a subset of associated MAGs. 1482 The MAG List conceptually contains the following fields for each 1483 associated MAG: 1485 * MAG ID of the associated MAG. 1487 * One or more IP address(es) of the associated MAG. The MAG's IP 1488 address information is learned through the Associate message. 1490 * Forwarding capabilities of the associated MAG. This capability 1491 list is learned from a particular MAG through the Associate 1492 message. From the list of supported forwarding approaches, the 1493 LMA enters only these approaches to the capabilities, which are 1494 supported by the LMA. 1496 * Forwarding setting for the associated MAG. This field is needed 1497 in case the LMA configures a single forwarding approach per MAG 1498 association. 1500 * Capability list of the associated MAG. These capabilities are 1501 learned from a particular MAG through the Associate message. 1503 8.2.2. Processing NetLMM Headers 1505 All NetLMM local mobility anchors MUST observe the rules described in 1506 Section 8.1.2 when processing NetLMM Headers. 1508 8.2.3. Processing NetLMM Messages 1510 8.2.3.1. Associate Procedure 1512 When a LMA receives an Association Request message, it MUST look up 1513 into its MAG list based on the MAG identifier contained in the ID 1514 option included in the request. If an entry for that MAG ID is 1515 already present in the MAG list, the LMA MUST send an Associate Reply 1516 message to the MAG with STATUS 10 "Already Associated" (note: an 1517 alternative may be that the LMA silently discards the message) (note: 1518 another alternative is that the new association request is an 1519 association update, e.g., in order to propose a new forwarding 1520 method. I would keep things simple and not include this case, not 1521 allowing an Association Request if the MAG is already associated). 1523 If an entry for the MAG identifier contained in the ID option does 1524 not exist, the LMA MUST create it, including the parameters contained 1525 in the Association Request message (MAG ID, MAG IP address). Based 1526 on internal policy (e.g., pre-configuration) the LMA MAY accept the 1527 data forwarding method proposed by the MAG or MAY propose other 1528 methods in Access Reply. After creating the entry, the LMA MUST send 1529 an Associate Reply message with STATUS value 1 ("Success"), including 1530 its ID in an ID option. Optionally, it MAY include also a Data 1531 Transport Option included the data forwarding method to be used. 1532 (Note: don't we need a message ID in order to bind the request with 1533 the reply?) 1535 The Association Request message MUST include: 1537 * the LMA identifier included in a NetLMM ID option. This 1538 identifier is used by the peer to identify the LMA and is included 1539 in all subsequent messages. 1541 * the LMA's capabilities in terms of support of data transport 1542 methods included in a NetLMM Data Transport Option. The LMA MUST 1543 insert in this option all possible tunneling methods that can be 1544 used with the peer MAG Based on configuration, it is possible that 1545 some tunneling methods are used only with some MAGs: in this case, 1546 the Association Request message MUST contain only the tunneling 1547 methods that are administratively permitted with that specific 1548 MAG. 1550 8.2.3.2. Disassociate Procedure 1552 In case the Disassociate procedure is initiated by the MAG, when the 1553 LMA receives a Disassociation Request message, the LMA MUST validate 1554 it. If it is correct, it MUST delete the related entry in its MAG 1555 List and send a Disassociate Reply with Status 1 "SUCCESS". As in 1556 all NetLMM messages, the LMA MUST include the ID option with its 1557 identity. 1559 In case the Disassociate Procedure is initiated by the LMA the LMA 1560 MUST include an ID Option with the its identity in the Disassociation 1561 Request. When sending the Disassociation Request, the LMA MAY set 1562 the MAG entry related to the specific MAG as tentative. When it 1563 receives a Disassociation Reply with Status 1 "SUCCESS", the LMA MUST 1564 delete the correspondent entry in its MAG List. 1566 8.2.3.3. MN network access procedure 1568 When the local mobility anchor receives a Location Registration 1569 message, it MUST validate it (note: what does it mean? should it 1570 check if the MAG ID in the message is in the MAG List). If the 1571 message is valid, it MUST check if an entry for the MN identifier 1572 included in the Location Registration is present. If an entry is 1573 already present, it means that a MAG to MAG handover has occurred: 1574 the detailed procedure for this event is described in 1575 Section 8.2.3.5. 1577 If an entry for that MN identifier is not present, the LMA MUST 1578 create a new entry with the MN ID, the MAG ID (?) and the MAG IP 1579 address (?). (Note: the two latter parameters are not present in the 1580 Routing Cache description. How the protocol works without them?). 1581 After creating the entry, it MUST send a Location Registration 1582 Acknowledgement with STATUS 1, including three ID options (MN ID, LMA 1583 ID, MAG ID) and the NetLMM prefix in a NetLMM Address option. The 1584 NetLMM prefix is then forwarded in a Router Advertisement to the MN 1585 by the MAG and used by the MN to auto-configure an IP address using 1586 stateless auto-configuration and/or to detect a change of local 1587 domain. 1589 In case the Location Registration is not valid or the registration 1590 procedure cannot be completed successfully, the LMA MUST send a 1591 Location Registration Acknowledgement with an appropriate Status 1592 value. 1594 8.2.3.4. MN IP address notification procedure 1596 When the MN tries to configure a new IP address on the local domain, 1597 the local mobility anchor receives a MN Address Setup message from 1598 the MAG which the MN is connected to. This message contains the IP 1599 address the MN is trying to configure in a NetLMM Address option. 1600 (Note: in the slides there is also a tunnel ID but I am not sure this 1601 is actually needed). 1603 When it receives this message, the LMA MUST check if the IP address 1604 in the NetLMM Address option is already assigned to another MN. If 1605 the address is a duplicated one, it MUST send a MN Address Setup 1606 Acknowledgement message with Status 5 "INVALID IP ADDRESS". If the 1607 address is not assigned to any other MN, the LMA MUST check if the 1608 number of addresses assigned to that MN does not exceed the maximum 1609 number of addresses that the MN can configure. This check is 1610 performed in the LMA Routing Cache; the maximum number of allowed IP 1611 addresses is a per MN variable that is pre-configured at the LMA. If 1612 the number of IP addresses exceeds the allowed one, the LMA MUST send 1613 a MN Address Setup Acknowledgement message with Status 6 "OVER IP 1614 ADDRESS LIMIT". (Note: the first check is mainly performed for the 1615 stateless configuration case and may be skipped in case DHCP is used. 1616 However the LMA does not know if the address is configured using DHCP 1617 or stateless so I would keep this check in any case) 1619 If the IP address is not a duplicated one and the maximum number of 1620 allowed IP addresses is not reached, the LMA MUST update the Routing 1621 Cache entry indexed by the MN ID contained in the MN Address Setup 1622 message with the new IP address and MUST update its forwarding state, 1623 depending on the tunneling mechanism used. 1625 8.2.3.5. MAG to MAG handover procedure 1627 When the LMA receives a Location Registration message, it MUST check 1628 in its Routing Cache if an entry for the MN ID carried in the message 1629 is already present. If it is not, that means that the MN is 1630 accessing the network for the first time (see section 1631 Section 8.2.3.3). If an entry is already present in the Routing 1632 Cache, a handover has occurred. In this case the LMA MUST send a 1633 Routing Setup message to the MAG, including three ID options (MN ID, 1634 MAG ID, LMA ID), one or more NetLMM Address options containing all 1635 NetLMM addresses configured to the MN and some forwarding state 1636 information that depends on the tunneling method used (e.g., tunnel 1637 ID).(Note: what it the behavior of the LMA during this time interval 1638 when packets arrive? Should it already update the Routing Cache 1639 entry or should it wait for an ack?) 1640 After that the LMA receives a Routing Setup Acknowledgement message; 1641 if the Status of this message is set to SUCCESS, the LMA MUST update 1642 the Routing Cache with the new location of the MN, updating the MAG 1643 ID. The LMA MUST then send back to the MAG a Location Registration 1644 Acknowledgement message with Status value set to 1 "SUCCESS", 1645 including in a NetLMM Address option the NetLMM prefix to be sent to 1646 the MN. 1648 8.2.3.6. Resource Revocation 1650 There are case (e.g. due to administrative reasons) where the 1651 forwarding state of a specific MN must be purged so that the MN is no 1652 more able to use the resources provided by the network. In this 1653 case, based on a trigger received from the network (e.g. AAA), the 1654 LMA MUST send a Location Deregistration message to the peer MAG, 1655 including the MN ID, the LMA ID and the MAG ID. Optionally, the LMA 1656 MAY include a Timer attribute specifying the remaining time to keep 1657 the state of the MN in the MAG. The revocation procedure terminates 1658 when the LMA receives a Resource Revocation Acknowledgement with 1659 Status 1. 1661 8.2.3.7. Network Detachment 1663 When the LMA receives a Location Deregistration message from the peer 1664 MAG, it MUST remove in its Routing Cache the entry of the MN 1665 indicated by the MN ID in the Location Deregistration message. After 1666 that, it MUST send a Location Deregistration Acknowledgement with 1667 Status 1, including the MN ID, the MAG ID and the LMA ID. 1669 8.2.3.8. IP address no longer in use 1671 When the LMA receives a MN Address Remove message, it MUST remove the 1672 NetLMM Address included in the NETLMM Address option from the entry 1673 in its Routing Cache related to the MN indicated in the message. 1674 After that, the LMA MUST respond with a MN Address Remove 1675 Acknowledgement with Status 1. 1677 8.2.3.9. Link availability test 1679 LMAs should ensure availability of their link to MAGs. To test link 1680 availability, each LMA should periodically send a Heartbeat message 1681 to each associated MAG according to the entries in the MAG List. If 1682 the Heartbeat Ack message from the MAG is received within 1683 HEARTBEAT_TIMEOUT seconds, availability of the link to the MAG is 1684 proven. If the LMA does not receive the Heartbeat Ack message within 1685 HEARTBEAT_TIMEOUT seconds, the LMA should send HEARTBEAT_RETRY_MAX 1686 further Heartbeat messages with incremented sequence number. In case 1687 none of these Heartbeat messages is acknowledged by the MAG, the LMA 1688 should raise an alarm. Optionally, the LMA can inform an external 1689 OAM function about the broken link. 1691 To avoid superfluous bandwidth consumption, LMAs should send 1692 Heartbeat messages to a MAG only in case there was no traffic on the 1693 associated link for LINK_ACTIVITY_TIMEOUT seconds. LMAs should 1694 perform Heartbeat tests according to the following rule: 1696 In case there was no signaling activity on a link to a MAG for 1697 LINK_ACTIVITY_TIMEOUT seconds, the LMA waits for an additional random 1698 delay time between HEARTBEAT_DELAY_MIN and HEARTBEAT_DELAY_MAX 1699 seconds. After the delay has expired, the LMA sends the Heartbeat 1700 message to the MAG. In case the LMA receives a Heartbeat message 1701 from a MAG while waiting for the additional random delay, the LMA 1702 should reset the delay timer and refrain from sending the Heartbeat 1703 message, but MUST acknowledge the Heartbeat message using the same 1704 sequence number as in the received message. 1706 9. Data Transport 1708 As soon as a particular MAG has associated with an LMA and an 1709 attached MN has been registered with the LMA, the LMA node and the 1710 MAG node are responsible for forwarding the MN's data traffic 1711 correctly within the NetLMM domain. Associated location and 1712 forwarding information is maintained within the LMA's and the MAG's 1713 Routing Cache. Different forwarding mechanisms between the LMA node 1714 and a particular MAG node might be supported and set up during the 1715 MAG's association procedure. 1717 Network entities, which have Version 0 of the NetLMM protocol 1718 implemented, MUST support IPv6-in-IPv6 encapsulation to tunnel data 1719 packets between an LMA node and an associated MAG node. Support of 1720 other forwarding approaches are for future extensions. 1722 9.1. Forwarding of Unicast Data Packets 1724 9.1.1. Handling of hop limit field in IPv6 data packets 1726 According to the NetLMM default mechanism to forward data packets 1727 between a particular LMA and MAG by means of encapsulation, LMA nodes 1728 and MAG nodes serve as tunnel entry-points and tunnel exit-points 1729 respectively. LMAs and MAGs have to decrement the hop limit field of 1730 the encapsulated IPv6 header properly. The MAG serves as the default 1731 gateway for an attached MN and forwards all packets from the MN into 1732 the tunnel, which in turn encapsulates the packet towards the LMA. 1733 The LMA on receiving the packet from the MAG decapsulates and 1734 forwards the packet using normal forwarding procedures. The packets 1735 destined towards the MN are forwarded in a similar fashion. The 1736 procedure of forwarding the packet decrements the hop limit. Hence, 1737 the hop limit will get decremented twice for any packet traversing 1738 the tunnel between LMA and MAG. 1740 9.1.2. IPv6-in-IPv6 tunnel 1742 LMA and MAG nodes MUST support IPv6-in-IPv6 encapsulation to forward 1743 packets within the NetLMM domain. Support of other forwarding 1744 schemes is optional. When an LMA node receives an IPv6 packet 1745 destined for a registered MN and IPv6-in-IPv6 tunneling has been 1746 selected as forwarding approach, it serves as tunnel entry-point. 1747 The LMA node decrements the hop limit of the data packet's IPv6 1748 header by one and encapsulates the packet in the tunnel IPv6 header. 1749 The tunnel IPv6 header might carry one or more extension headers. 1750 The LMA node forwards the tunnel packet to the MAG node, using its 1751 own address as source address and the MAG node's address as 1752 destination address in the outer IPv6 header. The MAG node 1753 terminates the tunnel and MUST process relevant Extension Headers, 1754 which might follow the encapsulating IPv6 header. The MAG node 1755 forwards the data packet towards the MN after decapsulation. 1757 To forward uplink packets, the MAG node serves as tunnel entry-point 1758 and decrements the data packet's hop limit field by one before it 1759 encapsulates the packet in the tunnel IPv6 header. The tunnel IPv6 1760 header might carry one or more extension headers. The MAG node 1761 forwards the tunnel packet to the LMA node, using its own address as 1762 source address and the LMA node's address as destination address in 1763 the outer IPv6 header. The LMA node terminates the tunnel and MUST 1764 process relevant Extension Headers, which might follow the 1765 encapsulating IPv6 header. The LMA node forwards the data packet 1766 towards its final destination after decapsulation. 1768 9.1.3. Future extensions 1770 Future extensions might support other approaches to forward data 1771 packets between LMA and MAG nodes. Such extensions could include 1772 IPv4-in-IPv6 encapsulation to forward IPv4 data packets of dual stack 1773 hosts within the NetLMM domain. Operators might prefer the use of 1774 other flexible forwarding approaches, such as Generic Routing 1775 Encapsulation (GRE) [RFC2784] or Multi-Protocol Label Switching 1776 (MPLS), and follow [RFC3031] and associated mechanisms to forward 1777 data packets between LMA and MAG nodes. Details about the use of 1778 such extensions are out of scope of this specification. 1780 For now, some suggestions of how GRE tunnelling could be used with 1781 NetLMM can be found in Appendix B, and similarly use with MPLS is 1782 described in Appendix C. 1784 9.2. Forwarding of Multicast Data Packets 1786 9.2.1. Link Local Multicast 1788 The scope of link local multicast packets is confined to the link 1789 between MNs and the associated MAG node. MAG nodes process but do 1790 not forward link local multicast packets. To support some functions, 1791 such as for Duplicate Address Detection (DAD), MAGs might proxy 1792 associated Neighbor Discovery messages to perform DAD procedure with 1793 LMA nodes. 1795 9.2.2. IP Multicast 1797 Three options have been identified to support IP multicast within a 1798 NetLMM domain. 1800 Option 1 implies that MAG nodes are multicast-enabled routers and 1801 support for IP multicast is orthogonal to the NetLMM protocol 1802 operation. According to native multicast support, access routers 1803 terminate a multicast tree and the LMA node does not play any 1804 multicast-specific role in forwarding of IP multicast traffic. 1806 Option 2 implies that MAG nodes are multicast-enabled routers and 1807 IP multicast traffic is tunnelled via the NetLMM domain's LMA 1808 nodes. 1810 Option 3 implies that an NetLMM domain's LMA nodes are multicast- 1811 enabled routers. LMA nodes join a multicast-tree and forward IP 1812 multicast packets to MAG nodes according to the selected 1813 forwarding approach. MAG nodes must coordinate multicast 1814 listeners according to IGMP operation [RFC3376] and communicate 1815 with LMA nodes using PIM control messages [RFC2362] to control IP 1816 multicast forwarding path between LMA nodes and respective MAG 1817 nodes, which have multicast listeners attached. LMA nodes 1818 coordinate multicast listener registration with other multicast 1819 routers, which are outside of an NetLMM domain, by means of PIM 1820 control messages. An exemplary IP multicast join procedure is 1821 illustrated in Fig. *MCJOIN* 1823 The specification of default operation for IP multicast support and 1824 optional enhancements is for further study and t.b.d. 1826 +--+ +---+ +---+ +--+ 1827 |MN| |MAG| |LMA| |MR| 1828 +--+ +---+ +---+ +--+ 1829 | | | | 1830 | | | | 1831 |----IGMP---->| | | 1832 | |----PIM Join--->| | 1833 | | |----PIM Join----->| 1834 / / / / 1835 / / / / 1836 |<------------|<===============|<-----------------|<--MC Data 1837 | | | forward to group | 1838 |-- MC Data-->|===============>|----------------->|--> 1840 Figure *MCJOIN*: IP multicast join procedure for the case that LMA 1841 nodes and MAG nodes are multicast routers. 1843 9.3. Forwarding of Broadcast Data Packets 1845 Version 0 of the NetLMM protocol specification does not consider 1846 forwarding of broadcast data packets. 1848 10. Protocol Constants and Configuration Variables 1850 11. Security Considerations 1852 The NetLMM protocol is executed between the MAG and LMA. The 1853 messages are used to create, update and delete mobility state in MAG 1854 and LMA. If the NetLMM signalling messages are not authenticated, 1855 following attacks are possible. 1857 * A malicious node can pretend to be MAG and associate with the LMA. 1858 This in itself may not create any harm if subsequent messages are 1859 authenticated. But it does allow for the attacker to learn the 1860 capabilities of the LMA which in turn may be used to exploit the 1861 specific weaknesses. 1863 * A malicious node can pretend to be MAG and send a location 1864 registration message to LMA. There are a couple of variants of 1865 this attack. 1867 - The MN is currently attached to MAG-1 and the IP address of the 1868 MN is known. A malicious node MAG-2 sends the location 1869 registration message to redirect all the traffic destined for 1870 the MN to itself. This enables the attacker to steal the MN's 1871 traffic. This attack may be detected by MAG-1 when it receives 1872 the location de-registration message from LMA while the MN is 1873 still attached. The detection of the attack depends on the 1874 security of mechanism used to detect the MN's attachment. 1876 - The MN is currently attached to MAG-1 and the IP address of the 1877 MN is not known. A malicious node MAG-2 sends the location 1878 registration message to redirect all the traffic destined for 1879 the MN to itself. The LMA would update the mobility state for 1880 MN with the ID of MAG-2. Later when the MN-address-setup 1881 messages comes from MAG-1, it would fail because the MAG IDs 1882 don't match. 1884 * A malicious man-in-the-middle node can alter the messages sent 1885 between MAG and LMA that can result in random attacks. For 1886 example, the attacker can modify the MN Identifier in the location 1887 registration message of MN-1 to that of MN-2. When MN-2 moves to 1888 a new link, it results in a new location registration message to 1889 be sent with MN-2 ID. This will cause the traffic destined to 1890 MN-1 address to be destined to the current link causing disruption 1891 for both MN-1 and MN-2. 1893 These attacks can be prevented by providing data origin 1894 authentication for the messages exchanged between LMA and MAG. This 1895 can be achieved by using IPsec ESP [RFC4303] with null-encryption and 1896 non-null authentication between MAG and LMA. 1898 It is possible to filter the signalling messages at the edge of the 1899 network so that a rogue MN or rogue node on the Internet cannot 1900 source such messages. Hence, any messages exchanged between the MAG 1901 and LMA can only come from within the network. This level of 1902 security may be sufficient for some deployments precluding the need 1903 for protecting the signalling messages. In such cases, IPsec may not 1904 be used to protect the signalling messages. 1906 Anomalous events should be logged. For example, once an address is 1907 assigned to the Mobile node, MN address setup message should appear 1908 at the LMA sooner or later. If it does not appear within a certain 1909 period of time, it should be considered as an error and logged. 1910 [TBD: May be document more of such events]. 1912 NetLMM messages are triggered by MN attachment and detachment to the 1913 MAG. The threats specific to MN-MAG interface are discussed in 1914 [I-D.ietf-netlmm-threats]. When neighbor discovery messages 1915 [I-D.ietf-ipv6-2461bis] are used as triggers, it should be secured 1916 using [RFC3971]. 1918 12. IANA Considerations 1920 13. Contributors 1922 This contribution is a joint effort of the NetLMM design team of the 1923 NetLMM WG. The members include Kent Leung, Gerardo Giaretta, Phil 1924 Roberts, Marco Liebsch, Katsutoshi Nishida, Hidetoshi Yokota, Henrik 1925 Levkowetz, and Mohan Parthasarathy. 1927 14. Acknowledgments 1929 15. References 1931 15.1. Normative References 1933 [I-D.ietf-ipv6-2461bis] 1934 Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", 1935 draft-ietf-ipv6-2461bis-07 (work in progress), May 2006. 1937 [I-D.ietf-netlmm-nohost-ps] 1938 Kempf, J., "Problem Statement for Network-based Localized 1939 Mobility Management", draft-ietf-netlmm-nohost-ps-04 (work 1940 in progress), June 2006. 1942 [I-D.ietf-netlmm-nohost-req] 1943 Kempf, J., "Goals for Network-based Localized Mobility 1944 Management (NETLMM)", draft-ietf-netlmm-nohost-req-01 1945 (work in progress), April 2006. 1947 [I-D.ietf-netlmm-threats] 1948 Kempf, J. and C. Vogt, "Security Threats to Network-based 1949 Localized Mobility Management", 1950 draft-ietf-netlmm-threats-00 (work in progress), 1951 April 2006. 1953 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1954 August 1980. 1956 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1957 Requirement Levels", BCP 14, RFC 2119, March 1997. 1959 [RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, 1960 S., Handley, M., and V. Jacobson, "Protocol Independent 1961 Multicast-Sparse Mode (PIM-SM): Protocol Specification", 1962 RFC 2362, June 1998. 1964 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 1965 Schoenwaelder, Ed., "Structure of Management Information 1966 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 1968 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1969 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1970 March 2000. 1972 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1973 Label Switching Architecture", RFC 3031, January 2001. 1975 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1976 Thyagarajan, "Internet Group Management Protocol, Version 1977 3", RFC 3376, October 2002. 1979 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1980 RFC 3753, June 2004. 1982 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1983 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1985 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 1986 Network Access Identifier", RFC 4282, December 2005. 1988 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1989 RFC 4303, December 2005. 1991 [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 1992 for IPv4, IPv6 and OSI", RFC 4330, January 2006. 1994 15.2. Informative References 1996 [ENTERPRISE-NUM] 1997 IANA, "IANA Enterprise Numbers Registry"", 2006. 1999 [RFC4064] Patel, A. and K. Leung, "Experimental Message, Extensions, 2000 and Error Codes for Mobile IPv4", RFC 4064, May 2005. 2002 Appendix A. TODO (Things that remain to be specified...) 2004 This is a short list of things that remain to be specified in future 2005 revisions of this document: 2007 * Describe the re-send mechanism for control messages, in order to 2008 provide reliable delivery. 2010 * Add an "LMA Announce message" which can be multicast from a newly 2011 connected LMA to trigger listening MAGs to send it Association 2012 Requests. 2014 * Add the capability to do bulk MN de-registrations and possibly 2015 registrations. 2017 * A review to ensure that all aspects of the protocol permits 2018 operation with both single /128 addresses and for instance /64 2019 prefix allocations to mobile nodes. 2021 * Add reserved status ranges (Section 7.1.1) for vendor-specific 2022 status, LMA status?, MAG status?. 2024 * Add experimental message, option and status values, in accordance 2025 with [RFC4064]. 2027 * Add a Heartbeat Sequence Number Option, to hold heartbeat-specific 2028 sequence numbers needed by algorithms for reacting to missed 2029 heartbeats. Write up suggested algorithm. 2031 * Make sure the use of the identity / locator split paradigm is 2032 consistent and workable throughout the document. Cover resolution 2033 of ID to locator. 2035 * Define how capability exchanges are handled, and how a unique 2036 common capability is derived, for instance to find the tunnelling 2037 method to be used as a result of the Association Request and 2038 Reply. 2040 * Add message and signalling optimization according to Section 5.12. 2042 * Maybe change the range-based skippable or non-skippable nature of 2043 Options to be indicated by a bit instead? 2045 * Point out somewhere that although a NetLMM Domain may have 2046 multiple LMAs, a MN is always served by the same LMA once an LMA 2047 has been assigned. 2049 * 2051 Appendix B. Using GRE Tunnels with NetLMM 2053 ** Text to be written ** 2055 Appendix C. Using MPLS with NetLMM 2057 ** Text to be written ** 2059 Appendix D. TTL Handling 2061 ** Text to be written ** 2063 Appendix E. MN-AR Interface considerations 2065 This document assumes that the MN-AR interface document will describe 2066 the following in more detail: 2068 * - A mechanism for indicating duplicate address to the MN 2070 * - No redirects should be sent by MAG to MN even if the destination 2071 is directly connected to MAG 2073 * - Trigger for IP address configuration 2075 * - MN Identifier option in the trigger ? 2077 * - If SEND is used, Proxy SEND details are needed for defending the 2078 address in the case of a duplicate 2080 * - Router advertisement details : unicast only, what else does it 2081 contain etc." 2083 Appendix F. Out of scope 2085 - Inter-MAP handover - Fast handover - Hierarchical MAP 2087 Authors' Addresses 2089 Gerardo Giaretta 2090 Telecom Italia 2091 via Reiss Romoli 274 2092 Torino 10148 2093 Italy 2095 Phone: +39 011 228 6904 2096 Email: gerardo.giaretta@telecomitalia.it 2098 Kent Leung 2099 Cisco 2100 170 W. Tasman Drive 2101 San Jose, CA 95134 2102 USA 2104 Phone: +1 408 853 9580 2105 Email: kleung@cisco.com 2107 Marco Liebsch 2108 NEC Network Laboratories 2109 Kurfuersten-Anlage 36 2110 Heidelberg, 69115 2111 Germany 2113 Phone: +49 6221-90511-46 2114 Email: marco.liebsch@netlab.nec.de 2116 Phil Roberts 2117 Motorola 2118 1301 E Algonquin Rd 2119 Schaumberg, IL 60196 2120 USA 2122 Email: phil.roberts@motorola.com 2123 Katsutoshi Nishida 2124 NTT DoCoMo Inc. 2125 3-5 Hikarino-oka, Yokosuka-shi 2126 Kanagawa, 2127 Japan 2129 Phone: +81 46 840 3545 2130 Email: nishidak@nttdocomo.co.jp 2132 Hidetoshi Yokota 2133 KDDI R&D Laboratories, Inc. 2134 2-1-15 Ohara, Fujimino 2135 Saitama, 356-8502 2136 Japan 2138 Phone: +81 49 278 7894 2139 Email: yokota@kddilabs.jp 2141 Mohan Parthasarathy 2142 Nokia 2144 Email: mohan.parthasarathy@nokia.com 2146 Henrik Levkowetz 2147 Ericsson 2148 Torsgatan 71 2149 Stockholm S-113 37 2150 SWEDEN 2152 Phone: +46 708 32 16 08 2153 Email: henrik@levkowetz.com 2155 Intellectual Property Statement 2157 The IETF takes no position regarding the validity or scope of any 2158 Intellectual Property Rights or other rights that might be claimed to 2159 pertain to the implementation or use of the technology described in 2160 this document or the extent to which any license under such rights 2161 might or might not be available; nor does it represent that it has 2162 made any independent effort to identify any such rights. Information 2163 on the procedures with respect to rights in RFC documents can be 2164 found in BCP 78 and BCP 79. 2166 Copies of IPR disclosures made to the IETF Secretariat and any 2167 assurances of licenses to be made available, or the result of an 2168 attempt made to obtain a general license or permission for the use of 2169 such proprietary rights by implementers or users of this 2170 specification can be obtained from the IETF on-line IPR repository at 2171 http://www.ietf.org/ipr. 2173 The IETF invites any interested party to bring to its attention any 2174 copyrights, patents or patent applications, or other proprietary 2175 rights that may cover technology that may be required to implement 2176 this standard. Please address the information to the IETF at 2177 ietf-ipr@ietf.org. 2179 Disclaimer of Validity 2181 This document and the information contained herein are provided on an 2182 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2183 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2184 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2185 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2186 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2187 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2189 Copyright Statement 2191 Copyright (C) The Internet Society (2006). This document is subject 2192 to the rights, licenses and restrictions contained in BCP 78, and 2193 except as set forth therein, the authors retain all their rights. 2195 Acknowledgment 2197 Funding for the RFC Editor function is currently provided by the 2198 Internet Society.