idnits 2.17.1 draft-sanjib-private-vlan-10.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 572. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 542. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 549. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 555. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (August 2008) is 5704 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force S. HomChaudhuri 2 Internet Draft M. Foschiano 3 Category: Informational Cisco Systems 4 Expires: February 2009 August 2008 6 Cisco Systems' Private VLANs: 7 Scalable Security in a Multi-Client Environment 8 draft-sanjib-private-vlan-10.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 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 Copyright Notice 34 Copyright (C) The IETF Trust (2008). 36 Abstract 38 This document describes a mechanism to achieve device isolation 39 through the application of special Layer 2 forwarding constraints. 40 Such mechanism allows end devices to share the same IP subnet while 41 being Layer 2 isolated, which in turn allows network designers to 42 employ larger subnets and so reduce the address management overhead. 44 Some of the numerous deployment scenarios of the aforementioned 45 mechanism (which range from data center designs to Ethernet-to-the- 46 home basement networks) are mentioned in the following to exemplify 47 its possible usages; however, this document is not intended to cover 48 all such deployment scenarios nor delve into their details. 50 Table of Contents 52 1. Introduction................................................4 53 1.1 Security Concerns with Sharing a VLAN.....................4 54 1.2 The Traditional Solution and its Related Problems.........5 55 2. Private VLANs Architecture..................................5 56 2.1 VLAN Pairings and Their Port-related Characteristics......9 57 3. Extending Private VLANs across Switches....................10 58 4. A More Flexible IP Addressing Scheme.......................11 59 5. Routing Considerations.....................................12 60 Security Considerations.........................................12 61 IANA Considerations.............................................13 62 Changes from the Previous Version...............................13 63 Acknowledgements................................................13 64 Normative References ...........................................13 65 Informative References..........................................13 66 Authors' Addresses..............................................14 67 IPR Notice......................................................14 68 Full Copyright Notice...........................................15 70 1. Introduction 72 In an Ethernet switch a VLAN is a broadcast domain, in which hosts 73 can establish direct communication with one another at Layer 2. If 74 untrusted devices are introduced into a VLAN, security issues may 75 arise because trusted and untrusted devices end up sharing the same 76 broadcast domain. 78 The traditional solution to this kind of problem is to assign a 79 separate VLAN to each user concerned about Layer 2 security issues. 80 However, the IEEE 802.1Q standard [802.1Q] specifies that the VLAN 81 ID field in an Ethernet frame is 12 bits wide. That allows for a 82 theoretical maximum of 4094 VLANs in an Ethernet network (VLAN 83 numbers 0 and 4095 are reserved). If the network administrator 84 assigns one VLAN per user, then that equates to a maximum of 4094 85 users that can be supported. The private VLANs technology described 86 in this memo addresses this scalability problem by offering more 87 granular and more flexible Layer 2 segregation, as explained in the 88 following sections. 90 1.1 Security Concerns with Sharing a VLAN 92 Companies who have Internet presence can either host their servers 93 in their own premises or, alternatively, they can locate their 94 servers at the Internet Service Provider's premises. A typical ISP 95 would have a server farm that offers web hosting functionality for a 96 number of customers. Co-locating the servers in a server farm 97 offers ease of management but at the same time may raise security 98 concerns. 100 Let us assume that the ISP puts all the servers in one big VLAN. 101 Servers residing in the same VLAN can listen to Layer 2 broadcasts 102 from other servers. Once a server learns the MAC address associated 103 to the IP address of another computer in the same VLAN, it can 104 establish direct Layer 2 communication with that device without 105 having to go through a Layer 3 gateway/firewall. If for example an 106 attacker gets access to one of the servers, he or she can use that 107 compromised host to launch an attack on other servers in the server 108 farm. To protect themselves from malicious attacks, ISP customers 109 want their machines to be isolated from other machines in the same 110 server farm. 112 The security concerns become even more apparent in metropolitan area 113 networks. Metropolitan Service Providers may want to provide Layer 114 2 Ethernet access to homes, rental communities, businesses, etc. In 115 this scenario, the subscriber next door could very well be a 116 malicious network user. 118 It is therefore very important to offer Layer 2 traffic isolation 119 among customers. Customer A would not want his Layer 2 frames being 120 broadcast to customer B, who happens to be in the same VLAN. Also, 121 customer A would not want customer B to bypass a router or a 122 firewall and establish direct Layer 2 communication with him/her. 124 1.2 The Traditional Solution and its Related Problems 126 The traditional solution would be to assign a separate VLAN to each 127 customer. That way, each user would be assured of Layer 2 isolation 128 from devices belonging to other users. 130 However, with the VLAN-per-customer model if for instance an ISP 131 wanted to offer web-hosting services to, say, 4000 customers it 132 would consume 4000 VLANs. Theoretically, the maximum number of 133 VLANs that an 802.1Q-compliant networking device can support is 4094. 134 In reality, many devices support a much lesser number of active 135 VLANs. Even if all devices supported all 4094 VLANs, there would 136 still be a scalability problem when the 4095th customer signed up. 138 A second problem with assigning a separate VLAN per customer is 139 management of IP addresses. Since each VLAN requires a separate 140 subnet, there can be potential wastage of IP addresses in each 141 subnet. This issue has been described by RFC 3069 [RFC3069] and 142 will not be discussed in detail in this document. 144 2. Private VLANs Architecture 146 The private VLANs architecture is similar but more elaborate than 147 the aggregated VLAN model proposed in RFC 3069. The concepts of 148 'super VLAN' and 'sub VLAN' used in that RFC are functionally 149 similar to the concepts of 'primary VLAN' and 'secondary VLAN' used 150 in this document. 152 On the other hand, the private VLANs technology differs from the 153 mechanism described in [RFC4562] because instead of using a MAC- 154 address-based 'forced forwarding' scheme it uses a VLAN-based one. 156 A regular VLAN is a single broadcast domain. The private VLAN 157 technology partitions a larger VLAN broadcast domain into smaller 158 sub-domains. So far two kinds of special sub-domains specific to 159 the private VLAN technology have been defined: an 'isolated' sub- 160 domain and a 'community' sub-domain. Each sub-domain is defined by 161 assigning a proper designation to a group of switch ports. 163 Within a private VLAN domain three separate port designations exist. 164 Each port designation has its own unique set of rules which regulate 165 a connected endpoint's ability to communicate with other connected 166 endpoints within the same private VLAN domain. The three port 167 designations are: promiscuous, isolated, and community. 169 An endpoint connected to a promiscuous port has the ability to 170 communicate with any endpoint within the private VLAN. Multiple 171 promiscuous ports may be defined within a single private VLAN domain. 172 In most networks, Layer 3 default gateways or network management 173 stations are commonly connected to promiscuous ports. 175 Isolated ports are typically used for those endpoints that only 176 require access to a limited number of outgoing interfaces on a 177 private-VLAN-enabled device. An endpoint connected to an isolated 178 port will only possess the ability to communicate with those 179 endpoints connected to promiscuous ports. Endpoints connected to 180 adjacent isolated ports cannot communicate with one another. For 181 example, within a web hosting environment, isolated ports can be 182 used to connect hosts that require access only to default gateways. 184 A community port is a port that is part of a private VLAN community, 185 which is a grouping of ports connected to devices belonging to the 186 same entity (for example, a group of hosts of the same ISP customer 187 or a pool of servers in a data center). Within a community, 188 endpoints can communicate with one another and can also communicate 189 with any configured promiscuous port. Endpoints belonging to one 190 community cannot instead communicate with endpoints belonging to a 191 different community or with endpoints connected to isolated ports. 193 The aforementioned three port designations directly correspond to 194 three different VLAN types (primary, isolated and community VLAN 195 types) with well-defined port-related characteristics, which are 196 described in detail in section 2.1 below. 198 Figure 1 below illustrates the private VLAN model from a switch port 199 classification perspective. 201 ----------- 202 | R | 203 ----------- 204 | 205 | 206 | 207 ---------------------------------------- 208 | p1 | 209 | | 210 =====| t1 | 211 | switch | 212 | | 213 | | 214 |i1 i2 c1 c2 | 215 ---------------------------------------- 216 | | | | 217 | | | | 218 | | | | 219 A B C D 221 A, B - Isolated devices 222 C, D - Community devices 223 R - Router (or other L4-L7 device) 224 i1, i2 - Isolated switch ports 225 c1, c2 - Community switch ports 226 p1 - Promiscuous switch port 227 t1 - Inter-switch link port (a VLAN-aware port) 229 Fig 1. Private VLAN classification of switch ports 230 -------------------------------------------------- 232 With reference to Figure 1 each of the port types is described below. 234 Isolated ports: An isolated port, e.g., i1 or i2, cannot talk to any 235 other port in the private VLAN domain except for promiscuous ports 236 (e.g., p1). If a customer device needs to have access only to a 237 gateway router, then it should be attached to an isolated port. 239 Community ports: A community port, e.g., c1 or c2, is part of a 240 group of ports. The ports within a community can have Layer 2 241 communications with one another and can also talk to any promiscuous 242 port. If an ISP customer has, say, 2 devices that he/she wants to 243 be isolated from other customers' devices but to be able to 244 communicate among themselves, then community ports should be used. 246 Promiscuous ports: As the name suggests, a promiscuous port (p1) can 247 talk to all other types of ports. A promiscuous port can talk to 248 isolated ports as well as community ports and vice versa. Layer 3 249 gateways, DHCP servers and other 'trusted' devices that need to 250 communicate with the customer endpoints are typically connected via 251 promiscuous ports. 253 Please note that isolated, community and promiscuous ports can be 254 either access ports or hybrid/trunk ports (according to the 255 terminology presented in Annex D of the IEEE 802.1Q specification up 256 to its 2004 revision). 258 The table below summarizes the communication privileges between the 259 different private VLAN port types. 261 Table 1. 263 --------------------------------------------------------------- 264 | | isolat-| promis-| commu-| commu-| interswitch | 265 | | ted | cuous | nity1 | nity2 | link port | 266 --------------------------------------------------------------- 267 | isolated | deny | permit | deny | deny | permit | 268 --------------------------------------------------------------- 269 | promiscuous | permit | permit | permit| permit| permit | 270 --------------------------------------------------------------- 271 | community1 | deny | permit | permit| deny | permit | 272 --------------------------------------------------------------- 273 | community2 | deny | permit | deny | permit| permit | 274 --------------------------------------------------------------- 275 | interswitch | | | | | | 276 | link port | deny(*)| permit | permit| permit| permit | 277 --------------------------------------------------------------- 279 (*) Please note that this asymmetric behavior is for traffic 280 traversing inter-switch link ports over an isolated VLAN only. 281 Traffic from an inter-switch link port to an isolated port will be 282 denied if it is in the isolated VLAN. Traffic from an inter-switch 283 link port to an isolated port will be permitted if it is in the 284 primary VLAN (see below for the different VLAN characteristics). 286 N.B.: An interswitch link port is simply a regular port that 287 connects two switches (and that happens to carry two or more VLANs). 289 2.1 VLAN Pairings and Their Port-related Characteristics 291 In practice, the Layer-2 communication constraints described in the 292 table above can be enforced by creating sub-domains within the same 293 VLAN domain. However, a sub-domain within a VLAN domain cannot be 294 easily implemented with only one VLAN ID. Instead, a mechanism of 295 pairing of VLAN IDs can be used to achieve this notion. 296 Specifically, sub-domains can be represented by pairs of VLAN 297 numbers: 299 Vp is the primary VLAN ID ------ 300 Vs is the secondary VLAN ID | Vp | 301 ------ 302 where Vs can be: / \ 303 - Vi (an isolated VLAN) / \ 304 - Vc (a community VLAN) / \ 305 ------ ------ 306 | Vi | | Vc | 307 ------ ------ 308 310 Fig 2. A private VLAN domain can be implemented with one 311 or more VLAN ID pairs 312 --------------------------------------------------------- 314 A private VLAN domain is built with at least one pair of VLAN IDs: 315 one (and only one) primary VLAN ID (Vp) plus one or more secondary 316 VLAN IDs (Vs). Secondary VLANs can be of two types: isolated VLANs 317 (Vi) or community VLANs (Vc). 319 A primary VLAN is the unique and common VLAN identifier of the whole 320 Private VLAN domain and of all its VLAN ID pairs. 322 An isolated VLAN is a secondary VLAN whose distinctive 323 characteristic is that all hosts connected to its ports are isolated 324 at Layer 2. Therefore, its primary quality is that it allows a 325 design based on Private VLANs to use a total of only two VLAN 326 identifiers (i.e., a single Private VLAN pairing) to provide port 327 isolation and serve any number of end users (vs. a traditional 328 design in which one separate plain VLAN ID would be assigned to each 329 port). 331 A community VLAN is a secondary VLAN that is associated to a group 332 of ports that connects to a certain "community" of end devices with 333 mutual trust relationships. 335 While only one isolated VLAN is allowed in a private VLAN domain, 336 there can be multiple distinct community VLANs. 338 Please note that this VLAN pairing scheme simply requires that all 339 traffic transported within primary and secondary VLANs be tagged 340 according to the IEEE 802.1Q standard (see for example [802.1Q] 341 section B.1.3), with at most a single standard VLAN tag. No special 342 double-tagging is necessary due to the 1:1 correspondence between a 343 secondary VLAN and its associated primary VLAN. 345 (Also note that this document makes use of the "traditional" VLAN 346 terminology whereas the IEEE 802.1ag standard [802.1ag] amends key 347 sections of IEEE 802.1Q-2005 to make the distinction between "VLANs" 348 and "VLAN IDs" so that every "VLAN" can be assigned one or more VLAN 349 IDs, similarly to the pairing scheme described in this document.) 351 The ports in a private VLAN domain derive their special 352 characteristics (as described in section 2) from the VLAN pairing(s) 353 they are configured with. In particular, a promiscuous port is a 354 port that can communicate with all other Private VLAN port types via 355 the primary VLAN and any associated secondary VLAN, whereas isolated 356 or community ports can communicate over their respective secondary 357 VLANs only. 359 For example, with reference to Figure 1, a router R connected to the 360 promiscuous port can have Layer 2 communication with a device A 361 connected to an isolated port and also with a device C connected to 362 a community port. Devices C and D can also have Layer 2 363 communication between themselves, since they are part of the same 364 community VLAN. However, devices A and B cannot communicate at 365 Layer 2 due to the special port segregation property of the isolated 366 VLAN. Also, devices A and C cannot communicate at Layer 2 since 367 they belong to different secondary VLANs. 369 The impact of these enforced forwarding restrictions is two-fold. 370 Firstly, service providers can assign multiple customers to the same 371 isolated VLAN, thereby conserving VLAN IDs. Secondly, end users can 372 be assured that their Layer 2 traffic cannot be sniffed by other end 373 users sharing the same isolated VLAN or connected to a different 374 secondary VLAN. 376 3. Extending Private VLANs across Switches 378 Some switch vendors have attempted to provide a port isolation 379 feature within a VLAN by implementing special logic at the port 380 level. However, when implemented at the port level, the isolation 381 behavior is restricted to a single switch. 383 When a VLAN spans multiple switches, there is no standard mechanism 384 to propagate port-level isolation information to other switches and, 385 consequently, the isolation behavior fails in other switches. 387 In this document, the proposal is to implement the port isolation 388 information implicitly at the VLAN level. A particular VLAN ID can 389 be configured to be the isolated VLAN. All switches in the network 390 would give special "isolated VLAN" treatment to frames tagged with 391 this particular VLAN ID. Thereby, the isolated VLAN behavior can be 392 maintained consistently across all switches in a Layer 2 network. 394 In general, isolated, community and primary VLANs can all span 395 multiple switches, just like regular VLANs. Inter-switch link ports 396 need not be aware of the special VLAN type and will carry frames 397 tagged with these VLANs just like they do any other frames. 399 One of the objectives of the private VLAN architecture is to ensure 400 that traffic from an isolated port in one switch does not reach 401 another isolated or community port in a different switch even after 402 traversing an inter-switch link. By implicitly embedding the 403 isolation information at the VLAN level and by transporting it along 404 with the packet, it is possible to maintain a consistent behavior 405 throughout the network. Therefore, the mechanism discussed in 406 section 2, which will restrict Layer 2 communication between two 407 isolated ports in the same switch, will also restrict Layer 2 408 communication between two isolated ports in two different switches. 410 4. A More Flexible IP Addressing Scheme 412 The common practice of deploying multiple VLANs in a network for 413 security reasons and of allocating a subnet to each VLAN has led to 414 a certain number of inefficiencies in network designs, such as the 415 suboptimal utilization of the IP addressing space (as exemplified 416 in the introduction of RFC 3069 [RFC3069]). Moreover, each subnet 417 requires addresses to be set aside for internetworking purposes (a 418 subnetwork address, a directed broadcast address, default gateway 419 address(es), etc.). So a high number of used VLANs traditionally 420 translates into a significant number of special addresses to be 421 consumed. 423 On the other hand, in a private VLAN domain all members can share a 424 common address space which is part of a single subnet associated to 425 the primary VLAN. An end device can be assigned an IP address 426 statically or by using a DHCP server connected to a promiscuous port. 427 Since IP addresses are no longer allocated on a smaller subnet basis 428 but are assigned from a larger address pool shared by all members in 429 the private VLAN domain, address allocation becomes much more 430 efficient: fewer addresses are consumed for internetworking purposes 431 while most of the address space is allotted to end devices, leaving 432 ample flexibility in the way available addresses are (re-)assigned. 434 5. Routing Considerations 436 The entire private VLAN architecture confines secondary VLANs within 437 the 2nd layer of the OSI model. With reference to Figure 2, the 438 secondary VLANs are internal to a private VLAN domain. Layer 3 439 entities are not directly aware of their existence: to them it 440 appears as if all the end devices are part of the primary VLAN. 442 With reference to Figure 1, the isolation behavior between devices A 443 and B is at the Layer 2 level only. Devices A and B can still 444 communicate at the layer 3 level via the router R. Since A and B 445 are part of the same subnet, the router assumes that they should be 446 able to talk directly to each other. That however is prevented by 447 the isolated VLAN's specific behavior. So, in order to enable A and 448 B to communicate via the router, a proxy-ARP-like functionality 449 needs to be supported on the router interface. 451 With regard to the specific version of the IP protocol in use, all 452 routing considerations apply to both IPv4 and IPv6 for the case of 453 unicast traffic. On the other hand, due to their complexity, 454 considerations about multicast bridging and routing within a Private 455 VLAN domain transcend the scope of this introductory document, and 456 are therefore omitted. 458 Security Considerations 460 In a heterogeneous Layer 2 network that is built with switches from 461 multiple vendors, the private VLANs feature should be supported and 462 configured on all the switches. If a switch S in that network does 463 not support this feature, then there may be undesired forwarding of 464 packets including permanent flooding of Layer 2 unicast frames. 465 That is because switch S is not aware of the association between 466 primary and secondary VLANs and consequently cannot apply the 467 segregation rules and constraints characteristic of the private VLAN 468 architecture (an example of one such constraint is explained in 469 [802.1Q] section B.1.3). This impact is limited to traffic within 470 the private VLAN domain and will not affect the regular Layer 2 471 forwarding behavior on other VLANs. 473 If the private VLANs feature is properly deployed, it can be used to 474 segregate at Layer 2 individual users or groups of users from each 475 other: this segregation allows a network designer to more 476 effectively constrain Layer 2 forwarding so as to, for instance, 477 block or contain unwanted inter-device communication like port scans 478 or ARP poisoning attacks. 480 IANA Considerations 482 This document has no actions for IANA. 484 Changes from the Previous Version 486 This version incorporates edits derived from comments received 487 during the IESG review process. 489 Acknowledgements 491 Many people have contributed to the Private VLANs architecture. We 492 would particularly like to thank, in alphabetical order, Senthil 493 Arunachalam, Jason Chen, Tom Edsall, Michael Fine, Herman Hou, 494 Milind Kulkarni, Kannan Kothandaraman, Prasanna Parthasarathy, Heng- 495 Hsin Liao, Tom Nosella, Ramesh Santhanakrishnan, Mukundan Sudarsan, 496 Charley Wen and Zhong Xu for their significant contributions. 498 Normative References 500 [802.1Q] Institute of Electrical and Electronics Engineers, "IEEE 501 Std 802.1Q 2005 Edition, Virtual Bridged Local Area 502 Networks", IEEE Standard 802.1Q, 2005 Edition, May 2006 504 [802.1ag] Institute of Electrical and Electronics Engineers, "IEEE 505 Std 802.1ag 2007 Edition, Connectivity Fault Management", 506 IEEE Standard 802.1ag, 2007 Edition, December 2007 508 Informative References 510 [RFC3069] McPherson, D. and B. Dykes, "VLAN Aggregation for 511 Efficient IP Address Allocation", RFC 3069, February 2001 513 [RFC4562] Melsen, T and Blake S., "MAC-Forced Forwarding: A Method 514 for Subscriber Separation on an Ethernet Access Network", 515 RFC 4562, June 2006 517 Authors' Addresses 519 Marco Foschiano 520 Cisco Systems, Inc. 521 Via Torri Bianche 7, Vimercate, MI, 20059, Italy 522 Email address: foschia@cisco.com 523 Alternate email address: mfoschiano@gmail.com 525 Sanjib HomChaudhuri 526 Email address: sanjibhc@gmail.com 528 IPR Notice 530 The IETF has been notified of intellectual property rights claimed 531 in regard to some or all of the specification contained in this 532 document. For more information consult the online list of claimed 533 rights. 535 The IETF takes no position regarding the validity or scope of any 536 Intellectual Property Rights or other rights that might be claimed 537 to pertain to the implementation or use of the technology described 538 in this document or the extent to which any license under such 539 rights might or might not be available; nor does it represent that 540 it has made any independent effort to identify any such rights. 541 Information on the procedures with respect to rights in RFC 542 documents can be found in BCP 78 and BCP 79. 544 Copies of IPR disclosures made to the IETF Secretariat and any 545 assurances of licenses to be made available, or the result of an 546 attempt made to obtain a general license or permission for the use 547 of such proprietary rights by implementers or users of this 548 specification can be obtained from the IETF on-line IPR repository 549 at http://www.ietf.org/ipr. 551 The IETF invites any interested party to bring to its attention any 552 copyrights, patents or patent applications, or other proprietary 553 rights that may cover technology that may be required to implement 554 this standard. Please address the information to the IETF at ietf- 555 ipr@ietf.org. 557 Full Copyright Notice 559 Copyright (C) The IETF Trust (2008). 561 This document is subject to the rights, licenses and restrictions 562 contained in BCP 78, and except as set forth therein, the authors 563 retain all their rights. 565 This document and the information contained herein are provided on 566 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 567 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 568 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 569 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 570 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 571 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 572 FOR A PARTICULAR PURPOSE. 574 Acknowledgement 576 Funding for the RFC Editor function is currently provided by the 577 Internet Society. 579 This Internet-Draft will expire in February 2009.