idnits 2.17.1 draft-chown-v6ops-vlan-usage-02.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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 496. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 473. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 480. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 486. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 502), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 11 longer pages, the longest (page 8) being 68 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 12 pages 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.) ** There are 5 instances of too long lines in the document, the longest one being 17 characters in excess of 72. 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 25, 2004) is 7123 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 informational reference (is this intentional?): RFC 2461 (ref. '1') (Obsoleted by RFC 4861) == Outdated reference: A later version (-03) exists of draft-chown-v6ops-campus-transition-00 == Outdated reference: A later version (-24) exists of draft-ietf-ngtrans-isatap-22 Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations T. Chown 3 Internet-Draft University of Southampton 4 Expires: April 25, 2005 October 25, 2004 6 Use of VLANs for IPv4-IPv6 Coexistence in Enterprise Networks 7 draft-chown-v6ops-vlan-usage-02 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 25, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 Ethernet VLANs are quite commonly used in enterprise networks for the 41 purposes of traffic segregation. This document describes how such 42 VLANs can be readily used to deploy IPv6 networking in an enterprise, 43 which focuses on the scenario of early deployment prior to 44 availability of IPv6-capable switch-router equipment. In this method 45 IPv6 may be routed in parallel with the existing IPv4 in the 46 enterprise and delivered at Layer 2 via VLAN technology. The IPv6 47 connectivity to the enterprise may or may not enter the site via the 48 same physical link. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Enabling IPv6 per link . . . . . . . . . . . . . . . . . . . . 4 54 2.1 IPv6 routing over VLANs . . . . . . . . . . . . . . . . . 4 55 2.2 One VLAN per router interface . . . . . . . . . . . . . . 5 56 2.3 Collapsed VLANs on a single interface . . . . . . . . . . 5 57 2.4 Congruent IPv4 and IPv6 Subnets . . . . . . . . . . . . . 5 58 2.5 IPv6 Addressing . . . . . . . . . . . . . . . . . . . . . 6 59 2.6 Final IPv6 Deployment . . . . . . . . . . . . . . . . . . 6 60 3. Example VLAN topology . . . . . . . . . . . . . . . . . . . . 7 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 63 6. Informative References . . . . . . . . . . . . . . . . . . . . 8 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 65 A. Appendix: Configuration example . . . . . . . . . . . . . . . 9 66 Intellectual Property and Copyright Statements . . . . . . . . 12 68 1. Introduction 70 Ethernet VLANs are quite commonly used in enterprise networks for the 71 purposes of traffic segregation. This document describes how such 72 VLANs can be readily used to deploy IPv6 networking in an enterprise, 73 including the scenario of early deployment prior to availability of 74 IPv6-capable switch-router equipment, where IPv6 may be routed in 75 parallel with the existing IPv4 in the enterprise and delivered to 76 the desired LANs via VLAN technology. 78 It is expected that in the long run, sites migrating to dual-stack 79 networking will either upgrade existing switch-router equipment to 80 support IPv6 or procure new equipment that supports IPv6. If a site 81 already has production routers deployed that support IPv6, the 82 procedures described in this document are not required. In the 83 interim however, a method is required for early IPv6 adopters that 84 enables IPv6 to be deployed in a structured, managed way to some or 85 all of an enterprise network which currently lacks IPv6 support in 86 its core infrastructure. 88 The IEEE 802.1Q VLAN standard allows separate LANs to be deployed 89 over a single bridged LAN, by inserting "Virtual LAN" tagging or 90 membership information into Ethernet frames. Hosts and switches that 91 support VLANs effectively allow software-based reconfiguration of 92 LANs through configuration of the tagging parameters. The software 93 control means VLANs can be used to alter the LAN infrastructure 94 without having to physically alter the wiring between the LAN 95 segments and Layer 3 routers. 97 Many IPv4 enterprise networks are utilising VLAN technology. Where a 98 site does not have IPv6-capable Layer 2/3 switch-router equipment, 99 but VLANs are supported, a simple yet effective method exists to 100 gradually introduce IPv6 to some or all of that site's network, in 101 advance of the site's core infrastructure having dual-stack 102 capability. 104 If such a site wishes to introduce IPv6, it may do so by deploying a 105 parallel IPv6 routing infrastructure (which is likely to be a 106 different platform to the site's main infrastructure equipment, i.e. 107 one that supports IPv6 where the existing equipment does not), and 108 then using VLAN technology to "overlay" IPv6 links onto existing IPv4 109 links. This can be achieved without needing any changes to the IPv4 110 configuration. The VLANs don't need to differentiate between IPv4 111 and IPv6; the deployment is just dual stack, as Ethernet is without 112 VLANs. 114 The IPv4 default route to the VLAN is provided by one (IPv4) router, 115 while the IPv6 default route to the VLAN is provided a different 116 (IPv6) router. The IPv6 router can provide native IPv6 connectivity 117 to the whole site with just a single physical interface, thanks to 118 VLAN tagging and trunking, as described below. 120 The IPv6 connectivity to the enterprise may or may not enter the site 121 via the same physical link as the IPv4 traffic, and may be native or 122 tunneled from the external provider to the IPv6 routing equipment. 124 This VLAN usage is a solution adopted by a number of sites already, 125 and is referenced in our Campus Network IPv6 Transition [2] text. 127 It should be noted that a parallel infrastructure will require 128 additional infrastructure and thus cost, and will often require a 129 separate link into the site (from an IPv6 provider), quite possibly 130 tunneled, that will require the site's security policy to be applied 131 (e.g. firewalling, and intrusion detection). For sites who believe 132 early adoption of IPv6 is important, that price is one they may be 133 quite willing to pay. However, this document focuses on the 134 technical issues of VLAN usage in such a scenario. 136 2. Enabling IPv6 per link 138 The precise method by which IPv6 would be "injected" into the 139 existing IPv4 network is deployment specific. For example, perhaps a 140 site has an IPv4-only router, connected to an Ethernet switch that 141 supports VLANs, and a number of hosts connected to that VLAN. Let's 142 further assume the site has a dozen of these setups which it wishes 143 to IPv6-enable immediately. This could be done by upgrading the 144 twelve routers to support IPv6, and turning IPv6 on on those routers. 145 However, this may not be practical for various reasons. 147 The simplest approach would be to connect an IPv6 router with one 148 interface to an ethernet switch, and connect that switch to other 149 switches, and then use VLAN tags between the switches and the IPv6 150 router to "reach" all the IPv4-only subnets from the IPv6 router. 151 Thus the general principle is that the IPv6 router device (e.g. 152 performing IPv6 Router Advertisements [1] in the case of stateless 153 autoconfiguration) is connected to the target link through the use of 154 VLAN capable Layer 2 equipment. 156 2.1 IPv6 routing over VLANs 158 In a typical scenario where connectivity is to be offered to a number 159 of existing IPv6 internal subnets, one IPv6 router could be deployed, 160 with both an external interface and one or more internal interfaces. 161 The external interface connects to the wider IPv6 internet, and may 162 be dual-stack if some tunnel mechanism is used for external 163 connectivity, or IPv6-only if a native external connection is 164 available. 166 The internal interface(s) can be connected directly to a VLAN-capable 167 switch. It is then possible to write VLAN tags on the packets sent 168 from the internal router interface based on the target IPv6 link 169 prefix. The VLAN-tagged traffic is then transported across the 170 internal VLAN-capable site infrastructure to the target IPv6 links 171 (which may be dispersed widely across the site network). 173 Where the IPv6 router is unable to VLAN-tag the packets, a 174 protocol-based VLAN can be created on the VLAN-capable device 175 connected to the IPv6 router, causing IPv6 traffic to be tagged and 176 then redistributed on (congruent) IPv4 subnet links that lie in the 177 same VLAN. 179 2.2 One VLAN per router interface 181 The VLAN marking may be done in different ways. Some sites may 182 prefer to use one router interface per VLAN, e.g. if there are three 183 internal IPv6 links, a BSD-based IPv6 router with four Ethernet ports 184 could be used, one for the external link and three for the internal 185 links. In such a case one switch port would be needed per link, to 186 receive the connectivity from each router port. 188 In such a deployment, the IPv6 routing could be cascaded through 189 lower tier internal IPv6-only routers. Here, the internal facing 190 ports on the IPv6 edge router may feed other IPv6 routers over 191 IPv6-only links which in turn inject the IPv6 connectivity (the /64 192 size links and associated Router Advertisements) into the VLANs. 194 2.3 Collapsed VLANs on a single interface 196 Using multiple IPv6 routers and one port per IPv6 link (i.e. VLAN) 197 may be unnecessary. Many devices now support VLAN tagging based on 198 virtual interfaces such that multiple IPv6 VLANs could be assigned 199 (trunked) from one physical router interface port. Thus it is 200 possible to use just one router interface for "aggregated" VLAN 201 trunking from a switch. This is a far more interesting case for a 202 site planning the introduction of IPv6 to (part of) its site network. 204 This approach is viable while IPv6 traffic load is light. As traffic 205 volume grows, the single collapsed interface could be extended to 206 utilise two or more physical ports, where the capacity of the IPv6 207 router device allows it. 209 2.4 Congruent IPv4 and IPv6 Subnets 211 Such a VLAN-based technique can be used to deploy IPv6-only VLANs in 212 an enterprise network. However most enterprises will be interested 213 in dual-stack IPv4-IPv6 networking. 215 In such a case the IPv6 connectivity may be injected into the 216 existing IPv4 VLANs, such that the IPv4 and IPv6 subnets are 217 congruent (i.e. they coincide exactly when superimposed). Such a 218 method may have desirable administrative properties, e.g. the 219 devices in each IPv4 subnet will be in the same IPv6 subnets also. 220 This is the method being used in our Campus Network IPv6 Transition 221 [2] text. 223 Further, IPv6-only devices may be gradually added into the subnet 224 without any need to resize the IPv6 subnet (which may hold in effect 225 an infinite number of hosts in a /64 in contrast to IPv4 where the 226 subnet size is often relatively limited, or kept to a minimum 227 possible due to address space usage concerns). The lack of 228 requirement to periodically resize an IPv6 subnet is a useful 229 administrative advantage for IPv6. 231 2.5 IPv6 Addressing 233 One site using this VLAN technique has chosen to number its IPv6 234 links with the format [Site IPv6 prefix]:[VLAN ID]::/64. This is not 235 a recommended addressing plan, but some sites may wish to consider 236 its usage. 238 2.6 Final IPv6 Deployment 240 The VLAN technique for IPv6 deployment offers a more structured 241 alternative to opportunistic per-host intra-site tunnelling methods 242 such as ISATAP [3]. It has the ability to offer a simple yet 243 efficient method for early IPv6 deployment to an enterprise site. 245 When the site acquires IPv6-capable switch-router equipment, the 246 VLAN-based mathod can still be used for delivery of IPv6 links to 247 physical switch interfaces, just as it is commonly today for IPv4 248 subnets, but with a common routing infrastructure. 250 3. Example VLAN topology 252 The following figure shows how a VLAN topology may be used to 253 introduce IPv6 in an enterprise network, using a parallel IPv6 254 routing infrastructure and VLAN tagging. 256 External IPv6 Internet 257 | 258 | 259 IPv6 Access Router 260 | 261 | 262 Switch-router with VLAN support 263 | 264 | 265 +--------------+----------------+ 266 |Site enterprise infrastructure | 267 | with support for VLANs | 268 +----+--------------------+-----+ 269 | | 270 | | 271 VLAN switch A VLAN switch B 272 | | | 273 | | | 274 Subnet1 Subnet2 Subnet3 276 Figure 1: IPv6 deployment using VLANs (physical diagram) 278 In this scenario, the IPv6 access router has one physical port facing 279 towards the internal infrastructure. In this example it need only be 280 IPv6-enabled, as its purpose is solely to handle IPv6 traffic for the 281 enterprise. The access router has an additional interface facing 282 towards the external infrastructure, which in this example could be 283 dual-stack if the external IPv6 connectivity is via a tunnel to an 284 IPv6 ISP. 286 A number of VLANs are handled by the internal-facing IPv6 router 287 port; in this case IPv6 links Subnet1, Subnet2, Subnet3. The VLANs 288 are seen as logical subinterfaces of the physical interface on the 289 IPv6 access router, which is using the "collapsed VLAN" method 290 described above, tagging the inbound traffic with one of three VLAN 291 IDs depending on the target IPv6 Subnet prefix. 293 The following figure shows how the IPv6 view of the deployment looks; 294 all IPv6 subnets are on-link to the IPv6 access router, whether they 295 share the same physical links over the VLAN infrastructure or not. 297 External IPv6 Internet 298 | 299 | 300 Site IPv6 Access Router 301 | | | 302 | | | 303 Subnet1 Subnet2 Subnet3 305 Figure 2: IPv6 view of the deployment (logical view) 307 In this example, the router acts as an IPv6 first-hop access router 308 to the physical links, separately from the IPv4-first hop router. 309 This technique allows a site to easily "inject" native IPv6 into all 310 the links where a VLAN-capable infrastructure is available, enabling 311 partial or full IPv6 deployment on the wire in a site. 313 4. Security Considerations 315 There are no additional security considerations particular to this 316 method of enabling IPv6 on a link. 318 Where the IPv6 connectivity is delivered into the enterprise network 319 by a different path from the IPv4 connectivity, care should be given 320 that equivalent application of security policy (e.g. firewalling) is 321 made to the IPv6 path. 323 5. Acknowledgements 325 The author would like to thank colleagues on the 6NET project, where 326 this technique for IPv4-IPv6 coexistence is widely deployed, in 327 particular Pekka Savola (CSC/FUNET), but also including Janos Mohacsi 328 (Hungarnet), Martin Dunmore and Chris Edwards (Lancaster University), 329 Christian Strauf (JOIN Project, University of Muenster) and Stig 330 Venaas (UNINETT). 332 6 Informative References 334 [1] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 335 IP Version 6 (IPv6)", RFC 2461, December 1998. 337 [2] Chown, T., "IPv6 Campus Transition Scenario Description and 338 Analysis", draft-chown-v6ops-campus-transition-00 (work in 339 progress), July 2004. 341 [3] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, "Intra-Site 342 Automatic Tunnel Addressing Protocol (ISATAP)", 343 draft-ietf-ngtrans-isatap-22 (work in progress), May 2004. 345 Author's Address 347 Tim Chown 348 University of Southampton 350 Southampton, Hampshire SO17 1BJ 351 United Kingdom 353 EMail: tjc@ecs.soton.ac.uk 355 Appendix A. Appendix: Configuration example 357 In this section we describe a configuration example for BSD to deploy 358 IPv6 networking across a number of IPv6 links on an enterprise (in 359 this case, eight links), for a scenario similar to the one described 360 above. Here the precise configuration may of course vary depending 361 on the existing site VLAN deployment. This section highlights that 362 the VLAN configuration must be manually configured; the support is 363 not "automatic". 365 In this example, the configuration is for an IPv6 BSD router 366 connected directly to a site's external IPv6 access router. The BSD 367 router has one interface (dc0) towards the site IPv6access router, 368 and three interfaces (dc1, dc2, dc3) over which the internal routing 369 is performed (the number of interfaces can be varied, three are used 370 here to distribute the traffic load). The IPv6 documentation prefix 371 (2001:db8::/32) is used in the example. 373 --- Example IPv6 VLAN configuration, FreeBSD --- 375 # 376 # To IPv6 enable a vlan 377 # 378 # 1. Add a new vlan device to cloned_interfaces called vlanX 379 # 380 # 2. Add an ifconfig_vlanX line, the number in quotes is the vlan tag ID 381 # 382 # 3. Add vlanX to ipv6_network_interfaces 383 # 384 # 4. Add an ipv6_ifconfig_vlanX line, with a new unique prefix 385 # 386 # 5. Add vlanX to rtadvd_interface 387 # 388 # 6. Add vlanX to ipv6_router_flags 390 ### Interfaces ### 392 # Bring physical interfaces up 393 ifconfig_dc0="up" 394 ifconfig_dc1="up" 395 ifconfig_dc2="up" 396 ifconfig_dc3="up" 398 # Create VLan interfaces 399 cloned_interfaces="vlan0 vlan1 vlan2 vlan3 vlan4 vlan5 vlan6 vlan7 vlan8" 401 # Upstream link to IPv6 Access Router 402 ifconfig_vlan0="vlan 37 vlandev dc0" 404 # Downstream interfaces, load balance over interfaces dc1,dc2,dc3 405 ifconfig_vlan1="vlan 11 vlandev dc1" # Subnet1 406 ifconfig_vlan2="vlan 17 vlandev dc2" # Subnet2 407 ifconfig_vlan3="vlan 24 vlandev dc3" # Subnet3 408 ifconfig_vlan4="vlan 25 vlandev dc1" # Subnet4 409 ifconfig_vlan5="vlan 34 vlandev dc2" # Subnet5 410 ifconfig_vlan6="vlan 14 vlandev dc3" # Subnet6 411 ifconfig_vlan7="vlan 19 vlandev dc1" # Subnet7 412 ifconfig_vlan8="vlan 13 vlandev dc2" # Subnet8 414 ### IPv6 ### 416 # Enable ipv6 417 ipv6_enable="YES" 419 # Forwarding 420 ipv6_gateway_enable="YES" 422 # Define Interfaces 423 ipv6_network_interfaces="vlan0 vlan1 vlan2 vlan3 vlan4 vlan5 vlan6 vlan7 vlan8" 424 # Define addresses 425 ipv6_ifconfig_vlan0="2001:db8:d0:101::2 prefixlen 64" # Uplink 426 ipv6_ifconfig_vlan1="2001:db8:d0:111::1 prefixlen 64" # Subnet1 427 ipv6_ifconfig_vlan2="2001:db8:d0:112::1 prefixlen 64" # Subnet2 428 ipv6_ifconfig_vlan3="2001:db8:d0:121::1 prefixlen 64" # Subnet3 429 ipv6_ifconfig_vlan4="2001:db8:d0:113::1 prefixlen 64" # Subnet4 430 ipv6_ifconfig_vlan5="2001:db8:d0:114::1 prefixlen 64" # Subnet5 431 ipv6_ifconfig_vlan6="2001:db8:d0:115::1 prefixlen 64" # Subnet6 432 ipv6_ifconfig_vlan7="2001:db8:d0:116::1 prefixlen 64" # Subnet7 433 ipv6_ifconfig_vlan8="2001:db8:d0:117::1 prefixlen 64" # Subnet8 435 # Router advs 436 rtadvd_enable="YES" 437 rtadvd_interfaces="-s vlan0 vlan1 vlan2 vlan3 vlan4 vlan5 vlan6 vlan7 vlan8" 439 ### Routing ### 441 # Multicast 442 mroute6d_enable="YES" 443 mroute6d_program="/sbin/pim6sd" 445 # RIP-ng 446 ipv6_router_enable="YES" 447 ipv6_router_flags="-N dc0,dc1,dc2,dc3,vlan1,vlan2,vlan3,vlan4,vlan5,vlan6,vlan7,vlan8" 449 --- End of configuration --- 451 Note that if there was only one internal facing interface, then again 452 so long as the OS supported VLAN trunking, all the VLAN IDs could be 453 associated to that interface (dc1, for example). 455 The VLAN IDs need to be managed by the site administrator, but would 456 probably already be assigned for existing IPv4 subnets (ones into 457 which IPv6 is being introduced). 459 For a large enterprise, a combination of internal tunnels and VLAN 460 usage could be used; the whole site need not be enabled by VLAN 461 tagging alone. This choice is one for the site administrator to 462 make. 464 Intellectual Property Statement 466 The IETF takes no position regarding the validity or scope of any 467 Intellectual Property Rights or other rights that might be claimed to 468 pertain to the implementation or use of the technology described in 469 this document or the extent to which any license under such rights 470 might or might not be available; nor does it represent that it has 471 made any independent effort to identify any such rights. Information 472 on the procedures with respect to rights in RFC documents can be 473 found in BCP 78 and BCP 79. 475 Copies of IPR disclosures made to the IETF Secretariat and any 476 assurances of licenses to be made available, or the result of an 477 attempt made to obtain a general license or permission for the use of 478 such proprietary rights by implementers or users of this 479 specification can be obtained from the IETF on-line IPR repository at 480 http://www.ietf.org/ipr. 482 The IETF invites any interested party to bring to its attention any 483 copyrights, patents or patent applications, or other proprietary 484 rights that may cover technology that may be required to implement 485 this standard. Please address the information to the IETF at 486 ietf-ipr@ietf.org. 488 Disclaimer of Validity 490 This document and the information contained herein are provided on an 491 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 492 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 493 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 494 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 495 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 496 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 498 Copyright Statement 500 Copyright (C) The Internet Society (2004). This document is subject 501 to the rights, licenses and restrictions contained in BCP 78, and 502 except as set forth therein, the authors retain all their rights. 504 Acknowledgment 506 Funding for the RFC Editor function is currently provided by the 507 Internet Society.