idnits 2.17.1 draft-giaretta-netlmm-dt-protocol-02.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 2673. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2650. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2657. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2663. ** 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: For each retransmission, the NetLMM entity should set the new RTO value to twice the previous RTO duration (e.g. new_RTO = 2 * previous_RTO). The RTO value SHOULD not exceed the limit of RTO_MAX seconds. The value for RTO_INIT and RTO_MAX should be configurable, with a resolution better than 1 second (such as 1 ms, for instance). -- 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 (October 5, 2006) is 6403 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) == Unused Reference: 'I-D.ietf-netlmm-nohost-ps' is defined on line 2405, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netlmm-threats' is defined on line 2415, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pki4ipsec-ikecert-profile' is defined on line 2470, but no explicit reference was found in the text == Unused Reference: 'I-D.thaler-intarea-multilink-subnet-issues' is defined on line 2476, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-netlmm-mn-ar-if-01 ** Downref: Normative reference to an Informational draft: draft-ietf-netlmm-mn-ar-if (ref. 'I-D.ietf-netlmm-mn-ar-if') ** 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-04 ** Downref: Normative reference to an Informational draft: draft-ietf-netlmm-nohost-req (ref. 'I-D.ietf-netlmm-nohost-req') ** Downref: Normative reference to an Informational draft: draft-ietf-netlmm-threats (ref. 'I-D.ietf-netlmm-threats') ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Downref: Normative reference to an Informational RFC: RFC 3753 ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 4330 (Obsoleted by RFC 5905) == Outdated reference: A later version (-12) exists of draft-ietf-pki4ipsec-ikecert-profile-11 -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) Summary: 13 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NetLMM H. Levkowetz, Ed. 3 Internet-Draft Ericsson 4 Expires: April 8, 2007 G. Giaretta 5 Telecom Italia 6 K. Leung 7 Cisco 8 M. Liebsch 9 NEC 10 P. Roberts 11 Motorola 12 K. Nishida 13 NTT DoCoMo Inc. 14 H. Yokota 15 KDDI Labs 16 M. Parthasarathy 17 Nokia 18 October 5, 2006 20 The NetLMM Protocol 21 draft-giaretta-netlmm-dt-protocol-02 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 April 8, 2007. 48 Copyright Notice 49 Copyright (C) The Internet Society (2006). 51 Abstract 53 This document specifies an Internet protocol that allows mobile nodes 54 to move around in a local mobility domain, changing their point of 55 attachment within the domain, but without ever being aware at the IP 56 layer that their point of attachment has changed, and maintaining 57 seamless communication in the presence of such changes. It defines 58 two protocol entities, a Mobile Access Gateway and a Local Mobility 59 Anchor, and a set of messages between them, that together make these 60 mobility events transparent to the mobile nodes at the IP layer, as 61 long as they remain within the local mobility domain. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3. Functional Entities . . . . . . . . . . . . . . . . . . . . . 7 68 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 69 4.1. Mobility Management . . . . . . . . . . . . . . . . . . 9 70 4.2. Setup and Node Association . . . . . . . . . . . . . . . 12 71 4.3. Message Transport . . . . . . . . . . . . . . . . . . . 13 72 4.4. Identity - Locator Split . . . . . . . . . . . . . . . . 16 73 4.5. Handling of Link-Local Addresses . . . . . . . . . . . . 16 74 5. Message Format and Message Types . . . . . . . . . . . . . . . 17 75 5.1. Message Format . . . . . . . . . . . . . . . . . . . . . 17 76 5.2. Location Registration . . . . . . . . . . . . . . . . . 19 77 5.3. Location Deregistration . . . . . . . . . . . . . . . . 20 78 5.4. Association Request . . . . . . . . . . . . . . . . . . 20 79 5.5. Disassociation Request . . . . . . . . . . . . . . . . . 21 80 5.6. Heartbeat . . . . . . . . . . . . . . . . . . . . . . . 21 81 5.7. Acknowledgements . . . . . . . . . . . . . . . . . . . . 23 82 5.8. Message Status Codes . . . . . . . . . . . . . . . . . . 23 83 6. Option Format and Option Types . . . . . . . . . . . . . . . . 25 84 6.1. Option Format . . . . . . . . . . . . . . . . . . . . . 25 85 6.2. Option Alignment . . . . . . . . . . . . . . . . . . . . 26 86 6.3. ID Option . . . . . . . . . . . . . . . . . . . . . . . 27 87 6.4. Handle Option . . . . . . . . . . . . . . . . . . . . . 28 88 6.5. Prefix Allocation Option . . . . . . . . . . . . . . . . 30 89 6.6. Prefix Delegation Option . . . . . . . . . . . . . . . . 31 90 6.7. Data Transport Option . . . . . . . . . . . . . . . . . 33 91 6.8. Deregistration Timeout Option . . . . . . . . . . . . . 34 92 6.9. Timestamp Option . . . . . . . . . . . . . . . . . . . . 35 93 6.10. Vendor-Specific Option . . . . . . . . . . . . . . . . . 36 94 6.11. Registration Lifetime Option . . . . . . . . . . . . . . 37 95 6.12. Status Option . . . . . . . . . . . . . . . . . . . . . 38 97 7. Protocol Specification . . . . . . . . . . . . . . . . . . . . 38 98 7.1. Mobile Access Gateway Operation . . . . . . . . . . . . 38 99 7.2. Local Mobility Anchor Operation . . . . . . . . . . . . 43 100 8. Data Transport . . . . . . . . . . . . . . . . . . . . . . . . 48 101 8.1. Forwarding of Unicast Data Packets . . . . . . . . . . . 48 102 8.2. Forwarding of Multicast Data Packets . . . . . . . . . . 49 103 8.3. Forwarding of Broadcast Data Packets . . . . . . . . . . 51 104 9. Protocol Constants and Configuration Variables . . . . . . . . 51 105 10. Security Considerations . . . . . . . . . . . . . . . . . . . 51 106 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 107 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 53 108 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54 109 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 110 14.1. Normative References . . . . . . . . . . . . . . . . . . 54 111 14.2. Informative References . . . . . . . . . . . . . . . . . 55 112 Appendix A. MN-AR Interface considerations . . . . . . . . . . . 56 113 Appendix B. Issues with omitting the MN Address Setup and 114 Routing Setup . . . . . . . . . . . . . . . . . . . . 56 115 Appendix C. Out of scope . . . . . . . . . . . . . . . . . . . . 57 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58 117 Intellectual Property and Copyright Statements . . . . . . . . . . 60 119 1. Introduction 121 This document specifies a protocol that allows nodes to move around 122 in an access network, attaching to various points of the network 123 while maintaining an IP layer configuration that does not change as 124 the mobile nodes' points of attachment change. 126 This protocol is not intended to solve all the problems of network- 127 based IP mobility. Over the past decade many companies and forums 128 have provided many, many staff years of research, development, and 129 standardization to realize all IP mobile networks and no doubt many 130 more years of effort are ahead to deliver improvements to realize all 131 the envisioned usage of such technology. Such systems have added 132 technology for specific link layers, and carrying IP packets over 133 those link layers, support for AAA infrastructures, and mobile 134 security to name a few. Challenges still lie ahead in the form of 135 for instance mobile QoS, power management and paging, and management 136 of changing network conditions in the face of various mobility 137 events. 139 The protocol described in this memo is developed in response to the 140 problem statement for network-based localized mobility [I-D.ietf- 141 netlmm-nohost-ps] and attempts to satisfy the goals in the NetLMM 142 goals document [I-D.ietf-netlmm-nohost-req]. It is intended 143 basically to solve the problem of packet forwarding to nodes that 144 change their point of attachment to the network without the use of 145 any protocol support at the IP layer on the mobile node to support 146 that mobility. 148 This document defines operation of the protocol for use in an IPv6 149 infrastructure and in support of IPv6 nodes, but the authors envision 150 that with modifications the protocol could be used with an IPv4 151 infrastructure or to support IPv4 nodes. The document refers 152 conscientiously to mobile nodes rather than mobile hosts because its 153 operation is not limited in any way to host only support. 155 This protocol has both some similarities and some clear differences 156 with various IP mobility protocols the IETF has standardized in the 157 past. It is similar in that it continues the tradition of 158 maintaining address continuity to mobile nodes regardless of the fact 159 that those nodes have changed their points of attachment in the 160 network. It differs in that it does not require any operational 161 changes in protocol operation between the mobile node and the network 162 at the IP layer, in that it supports an infrastructure that embraces 163 network controlled mobility operation, and in that its operation is 164 limited in scope rather than globally applicable. 166 The differences between this protocol and previous mobility protocols 167 are complementary rather than contradictory. It is quite possible to 168 conceive of deployments in which mobile IP is used in a wide area to 169 provide mobility services across multiple interface types or separate 170 local mobility domains while NetLMM is used within a single type of 171 access network or a single local mobility domain to facilitate 172 mobility without involving the mobile. 174 2. Terminology 176 In this document, several words are used to signify the requirements 177 of the specification. These words are often capitalized. The key 178 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 179 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 180 are to be interpreted as described in [RFC2119]. 182 Mobility terminology in this document follows that in RFC 3753, 183 "Mobility Related Terminology" [RFC3753], with the added 184 specification of some terms as they are used in this particular 185 document: 187 IP Link 188 A set of routers, mobile nodes, and wireless access points that 189 share link broadcast capability or its functional equivalent. 190 This definition covers one or multiple access points under one or 191 several access routers. In the past, such a set has been called a 192 subnet, but this term is not strictly correct for IPv6, since 193 multiple subnet prefixes can be assigned to an IP link in IPv6. 195 Access Network (revised) 196 An Access Network consists of following three components: wireless 197 or other access points, access routers, access network gateways 198 which form the boundary to other networks and may shield other 199 networks from the specialized routing protocols (if any) run in 200 the Access Network; and (optionally) other internal access network 201 routers which may also be needed in some cases to achieve a 202 specialized routing protocol. 204 Local Mobility (revised) 205 Local Mobility is mobility over a restricted area of the network 206 topology. Note that, although the area of network topology over 207 which the mobile node moves may be restricted, the actual 208 geographic area could be quite large, depending on the mapping 209 between the network topology and the wireless coverage area. 211 Localized Mobility Management 212 Localized Mobility Management is a generic term for protocols 213 dealing with IP mobility management confined within the access 214 network. Localized Mobility Management signaling is not routed 215 outside the access network, although a handover may trigger Global 216 Mobility Management signaling. Localized Mobility Management 217 protocols exploit the locality of movement by confining movement 218 related changes to the access network. 220 Localized Mobility Management Protocol 221 A protocol that supports localized mobility management. 223 Intra-Link Mobility 224 Intra-Link Mobility is mobility between wireless access points 225 within an IP Link. Typically, this kind of mobility only involves 226 Layer 2 mechanisms, so Intra-Link Mobility is often called Layer 2 227 mobility. No IP link configuration is required upon movement 228 since the link does not change, but some IP signaling may be 229 required for the mobile node to confirm whether or not the change 230 of wireless access point also resulted in a change of IP link. If 231 the IP link consists of a single access point/router combination, 232 then this type of mobility is typically absent. 234 Mobile Access Gateway (MAG) 235 A Mobile Access Gateway (MAG) is a router embedded in a device 236 that terminates a specific link layer technology to which mobile 237 nodes attach themselves. It terminates one end of the MAG of the 238 connection to one or more Local Mobility Anchors and participates 239 in the NetLMM protocol exchange. 241 Local Mobility Anchor (LMA) 242 A local mobility anchor (LMA) is a router that terminates 243 connections to multiple Mobile Access Gateways, services mobility 244 requests for mobile nodes moving within a NetLMM system, and 245 participates in the NetLMM protocol exchange. 247 NetLMM Domain 248 A NetLMM domain is a set of multiple MAGs and a set of one or more 249 LMAs interconnected within an access network that provides 250 mobility operations for attached mobile nodes through the 251 execution of the NetLMM protocol. 253 NetLMM Address 254 The invariant IP address of the MN inside the NetLMM domain. For 255 IPv6 it is assumed that this is an invariant routable IP address 256 with global scope. 258 NetLMM Network Prefix 259 The NetLMM Network Prefix (NNP) is the IPv6 link prefix of the 260 NetLMM address. 262 3. Functional Entities 264 The principal functional entities in a NetLMM infrastructure are the 265 Mobile Access Gateway (MAG) and the Local Mobility Anchor (LMA). An 266 access network with NetLMM based mobility support may also have other 267 nodes which support various other functionality such as AAA, routing, 268 DNS, etc., and the functionality of these nodes may be used by the 269 MAG and the LMA, but the operation of such additional nodes need not 270 be changed in any way for the proper operation of the NetLMM 271 protocol. 273 +---------+ +---------+ 274 | LMA La1 | (other LMAs) | LMA Lb1 | (other LMAs) 275 +---------+ +---------+ 276 @ @ @ 277 @ @ @ 278 @ @ @ (other routers) 279 @ @ @ 280 @ @ @ 281 @ @ @ 282 +-------+ +-------+ +-------+ 283 |MAG Ra1| |MAG Ra2|(other MAGs) |MAG Rb1| (other MAGs) 284 +-------+ +-------+ +-------+ 285 * * * 286 * * * * * 287 * * * * * 288 * * * * * 289 * * * * * 290 * * * (other APs) * * (other APs) 291 /\ /\ /\ /\ /\ 292 /AP\ /AP\ /AP\ /AP\ /AP\ 293 / Pa1\ / Pa2\ / Pa3\ / Pb1\ / Pb2\ 294 ------ ------ ------ ------ ------ 296 +--+ +--+ +--+ +--+ 297 |MN|----->|MN|----->|MN|----------->|MN| 298 +--+ +--+ +--+ +--+ 299 Intra-link Local Global 300 (Layer 2) Mobility Mobility 301 Mobility 303 Figure 1 305 The Mobile Access Gateway 306 The Mobile Access Gateway (MAG) is a router that a mobile node is 307 attached to as the first hop router in the NetLMM infrastructure. 308 The MAG is connected to the mobile node over some specific link 309 provided by a link layer but the NetLMM infrastructure is agnostic 310 about the link layer technology that is used. Each MAG has its 311 own identifier used in NetLMM protocol messaging between the MAG 312 and the LMA. The important interfaces between link layer specific 313 functions and the NetLMM function reside on the MAG. There are 314 multiple MAGs in a NetLMM infrastructure. 316 The Local Mobility Anchor 317 The local mobility anchor (LMA) is a router that maintains 318 reachability to a mobile node's address while the mobile node 319 moves around within the NetLMM infrastructure. It is responsible 320 for maintaining forwarding information for the mobile nodes which 321 includes a set of mappings to associate mobile nodes by their 322 identifiers with their address information, associating the mobile 323 nodes with their serving MAGs and the relationship between the LMA 324 and the MAGs. There may be one or more LMAs in a NetLMM 325 infrastructure. 327 4. Protocol Overview 329 The protocol consists of two groups of messages. The first group 330 provides the basic mobility support, which is the end purpose of the 331 protocol, while the second group provides necessary support for 332 maintaining and managing association and connectivity between the 333 LMAs and MAGs. 335 It is not assumed that a MAG is associated with only a single LMA. 336 If there exists multiple LMAs in a NetLMM Domain, each MAG would most 337 likely be associated with, and potentially communicate with all the 338 LMAs rather than only a single LMA. 340 However, the same is not true for mobile nodes. As they move around, 341 and their traffic is routed through various MAGs, their routing state 342 is handled by one specific LMA; the serving LMA does not change. As 343 for the relationship between an MN and a MAG, this should preferably 344 be seen as a relationship between the MN's identity (ID) or IDs and 345 the MAG or MAGs. From the viewpoint of the NetLMM protocol, each MN 346 ID, rather than each MN, is treated as a separate entity. Normally, 347 each MN ID is associated with one MAG, and traffic related to that MN 348 ID is routed through one MAG; but during handover, especially in the 349 case of make-before-break handover, an MN ID may be associated with 350 multiple MAGs. 352 Note that the MN ID used by the NetLMM protocol is not necessarily or 353 maybe not even mostly the same as the ID the MN uses when 354 authenticating. It could be a technology-specific ID assigned by the 355 network, or it could be something like the SEND key. 357 4.1. Mobility Management 359 The NetLMM infrastructure uses 3 messages pairs to manage the 360 attachment, departure, mobility, and other activities of mobile nodes 361 within the infrastructure: 363 * Location Registration / Ack 364 * Location Deregistration / Ack 366 When a mobile node first attaches to a NetLMM enabled network, the 367 network needs to determine if the mobile node should be provided 368 service. This can be a pre-set policy of providing service to all 369 attaching nodes, or it could be a more selective policy requiring 370 some authentication and authorization. The mechanics of 371 authentication and authorization is out of scope for this document. 373 In order not to keep state in the network, the LMA does no AAA access 374 to verify whether it may provide service or not - that is done at the 375 time of authentication, and the information goes to the MAG, not to 376 the LMA. The MAG is the gateway to netlmm service, and screens for 377 authorization; if authorization is given, it signals the LMA, which 378 simply effectuates the commands from the MAG. 380 The mobile node then needs to acquire an address (see Figure 2). 381 Whether it is using stateful or stateless address configuration, the 382 serving LMA needs to be involved in the address allocation process. 384 This specification assumes that a separate subnet prefix is allocated 385 to each mobile node, and does not cover the case of the whole NetLMM 386 domain being organized as a multi-link subnet common to all mobile 387 nodes in the domain. 389 As a result of the mobile node connecting, the MAG sends a Location 390 Registration message to an LMA containing its own ID, the LMA's ID 391 and the Mobile Node's ID. If no error is found, the LMA responds to 392 the message with a Location Registration Ack message. If the MAG 393 obtains a NetLMM subnet prefix for the MN first, the MAG transfers 394 this prefix to the LMA via the Location Registration message. This 395 can happen for instance if the MN acquires its address or delegated 396 prefix through the use of DHCP, with the MAG acting as a DHCP relay. 397 The MAG would then see the DHCP response, whereas the LMA would not. 399 On the other hand, if the LMA obtains the NetLMM subnet prefix for 400 the MN, the LMA transfers the prefix to the MAG via the Location 401 Registration Ack. The LMA creates forwarding state for packets based 402 on the subnet prefix allocated to the MN. 404 This document assumes that the NetLMM prefix is unique to each MN 405 (per-MN subnet); therefore, the MAG and the LMA can route packets 406 destined for the MN by the NetLMM subnet prefix. The case for the 407 shared prefix mode requires additional messages which are not 408 specified in this memo. 410 At any time while it is attached to the network, the MN may acquire 411 additional addresses, through DHCP or link-specific means. If this 412 occurs, the MAG needs to update the routing state by sending a new 413 Location Registration message to inform the LMA about the current set 414 of addresses and prefixes allocated and / or delegated to the MN. 415 Such a Location Registration message MUST contain all the valid 416 addresses and prefixes associated with the MN, not only the newly 417 acquired address or prefix. 419 The MAG, when receiving a successful Acknowledgement to the Location 420 Registration message, creates forwarding state for packets destined 421 to the mobile node, also based on the subnet prefix. In the case of 422 stateless address configuration being used, the MAG also sends a 423 router advertisement to the attached mobile. 425 +-----+ +-----+ +-----+ +-----+ 426 | MN | | MAG | | LMA | | PDP | 427 +-----+ +-----+ +-----+ +-----+ 428 | | | | 429 * 1.MN Attachment | | | 430 | | | | 431 | 2."MN_Access_Network API" | | 432 | (MN ID,LMA handle) | | 433 | | | | 434 | * | | 435 | | | | 436 | |3.Location Reg. | | 437 | |(MN ID,MAG handle,LMA handle,{Prefix}) | 438 | |------------------>| | 439 | | | | 440 | |4.Acknowledgement | | 441 | |(MN ID,MAG handle,LMA handle, | 442 | | Prefix, Status) | | 443 | |<------------------| | 444 . . . . 445 . . . . 446 . . . . 447 | | | | 448 |5.Router Advertisement | | 449 | (Prefix) | | | 450 |<==================| | | 451 | | | | 452 |6.IP Address DAD | | | 453 | (Address) | | | 454 |==================>| | | 456 ----- NetLMM signalling 457 ===== Link-Layer signalling 458 {Xxxx} Optional parameter 460 Figure 2 462 It is possible for the LMA to remove a mobile node from the network. 463 This could be done for a number of policy specific reasons in the 464 network. The two messages used are Location Deregistration and the 465 associated Acknowledgement, initiated by the LMA and acknowledged by 466 the MAG. The MAG disconnects the mobile and removes all mobile state 467 in response to this message. 469 When a mobile node moves from one MAG to another MAG (see Figure 3), 470 the new MAG (nMAG) sends a Location Registration message to the LMA 471 with the MAG handle, LMA handle and the MN ID. The LMA responds by 472 sending an acknowledgement to the nMAG that includes the MN ID, the 473 MAG handle, the LMA handle, and prefix information that the nMAG uses 474 in the router advertisement for the MN, and then sends a Location 475 Deregistration message to the old MAG to have it remove the state it 476 has which is related to the MN. 478 +-----+ +-------+ +-------+ +-----+ 479 | MN | |old MAG| |new MAG| | LMA | 480 +-----+ +-------+ +-------+ +-----+ 481 | | | | 482 * 1.MN Attachment | | | 483 | | | | 484 | | 2."MN_Access_Network API" | 485 | | (MN ID,LMA handle,Prefix) | 486 | | | | 487 | | * | 488 | | | | 489 | | |3.Location Registration 490 | | (MN ID,MAG handle,LMA handle, 491 | | | {Prefix} ) | 492 | | |------------------>| 493 | | | | 494 | | |4.Acknowledgement | 495 | | (MN ID,MAG handle,LMA handle, 496 | | | Prefix,Status) | 497 | | |<------------------| 498 | | | | 499 | | 5.Location Deregistration | 500 | | (MN ID, MAG handle,LMA handle) | 501 | |<--------------------------------------| 502 | | | | 503 | | 6.Acknowledgement | | 504 | | (MN ID,MAG handle,LMA handle,Status) | 505 | |-------------------------------------->| 506 | | | | 508 Figure 3 510 4.2. Setup and Node Association 512 The NetLMM infrastructure uses 3 message pairs to establish and 513 maintain associations between the MAGs and the LMAs: 515 * Association Request / Ack 516 * Disassociation Request / Ack 517 * Heartbeat / Ack 519 A MAG associates itself with an LMA by sending an Association Request 520 message (see Figure 4) that includes its MAG handle and the supported 521 data forwarding modes (such as IPv6-in-IPv6) [RFC2473]. In response 522 the LMA creates an association with the MAG and populates state 523 information about the association. The LMA responds, providing an 524 agreed upon data forwarding mode to the MAG. The MAG can undo the 525 relationship with the LMA through sending a Disassociation Request, 526 to which the LMA responds with an acknowledgement. Heartbeat 527 messages MAY be sent between the MAG and LMA to determine the current 528 status of the reachability of the other entity. All of these 529 messages may be sent optionally over an IPsec connection if 530 additional security is desired. 532 +-----+ +-----+ 533 | MAG | | LMA | 534 +-----+ +-----+ 535 | | 536 | Association Request | 537 | (MAG handle, LMA handle, DataTransport) | 538 |---------------------------------------->| 539 | | 540 | Acknowledgement | 541 | (MAG handle,LMA handle, DataTransport, Status) 542 |<----------------------------------------| 543 . . 544 . . 545 . (Regular operation message flows, . 546 . optionally Heartbeats) . 547 . . 548 | Disssociation Request | 549 | (MAG handle, LMA handle) | 550 |---------------------------------------->| 551 | | 552 | Acknowledgement | 553 | (MAG handle,LMA handle, Status) | 554 |<----------------------------------------| 556 Figure 4 558 4.3. Message Transport 560 The NetLMM control messages defined in this document are carried by 561 the User Datagram Protocol RFC 768 [RFC0768] using well known port 562 number NETLMM_UDP_PORT (TBD -- assigned by IANA -- please replace 563 'NETLMM_UDP_PORT with the actual port number here and below). 565 Any implementation of the NetLMM protocol MUST include support for 566 IPsec protected transport, using Encapsulating Security Payload 567 [RFC4303] in transport mode. IPsec SHOULD be used unless other means 568 of protecting the NetLMM control signalling provide enough security 569 within the NETLMM domain. If IPsec is used, it MUST use a non-NULL 570 authentication algorithm to provide data origin authentication. 572 The message sender SHOULD include a non-zero UDP Checksum. The 573 recipient of the message MUST process and check the UDP checksum. A 574 Zero checksum SHOULD be accepted by the recipient. 576 The sender and initiator of a message exchange MUST use the following 577 UDP ports: 579 * Source Port: variable 581 * Destination Port: NETLMM_UDP_PORT 583 When the recipient of a NetLMM message sends an Acknowledgement, the 584 following UDP ports MUST be used: 586 * Source Port: variable 588 * Destination Port: Copied from the source port of the received 589 message. 591 4.3.1. Message Retransmission 593 To ensure reliable delivery of control messages, NetLMM requires a 594 positive acknowledgement from the receiver and retransmission by the 595 sender for an unacknowledged message. 597 Each request message has a corresponding acknowledgement message, 598 which must be used to acknowledge receipt of the request message. In 599 the acknowledgements, NetLMM entities can append message options 600 (defined in Section 6) according to the protocol operation (Section 4 601 and Section 5). 603 NetLMM entities maintain a retransmission timer T-rtx and MUST 604 support the basic back-off scheme described below for the 605 retransmission timeout (RTO). 607 After a NetLMM control message has been sent, the NetLMM entity 608 initializes T-rtx with an RTO value of RTO_INIT. If the 609 acknowledgement of the associated NetLMM control message is received 610 before T-rtx has expired, T-rtx is stopped. If T-rtx expires before 611 the acknowledgement is received, the NetLMM entity retransmits the 612 packet using the same sequence number as for the original packet. 614 For each retransmission, the NetLMM entity should set the new RTO 615 value to twice the previous RTO duration (e.g. new_RTO = 2 * 616 previous_RTO). The RTO value SHOULD not exceed the limit of RTO_MAX 617 seconds. The value for RTO_INIT and RTO_MAX should be configurable, 618 with a resolution better than 1 second (such as 1 ms, for instance). 620 In case a NetLMM entity has multiple associations, an individual RTO 621 must be maintained for each associated NetLMM peer entity. 623 Optionally, NetLMM entities MAY use more enhanced schemes to 624 dynamically re-calculate and adjust the RTO. As an example, the RTO 625 could be derived from periodic round trip time (RTT) measurements and 626 RTT deviations, as utilized by the Stream Control Transport Protocol 627 (SCTP) [RFC2960]. If no enhanced approach for RTO derivation is 628 supported, NetLMM entities MUST use the basic approach as described 629 above. 631 Heartbeat messages are not considered NetLMM control messages in the 632 context of this section; they are handled according to Section 5.6.1 633 and are not re-transmitted. 635 The default values for RTO_INIT and RTO_MAX are defined as follows: 637 RTO_INIT = 1 second 639 RTO_MAX = 64 seconds 641 4.3.2. Message Re-ordering 643 If messages from a MAG regarding a specific MN are received out-of- 644 order, there are cases where an MN may be left without service unless 645 care is taken to ensure processing of messages in the correct order. 647 One example of such a situation is if a mobile node acquires multiple 648 prefixes through DHCP, but the initial Location Registration message, 649 indicating only one allocated prefix, is lost and subsequently re- 650 transmitted. Another Location Registration message, generated after 651 a second prefix allocation or delegation has taken place, will 652 indicate both prefixes. If the initial Location Registration message 653 is processed after the second Location Registration message, the 654 Routing Cache at the LMA will only contain routing information for 655 the initial prefix, not for the later prefix. 657 To avoid problems due to out-of-order processing of messages, the MAG 658 MUST ensure that no message pertaining to a given MN or sets of MNs 659 are sent until any previous message pertaining to the same MN or MNs 660 has been acknowledged by the LMA. 662 4.3.3. Message Rate-Limitation 664 In addition to the retransmission mechanism, NetLMM entities MUST 665 implement a configurable rate limitation, so that situations where 666 message storms may occur, there is an upper limit on the number of 667 messages per second that may be originated by an entity towards 668 another. The message rate limitation SHOULD be dynamic, so that when 669 for instance the heartbeat mechanism indicates that the peer is 670 heavily loaded, the rate limit is lowered. 672 4.4. Identity - Locator Split 674 The protocol has been explicitly designed to support the use of 675 NetLMM node identifiers which are separate from the node locators 676 (addresses). In addition to what some may claim is a philosophically 677 pleasing separation of distinct and separate functions, this provides 678 some direct practical benefits: 680 With nodes always being identified by their identities (called 681 handles in this document) rather than by their address, the 682 protocol has the potential of running unchanged on infrastructure 683 using different IP addresses types, or even mixing multiple 684 address types. 686 A node identified by one identifier may have multiple addresses, 687 belonging to multiple interfaces. This makes it easier to design 688 high-availability and high-performance hardware for the NetLMM 689 nodes, without the nodes having to be individually configured with 690 knowledge of the multiple interfaces and addresses which may 691 belong to each of its peers. 693 Note that this document does not prescribe which kind of identifiers 694 should be used as LMA and MAG identifiers, and does not prescribe a 695 mechanism to resolve identifiers to addresses. By default, the 696 simplest possible resolver mechanism and identifier choice is 697 assumed: The use of a node's global IPv6 address as identifier, with 698 the identity to location resolver function being to use the identity 699 as locator. 701 4.5. Handling of Link-Local Addresses 703 Depending on how link-local addresses are handled, their existence 704 may cause trouble for applications. 706 There are a number of different ways that link-local addresses could 707 be handled within a network with NetLMM mobility support: 709 a. Link-local addresses may have network-wide scope. This is 710 discussed at length in [I-D.thaler-intarea-multilink-subnet- 711 issues], and is not to be recommended. 713 b. Link-local addresses may have MAG-wide scope; i.e., all MNs 714 attached to the same MAG will have link-local reachability to 715 each other. The consequence of this is that nodes may discover 716 they have link-local reachability at one instant in time, but be 717 deprived of it at the next instant. In other words, because of 718 node movements, nothing can really be assumed about the 719 reachability of other nodes through link-local addresses from one 720 moment to another. 722 c. Link-local addresses have MN-scope only, or put in a different 723 way, the MN has a point-to-point link with the MAG. In this 724 case, the MN will never discover link-local addresses belonging 725 to other MNs, and applications on the MN will not be in a 726 position of being able to make erroneous assumptions about link- 727 local reachability of other nodes. 729 This document also assumes that link-local addresses are handled 730 according to method c. above, which is effectively the same manner as 731 global addresses are handled: The link-local addresses are unique to 732 each MN, or expressed with different words, the link between the MN 733 and the MAG is effectively a point-to-point link, with no other nodes 734 than the MN and the MAG on the link. 736 5. Message Format and Message Types 738 5.1. Message Format 740 An NetLMM message consists of a header followed by one or more 741 options. The message header is common and messages are distinguished 742 by Type field in the header. NetLMM options are in TLV format and 743 8-octet aligned, with a Type field divided into two parts; Option 744 Type and Option Sub-Type. All option payloads whose length is not a 745 unit of 8 octets must be padded to the correct alignment. 747 All NetLMM messages start with the following common header. 748 Parameters for each message are contained in the option format (see 749 following sections). 751 0 1 2 3 752 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 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Version | Type | Sequence Number | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | Reserved | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 . Src ID Option . 759 . . 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 . Dst ID Option . 762 . . 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 . . 765 . Options . 766 . . 767 | | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 Version 771 An 8-bit number, indicating the NetLMM protocol version. The 772 version of the NetLMM protocol specified in this document is 1. 774 Type 775 8-bit value indicating the NetLMM message type. The message types 776 are specified below, in following sections. 778 Sequence Number 779 16-bit length, used to ensure the correspondence of request and 780 acknowledgement messages between the MAG and the LMA. The 781 sequence number is exchanged between given MAG and LMA, and 782 configured when MAG has joined to a NetLMM domain through the 783 exchange of Association Request/Acknowledgement messages. 784 Sequence Number comparisons MUST be performed modulo 2^16, i.e., 785 the number is a free running counter represented modulo 65536. A 786 Sequence Number in a received message is considered less than or 787 equal to the last received number if its value lies in the range 788 of the last received number and the preceding 32768 values, 789 inclusive. For instance, if the last received sequence number was 790 15, then messages with sequence numbers 0 through 15, as well as 791 32783 through 65535, would be considered 'less than or equal'. 793 Sequence numbers are unique to a MAG-LMA association, based on the 794 MAG handle and LMA handle. If a MAG or an LMA has multiple IP 795 addresses, they all share one sequence number series. 797 Reserved 798 32-bit field reserved for future use. The value MUST be 799 initialized to zero by the sender, and MUST be ignored by the 800 receiver. 802 Src ID Option 803 An ID Option (Section 6.3) giving the ID of the source of the 804 message 806 Dst ID Option 807 An ID Option giving the ID of the destination of the message. 809 Options 810 Any other options associated with the message. 812 5.2. Location Registration 814 Request Message Type: 1 815 Required options: MAG handle, LMA handle, MN ID, Timestamp 817 Acknowledgement Message Type: 65 818 Required options: MAG handle, LMA handle, MN ID, Status 820 Implementation: Mandatory 821 Use: Mandatory 823 The Location Registration message is sent from the MAG to the LMA 824 when the MAG detects the MN having accessed the network without an IP 825 address, or when an MN obtains another prefix/IP address. The 826 mobility state of the MN, in the MAG and LMA, is created or updated 827 using this message. The message may contain multiple Prefix 828 Allocation (Section 6.5) and Prefix Delegation (Section 6.6) Options. 830 The forwarding state for a MN is fully defined by the Prefix 831 Allocation and Delegation Options if any are present. On receipt of 832 a Location Registration message containing one or more Prefix 833 Allocation and / or Prefix Delegation Options, any old forwarding 834 state is replaced by the forwarding state defined by the latest 835 received prefix options. If the Location Registration does not 836 contain any Prefix Allocation or Prefix Delegation Option, the 837 forwarding state is unchanged, and Prefix Allocation and Prefix 838 Delegation Options describing the state are returned from the LMA to 839 the MAG in the Location Registration Acknowledgement. 841 The Location Registration Acknowledgement is sent from the LMA to the 842 MAG to acknowledge the receipt of the Location Registration message. 843 If the registration is successful, the LMA sends the NetLMM prefix on 844 this message, which in turn is used for the Router Advertisement sent 845 by the MAG. 847 5.3. Location Deregistration 849 Request Message Type: 2 850 Required options: MAG handle, LMA handle, MN ID 852 Acknowledgement Message Type: 66 853 Required options: MAG handle, LMA handle, MN ID, Status 855 Implementation: Mandatory 856 Use: Mandatory 858 The Location Deregistration message is sent from the LMA to a MAG to 859 delete the mobility state of the MN. The LMA sends this message when 860 it determines that the MN is at a new location. This message 861 contains the MN ID, MAG handle, LMA handle and may contain a 862 Deregistration Timeout option, providing a delayed deregistration. 864 An Acknowledgement message is sent back to the source of the Location 865 Deregistration message to acknowledge the receipt of the Location 866 Deregistration message. This message may contain the applied 867 deregistration delay time. 869 5.4. Association Request 871 Request Message Type: 16 872 Required options: MAG handle, LMA handle, Data Transport 874 Acknowledgement Message Type: 80 875 Required options: MAG handle, LMA handle, Data Transport, Status 877 Implementation: Mandatory 878 Use: Mandatory 880 The Association Request is used to set up the control and data plane 881 relationship between the MAG and LMA. This message is sent from the 882 MAG to the LMA in the MAGs initiation phase, before it enters the 883 operational phase and handles MN Location Registration. The message 884 contains the sender's ID, its functional capabilities and supported 885 data forwarding modes. The data forwarding mode specifies the tunnel 886 method of the data plane (e.g., IP-in-IP). The tunnel between the 887 MAG and LMA is bidirectional, which is achieved by establishing two 888 unidirectional tunnels in opposite directions. 890 An acknowledgement to the the Associate Request message is sent from 891 the LMA to the MAG to indicate the status of the request (success or 892 error code). If the request is successful, the receiver of the 893 request also sends back one choice from each set of capabilities 894 specified in the Association Request, indicating for each capability 895 the method which will be used by the two nodes. 897 5.5. Disassociation Request 899 Request Message Type: 17 900 Required options: MAG handle, LMA handle 902 Acknowledgement Message Type: 81 903 Required options: MAG handle, LMA handle, Status 905 Implementation: Mandatory 906 Use: Mandatory 908 The Disassociation Request message is sent from the MAG to the LMA or 909 vice versa to tear down the control and data plane relationship 910 between them. This message contains the MAG handle and LMA handle. 912 An acknowledgement of the the Disassociate Request message is sent 913 from the LMN to the MAG or vice versa to indicate the status of the 914 request (success or error code). 916 5.6. Heartbeat 918 Request Message Type: 18 919 Required options: MAG handle, LMA handle 921 Acknowledgement Message Type: 82 922 Required options: MAG handle, LMA handle 924 Implementation: Mandatory 925 Use: Optional 927 The Heartbeat message is sent from the MAG to LMA or vice versa to 928 obtain the connectivity status. This message contains the MAG handle 929 and the LMA handle. It MAY contain other options, such as a 930 Timestamp Option. Contrary to the case for other NetLMM messages, 931 Heartbeat messages are never re-transmitted. 933 The Heartbeat Ack is sent back from the node that received the 934 Heartbeat message to its peer. This message contains the MAG handle 935 and the LMA ID. It MAY contain other options, such as a Timestamp 936 Option. 938 5.6.1. Heartbeat Handling 940 If used, Heartbeats are sent at a fixed, configurable rate, 941 determined by the HEARTBEAT_SEND_INTERVAL, and a history is kept for 942 the last HEARTBEAT_HISTORY_SIZE heartbeats. The history has a number 943 of slots (equal to HEARTBEAT_HISTORY_SIZE), and each slots holds the 944 Sequence Number of the Heartbeat message sent in that time-slot, the 945 time at which the Heartbeat message was sent, and the number of 946 Heartbeat Acknowledgements that were received during that time-slot. 948 The following algorithm is used to detect connectivity and load 949 problems: 951 Each time a Heartbeat message is sent, the message sequence number is 952 registered in the heartbeat history. A count is also made of the 953 number of received Heartbeat Acknowledgements recorded in the 954 heartbeat history. Except during startup, when the number of 955 heartbeats recorded in the history is less than 956 HEARTBEAT_HISTORY_SIZE, the heartbeat loss ratio is calculated as 957 (heartbeats_sent - received_acks) / (heartbeats_sent). If the ratio 958 is larger than a configurable value HEARTBEAT_LOSS_THRESHOLD, an 959 alarm should be raised, and the event MUST be logged. (The heartbeat 960 loss rate can be derived from the heartbeat loss ratio as loss_rate = 961 loss_ratio / HEARTBEAT_SEND_INTERVAL). 963 When a Heartbeat message is received by the destination node, it MUST 964 respond with a Heartbeat Ack with the same Sequence Number as the 965 received Heartbeat message. 967 When a Heartbeat Ack is received, the count of received 968 acknowledgements is increased for the current history time-slot and 969 the time since the corresponding Heartbeat message was sent is 970 calculated. If the corresponding heartbeat's Sequence Number is no 971 longer on record in the heartbeat history, the value 972 (HEARTBEAT_SEND_INTERVAL * HEARTBEAT_HISTORY_SIZE is used). If this 973 calculated delay is larger than a configurable value 974 HEARTBEAT_DELAY_THRESHOLD, an alarm should be raised, and the event 975 MUST be logged. 977 The Heartbeat loss rate is primarily an indication of the quality of 978 the communication link, while the Heartbeat delay is primarily an 979 indication of the load of the peer. A sudden overload situation can 980 also manifest as an apparent sudden in crease in loss rate, but in 981 the absence of link problems, a steady state high load situation will 982 show an acceptable loss rate, but a large heartbeat delay. 984 An implementation of the NetLMM protocol may adjust its resend 985 timeout value (RTO) based on both the heartbeat loss rate and the 986 average heartbeat delay. For instance, a RTO which is lower than the 987 average heartbeat delay will result in unnecessary re-sends and added 988 load in a high-load situation. 990 5.7. Acknowledgements 992 An acknowledgement MUST be sent in response to any non- 993 Acknowledgement message. It is sent from the node that received the 994 initial message to the originator of that message. It indicates that 995 the initial message has been received, and also carries a status 996 value which indicates the result of the operation requested by the 997 initial message. 999 The Sequence Number field of an acknowledgement message MUST be set 1000 to the same value as the Sequence Number of the message which it 1001 acknowledges, in order to support the message re-send mechanism 1002 described in Section 4.3. 1004 The acknowledgement message MUST contain at least the Status Option 1005 (Section 6.12) except in the case of the Heartbeat Acknowledgement, 1006 but may also contain other options which are appropriate in response 1007 to the initial message. 1009 5.8. Message Status Codes 1011 The status codes used by the NetLMM protocol are used when 1012 acknowledging a message, to indicate the result of processing the 1013 associated request message. The status code is carried in the Status 1014 Option (Section 6.12). 1016 The status codes are allocated in ranges, depending on their usage. 1017 The defined ranges are as follows: 1019 0 - 63: Generic Status 1020 This range is used for status codes which are of a generic nature, 1021 and not specific to MAG or LMA. 1023 64 - 127: LMA-specific Status 1024 This range is used for status codes which are specific to the 1025 LMAs. 1027 128 - 191: MAG-Specific Status 1028 This range is used for status codes which are specific to the 1029 LMAs. 1031 192 - 255: Reserved 1032 This range is reserved for future use. 1034 The following values are defined by this document: 1036 0: Not Applicable (N/A) 1037 The status code is not applicable for the message. 1039 1: Success 1040 The associated request message was successfully processed. 1042 2: Administratively Prohibited 1043 An action was refused due to administrative policy reasons. 1045 3: Lack of Resources 1046 The resources needed to provide the requested service was not 1047 available. 1049 4: Invalid Message 1050 The NetLMM Request message was invalid or malformed. 1052 62: Vendor-Specific Status (Generic) 1053 For use with vendor-specific messages. Additional status 1054 detail may be provided for instance in vendor-specific options. 1056 63: Experimental Status (Generic) 1057 For use during experimental implementation of new protocol 1058 features, according to "Assigning Experimental and Testing 1059 Numbers Considered Useful" [RFC3692] 1061 65: Duplicate Prefix 1062 Used by the LMA when an Location Registration contains an IP 1063 address or prefix that is duplicated in the same NetLMM domain. 1064 The specific invalid addresses/prefixes MUST be specified in 1065 Address Options. 1067 66: Invalid Prefix 1068 Used by the LMA when an Location Registration contains an IP 1069 address or prefix that is invalid in the same NetLMM domain. 1070 The specific invalid addresses/prefixes MUST be specified in 1071 Address Options. 1073 67: Over IP Address Limit 1074 Used by the LMA on receipt of a Location Registration message, 1075 if the maximum number of IP addresses or prefixes allowed for a 1076 MN has been exceeded. The specific addresses/prefixes which 1077 were disallowed MUST be specified in Address Options. 1079 68: Invalid Tunnelling Method 1080 The proposed tunnel method is not supported or unavailable. 1082 69: Already Associated 1083 The LMA already had the requesting MAG listed as associated. 1085 70: Not Associated 1086 The LMA received a Disassociate request from a MAG which was 1087 not in its MAG list. 1089 126: Vendor-Specific Status (LMA-specific) 1090 For use with vendor-specific messages. Additional status 1091 detail may be provided for instance in vendor-specific options. 1093 127: Experimental Status (LMA-specific) 1094 For use during experimental implementation of new protocol 1095 features, according to RFC 3692. 1097 128: Requested Timeout Modified 1098 Indicates that MAG could not comply with the timeout time 1099 indicated by the LMA in a Location Deregistration message. A 1100 message containing this error code should also contain a 1101 Deregistration Timeout Option indicating the timeout that will 1102 be applied. 1104 190: Vendor-Specific Status (MAG-Specific) 1105 For use with vendor-specific messages. Additional status 1106 detail may be provided for instance in vendor-specific options. 1108 191: Experimental Status (MAG-specific) 1109 For use during experimental implementation of new protocol 1110 features, according to RFC 3692. 1112 6. Option Format and Option Types 1114 6.1. Option Format 1116 NetLMM defines a general extension mechanism using options to allow 1117 optional information to be carried in the control messages. The 1118 options are encoded in a Type-Length-Value format, and are described 1119 in detail in the following. The options carry additional information 1120 used for processing the message. Up-to-date values for the option 1121 types are maintained in the online IANA registry of assigned numbers. 1122 Each option is uniquely identified by its combination of Option Type 1123 and Option Sub-Type. 1125 Format: 1127 0 1 2 3 1128 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 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | Option Type |Option Sub-Type| Length | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 | Option-specific data | 1133 . (up to option length) . 1134 . . 1135 . . 1136 . . . . 1138 Option Type 1139 This field identifies the particular type of option serving a 1140 specified function. 1142 The Type field in the NetLMM option is split into two ranges: Type 1143 values of 0 through 127 (inclusive) for not skippable options and 1144 128 through 255 (inclusive) for skippable options. The recipient 1145 of a message with an unrecognized non-skippable option MUST 1146 silently discard the message. Otherwise, if no unrecognized non- 1147 skippable options are found, the message MUST be processed with 1148 any unrecognized skippable option bypassed (i.e. move to next 1149 option using the Length field of the unrecognized option) during 1150 processing by the receiver. 1152 Option Sub-Type 1153 This field indicates the sub-type of the option, and provides for 1154 up to 256 related Option Sub-Types with the same Option Type 1155 field. 1157 Length 1158 The value represents the length of the "Data" portion of the 1159 option, in unit of octets. 1161 6.2. Option Alignment 1163 Options are always aligned to start on an 8-octet aligned boundary, 1164 relative to the start of the message header. The first 4 octets of 1165 an option has a fixed format, giving the Option type, sub-type, and 1166 length in octets. When assembling a message, for an option which has 1167 a length in octets which is not a multiple of 8, zero octets are 1168 added after the option up to the next 8-octet-aligned boundary. The 1169 option length is not adjusted to include the padding. When parsing 1170 the options of a message, any octets between the end of one option 1171 and the next 8-octet-aligned boundary are discarded. 1173 In other words, if we include the padding in the figure showing 1174 option field layout, we get the following for an option of total 1175 length N*8+3. (Total length N*8+3 implies that the Length field has 1176 the value (N*8+3)-4, as the length field indicates the length of the 1177 option data, i.e., does not include the first 4 octets): 1179 0 1 2 3 1180 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 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 | Option Type |Option Sub-Type| Length | 1183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1184 | Option-specific data | 1185 . (up to option length) . 1186 . . 1187 . +-+-+-+-+-+-+-+-+ 1188 | | Padding... | 1189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1190 | ...Padding | 1191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1193 6.3. ID Option 1195 The ID option carries various types of identifiers. All messages 1196 related to a specific MN must include an ID option providing the MN 1197 ID. Multiple ID options can be included in an message. For the 1198 purpose of the ID option, the ID itself is viewed as an octet 1199 sequence, but to avoid ID collisions, the ID is prefixed with an ID 1200 type. An example for the MN ID is a NAI [RFC4282]. 1202 0 1 2 3 1203 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 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 | Option Type |Option Sub-Type| Length | 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 | ID-Type | Identifier... | 1208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1209 | | 1210 . . 1211 . . 1212 . . 1213 | | 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1216 Option Type 1217 0 1219 Option Sub-Type 1220 0 1222 Length 1223 The length of the option in octets, excluding the Type, Sub-Type 1224 and Length fields. 1226 ID-Type 1227 This field indicates the type of ID carried in the remainder of 1228 the option. 1229 *** Note: Check whether there already exists an applicable IANA 1230 registry for ID types which we could use here *** 1232 0: SEND [RFC3971] public key. 1234 1: NAI according to [RFC4282] 1236 2: Ethernet MAC Address 1238 Additional ID-Types based on cryptographically generated 1239 identifiers are expected to be used, but in order to allocate ID- 1240 Type values for such identifiers it must be clearly specified 1241 exactly what goes into the Identifier field in each case, to 1242 ensure interoperability. 1244 Identifier 1245 This is a variable-length octet sequence, which is expected to 1246 hold an identifier of the type indicated by the ID-Type field. 1248 6.4. Handle Option 1250 The handle option carries LMA and MAG handle entities called handles. 1251 For the purpose of the handle option, the handle itself is viewed as 1252 an octet sequence, but to avoid handle collisions, the handle is 1253 prefixed with an handle type. 1255 0 1 2 3 1256 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 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1258 | Option Type |Option Sub-Type| Length | 1259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1260 | Handle-Type | Identifier... | 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1262 | | 1263 . . 1264 . . 1265 . . 1266 | | 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 Option Type 1270 0 1272 Option Sub-Type 1273 This field indicates what the handle in this option refers to. It 1274 is expected that additional Sub-Types may be defined in the 1275 future. 1277 1: LMA handle 1279 2: MAG handle 1281 Length 1282 The length of the option in octets, excluding the Type, Sub-Type 1283 and Length fields. 1285 Handle-Type 1286 This field indicates the type of handle carried in the remainder 1287 of the option. 1288 *** Note: Check whether there already exists an applicable IANA 1289 registry for handle types which we could use here *** 1291 0: SEND [RFC3971] public key. 1293 1: NAI according to [RFC4282] 1295 2: Ethernet MAC Address 1297 3: IPv6 Address 1299 Additional Handle-Types based on cryptographically generated 1300 identifiers are expected to be used, but in order to allocate 1301 Handle-Type values for such identifiers it must be clearly 1302 specified exactly what goes into the Identifier field in each 1303 case, to ensure interoperability. 1305 Identifier 1306 This is a variable-length octet sequence, which is expected to 1307 hold an identifier of the type indicated by the Handle-Type field. 1309 6.5. Prefix Allocation Option 1311 This option defines the address or prefix which has been allocated to 1312 a mobile node. If the address prefix length is the same as the full 1313 address length, it describes a single address, otherwise it describes 1314 a prefix allocated to the MN. The address or prefix can be either 1315 IPv4 and IPv6. 1317 0 1 2 3 1318 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 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 | Option Type |Option Sub-Type| Length | 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 | Prefix | Reserved | 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 | | 1325 + + 1326 | | 1327 + Address (IPv6 case) + 1328 | | 1329 + + 1330 | | 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 Option Type 1334 1 1336 Option Sub-Type 1338 0: Indicates that the data in the Address field is an IPv6 address 1339 or address range. If the Address Prefix Length is 128 this is 1340 an address, otherwise it is an address range with span 1341 determined by the given prefix length. 1343 1: Indicates that the data in the Address field is an IPv4 1344 address. 1346 Length 1347 The length of the option in octets, excluding the Type, Sub-Type 1348 and Length fields. When the Option Sub-Type is 0, the Length is 1349 20, and when the Sub-Type is 1, the length is 8. 1351 Prefix 1352 The number of leading bits in the Address that are valid as a 1353 subnet prefix. 1355 Address Prefix 1356 Variable. The value indicates the prefix length of the prefix or 1357 address allocated to the mobile node. If the prefix length is 1358 equal to the full address length, the option describes an address 1359 allocation, otherwise it describes a prefix allocation. 1361 Reserved 1362 Reserved for future use. The value MUST be initialized to zero by 1363 the sender, and MUST be ignored by the receiver. 1365 Address: 1366 If the Option Sub-Type is 0, the value is an IPv6 address, while 1367 if the type is 1, the value is an IPv4 address. 1369 6.6. Prefix Delegation Option 1371 This option defines a prefix which has been delegated to a mobile 1372 node. It is used by the MAG to inform the LMA about a prefix 1373 delegation to the MN which has been done through for instance DHCP. 1374 The prefix can be either IPv4 and IPv6. 1376 Typically, there will be one address or prefix allocation 1377 (communicated by the presence of the Prefix Allocation Option, 1378 (Section 6.5) taking place when a mobile node first attaches to the 1379 network through a MAG), with address delegations acquired later, for 1380 instance by the use of DHCP, and communicated by the use of the 1381 Prefix Delegation Option. The LMA handles routing in the same way 1382 for allocated and delegated prefixes, but needs to correctly 1383 communicate to a new MAG the allocated and delegated prefixes so that 1384 the MAG can construct its Routing Advertisements correctly, if such 1385 are used. 1387 0 1 2 3 1388 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 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 | Option Type |Option Sub-Type| Length | 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 | Prefix | Reserved | 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 | | 1395 + + 1396 | | 1397 + Address (IPv6 case) + 1398 | | 1399 + + 1400 | | 1401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1403 Option Type 1404 1 1406 Option Sub-Type 1408 2: Indicates that the data in the Address field is an IPv6 address 1409 or address range. 1411 3: Indicates that the data in the Address field is an IPv4 1412 address. 1414 Length 1415 The length of the option in octets, excluding the Type, Sub-Type 1416 and Length fields. When the Option Sub-Type is 2, the Length is 1417 20, and when the Sub-Type is 3, the length is 8. 1419 Prefix 1420 The number of leading bits in the Address that are valid as a 1421 subnet prefix. 1423 Address Prefix 1424 Variable. The value indicates the prefix length of the prefix 1425 delegated to the mobile node. 1427 Reserved 1428 Reserved for future use. The value MUST be initialized to zero by 1429 the sender, and MUST be ignored by the receiver. 1431 Address: 1432 If the Option Sub-Type is 2, the value is an IPv6 address, while 1433 if the type is 3, the value is an IPv4 address. 1435 6.7. Data Transport Option 1437 This option contains data transport methods capabilities that the MAG 1438 or LMA has. This option is used by Association Request message and 1439 Acknowledgement to negotiate the data transport method between MAG 1440 and LMA. Multiple methods can be contained in the field with the 1441 order of preference. The mandatory transport method is IPv6-in-IPv6 1442 [RFC2473], which must be listed. 1444 0 1 2 3 1445 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 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 | Option Type |Option Sub-Type| Length | 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 | Data Transport Method 1 | 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 | | 1452 ~ ~ 1453 | | 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 | Data Transport Method n | 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 Option Type 1459 2 1461 Option Sub-Type 1462 0 1464 Length 1465 The length of the option in octets, excluding the Type, Sub-Type 1466 and Length fields. 1468 The number of Data Transport Method fields is equal to the Length 1469 divided by the size, in octets, of the Data Transport Method 1470 field. 1472 Data Transport Method 1473 Indicates the data transport methods available at the sender in 1474 the case of the Association Request message. The methods are 1475 listed in order of preference. In the case of the Association 1476 Request Acknowledgement, only one method would be listed, 1477 indicating the chosen data transport method. 1479 The following values are defined for the data transport method 1480 field by this memo: 1482 0: IPv6-in-IPv6 1484 1: GRE 1486 2: IPv4-in-IPv6 1488 6.8. Deregistration Timeout Option 1490 This option indicates the length, in milliseconds, to keep the 1491 forwarding state of a given MN active after a handover. When used, 1492 this option is included in the Location Deregistration message and 1493 its acknowledgement. The timeout time in the Location Deregistration 1494 Ack is copied from that given in the Timeout Option of the Location 1495 Deregistration. If the MAG can not keep the MN state alive as long 1496 as the LMA has requested for some reason, the MAG can indicate the 1497 preferred timeout time and return error code "Requested Timeout 1498 Modified" instead of copying the original value. 1500 0 1 2 3 1501 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 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 | Option Type |Option Sub-Type| Length | 1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1505 | Timeout Time | 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1508 Option Type 1509 3 1511 Option Sub-Type 1512 0 1514 Length 1515 4. The length of the option in octets, excluding the Type, Sub- 1516 Type and Length fields. 1518 Timeout Time 1519 Indicates the preferred delay before deleting the MN forwarding 1520 state from the previous MAG during handover. The value is in 1521 milliseconds. 1523 6.9. Timestamp Option 1525 This option contains the timestamp value in the format of an NTP 1526 timestamp (RFC 4330, Section 3 [RFC4330]), and records the time when 1527 the message is sent. This option can be used to detect an overtaking 1528 message in a race condition by comparing the timestamp values of 1529 messages. Especially during handovers, if the network suffers from a 1530 sudden propagation delay for some reason or the MN moves rapidly 1531 between MAGs, the timestamp may be used to facilitate in-order 1532 messages processing regardless of message arrival order. The use of 1533 this option requires a reliable time distribution method, such as NTP 1534 or GPS time synchronization, with sufficient accuracy to support fast 1535 moving MNs. 1537 If a Location Registration message received from a MAG has a 1538 timestamp which is earlier than the timestamp of the most recently 1539 received message pertaining to the same MN, special processing has to 1540 be done. If the two messages are from the same MAG it indicates an 1541 error condition, as the lock-step message sending described in 1542 Section 4.3.2 should prevents this from happening. If the two 1543 messages are from different MAGs, the most recently received message, 1544 which has a timestamp older than some previously received message 1545 pertaining to the same mobile node, MUST be discarded and the event 1546 logged. 1548 LMA and MAG nodes MUST support and use message timestamps in the 1549 Location Registration messages. 1551 Acknowledgements of these messages should however not carry a 1552 timestamp option. 1554 Heartbeat messages and acknowledgements may optionally contain a 1555 timestamp option for informational or diagnostic purposes. 1557 0 1 2 3 1558 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 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1560 | Option Type |Option Sub-Type| Length | 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 | Timestamp | 1563 | | 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 Option Type 1567 4 1569 Option Sub-Type 1570 0 1572 Length 1573 8. The length of the option in octets, excluding the Type, Sub- 1574 Type and Length fields. 1576 Timestamp 1577 A timestamp in the 64 bit format defined for NTP timestamps 1578 [RFC4330]. 1580 6.10. Vendor-Specific Option 1582 This option can be used by any vendor or organization that has an 1583 IANA-allocated SMI Network Management Private Enterprise Code. 1584 Details of the meaning of value field is entirely up to the defining 1585 vendor or organization. 1587 0 1 2 3 1588 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 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1590 | Option Type |Option Sub-Type| Length | 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 | Vendor/Org-ID | 1593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1594 | | 1595 . . 1596 . Value . 1597 . . 1598 | | 1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1601 Option Type 1602 5 1604 Option Sub-Type 1605 0. 1607 This field may not be assigned any value different from zero by 1608 the organizations using the option; only the Value field may be 1609 freely used. 1611 Length 1612 The length of the option in octets, excluding the Type, Sub-Type 1613 and Length fields. 1615 Vendor/Org-ID 1616 The high-order octet is 0 and the low-order 3 octets are the SMI 1617 Network Management Private Enterprise Number [RFC2578], 1618 [ENTERPRISE-NUM], of the Vendor in network byte order. 1620 Value 1621 Variable. Details defined by individual Vendors / Organizations. 1623 6.11. Registration Lifetime Option 1625 This option MAY be used to indicate a limited lifetime for the state 1626 created as a result of Location Registration (Section 5.2) messages. 1627 If no Registration Lifetime Option is used, the lifetime of the state 1628 is to be taken as "Infinite", but with the reservation that in cases 1629 where a node experiences an impending lack of resources, the Least 1630 Recently Used (LRU) states may be removed (garbage collected), to 1631 recover resources for continued operation. 1633 0 1 2 3 1634 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 1635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1636 | Option Type |Option Sub-Type| Length | 1637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1638 | Lifetime | 1639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1641 Option Type 1642 6 1644 Option Sub-Type 1645 0 1647 Length 1648 4. The length of the option in octets, excluding the Type, Sub- 1649 Type and Length fields. 1651 Lifetime 1652 The lifetime in seconds, with a value between 1 and 2^32 - 2. The 1653 values 0 and 2^32 - 1 are reserved, and MUST NOT be used. 1655 6.12. Status Option 1657 This option MUST be used in Acknowledgements to indicate the status 1658 result of the acknowledged message. 1660 0 1 2 3 1661 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 1662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1663 | Option Type |Option Sub-Type| Length | 1664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1665 | Status | Reserved | 1666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1668 Option Type 1669 7 1671 Option Sub-Type 1672 0 1674 Length 1675 8. The length of the option in octets, excluding the Type, Sub- 1676 Type and Length fields. 1678 Status 1679 An 8-bit number, which indicates the Status result of handling the 1680 acknowledged message. Individual status codes are defined in 1681 Section 5.8. 1683 Reserved 1684 24-bit field reserved for future use. The value MUST be 1685 initialized to zero by the sender, and MUST be ignored by the 1686 receiver. 1688 7. Protocol Specification 1690 7.1. Mobile Access Gateway Operation 1692 7.1.1. Conceptual Data Structures 1694 Each MAG MUST maintain a NetLMM Routing Cache and an LMA List. 1696 Each MAG Routing Cache entry conceptually contains the following 1697 fields for each attached MN: 1699 * The MN ID of the attached MN. This identifier is acquired during 1700 the attach procedure and is used from the MAG to identify the 1701 attached MN in the Location Registration message, which is sent to 1702 the selected LMA. 1704 * One or more global IP addresses or address prefixes of an attached 1705 MN. Each IP address or prefix is acquired from an LMA through the 1706 Location Registration Acknowledgement or by means of local 1707 operation, such as when acting as a DHCP relay (see Section 4.1 1708 and Section 4.3.2). According to the context of the received 1709 message or local indication, an IP address is set up, updated or 1710 removed from the Routing Cache. 1712 * The LMA handle of the LMA serving an attached MN. The serving LMA 1713 and its LMA handle is acquired from the LMA selection policy, 1714 which is out of scope of this specification. 1716 Each MAG MUST maintain an LMA List, which identifies all LMAs with 1717 which the MAG is associated. The LMA List is used to perform 1718 heartbeat tests and to map an LMA handle to the associated LMA's IP 1719 address(es). The LMA List also supports the procedure of bulk 1720 deregistrations at all or a subset of LMAs. 1722 The LMA List also indicates the forwarding approach which has been 1723 selected for an association between the MAG and a particular LMA. 1724 During the association procedure, an LMA selects a forwarding 1725 approach from the MAG's full set of forwarding capabilities. For 1726 this the MAG appends a Data Transport option, which indicates its 1727 supported forwarding capabilities in decreasing order of preference, 1728 to the Association message. The Data Transport option received back 1729 from the LMA in the resulting Association Acknowledgement indicates a 1730 single, selected forwarding approach in one Data Transport Method 1731 field. 1733 The LMA List conceptually contains the following fields for each LMA 1734 entry: 1736 * The LMA handle of the LMA. 1738 * One or more IP address(es) of the LMA. The LMA's IP address 1739 information is acquired through the LMA selection policy, which is 1740 out of scope of this specification. Availability of multiple LMA 1741 IP addresses could support operation of multi-homed LMAs. Details 1742 about how to handle multiple LMA IP addresses is out of scope of 1743 this specification. Message sequence numbers are per MAG - LMA 1744 association, based on MAG and LMA handles, not per IP address. 1746 * The selected forwarding approach for the association with an LMA. 1747 This field is needed in case a single forwarding approach is set 1748 up for the association with an LMA. 1750 Each MAG MAY maintain a list of available LMAs. Such a list can 1751 support the LMA selection procedure and the MAG's association 1752 procedure. 1754 The list of available LMAs comprises conceptually the following 1755 fields for each LMA: 1757 * The LMA handle of the LMA. 1759 * One or more IP address(es) of the LMA. Availability of multiple 1760 IP addresses could support the operation of multi-homed LMAs. 1761 Details about how to handle multiple IP addresses is out of scope 1762 of this specification. 1764 7.1.2. Processing NetLMM Headers 1766 * The Type field MUST have a known value (Section 5.1). Otherwise, 1767 the receiving node MUST discard the message and respond with an 1768 Error message with Status field set to "Invalid Message" ). 1770 7.1.3. Association Procedure 1772 Each Mobile Access Gateway sends an Association Request message in 1773 order to set up the control and data plane relationship with a given 1774 local mobility anchor. The actual trigger for this message is out of 1775 scope of this document and may depend on network configuration 1776 peculiarities. For example, the Association Request message may be 1777 sent during the MAG start up procedure. 1779 The Association Request message MUST include: 1781 * the MAG handle included in a NetLMM ID option. This identifier is 1782 used by the peer to identify the MAG and is included in all 1783 subsequent messages. 1785 * the MAG's capabilities in terms of support of data transport 1786 methods included in a NetLMM Data Transport Option. The MAG MUST 1787 insert in this option all possible tunneling methods that can be 1788 used with the peer LMA. Based on configuration, it is possible 1789 that some tunneling methods are used only with some LMAs: in this 1790 case, the Association Request message MUST contain only the 1791 tunneling methods that are administratively permitted with that 1792 specific LMA. 1794 When sending an Association Request, the MAG MAY create a tentative 1795 entry in its LMA List, including the LMA handle, IP address of the 1796 LMA and the proposed forwarding capabilities. However it may be that 1797 the MAG does not know these data during the association procedure: in 1798 this case, it does not create any tentative entry in the LMA List. 1800 In order to complete the NetLMM association, the MAG MUST receive an 1801 Association Acknowledgement from the peer LMA with status 1, 1802 "Success". In this case, the MAG MUST create an entry in its LMA 1803 List (or update the tentative entry created earlier), with the 1804 messages sent by the LMA in the acknowledgement. The MAG MUST also 1805 update the forwarding method to the one indicated in the 1806 acknowledgement. 1808 7.1.4. Disassociate Procedure 1810 The Disassociation Request can be sent both by the MAG and by the LMA 1811 in order to tear down the control and data plane relationship between 1812 MAG and LMA. The event that triggers this message is out of the 1813 scope of this specification; for example, the MAG may send a 1814 Disassociation Request to all the LMAs present in its LMA List just 1815 before shutting down. 1817 In case the Disassociate Procedure is initiated by the MAG, the MAG 1818 MUST include an ID Option with the its identity in the Disassociation 1819 Request. When sending the Disassociation Request, the MAG MAY set 1820 the LMA entry related to the specific LMA as tentative. When it 1821 receives an acknowledgement with status 1, "Success", the MAG MUST 1822 delete the correspondent entry in its LMA List. 1824 In case the Disassociate Procedure is initiated by the LMA, when the 1825 MAG receives a Disassociation Request message, it MUST validate it. 1826 If it is correct, it MUST delete the related entry in its LMA List 1827 and send an acknowledgement with status 1, "Success". As in all 1828 NetLMM messages, the MAG MUST include the ID option with its 1829 identity. 1831 7.1.5. MN network access procedure 1833 When a new MN attaches to the network, the Mobile Access Gateway 1834 receives an indication. This indication can be received by very 1835 different means (e.g., L2 mechanisms, AAA infrastructure) that are 1836 out of scope of this specification. In any case, regardless how this 1837 is accomplished, the MAG receives a MN_Access_Network API event that 1838 carries the MN identifier (e.g., MAC address of the MN, NAI) and the 1839 LMA handle. 1841 Upon the API notification, the MAG MUST send a Location Registration 1842 message to the LMA including its own handle, the handle of the LMA, 1843 and the identity of the MN. How the MAG resolves the LMA handle 1844 received in the API into the LMA IP address is out of scope of this 1845 specification and is part of the NetLMM bootstrapping procedure. 1846 Viable options are pre-configuration or DNS resolution (in case the 1847 LMA handle is the FQDN of the LMA). In case there is only one LMA in 1848 the local domain, this issue does not exist. 1850 If the location registration is successfully performed, the MAG 1851 receives an Location Registration Acknowledgement message from the 1852 LMA with Status 1, "Success". This message also may include a NetLMM 1853 Network Prefix that the MAG MUST use for any mechanism it provides 1854 for MN address allocation, e.g., when building a Router Advertisement 1855 if IPv6 stateless address configuration is used. (See [I-D.ietf- 1856 netlmm-mn-ar-if] for a more detailed description of this case). 1858 The MN can acquire an address through stateless address assignment, 1859 or acquire an address or prefix delegation trough stateful address 1860 assignment, for instance DHCP. When using DHCP, the MAG SHOULD be 1861 configured to act as a DHCP relay. In this case, the MAG may have to 1862 add DHCP options to ensure that address allocation or prefix 1863 delegation is done from the correct address pool, and to ensure that 1864 there is a known binding between the MN ID and the allocated address 1865 or delegated prefix. If DHCP address allocation with the MAG as DHCP 1866 relay occurs after the initial Location Registration message, the MAG 1867 has to send a supplementary Location Registration message which 1868 informs the LMA about the additional address allocation or prefix 1869 delegation received from the DHCP server. 1871 7.1.6. MAG to MAG handover procedure 1873 When a MN hands over from one MAG to another, the new MAG may not 1874 know if the event occurred is a handover or a network attach. This 1875 is because the base protocol specified in this document is agnostic 1876 with respect to any MAG to MAG communication that may be in place. 1877 Due to this reason, as for network attach, the MAG will just receive 1878 a trigger that a new MN has attached to the link; this trigger, 1879 referred to as a MN_Access_Network API event carries the MN ID and 1880 the LMA handle. As mentioned above, this API event can be for 1881 example based on an AAA exchange. 1883 After receiving this API event, the MAG performs the same procedure 1884 as described for network access (see Section 7.1.5): it sends a 1885 Location Registration message containing the MN ID, the MAG handle 1886 and the LMA handle and receives the Acknowledgement of the Location 1887 Registration message, which includes the Prefixes allocated to and 1888 delegated to the MN. 1890 7.1.7. Resource Revocation 1892 If the MAG receives a Location Deregistration message from the LMA, 1893 it MUST delete the entry related to the MN specified in the MN ID 1894 Option in its Routing Cache. Moreover, the MAG MUST remove any 1895 forwarding state for the MN. After doing that, the MAG MUST send an 1896 acknowledgement of the Location Deregistration message to the LMA 1897 with Status 1, "Success". 1899 In case the Location Deregistration contains a Deregistration Timeout 1900 option, the MAG MAY keep forwarding uplink packets to the LMA for the 1901 MN. This may be useful in case of make before break link layer 1902 technologies. The adopted timeout cannot be greater than the one 1903 suggested by the LMA and MUST be sent back to the LMA in the Location 1904 Deregistration message Acknowledgement. 1906 7.1.8. Network Detachment 1908 A MAG does not take any action if it detects that a mobile node 1909 detaches, but instead waits for a Location Deregistration message 1910 from the LMA, which will be sent by the LMA once the mobile node has 1911 attached through another MAG. There will however be cases where a 1912 mobile node is taken out of operation, and never re-attaches to 1913 another MAG. In order to handle such cases, a MAG MUST implement 1914 some form of garbage collection of mobile node related state on a 1915 Least Recently Used (LRU) basis. This may be done by simply purging 1916 the oldest mobile node state entries, but this is not recommended. 1917 It is RECOMMENDED to instead purge state for mobile nodes which has 1918 least recently sent or received user traffic, and to do this when the 1919 remaining available resources fall below a threshold, rather than 1920 after fixed or configurable time has elapsed. 1922 7.2. Local Mobility Anchor Operation 1924 7.2.1. Conceptual Data Structures 1926 Each LMA MUST maintain a NetLMM Routing Cache and a MAG List. 1928 Each LMA Routing Cache entry conceptually contains the following 1929 fields for each MN: 1931 * The MN ID of the registered MN. This Identifier is acquired 1932 through the Location Registration message, which registers an 1933 attached MN. 1935 * The MAG handle of the registered MN's serving MAG. This 1936 identifier is acquired through the Location Registration message, 1937 which registers an attached MN. Dependent on the context of this 1938 message, the MAG handle entry is either initialized, or updated in 1939 case of a handover. The MAG handle can be linked to the 1940 associated MAG's IP address with the help of the MAG List. 1942 * One or more global IP addresses or address prefixes of a 1943 registered MN. Each IP address or prefix is allocated by the LMA 1944 or on request of the LMA. The MAG is informed about the allocated 1945 address or prefix in the Location Registration Ack message. 1947 Each LMA MUST maintain a MAG List, which refers to associated MAG 1948 entities. The list of associated MAGs is used to perform heartbeat 1949 tests and to map the Routing Cache's MAG handle entries to the 1950 associated MAG's IP address(es). The MAG List also supports the 1951 procedure of bulk deregistrations towards all or a subset of 1952 associated MAGs. 1954 The MAG List also indicates the forwarding approach which has been 1955 selected for the association between the LMA and a particular MAG. 1956 During the association procedure, an LMA selects a forwarding 1957 approach from the MAG's full set of forwarding capabilities. The LMA 1958 receives a MAG's full set of forwarding capabilities in decreasing 1959 order of preferences in a Data Transport option with the Association 1960 message. The LMA could selects the first forwarding approach which 1961 suits the LMA's forwarding capabilities, starting with the MAG's most 1962 preferable forwarding approach as indicated in the first Data 1963 Transport Method field of the Data Transport option. Other selection 1964 schemes are allowed and optional. The LMA indicates the selected 1965 forwarding approach back to the MAG in the Association 1966 Acknowledgement, which carries a Data Transport option with a single 1967 Data Transport Method field. 1969 The MAG List conceptually contains the following fields for each 1970 associated MAG: 1972 * The MAG handle of the associated MAG. 1974 * One or more IP address(es) of the associated MAG. The MAG's IP 1975 address information is acquired through the Associate message. 1976 Availability of multiple MAG IP addresses could support operation 1977 of multi-homed MAGs. Details about how to handle multiple MAG IP 1978 addresses is out of scope of this specification. Message sequence 1979 numbers are per MAG - LMA association, based on MAG and LMA 1980 handles, not per IP address. 1982 * The forwarding capabilities of the associated MAG. This 1983 capability list is acquired from a particular MAG through the 1984 Associate message. From the list of supported forwarding 1985 approaches, the LMA enters only the approaches to the capabilities 1986 which are supported by the LMA. 1988 * The forwarding setting for the associated MAG. This field is 1989 needed in case the LMA configures a single forwarding approach per 1990 MAG association. 1992 7.2.2. Processing NetLMM Headers 1994 All NetLMM local mobility anchors MUST observe the rules described in 1995 Section 7.1.2 when processing NetLMM Headers. 1997 7.2.3. Association Procedure 1999 When a LMA receives an Association Request message, it MUST look up 2000 in its MAG list the MAG handle contained in the ID option included in 2001 the request. If an entry for that MAG handle is already present in 2002 the MAG list, the LMA MUST send an acknowledgement to the MAG with 2003 status "Already Associated", and log the event. 2005 If an entry for the MAG handle contained in the ID option does not 2006 exist, the LMA MUST create it, including the parameters contained in 2007 the Association Request message (MAG handle, MAG IP address). Based 2008 on internal policy (e.g., pre-configuration) the LMA MAY accept the 2009 data forwarding methods proposed by the MAG or MAY indicate a 2010 specific method in the Acknowledgement. After creating the entry, 2011 the LMA MUST send an acknowledgement with STATUS value 1 ("Success") 2012 with the content described below. 2014 The Acknowledgement to the received Association Request message MUST 2015 include: 2017 * the LMA handle included in a NetLMM ID option. This identifier is 2018 used by the peer to identify the LMA and is included in all 2019 subsequent messages. 2021 * the MAG handle as received from the requesting MAG in the 2022 Association Request message. 2024 * the Data Transport option with the selected data transport method. 2025 The LMA MUST select one forwarding approach from the list of 2026 capabilities as received in the Association Request message. 2028 * the Status option, indicating the result of processing the 2029 Association Request message. 2031 7.2.4. Disassociation Procedure 2033 In case the Disassociate procedure is initiated by the MAG, the LMA 2034 MUST validate any Disassociation Request message it receives. If it 2035 is correct, it MUST delete the related entry in its MAG List, mark 2036 related MN entries in its Routing Cache as unroutable, and send an 2037 Acknowledgement with status 1, "Success". As in all NetLMM messages, 2038 the LMA MUST include the ID option with its identity. If the LMA 2039 does not have an entry in the MAG list, it MUST respond with status 2040 "Not Associated", and log the event. 2042 In case the Disassociate Procedure is initiated by the LMA the LMA 2043 MUST include an ID Option with the its identity in the Disassociation 2044 Request. When sending the Disassociation Request, the LMA MAY set 2045 the MAG entry related to the specific MAG as tentative. When it 2046 receives an acknowledgement with status 1, "Success", the LMA MUST 2047 delete the correspondent entry in its MAG List, and mark all related 2048 MN entries in its Routing Cache as unroutable. 2050 7.2.5. MN network access procedure 2052 When the local mobility anchor receives a Location Registration 2053 message, it MUST validate it. If the LMA does not have an entry the 2054 MAG list, it MUST respond with status "Not Associated", and log the 2055 event. If the message is badly formed, it MUST respond with status 2056 "Invalid Message" and log the event. If the message is valid, it 2057 MUST check if an entry for the MN identifier included in the Location 2058 Registration is present. If an entry is already present, it means 2059 that a MAG to MAG handover has occurred: the detailed procedure for 2060 this event is described in Section 7.2.7. 2062 If an entry for that MN identifier is not present, the LMA MUST 2063 create a new entry with the MN ID and the MAG handle. After creating 2064 the entry, it MUST send an acknowledgement of the Location 2065 Registration message, with status 1, "Success", including MN ID, LMA 2066 handle, MAG handle. If the Location Registration message contained 2067 one or more Prefix Allocation or Prefix Delegation Options the LMA 2068 registers these in the Routing Cache, otherwise it allocates a prefix 2069 which it associates with the MN ID and returns this prefix to the MAG 2070 as part of the Location Registration Acknowledgement. In this case, 2071 the returned prefix MUST be used by the MAG for any mechanism it 2072 provides for MN address allocation, e.g., when building a Router 2073 Advertisement if IPv6 stateless address configuration is used. (See 2074 [I-D.ietf-netlmm-mn-ar-if] for a more detailed description of this 2075 case). 2077 In case the Location Registration is not valid or the registration 2078 procedure cannot be completed successfully, the LMA MUST send a 2079 Acknowledgement with an appropriate Status value. 2081 7.2.6. MN IP address notification procedure 2083 At any time while it is attached to the network, the MN may also 2084 acquire additional addresses, through DHCP or link-specific means. 2085 If this occurs, the MAG will send a new Location Registration message 2086 to inform the LMA about the current set of addresses and prefixes 2087 allocated and / or delegated to the MN. When receiving such a 2088 Location Registration message, the LMA replaces the existing set of 2089 Routing Cache entries for the given MN ID with the new set taken from 2090 the Location Registration message. 2092 7.2.7. MAG to MAG handover procedure 2094 When the LMA receives a Location Registration message, it MUST check 2095 in its Routing Cache if an entry for the MN ID carried in the message 2096 is already present. If it is not, that means that the MN is 2097 accessing the network for the first time (see Section 7.2.5). If an 2098 entry is already present in the Routing Cache, a handover has 2099 occurred. In either case, the LMA MUST send back an Acknowledgement 2100 of the Location Registration message with Status value set to 1, 2101 "Success", including Prefix options which specifies the prefixes 2102 allocated and /or delegated to the MN. 2104 7.2.8. Resource Revocation 2106 There are cases (e.g., due to administrative reasons) where the 2107 forwarding state of a specific MN must be purged so that the MN is no 2108 more able to use the resources provided by the network. In this 2109 case, based on a trigger received from the network (e.g. AAA), the 2110 LMA MUST send a Location Deregistration message to the peer MAG, 2111 including the MN ID, the LMA handle and the MAG handle. Optionally, 2112 the LMA MAY include a Deregistration Timeout option specifying the 2113 remaining time to keep the state of the MN in the MAG. 2115 The revocation procedure terminates when the LMA receives an 2116 Acknowledgement of the Resource Revocation message with status 1, 2117 "Success". 2119 7.2.9. Network Detachment 2121 If a mobile node is taken out of operation, and never re-attaches to 2122 another MAG, the routing state of the LMA will by default remain 2123 unchanged and un-purged. In order to handle such cases, a LMA MUST 2124 implement some form of garbage collection of mobile node related 2125 state on a Least Recently Used (LRU) basis. This may be done by 2126 simply purging the oldest mobile node state entries, but this is not 2127 recommended. It is RECOMMENDED to instead purge state for mobile 2128 nodes which has least recently sent or received user traffic, and to 2129 do this when the remaining available resources fall below a 2130 threshold, rather than after fixed or configurable time has elapsed. 2132 8. Data Transport 2134 As soon as a particular MAG has associated with an LMA and an 2135 attached MN has been registered with the LMA, the LMA node and the 2136 MAG node are responsible for forwarding the MN's data traffic 2137 correctly within the NetLMM domain. Associated location and 2138 forwarding information is maintained within the LMA's and the MAG's 2139 Routing Cache. Different forwarding mechanisms between the LMA node 2140 and a particular MAG node might be supported and set up during the 2141 MAG's association procedure. 2143 Network entities which have Version 1 of the NetLMM protocol 2144 implemented, MUST support IPv6-in-IPv6 encapsulation [RFC2473] to 2145 tunnel data packets between an LMA node and an associated MAG node. 2146 Support of other forwarding approaches are for future extensions. 2148 8.1. Forwarding of Unicast Data Packets 2150 8.1.1. Handling of hop limit field in IPv6 data packets 2152 According to the NetLMM default mechanism for forwarding data packets 2153 between a particular LMA and a MAG by means of encapsulation, LMA 2154 nodes and MAG nodes serve as tunnel entry-points and tunnel exit- 2155 points respectively. LMAs and MAGs have to decrement the hop limit 2156 field of the encapsulated IPv6 header properly. The MAG serves as 2157 the default gateway for an attached MN and forwards all packets from 2158 the MN into the tunnel, which in turn encapsulates the packet towards 2159 the LMA. The LMA on receiving the packet from the MAG decapsulates 2160 and forwards the packet using normal forwarding procedures. The 2161 packets destined towards the MN are forwarded in a similar fashion. 2162 The procedure of forwarding the packet decrements the hop limit. 2163 Hence, the hop limit will get decremented twice for any packet 2164 traversing the tunnel between LMA and MAG, once at the LMA and once 2165 at the MAG. 2167 8.1.2. IPv6-in-IPv6 tunnel 2169 LMA and MAG nodes MUST support IPv6-in-IPv6 encapsulation according 2170 to RFC 2473 [RFC2473] for forwarding packets within the NetLMM 2171 domain. Support of other forwarding schemes is optional. When an 2172 LMA node receives an IPv6 packet destined for a registered MN and 2173 IPv6-in-IPv6 tunneling has been selected as forwarding approach, it 2174 serves as tunnel entry-point. The LMA node decrements the hop limit 2175 of the data packet's IPv6 header by one and encapsulates the packet 2176 in the tunnel IPv6 header. The tunnel IPv6 header might carry one or 2177 more extension headers. The LMA node forwards the tunnel packet to 2178 the MAG node, using its own address as source address and the MAG 2179 node's address as destination address in the outer IPv6 header. The 2180 MAG node terminates the tunnel and MUST process relevant Extension 2181 Headers, which might follow the encapsulating IPv6 header. The MAG 2182 node forwards the data packet towards the MN after decapsulation. 2184 To forward uplink packets, the MAG node serves as tunnel entry-point 2185 and decrements the data packet's hop limit field by one before it 2186 encapsulates the packet in the tunnel IPv6 header. The tunnel IPv6 2187 header might carry one or more extension headers. The MAG node 2188 forwards the tunnel packet to the LMA node, using its own address as 2189 source address and the LMA node's address as destination address in 2190 the outer IPv6 header. The LMA node terminates the tunnel and MUST 2191 process relevant Extension Headers, which might follow the 2192 encapsulating IPv6 header. The LMA node forwards the data packet 2193 towards its final destination after decapsulation. 2195 8.2. Forwarding of Multicast Data Packets 2197 8.2.1. Link Local Multicast 2199 The scope of link local multicast packets is confined to the link 2200 between MNs and the associated MAG node. 2202 8.2.2. IP Multicast 2204 The following options have been identified to support IP multicast 2205 within a NetLMM domain. 2207 Native mode: This option implies that MAG nodes are multicast- 2208 enabled routers and support for IP multicast is orthogonal to the 2209 NetLMM protocol operation. According to native multicast support, 2210 access routers terminate a multicast tree and the LMA node does 2211 not play any multicast-specific role in forwarding of IP multicast 2212 traffic. 2214 Tunnel mode: This option implies that MAG nodes and LMA nodes are 2215 both multicast-enabled routers and the IP multicast traffic is 2216 tunnelled via the two NetLMM nodes. IP Multicast protocol is used 2217 on the tunnel between the MAG nodes and LMA nodes to set up the 2218 multicast forwarding path. 2220 MAG nodes must coordinate multicast listeners according to MLD 2221 operation [RFC2710] and communicate with other multicast-enabled 2222 routers using IP Multicast protocol (e.g. PIM, based on RFC 2362). 2223 The MAG nodes send multicast control messages in the tunnel or on the 2224 connected interface to reach the LMA nodes or other routers, 2225 respectively. This establishes the multicast forwarding path for 2226 directing multicast packets to the listeners. An example of a IP 2227 multicast join procedure is illustrated in Figure 5. By default, the 2228 native mode of operation is REQUIRED. 2230 +--+ +---+ +---+ +--+ 2231 |MN| |MAG| |LMA| |MR| 2232 +--+ +---+ +---+ +--+ 2233 | | | | 2234 | | | | 2235 |-MLD Report-->| | | 2236 | |====PIM Join===>| | 2237 | | |----PIM Join----.>| 2238 / / / / 2239 / / / / 2240 |<-------------|<===============|<-----------------|<--MC Data 2241 | | | | 2243 Figure 5: Example of IP multicast join procedure for the Tunnel Mode. 2244 The MR is a multicast-enabled router between the multicast source and 2245 the LMA node. 2247 The mobile node may be a multicast sender. The MAG nodes allow 2248 multicast packets to be received on the interface of the mobile node 2249 by successfully passing any Reverse Path Forwarding (RPF) check. All 2250 multicast packets that are sourced from the mobile node are tunneled 2251 to the LMA nodes. The RPF check on the LMA nodes should allow these 2252 packets to be received on the tunnel as well. The multicast packets 2253 are forwarded by the LMA nodes based on the multicast forwarding 2254 table, set up by IP Multicast protocol used among the routers. An 2255 example of a IP multicast source sending multicast packet to the 2256 group is illustrated in Figure 6. 2258 +--+ +---+ +---+ +--+ 2259 |MN| |MAG| |LMA| |MR| 2260 +--+ +---+ +---+ +--+ 2261 | | | | 2262 | | |<----PIM Join-----| 2263 / / / / 2264 / / / / 2265 | | | forward to group | 2266 |-- MC Data--.>|===============>|----------------.>|--.> 2267 | | | | 2269 Figure 6: Example of a mobile node sourcing multicast packets to the 2270 group. 2272 8.3. Forwarding of Broadcast Data Packets 2274 Version 1 of the NetLMM protocol specification does not consider 2275 forwarding of broadcast data packets. 2277 9. Protocol Constants and Configuration Variables 2279 10. Security Considerations 2281 The NetLMM protocol consists of messages between MAG and LMA nodes. 2282 The messages are used to create, update and delete mobility state in 2283 MAGs and LMAs. The threats are described in [I-D.ietf-netlmm- 2284 threats]. To address these threats, NetLMM protocol must support 2285 data origin authentication, integrity and replay protection on a per- 2286 packet basis. IPsec [RFC2401] MUST be implemented and SHOULD be 2287 used. 2289 There are several details that should be considered when IPsec is 2290 used for protecting the messages. 2292 The IP addresses and NETLMM-UDP-PORT SHOULD be used as selectors 2293 for identifying the control messages. By including the port, only 2294 control messages are protected with IPsec. 2296 IPsec MUST be used in transport mode between MAG and LMA. Though 2297 AH [RFC4302] provides protection for the addresses in the IP 2298 header, ESP [RFC4303] provides the same by checking the IP address 2299 against the selectors in the SAD [RFC2401]. Thus, ESP [RFC4303] 2300 with non-NULL authentication is sufficient to provide the 2301 necessary protection for the control messages. 2303 IPsec can provide anti-replay protection when dynamic keying is 2304 used. IPsec does not guarantee correct ordering of packets, only 2305 that they have not been replayed. Hence, when dynamic keying is 2306 used along with the sequence numbers in the NetLMM messages, 2307 replay and re-ordering attacks can be prevented. Note that the 2308 re-ordering attack makes sense only if the messages that are re- 2309 ordered relates to the same mobile node. IKE [RFC2409] MUST be 2310 used for dynamic keying. IKEv2 [RFC4306] MAY be supported. 2312 Dynamic keying [RFC2409], [RFC4306] supports several 2313 authentication mechanisms. Pre-shared keys are difficult to 2314 configure and maintain when the number of nodes (MAG and LMA) are 2315 large as there needs to be one pre-shared key between any possible 2316 combination of LMA and MAG. Hence, certificate based IKE 2317 authentication SHOULD be supported. This does not require a 2318 global PKI. The certificates may be signed by the local operator 2319 that deploys the netlmm service. The use of IKE with certificates 2320 including the various identities is described in [I-D.ietf- 2321 pki4ipsec-ikecert-profile] 2323 MAG can dynamically associate with any LMA in the NetLMM domain. 2324 If the LMA knows the IP addresses of all the MAG in the NetLMM 2325 domain a priori before the IKE session is setup, then the 2326 appropriate SPD entries can be setup beforehand which can be 2327 consulted before engaging in the IKE session. Even if the LMA 2328 does not have any knowledge about the IP addresses of the MAG, it 2329 can use the named SPD entry [RFC2401] and later when the IKE 2330 negotiation is successfully completed, the SPD entry can be added. 2332 IPsec provides data origin authentication based on the identity 2333 verified when the IPsec security association is setup using IKE. The 2334 identity carried within IKE is different from the ID described in 2335 this document. As part of IPsec processing, the receiver of an IPsec 2336 protected datagram verifies that the selectors from the IP header 2337 matches against the values stored in the SAD that were established 2338 during IKE. In the case of NETLMM, the IP address and the port 2339 number would be verified to be consistent with the ones that was 2340 presented during SA establishment. But this verification is not 2341 sufficient to authorize the node (LMA or MAG) to send arbitrary 2342 NetLMM messages. 2344 When the NetLMM message is processed, the source ID should be mapped 2345 to the corresponding IP address using whatever mechanism available 2346 (not described in this document) and matched against what was 2347 received in the packet. If there is a mismatch-match, the packet 2348 should be dropped. Additionally, the following checks should be 2349 performed. 2351 * The Location registration can be originated only by the MAG. 2352 Hence, the MAG MUST drop all Location Registration messages 2353 originated by the LMA. 2355 * The Location deregistration message may be originated by the MAG 2356 or LMA to delete the forwarding state. Proper authorization 2357 checks must be performed to make sure that the forwarding state is 2358 deleted only by the entity (LMA or MAG) that created it. There 2359 are two cases. 2361 - In the handover scenario, the deregistration message comes from 2362 the LMA towards the old/previous MAG. The MAG MUST check to 2363 see if the LMA handle in the deregistration request matches the 2364 value stored in the MAG Routing cache entry for the given 2365 MN-ID. 2367 - In case where the MAG detects that the MN has detached, it 2368 sends the deregistration message to the LMA. The LMA MUST 2369 check to see if the MAG-ID in the deregistration request 2370 matches the value stored in the LMA Routing cache entry for the 2371 given MN-ID. 2373 * The MAG MUST drop all associate messages coming from LMA. 2375 * It is possible to filter the signalling messages at the edge of 2376 the network so that a rogue MN or rogue node on the Internet 2377 cannot source such messages. If this is done, any messages 2378 exchanged between the MAG and LMA can only come from within the 2379 network. This level of security may be sufficient for some 2380 deployments, precluding the need for protecting the signalling 2381 messages. In such cases, IPsec may not need to be used to protect 2382 the signalling messages. 2384 11. IANA Considerations 2386 12. Contributors 2388 This contribution is a joint effort of the NetLMM design team of the 2389 NetLMM WG. The members include Kent Leung, Gerardo Giaretta, Phil 2390 Roberts, Marco Liebsch, Katsutoshi Nishida, Hidetoshi Yokota, Henrik 2391 Levkowetz, and Mohan Parthasarathy. 2393 13. Acknowledgments 2395 14. References 2397 14.1. Normative References 2399 [I-D.ietf-netlmm-mn-ar-if] 2400 Laganier, J., "Network-based Localized Mobility Management 2401 Interface between Mobile Node and Access Router", 2402 draft-ietf-netlmm-mn-ar-if-01 (work in progress), 2403 June 2006. 2405 [I-D.ietf-netlmm-nohost-ps] 2406 Kempf, J., "Problem Statement for Network-based Localized 2407 Mobility Management", draft-ietf-netlmm-nohost-ps-05 (work 2408 in progress), September 2006. 2410 [I-D.ietf-netlmm-nohost-req] 2411 Kempf, J., "Goals for Network-based Localized Mobility 2412 Management (NETLMM)", draft-ietf-netlmm-nohost-req-04 2413 (work in progress), August 2006. 2415 [I-D.ietf-netlmm-threats] 2416 Kempf, J. and C. Vogt, "Security Threats to Network-Based 2417 Localized Mobility Management", 2418 draft-ietf-netlmm-threats-04 (work in progress), 2419 September 2006. 2421 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2422 August 1980. 2424 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2425 Requirement Levels", BCP 14, RFC 2119, March 1997. 2427 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 2428 Internet Protocol", RFC 2401, November 1998. 2430 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 2431 (IKE)", RFC 2409, November 1998. 2433 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 2434 IPv6 Specification", RFC 2473, December 1998. 2436 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 2437 Schoenwaelder, Ed., "Structure of Management Information 2438 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 2440 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 2441 Listener Discovery (MLD) for IPv6", RFC 2710, 2442 October 1999. 2444 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 2445 RFC 3753, June 2004. 2447 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 2448 Neighbor Discovery (SEND)", RFC 3971, March 2005. 2450 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 2451 Network Access Identifier", RFC 4282, December 2005. 2453 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 2454 December 2005. 2456 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 2457 RFC 4303, December 2005. 2459 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 2460 RFC 4306, December 2005. 2462 [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 2463 for IPv4, IPv6 and OSI", RFC 4330, January 2006. 2465 14.2. Informative References 2467 [ENTERPRISE-NUM] 2468 IANA, "IANA Enterprise Numbers Registry"", 2006. 2470 [I-D.ietf-pki4ipsec-ikecert-profile] 2471 Korver, B., "The Internet IP Security PKI Profile of 2472 IKEv1/ISAKMP, IKEv2, and PKIX", 2473 draft-ietf-pki4ipsec-ikecert-profile-11 (work in 2474 progress), September 2006. 2476 [I-D.thaler-intarea-multilink-subnet-issues] 2477 Thaler, D., "Issues With Protocols Proposing Multilink 2478 Subnets", draft-thaler-intarea-multilink-subnet-issues-00 2479 (work in progress), March 2006. 2481 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 2482 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 2483 Zhang, L., and V. Paxson, "Stream Control Transmission 2484 Protocol", RFC 2960, October 2000. 2486 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 2487 Considered Useful", BCP 82, RFC 3692, January 2004. 2489 Appendix A. MN-AR Interface considerations 2491 This document assumes that the MN-AR interface document will describe 2492 the following in more detail: 2494 * - A mechanism for indicating duplicate address to the MN 2496 * - No redirects should be sent by MAG to MN even if the destination 2497 is directly connected to MAG 2499 * - Trigger for IP address configuration 2501 * - MN Identifier option in the trigger ? 2503 * - If SEND is used, Proxy SEND details are needed for defending the 2504 address in the case of a duplicate 2506 * - Router advertisement details : unicast only, what else does it 2507 contain etc." 2509 Appendix B. Issues with omitting the MN Address Setup and Routing Setup 2511 The design team currently considers optimization of the handover 2512 related signaling. This focuses in particular on reducing the 2513 handover signaling from two handshakes to one handshake between the 2514 nMAG and the LMA. The 00 version of the draft specifies different 2515 messages to notify the arrival of an MN to the LMA by means of 2516 indicating the MNID (Location Registration) and to setup routing 2517 states by means of indicating the MN's IP address information (MN 2518 Address Setup and Routing Setup). 2520 In most handover cases, explicit signaling of the MN's IP address by 2521 means of the MN Address Setup and Routing Setup is not required in 2522 case the Location Registration Req/Ack could append IP Address 2523 options. This brings up the question whether or not NetLMM operation 2524 needs the MN Address Setup message at all. 2526 The MN Address Setup has been specified in particular to notify an 2527 MN's IP address from a MAG to the LMA, which includes adding new IP 2528 addresses to an existing state at the LMA. Referring to the agreed 2529 per-MN Prefix addressing model for NetLMM, the LMA and MAG could take 2530 routing decisions solely based on the MN's prefix. Since delegation 2531 of the MN's prefix is performed through the LMA, which notifies the 2532 MN through the MAG about the assigned prefix, the LMA is aware of the 2533 MN's (delegated) prefix after having sent the Location Registration 2534 Acknowledgement. Sending the MN's full IP address back to the LMA by 2535 means of the MN Address Setup message is required only if the LMA 2536 takes routing decisions on the full IP address. Other reasons might 2537 exist. 2539 As taking routing decisions on the LMA based on the full IP address 2540 is only mandatory for the shared prefix addressing model, which is 2541 not supported in the base NetLMM protocol, the design team considers 2542 omitting the MN Address Setup message. However, explicit 2543 notification of the MN's full IP address could still be done by means 2544 of appending the NetLMM Address option to an existing message, such 2545 as the Location Registration message. Such an approach conceptually 2546 overloads the Location Registration message and eliminates the 2547 conceptual split between messages handling IDs and routing 2548 information. The design team should take a decision from the 2549 following approaches: 2551 1. Keep MN Address Setup and Routing Setup messages and specify an 2552 approach to piggyback these messages with a Location Registration 2553 Req/Ack. 2555 2. Keep MN Address Setup and Routing Setup messages to be flexible 2556 for specific scenarios, such as notification of the full MN IP 2557 address to the LMA, but allow overloading the Location 2558 Registration (append NetLMM Address options). 2560 3. Omit the MN Address Setup message and allow overload the Location 2561 Registration message (append NetLMM Address options). 2563 4. Other alternatives. 2565 Appendix C. Out of scope 2567 * Inter-MAP handover 2569 * Fast handover 2571 * Hierarchical MAP 2573 Authors' Addresses 2575 Henrik Levkowetz (editor) 2576 Ericsson 2577 Torsgatan 71 2578 Stockholm S-113 37 2579 SWEDEN 2581 Phone: +46 708 32 16 08 2582 Email: henrik@levkowetz.com 2584 Gerardo Giaretta 2585 Telecom Italia 2586 via Reiss Romoli 274 2587 Torino 10148 2588 Italy 2590 Phone: +39 011 228 6904 2591 Email: gerardo.giaretta@telecomitalia.it 2593 Kent Leung 2594 Cisco 2595 170 W. Tasman Drive 2596 San Jose, CA 95134 2597 USA 2599 Phone: +1 408 853 9580 2600 Email: kleung@cisco.com 2602 Marco Liebsch 2603 NEC Network Laboratories 2604 Kurfuersten-Anlage 36 2605 Heidelberg, 69115 2606 Germany 2608 Phone: +49 6221-90511-46 2609 Email: marco.liebsch@netlab.nec.de 2610 Phil Roberts 2611 Motorola 2612 1301 E Algonquin Rd 2613 Schaumberg, IL 60196 2614 USA 2616 Email: phil.roberts@motorola.com 2618 Katsutoshi Nishida 2619 NTT DoCoMo Inc. 2620 3-5 Hikarino-oka, Yokosuka-shi 2621 Kanagawa, 2622 Japan 2624 Phone: +81 46 840 3545 2625 Email: nishidak@nttdocomo.co.jp 2627 Hidetoshi Yokota 2628 KDDI R&D Laboratories, Inc. 2629 2-1-15 Ohara, Fujimino 2630 Saitama, 356-8502 2631 Japan 2633 Phone: +81 49 278 7894 2634 Email: yokota@kddilabs.jp 2636 Mohan Parthasarathy 2637 Nokia 2639 Email: mohan.parthasarathy@nokia.com 2641 Intellectual Property Statement 2643 The IETF takes no position regarding the validity or scope of any 2644 Intellectual Property Rights or other rights that might be claimed to 2645 pertain to the implementation or use of the technology described in 2646 this document or the extent to which any license under such rights 2647 might or might not be available; nor does it represent that it has 2648 made any independent effort to identify any such rights. Information 2649 on the procedures with respect to rights in RFC documents can be 2650 found in BCP 78 and BCP 79. 2652 Copies of IPR disclosures made to the IETF Secretariat and any 2653 assurances of licenses to be made available, or the result of an 2654 attempt made to obtain a general license or permission for the use of 2655 such proprietary rights by implementers or users of this 2656 specification can be obtained from the IETF on-line IPR repository at 2657 http://www.ietf.org/ipr. 2659 The IETF invites any interested party to bring to its attention any 2660 copyrights, patents or patent applications, or other proprietary 2661 rights that may cover technology that may be required to implement 2662 this standard. Please address the information to the IETF at 2663 ietf-ipr@ietf.org. 2665 Disclaimer of Validity 2667 This document and the information contained herein are provided on an 2668 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2669 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2670 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2671 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2672 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2673 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2675 Copyright Statement 2677 Copyright (C) The Internet Society (2006). This document is subject 2678 to the rights, licenses and restrictions contained in BCP 78, and 2679 except as set forth therein, the authors retain all their rights.