idnits 2.17.1 draft-ietf-mipshop-4140bis-05.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1094. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1105. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1112. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1118. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 25, 2008) is 5747 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: 'RFC4861' is defined on line 1013, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Soliman 3 Internet-Draft Elevate Technologies 4 Intended status: Standards Track C. Castelluccia 5 Expires: January 26, 2009 INRIA 6 K. ElMalki 7 Athonet 8 L. Bellier 9 INRIA 10 July 25, 2008 12 Hierarchical Mobile IPv6 Mobility Management 13 draft-ietf-mipshop-4140bis-05 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 26, 2009. 40 Abstract 42 This document introduces extensions to Mobile IPv6 and IPv6 Neighbour 43 Discovery to allow for local mobility handling. Hierarchical 44 mobility management for Mobile IPv6 is designed to reduce the amount 45 of signalling between the Mobile Node, its Correspondent Nodes, and 46 its Home Agent. The Mobility Anchor Point (MAP) described in this 47 document can also be used to improve the performance of Mobile IPv6 48 in terms of handover speed. 50 Table of Contents 52 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Overview of HMIPv6 . . . . . . . . . . . . . . . . . . . . . . 6 55 3.1. HMIPv6 Operations . . . . . . . . . . . . . . . . . . . . 6 56 4. Mobile IPv6 Extension - Local Binding update . . . . . . . . . 9 57 5. Neighbour Discovery Extension: The MAP Option . . . . . . . . 10 58 6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 12 59 6.1. Mobile Node Operation . . . . . . . . . . . . . . . . . . 12 60 6.1.1. Sending Packets to Correspondent Nodes . . . . . . . . 13 61 6.2. MAP Operations . . . . . . . . . . . . . . . . . . . . . . 14 62 6.3. Home Agent Operations . . . . . . . . . . . . . . . . . . 14 63 6.4. Correspondent Node Operations . . . . . . . . . . . . . . 15 64 6.5. Local Mobility Management Optimisation within a MAP 65 Domain . . . . . . . . . . . . . . . . . . . . . . . . . . 15 66 6.6. Location Privacy . . . . . . . . . . . . . . . . . . . . . 15 67 7. MAP Discovery . . . . . . . . . . . . . . . . . . . . . . . . 16 68 7.1. Mobile Node Operation . . . . . . . . . . . . . . . . . . 16 69 8. Updating Previous MAPs . . . . . . . . . . . . . . . . . . . . 17 70 9. Note On MAP Selection by the Mobile Node . . . . . . . . . . . 18 71 9.1. MAP Selection in Distributed MAP Environment . . . . . . . 18 72 9.2. MAP Selection in a Flat Mobility Architecture. . . . . . . 19 73 10. Detection and Recovery from MAP Failures . . . . . . . . . . . 21 74 11. Tunelling impacts on MTU . . . . . . . . . . . . . . . . . . . 23 75 12. Security Considerations . . . . . . . . . . . . . . . . . . . 24 76 12.1. Mobile Node - MAP Security . . . . . . . . . . . . . . . . 24 77 12.2. Mobile Node - Correspondent Node Security . . . . . . . . 26 78 12.3. Mobile Node - Home Agent Security . . . . . . . . . . . . 26 79 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 80 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 81 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 82 15.1. Normative References . . . . . . . . . . . . . . . . . . . 29 83 15.2. Informative References . . . . . . . . . . . . . . . . . . 29 84 Appendix A. Appendix A - Changes from RFC 4140 . . . . . . . . . 30 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 86 Intellectual Property and Copyright Statements . . . . . . . . . . 32 88 1. Requirements notation 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 In addition, the following terms are introduced: 96 Access Router (AR) 98 The AR is the Mobile Node's default router. The AR aggregates the 99 outbound traffic of mobile nodes. 101 Mobility Anchor Point (MAP) 103 A Mobility Anchor Point is a router located in a network visited 104 by the mobile node. The MAP is used by the MN as a local HA. One 105 or more MAPs can exist within a visited network. 107 Regional Care-of Address (RCoA) 109 An RCoA is an address allocated by the MAP to the mobile node. 111 HMIPv6-Aware Mobile Node 113 An HMIPv6-aware mobile node is a mobile node that can receive and 114 process the MAP option received from its default router. An 115 HMIPv6-aware Mobile Node must also be able to send local binding 116 updates (Binding Update with the M flag set). 118 On-Link Care-of Address 120 The LCoA is the on-link CoA configured on a mobile node's 121 interface based on the prefix advertised by its default router. 122 In [RFC3775], this is simply referred to as the Care-of- address. 123 However, in this memo LCoA is used to distinguish it from the 124 RCoA. 126 Local Binding Update 128 The MN sends a Local Binding Update to the MAP in order to 129 establish a binding between the RCoA and LCoA. 131 2. Introduction 133 This specification introduces the concept of a Hierarchical Mobile 134 IPv6 network, utilising a new node called the Mobility Anchor Point 135 (MAP). 137 Mobile IPv6 [RFC3775] allows nodes to move within the Internet 138 topology while maintaining reachability and on-going connections 139 between mobile and correspondent nodes. To do this a mobile node 140 sends Binding Updates (BUs) to its Home Agent (HA) every time it 141 moves. 143 The mobile node may send data packets via its Home Agent immediately 144 after sending the Binding Update, but the Home Agent will not be able 145 to route traffic back to the mobile node before it receives the 146 Binding Update. This incurs at least half a round-trip delay before 147 packets are again forwarded to the right place. There is an 148 additional delay for sending data packets if the mobile node chooses 149 to wait for a Binding Acknowledgement (BA). The round-trip times can 150 be relatively long, if the mobile node and its home agent are in 151 different parts of the world. 153 Additional delay is also incurred if the mobile node employs route 154 optimization. Authenticating binding updates requires approximately 155 1.5 round-trip times between the mobile node and each correspondent 156 node (for the entire return routability procedure in a best case 157 scenario, i.e., no packet loss). This can be done in parallel with 158 sending Binding Updates to the Home agent, and there are further 159 optimizations that reduce the required 1.5 round-trips [RFC4449] 160 [RFC4651] [RFC4866]. 162 Nevertheless, the signaling exchanges required to update your 163 location will always cause some disruption to active connections. 164 Some packets will be lost. Together with link layer and IP layer 165 connection setup delays there may be effects to upper layer 166 protocols. Reducing these delays during the time-critical handover 167 period will improve the performance of Mobile IPv6. 169 Moreover, in the case of wireless links, such a solution reduces the 170 number of messages sent over the air interface to all correspondent 171 nodes and the Home Agent. A local anchor point will also allow 172 Mobile IPv6 to benefit from reduced mobility signalling with external 173 networks. 175 For these reasons a new Mobile IPv6 node, called the Mobility Anchor 176 Point, is used and can be located at any level in a hierarchical 177 network of routers, including the Access Router (AR). The MAP will 178 limit the amount of Mobile IPv6 signalling outside the local domain. 180 The introduction of the MAP provides a solution to the issues 181 outlined earlier in the following way: 183 o The mobile node sends Binding Updates to the local MAP rather than 184 the HA (which is typically further away) and CNs. 186 o Only one Binding Update message needs to be transmitted by the MN 187 before traffic from the HA and all CNs is re-routed to its new 188 location. This is independent of the number of CNs that the MN is 189 communicating with. 191 A MAP is essentially a local Home Agent. The aim of introducing the 192 hierarchical mobility management model in Mobile IPv6 is to enhance 193 the performance of Mobile IPv6 while minimising the impact on Mobile 194 IPv6 or other IPv6 protocols. Furthermore, HMIPv6 allows mobile 195 nodes to hide their location from correspondent nodes and Home Agents 196 while using Mobile IPv6 route optimisation. The security differences 197 between the MAP and the Home Agent are described in Section 12 199 It is pertinent to note that the use of the MAP does not rely on or 200 assume the presence of a permanent Home Agent. In other words, a 201 mobile node need not have a permanent Home address or Home Agent in 202 order to be HMIPv6-aware or use the features in this specification. 203 A MAP may be used by a mobile node in a nomadic manner to achieve 204 mobility management within a local domain. Section 6.5 describes 205 such scenario. 207 3. Overview of HMIPv6 209 This Hierarchical Mobile IPv6 scheme introduces a new function, the 210 MAP, and minor extensions to the mobile node operation. The 211 correspondent node and Home Agent operation will not be affected. 213 Just like Mobile IPv6, this solution is independent of the underlying 214 access technology, allowing mobility within or between different 215 types of access networks. 217 A mobile node entering a MAP domain will receive Router 218 Advertisements containing information about one or more local MAPs. 219 The MN can bind its current location (on-link CoA) with an address on 220 the MAP's subnet (RCoA). Acting as a local HA, the MAP will receive 221 all packets on behalf of the mobile node it is serving and will 222 encapsulate and forward them directly to the mobile node's current 223 address. If the mobile node changes its current address within a 224 local MAP domain (LCoA), it only needs to register the new address 225 with the MAP. Hence, only the Regional CoA (RCoA) needs to be 226 registered with correspondent nodes and the HA. The RCoA does not 227 change as long as the MN moves within a MAP domain (see below for 228 definition). This makes the mobile node's mobility transparent to 229 correspondent nodes it communicates with. 231 A MAP domain's boundaries are defined by the Access Routers (ARs) 232 advertising the MAP information to the attached Mobile Nodes. The 233 detailed extensions to Mobile IPv6 and operations of the different 234 nodes will be explained later in this document. 236 It should be noted that the HMIPv6 concept is simply an extension to 237 the Mobile IPv6 protocol. An HMIPv6-aware mobile node with an 238 implementation of Mobile IPv6 SHOULD choose to use the MAP when 239 discovering such capability in a visited network. However, in some 240 cases the mobile node may prefer to simply use the standard Mobile 241 IPv6 implementation. For instance, the mobile node may be located in 242 a visited network within its home site. In this case, the HA is 243 located near the visited network and could be used instead of a MAP. 244 In this scenario, the mobile node would only update the HA whenever 245 it moves. The method to determine whether the HA is in the vicinity 246 of the MN (e.g., same site) is outside the scope of this document. 248 3.1. HMIPv6 Operations 250 The network architecture shown in Figure 1 illustrates an example of 251 the use of the MAP in a visited network. 253 In Figure 1, the MAP can help in providing seamless mobility for the 254 mobile node as it moves from Access Router 1 (AR1) to Access Router 2 255 (AR2), while communicating with the correspondent node. A multi- 256 level hierarchy is not required for a higher handover performance. 257 Hence, it is sufficient to locate one or more MAPs (possibly covering 258 the same domain) at any position in the operator's network. 260 +-------+ 261 | HA | 262 +-------+ +----+ 263 | | CN | 264 | +----+ 265 | | 266 +-------+-----+ 267 | 268 |RCoA 269 +-------+ 270 | MAP | 271 +-------+ 272 | | 273 | +--------+ 274 | | 275 | | 276 +-----+ +-----+ 277 | AR1 | | AR2 | 278 +-----+ +-----+ 279 LCoA1 LCoA2 281 +----+ 282 | MN | 283 +----+ ------------> 284 Movement 286 Figure 1: Hierarchical Mobile IPv6 domain 288 Upon arrival in a visited network, the mobile node will discover the 289 global address of the MAP. This address is stored in the Access 290 Routers and communicated to the mobile node via Router Advertisements 291 (RAs). A new option for RAs is defined later in this specification. 292 This is needed to inform mobile nodes about the presence of the MAP 293 (MAP discovery). The discovery phase will also inform the mobile 294 node of the distance of the MAP from the mobile node. For example, 295 the MAP function could be implemented as shown in Figure 1, and, at 296 the same time, also be implemented in AR1 and AR2. In this case the 297 mobile node can choose the first hop MAP or one further up in the 298 hierarchy of routers. The details on how to choose a MAP are 299 provided in section 10. 301 The process of MAP discovery continues as the mobile node moves from 302 one subnet to the next. Every time the mobile node detects movement, 303 it will also detect whether it is still in the same MAP domain. The 304 router advertisement used to detect movement will also inform the 305 mobile node, through neighbour discovery [RFC4861]the MAP option, 306 whether it is still in the same MAP domain. As the mobile node roams 307 within a MAP domain, it will continue to receive the same MAP option 308 included in router advertisements from its AR. If a change in the 309 advertised MAP's address is received, the mobile node MUST act on the 310 change by sending Binding Updates to its HA and correspondent nodes. 312 If the mobile node is not HMIPv6-aware, then no MAP Discovery will be 313 performed, resulting in the mobile node using the Mobile IPv6 314 [RFC3775] protocol for its mobility management. On the other hand, 315 if the mobile node is HMIPv6-aware it SHOULD choose to use its HMIPv6 316 implementation. If so, the mobile node will first need to register 317 with a MAP by sending it a BU containing its Home Address and on-link 318 address (LCoA). The Home address used in the BU is the RCoA. The 319 MAP MUST store this information in its Binding Cache to be able to 320 forward packets to their final destination when received from the 321 different correspondent nodes or HAs. 323 The mobile node will always need to know the original sender of any 324 received packets to determine if route optimisation is required. 325 This information will be available to the mobile node because the MAP 326 does not modify the contents of the original packet. Normal 327 processing of the received packets (as described in [RFC3775]) will 328 give the mobile node the necessary information. 330 To use the network bandwidth in a more efficient manner, a mobile 331 node may decide to register with more than one MAP simultaneously and 332 to use each MAP address for a specific group of correspondent nodes. 333 For example, in Fig 1, if the correspondent node happens to exist on 334 the same link as the mobile node, it would be more efficient to use 335 the first hop MAP (in this case assume it is AR1) for communication 336 between them. This will avoid sending all packets via the "highest" 337 MAP in the hierarchy and thus will result in more efficient usage of 338 network bandwidth. The mobile node can also use its current on-link 339 address (LCoA) as a CoA, as specified in [RFC3775]. Note that the 340 mobile node MUST NOT present an RCoA from a MAP's subnet as an LCoA 341 in a binding update sent to another MAP. The LCoA included in the 342 binding update MUST be the mobile node's address derived from the 343 prefix advertised on its link. 345 4. Mobile IPv6 Extension - Local Binding update 347 This section outlines the extensions proposed to the binding update 348 specified in [RFC3775]. 350 A new flag is added: the M flag, which indicates MAP registration. 351 When a mobile node registers with the MAP, the M and A flags MUST be 352 set to distinguish this registration from a BU being sent to the HA 353 or a correspondent node. 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Sequence # | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 |A|H|L|K|M| Reserved | Lifetime | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | | 363 | | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 Figure 2: Local Binding Update 368 M 370 If set to 1 it indicates a MAP registration. 372 5. Neighbour Discovery Extension: The MAP Option 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Type | Length | Dist | Pref |R| Reserved | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Valid Lifetime | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | | 382 + + 383 | | 384 + Global IP Address for MAP + 385 | | 386 + + 387 | | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 Figure 3: The MAP option 392 Type 394 IPv6 Neighbor Discovery option. 23. 396 Length 398 8-bit unsigned integer. The length of the option and MUST be set 399 to 3. 401 Dist 403 A 4-bit unsigned integer identifying the Distance Between MAP and 404 the receiver of the advertisement, measure in the number of hops 405 and starting from 1 if the MAP is on the same link as the mobile 406 node. A Distance value of Zero MUST NOT be used. 408 Pref 410 The preference field, used as an indicator of operator preference. 411 A 4-bit unsigned integer. A decimal value of 15 indicates the 412 highest preference. When comparing two potential MAPs, the mobile 413 node SHOULD inspect this field as a tie-breaker for MAPs that have 414 equal Dist values. 416 R 417 When set to 1, it indicates that the mobile node is allocated the 418 RCoA by the MAP based on section 9 of [RFC4877]. 420 Valid Lifetime 422 The minimum value (in seconds) of both the valid lifetimes of the 423 prefix used to form the MAP's address and that used to form the 424 RCoA. This value indicates the validity of the MAP's address and 425 the RCoA. 427 Global Address 429 One of the MAP's global addresses. 431 6. Protocol Operation 433 This section describes the HMIPv6 protocol. In HMIPv6, the mobile 434 node has two addresses, an RCoA on the MAP's link and an on-link CoA 435 (LCoA). This RCoA is formed in a stateless manner by combining the 436 mobile node's interface identifier and the subnet prefix received in 437 the MAP option. 439 As illustrated in this section, this protocol requires updating the 440 mobile nodes' implementation only. The HA and correspondent node are 441 unchanged. The MAP performs the function of a "local" HA that binds 442 the mobile node's RCoA to an LCoA. 444 6.1. Mobile Node Operation 446 When a mobile node moves into a new MAP domain (i.e., its MAP 447 changes), it needs to configure two CoAs: an RCoA on the MAP's link 448 and an on-link CoA (LCoA). After employing [RFC4877] to acquire an 449 RCoA, the mobile node sends a local BU to the MAP with the A and M 450 flags set. The local BU is a BU defined in [RFC3775] and includes 451 the mobile node's RCoA in the Home Address Option. No alternate-CoA 452 option is needed in this message. The LCoA is used as the source 453 address of the BU. This BU will bind the mobile node's RCoA (similar 454 to a Home Address) to its LCoA. The MAP (acting as a HA) will then 455 return a Binding Acknowledgement to the MN. This acknowledgement 456 identifies the binding as successful or contains the appropriate 457 fault code. No new error codes need to be supported by the mobile 458 node for this operation. The mobile node MUST silently ignore 459 binding acknowledgements that do not contain a routing header type 2, 460 which includes the mobile node's RCoA. 462 Following a successful registration with the MAP, a bi-directional 463 tunnel between the mobile node and the MAP is established. All 464 packets sent by the mobile node are tunnelled to the MAP. The outer 465 header contains the mobile node's LCoA in the source address field 466 and the MAP's address in the destination address field. The inner 467 header contains the mobile node's RCoA in the source address field 468 and the peer's address in the destination address field. Similarly, 469 all packets addressed to the mobile node's RCoA are intercepted by 470 the MAP and tunnelled to the mobile node's LCoA. 472 This specification allows a mobile node to use more than one RCoA if 473 it received more than one MAP option. In this case, the mobile node 474 MAY perform the binding update procedure for each RCoA. In addition, 475 the mobile node MUST NOT use one RCoA (e.g., RCoA1) derived from a 476 MAP's prefix (e.g., MAP1) as a care-of address in its binding update 477 to another MAP (e.g., MAP2). This would force packets to be 478 encapsulated several times (twice in this example) on their path to 479 the mobile node. This form of multi-level hierarchy will reduce the 480 protocol's efficiency and performance. 482 After registering with the MAP, the mobile node MUST register its new 483 RCoA with its HA by sending a BU that specifies the binding (RCoA, 484 Home Address) as in Mobile IPv6. The mobile node's Home Address is 485 used in the home address option and the RCoA is used as the care-of 486 address in the source address field. The mobile node may also send a 487 similar BU (i.e., that specifies the binding between the Home Address 488 and the RCoA) to its current correspondent nodes. 490 The mobile node SHOULD wait for the binding acknowledgement from the 491 MAP before registering the RCoA with other nodes (e.g. CN or HA, if 492 available). It should be noted that when binding the RCoA with the 493 HA and correspondent nodes, the binding lifetime MUST NOT be larger 494 than the mobile node's binding lifetime with the MAP, which is 495 received in the Binding Acknowledgement. 497 In order to speed up the handover between MAPs and reduce packet 498 loss, a mobile node SHOULD send a local BU to its previous MAP, 499 specifying its new LCoA. Packets in transit that reach the previous 500 MAP are then forwarded to the new LCoA. 502 The MAP will receive packets addressed to the mobile node's RCoA 503 (from the HA or correspondent nodes). Packets will be tunnelled from 504 the MAP to the mobile node's LCoA. The mobile node will de-capsulate 505 the packets and process them in the normal manner. 507 When the mobile node moves within the same MAP domain, it should only 508 register its new LCoA with its MAP. In this case, the RCoA remains 509 unchanged. 511 Note that a mobile node may send a BU containing its LCoA (instead of 512 its RCoA) to correspondent nodes. If these nodes are connected to 513 the same link, packets will then be routed directly without going 514 through the MAP. 516 6.1.1. Sending Packets to Correspondent Nodes 518 The mobile node can communicate with a correspondent node through the 519 HA, or in a route-optimised manner, as described in [RFC3775]. When 520 communicating through the HA, the message formats in [RFC3775] are 521 used. 523 If the mobile node communicates directly with the correspondent node 524 (i.e., the CN has a binding cache entry for the mobile node), the 525 mobile node MUST use the same care-of address used to create a 526 binding cache entry in the correspondent node (RCoA) as a source 527 address. According to [RFC3775], the mobile node MUST also include a 528 Home Address option in outgoing packets. The Home address option 529 MUST contain the mobile node's home address. 531 6.2. MAP Operations 533 The MAP acts like an HA; it intercepts all packets addressed to 534 registered mobile nodes and tunnels them to the corresponding LCoA, 535 which is stored in its binding cache. 537 A MAP has no knowledge of the mobile node's Home address. The mobile 538 node will send a local BU to the MAP with the M and A flags set. The 539 aim of this BU is to bind the RCoA (contained in the BU as a Home 540 address) to the mobile node's LCoA. If successful, the MAP MUST 541 return a binding acknowledgement to the mobile node, indicating a 542 successful registration. This is identical to the HA operation in 543 [RFC3775]. No new error codes are introduced for HMIPv6. The 544 binding acknowledgement MUST include a routing header type 2 that 545 contains the mobile node's RCoA. 547 The MAP MUST be able to accept packets tunnelled from the mobile 548 node, with the mobile node being the tunnel entry point and the MAP 549 being the tunnel exit point. 551 The MAP employs [RFC4877] Section 9 procedures for the allocation of 552 RCoA, and subsequently acts as a HA for the RCoA. Packets addressed 553 to the RCOA are intercepted by the MAP, using proxy Neighbour 554 Advertisement, and then encapsulated and routed to the mobile node's 555 LCoA. This operation is identical to that of the HA described in 556 [RFC3775]. 558 A MAP MAY be configured with the list of valid on-link prefixes that 559 mobile nodes can use to derive LCoAs. This is useful for network 560 operators that need to stop mobile nodes from continuing to use the 561 MAP after moving to a different administrative domain. If a mobile 562 node sent a binding update containing an LCoA that is not in the 563 MAP's "valid on-link prefixes" list, the MAP could reject the binding 564 update using existing error code 129 (administratively prohibited). 566 6.3. Home Agent Operations 568 The support of HMIPv6 is completely transparent to the HA's 569 operation. Packets addressed to a mobile node's Home Address will be 570 forwarded by the HA to its RCoA, as described in [RFC3775]. 572 6.4. Correspondent Node Operations 574 HMIPv6 is completely transparent to correspondent nodes. 576 6.5. Local Mobility Management Optimisation within a MAP Domain 578 In [RFC3775], it is stated that for short-term communication, 579 particularly communication that may easily be retried upon failure, 580 the mobile node MAY choose to directly use one of its care-of 581 addresses as the source of the packet, thus not requiring the use of 582 a Home Address option in the packet. Such use of the CoA will reduce 583 the overhead of sending each packet due to the absence of additional 584 options. In addition, it will provide an optimal route between the 585 mobile node and correspondent node. 587 HMIPv6-aware mobile nodes can use their RCoA as the source address 588 without using a Home Address option. In other words, the RCoA can be 589 used as a source address for upper layers. Using this feature, the 590 mobile node will be seen by the correspondent node as a fixed node 591 while moving within a MAP domain. 593 This usage of the RCoA does not have the cost of Mobile IPv6 (i.e., 594 no bindings or home address options are sent over the Internet), but 595 still provides local mobility management to the mobile nodes with 596 near-optimal routing. Although such use of RCoA does not provide 597 global mobility (i.e., communication is broken when a mobile node 598 changes its RCoA), it would be useful for several applications (e.g., 599 web browsing). The validity of the RCoA as a source address used by 600 applications will depend on the size of a MAP domain and the speed of 601 the mobile node. Furthermore, because the support for BU processing 602 in correspondent nodes is not mandated in [RFC3775], this mechanism 603 can provide a way of obtaining route optimisation without sending BUs 604 to the correspondent nodes. 606 Enabling this mechanism can be done by presenting the RCoA as a 607 temporary home address for the mobile node. This may require an 608 implementation to augment its source address selection algorithm with 609 the knowledge of the RCoA in order to use it for the appropriate 610 applications. 612 6.6. Location Privacy 614 In HMIPv6, a mobile node hides its LCoA from its corresponding nodes 615 and its home agent by using its RCoA in the source field of the 616 packets that it sends. As a result, address-based location tracking 617 of a mobile node by its corresponding nodes or its home agent is more 618 difficult because they only know its RCoA and not its LCoA. 620 7. MAP Discovery 622 This section describes how a mobile node obtains the MAP address and 623 subnet prefix, and how ARs in a domain discover MAPs. 625 This specification requires network administrators to manually 626 configure the MAP option information in ARs and other Future 627 mechanisms may be defined to allow MAPs to be discovered dynamically. 629 7.1. Mobile Node Operation 631 When an HMIPv6-aware mobile node receives a router advertisement, it 632 should search for the MAP option. One or more options may be found 633 for different MAP IP addresses. A mobile node SHOULD register with 634 the MAP having the highest preference value. A MAP with a preference 635 value of zero SHOULD NOT be used for new local BUs (i.e., the mobile 636 node can refresh existing bindings but cannot create new ones). 637 However, a mobile node MAY choose to register with one MAP over 638 another, depending on the value received in the Distance field, 639 provided that the preference value is above zero. 641 A MAP option containing a valid lifetime value of zero means that 642 this MAP MUST NOT be selected by the MN. A valid lifetime of zero 643 indicates a MAP failure. When this option is received, a mobile node 644 MUST choose another MAP and create new bindings. Any existing 645 bindings with this MAP can be assumed to be lost. If no other MAP is 646 available, the mobile node MUST NOT attempt to use HMIPv6. 648 If a multihomed mobile node has access to several ARs simultaneously 649 (on different interfaces), it SHOULD use an LCoA on the link defined 650 by the AR that advertises its current MAP. 652 A mobile node MUST store the received option(s) in order to choose at 653 least one MAP to register with. Storing the options is essential, as 654 they will be compared to other options received later for the purpose 655 of the movement detection algorithm. 657 If the R flag is set, the mobile node MUST place its RCoA in place of 658 the Home Address in the binding update message. This causes the RCoA 659 to be bound to the LCoA in the MAP's Binding Cache. 661 A mobile node MAY choose to register with more than one MAP 662 simultaneously, or use both the RCoA and its LCoA as care-of 663 addresses simultaneously with different correspondent nodes. 665 8. Updating Previous MAPs 667 When a mobile node moves into a new MAP domain, the mobile node may 668 send a BU to the previous MAP requesting it to forward packets 669 addressed to the mobile node's new CoA. An administrator MAY 670 restrict the MAP from forwarding packets to LCoAs outside the MAP's 671 domain. However, it is RECOMMENDED that MAPs be allowed to forward 672 packets to LCoAs associated with some of the ARs in neighbouring MAP 673 domains, provided that they are located within the same 674 administrative domain. 676 For instance, a MAP could be configured to forward packets to LCoAs 677 associated with ARs that are geographically adjacent to ARs on the 678 boundary of its domain. This will allow for a smooth inter-MAP 679 handover as it allows the mobile node to continue to receive packets 680 while updating the new MAP, its HA and, potentially, correspondent 681 nodes. 683 9. Note On MAP Selection by the Mobile Node 685 HMIPv6 provides a flexible mechanism for local mobility management 686 within a visited network. As explained earlier, a MAP can exist 687 anywhere in the operator's network (including the AR). Several MAPs 688 can be located within the same domain independently of each other. 689 In addition, overlapping MAP domains are also allowed and 690 recommended. Both static and dynamic hierarchies are supported. 692 When the mobile node receives a router advertisement including a MAP 693 option, it should perform actions according to the following movement 694 detection mechanisms. In a Hierarchical Mobile IP network such as 695 the one described in this document, the mobile node should be: 697 o "Eager" to perform new bindings. 699 o "Lazy" in releasing existing bindings 701 The above means that the mobile node should register with any "new" 702 MAP advertised by the AR (Eager). The method by which the mobile 703 node determines whether the MAP is a "new" MAP is described in 704 section 9.1. The mobile node should not release existing bindings 705 until it no longer receives the MAP option (or receives it with a 706 lifetime of zero) or the lifetime of its existing binding expires 707 (Lazy). This Eager-Lazy approach, described above, will assist in 708 providing a fallback mechanism in case of the failure of one of the 709 MAP routers, as it will reduce the time it takes for a mobile node to 710 inform its correspondent nodes and HA about its new care-of address. 712 9.1. MAP Selection in Distributed MAP Environment 714 The mobile node needs to consider several factors to optimally select 715 one or more MAPs, where several MAPs are available in the same 716 domain. 718 There are no benefits foreseen in selecting more than one MAP and 719 forcing packets to be sent from the higher MAP down through a 720 hierarchy of MAPs. This approach may add forwarding delays and 721 eliminate the robustness of IP routing between the highest MAP and 722 the mobile node; therefore, it is prohibited by this specification. 723 Allowing more than one MAP ("above" the AR) within a network should 724 not imply that the mobile node forces packets to be routed down the 725 hierarchy of MAPs. However, placing more than one MAP "above" the AR 726 can be used for redundancy and as an optimisation for the different 727 mobility scenarios experienced by mobile nodes. The MAPs are used 728 independently of each other by the MN (e.g., each MAP is used for 729 communication to a certain set of CNs). 731 In terms of the Distance-based selection in a network with several 732 MAPs, a mobile node may choose to register with the furthest MAP to 733 avoid frequent re-registrations. This is particularly important for 734 fast mobile nodes that will perform frequent handoffs. In this 735 scenario, the choice of a more distant MAP would reduce the 736 probability of having to change a MAP and informing all correspondent 737 nodes and the HA. 739 In a scenario where several MAPs are discovered by the mobile node in 740 one domain, the mobile node may need sophisticated algorithms to be 741 able to select the appropriate MAP. These algorithms would have the 742 mobile node speed as an input (for distance based selection) combined 743 with the preference field in the MAP option. However, this 744 specification proposes that the mobile node uses the following 745 algorithm as a default, where other optimised algorithms are not 746 available. The following algorithm is simply based on selecting the 747 MAP that is most distant, provided that its preference value did not 748 reach a value of zero. The mobile node operation is shown below: 750 1. Receive and parse all MAP options. 752 2. Arrange MAPs in a descending order, starting with the furthest 753 MAP (i.e., MAP option having largest Dist field) 755 3. Select first MAP in list 757 4. If either the preference value or the valid lifetime fields are 758 set to zero, select the following MAP in the list. 760 5. Repeat step (4) while new MAP options still exist, until a MAP is 761 found with a non-zero preference value and a non-zero valid 762 lifetime. 764 Implementing the steps above would result in mobile nodes selecting, 765 by default, the most distant or furthest available MAP. This will 766 continue until the preference value reduces to zero. Following this, 767 mobile nodes will start selecting another MAP. 769 9.2. MAP Selection in a Flat Mobility Architecture. 771 Network operators may choose a flat architecture in some cases where 772 a Mobile IPv6 handover may be considered a rare event. In these 773 scenarios, operators may choose to include the MAP function in ARs 774 only. The inclusion of the MAP function in ARs can still be useful 775 to reduce the time required to update all correspondent nodes and the 776 HA. In this scenario, a mobile node may choose a MAP (in the AR) as 777 an anchor point when performing a handoff. This kind of dynamic 778 hierarchy (or anchoring) is only recommended for cases where inter-AR 779 movement is not frequent. 781 10. Detection and Recovery from MAP Failures 783 This specification introduces a MAP that can be seen as a local Home 784 Agent in a visited network. A MAP, like a Home Agent, is a single 785 point of failure. If a MAP fails, its binding cache content will be 786 lost, resulting in loss of communication between mobile and 787 correspondent nodes. This situation may be avoided by using more 788 than one MAP on the same link and by utilising a form of context 789 transfer protocol between them. However, MAP redundancy is outside 790 the scope of this document. 792 In cases where such protocols are not supported, the mobile node 793 would need to detect MAP failures. The mobile node can detect this 794 situation when it receives a router advertisement containing a MAP 795 option with a lifetime of zero. The mobile node should then start 796 the MAP discovery process and attempt to register with another MAP. 797 After it has selected and registered with another MAP, it will also 798 need to inform correspondent nodes and the Home Agent if its RCoA has 799 changed. Note that in the presence of a protocol that transfers 800 binding cache entries between MAPs for redundancy purposes, a new MAP 801 may be able to provide the same RCoA to the mobile node (e.g., if 802 both MAPs advertise the same prefix in the MAP option). This would 803 save the mobile node from updating correspondent nodes and the Home 804 Agent. 806 Access routers can be triggered to advertise a MAP option with a 807 lifetime of zero (indicating MAP failure) in different ways: 809 o By manual intervention. 811 o In a dynamic manner. 813 One way of performing dynamic detection of MAP failure can be done by 814 probing the MAP regularly (e.g., every ten seconds). If no response 815 is received, an AR MAY try to aggressively probe the MAP for a short 816 period of time (e.g., once every 5 seconds for 15 seconds); if no 817 reply is received, a MAP option may be sent with a valid lifetime 818 value of zero. The exact mechanisms for probing MAPs is outside the 819 scope of this document. The above text simply shows one example of 820 detecting failures. 822 This specification does not mandate a particular recovery mechanism. 823 However, any mechanism between the MAP and an AR SHOULD be secure to 824 allow for message authentication, integrity protection, and 825 protection against replay attacks. 827 Note that the above suggestion for detecting MAP failure may not 828 detect MAP failures that might take place between probes, i.e. if a 829 MAP reboots between probes. 831 11. Tunelling impacts on MTU 833 This specification requires the mobile node to tunnel outgoing trafic 834 to the MAP. Similarly, the MAP tunnels inbound packets to the mobile 835 node. If the mobile node has a home agent elsewhere on the Internet, 836 this will result in double encapsulations of inbound and outbound 837 packets. This may have impacts on the mobile node's path MTU. 838 Hence, mobile nodes MUST consider the encapsulation of traffic 839 between the node and the MAP when calculating the available MTU for 840 upper layers. 842 12. Security Considerations 844 This specification introduces a new concept to Mobile IPv6, namely, a 845 Mobility Anchor Point that acts as a local Home Agent. It is crucial 846 that the security relationship between the mobile node and the MAP is 847 strong; it MUST involve mutual authentication, integrity protection, 848 and protection against replay attacks. Confidentiality may be needed 849 for payload traffic, such as when the mobile node is unwilling to 850 reveal any traffic to the access network beyond what is needed for 851 the mobile node to attach to the network and communicate with a MAP. 852 Confidentiality is not required for binding updates to the MAP. The 853 absence of any of these protections may lead to malicious mobile 854 nodes impersonating other legitimate ones or impersonating a MAP. 855 Any of these attacks will undoubtedly cause undesirable impacts to 856 the mobile node's communication with all correspondent nodes having 857 knowledge of the mobile node's RCoA. 859 Three different relationships (related to securing binding updates) 860 need to be considered: 862 1. The mobile node - MAP 864 2. The mobile node - Home Agent 866 3. The mobile node - correspondent node 868 12.1. Mobile Node - MAP Security 870 In order to allow a mobile node to use the MAP's forwarding service, 871 initial authorisation (specifically for the service, not for the 872 RCoA) MAY be needed. Authorising a mobile node to use the MAP 873 service can be done based on the identity of the mobile node 874 exchanged during the SA negotiation process. The authorisation may 875 be granted based on the mobile node's identity, or based on the 876 identity of a Certificate Authority (CA) that the MAP trusts. For 877 instance, if the mobile node presents a certificate signed by a 878 trusted entity (e.g., a CA that belongs to the same administrative 879 domain, or another trusted roaming partner), it would be sufficient 880 for the MAP to authorise the use of its service. Note that this 881 level of authorisation is independent of authorising the use of a 882 particular RCoA. Similarly, the mobile node trusts the MAP if it 883 presents a certificate signed by the same CA or by another CA that 884 the mobile node is configured to trust (e.g., a roaming partner). It 885 is likely that some deployments would be satisfied with the use of 886 self signed certificates for either the mobile node or the MAP or 887 both. This guarantees that the mobile node and the MAP are 888 authenticated for address allocation and future binding updates 889 without the need for identity authentication. Hence, the use of 890 trusted third party certificates is not required by this 891 specification. 893 It is important to note that in this specification, authentication 894 and authorisation are effectively the same thing. All the MAP needs 895 to allocate the mobile node an RCoA is to authenticate the mobile 896 node and verify that it belongs to a trusted group (based on its 897 certificate). 899 IKEv2 MUST be supported by the mobile node and the MAP. IKEv2 allows 900 the use of EAP as a mechanism to bootstrap the security association 901 between the communicating peers. Hence, EAP can be used with IKEv2 902 to leverage the AAA infrastructure to bootstrap the SA between the 903 mobile node and the MAP. Such mechanism is useful in scenarios where 904 an administrator wishes to avoid the configuration and management of 905 certificates on mobile nodes. A MAP MAY support the use of EAP over 906 IKEv2. 908 If EAP is used with IKEv2, the EAP method runs between the mobile 909 node and a AAA server. Following a successful authentication, the 910 resulting keying material can be used to bootstrap IKEv2 between the 911 MAP and the mobile node. The specification of which EAP methods 912 should be used, or how keys are transported between the MAP and the 913 AAA server is outside the scope of this document. 915 HMIPv6 uses an additional registration between the mobile node and 916 its current MAP. As explained in this document, when a mobile node 917 moves into a new domain (i.e., served by a new MAP), it obtains an 918 RCoA, an LCoA and registers the binding between these two addresses 919 with the new MAP. The MAP then verifies the BU and creates a binding 920 cache entry with the RCoA and LCoA. Whenever the mobile node gets a 921 new LCoA, it needs to send a new BU that specifies the binding 922 between RCoA and its new LCoA. This BU needs to be authenticated, 923 otherwise any host could send a BU for the mobile node's RCoA and 924 hijack the mobile node's packets. 926 The MAP does not need to have prior knowledge of the identity of the 927 mobile node nor its Home Address. As a result the SA between the 928 mobile node and the MAP can be established using any key 929 establishment protocols such as IKEv2. A return routability test is 930 not necessary. 932 The MAP needs to set the SA for the RCoA (not the LCoA). This can be 933 performed with IKEv2 [RFC4306]. The mobile node uses its LCoA as the 934 source address, but specifies that the RCoA should be used in the SA. 935 This is achieved by using the RCoA as the identity in the IKE child 936 SA negotiation. This step is identical to the use of the home 937 address in IKE child SA when negotiating with the home agent. 939 The IPsec PAD entries and configuration payloads described in 940 [RFC4877] for allocating dynamic home addresses SHOULD be used by the 941 MAP to allocate the RCoA for mobile nodes. Binding updates between 942 the MAP and the mobile node MUST be protected with either AH or ESP 943 in transport mode. When ESP is used, a non- null authentication 944 algorithm MUST be used. 946 The Security Policy Database (SPD) entries in both the home agent and 947 the mobile node are identical to those setup for the home agent and 948 mobile node, respectively, as outlined in [RFC4877] 950 12.2. Mobile Node - Correspondent Node Security 952 Mobile IPv6 [RFC3775] defines a return routability procedure that 953 allows mobile and correspondent nodes to authenticate binding updates 954 and acknowledgements. This specification does not impact the return 955 routability test defined in [RFC3775]. However, it is important to 956 note that mobile node implementers need to be careful when selecting 957 the source address of the HoTI and CoTI messages, defined in 958 [RFC3775]. The source address used in HoTI messages SHOULD be the 959 mobile node's home address unless the mobile node wishes to use the 960 RCoA for route optimisation. The packet containing the HoTI message 961 is encapsulated twice. The inner encapsulating header contains the 962 RCoA in the source address field and the home agent's address in the 963 destination address field. The outer encapsulating header contains 964 the mobile node's LCoA in the source address field and the MAP's 965 address in the destination field. 967 12.3. Mobile Node - Home Agent Security 969 The security relationship between the mobile node and its Home Agent, 970 as discussed in [RFC3775], is not impacted by this specification. 972 The relationship between the MAP and the mobile node is not impacted 973 by the presence of a home agent. 975 13. IANA Considerations 977 There are no IANA considerations for this specification. The MAP 978 option was allocated for RFC 4140 and will continue to be used by 979 this specification. 981 14. Acknowledgements 983 The authors would like to thank Conny Larsson (Ericsson) and Mattias 984 Pettersson (Ericsson) for their valuable input to this document. The 985 authors would also like to thank the members of the French RNRT 986 MobiSecV6 project (BULL, France Telecom and INRIA) for testing the 987 first implementation and for their valuable feedback. The INRIA 988 HMIPv6 project is partially funded by the French Government. 990 In addition, the authors would like to thank the following members of 991 the working group in alphabetical order: Samita Chakrabarti (Sun), 992 Gregory Daley, Francis Dupont (GET/Enst Bretagne), Gopal Dommety 993 (Cisco), Eva Gustaffson (Ericsson), Dave Johnson (Rice University), 994 Annika Jonsson (Ericsson), James Kempf (Docomo labs), Martti 995 Kuparinen (Ericsson) Fergal Ladley, Gabriel Montenegro (Microsoft), 996 Nick "Sharkey" Moore, Vidya Narayanan (Qualcomm), Erik Nordmark 997 (Sun), Basavaraj Patil (Nokia), Brett Pentland (NEC), Thomas Schmidt 998 and Alper Yegin (Samsung) for their comments on the document. 1000 15. References 1002 15.1. Normative References 1004 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1005 Requirement Levels", BCP 14, RFC 2119, March 1997. 1007 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1008 in IPv6", RFC 3775, June 2004. 1010 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1011 RFC 4306, December 2005. 1013 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1014 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1015 September 2007. 1017 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1018 IKEv2 and the Revised IPsec Architecture", RFC 4877, 1019 April 2007. 1021 15.2. Informative References 1023 [RFC4449] Perkins, C., "Securing Mobile IPv6 Route Optimization 1024 Using a Static Shared Key", RFC 4449, June 2006. 1026 [RFC4651] Vogt, C. and J. Arkko, "A Taxonomy and Analysis of 1027 Enhancements to Mobile IPv6 Route Optimization", RFC 4651, 1028 February 2007. 1030 [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route 1031 Optimization for Mobile IPv6", RFC 4866, May 2007. 1033 Appendix A. Appendix A - Changes from RFC 4140 1035 o Dynamic MAP Discovery was removed. 1037 o Updated the security section to use IKEv2 instead of IKEv1 1039 o The document clarified that HMIPv6 can be used without the need 1040 for a home agent 1042 o Several editorials throughout the document 1044 o IKEv2 only is now used to allocated the RCoA 1046 RFC 4140 was implemented and interop tested by at least two different 1047 organisations. A test suite including test cases for RFC 4140 was 1048 also developed by Ericsson and run against both implementations. No 1049 major issues were found. The scalability of Dynamic MAP discovery 1050 defined in RFC 4140 was seen as inappripriate for large scale 1051 deployments and prone to loops. It was removed from this 1052 specification. 1054 At this time there is no publicly known deployment of this 1055 specification. 1057 Authors' Addresses 1059 Hesham Soliman 1060 Elevate Technologies 1062 Email: hesham@elevatemobile.com 1064 Claude Castelluccia 1065 INRIA 1067 Phone: +33 4 76 61 52 15 1068 Email: claude.castelluccia@inria.fr 1070 Karim ElMalki 1071 Athonet 1073 Email: karim@elmalki.homeip.net 1075 Ludovic Bellier 1076 INRIA 1078 Email: ludovic.bellier@inria.fr 1080 Full Copyright Statement 1082 Copyright (C) The IETF Trust (2008). 1084 This document is subject to the rights, licenses and restrictions 1085 contained in BCP 78, and except as set forth therein, the authors 1086 retain all their rights. 1088 This document and the information contained herein are provided on an 1089 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1090 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1091 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1092 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1093 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1094 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1096 Intellectual Property 1098 The IETF takes no position regarding the validity or scope of any 1099 Intellectual Property Rights or other rights that might be claimed to 1100 pertain to the implementation or use of the technology described in 1101 this document or the extent to which any license under such rights 1102 might or might not be available; nor does it represent that it has 1103 made any independent effort to identify any such rights. Information 1104 on the procedures with respect to rights in RFC documents can be 1105 found in BCP 78 and BCP 79. 1107 Copies of IPR disclosures made to the IETF Secretariat and any 1108 assurances of licenses to be made available, or the result of an 1109 attempt made to obtain a general license or permission for the use of 1110 such proprietary rights by implementers or users of this 1111 specification can be obtained from the IETF on-line IPR repository at 1112 http://www.ietf.org/ipr. 1114 The IETF invites any interested party to bring to its attention any 1115 copyrights, patents or patent applications, or other proprietary 1116 rights that may cover technology that may be required to implement 1117 this standard. Please address the information to the IETF at 1118 ietf-ipr@ietf.org.