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