idnits 2.17.1 draft-ietf-mif-problem-statement-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 26, 2009) is 5267 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-behave-dns64-01 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 4294 (Obsoleted by RFC 6434) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Blanchet Ed. 3 Internet-Draft Viagenie 4 Intended status: Informational P. Seite 5 Expires: April 29, 2010 France Telecom 6 October 26, 2009 8 Multiple Interfaces Problem Statement 9 draft-ietf-mif-problem-statement-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 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 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on April 29, 2010. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 A multihomed host receives node configuration information from each 58 of its provisioning domain. Some configuration objects are global to 59 the node, some are local to the interface. Various issues arise when 60 multiple conflicting node-scoped configuration objects are received 61 on multiple interfaces. Similar situations also happen with single 62 interface host connected to multiple networks. This document 63 describes these issues. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Scope and Existing Work . . . . . . . . . . . . . . . . . . . 4 70 3.1. Below IP Interaction . . . . . . . . . . . . . . . . . . . 4 71 3.2. Hosts Requirements . . . . . . . . . . . . . . . . . . . . 4 72 3.3. Mobility and other IP protocols . . . . . . . . . . . . . 5 73 3.4. Address Selection . . . . . . . . . . . . . . . . . . . . 5 74 3.5. Interactive Connectivity Establishment (ICE) . . . . . . . 5 75 3.6. Socket API . . . . . . . . . . . . . . . . . . . . . . . . 6 76 3.7. Above IP Layers . . . . . . . . . . . . . . . . . . . . . 6 77 4. Symptoms . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 4.1. DNS resolution issues . . . . . . . . . . . . . . . . . . 6 79 4.2. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 4.3. Address Selection Policy . . . . . . . . . . . . . . . . . 8 81 4.4. Single Interface on Multiple Networks . . . . . . . . . . 9 82 5. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 86 9. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 88 11. Discussion home for this draft . . . . . . . . . . . . . . . . 10 89 12. Informative References . . . . . . . . . . . . . . . . . . . . 10 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 92 1. Introduction 94 A multihomed host have multiple provisioning domains (via physical 95 and/or virtual interfaces). For example, a node may be 96 simultaneously connected to a wired Ethernet LAN, a 802.11 LAN, a 3G 97 cell network, one or multiple VPN connections or one or multiple 98 automatic or manual tunnels. Current laptops and smartphones 99 typically have multiple access network interfaces and, thus, may be 100 simultaneously connected to different provisioning domains. 102 A multihomed host receives node configuration information from each 103 of its access networks, through various mechanims such as DHCPv4 104 [RFC2131], DHCPv6 [RFC3315], PPP [RFC1661] and IPv6 Router 105 Advertisements [RFC4861]. Some received configuration objects are 106 specific to an interface such as the IP address and the link prefix. 107 Others are typically considered by implementations as being global to 108 the node, such as the routing information (e.g. default gateway), DNS 109 servers IP addresses and address selection policies. 111 When the received node-scoped configuration objects have different 112 values from each provisioning domains, such as different DNS servers 113 IP addresses, different default gateways or different address 114 selection policies, the node has to decide which it will use or how 115 it will merge them. 117 Several issues regarding how the node-scoped configuration objects 118 are used in a multihomed node environment have been raised. The 119 following sections define the MIF host and the scope of this 120 document, describe related work, list the symptoms and then the 121 underlying problems. 123 A companion document [I-D.mrw-mif-current-practices] discusses 124 current practices. 126 2. Terminology 128 A MIF host is defined as: 129 o A [RFC1122] IPv4 and/or [RFC4294] IPv6 compliant host 130 o Configured with more than one IP addresses (excluding loopback, 131 link-local) 132 o On one or more provisioning domains, as presented to the IP stack. 133 o The interfaces may be logical, virtual or physical. 134 o The IP addresses come from more than one administrative domains. 135 o The IP addresses may be from the same or from different address 136 families, such as IPv4 and IPv6. 138 o Communications using these IP addresses may happen simultaneously 139 and independently. 140 o Communications using these IP addresses may be tied on all the 141 possible provisioning domains, or, at least, on a limited number 142 of provisioning domains. 143 o While the MIF host may forward packets between its interfaces, 144 forwarding packets is not taken into account in this definition. 146 When a protocol keyword such as IP, PPP, DHCP is used without any 147 reference to a specific IP version, then it implies both IPv4 and 148 IPv6. A specific IP version keyword such as DHCPv4 or DHCPv6 is 149 specific to that IP version. 151 3. Scope and Existing Work 153 This section describes existing related work and defines the scope of 154 the problem. 156 3.1. Below IP Interaction 158 Network discovery and selection on lower layers as defined by 159 [RFC5113] is out of scope of this document. Moreover, lower layer 160 interaction such as IEEE 802.21 is also out of scope. 162 Proxy MIP allows sharing a single IP address across multiple interfac 163 es (e.g., WiMAX and CDMA, LTE and HSPA, etc) to disparate networks. 164 From the IP stack view on the node, there is only a single interface 165 and single IP address. Therefore, this situation is out of scope. 166 Furthermore, link aggregation done under IP where a single interace 167 is shown to the IP stack is also out of scope. 169 3.2. Hosts Requirements 171 The requirements for Internet Hosts [RFC1122] describe the multihomed 172 host as if it has multiple IP addresses, which may be associated with 173 one or more physical interfaces connected to the same or different 174 networks. 176 The host maintains a route cache table where each entry contains the 177 local IP address, the destination IP address, Type-of-Service and 178 Next-hop gateway IP address. The route cache entry would have data 179 about the properties of the path, such as the average round-trip 180 delay measured by a transport protocol. 182 As per [RFC1122], two models are defined: 184 o The "Strong" host model defines a multihomed host as a set of 185 logical hosts within the same physical host. In this model a 186 packet must be sent on an interface that corresponds to the source 187 address of that packet. 188 o The "Weak" host model describes a host that has some embedded 189 gateway functionality. In the weak host model, the host can send 190 and receive packets on any interface. 192 The multihomed host computes routes for outgoing datagrams 193 differently depending on the model. Under the strong model, the 194 route is computed based on the source IP address, the destination IP 195 address and the Type-of-Service. Under the weak model, the source IP 196 address is not used, but only the destination IP address and the 197 Type-of-Service. 199 3.3. Mobility and other IP protocols 201 This document assumes hosts only implementing [RFC1122] for IPv4 and 202 [RFC4294] for IPv6, and not using any kind of new transport 203 protocols. It is not required for the host to support additional IP 204 mobility or multihoming protocols, such as SHIM6, SCTP, Mobile IP, 205 HIP, RRG, LISP or else. Moreover, the peer of the connection is also 206 not required to use these mechanisms. 208 3.4. Address Selection 210 The Default Address Selection [RFC3484] defines algorithms for source 211 and destination IP address selections. It is mandatory to be 212 implemented in IPv6 nodes, which also means dual-stack nodes. A 213 node-scoped policy table managed by the IP stack is defined. 214 Provisions are made to change or update the policy table, however, no 215 mechanism is defined. 217 Issues on using the Default Address Selection were found [RFC5112] in 218 the context of multiple prefixes on the same link. New work 219 [I-D.chown-addr-select-considerations] discusses the multiple 220 attached networks scenarios and how to update the policy table. 222 3.5. Interactive Connectivity Establishment (ICE) 224 Interactive Connectivity Establishment (ICE [I-D.ietf-mmusic-ice]) is 225 a technique for NAT traversal for UDP-based (and TCP) media streams 226 established by the offer/answer model. The multiplicity of IP 227 addresses and ports in SDP offers are tested for connectivity by 228 peer-to-peer connectivity checks. The result is candidate IP 229 addresses and ports for establishing a connection with the other 230 peer. 232 ICE does not solve the MIF issues, such as the incompatible 233 configuration objects received on different interfaces. However, ICE 234 may be of use for address selection if the application is ICE- 235 enabled. 237 3.6. Socket API 239 Application Programming Interface (API) may expose objects that user 240 applications may use for the MIF purpose. For example, [RFC3542] 241 shows how an application using the Advanced sockets API can specify 242 the interface or the source IP address, through simple bind() 243 operation or IPV6_PKTINFO socket option. 245 An API is also defined [RFC5014] to influence the default address 246 selection mechanism by specifying attributes of the source addresses 247 it prefers. 249 3.7. Above IP Layers 251 The MIF issues discussed in this document assume no changes in 252 transport protocols or applications. However, fixing the issues 253 might involve these layers. 255 4. Symptoms 257 This section describes the various symptoms found using a MIF host 258 that has already received configuration objects from its various 259 provisioning domains. 261 These situations are also described in 262 [I-D.savolainen-6man-fqdn-based-if-selection], [I-D.yang-mif-req] and 263 [RFC4477]. They occur, for example, when: 264 1. one interface is on the Internet and one is on a corporate 265 private network. The latter may be through VPN. 266 2. one interface is on one access network (i.e. wifi) and the other 267 one is on another access network (3G) with specific services. 269 4.1. DNS resolution issues 271 A MIF host (H1) has an active interface(I1) connected to a network 272 (N1) which has its DNS server (S1) and another active interface (I2) 273 connected to a network (N2) which has its DNS server (S2). S1 serves 274 with some private namespace "private.example.com". The user or the 275 application uses a name "a.private.example.com" which is within the 276 private namespace of S1 and only resolvable by S1. Any of the 277 following situations may occur: 279 1. H1 stack, based on its routing table, uses I2 to reach S1 to 280 resolve "a.private.example.com". H1 never reaches S1. The name 281 is not resolved. 282 2. H1 keeps only one set of DNS server addresses from the received 283 configuration objects and kept S2 address. H1 sends the DNS A 284 query for a.private.example.com to S2. S2 responds with an error 285 for an non-existant domain (NXDOMAIN). The name is not resolved. 286 3. H1 keeps only one set of DNS server addresses from the received 287 configuration objects and kept S2 address. H1 sends the DNS A 288 query for a.private.example.com to S2. S2 asks its upstream DNS 289 and gets an IP address for a.private.example.com. However, the 290 IP address is not the right one S1 would have given. Therefore, 291 the application tries to connect to the wrong destination host, 292 which may imply security issues. 293 4. S1 or S2 has been used to resolve "a.private.example.com" to an 294 [RFC1918] address. Both N1 and N2 are [RFC1918] addressed 295 networks. IPv4 source address selection may face challenges, as 296 due address overlapping the source/destination IP addresses do 297 not necessarily provide enough information for making proper 298 address selection decisions. 299 5. H1 has resolved an FQDN to locally valid IP address when 300 connected to N1. After movement from N1 to N2, the host tries to 301 connect to the same IP address as earlier, but as the address was 302 only locally valid, connection setup fails. 303 6. H1 requests AAAA record from a DNS server on a network that uses 304 protocol translators and DNS64 [I-D.ietf-behave-dns64]. If the 305 H1 receives synthesized AAAA record, it is quaranteed to be valid 306 only on the network it was learned from. If the H1 uses 307 synthesized AAAA on an network interface it is not valid on, the 308 packets will be dropped by the network. 310 4.2. Routing 312 A MIF host (H1) has an active interface(I1) connected to a network 313 (N1) and another active interface (I2) connected to a network (N2). 314 The user or the application is trying to reach an IP address (IP1). 315 Any of the following situations may occur: 316 1. For the IP1 address family, H1 has one default route (R1, R2) per 317 network (N1, N2). IP1 is only reachable by N2. H1 stack uses R1 318 and tries to send through I1. IP1 is never reached or is not the 319 right target. 320 2. For the IP1 address family, H1 has one default route (R1, R2) per 321 network (N1, N2). IP1 is reachable by both networks, but N2 path 322 has better characterictics, such as better round-trip time, least 323 cost, better bandwidth, etc.... These preferences could be 324 defined by user, by the provider, by discovery or else. H1 stack 325 uses R1 and tries to send through I1. IP1 is reached but the 326 service would be better by I2. 328 3. For the IP1 address family, H1 has a default route (R1), a 329 specific X.0.0.0/8 route R1B (eg. RFC1918 prefix) to N1 and a 330 default route (R2) to N2. IP1 is reachable by N2 only, but the 331 prefix (X.0.0.0/8) is used in both networks. Because of the most 332 specific route R1B, H1 stack sends through I2 and never reach the 333 target. 335 A MIF host may have multiple routes to a destination. However, by 336 default, it does not have any hint concerning which interface would 337 be the best to use for that destination. For example, as discussed 338 in [I-D.savolainen-6man-fqdn-based-if-selection], 339 [I-D.hui-ip-multiple-connections-ps] and [I-D.yang-mif-req], a 340 service provider might want to influence the routing table of the 341 host connecting to its network. 343 A host usually has a node-scoped routing table. Therefore, when a 344 MIF host is connected to multiple provisioning domains where each 345 service provider wants to influence the routing table of the host, 346 then conflicts might arise from the multiple routing information 347 being pushed to the host. 349 A user on such multihomed host might want a local policy to influence 350 which interface will be used based on various conditions. 352 On a MIF host, some source addresses are not valid if used on some 353 interfaces. For example, an RFC1918 source address might be 354 appropriate on the VPN interface but not on the public interface of 355 the MIF host. If the source address is not chosen appropriately, 356 then sent packets might be filtered in the path if source address 357 filtering is in place ([RFC2827],[RFC3704]) and reply packets might 358 never come back to the source. 360 4.3. Address Selection Policy 362 A MIF host (H1) has an active interface(I1) connected to a network 363 (N1) and another active interface (I2) connected to a network (N2). 364 The user or the application is trying to reach an IP address (IP1). 365 Any of the following situations may occur: 366 1. H1 receives from both networks (N1 and N2) an update of its 367 default address selection policy. However, the policies are 368 specific to each network. The policies are merged by H1 stack. 369 Based on the merged policy, the chosen source address is from N1 370 but packets are sent to N2. The source address is not reachable 371 from N2, therefore the return packet is lost. 372 2. TBD: add more 374 Merging address selection policies may have important impacts on 375 routing. 377 4.4. Single Interface on Multiple Networks 379 When a MIF host using a single interface is connected to multiple 380 networks with different default routers, similar issues as described 381 above happen. 383 5. Problems 385 This section tries to list the underlying problems corresponding to 386 the issues discussed in the previous section. 387 1. Routing tables are usually node-scoped. 388 2. DNS server addresses and other configuration objects (NTP 389 servers, ...) are usually node-scoped. 390 3. Same configuration objects (eg DNS server addresses, NTP server 391 addresses, ..) received from multiple provisioning domains are 392 usually overwritten. 393 4. Default Address Selection policies are usually node-scoped. 394 5. Default Address Selection policies may differ when received on 395 different provisioning domains. 396 6. Host implementations usually do not implement the [RFC1122] 397 strong model where the source address is in the routing table. 398 7. Host implementations usually do not implement the [RFC1122] 399 model where the Type-of-Service are in the routing table. 400 8. Host implementations usually do not keep path characteristics, 401 user or provider preferences in the routing table. 402 9. Applications usually do not use advanced APIs to specify the 403 source IP address or to set preferences on the address selection 404 policies. 405 10. DNS answers are usually not kept with the interface from which 406 the answer comes from. 407 11. Host implementations usually do not keep separate network 408 configuration (such as DNS server addresses) per provisioning 409 domain. 411 6. Summary 413 A MIF host receives node configuration information from each of its 414 provisioning domains. Some configuration objects are global to the 415 node, some are local to the interface. Various issues arise when 416 multiple conflicting node-scoped configuration objects are received 417 via multiple provisioning domains. Similar situations also happen 418 with single interface host connected to multiple networks. 419 Therefore, there is a need to define the appropriate behavior of an 420 IP stack and possibly define protocols to manage these cases. 422 7. Security Considerations 424 The problems discussed in this document have security implications, 425 such as when the packets sent on the wrong interface might be leaking 426 some confidential information. Moreover, the undetermined behavior 427 of IP stacks in the multihomed context bring additional threats where 428 an interface on a multihomed host might be used to conduct attacks 429 targeted to the networks connected by the other interfaces. 431 8. IANA Considerations 433 This document has no actions for IANA. 435 9. Authors 437 This document is a joint effort with authors of the MIF requirements 438 draft [I-D.yang-mif-req]. The authors of this document, in 439 alphabetical order, include: Marc Blanchet, Jacqni Qin, Pierrick 440 Seite, Carl Williams and Peny Yang. 442 10. Acknowledgements 444 The initial Internet-Drafts prior to the MIF working group and the 445 discussions during the MIF BOF meeting and on the mailing list around 446 the MIF charter scope on the mailing list brought very good input to 447 the problem statement. This draft steals a lot of text from these 448 discussions and the initial drafts. Therefore, the editor would like 449 to acknowledge the following people (in no specific order), from 450 which some text has been taken from: Jari Arkko, Keith Moore, Sam 451 Hartman, George Tsirtsis, Scott Brim, Ted Lemon, Bernie Volz, Giyeong 452 Son, Gabriel Montenegro, Teemu Savolainen, Christian Vogt, Lars 453 Eggert, Margaret Wasserman, Hui Deng, Ralph Droms, Ted Hardie, 454 Christian Huitema, Remi Denis-Courmont. Sorry if some contributors 455 have not been named. 457 11. Discussion home for this draft 459 This document is intended to define the problem space discussed in 460 the mif@ietf.org mailing list. 462 12. Informative References 464 [I-D.chown-addr-select-considerations] 465 Chown, T., "Considerations for IPv6 Address Selection 466 Policy Changes", draft-chown-addr-select-considerations-03 467 (work in progress), July 2009. 469 [I-D.hui-ip-multiple-connections-ps] 470 Hui, M. and H. Deng, "Problem Statement and Requirement of 471 Simple IP Multi-homing of the Host", 472 draft-hui-ip-multiple-connections-ps-02 (work in 473 progress), March 2009. 475 [I-D.ietf-behave-dns64] 476 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 477 "DNS64: DNS extensions for Network Address Translation 478 from IPv6 Clients to IPv4 Servers", 479 draft-ietf-behave-dns64-01 (work in progress), 480 October 2009. 482 [I-D.ietf-mmusic-ice] 483 Rosenberg, J., "Interactive Connectivity Establishment 484 (ICE): A Protocol for Network Address Translator (NAT) 485 Traversal for Offer/Answer Protocols", 486 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 488 [I-D.mrw-mif-current-practices] 489 Wasserman, M., "Current Practices for Multiple Interface 490 Hosts", draft-mrw-mif-current-practices-02 (work in 491 progress), March 2009. 493 [I-D.savolainen-6man-fqdn-based-if-selection] 494 Savolainen, T., "Domain name based network interface 495 selection", 496 draft-savolainen-6man-fqdn-based-if-selection-00 (work in 497 progress), October 2008. 499 [I-D.yang-mif-req] 500 Yang, P., Seite, P., Williams, C., and J. Qin, 501 "Requirements on multiple Interface (MIF) of simple IP", 502 draft-yang-mif-req-00 (work in progress), March 2009. 504 [RFC1122] Braden, R., "Requirements for Internet Hosts - 505 Communication Layers", STD 3, RFC 1122, October 1989. 507 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 508 RFC 1661, July 1994. 510 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 511 E. Lear, "Address Allocation for Private Internets", 512 BCP 5, RFC 1918, February 1996. 514 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 515 RFC 2131, March 1997. 517 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 518 Defeating Denial of Service Attacks which employ IP Source 519 Address Spoofing", BCP 38, RFC 2827, May 2000. 521 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 522 and M. Carney, "Dynamic Host Configuration Protocol for 523 IPv6 (DHCPv6)", RFC 3315, July 2003. 525 [RFC3484] Draves, R., "Default Address Selection for Internet 526 Protocol version 6 (IPv6)", RFC 3484, February 2003. 528 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 529 "Advanced Sockets Application Program Interface (API) for 530 IPv6", RFC 3542, May 2003. 532 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 533 Networks", BCP 84, RFC 3704, March 2004. 535 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 536 April 2006. 538 [RFC4477] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host 539 Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack 540 Issues", RFC 4477, May 2006. 542 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 543 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 544 September 2007. 546 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 547 Socket API for Source Address Selection", RFC 5014, 548 September 2007. 550 [RFC5112] Garcia-Martin, M., "The Presence-Specific Static 551 Dictionary for Signaling Compression (Sigcomp)", RFC 5112, 552 January 2008. 554 [RFC5113] Arkko, J., Aboba, B., Korhonen, J., and F. Bari, "Network 555 Discovery and Selection Problem", RFC 5113, January 2008. 557 Authors' Addresses 559 Marc Blanchet 560 Viagenie 561 2600 boul. Laurier, suite 625 562 Quebec, QC G1V 4W1 563 Canada 565 Email: Marc.Blanchet@viagenie.ca 566 URI: http://www.viagenie.ca 568 Pierrick Seite 569 France Telecom 570 4, rue du Clos Courtel, BP 91226 571 Cesson-Sevigne 35512 572 France 574 Email: pierrick.seite@orange-ftgroup.com