idnits 2.17.1 draft-sarikaya-dmm-dmipv6-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 1, 2012) is 4467 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: 'RFC2119' is defined on line 476, but no explicit reference was found in the text == Unused Reference: 'RFC3810' is defined on line 512, but no explicit reference was found in the text == Unused Reference: 'RFC3376' is defined on line 515, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-mip6-hiopt-17 -- Possible downref: Normative reference to a draft: ref. 'I-D.xia-mext-hioptv4' ** Downref: Normative reference to an Informational RFC: RFC 4187 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Sarikaya 3 Internet-Draft Huawei USA 4 Intended status: Standards Track February 1, 2012 5 Expires: August 4, 2012 7 Distributed Mobile IPv6 8 draft-sarikaya-dmm-dmipv6-00.txt 10 Abstract 12 As networks are moving towards flat architectures, a distributed 13 approach is needed to Mobile IPv6. This document defines a 14 distributed mobility management protocol. Protocol is based on 15 Mobile IPv6 and its extensions for multiple care of address 16 registration, flow mobility and dual stack mobile IPv6 with minimum 17 extensions. Control and data plane separation is achieved by 18 separating Home Agent functionalities into the control and data 19 planes. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 4, 2012. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Correspondent Node Operation . . . . . . . . . . . . . . . . . 5 59 5. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 6 60 6. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 7 61 6.1. Multiple Interface Operation . . . . . . . . . . . . . . . 8 62 7. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 8. Control and Data Plane Separation . . . . . . . . . . . . . . 9 64 9. Authentication for Distributed Mobility Management . . . . . . 10 65 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 66 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 67 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 68 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 13.1. Normative References . . . . . . . . . . . . . . . . . . . 11 70 13.2. Informative references . . . . . . . . . . . . . . . . . . 12 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 1. Introduction 75 Mobile IPv6 defines client based mobility support to the mobile nodes 76 and is defined in [RFC6275]. There are several extensions to Mobile 77 IPv6 such as multiple Care-of Address registration for multi-homed 78 mobile nodes [RFC5648], flow mobility [RFC6089] and Dual Stack Mobile 79 IPv6 [RFC5555]. Mobile IPv6 is based on a centralized mobility 80 anchoring architecture. 82 Centralized mobility anchoring has several drawbacks such as single 83 point of failure, routing in a non optimal route, overloading of the 84 centralized data anchor point due to the data traffic increase, low 85 scalability of the centralized route and context management 86 [I-D.liu-mext-distributed-mobile-ip]. 88 In this document, we define a client based distributed mobility 89 management protocol. The protocol assumes a flat network 90 architecture as shown in Figure 1 91 [I-D.liu-mext-distributed-mobile-ip]. Access router on each link 92 mobile node visits is expected to have the home agent capabilities. 93 Unlike in Mobile IPv6, mobile node at a given time may be registered 94 with more than one home agent and may be receiving data tunneled from 95 these home agents. Mobile IPv6 used in such a flat architecture 96 removes the need for route optimization which has many flaws such as 97 revealing the mobile nodes location to the outside 98 [I-D.liu-mext-distributed-mobile-ip]. 100 Control and data plane separation is stated as a requirement for the 101 distributed mobility management. Mobile IPv6 control plane is used 102 for registration and handover signaling and for establishing security 103 association, e.g. IPSec SAs. Data plane is used for data transfer 104 from the corresponding nodes (CN) to MN and from MN to CNs. 105 Typically control plane traffic is much ligther than the data plane 106 traffic and thus the control plane can be centralized while 107 distributing the data plane. This separation however requires new 108 signaling between the control and data plane functional entities 109 [I-D.yokota-dmm-scenario]. 111 Client based distributed mobility management protocol is designed 112 based on Mobile IPv6 protocols and its many extensions with a minimum 113 amount of extensions. 115 Due to the popularity of mobile nodes with multiple interfaces client 116 based distributed mobility management protocol must support multi- 117 homed mobile nodes. In this document, this is achieved by way of 118 using [RFC5648]. Flow mobility among the interfaces need to be 119 supported and this is accomplished using [RFC6089]. Mobile nodes in 120 IPv4 only networks also need to be supported and this is done using 122 [RFC5555]. 124 Access to a content delivery network (CDN) is done using 125 multicasting. Mobile node operation for multicasting is needed for a 126 client based distributed mobility management protocol. The current 127 trend is that service providers tend to relieve the core network 128 traffic by placing the content closer to the users in the access 129 network in the form of cache or local CDN servers. Multicast support 130 in the client based distributed mobility management protocol is out 131 of scope. 133 +---+ +---+ +---+ 134 |CN1| |CN2| |CN3| 135 +---+ +---+ +--,+ 136 _.---------+----------. \ 137 ,----'' | `---'-. 138 ,-' | \ `-. 139 ,' | ' `. 140 ( IP Network| \ 141 `. | ' ,' 142 `-. ; ,\' 143 ;-----. ; _.----' ' 144 ,' `---------+----------'' | 145 / | ' 146 +---'---+ +---:---+ +-------+ 147 | AR1 | | AR2 |------------| AR3 | 148 | HA | | HA |------------|HA | 149 +-------+ +-------+ +-------+ 150 \\ \ 151 \\ ' 152 +-----+ +--\--+ 153 | MN | ----move-------> | MN | 154 +-----+ +-----+ 156 Figure 1: Architecture of Distributed Mobile IPv6 Protocol 158 2. Terminology 160 This document uses the terminology defined in [RFC6275]. 162 3. Overview 164 This section presents an overview of the protocol. 166 Home agent capable access routers (AR) send router advertisements 167 (RA) with Home Agent Information Option. Mobile node caches the home 168 agent address when it receives such an RA. Cache entries expire 169 after a timeout period. Only the first entry from MN's home link 170 does not expire. 172 Mobile node uses a home agent after it moves to another link and if 173 it still has ongoing communication with a correspondent node. MN 174 gets a new Care-of Address (CoA) on the new link and MN sends a 175 Binding Update message to the HA on the previous link to register CoA 176 with HA. Binding Acknowledgement received from HA completes the 177 registration. MN starts to receive the packets over HA-MN link from 178 CN and MN starts to reverse tunnel packets to the CN. 180 At each link, mobile node goes through bootstrapping if the router 181 advertisement from the access router does not contain Home Agent 182 Information Option. Using [RFC5026] MN either does DNS lookup by 183 home agent name or by service name. MN gets the local domain name 184 during link establishment. This constitutes dynamic assignment of 185 the home agent and [RFC5026] allows such a dynamic assignment as 186 mentioned in Section 5.1.1. 188 Alternatively, MN can use stateless DHCP for Home Info discovery as 189 in [I-D.ietf-mip6-hiopt]. Dynamic home agent address assignment 190 using DHCP is allowed as mentioned in Section 1. 192 After the bootstrapping, MN gets a new Care-of Address. MN uses this 193 new address as its new Home Address and registers it in the DNS. HA 194 can register MN's address in the DNS if MN sets DNS Update Mobility 195 Option defined in [RFC5026] and sends it in the binding update to HA. 196 MN sets R bit to zero. The procedure for sending a dynamic DNS 197 update message is specified in [RFC2136]. AAA server could also 198 register MN's new address in the DNS. MN also removes DNS entries 199 with MN's Home Addresses that are no longer used. MN sends BU with 200 DNS Update Mobility Option. MN sets the R flag in the option and 201 sets its old address as the FQDN in the option. 203 MN uses Cryptographically Generated Addresses if the link is a public 204 multi-access link. Wireless LAN links especially in public hotspots 205 are examples of such links. 207 4. Correspondent Node Operation 209 This protocol removes the need for route optimization. Corresponding 210 nodes receive regular IPv6 data packets sent by the mobile nodes and 211 reverse tunneled from the home agent. Also corresponding nodes do 212 not need to be involved in any route optimization message exchanges 213 nor maintaining state, i.e. binding cache. 215 Correspondent nodes when communicating with the same mobile node may 216 only receive regular IPv6 data packets with no mobility headers. In 217 some cases these packets are directly sent by the mobile node, i.e. 218 when the mobile node is not using its home agent and in some other 219 cases, i.e. when the mobile node starts using a home agent, coming 220 via the home agent. 222 5. Home Agent Operation 224 Home agent provides mobility support to the mobile nodes as defined 225 in [RFC6275]. 227 Home agent receiving the DNS Update mobility option MUST process the 228 option as described in Section 6 of [RFC5026]. The dynamic DNS 229 update SHOULD be performed in a secure way. After the DNS update, 230 the home agent MUST send a Binding Acknowledgement message to the 231 Mobile Node, including the DNS Update mobility option with the 232 correct value in the Status field. 234 Home agent receiving the DNS Update mobility option with R-flag set 235 the Home Agent MUST remove the DNS entry and MUST send Binding 236 Acknowledgement message to the Mobile Node, including the DNS Update 237 mobility option with the correct value in the Status field. Home 238 agent MUST remove the DNS entry upon receiving a deregistration BU 239 from the mobile node. Home agent MAY use the binding cache entry 240 expiration as a trigger to remove the DNS entry. 242 In this specification route optimization is DISABLED. This means 243 that Home Test Init, Care-of Test Init, Home Test, Care-of Test 244 messages defined in [RFC6275] are not used in this specification. 246 Home agent MUST support multiple Care-of address registration 247 [RFC5648] and flow mobility for multi homed mobile nodes [RFC6089]. 248 Home agent MUST maintain several flow bindings for a given home 249 address and to direct packets to different care-of addresses 250 according to flow bindings. Home agent MUST keep a flow binding list 251 which is associated with the mobile node with an entry for each flow 252 that is registered. 254 Dual stack home agent MUST support Dual Stack Mobile IPv6 protocol 255 defined in [RFC5555]. When home agent receives Binding Update 256 message with IPv4 CoA option and IPv4 Home Address option home agent 257 sets a home address and/or prefix, creates a binding cache entry for 258 this mobile node and then sends back a binding acknowledgement 259 message with IPv4 Address Acknowledgement option which includes an 260 IPv4 home address. 262 6. Mobile Node Operation 264 Mobile nodes keep a cache of home agent addresses. This cache is 265 called Binding Update List in [RFC6275] and is used for route 266 optimization. In this specification, home agent cache or binding 267 update list is used to keep track of the home agents with which the 268 mobile node is currently registered and not for route optimization. 270 Mobile node sends periodic binding update messages to each home agent 271 in the home agent cache if the sessions initiated when mobile node 272 was on home agent's link. This keeps the HA-MN tunnel active. 273 Mobile node MAY send a deregistration BU when the sessions initiated 274 with the home agent are no longer active. 276 If mobile node receives a router advertisement with Home Agent 277 Information option it adds an entry to the home agent cache. Mobile 278 node does not establish a binding with a home agent until it moves to 279 a new link and still has active sessions initiated when on link. On 280 the new link, if a binding update message is not sent the cache entry 281 for this home agent is removed. 283 On a new link, mobile node does a DNS lookup for a Home Agent address 284 if it is configured with a DNS server address. If the Mobile Node is 285 configured with the Fully Qualified Domain Name of the Home Agent it 286 does DNS lookup by home agent name. Otherwise mobile node does DNS 287 lookup by service name and constructs a request with QNAME set to 288 "_mip6._ipv6.example.com" and QTYPE to SRV. 290 On a new link, mobile node does home agent address discovery using 291 stateless DHCP if configured. Mobile node as DHCP Client exchanges 292 home network information with DHCP server. Mobile node sends 293 Information-request message including the Home Network Information 294 option. Mobile node indicates its preference about the requested 295 home network with the Id-type in the Home Network Information option. 296 Mobile node MUST set the Id-type to 2 to indicate that the mobile 297 node has no preferred home network. Such a value is needed for 298 bootstrapping on any link. DHCP server returns the Reply message 299 including a Home Network Information option which contains home agent 300 address and home network prefix. 302 In the registration binding update message mobile node MUST set DNS 303 Update mobility option so that home agent does DNS update on its 304 behalf. Mobile node does not set the flag R in the option. Mobile 305 node sets the MN identity field in DNS Update option with its FQDN 306 and sets its Home Address in the Home Address Option. DNS update is 307 made based on these values. 309 Mobile node starts to use a home agent after it moves to a new link 310 and if it still has ongoing communication with a correspondent node. 311 MN registers its care-of address with the home agent. MN changes its 312 communication with the corresponding node: MN starts to receive the 313 packets over HA-MN link from CN and MN starts to reverse tunnel 314 packets to the CN. To the corresponding nodes this change is 315 invisible except for some additional delays the tirangular route may 316 introduce. 318 6.1. Multiple Interface Operation 320 When a new interface becomes active such as Wi-Fi the mobile node 321 forms an address and starts using that interface for communication on 322 that link. No home agent is involved. When the mobile node starts 323 to use a home agent any new communication on the new interface MUST 324 use the registered home address. Mobile node MUST register its 325 care-of address with this home agent as described in [RFC5648]. In 326 the Binding Update message, Binding Identifier Mobility option 327 defined in MUST be used. Mobile node MUST assign a BID for this 328 Care-of Address which is unique. Mobile node also MUST assign a BID- 329 PRI for this BID with lower value indicating a higher priority. If 330 the registration is successful mobile node receives a binding 331 acknowledgement with Status set to zero in the Binding Identifier 332 Mobility option. 334 Multiple Care-of address registration allows flow mobility between 335 interfaces of a mobile node. Mobile node can then move flows by 336 sending BU with flow identification mobility option. 338 Multiple interfaces and possible use of multiple home address 339 registered with the home agents makes it important for the mobile 340 node to select the correct source address in sending packets. 342 7. IPv4 Support 344 In IPv4 only foreign networks mobile node gets an IPv4 care-of 345 address. It registers this address with a dual stack home agent only 346 after moving to a new link and with open sessions with the 347 correspondent nodes. Mobile node includes IPv4 CoA option and IPv4 348 Home Address option in the binding update message when registering 349 and gets an IPv4 Home Address assigned. Mobile node does a DNS 350 update registering its IPv4 home address on the DNS. 352 In IPv4 only foreign networks mobile node does stateless DHCP in 353 order to receive the home network information. Mobile node MUST use 354 Home Network Information DHCPv4 option defined in 355 [I-D.xia-mext-hioptv4]. 357 8. Control and Data Plane Separation 359 ------------+----------. 360 / Binding Cache and \ 361 | Security Associations | 362 \ / 363 ------------------------- 364 ,-' | `-. 365 +---'----+ +---:----+ +--------+ 366 | HA | | HA | | HA | 367 | Data | | Data | | Control| 368 | Plane | | Plane | | Plane | 369 |Function| |Function| |Function| 370 +--------+ +--------+ +--------+ 371 / \\ \ 372 / \\ ' 373 +-----+ +--\--+ 374 | MN |---move----> | MN | 375 +-----+ +-----+ 377 Figure 2: Architecture of Control and Data Planes 379 Control and data plane separation can be achieved by dividing HA into 380 two functional entities: control plane functional entity and data 381 plane functional entity as shown in Figure 2. These functional 382 entities can be hosted on different physical entities. These two 383 entities must share a common database. The database contains the 384 binding cache and the security association information such as IPSec 385 keys. 387 MN first communicates with the control plane function to establish 388 security association. Address configuration and binding registration 389 follows. Next MN receives/sends data packets using the data plane 390 function closest to the link MN is attached. 392 When MN moves MN does handover signaling with the control plane 393 function which updates the binding cache based on this move. Control 394 plane function informs the new data plane function of this binding 395 cache update and then this MN starts to receive and send data to the 396 new data plane function. MN MUST keep HA control plane function 397 address in cache so that it can conduct handover signaling with it. 399 When MN boots, it goes through authentication and security 400 association establishment. Next MN sends a binding update. MN does 401 these steps with HA control plane function. MN sends Binding Update 402 message to HA control plane function and receives a Binding 403 Acknowledgement message and in this message MN MUST receive HA data 404 plane function address. 406 HA data plane function address can be provided by HA control plane 407 function to MN in Alternate Home Agent Tunnel Address option defined 408 in [I-D.perkins-mext-hatunaddr] of BA message [RFC6275]. 410 Control and data plane separation does not require protocol 411 extensions except the sharing of binding cache and security 412 associations database. How this sharing can be accomplished is left 413 out of scope with this specification. 415 9. Authentication for Distributed Mobility Management 417 Currently, MN and HA create security associations (SA) based on the 418 home address using IKEv2 as the key exchange protocol. When MN moves 419 SAs are reestablished when MN gets a new care-of address. After SA 420 is established, MN and HA use Encapsulating Security Payload (ESP) 421 encapsulation for Binding Updates and Binding Acknowledgements 422 [RFC4877]. 424 IKEv2 enables the use of EAP authentication and provides EAP 425 transport between MN as the peer and HA as the authenticator. EAP 426 authentication is done using one of the EAP methods such as EAP-AKA 427 [RFC4187]. 429 MN is authorized as a valid user using EAP authentication. IKEv2 430 public key signature authentication with certificates is used to 431 authenticate the home agent and derive keys to be used in exchanging 432 BU/BA securely. MN can use the same identity, e.g. MN-NAI during 433 both EAP and IKEv2 authentication. 435 On the other hand MN goes through the access authentication when it 436 first connects to the network. A typical access authentication 437 protocol is AKA. MSK derived from this authentication serves as the 438 session key in accessing the air interface. 440 There is an overlap between the access and user authentications 441 sometimes done using the same protocol, e.g. AKA. Full EAP method 442 execution may take several round trips, some times five or more round 443 trips and slow down the user access to the Internet. This is 444 especially an important consideration in Distributed Mobility 445 Management since MN may connect to several home agents instead of 446 staying anchored at one home agent. 448 In order to reduce the number of round trips EAP authenticaton can be 449 combined with reauthentication. Reauthentication is EAP method 450 dependent. EAP-AKA reauthentication takes only one round trip 451 [RFC4187]. MN must go through an EAP-AKA reauthentication before 452 when MN was connected to the previous HA. During reauthentication 453 reauthentication ID is generated. MN MUST use its reauthentication 454 ID during IKEv2 EAP authentication with the new home agent. This 455 ensures that EAP-AKA authentication takes only one round trip. MN 456 continues to use its reauthentication ID in subsequent 457 reauthentication runs with the same HA. 459 10. Security Considerations 461 TBD. 463 11. IANA Considerations 465 TBD. 467 12. Acknowledgements 469 Romain Kuntz provided many comments that has lead to improvements in 470 this document. 472 13. References 474 13.1. Normative References 476 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 477 Requirement Levels", BCP 14, RFC 2119, March 1997. 479 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 480 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 481 RFC 2136, April 1997. 483 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 484 in IPv6", RFC 6275, July 2011. 486 [RFC5026] Giaretta, G., Kempf, J., and V. Devarapalli, "Mobile IPv6 487 Bootstrapping in Split Scenario", RFC 5026, October 2007. 489 [RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and 490 Routers", RFC 5555, June 2009. 492 [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., 493 and K. Nagami, "Multiple Care-of Addresses Registration", 494 RFC 5648, October 2009. 496 [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., 497 and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and 498 Network Mobility (NEMO) Basic Support", RFC 6089, 499 January 2011. 501 [I-D.ietf-mip6-hiopt] 502 Jang, H., Yegin, A., Chowdhury, K., and J. Choi, "DHCP 503 Options for Home Information Discovery in MIPv6", 504 draft-ietf-mip6-hiopt-17 (work in progress), May 2008. 506 [I-D.xia-mext-hioptv4] 507 Xia, F. and B. Sarikaya, "DHCPv4 Options for Home 508 Information Discovery in Dual Stack MIPv6", 509 draft-xia-mext-hioptv4-04 (work in progress), 510 January 2012. 512 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 513 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 515 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 516 Thyagarajan, "Internet Group Management Protocol, Version 517 3", RFC 3376, October 2002. 519 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 520 Protocol Method for 3rd Generation Authentication and Key 521 Agreement (EAP-AKA)", RFC 4187, January 2006. 523 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 524 IKEv2 and the Revised IPsec Architecture", RFC 4877, 525 April 2007. 527 13.2. Informative references 529 [I-D.liu-mext-distributed-mobile-ip] 530 Liu, D., "Distributed Deployment of Mobile IPv6", 531 draft-liu-mext-distributed-mobile-ip-00 (work in 532 progress), March 2011. 534 [I-D.yokota-dmm-scenario] 535 Yokota, H., Seite, P., Demaria, E., and Z. Cao, "Use case 536 scenarios for Distributed Mobility Management", 537 draft-yokota-dmm-scenario-00 (work in progress), 538 October 2010. 540 [I-D.perkins-mext-hatunaddr] 541 Perkins, C., "Alternate Tunnel Source Address for Home 542 Agent", draft-perkins-mext-hatunaddr-02 (work in 543 progress), October 2011. 545 Author's Address 547 Behcet Sarikaya 548 Huawei USA 549 5340 Legacy Dr. Building 175 550 Plano, TX 75074 552 Phone: +1 469 277 5839 553 Email: sarikaya@ieee.org