idnits 2.17.1 draft-sarikaya-mif-dhcpv6solution-04.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 (July 1, 2010) is 5019 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 411, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 414, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mext-flow-binding' is defined on line 431, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-15) exists of draft-ietf-mif-problem-statement-04 ** Downref: Normative reference to an Informational draft: draft-ietf-mif-problem-statement (ref. 'I-D.ietf-mif-problem-statement') == Outdated reference: A later version (-11) exists of draft-ietf-mext-flow-binding-06 == Outdated reference: A later version (-05) exists of draft-ietf-mext-binary-ts-04 -- Obsolete informational reference (is this intentional?): RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Sarikaya 3 Internet-Draft F. Xia 4 Intended status: Standards Track Huawei USA 5 Expires: January 2, 2011 P. Seite 6 France Telecom 7 July 1, 2010 9 DHCPv6 Extension for Configuring Hosts with Multiple Interfaces 10 draft-sarikaya-mif-dhcpv6solution-04.txt 12 Abstract 14 This document defines DHCPv6 Options to configure a multi-homed 15 host's routing table with new entries when the host attaches to a new 16 network on a new interface. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 2, 2011. 35 Copyright Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Configuring Routing Tables of Multi-homed Hosts . . . . . . . 3 55 4. DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 4 57 4.2. Flow Description Sub-option . . . . . . . . . . . . . . . 6 58 4.3. QoS Info Sub-option . . . . . . . . . . . . . . . . . . . 6 59 4.4. Flow Route Prefix Sub-option . . . . . . . . . . . . . . . 7 60 4.5. IPv6 Router Address Sub-option . . . . . . . . . . . . . . 8 61 4.6. Interface Info Sub-option . . . . . . . . . . . . . . . . 9 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 67 8.2. Informative references . . . . . . . . . . . . . . . . . . 11 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 70 1. Introduction 72 Traditional routing considered only the destination address in 73 IPv4/v6 header. Policy-based routing on the hand considers other 74 fields in the header sometimes even the payload. In IPv6, the hosts 75 receive router advertisements (RA) containing information useful for 76 enforcing policy-based routing. However in some networks, e.g. 77 cellular networks, DHCP servers can be used to help multi-homed 78 mobile nodes configure their routing tables. 80 Using a single default route would lead to routing of all flows 81 through a single interface. Such a configuration makes it impossible 82 to use multiple interfaces simultaneously if the host is multi-homed. 84 Requirements of supporting multiple interfaces in hosts without 85 involving mobility protocols are discussed in 86 [I-D.ietf-mif-problem-statement], [I-D.yang-mif-req]. DHCP is 87 identified as a protocol to communicate interface management policies 88 between MIF nodes and the network. 90 The IPv6 hosts receive router advertisements and then populate their 91 Default Router List and Prefix List based on information in the 92 router advertisements [RFC2461]. [RFC4191] extended RAs with Route 93 Information Option and added Default Router Preference. Such RAs if 94 available would help multi-homed mobile nodes configure better to 95 enable the simultaneous use of all interfaces. 97 In this document we define a new DHCPv6 [RFC3315] Option. This 98 option is to inform multi-homed hosts about the routes and other 99 useful information available on the new network that the host has 100 just connected. It is appropriate to use DHCP for this purpose 101 because DHCP is already needed for initial configuration of the 102 host's interface, e.g. for address assignment. 104 2. Terminology 106 This document uses the terminology defined in [RFC3315] and 107 [RFC3633]. 109 3. Configuring Routing Tables of Multi-homed Hosts 111 An IPv6 routing table contains these entries (non exhaustive list): 112 prefix, prefix length, preference value, lifetime, and the address of 113 the next-hop router. 115 Multi-homed hosts receive configuration information on each 116 interface. Routers send router advertisements. DHCP servers provide 117 host configuration information. SDOs are defining servers such as 118 Access Network Discovery and Selection Function (ANDSF) [3GPP23402]. 119 ANDSF can also provide node configuration information on SDO 120 interfaces. Configuration information helps host set up and update 121 important databases that the host uses such as the routing table. 123 Since IPv6 allows multiple unicast addresses to be assigned to 124 interfaces, IPv6 hosts face the problem of default source and 125 destination address selection when initiating communication. 126 [RFC3484] defines algorithms for this purpose. 128 In this document we define a new DHCPv6 Option called multi-homed 129 routing policy entry option. Using this Option DHCPv6 server can 130 inform DHCPv6 client on the default routes available on the interface 131 which the host is about to connect. The option also allows DHCP 132 server to provide more information on the flows such as more 133 sophisticated flow description. The host receives the route 134 information ordered with priority which allows the host to select the 135 right interface to start communication. 137 DHCP server gets information about host's interface using Interface 138 Info Sub-option included in the multi-homed routing policy entry 139 option. A MIF host MAY include one Interface Info Sub-option for 140 each of its interfaces. A MIF host requesting routing information 141 MAY set preferred-lifetime to a value in multi-homed routing policy 142 entry option. DHCP server considers preferred-lifetime value it 143 received and it sets valid-lifetime value in the reply. Valid- 144 lifetime value defines the expiration value of the routing policy 145 entry. 147 Policy entries are identified using Policy Identifiers (PID). Each 148 option MUST have a unique PID. 150 4. DHCPv6 Option 152 4.1. Option Format 154 A new option is defined to carry the host routing information. It is 155 shown in Figure 1. 157 DHCP server MAY send a Reply message containing multi-homed routing 158 policy entry option. DHCP client MUST add an entry to its routing 159 table based on this option. DHCP client MAY modify other tables such 160 as Default Router List or Pref List [RFC4191]. 162 DHCP Client MAY include multi-homed routing policy entry option in 163 Option Request Option [RFC3315] in DHCP Request message. DHCP Server 164 MUST include multi-homed routing policy entry option in the 165 corresponding Reply message. The option contains a list of routing 166 policies, each of them containing the flow description followed by 167 the route to apply when datagram to forward is matching. 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | OPTION_MHRPE | option-length | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | sub-option-code | sub-option-len | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | sub-option-content | 176 . . 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | ... | 179 . . 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | ... | 182 . . 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | PID | Reserved | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | preferred-lifetime | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | valid-lifetime | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 Figure 1: DHCPv6 Multi-Homed Routing Policy Option 193 o Option-code: OPTION_MHRPE multi-homed routing policy entry option 194 (To be assigned by IANA) 195 o Option-length: Total length of the sub-options + 4. 196 o sub-option-code: the code of the included sub option. In this 197 document SUB_OPTION_FLOW_DESC, SUB_OPTION_QOS_INFO, 198 SUB_OPTION_PREFIX and SUB_OPTION_ROUTER_ADDRESS are defined. 199 o sub-option-len: length of the sub-option. 200 o sub-option-content: content of the sub-option. 201 o PID: The Policy Identifier field is an 8-bit unsigned integer that 202 includes the identifier for the policy. 203 o Reserved: 24 bits set to zero by the sender ignored by the 204 receiver 205 o preferred-lifetime: The preferred lifetime in units of seconds for 206 the multi-homed routing policy entry option. 208 o valid lifetime: The valid lifetime in units of seconds for the 209 multi-homed routing policy entry option. 211 4.2. Flow Description Sub-option 213 Flow Description Sub-option is used to describe the flow for this 214 route. More than one flow description MAY be included. Flow 215 descriptions are usually in binary format but textual formats are 216 also allowed. The preferred interface for this flow is included in 217 Interface Info Sub-option. 219 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 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | SUB_OPTION_FLOW_DESC | sub-option-len | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | FD-Type | FD-len | | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 225 | Flow Description ... | 226 . . 227 | | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Figure 2: Flow Description Sub-option 232 o option-code: SUB_OPTION_FLOW_DESC (to be assigned by IANA) 233 o option-length: Variable. 234 o FD-Type: type of the flow description: 235 o 236 o (0) Reserved 237 o (1) Binary 238 o (2) Text 239 o FD-len: length of the flow description that follows in bytes. 240 o Flow Description: This field contains flow description in binary 241 such as in [I-D.ietf-mext-binary-ts] or in textual format. This 242 field is of length FD-length. 244 4.3. QoS Info Sub-option 246 This Sub-option contains quality of service information associated 247 with each interface as specified in Interface Info Sub-option, e.g. 248 on 3G 150kbps for video on WiFi 400kbps for video. 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | SUB_OPTION_QOS_INFO | sub-option-len | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 |QoS Information Code |QoS Information Sub-Code | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 |QoS Information value | 257 + + 258 | | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 Figure 3: QoS Sub-option 263 o option-code: SUB_OPTION_QOS_INFO (to be assigned by IANA) 264 o option-length: Variable. 265 o QoS information Code: this field identifies the type of the QoS 266 information: 267 o 268 o (0) Reserved 269 o (1) Packet rate 270 o (2) One-way delay metric 271 o (3) Inter-packet delay variation 272 o QoS information Sub-code: this field carries the sub-type of the 273 QoS information. The following sub-types have been identified: 274 o 275 o (0) None 276 o (1) Reserved rate 277 o (2) Available rate 278 o (3) Loss rate 279 o (4) Minimum one-way delay 280 o (5) Maximum one-way delay 281 o (6) Average one-way delay 282 o QoS information value: this field indicates the value of the QoS 283 information. The corresponding units depend on the instantiation 284 of the QoS information code. 286 4.4. Flow Route Prefix Sub-option 288 This Sub-option defines IPv6 prefix over which the flow as defined in 289 flow description sub-option will be routed. One flow route prefix 290 sub-option MAY be included for each flow description sub-option. 292 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 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | SUB_OPTION_FR_PREFIX | sub-option-len | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | prefix-len | | 297 +-+-+-+-+-+-+-+-+ IPv6 prefix | 298 | (variable) | 299 | | 300 ~ ~ 301 | | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Figure 4: Flow Route Prefix Sub-option 306 o option-code: SUB_OPTION_FR_PREFIX (to be assigned by IANA) 307 o option-length: Variable. 308 o prefix-len: Prefix length of the destination prefix over which the 309 flow will be routed 310 o IPv6 prefix: Destination prefix over which the flow will be 311 routed. The first prefix-len bits make up the prefix. The rest 312 is ignored. 314 4.5. IPv6 Router Address Sub-option 316 This sub-option defines the default router address for this route. 317 Flow Route Prefix Sub-option and IPv6 Router Address Sub-option 318 define a route. 320 For each flow there MUST be at least one route. If more than one 321 route is defined the first route is the primary route. 323 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 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | SUB_OPTION_ROUTER_ADDRESS | sub-option-len | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | IPv6 Router Address (16 octets) | 328 | | 329 | | 330 | | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | prefix-length | Reserved | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 Figure 5: IPv6 Router Address Sub-option 337 o option-code: SUB_OPTION_ROUTER_ADDRESS (to be assigned by IANA) 338 o option-length: 24. 339 o IPv6 Router Address: Default router address for this route. This 340 field is 16 octets. 341 o Prefix-length: Length of the prefix of IPv6 router address field. 342 It is 8 bits. 343 o Reserved: 24 bits set to zero by the sender ignored by the 344 receiver 346 4.6. Interface Info Sub-option 348 Interface Info Sub-option is used to provide information about each 349 interface of the host. One such sub-option SHOULD be included for 350 each interface of a MIF host. 352 Link layer address is a MAC address for IEEE interfaces such as 353 Ethernet or Wi-Fi. Link layer address could be International Mobile 354 Subscriber Identity (IMSI) for some 3G or 4G interfaces. 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 | SUB_OPTION_INTERFACE_INFO | sub-option-len | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | ATT | Length | | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 362 | Link Layer Address | 363 + + 364 | | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 Figure 6: Interface Info Sub-option 369 o option-code: SUB_OPTION_INTERFACE_INFO (to be assigned by IANA) 370 o option-length: 16. 371 o ATT: This is an 8-bit field that specifies the access technology 372 of the interface. The values for this field are assigned from 373 Access Technology Type Option type values of IANA related to 374 [RFC5213]. 375 o Length: The length in bytes of Link Layer address 376 o The variable length link-layer address. MAC address (if exists) 377 is placed as value in this field. 379 5. Security Considerations 381 This document does not by itself introduce any security issues. 383 6. IANA Considerations 385 IANA is requested to assign an option code to the following options 386 from the option-code space defined in "DHCPv6 Options" section of the 387 DHCPv6 specification [RFC3315]. 389 +---------------------------+-------+--------------+ 390 | Option Name | Value | Described in | 391 +---------------------------+-------+--------------+ 392 | OPTION_MHPTE | TBD | Section 4.1 | 393 | SUB_OPTION_FLOW_DESC | TBD | Section 4.2 | 394 | SUB_OPTION_QOS_INFO | TBD | Section 4.3 | 395 | SUB_OPTION_FR_PREFIX | TBD | Section 4.4 | 396 | SUB_OPTION_ROUTER_ADDRESS | TBD | Section 4.5 | 397 | SUB_OPTION_INTERFACE_INFO | TBD | Section 4.6 | 398 +---------------------------+-------+--------------+ 400 Table 1: DHCPv6 Options 402 7. Acknowledgements 404 The authors acknowledge Mohamed Boucadair who provided useful 405 comments for this document. 407 8. References 409 8.1. Normative References 411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 412 Requirement Levels", BCP 14, RFC 2119, March 1997. 414 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 415 June 1999. 417 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 418 and M. Carney, "Dynamic Host Configuration Protocol for 419 IPv6 (DHCPv6)", RFC 3315, July 2003. 421 [I-D.ietf-mif-problem-statement] 422 Blanchet, M. and P. Seite, "Multiple Interfaces Problem 423 Statement", draft-ietf-mif-problem-statement-04 (work in 424 progress), May 2010. 426 [I-D.yang-mif-req] 427 Yang, P., Seite, P., Williams, C., and J. Qin, 428 "Requirements on multiple Interface (MIF) of simple IP", 429 draft-yang-mif-req-00 (work in progress), March 2009. 431 [I-D.ietf-mext-flow-binding] 432 Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G., 433 and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and NEMO 434 Basic Support", draft-ietf-mext-flow-binding-06 (work in 435 progress), March 2010. 437 [I-D.ietf-mext-binary-ts] 438 Tsirtsis, G., Giaretta, G., Soliman, H., and N. Montavont, 439 "Traffic Selectors for Flow Bindings", 440 draft-ietf-mext-binary-ts-04 (work in progress), 441 February 2010. 443 8.2. Informative references 445 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 446 Host Configuration Protocol (DHCP) version 6", RFC 3633, 447 December 2003. 449 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 450 More-Specific Routes", RFC 4191, November 2005. 452 [RFC3484] Draves, R., "Default Address Selection for Internet 453 Protocol version 6 (IPv6)", RFC 3484, February 2003. 455 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 456 Discovery for IP Version 6 (IPv6)", RFC 2461, 457 December 1998. 459 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 460 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 462 [3GPP23402] 463 "3GPP TS 23.402. Architecture enhancements for non-3GPP 464 accesses.", June 2009. 466 Authors' Addresses 468 Behcet Sarikaya 469 Huawei USA 470 1700 Alma Dr. Suite 500 471 Plano, TX 75075 473 Phone: +1 972-509-5599 474 Email: sarikaya@ieee.org 476 Frank Xia 477 Huawei USA 478 1700 Alma Dr. Suite 500 479 Plano, TX 75075 481 Phone: +1 972-509-5599 482 Email: xiayangsong@huawei.com 484 Pierrick Seite 485 France Telecom 486 4, rue du Clos Courtel 487 BP 91226 488 Cesson-Sevigne, 35512 489 France 491 Email: pierrick.seite@orange-ftgroup.com