idnits 2.17.1 draft-huitema-multi6-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.a on line 19. -- 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. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 a Security Considerations section. ** 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 == Line 83 has weird spacing: '...al with the...' == Line 86 has weird spacing: '...mponent and a...' -- 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 16, 2004) is 7132 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: 13 errors (**), 0 flaws (~~), 4 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 16, 2005 Microsoft 5 M. Bagnulo 6 UC3M 7 October 16, 2004 9 Ingress filtering compatibility for IPv6 multihomed sites 10 draft-huitema-multi6-ingress-filtering-00 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on April 16, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). 43 Abstract 45 The note presents a set of mechanisms to provide ingress filtering 46 compatibility for legacy hosts in IPv6 multihomed sites. The 47 described mechanisms are not a complete multihoming solution but just 48 a component, and additional mechanisms will be needed to fulfill all 49 the requirements of multihoming. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Reference topology . . . . . . . . . . . . . . . . . . . . . . 4 55 3. The problem: Ingress filtering incompatibility . . . . . . . . 5 56 4. Goals and non goals of the presented solution . . . . . . . . 6 57 4.1 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 4.2 Non-goals . . . . . . . . . . . . . . . . . . . . . . . . 6 59 5. Proposed solution . . . . . . . . . . . . . . . . . . . . . . 7 60 5.1 Relaxing the ingress filtering . . . . . . . . . . . . . . 7 61 5.2 Source address dependent (SAD) routing . . . . . . . . . . 8 62 5.2.1 Single site exit router . . . . . . . . . . . . . . . 8 63 5.2.2 DMZ . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 5.2.3 General case . . . . . . . . . . . . . . . . . . . . . 10 65 6. Appendix A: Host based optimization . . . . . . . . . . . . . 12 66 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 69 Intellectual Property and Copyright Statements . . . . . . . . 16 71 1. Introduction 73 A way to solve the issue of site multihoming is to have a separate 74 site prefix for each connection of the site, and to derive as many 75 addresses for each hosts. This approach to multi-homing, which we 76 call Host-Centric IPv6 Multihoming, has the advantage of minimal 77 impact on the inter-domain routing fabric, since each site prefix can 78 be aggregated within the larger prefix of a specific provider; 79 however, it opens a number of issues, that have to be addressed in 80 order to provide a multihoming solution compatible with such 81 addressing scheme. 83 In this memo we will present a set of mechanisms to deal with the 84 problem created by the interaction between ingress filtering [3] 85 and legacy hosts in multihomed sites. The mechanisms presented are 86 not a complete solution but just a component and additional 87 mechanisms will be needed to fulfill all the requirements of 88 multihoming. 90 The remaining of this memo is structured as follows: we will first 91 present the reference topology and then the problem created by the 92 interaction of ingress filtering and multihoming. Then, we will 93 state the goals and non goals of the mechanisms presented in this 94 memo. Next the proposed mechanisms are described. The Appendix A 95 include a possible optimization for the case that the host within the 96 multihomed site involved in the communication has special multihoming 97 support. 99 2. Reference topology 101 In the following discussion, we will use this reference topology: 103 /-- ( A ) ---( ) --- ( C ) --\ 104 X (site X) ( IPv6 ) (Site Y) Y 105 \-- ( B ) ---( ) --- ( D ) --/ 107 The topology features two hosts, X and Y, whose respective sites are 108 both multi-homed. Host X has two global IPv6 addresses, which we 109 will note "A:X" and "B:X", formed by combining the prefixes allocated 110 by ISP A and B to "site X" with the host identifier of X. Similarly, 111 Y has two addresses "C:Y" and "D:Y". 113 We assume that X, when it starts engaging communication with Y, has 114 learned the addresses C:Y and D:Y, for example because they were 115 published in the DNS. We assume that Y, when it receives packets 116 from X, has only access to information contained in the packet coming 117 from X, e.g. the source address; we do not assume that Y can 118 retrieve by external means the set of addresses associated to X. 120 3. The problem: Ingress filtering incompatibility 122 Ingress filtering refers to the verification of the source address of 123 the IP packets at the periphery of the Internet, typically at the 124 link between a customer and an ISP. This process, which is described 125 in [3] is intended to thwart a class of denial of service attacks in 126 which attackers hide their identity by using a "spoofed" source 127 address. 129 A special complication appears when the ISPs who serve the multihomed 130 site perform ingress filtering. In our generic configuration, we 131 assume that X is served by ISP A and B, and thus can be reached by 132 the addresses A:X and B:X. We also we assume that Y is served by ISP 133 C and D, and thus can be reached by the addresses C:Y and D:Y. To 134 communicate with Y, X will choose the destination address that 135 appears to be easier to reach, for example D:Y; then, it will choose 136 the source address that provides the most efficient reverse path, say 137 A:X. 139 Suppose now that the ISP connections at Site X are managed by two 140 different site exit routers, RXA and RXB, and that there is a similar 141 configuration at Site Y, with routers RYC and RYD. 143 /-- ( A ) ---( ) --- ( C ) --\ 144 (RXA) ( ) (RYC) 145 X (site X) ( IPv6 ) (Site Y) Y 146 (RXB) ( ) (RYD) 147 \-- ( B ) ---( ) --- ( D ) --/ 149 Within Site X, the interior routing will decide which of RXA or RXB 150 is the preferred exit router for the destination "D:Y"; similarly, 151 within Site Y, the interior routing will decide which of RYC or RYD 152 is the preferred exit for destination A:X. If the chosen exit router 153 at Site X is RXA, the packet will flow freely to RYD; If the chosen 154 exit router at Site Y is RYD, the response will also flow freely. 155 However, if the exit routers are RXB or RYC, and if the ISPs perform 156 ingress filtering, we have a problem: ISP B sees a packet coming from 157 RXB, whose source address does not match the prefix assigned by B to 158 X; ISP C, similarly, sees a packet whose source address does not 159 match the prefix assigned by that ISP to Y. If either of these ISPs 160 decides to drop the packet, the communication will be broken. 161 Similar problems can also occur in communications between a host 162 within a multihomed site and a host within a single-homed site. 164 4. Goals and non goals of the presented solution 166 4.1 Goal 168 The goal of the proposed solution is to provide ingress filtering 169 compatibility for legacy hosts in multihomed environments, as 170 described in RFC 3582 [2] . 172 "The solution should not destroy IPv6 connectivity for a legacy host 173 implementing RFC 3513 [4] , RFC 2460 [1] , RFC 3493 [5], and other 174 basic IPv6 specifications current in April 2003. That is to say, if 175 a host can work in a single-homed site, it should still be able to 176 work in a multihomed site, even if it cannot benefit from site- 177 multihoming. 179 It would be compatible with this goal for such a host to lose 180 connectivity if a site lost connectivity to one transit provider, 181 despite the fact that other transit provider connections were still 182 operational."[sic] 184 So, the goal of the presented solution is to enable a communication 185 of two legacy hosts when at least one of them is in multihomed site, 186 as long as no outage has occurred in the connectivity. 188 4.2 Non-goals 190 - It is not a goal of the presented solution to provide a complete 191 multihoming solution. In particular, the presented solution does not 192 provide fault tolerance capabilities (it does not preserve 193 established communication through outages nor it enable hosts to 194 initiate communications after an outage). So, the presented solution 195 is a single component of a multihoming solution. 197 - It is not a goal of the presented solution to address the ingress 198 filtering incompatibility problem for a communication between two 199 hosts that have some sort of mutlihoming support. The presented 200 solution may apply to those hosts but maybe there are better 201 solutions that can be used in such scenario. 203 5. Proposed solution 205 In order to support legacy hosts, the addresses included in packets 206 must be honored i.e. cannot be changed after that the host that is 207 initiating the communication has selected them. So, there are two 208 possible approaches to provide ingress filtering compatibility: to 209 relax the ingress filtering or to perform some form of source address 210 dependent routing. Both mechanisms will be presented next. 212 5.1 Relaxing the ingress filtering 214 An obvious way to avoid failures due to ingress filtering is to 215 simply make sure that all the addresses used by the hosts of a given 216 site will be considered acceptable by each of the site's providers. 217 In our site X example, that would mean that provider A would accept 218 addresses of the form "B:X" as valid, and that provider B will in 219 turn accept addresses of the form "A:X" as valid. 221 One way to achieve this is simply to ask the service provider to turn 222 off source address checks on the site connection. This requires a 223 substantial amount of trust between the provider and the site, as 224 source address checks are in effect delegated to the site routers. 225 One possible way to achieve this trust is to make sure that the site 226 routers, or possibly the site firewalls, meet a quality level 227 specified by the provider. 229 Another way to achieve this relaxed level of checking is to check 230 source addresses against a list of "authorized prefixes" for the site 231 connection, rather than simply the single prefix delegated by the 232 provider. This solution requires that the site communicates the 233 authorized prefixes to the provider, either through a management 234 interface or through a routing protocol. This is obviously more 235 complex than simply lifting the controls, and in fact ends up with a 236 very similar requirement of trust: the provider has to be believe 237 that the site will transmit the right prefixes. 239 In conclusion, relaxing the source address checks requires some form 240 of explicit trust between the site and its providers. There is no 241 doubt that this level of trust will exist in many cases; there is 242 also no doubt that there will be many cases in which the provider is 243 unwilling to grant this trust, particularly in the case of small 244 sites, such as for example home networks dual-homes to a DSL provider 245 and a cable network provider. So, this solution is a perfectly 246 reasonable solution for large sites, i.e. the sites that benefit of 247 IPv4 multihoming today: it should not be more complex to convince a 248 provider to relax address checks for a particular customer tomorrow, 249 than to convince today a similar provider to advertise in its routing 250 table the global IPv4 address of the site. If we choose this 251 solution, we should choose its simplest implementation, i.e. one in 252 which the provider completely delegates source address checks to the 253 site's router or firewalls. This is however not a general solution, 254 since we cannot expect all sites to convince every provider to relax 255 their checks. 257 5.2 Source address dependent (SAD) routing 259 In order to provide ingress filtering compatibility it is possible to 260 perform some kind of source address dependent routing within the 261 site, so that the site exit is effectively a function of the source 262 address in the packet. It should be noted that SAD routing doesn't 263 have to be supported by all the routers of the multihomed site, but 264 its support is only required to a connected domain that includes all 265 the site exit routers as in the next figure: 267 Multiple site exits 268 | | | | 269 -----+-----+-----+-----+----- 270 ( ) 271 ( Source based routing domain ) 272 ( ) 273 ----+----+----+----+----+---- 274 ( ) 275 ( Generic routing domain ) 276 ( ) 277 ----------------------------- 279 In this schema, all site exit routers are connected to a source based 280 routing domain. Packets initiated in the generic routing domain and 281 bound to an "out of site" address are passed to the nearest access 282 point to the source based routing domain, using classic "hot potato" 283 routing. The routers in the source based routing domain maintain as 284 many parallel routing tables as there are valid source prefixes, and 285 would choose a route that is a function of both the source and the 286 destination address; the packets exit the site through the "right" 287 router. There are multiple possible implementations of this general 288 concept, depending on the site topology and the amount of routers 289 involved. We will next present different scenarios and how SAD 290 routing can be adopted in each of them. 292 5.2.1 Single site exit router 294 The simplest implementation is to have only one exit router for the 295 site; this exit router chooses the exit link on the basis of the 296 source address in the packet. Many of the commercial routers already 297 support this functionality so the solution in this cases could be 298 easily adopted. 300 5.2.2 DMZ 302 A slightly less complex implementation is to connect all exit routers 303 to the same link, e.g. to what is often referred to as the "DMZ" for 304 the site. This solution requires that all routers connected to the 305 DMZ support SAD routing. In this case, when a site exit router 306 receives a packet, it verifies the source address; if the source 307 address corresponds to its directly connected ISP, the site exit 308 router forwards the packet through the ISP; if the source address of 309 the packet does not corresponds to the directly connected ISP, the 310 site exit router forwards the packet to the site exit router which 311 ISP corresponds to the source address included in the packet. 313 In the case that a DMZ is not naturally available in the site, it is 314 possible to create a virtual DMZ by using a mesh of tunnels between 315 the site exit routers. In this case, a site exit router that 316 receives a packet bound for an out-of-site address would perform a 317 source address check before forwarding the packet on one of its 318 outgoing interfaces; if the source address check is positive, the 319 packet will effectively be sent on the interface; if it is not, the 320 packet would be "tunneled" to a more adequate router. 322 The main requirement of the DMZ alternative is that site-exit routers 323 be able to perform address checks, and that each site exit router be 324 able to associate to each valid site prefix the address of a 325 corresponding site exit router. An obvious possibility is to 326 configure prefixes and corresponding addresses in each router; it 327 would however be preferable to derive these addresses automatically. 328 A strong assumption of the IPv6 architecture is that all prefixes of 329 a site will have the same length; it is thus possible to derive a 330 prefix from the source address of a "misdirected" packet, by 331 combining this prefix with a conventional suffix. The suffix should 332 be chosen to not collide with the subnet numbers used in the site; a 333 null value will be inadequate, since it could be matched by any 334 router with knowledge of the prefix, not just the site exit router; a 335 value of "all ones" could be adequate. 337 So, each router managing a site prefix will then inject a "host 338 route" for its locally managed prefixes in the interior routing 339 protocol. Site exit routers can then use the standard routing 340 procedures to detect whether the anycast address corresponding to the 341 prefix in use is reachable; they can automatically reject, rather 342 than forward, packets whose source address does not correspond to a 343 reachable anycast address. 345 An inconvenience of this set-up is that some packet will follow a 346 less than direct path; in the case of a natural DMZ, the additional 347 path is probably negligible. However, in the case of a mesh of 348 tunnels, the additional path may be significant, so this is not by 349 itself a definitive solution. A possibility is to use this approach 350 to support legacy hosts within the multihomed site and complement the 351 solution by adopting the host based mechanism presented in Appendix A 352 to allow upgraded host to select the optimal path. Another 353 possibility is to use this approach as a way to "phase in" a full 354 Source Address Dependent solution described in the next section. 356 5.2.3 General case 358 In the most general set up, SAD routing is supported in all the site 359 exit routers and all the internal routers required to created a 360 connected SAD routing domain. Each router of the SAD domain would 361 maintain as many parallel routing tables as there are valid source 362 prefixes, and would choose a route that is a function of both the 363 source and the destination address. Depending on how routes to 364 external destinations are configured in routers the amount of work 365 required to support SAD routing varies considerably. 367 5.2.3.1 Manual configuration 369 If routes to external destinations are manually configured, then the 370 manual configuration of additional routes corresponding to each of 371 the available prefixes is required. So, if within the multihomed 372 site there are n prefixes and each router has m external routes 373 configured, then (n-1)m additional routes need to be configured per 374 router of the SAD routing domain. 376 It should be noted than multiple commercial routers currently support 377 manually configured SAD routing, so this solution is already 378 available. 380 It should also be noted that the usage of manually configured static 381 routes doesn't precludes the fault tolerance capabilities of a 382 multihoming solution, since fault tolerance is achieved by changing 383 the prefix used for the communication, which is likely to be 384 performed by the host itself, and not by the routing system. 385 However, obtaining dynamic routing information may help the host to 386 detect outages and enable faster response to outages. 388 5.2.3.2 Dynamic configuration 390 Information about external routes can be propagated within the 391 multihomed site using a routing protocol, whether a IGP or BGP. 393 In order to support SAD routing in this scenario, routing protocols 394 also have to convey information about the prefix associated with 395 routing information that is being propagated. That is the prefix 396 corresponding to the ISP through which the routing information was 397 obtained. 399 When BGP is used, it would be possible to use a private community 400 attribute to encode such information. However, current commercial 401 routers don't support updating the different routing tables required 402 to support SAD routing based on a BGP attribute (as far as we know). 404 In the general case, it is possible to run multiple instances of the 405 routing protocol and associate each instance to a prefix, so that 406 each instance of the routing protocol only carries information 407 learned through the ISP corresponding to the prefix. However, our 408 preliminary tests on this mechanisms seem to indicate that such 409 mechanism wouldn't be currently supported by commercial routers. 411 It should be noted that having dynamic routing information about 412 external routes doesn't provides fault tolerance to the multihomed 413 sites as it did in IPv4-style multihoming, since, in sites with 414 multiple prefixes, fault tolerance requires changing the prefix used 415 for the communication. However, having dynamic routing information 416 available does provides a faster feedback about failures, enabling 417 faster response to outages. 419 6. Appendix A: Host based optimization 421 In this Appendix we will present a host based mechanism to provide 422 ingress filtering compatibility. The mechanism, called "Exit router 423 discovery", enables the host to discover the preferred exit router 424 for a given source address so that the host can tunnel the packet 425 directly to the adequate exit router, obtaining optimal site exit 426 path. 428 Exit router discovery is a natural complement of the tunneling 429 mechanism between site exit routers. When an exit router tunnels a 430 misdirected packet towards another exit, it may send an appropriate 431 ICMP Destination Unreachable error message with code 5 which means 432 source address failed ingress policy. If the host is a legacy host, 433 the ICMP message will be ignored; further packets will continue using 434 the same slightly sub-optimal path. On the other hand, if the host 435 has been upgraded to take advantage of multi-homing, the packets will 436 be tunneled to the appropriate exit router; they will follow a direct 437 path to this router. 439 So, according to the mechanisms presented in this memo, site exit 440 routers are expected to perform necessary source address checks 441 before forwarding any packet on a site exit link. The amount of 442 checking will vary depending on the exit link. If the provider has 443 agreed to relax source address checking, the router will be 444 configured to not do any checking at all; if the provider is expected 445 to enforce a source address check, the site exit router must do the 446 check first, in order to avoid local packets being routed to a black 447 hole. If the result of the check is positive, the packet will be 448 forwarded. If the result is negative, the router will derive a "site 449 exit anycast address" from the source address of the incoming packet. 450 If the anycast address is unreachable, the incoming packet will have 451 to be discarded. If the anycast address is reachable, the incoming 452 packet will be tunneled towards that address, and the router may 453 issue a ICMP Destination Unreachable error message with code 5 which 454 means source address failed ingress policy. 456 The reception of the ICMP packet is interpreted by the host 457 implementing the exit discovery mechanism as an indication that the 458 exit path being used is suboptimal. So, the host will first generate 459 the site exit anycast address that corresponds to the source prefix 460 of the packet that caused the generation of the ICMP packet (this is 461 possible because the ICMP message payload contains enough information 462 about the initial packet). Then, the host will associate this site 463 exit anycast address to the source and destination address pair of 464 the initial packet, and then tunnel packets directly to that exit 465 router which will decapsulate these packets and send them over the 466 appropriate exit link. 468 This mechanism requires a change to the caches used in neighbor 469 discovery, specifically the management of a "source exit cache" that 470 associates a specific source address with an exit router, or maybe 471 the combination of a destination address and a source address with an 472 exit router. 474 We should note that "exit router discovery" is not implemented in 475 current hosts. We must meet the requirement expressed in RFC 3582 476 that hosts implementing the current version of IPv6 can continue to 477 operate in a multi-homed site, even if they would not take advantage 478 of multihoming; in consequence, these procedures can only be used as 479 an optional optimization. It should also be noted that the presented 480 mechanism does not requires any support from the host outside the 481 multihomed site. 483 7. Acknowledgments 485 This memo contains parts of a previous work entitled "Host-Centric 486 IPv6 Multihoming" that benefited from comments from Alberto Garcia 487 Martinez, Cedric de Launois, Brian Carpenter, Dave Crocker, Xiaowei 488 Yang and Erik Nordmark. 490 8 References 492 [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 493 Specification", RFC 2460, December 1998. 495 [2] Abley, J., Black, B. and V. Gill, "Goals for IPv6 496 Site-Multihoming Architectures", RFC 3582, August 2003. 498 [3] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating 499 Denial of Service Attacks which employ IP Source Address 500 Spoofing", RFC 2267, January 1998. 502 [4] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 503 Addressing Architecture", RFC 3513, April 2003. 505 [5] Gilligan, R., Thomson, S., Bound, J., McCann, J. and W. Stevens, 506 "Basic Socket Interface Extensions for IPv6", RFC 3493, March 507 2003. 509 Authors' Addresses 511 Christian Huitema 512 Microsoft Corporation 513 One Microsoft Way 514 Redmond, WA 98052-6399 515 USA 517 Phone: 518 EMail: huitema@microsoft.com 519 URI: 521 Richard Draves 522 Microsoft Corporation 523 One Microsoft Way 524 Redmond, WA 98052-6399 525 USA 527 Phone: 528 EMail: richdr@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 (2004). 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.