idnits 2.17.1 draft-wakikawa-mext-global-haha-spec-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 257: '...in the same global home agent set MUST...' RFC 2119 keyword, line 505: '..., each home agent SHOULD be configured...' RFC 2119 keyword, line 537: '... agent SHOULD NOT configure with its...' RFC 2119 keyword, line 589: '...e values. This value SHOULD be set to...' RFC 2119 keyword, line 590: '...0. The receiver SHOULD ignore this va...' (44 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 2, 2011) is 4619 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC2991' is defined on line 1023, but no explicit reference was found in the text == Unused Reference: 'RFC4885' is defined on line 1032, but no explicit reference was found in the text == Unused Reference: 'RFC4888' is defined on line 1038, but no explicit reference was found in the text == Unused Reference: 'RFC4889' is defined on line 1042, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MEXT Working Group R. Wakikawa 3 Internet-Draft R. Kuntz 4 Intended status: Experimental Toyota ITC 5 Expires: March 5, 2012 Z. Zhu 6 L. Zhang 7 UCLA 8 September 2, 2011 10 Global HA to HA Protocol Specification 11 draft-wakikawa-mext-global-haha-spec-02 13 Abstract 15 This document presents a revised version of the global HAHA protocol 16 specification. Global HAHA allows the deployment of Home Agents over 17 the Internet for reliability, scalability and performance purposes. 18 This version clarifies several issues that were vague in the original 19 specification. Global HAHA makes use of the signaling defined by the 20 Home Agent Reliability protocol (HARP) although it is not designed to 21 operate in conjunction with HARP. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 5, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 3.1. Initial Binding Registration . . . . . . . . . . . . . . . 9 63 3.2. Primary Home Agent Switch . . . . . . . . . . . . . . . . 9 64 3.3. Routing Packets . . . . . . . . . . . . . . . . . . . . . 10 65 3.4. Differences between global HAHA and HARP . . . . . . . . . 11 67 4. Home Agent Configurations . . . . . . . . . . . . . . . . . . 12 68 4.1. Home Agent and Subnet Distributions . . . . . . . . . . . 12 69 4.2. Anycast Routing Consideration . . . . . . . . . . . . . . 13 71 5. Global HAHA Protocol . . . . . . . . . . . . . . . . . . . . . 14 72 5.1. Home Agents Bootstrap . . . . . . . . . . . . . . . . . . 14 73 5.2. Management of global Home Agent set . . . . . . . . . . . 14 74 5.2.1. Home Agent List for the global HAHA . . . . . . . . . 15 75 5.2.2. Modified HARP Message . . . . . . . . . . . . . . . . 15 76 5.2.3. Sending Home Agent Hello Messages . . . . . . . . . . 16 77 5.2.4. Receiving Hello Message . . . . . . . . . . . . . . . 16 78 5.3. Primary Home Agent Receiving Binding Update . . . . . . . 17 79 5.4. Global Binding Management . . . . . . . . . . . . . . . . 18 80 5.4.1. Global Binding . . . . . . . . . . . . . . . . . . . . 18 81 5.4.2. Modified State Synchronization Message and 82 Mobility Option . . . . . . . . . . . . . . . . . . . 19 83 5.4.3. Global Binding Registration . . . . . . . . . . . . . 19 84 5.5. Primary Home Agent Switch . . . . . . . . . . . . . . . . 21 85 5.6. Packet Interception and Delivery . . . . . . . . . . . . . 22 86 5.7. Home Agents Discovery . . . . . . . . . . . . . . . . . . 23 88 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 24 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 92 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 94 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 95 9.1. Normative References . . . . . . . . . . . . . . . . . . . 26 96 9.2. Informative References . . . . . . . . . . . . . . . . . . 26 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 100 1. Introduction 102 The global HAHA protocol aims at leveraging the global deployment of 103 Home Agents over the Internet, by proposing reliability, scalability 104 and better performances to Mobile IPv6 [RFC6275] deployments. 106 The original global HAHA protocol [I-D.thubert-mext-global-haha] has 107 been discussed for several years in MIP6, NEMO and now MEXT working 108 groups. Several documents [I-D.thubert-mext-global-haha] 109 [I-D.wakikawa-mip6-nemo-haha-spec] 110 [I-D.wakikawa-mext-haha-interop2008] have been published and 111 presented in past IETF meetings, and received valuable feedback. 112 This document presents a revised version of the global HAHA protocol 113 specification. This version clarified several issues that were vague 114 in the original specification [I-D.thubert-mext-global-haha]. 116 Global HAHA makes use of the signaling defined by the Home Agent 117 Reliability protocol (HARP) [I-D.ietf-mip6-hareliability] which is 118 being standardized in the MEXT working group. On one hand, HARP 119 provides a redundancy mechanism for the Home Agents located on the 120 same layer-2 link (or in different layer-2 links provided that proper 121 routing updates are performed between links upon failure). On the 122 other hand, global HAHA builds on anycast routing to not only provide 123 redundancy but also achieve a better distributed mobility management 124 for Mobile IPv6. More specifically, global HAHA provides the 125 following advantages: 127 o It eliminates the single point of failure and bottleneck in Mobile 128 IPv6 and NEMO protocols. By distributing multiple Home Agents 129 over wide areas, scalability and robustness of the mobility 130 infrastructure can be improved. 132 o It provides very flexible deployment schemes. When home agents 133 are placed at Internet Exchange Points, they can improve the 134 performances of mobility over long distances (such as depicted in 135 aeronautics scenarios [RFC5522]) by minimizing triangle routing as 136 compared to the path utilizing a single home agent (so called dog- 137 leg routing). Alternatively, when home agents are placed closer 138 to the edge of the network, a more flat design can be achieved. 139 Offloading near the edge of the network becomes possible, to the 140 benefit of the core network load [I-D.kuntz-dmm-summary]. 142 o It makes use of existing protocols (HARP signaling 143 [I-D.ietf-mip6-hareliability], Home Agent Switch messages 144 [RFC5142]) while confining the required changed to the home agent 145 only. 147 Global HAHA also provides reliability in case of a home agent 148 failure. Whether it would be useful to be able to combine HARP with 149 global HAHA for local reliability of a home agent is open for future 150 discussion. Such combination can bring better performances in cases 151 that may be unlikely to happen often, at the cost of an increased 152 complexity. Furthermore, whether Global HAHA should be independent 153 from HARP and define its own signaling protocol is also open for 154 further discussion. 156 The global HAHA concept has been evaluated through prototype 157 implementations in several places [PAPER-CONEXT] and the results show 158 that the design is simple and effective in reducing triangle routing. 159 Several industry sectors such as aviation [RFC5522] and automobile 160 [I-D.ietf-mext-nemo-ro-automotive-req] have shown their interests in 161 using global HAHA to meet the need for their mobility managements. 163 As every coin has two sides, the global HAHA protocol is not an 164 exception. It achieves the above goals through utilizing anycast 165 routing, which has raised a concern on routing scalability, and it 166 introduces additional overheads due to the need to synchronize the 167 mobility state among distributed home agents. By presenting a 168 complete design together with the design justifications, we hope that 169 this document will help move the discussion towards a converged 170 understanding on the pros and cons of the global HAHA protocol. 172 2. Terminology 174 This document uses terms defined in [RFC3753], [RFC6275], [RFC3963] 175 and and [I-D.ietf-mip6-hareliability]. A few new terms are also 176 introduced in this document: 178 Home subnet prefix 180 It is assigned to a home subnet, and the home agent unicast 181 address (defined below) of a mobile node is assigned out of this 182 prefix block. In this global HAHA specification, the home subnet 183 prefix is assumed to be a provider independent prefix. 185 Home agent unicast address 187 A unicast IP address created from the home subnet prefix and 188 assigned to a home agent. This is the address used by Mobile 189 nodes when sending Binding Updates to their Home Agent. 191 Home agent locator address 193 A unicast IP address assigned to a home agent by the ISP who 194 provides the Internet connectivity for the home agent. This 195 address is used to exchange mobility messages between globally 196 distributed home agents. 198 Home agent anycast address 200 The anycast address defined as per [RFC2526] and used by mobile 201 nodes for Dynamic Home Agent Address Discovery purposes. 203 Global home agent set 205 The set of home agents serving the same home subnet prefix. The 206 home agents are located in topologically and/or geographically 207 different locations. A global home agent set is identified with a 208 8-bit group ID. 210 HAHA link 212 All the home agents in the same global home agent set share the 213 same home subnet prefix although they may be located in different 214 parts on Internet. In order for each of them to reach all the 215 others directly as required by IP subnet definition, logical 216 connectivity links are created between each pair of home agents. 217 These logical links, called HAHA links, can be realized using IP 218 tunnel technologies such as IP tunnel, IPsec tunnel, L2TP, PPTP, 219 and so on. Data packets and Binding Updates that need to be 220 forwarded between home agents are sent over these HAHA links. 222 Primary Home Agent 224 The home agent which a mobile node is currently registered with. 225 Among all the available home agents in the same set, this primary 226 home agent should be topologically closest to the mobile node. At 227 any given time each mobile node has one primary home agent. 229 Global Binding 231 When a mobile node registers with a primary home agent, the home 232 agent notifies this binding, called the global binding, to all the 233 other home agents in the same global home agent set. The receiver 234 of this global binging information learns the mapping between the 235 mobile node and its current primary home agent, and creates a 236 route entry for the mobile node with the next hop pointing to the 237 primary home agent locator address. This route entry has a 238 lifetime which can be different from the lifetime carried in the 239 original binding message. When the lifetime expires, the route is 240 deleted. 242 3. Overview 244 Global HAHA relies on IP anycast routing between geographically and 245 topologically different home agent locations. The home subnet prefix 246 is announced by all the home agents in a deployed global HAHA system, 247 so that packets from and to mobile nodes are always routed towards 248 the closest home agents in a way that is completely transparent to 249 the mobile and correspondent nodes. 251 Global HAHA does not require any modification to mobile nodes and 252 mobile routers (i.e. end mobile entity). Supporting Mobile IPv6 253 [RFC6275] and Home Agent Switch message [RFC5142] is sufficient to 254 run mobile nodes with globally distributed home agents. 256 Figure 1 shows the protocol sequence of the global HAHA. As an 257 assumption, each home agent in the same global home agent set MUST 258 establish HAHA links for interconnecting other home agents. The 259 detail of HAHA link establishment is described in Section 5.1. 261 MN HA1 HA2 CN 262 | | | | 263 |----> (Primary) | | 1. Binding Update 264 |<--------| | | 2. Binding Acknowledgment 265 | |-------->| | 3. State Synchronization 266 |<========|<========|<--------| 4. From CN to MN 267 |========>|------------------>| 5. From MN to CN 268 | | | | 269 : : : : MN MOVEMENT 270 | | | | 271 |------------------+| | 6. Binding Update 272 | |<=======+| | 273 |<--------| | | 7. Binding Acknowledgment 274 |<--------| | | 8. Home Agent Switch 275 |--------------> (Primary) | 9. Binding Re-registration 276 | |<--------| | 10. State Synchronization 277 |<==================|<--------| 11. From CN to MN 278 |==================>|-------->| 12. From MN to CN 279 | | | | 281 ==== for tunneling 282 ---- for direct packets 284 Figure 1: Overview of global HAHA 286 3.1. Initial Binding Registration 288 Global HAHA home agents can be reached by the mobile node through 289 both the home agent anycast address (e.g. obtained with Dynamic Home 290 Agent Address Discovery [RFC6275]) and the Home agent unicast address 291 (e.g. obtained from the DNS) created from the home agent home subnet 292 prefix (see Section 5.7). Note that the home agent locator address 293 is not known by the mobile nodes and is only used between global home 294 agents to exchange mobility messages among them. 296 When the mobile node attempts the binding registration to a home 297 agent using the HA anycast address (operation 1 in Figure 1), the 298 binding update is routed to the topologically closest home agent of 299 the mobile node via IP anycast routing. The closest home agent which 300 the mobile node registers its binding with is called a primary home 301 agent for the mobile node. This specification assumes that the route 302 of home subnet prefix is advertised from each of different locations 303 where an HAHA home agent resides. 305 After sending a binding Acknowledgment to the mobile node (operation 306 2 in Figure 1) and registering a binding cache for the mobile node, 307 the primary home agent (HA1) sends State Synchronization messages to 308 all the other home agent (i.e. HA2) in the same global home agent 309 set (operation 3 in Figure 1). Then, HA2 creates a global binding 310 for the mobile node and creates the mobile node's route entry with 311 the next hop set to the locator address of the primary home agent 312 (HA1). The global binding needs to be updated when a mobile node 313 changes its primary home agent. It must also be refreshed before its 314 lifetime expiration. 316 When HA2 receives packets from a correspondent node destined to the 317 mobile node, it forwards them to the primary home agent (HA1) over 318 the HAHA link according to the global binding (operation 4 in 319 Figure 1). When a mobile node sends data to the correspondent node, 320 the traffic is tunneled to the primary home agent, which then routes 321 directly to the destination (operation 5 in Figure 1). 323 If the mobile node obtained the home agent unicast address through 324 the DNS, and that address does not correspond to the topologically 325 closest home agent, a home agent switch will be performed as 326 described in the next section. 328 3.2. Primary Home Agent Switch 330 In this example, from the routing perspective, the closest home agent 331 of the mobile node is now changed from HA1 to HA2 after a mobile 332 node's movement. Thus, the primary home agent of the mobile node 333 needs to be updated from HA1 to HA2. This case can also happen if 334 the home agent unicast address obtained from the DNS (during the 335 bootstrapping phase of the mobile node) is set to HA1 whereas the 336 mobile node is initially closer to HA2. 338 The Primary Home Agent switch operation consists of two binding 339 updates exchange. The first binding update is used to detect the 340 closer home agent by the current primary home agent. The second 341 binding update is to let the mobile node change its primary home 342 agent. 344 When a mobile node changes its point of attachment, it simply sends 345 the first Binding Update to its current primary home agent (i.e. HA1 346 in Figure 1) in order to renew its binding as per [RFC6275]. 347 However, since HA2 also advertises the same home subnet prefix, the 348 Binding Update is first routed to the HA2 by IP anycast routing. HA2 349 knows that HA1 belongs to the same global Home Agent set, and thus 350 forwards the Binding Update to its destination (HA1) over the HAHA 351 link (operation 6 in Figure 1). 353 Due to fact that the binding update is forwarded from one of other 354 home agents in the same global home agent set, the HA1 now detects 355 that the primary home agent is changed to the HA2. The HA1 first 356 processes the Binding Update and returns a Binding Acknowledgment to 357 the mobile node (operation 7 in Figure 1). In parallel, it triggers 358 a Home Agent Switch message [RFC5142] to the mobile node (operation 8 359 in Figure 1). In the Home Agent switch message, the home agent 360 unicast address of HA2 is stored in the Home Agent Address field so 361 that the mobile node can associate with the closest home agent. 363 When the mobile node receives the Home Agent Switch message from the 364 HA1, it switches its home agent to the HA2 according to [RFC5142]. 365 The mobile node sends another Binding Update to the HA2 (operation 9 366 in Figure 1). After receiving the Binding Update, the HA2 creates 367 the binding cache and sends a State Synchronization message to the 368 other Home Agents (i.e. HA1) in the global home agent set (operation 369 10 in Figure 1). The HA1 removes the binding cache entry of the 370 mobile node and creates a global binding as well as the route for the 371 mobile node with the next hop set to the locator address of HA2 over 372 the HAHA link. 374 3.3. Routing Packets 376 The packets originated by the mobile node are always routed through 377 the primary home agent as shown in operations 5 and 12 in Figure 1. 378 They are tunneled to the primary home agent and, then, routed 379 directly to the CN. 381 On the other hand, the packets originated by the correspondent node 382 are routed to the closest home agent by IP anycast routing as shown 383 in operations 4 and 11 in Figure 1. If the home agent is not the 384 primary home agent of the mobile node (destination), the home agent 385 looks up the global binding and routes them to the primary home agent 386 of the mobile node over the HAHA link. Then, the primary home agent 387 routes the packets to the mobile node over the Mobile IPv6's bi- 388 directional tunnel. 390 In some scenario, the path between a mobile node and a correspondent 391 node becomes asymmetric. In the global HAHA, the primary home agent 392 does not have any specific information of the correspondent nodes and 393 does not forward the packets to the closest home agent of the 394 correspondent node. 396 3.4. Differences between global HAHA and HARP 398 The global HAHA protocol makes use of the signaling defined by the 399 Home Agent Reliability protocol (HARP) [I-D.ietf-mip6-hareliability] 400 which is being standardized in the MEXT working group. However, 401 global HAHA is not designed to be operated in conjunction with HARP. 402 HARP extends Mobile IPv6 [RFC6275] to provide reliability to home 403 agents. Its concept is similar to the router's redundancy protocols 404 such as VRRP and HSRP. When one home agent fails, another standby 405 home agent located in the same home link or in a different network 406 can immediately take over the function of the failed one, so that 407 ongoing sessions of mobile nodes will not be interrupted by any 408 single home agent failures. 410 Global HAHA can also achieve reliability by relying on IP anycast 411 routing. The home subnet prefix being announced by all the home 412 agents, packets from and to mobile nodes can be forwarded to 413 remaining functional home agents in a transparent manner. In 414 addition, global HAHA can achieve better scalability and provide 415 optimized paths between a mobile node and its correspondents, by 416 always associating the nearest home agent to the mobile node. 418 4. Home Agent Configurations 420 4.1. Home Agent and Subnet Distributions 422 Figure 2 shows the subnet and home agent distribution in a global 423 HAHA system. Home agents are connected to a number of subnets 424 located in various places on Internet, they are all assigned the same 425 Provider-Independent (PI) prefix as their home subnet prefix. Each 426 home subnet is connected to the global Internet through an ISP who 427 also assigns a prefix out of its own address block to the home 428 subnet. We call this ISP assigned prefix "Locator Prefix" (LP). 429 Each home agent has two unicast IP addresses: one from its PI home 430 subnet prefix (the "home agent unicast address") and another from its 431 provider (the "home agent locator address"). Each ISP that hosts a 432 HAHA subnet also agrees to announce the HAHA's PI Home subnet prefix 433 to the global Internet, so that packets destined to any IP address 434 that belongs to the home subnet prefix are delivered to the 435 topologically closest home agent. 437 Home Link1 (2001:db8:0:1::/64) 438 HA1 439 | 440 --+-- 441 | /|\ LP-1 Prefix 442 +--------+ | 443 | ISP1 | 444 +--------+ LP-2 Prefix 445 | --> 446 +--------+ +--------+ | 447 |Backbone|--| ISP2 |----+- HA2 Home Link2 448 +--------+ +--------+ | (2001:db8:0:1::/64) 449 | 450 +--------+ 451 | ISP3 | 452 +--------+ | LP-3 Prefix 453 | \|/ 454 --+-- 455 | 456 HA3 457 Home Link3 (2001:db8:0:1::/64) 459 HA unicast address (PI) HA locator address (LP) 460 - HA1 2001:db8:0:1::1 LP-1Prefix::1 461 - HA2 2001:db8:0:1::2 LP-2Prefix::2 462 - HA3 2001:db8:0:1::3 LP-3Prefix::3 463 Figure 2: Home Subnets and Agents Distribution 465 4.2. Anycast Routing Consideration 467 IP anycast routing has been widely used in recent years. As 468 documented in [RFC4786], anycast has become increasingly popular for 469 adding redundancy to DNS servers to complement the redundancy that 470 the DNS architecture itself already provides. Several root DNS 471 server operators have distributed their servers widely around the 472 Internet, and DNS queries are directed to the nearest functioning 473 servers. Another popular anycast usage is by web service providers, 474 where two or more web farms share the same IP prefix, so that when 475 all the sites are up, HTTP requests are forwarded to the web servers 476 closest to the browsers; when a site is down, requests are 477 automatically routed to next nearest web farm. Anycast routing 478 provides a simple and effective means to provide robust services. 480 A concept related to anycast is MOAS (Multi-Origin AS) prefixes, they 481 are prefixes advertised by more than one origin AS. A MOAS prefix 482 represents an anycast prefix, although the inverse is not necessarily 483 true, i.e. an anycast prefix may not be a MOAS prefix if the prefix 484 is announced to the routing system by one origin AS out of the AS's 485 multiple locations. Our measurement using BGP data collected by 486 RouteViews and RIPE observed about 2000 or so MOAS prefixes in 487 today's global routing system, which is a very small percentage of 488 the current routing table entries of about 300K entries. 490 One basic cost from providing anycast services is an additional entry 491 in the global routing table for each anycast prefix. When the number 492 of anycast applications is small, the impact on the global routing 493 system scalability is small. The use of anycast for important 494 infrastructure services, such as DNS root servers, is well justified. 495 Using anycast to bootstrap other important services may also be 496 justified, if the services are globally scoped are commonly used, and 497 the number of anycast prefixes needed is small. However anycast is 498 clearly not for everyone or for all applications usage. It is a 499 worthwhile investigation to consider where best to draw the line. 501 5. Global HAHA Protocol 503 5.1. Home Agents Bootstrap 505 For the global HAHA protocol, each home agent SHOULD be configured 506 with the following information: 508 o An own home subnet prefix (Provider Independent prefix, PI) 510 o An own home agent unicast address (created from the PI) 512 o An own home agent locator address (created from the Locator 513 Prefix, LP) 515 o A home agent anycast address for Dynamic Home Agent Address 516 discovery mechanism (created as per [RFC2526]) 518 o A Group ID of own global home agent set 520 o Home Agent locator addresses of all the other home agents in the 521 same global home agent set. 523 A home agent first establishes HAHA links with all the other home 524 agents. How to establish a HAHA link is out of scope in this 525 document. For instance, IP tunnel is established between two home 526 agent's locator addresses. This HAHA link is used to exchange data 527 packets destined to the mobile node and binding updates coming from 528 the mobile node. Although all the Binding Updates are already 529 securely exchanged, it is recommended to secure every packets 530 tunneled over this HAHA link. Note that Home Agent HELLO message and 531 State Synchronization message do not need to be tunneled over the 532 HAHA link as they can be sent directly using the Home Agent locator 533 addresses as source and destination addresses. 535 As soon as HAHA links are fully ready, the home agent now provides 536 its home agent service to a mobile node. Without HAHA links, a home 537 agent SHOULD NOT configure with its home subnet prefix and act as a 538 home agent of the home subnet prefix. The home agent now starts 539 sending its Home Agent HELLO message as described in Section 5.2 and 540 soliciting global bindings of all the other home agents as discussed 541 in Section 5.4.3. 543 5.2. Management of global Home Agent set 545 A home agent exchanges its availability with other home agents of the 546 same global home agent set. The status exchange is done with a Home 547 Agent HELLO message defined in the Home Agent Reliability protocol 548 [I-D.ietf-mip6-hareliability]. 550 5.2.1. Home Agent List for the global HAHA 552 [RFC6275] and [I-D.ietf-mip6-hareliability] specify and extend the 553 data structure named the Home Agent List. This list is used to 554 manage home agent information at a same home link. The following two 555 fields introduced in [RFC6275] are not used in this specification: 557 o The link-local IP address of a home agent 559 o The preference for this home agent 561 5.2.2. Modified HARP Message 563 This specification defines a new flag for the HARP HA-HELLO message 564 (Type 4): 566 0 1 2 3 567 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 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Type | Group ID | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Sequence # |A|R|V|M|G| Rsvd| Status | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Home Agent Preference | Home Agent Lifetime | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Hello Interval | | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 577 | | 578 . Mobility Options . 579 . . 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 Figure 3: HARP Message 584 Home Agent Preference 586 In this specification, a same preference value is used among home 587 agents in a global home agent set. A home agent is selected by a 588 mobile node according to routing topology (i.e. anycast routing), 589 but not by these preference values. This value SHOULD be set to 590 0. The receiver SHOULD ignore this value. 592 Group Identifier 593 This value is used to identify a particular global home agent set. 595 Global (G) flag 597 Global HA flag. If this flag is set, the home agent sending this 598 HA-HELLO message is operated with this specification. 600 5.2.3. Sending Home Agent Hello Messages 602 Each home agent periodically sends HA-HELLO to the other home agents 603 in the same global home agent set. Each home agent MUST also 604 generate HA-HELLO in the following cases: 606 o when a home agent receives a HA-HELLO with the G (Global HA) and R 607 (Request) flag set 609 o When a new home agent boots up, it SHOULD solicit HA-HELLO 610 messages by sending a HA-HELLO with the G and R-flag set in 611 parallel with sending its own HA-HELLO message. 613 When a home agent sends HA-HELLO, the following rule MUST be applied 614 in addition to the Section 4.3.2.1 of [I-D.ietf-mip6-hareliability]. 616 o It MUST set G flag in HA-HELLO. 618 o It MUST specify its global home agent set's ID to the Group ID 619 field in HA-HELLO. 621 o The source and destination IPv6 addresses of the IPv6 header of 622 the HA-HELLO MUST be the source and destination home agent locator 623 addresses. They MUST belong to the same global home agent set. 625 o It MUST protect HA-HELLO by IPsec ESP. 627 5.2.4. Receiving Hello Message 629 When a home agent receives HA-HELLO, it follows the verification 630 described in Section 4.3.2.2 of [I-D.ietf-mip6-hareliability]. In 631 addition to this, it MUST process HA-HELLO which G flag is set as 632 follows: 634 o If the HA-HELLO is not protected by IPsec ESP, it MUST be 635 discarded. 637 o If the source IPv6 address of HA-HELLO does not belong to one of 638 the home agents in the redundant home agent set, the HA-HELLO MUST 639 be ignored. 641 o If the Group ID field of the received HA-HELLO and the receiver's 642 Group ID are different, HA-HELLO MUST be discarded. HA-HELLO MUST 643 NOT be sent to home agents whose Group ID is different from the 644 sender. 646 o HA-HELLO satisfying all of above tests MUST be processed by 647 receiver. The receiver copies home agent information in HA-HELLO 648 to the corresponding home agent list entry. The home agent 649 locator address of the sender is retrieved from the source address 650 field of the IPv6 header of the HA-HELLO. 652 5.3. Primary Home Agent Receiving Binding Update 654 The binding update sent by a mobile node is routed to the one of home 655 agents in the global home agent set according to the anycast routing. 656 If the receiver does not have any binding cache entry nor global 657 binding for this mobile node, it processes the binding update 658 according to [RFC6275] and stores a binding cache entry for the 659 mobile node. After successful binding registration, the home agent 660 becomes a primary home agent for the mobile node. The primary home 661 agent has the following functional requirements: 663 o Delivering IP packets destined to the mobile node over the bi- 664 directional tunnel 666 o Updating the binding according to the mobile node's binding 667 refreshment 669 o Notifying the mobile node binding to the other home agents in the 670 same global home agent set 672 o Sending a Home Agent Switch message if another home agent is more 673 preferable to be the primary home agent. Usually, this is 674 trigerred by the reception of a valid Binding Update via another 675 home agent of the global home agent set 677 o Providing state synchronization information to other home agents 678 of the global home agent set when a binding is created, updated, 679 removed or upon request. 681 The binding registration and management are the same as specified in 682 [RFC6275]. The global HAHA requires to register global bindings of 683 the mobile node by sending the state synchronization message to all 684 the other home agents as described in the next section. 686 5.4. Global Binding Management 688 5.4.1. Global Binding 690 A global binding has the following information. Any mobile node's 691 specific information can be potentially stored in the global binding. 692 The aim of this global binding is to forward the data packets of a 693 mobile node received at non-primary home agent to the primary home 694 agent of the mobile node. It is not used to deliver a packet 695 directly to a mobile node from the non-primary home agents. 696 Therefore, the mobile node's care-of address is not necessary in the 697 global binding, more than likely the primary home agent of the mobile 698 node is important in the global binding. 700 o The primary home agent locator address 702 o The mobile node's home address 704 o The mobile router's mobile network prefix(es) 706 o The binding sequence number of a binding update 708 o The flags of a binding update 710 o The lifetime of the global binding 712 o The mobile node's care-of address (optional) 714 The modified State Synchronization message 715 [I-D.ietf-mip6-hareliability] described in the next section is used 716 to exchange the global bindings among the home agents. 718 When a global binding is created, the home agent MAY use proxy 719 Neighbor Discovery or IP routing to intercept the packets addressed 720 to the mobile node's home address. 722 When a global binding is created, the home agent MUST create a mobile 723 node's route entry which next hop is set to the locator address of 724 the primary home agent. If a mobile node is a mobile router 725 [RFC3963], the following mobile node's routes are created: one for 726 the home address and one per mobile network prefix. If the mobile 727 router's home address is derived from its mobile network prefix 728 [RFC3963] (i.e. the operation of aggregated home network [RFC4887]), 729 only a single route for the mobile network prefix is sufficient. 731 5.4.2. Modified State Synchronization Message and Mobility Option 733 Figure 4 shows the modified version of the state synchronization (SS) 734 message defined in [I-D.ietf-mip6-hareliability]. A new G flag is 735 introduced to explicitly indicate the global binding registration. 737 0 1 2 3 738 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 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 740 | Type |A|G| Reserved | 741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 | Identifier | | 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 744 . . 745 . Mobility Options . 746 . . 747 . | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 Figure 4: State Synchronization Message 752 Global (G) flag 754 When State Synchronization messages are exchanged for global 755 binding registration, the Global flag MUST be set. 757 Mobility Options 759 The Binding Cache Information Option as defined in 760 [I-D.ietf-mip6-hareliability] is mandatory for the State 761 Synchronization Request (SS-REQ) message (Type 0) as well as State 762 Synchronization Reply (SS-REP) message (Type 1). 764 Others options (e.g. AAA Information option, Vendor Specific 765 Mobility option, as well as the others referenced in 766 [I-D.ietf-mip6-hareliability]) can be used too. 768 The SS Status Option as defined in [I-D.ietf-mip6-hareliability] 769 MUST be used in the State Synchronization Reply-Ack (SS-ACK) 770 message (Type 2). 772 5.4.3. Global Binding Registration 774 If a primary home agent sends a SS-REP message for every binding 775 registration from a mobile node, it causes certain overhead to 776 exchange messages. Unless the binding information is changed (except 777 for sequence number and lifetime), the state synchronization reply 778 message is not necessarily sent per mobile nodes' binding 779 refreshment. A SS-REP message MUST be sent by a primary home agent 780 to register a global binding at the following timing: 782 o When a primary home agent registers a binding for a mobile node 783 for the first time. The primary home agent MUST register a global 784 binding to the global home agent set. 786 o When a global binding is expired. The primary home agent MUST 787 refresh the global binding. 789 When a primary home agent receives a binding update from a mobile 790 node and registers a binding for it, it sends a State Synchronization 791 Reply message. SS-REP is sent to all the other home agents in the 792 global home agent set with the following rules: 794 o The A (Ack) and G (Global) flags MUST be set in SS-REP. 796 o At least, one Binding Cache Information Option MUST be stored in 797 the mobility option field. Multiple options can be stored in a 798 SS-REP. 800 o Other optional mobility options listed in Section 5.4.2 MAY be 801 stored in the mobility option field. 803 o IPsec ESP MUST be applied. 805 o The source and destination addresses of the SS-REP MUST be the 806 source and destination home agent locator addresses. 808 o The source and destination addresses MUST belong to the same 809 global home agent set. 811 When a home agent receives the SS-REP, the following rules must be 812 applied to the received SS-REP: 814 o If the SS-REP is not protected by IPsec ESP, it MUST be discarded. 816 o If no options are carried in SS-REP, the receiver MUST ignore the 817 SS-REP and MUST send SS-ACK with the Status Synchronization Status 818 option which status value is set to the newly defined value [131: 819 No Mobility Option]. 821 o If the sender of SS-REP is not in the same global home agent set, 822 the receiver MUST reject the SS-REP and MUST send SS-ACK with the 823 Status Synchronization Status option which status value is set to 824 [130: Not in same global home agent set]. 826 o If the G flag is not set in RR-REP, the receiver MUST ignore the 827 SS-REP and MUST send SS-ACK with the Status Synchronization Status 828 option which status value is set to [129: Malformed SS-REP]. 830 o If no errors are found in SS-REP, the receiver MUST register or 831 update the global binding per Binding Cache Information Option. 832 If the supplemental mobility options are specified for a mobile 833 node, the information MUST be stored in the global binding. 835 o After the successful global binding registration, it MUST create a 836 mobile node's route entry which next hop is set to the primary 837 home agent locator address (i.e. the sender of SS-REP). If a 838 mobile node is a mobile router [RFC3963], the following mobile 839 node's routes are created: one for the home address and one per 840 mobile network prefix. If the mobile router's home address is 841 derived from its mobile network prefix [RFC3963] (i.e. the 842 operation of aggregated home network [RFC4887], only a single 843 route for the mobile network prefix is sufficient. 845 o The receiver of SS-REP then sends SS-ACK with state 846 synchronization status mobility options for all the mobile nodes 847 registering its global binding. 849 When a home agent needs to solicit SS-REP, it can send SS-REQ to a 850 home agent. The rules to construct SS-REQ is described in Section 851 4.4.3 of [I-D.ietf-mip6-hareliability]. In addition, the following 852 rules MUST be applied: 854 o IPsec ESP MUST be applied. 856 o The source and destination addresses of the SS-REQ MUST be the 857 source and destination home agent locator addresses. 859 o The source and destination addresses MUST belong to the same 860 global home agent set. 862 5.5. Primary Home Agent Switch 864 Primary Home Agent switch operation consists of two binding update 865 exchanges. The first binding update is basically used by a primary 866 home agent to detect the better home agent in the same global home 867 agent set and to trigger sending a home agent switch message to 868 mobile nodes. The second one is to complete primary home agent 869 switch by registering the binding to the new primary home agent. 871 When a mobile node moves, it sends a binding update to its primary 872 home agent currently registering the binding. If the binding update 873 is directly routed to the destination (i.e. home agent), there is no 874 need to start the primary home agent switch. On the other hand, if 875 the binding update is first routed to one of non-primary home agents, 876 the receiver of the binding update SHOULD become the primary home 877 agent of the mobile node from the routing perspective. The receiver 878 does not operate any inspection of the binding update and simply 879 forwards it to the destination address of the binding update over the 880 HAHA link. 882 Once the primary home agent receives the binding update forwarded by 883 one of home agents in the same global home agent set, it processes 884 the binding update as described in Section 5.3. In addition, it 885 starts sending a home agent switch message [RFC5142] for the primary 886 home agent switch operation. How to send the home agent switch 887 message is described in [RFC5142] and Section 4.5 of 888 [I-D.ietf-mip6-hareliability]. 890 The mobile node receiving the home agent switch message simply 891 updates its home agent address and re-registers its binding to the 892 new primary home agent. The new primary home agent sends SS-REP to 893 all the other home agents to update its global binding. After 894 receiving SS-REP, the previous primary home agent SHOULD delete its 895 original binding and create a global binding for the mobile node. 896 According to [RFC5142], upon receipt of a Home Agent Switch message, 897 the mobile node must delete its home binding by sending a Binding 898 Update deregistration message. However, the mobile node SHOULD NOT 899 send this de-registration in this specification, since the previous 900 active home agent knows the primary home agent switch by receiving 901 the SS-REP. Although this represents a slight modification of the 902 mobile node side, this helps achieving minimum latency of the primary 903 home agent switch by eliminating the binding de-registration process. 905 5.6. Packet Interception and Delivery 907 When a home agent receives a packet destined to a mobile node, it 908 first check the binding cache. If it finds an original binding, it 909 tunnels the packet to the mobile node over the bi-directional tunnel. 910 Otherwise, it checks the global binding of the mobile node. If it 911 finds the global binding, it then routes the packet to the primary 912 home agent recorded in the global binding over the HAHA link. The 913 packet is delivered to the primary home agent by IP encapsulation. 914 In the outer IP header, the home agent source and destination locator 915 addresses should be used. If neither a binding nor a global binding 916 is found, the packet MUST be simply discarded. The home agent SHOULD 917 return an ICMP Destination Unreachable (Code 3) message to the 918 packet's source address (unless this source address is a multicast 919 address). 921 5.7. Home Agents Discovery 923 When a mobile node boots up and needs to discover a home agent, it 924 can either use Dynamic Home Agent Address Discovery (DHAAD) or 925 perform a DNS lookup by home agent name or service name as specified 926 in [RFC5026]. 928 In the DHAAD case, the mobile node simply sends a DHAAD request 929 message to the home agent anycast address. In that case, the DHAAD 930 request message is routed to the closest home agent via IP anycast 931 routing. The closest home agent SHOULD return its own unicast 932 address with the highest priority in the DHAAD reply message so that 933 the mobile node can use the closest home agent for its binding 934 registration. 936 In the DNS case, the lookup by home agent name or service name may 937 return either the home agent anycast address or a home agent unicast 938 address. In both cases, the binding update sent by the mobile node 939 will reach the closest home agent thanks to IP anycast routing. 940 However, in the second case, the binding update may be forwarded by 941 that home agent towards the owner of the home agent unicast address 942 used in the binding update. In that case, a primary home agent 943 switch may be initiated right after the registration of the mobile 944 node. In order to avoid this case, the DNS may be configured to 945 return only the home agent anycast address, or have the necessary 946 mechanisms to return the unicast address of the closest home agent 947 for the mobile node. 949 6. IANA considerations 951 This document does not contain any actions for the IANA 953 7. Security Considerations 955 TBA: Section 7 of [I-D.ietf-mip6-hareliability] gives useful 956 information. 958 8. Acknowledgements 960 We would like to thank to Pascal Thubert and Vijay Devarapalli for 961 the original discussion of the global HAHA. We also thank to Arnaud 962 Ebalard for his review and valuable comments. 964 9. References 966 9.1. Normative References 968 [I-D.ietf-mip6-hareliability] 969 Wakikawa, R., "Home Agent Reliability Protocol (HARP)", 970 draft-ietf-mip6-hareliability-09 (work in progress), 971 May 2011. 973 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 974 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 975 RFC 3963, January 2005. 977 [RFC5142] Haley, B., Devarapalli, V., Deng, H., and J. Kempf, 978 "Mobility Header Home Agent Switch Message", RFC 5142, 979 January 2008. 981 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 982 in IPv6", RFC 6275, July 2011. 984 9.2. Informative References 986 [I-D.ietf-mext-nemo-ro-automotive-req] 987 Baldessari, R., Ernst, T., Festag, A., and M. Lenardi, 988 "Automotive Industry Requirements for NEMO Route 989 Optimization", draft-ietf-mext-nemo-ro-automotive-req-02 990 (work in progress), January 2009. 992 [I-D.kuntz-dmm-summary] 993 Kuntz, R., Sudhakar, D., Wakikawa, R., and L. Zhang, "A 994 Summary of Distributed Mobility Management", 995 draft-kuntz-dmm-summary-01 (work in progress), 996 August 2011. 998 [I-D.thubert-mext-global-haha] 999 Thubert, P., Wakikawa, R., and V. Devarapalli, "Global HA 1000 to HA protocol", draft-thubert-mext-global-haha-01 (work 1001 in progress), July 2009. 1003 [I-D.wakikawa-mext-haha-interop2008] 1004 Wakikawa, R., Shima, K., and N. Shigechika, "The Global 1005 HAHA Operation at the Interop Tokyo 2008", 1006 draft-wakikawa-mext-haha-interop2008-00 (work in 1007 progress), July 2008. 1009 [I-D.wakikawa-mip6-nemo-haha-spec] 1010 Wakikawa, R., "Inter Home Agents Protocol Specification", 1011 draft-wakikawa-mip6-nemo-haha-spec-01 (work in progress), 1012 March 2006. 1014 [PAPER-CONEXT] 1015 Wakikawa, R., Valadon, G., and J. Murai, "Migrating Home 1016 Agents towards Internet-Scale Mobility Deployments", 1017 CoNEXT 2006 Conference on Future Networking Technologies, 1018 December 2006. 1020 [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 1021 Addresses", RFC 2526, March 1999. 1023 [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and 1024 Multicast Next-Hop Selection", RFC 2991, November 2000. 1026 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1027 RFC 3753, June 2004. 1029 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 1030 Services", BCP 126, RFC 4786, December 2006. 1032 [RFC4885] Ernst, T. and H-Y. Lach, "Network Mobility Support 1033 Terminology", RFC 4885, July 2007. 1035 [RFC4887] Thubert, P., Wakikawa, R., and V. Devarapalli, "Network 1036 Mobility Home Network Models", RFC 4887, July 2007. 1038 [RFC4888] Ng, C., Thubert, P., Watari, M., and F. Zhao, "Network 1039 Mobility Route Optimization Problem Statement", RFC 4888, 1040 July 2007. 1042 [RFC4889] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network 1043 Mobility Route Optimization Solution Space Analysis", 1044 RFC 4889, July 2007. 1046 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 1047 Bootstrapping in Split Scenario", RFC 5026, October 2007. 1049 [RFC5522] Eddy, W., Ivancic, W., and T. Davis, "Network Mobility 1050 Route Optimization Requirements for Operational Use in 1051 Aeronautics and Space Exploration Mobile Networks", 1052 RFC 5522, October 2009. 1054 Authors' Addresses 1056 Ryuji Wakikawa 1057 Toyota InfoTechnology Center USA, Inc. 1058 465 Bernardo Ave 1059 Mountain View, California 94045 1060 USA 1062 Email: ryuji@us.toyota-itc.com 1064 Romain Kuntz 1065 Toyota InfoTechnology Center USA, Inc. 1066 465 Bernardo Ave 1067 Mountain View, California 94045 1068 USA 1070 Email: rkuntz@us.toyota-itc.com 1072 Zhenkai Zhu 1073 UCLA 1074 420 Westwood Plaza 1075 Los Angeles, California 90095 1076 USA 1078 Email: zhenkai@cs.ucla.edu 1080 Lixia Zhang 1081 UCLA 1082 3713 Boelter Hall 1083 Los Angeles, California 90095-1596 1084 USA 1086 Email: lixia@cs.ucla.edu