idnits 2.17.00 (12 Aug 2021) /tmp/idnits60738/draft-bagnulo-shim6-ingress-filtering-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 550. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 557. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 563. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 17, 2006) is 5816 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) ** Obsolete normative reference: RFC 2460 (ref. '1') (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 3582 (ref. '2') ** Obsolete normative reference: RFC 2267 (ref. '3') (Obsoleted by RFC 2827) ** Obsolete normative reference: RFC 3513 (ref. '4') (Obsoleted by RFC 4291) ** Downref: Normative reference to an Informational RFC: RFC 3493 (ref. '5') Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Huitema 3 Internet-Draft Microsoft 4 Expires: December 19, 2006 M. Bagnulo 5 UC3M 6 June 17, 2006 8 Ingress filtering compatibility for IPv6 multihomed sites 9 draft-bagnulo-shim6-ingress-filtering-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 19, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 The note presents a set of mechanisms to provide ingress filtering 43 compatibility for legacy hosts in IPv6 multihomed sites. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Reference topology . . . . . . . . . . . . . . . . . . . . . . 4 49 3. The problem: Ingress filtering incompatibility . . . . . . . . 5 50 4. Goals and non goals of the presented solution . . . . . . . . 6 51 4.1. Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 52 4.2. Non-goals . . . . . . . . . . . . . . . . . . . . . . . . 6 53 5. Proposed solution . . . . . . . . . . . . . . . . . . . . . . 7 54 5.1. Relaxing the ingress filtering . . . . . . . . . . . . . . 7 55 5.2. Source Address Dependent (SAD) routing . . . . . . . . . . 8 56 5.2.1. Single site exit router . . . . . . . . . . . . . . . 8 57 5.2.2. DMZ . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 5.2.3. General case . . . . . . . . . . . . . . . . . . . . . 10 59 6. Appendix A: Host based optimization . . . . . . . . . . . . . 12 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 61 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 62 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 64 Intellectual Property and Copyright Statements . . . . . . . . . . 17 66 1. Introduction 68 A way to solve the issue of site multihoming is to have a separate 69 site prefix for each connection of the site, and to derive as many 70 addresses for each hosts. This approach to multi-homing has the 71 advantage of minimal impact on the inter-domain routing fabric, since 72 each site prefix can be aggregated within the larger prefix of a 73 specific provider; however, it opens a number of issues, that have to 74 be addressed in order to provide a multihoming solution compatible 75 with such addressing scheme. 77 In this memo we will present a set of mechanisms to deal with the 78 problem created by the interaction between ingress filtering [3] and 79 legacy hosts in multihomed sites. 81 The remaining of this memo is structured as follows: we will first 82 present the reference topology and then the problem created by the 83 interaction of ingress filtering and multihoming. Then, we will 84 state the goals and non goals of the mechanisms presented in this 85 memo. Next the proposed mechanisms are described. The Appendix A 86 include a possible optimization for the case that the host within the 87 multihomed site involved in the communication has special multihoming 88 support. 90 2. Reference topology 92 In the following discussion, we will use this reference topology: 94 /-- ( A ) ---( ) --- ( C ) --\ 95 X (site X) ( IPv6 ) (Site Y) Y 96 \-- ( B ) ---( ) --- ( D ) --/ 98 The topology features two hosts, X and Y, whose respective sites are 99 both multi-homed. Host X has two global IPv6 addresses, which we 100 will note "A:X" and "B:X", formed by combining the prefixes allocated 101 by ISP A and B to "site X" with the host identifier of X. Similarly, 102 Y has two addresses "C:Y" and "D:Y". 104 We assume that X, when it starts engaging communication with Y, has 105 learned the addresses C:Y and D:Y, for example because they were 106 published in the DNS. We assume that Y, when it receives packets 107 from X, has only access to information contained in the packet coming 108 from X, e.g. the source address; we do not assume that Y can retrieve 109 by external means the set of addresses associated to X. 111 3. The problem: Ingress filtering incompatibility 113 Ingress filtering refers to the verification of the source address of 114 the IP packets at the periphery of the Internet, typically at the 115 link between a customer and an ISP. This process, which is described 116 in [3] is intended to thwart a class of denial of service attacks in 117 which attackers hide their identity by using a "spoofed" source 118 address. 120 A special complication appears when the ISPs who serve the multihomed 121 site perform ingress filtering. In the above configuration, X is 122 served by ISP A and B, and thus can be reached by the addresses A:X 123 and B:X. In addition Y is served by ISP C and D, and thus can be 124 reached by the addresses C:Y and D:Y. To communicate with Y, X will 125 choose the destination address that appears to be easier to reach, 126 for example D:Y; then, it will choose the source address that 127 provides the most efficient reverse path, say A:X. 129 Suppose now that the ISP connections at Site X are managed by two 130 different site exit routers, RXA and RXB, and that there is a similar 131 configuration at Site Y, with routers RYC and RYD. 133 /-- ( A ) ---( ) --- ( C ) --\ 134 (RXA) ( ) (RYC) 135 X (site X) ( IPv6 ) (Site Y) Y 136 (RXB) ( ) (RYD) 137 \-- ( B ) ---( ) --- ( D ) --/ 139 Within Site X, the interior routing will decide which of RXA or RXB 140 is the preferred exit router for the destination "D:Y"; similarly, 141 within Site Y, the interior routing will decide which of RYC or RYD 142 is the preferred exit for destination A:X. If the chosen exit router 143 at Site X is RXA, the packet will flow freely to RYD; If the chosen 144 exit router at Site Y is RYD, the response will also flow freely. 145 However, if the exit routers are RXB or RYC, and if the ISPs perform 146 ingress filtering, we have a problem: ISP B sees a packet coming from 147 RXB, whose source address does not match the prefix assigned by B to 148 X; ISP C, similarly, sees a packet whose source address does not 149 match the prefix assigned by that ISP to Y. If either of these ISPs 150 decides to drop the packet, the communication will be broken. 151 Similar problems can also occur in communications between a host 152 within a multihomed site and a host within a single-homed site. 154 4. Goals and non goals of the presented solution 156 4.1. Goal 158 The goal of the proposed solution is to provide ingress filtering 159 compatibility for legacy hosts in multihomed environments, as 160 described in RFC 3582 [2] . 162 "The solution should not destroy IPv6 connectivity for a legacy host 163 implementing RFC 3513 [4] , RFC 2460 [1] , RFC 3493 [5], and other 164 basic IPv6 specifications current in April 2003. That is to say, if 165 a host can work in a single-homed site, it should still be able to 166 work in a multihomed site, even if it cannot benefit from site- 167 multihoming. 169 It would be compatible with this goal for such a host to lose 170 connectivity if a site lost connectivity to one transit provider, 171 despite the fact that other transit provider connections were still 172 operational."[sic] 174 So, the goal of the presented solution is to enable a communication 175 of two legacy hosts when at least one of them is in multihomed site, 176 as long as no outage has occurred in the connectivity. 178 4.2. Non-goals 180 - It is not a goal of the presented solution to provide a complete 181 multihoming solution. In particular, the presented solution does not 182 provide fault tolerance capabilities (it does not preserve 183 established communication through outages nor it enable hosts to 184 initiate communications after an outage). So, the presented solution 185 is a single component of a multihoming solution. 187 5. Proposed solution 189 In order to support legacy hosts, the addresses included in packets 190 must be honored i.e. cannot be changed after that the host that is 191 initiating the communication has selected them. So, there are two 192 possible approaches to provide ingress filtering compatibility: to 193 relax the ingress filtering or to perform some form of source address 194 dependent routing. Both mechanisms will be presented next. 196 5.1. Relaxing the ingress filtering 198 An obvious way to avoid failures due to ingress filtering is to 199 simply make sure that all the addresses used by the hosts of a given 200 site will be considered acceptable by each of the site's providers. 201 In our site X example, that would mean that provider A would accept 202 addresses of the form "B:X" as valid, and that provider B will in 203 turn accept addresses of the form "A:X" as valid. 205 One way to achieve this is simply to ask the service provider to turn 206 off source address checks on the site connection. This requires a 207 substantial amount of trust between the provider and the site, as 208 source address checks are in effect delegated to the site routers. 209 One possible way to achieve this trust is to make sure that the site 210 routers, or possibly the site firewalls, meet a quality level 211 specified by the provider. 213 Another way to achieve this relaxed level of checking is to check 214 source addresses against a list of "authorized prefixes" for the site 215 connection, rather than simply the single prefix delegated by the 216 provider. This solution requires that the site communicates the 217 authorized prefixes to the provider, either through a management 218 interface or through a routing protocol. This is obviously more 219 complex than simply lifting the controls, and in fact ends up with a 220 very similar requirement of trust: the provider has to be believe 221 that the site will transmit the right prefixes. 223 In conclusion, relaxing the source address checks requires some form 224 of explicit trust between the site and its providers. There is no 225 doubt that this level of trust will exist in many cases; there is 226 also no doubt that there will be many cases in which the provider is 227 unwilling to grant this trust, particularly in the case of small 228 sites, such as for example home networks dual-homes to a DSL provider 229 and a cable network provider. So, this solution is a perfectly 230 reasonable solution for large sites, i.e. the sites that benefit of 231 IPv4 multihoming today: it should not be more complex to convince a 232 provider to relax address checks for a particular customer tomorrow, 233 than to convince today a similar provider to advertise in its routing 234 table the global IPv4 address of the site. If we choose this 235 solution, we should choose its simplest implementation, i.e. one in 236 which the provider completely delegates source address checks to the 237 site's router or firewalls. This is however not a general solution, 238 since we cannot expect all sites to convince every provider to relax 239 their checks. 241 5.2. Source Address Dependent (SAD) routing 243 In order to provide ingress filtering compatibility it is possible to 244 perform some kind of Source Address Dependent (SAD) routing within 245 the site, so that the site exit is effectively a function of the 246 source address in the packet. It should be noted that SAD routing 247 does not have to be supported by all the routers of the multihomed 248 site, but its support is only required to a connected domain that 249 includes all the site exit routers as in the next figure: 251 Multiple site exits 252 | | | | 253 -----+-----+-----+-----+----- 254 ( ) 255 ( SAD routing domain ) 256 ( ) 257 ----+----+----+----+----+---- 258 ( ) 259 ( Generic routing domain ) 260 ( ) 261 ----------------------------- 263 In this schema, all site exit routers are connected to a SAD routing 264 domain. Packets initiated in the generic routing domain and bound to 265 an "out of site" address are passed to the nearest access point to 266 the SAD routing domain, using classic "hot potato" routing. The 267 routers in the SAD routing domain maintain as many parallel routing 268 tables as there are valid source prefixes, and would choose a route 269 that is a function of both the source and the destination address; 270 the packets exit the site through the "right" router. There are 271 multiple possible implementations of this general concept, depending 272 on the site topology and the amount of routers involved. We will 273 next present different scenarios and how SAD routing can be adopted 274 in each of them. 276 5.2.1. Single site exit router 278 The simplest implementation is to have only one exit router for the 279 site; in this case, the SAD routing domain is reduced to the exit 280 router itself. This exit router chooses the exit link on the basis 281 of the source address in the packet. Many of the commercial routers 282 already support this functionality so the solution in this cases 283 could be easily adopted. 285 5.2.2. DMZ 287 A slightly less complex implementation is to connect all site exit 288 routers to the same link, e.g. to what is often referred to as the 289 "DMZ" for the site. This solution requires that all site exit 290 routers connected to the DMZ support SAD routing. In this case, when 291 a site exit router receives a packet, it verifies the source address; 292 if the source address corresponds to its directly connected ISP, the 293 site exit router forwards the packet through the ISP; if the source 294 address of the packet does not corresponds to the directly connected 295 ISP, the site exit router forwards the packet to the site exit router 296 which ISP corresponds to the source address included in the packet. 298 In the case that a DMZ is not naturally available in the site, it is 299 possible to create a virtual DMZ by using a mesh of tunnels between 300 the site exit routers. In this case, a site exit router that 301 receives a packet bound for an out-of-site address would perform a 302 source address check before forwarding the packet on one of its 303 outgoing interfaces; if the source address check is positive, the 304 packet will effectively be sent on the interface; if it is not, the 305 packet would be "tunneled" to the appropriate router. 307 The main requirement of the DMZ alternative is that site-exit routers 308 be able to perform address checks, and that each site exit router be 309 able to associate to each valid site prefix the address of a 310 corresponding site exit router. An obvious possibility is to 311 configure prefixes and corresponding addresses in each router; it 312 would however be preferable to derive these addresses automatically. 313 An assumption of the IPv6 architecture is that all prefixes of a site 314 will have the same length; it is thus possible to derive a prefix 315 from the source address of a "misdirected" packet, by combining this 316 prefix with a conventional suffix. The suffix should be chosen to 317 not collide with the subnet numbers used in the site; a null value 318 will be inadequate, since it could be matched by any router with 319 knowledge of the prefix, not just the site exit router; a value of 320 "all ones" could be adequate. 322 So, each router managing a site prefix will then inject a "host 323 route" announcing the anycast address associated to its locally 324 managed prefixes in the interior routing protocol. Site exit routers 325 can then use the standard routing procedures to detect whether the 326 anycast address corresponding to the prefix in use is reachable; they 327 can automatically reject, rather than forward, packets whose source 328 address does not correspond to a reachable anycast address. 330 An inconvenience of this set-up is that some packet will follow a 331 less than direct path; in the case of a natural DMZ, the additional 332 path is probably negligible. However, in the case of a mesh of 333 tunnels, the additional path may be significant, so this is not by 334 itself a definitive solution. A possibility is to use this approach 335 to support legacy hosts within the multihomed site and complement the 336 solution by adopting the host based mechanism presented in Appendix A 337 to allow upgraded host to select the optimal path. Another 338 possibility is to use this approach as a way to "phase in" a full SAD 339 routing solution described in the next section. 341 5.2.3. General case 343 In the most general set up, SAD routing is supported in all the site 344 exit routers and all the internal routers required to create a 345 connected SAD routing domain. Each router of the SAD domain would 346 maintain as many parallel routing tables as there are valid source 347 prefixes, and would choose a route that is a function of both the 348 source and the destination address. Depending on how routes to 349 external destinations are configured in routers the amount of work 350 required to support SAD routing varies considerably. 352 5.2.3.1. Manual configuration 354 If routes to external destinations are manually configured, then the 355 manual configuration of additional routes corresponding to each of 356 the available prefixes is required. So, if within the multihomed 357 site there are n prefixes and each router has m external routes 358 configured, then (n-1)m additional routes need to be configured per 359 router of the SAD routing domain. 361 It should be noted than multiple commercial routers currently support 362 manually configured SAD routing, so this solution is already 363 available. 365 It should also be noted that the usage of manually configured static 366 routes does not preclude the fault tolerance capabilities of a 367 multihoming solution, since fault tolerance is achieved by changing 368 the prefix used for the communication, which is likely to be 369 performed by the host itself, and not by the routing system. 370 However, obtaining dynamic routing information may help the host to 371 detect outages and enable faster response to outages. 373 5.2.3.2. Dynamic configuration 375 Information about external routes can be propagated within the 376 multihomed site using a routing protocol, whether a IGP or BGP. 378 In order to support SAD routing in this scenario, routing protocols 379 also have to convey information about the prefix associated with 380 routing information that is being propagated. That is the prefix 381 corresponding to the ISP through which the routing information was 382 obtained. 384 When BGP is used, it would be possible to use a private community 385 attribute to encode such information. However, current commercial 386 routers don't support updating the different routing tables required 387 to support SAD routing based on a BGP attribute (as far as we know). 389 In the general case, it is possible to run multiple instances of the 390 routing protocol and associate each instance to a prefix, so that 391 each instance of the routing protocol only carries information 392 learned through the ISP corresponding to the prefix. However, our 393 preliminary tests on this mechanisms seem to indicate that such 394 mechanism wouldn't be currently supported by commercial routers. 396 It should be noted that having dynamic routing information about 397 external routes does not provide fault tolerance to the multihomed 398 sites as it did in IPv4-style multihoming, since, in sites with 399 multiple prefixes, fault tolerance requires changing the prefix used 400 for the communication. However, having dynamic routing information 401 available does provide a faster feedback about failures, enabling 402 faster response to outages. 404 6. Appendix A: Host based optimization 406 In this Appendix we present a host based mechanism to provide ingress 407 filtering compatibility. The mechanism, called "Exit router 408 discovery", enables the host to discover the preferred exit router 409 for a given source address so that the host can tunnel the packet 410 directly to the adequate exit router, obtaining optimal site exit 411 path. 413 Exit router discovery is a natural complement of the tunneling 414 mechanism between site exit routers. When an exit router tunnels a 415 misdirected packet towards another exit, it may send an appropriate 416 ICMP Destination Unreachable error message with code 5 which means 417 source address failed ingress policy. If the host is a legacy host, 418 the ICMP message will be ignored; further packets will continue using 419 the same slightly sub-optimal path. On the other hand, if the host 420 has been upgraded to take advantage of multi-homing, the packets will 421 be tunneled to the appropriate exit router; they will follow a direct 422 path to this router. 424 So, according to this mechanisms presented in this memo, site exit 425 routers are expected to perform necessary source address checks 426 before forwarding any packet on a site exit link. The amount of 427 checking will vary depending on the exit link. If the provider has 428 agreed to relax source address checking, the router will be 429 configured to not do any checking at all; if the provider is expected 430 to enforce a source address check, the site exit router must do the 431 check first, in order to avoid local packets being routed to a black 432 hole. If the result of the check is positive, the packet will be 433 forwarded. If the result is negative, the router will derive a "site 434 exit anycast address" from the source address of the incoming packet. 435 If the anycast address is unreachable, the incoming packet will have 436 to be discarded. If the anycast address is reachable, the incoming 437 packet will be tunneled towards that address, and the router may 438 issue a ICMP Destination Unreachable error message with code 5 which 439 means source address failed ingress policy. 441 The reception of the ICMP packet is interpreted by the host 442 implementing the exit discovery mechanism as an indication that the 443 exit path being used is suboptimal. So, the host will first generate 444 the site exit anycast address that corresponds to the source prefix 445 of the packet that caused the generation of the ICMP packet (this is 446 possible because the ICMP message payload contains enough information 447 about the initial packet). Then, the host will associate this site 448 exit anycast address to the source and destination address pair of 449 the initial packet, and then tunnel packets directly to that exit 450 router which will decapsulate these packets and send them over the 451 appropriate exit link. 453 This mechanism requires a change to the caches used in neighbor 454 discovery, specifically the management of a "source exit cache" that 455 associates a specific source address with an exit router, or maybe 456 the combination of a destination address and a source address with an 457 exit router. 459 We should note that "exit router discovery" is not implemented in 460 current hosts. We must meet the requirement expressed in RFC 3582 461 that hosts implementing the current version of IPv6 can continue to 462 operate in a multi-homed site, even if they would not take advantage 463 of multihoming; in consequence, these procedures can only be used as 464 an optional optimization. It should also be noted that the presented 465 mechanism does not requires any support from the host outside the 466 multihomed site. 468 7. Security Considerations 470 There are elements presented in this draft that require further 471 analysis from a security point of view: the usage of the anycast 472 address of the site exit router associated to a given prefix and the 473 usage of ICMP error messages to redirect following packets. 475 The usage of the anycast address of the site exit router router 476 associated to a given prefix may enable potential attacks where the 477 attacker announces the anycast address associated with a certain 478 perifx and sinks the traffic containing such prefix in the source 479 address. However, this threat is similar to the case where an 480 attacker simply injects a route in the interior routing system, for 481 instance a default route, sinking the packets of those routers and 482 hosts that preffer such route. 484 An attacker could generate false ICMP errors to trigger the 485 tunnelling of packets to the anycast address associated with the 486 prefix of the source address. However, the result of such attack 487 would simply be that packets are tunnelled through the appropriate 488 site exit router. In the worst case, the packet would carry an extra 489 tunnel header that would not be really required, causing additional 490 overhead. In any case, these attack does not seem to cause 491 cosniderable harm. 493 8. Acknowledgments 495 This memo contains parts of a previous work entitled "Host-Centric 496 IPv6 Multihoming" that benefited from comments from Alberto Garcia 497 Martinez, Cedric de Launois, Brian Carpenter, Dave Crocker, Xiaowei 498 Yang and Erik Nordmark. 500 9. References 502 [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 503 Specification", RFC 2460, December 1998. 505 [2] Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site- 506 Multihoming Architectures", RFC 3582, August 2003. 508 [3] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating 509 Denial of Service Attacks which employ IP Source Address 510 Spoofing", RFC 2267, January 1998. 512 [4] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 513 Addressing Architecture", RFC 3513, April 2003. 515 [5] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 516 Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, 517 March 2003. 519 Authors' Addresses 521 Christian Huitema 522 Microsoft Corporation 523 One Microsoft Way 524 Redmond, WA 98052-6399 525 USA 527 Phone: 528 Email: huitema@microsoft.com 529 URI: 531 Marcelo Bagnulo 532 Universidad Carlos III de Madrid 533 Av. Universidad 30 534 Leganes, Madrid 28911 535 SPAIN 537 Phone: 34 91 6249500 538 Email: marcelo@it.uc3m.es 539 URI: http://www.it.uc3m.es 541 Intellectual Property Statement 543 The IETF takes no position regarding the validity or scope of any 544 Intellectual Property Rights or other rights that might be claimed to 545 pertain to the implementation or use of the technology described in 546 this document or the extent to which any license under such rights 547 might or might not be available; nor does it represent that it has 548 made any independent effort to identify any such rights. Information 549 on the procedures with respect to rights in RFC documents can be 550 found in BCP 78 and BCP 79. 552 Copies of IPR disclosures made to the IETF Secretariat and any 553 assurances of licenses to be made available, or the result of an 554 attempt made to obtain a general license or permission for the use of 555 such proprietary rights by implementers or users of this 556 specification can be obtained from the IETF on-line IPR repository at 557 http://www.ietf.org/ipr. 559 The IETF invites any interested party to bring to its attention any 560 copyrights, patents or patent applications, or other proprietary 561 rights that may cover technology that may be required to implement 562 this standard. Please address the information to the IETF at 563 ietf-ipr@ietf.org. 565 Disclaimer of Validity 567 This document and the information contained herein are provided on an 568 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 569 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 570 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 571 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 572 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 573 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 575 Copyright Statement 577 Copyright (C) The Internet Society (2006). This document is subject 578 to the rights, licenses and restrictions contained in BCP 78, and 579 except as set forth therein, the authors retain all their rights. 581 Acknowledgment 583 Funding for the RFC Editor function is currently provided by the 584 Internet Society.