idnits 2.17.1 draft-melsen-mac-forced-fwd-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 589. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 579. ** 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.) 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 (January 27, 2006) is 6656 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) == Unused Reference: 'RFC2362' is defined on line 493, but no explicit reference was found in the text == Unused Reference: 'RFC2462' is defined on line 523, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2362 (Obsoleted by RFC 4601, RFC 5059) -- Obsolete informational reference (is this intentional?): RFC 1009 (Obsoleted by RFC 1812) -- Obsolete informational reference (is this intentional?): RFC 2338 (Obsoleted by RFC 3768) -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2462 (Obsoleted by RFC 4862) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Personal T. Melsen 3 Internet-Draft S. Blake 4 Expires: July 31, 2006 Ericsson 5 January 27, 2006 7 MAC-Forced Forwarding: A Method for Traffic Separation on an Ethernet 8 Access Network 9 draft-melsen-mac-forced-fwd-04.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on July 31, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document describes a mechanism to ensure layer-2 separation of 43 LAN stations accessing an v4IPv4 gateway over a bridged Ethernet 44 segment. 46 The mechanism - called "MAC-Forced Forwarding" - implements an ARP 47 proxy function that prohibits MAC address resolution between hosts 48 located within the same IPv4 subnet but at different customer 49 premises, and in effect directs all upstream traffic to an IPv4 50 gateway. The IPv4 gateway provides IP-layer connectivity between 51 these same hosts. 53 Table of Contents 55 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Access Network Requirements . . . . . . . . . . . . . . . 4 58 2.2. Using Ethernet as an Access Network Technology . . . . . . 5 59 3. Solution Aspects . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.1. Obtaining the IP and MAC addresses of the Access Router . 7 61 3.2. Responding to ARP Requests . . . . . . . . . . . . . . . . 7 62 3.3. Filtering Upstream Traffic . . . . . . . . . . . . . . . . 8 63 3.4. Restricted Access to Application Servers . . . . . . . . . 8 64 4. Access Router Considerations . . . . . . . . . . . . . . . . . 9 65 5. Resiliency Considerations . . . . . . . . . . . . . . . . . . 9 66 6. Multicast Considerations . . . . . . . . . . . . . . . . . . . 10 67 7. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 72 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 74 Intellectual Property and Copyright Statements . . . . . . . . . . 14 76 1. Terminology 78 Access Node (AN) 79 The entity interconnecting individual subscriber lines to the 80 shared aggregation network. 82 Access Router (AR) 83 The entity interconnecting the access network to the Internet or 84 other IP-based networks. The AR provides connectivity between 85 hosts on the access network at different customer premises. It is 86 also used to provide security filtering, policing, and accounting 87 of customer traffic. 89 Application Server (AS) 90 A server, usually owned by a service provider, that attaches 91 directly to the aggregation network, and is directly reachable at 92 layer-2 by customer hosts. 94 Ethernet Access Node (EAN) 95 An Access Node supporting Ethernet-based subscriber lines and 96 uplinks to an Ethernet-based aggregation network, and MAC-Forced 97 Forwarding. For example, for xDSL access, the EAN is an Ethernet- 98 centric DSLAM. The EAN is a special type of filtering bridge that 99 does not forward Ethernet broadcast and multicast frames 100 originating on a subscriber line to other subscriber lines, but 101 either discards them or forwards them upstream (towards the 102 aggregation network). The EAN also discards unicast Ethernet 103 frames originating on a subscriber line and not addressed to an 104 AR. 106 2. Introduction 108 The main purpose of an access network is to provide connectivity 109 between customer hosts and service provider access routers (ARs), 110 typically offering reachability to the Internet and other IP networks 111 and/or IP-based applications. 113 An access network may be decomposed into a subscriber line part and 114 an aggregation network part. The subscriber line - often referred to 115 as "the first mile" - is characterized by an individual physical (or 116 logical, in the case of some wireless technologies) connection to 117 each customer premise. The aggregation network - "the second mile" - 118 performs aggregation and concentration of customer traffic. 120 The subscriber line and the aggregation network are interconnected by 121 an Access Node (AN). Thus, the AN constitutes the border between 122 individual subscriber lines and the common aggregation network. This 123 is illustrated in the following figure. 125 Access Aggregation Access Subscriber Customer 126 Routers Network Nodes Lines Premise 127 Networks 128 +----+ | 129 --+ AR +-----------| +----+ 130 +----+ | | +----------------[]-------- 131 |--------+ AN | 132 | | +----------------[]-------- 133 | +----+ 134 | 135 | +----+ 136 | | +----------------[]-------- 137 |--------+ AN | 138 | | +----------------[]-------- 139 | +----+ 140 | 141 | +----+ 142 | | +----------------[]-------- 143 |--------+ AN | 144 +----+ | | +----------------[]-------- 145 --+ AR +-----------| +----+ 146 +----+ | 148 2.1. Access Network Requirements 150 There are two basic requirements that an access network solution must 151 satisfy: 152 1. Layer-2 traffic separation between customer premises. 153 2. High IPv4 address assignment efficiency. 155 It is required that all traffic to and from customer hosts located at 156 different premises (i.e., accessed via different subscriber lines, or 157 via different access networks) be forwarded via an AR, and not 158 bridged or switched at layer-2 (Requirement 1). This enables the 159 access network service provider to use the AR(s) to perform security 160 filtering, policing, and accounting of all customer traffic. This 161 implies that within the access network, layer-2 traffic paths should 162 not exist that circumvent an AR (with some exceptions; see 163 Section 3.4). 165 In ATM-based access networks, the separation of individual customer 166 hosts' traffic is an intrinsic feature achieved by the use of ATM 167 permanent virtual connections (PVCs) between the customers' access 168 device (e.g., DSL modem) and the AR (typically co-located/integrated 169 with access control functionality in a Broadband Remote Access Server 170 (BRAS)). In this case, the AN is an ATM-based Digital Subscriber 171 Line Access Multiplexer (DSLAM). 173 This document, however, targets Ethernet-based access networks. 174 Techniques other than ATM PVCs must be employed to ensure the desired 175 separation of traffic to and from individual customer hosts. 177 Efficient address assignment is necessary to minimize consumption of 178 scarce IPv4 address space (Requirement 2). See [RFC3069] for further 179 discussion. Address assignment efficiency is improved if host 180 addresses are assigned out of one or more large pools, rather than by 181 being assigned out of separate, smaller subnet blocks allocated to 182 each customer premise. IPv6 address assignment efficiency is of much 183 less concern, and it is anticipated that IPv6 deployments will 184 allocate separate IPv6 subnet blocks to each customer premise [v6BB]. 186 2.2. Using Ethernet as an Access Network Technology 188 A major aspect of using Ethernet as an access technology is that 189 traffic pertaining to different customer hosts is conveyed over a 190 shared broadcast network. Layer-2 isolation between customer premise 191 networks could be provided by implementing access router 192 functionality in each EAN, treating each subscriber line as a 193 separate IP interface. However, there are a variety of reasons why 194 it is often desirable to avoid IP routing in the access network, 195 including the need to satisfy regulatory requirements for direct 196 layer-2 accessibility to multiple IP service providers. In addition, 197 this solution would not solve Requirement 2. 199 To avoid IP routing within the access network, the Ethernet 200 aggregation network is bridged via EANs to individual Ethernet 201 networks at the customers' premises. If the EAN were a standard 202 Ethernet bridge then there would be direct layer-2 visibility between 203 Ethernet stations (hosts) located at different customers' premises. 204 Specifically, hosts located within the same IP subnet would have this 205 visibility. This violates Requirement 1 (Section 2.1) and introduces 206 security issues, as malicious end-users could attack hosts at other 207 customers' premises directly at the Ethernet layer. 209 Existing standardized solutions may be deployed to prevent layer-2 210 visibility between stations: 211 o PPP over Ethernet [RFC2516]. The use of PPPoE creates individual 212 PPP sessions between hosts and one or more BRASs over a bridged 213 Ethernet topology. Traffic always flows between a BRAS and hosts, 214 never directly between hosts. The AN can force upstream traffic 215 to flow only to the BRAS initially selected by the host. 216 o VLAN per-customer premise network [RFC3069]. Traffic to/from each 217 customer premise network can be separated into different VLANs 218 across the aggregation network between the AN and the AR. 220 Both solutions provide layer-2 isolation between customer hosts, but 221 they are not considered optimal for broadband access networks, 222 because: 223 o PPPoE does not support efficient multicast: packets must be 224 replicated on each PPPoE session to hosts listening on a multicast 225 group. This negates one of the major advantages of using Ethernet 226 (instead of ATM) as an access technology. This is an especially 227 problematic limitation for services such as IPTV which require 228 high bandwidth per-multicast group (channel), and which may often 229 have hundreds or thousands of listening customer hosts per-group. 230 o Using VLANs to isolate individual customer premise networks also 231 forces multicast packets to be replicated to each VLAN with a 232 listening host. Furthermore, the basic limit of a maximum of 4096 233 VLANs per-Ethernet network limits the scalability of the solution. 234 This scalability limit can be removed by deploying VLAN stacking 235 techniques within the access network, but this approach increases 236 provisioning complexity. 238 The solution proposed in this document avoids these problems. 240 3. Solution Aspects 242 The basic property of the solution is that the EAN ensures that 243 upstream traffic is always sent to a designated AR, even if the IP 244 traffic should ultimately flow between customer hosts located within 245 the same IP subnet. 247 The solution has three major aspects: 248 1. Initially, the EAN obtains the IP and MAC address of the legal 249 target ARs for each customer host. 250 2. The EAN replies to any upstream ARP request [RFC0826] from 251 customer hosts with the MAC address of a legal target AR. 252 3. The EAN discards any upstream unicast traffic to MAC addresses 253 other than the legal target ARs. The EAN also discards all non- 254 essential broadcast and multicast packets received on subscriber 255 lines. 257 These aspects are discussed in the following sections. 259 3.1. Obtaining the IP and MAC addresses of the Access Router 261 An access network may contain multiple ARs, and different hosts may 262 be assigned to different (groups of) ARs. This implies that the EAN 263 must register the assigned AR addresses on a per-customer host basis. 265 For each customer host, one of the ARs is acting as the default 266 gateway. If a customer has simultaneous access to multiple ARs, the 267 other ARs typically will provide access to other IP networks. 269 The EAN learns the IPv4 address of the legal target ARs in one of two 270 ways, depending on the host IPv4 address assignment method. For each 271 host using DHCP, the EAN learns the AR IPv4 addresses dynamically by 272 snooping the DHCPACK reply to a host [RFC2131]. If a host using DHCP 273 shall have simultaneous access to multiple ARs, DHCP option 121 274 [RFC3442] or DHCP option 33 [RFC2132] must be used to specify them to 275 that host. If static address assignment is used instead of DHCP, 276 then AR IPv4 addresses must be pre-provisioned in the EAN by the 277 network operator. In both cases, the EAN will need to ARP to 278 determine the ARs' corresponding MAC addresses. This can be done 279 immediately after the IPv4 addresses are learned, or when the MAC 280 addresses are first required. 282 The DHCP server can associate customer hosts with subscriber lines if 283 the EAN uses the DHCP Relay Agent Information Option (82) to convey a 284 subscriber line identifier to the DHCP server in DHCP messages 285 flowing upstream from the customer host [RFC3046]. 287 3.2. Responding to ARP Requests 289 If all customer networks were assigned individual IP subnet blocks 290 (and if routing protocols were blocked inside the access network), 291 then all upstream traffic would normally go to an AR (typically the 292 default gateway), and the EAN could validate all upstream traffic by 293 checking that the destination MAC address matched an AR's. 295 However, to comply with Requirement 2 of Section 2.1, residential 296 customer networks are not (usually) assigned individual IPv4 subnet 297 blocks. In other words, several hosts located at different premises 298 are within the same IPv4 subnet. Consequently, if a host wishes to 299 communicate with a host at another premise, an ARP is issued to 300 obtain that host's corresponding MAC address. This ARP request is 301 intercepted by the EAN's ARP proxy, and an ARP reply is sent, 302 specifying a legal AR MAC address (typically the default gateway's) 303 as the requested layer-2 destination address, in a manner similar to 304 the "proxy ARP" mechanism described in [RFC1009]. In this way, the 305 ARP table of the requesting host will register an AR MAC address as 306 the layer-2 destination for any host within that IPv4 subnet (except 307 those at the same customer premise; see below). 309 ARP requests for an IPv4 address of a legal target AR are replied to 310 by the EAN's ARP proxy with that AR's MAC address, rather than the 311 MAC address of the default gateway AR. 313 An exception is made when a host is ARPing for another host located 314 within the same premise network. If this ARP request reaches the 315 EAN, it should be discarded, because it is assumed to be answered 316 directly by the target host within the premise network. The EAN must 317 keep track of all assigned IPv4 addresses on a subscriber line so 318 that it can detect these ARP requests and discard them. 320 3.3. Filtering Upstream Traffic 322 Since the EAN's ARP proxy will reply always with the MAC address of 323 an AR, the requesting host will never learn MAC addresses of hosts 324 located at other premises. However, malicious customers or 325 malfunctioning hosts may still try to send traffic using other 326 unicast destination MAC addresses. The EAN must discard all unicast 327 frames received on a subscriber line that are not addressed to a 328 destination MAC address for a legal AR (with some exceptions; see 329 Section 3.4. 331 Similarly, broadcast or multicast packets received on a subscriber 332 line must never be forwarded on other subscriber lines, but only on 333 EAN uplinks to the aggregation network. An EAN must discard all 334 broadcast packets received on subscriber lines, except when DHCP is 335 in use, in which case the EAN must forward client-to-server DHCP 336 broadcast messages (DHCPDISCOVER, DHCPREQUEST, DHCPDECLINE, 337 DHCPINFORM) [RFC2131] upstream. An EAN should rate limit upstream 338 broadcast packets. 340 Broadcast packets forwarded on an EAN uplink may be forwarded to 341 other EANs by the aggregation network. EANs should discard all 342 broadcast packets received from the aggregation network, except 343 server-to-client DHCP messages (DHCPOFFER, DHCPACK, DHCPNAK) 344 [RFC2131], when DHCP is in use. 346 Filtering of multicast packets to and from an EAN uplink is discussed 347 in Section 6. 349 3.4. Restricted Access to Application Servers 351 The previous discussion (Section 3.1) describes how customer hosts 352 are allowed direct layer-2 connectivity only to one or more ARs. 353 Similarly, a customer host could be allowed direct layer-2 access to 354 one or more Application Servers (ASs) which are directly connected to 355 the aggregation network. There is no functional difference in the 356 way that MAC-Forced Forwarding treats access to ARs or ASs. 358 4. Access Router Considerations 360 Traffic between customer hosts that belong to the same IPv4 subnet 361 but are located at different customer premises always will be 362 forwarded via an AR. In this case, the AR will forward the traffic 363 to the originating network, i.e., on the same interface from where it 364 was received. This normally results in an ICMP redirect message 365 [RFC0792] being sent to the originating host. To prevent this 366 behavior, the ICMP redirect function for aggregation network 367 interfaces must be disabled in the AR. 369 5. Resiliency Considerations 371 The operation of MAC-Forced Forwarding does not interfere with or 372 delay IP connectivity recovery in the event of a sustained AR 373 failure. Use of DHCP to configure hosts with information on 374 multiple, redundant ARs, or use of VRRP [RFC2338] to implement AR 375 redundancy, allows IP connectivity to be maintained. 377 MAC-Forced Forwarding is a stateful protocol. If static IPv4 address 378 assignment is used in the access network, then the EAN must be pre- 379 provisioned with state information on the customer hosts which may be 380 configured on a subscriber line, and the ARs associated with those 381 hosts. In the event of a transient EAN failure, the EAN's state 382 database can be quickly recovered from its configuration storage. 384 If DHCP is used to assign IPv4 addresses in the access network, then 385 MAC-Forced Forwarding operates as a soft-state protocol. Since the 386 DHCP and ARP messages that are snooped to construct the EAN state 387 database are usually sent infrequently, a transient failure may not 388 be detected by either the AR(s) or the customer hosts. Therefore, a 389 transient failure of an EAN could lead to an extended loss of 390 connectivity. To minimize connectivity loss, an EAN should maintain 391 its dynamic state database in resilient storage to permit timely 392 database and connectivity restoration. 394 The EAN is a single point of attachment between a subscriber line and 395 the aggregation network; hence, the EAN is a single point of 396 connectivity failure. Customers seeking more resilient connectivity 397 should multi-home. 399 6. Multicast Considerations 401 Multicast traffic delivery for streams originating from within the 402 aggregation network or further upstream, and delivered to one or more 403 customer hosts in an access network, is supported in a scalable 404 manner by virtue of Ethernet's native multicast capability. 405 Bandwidth efficiency can be enhanced if the EAN behaves as an IGMP 406 snooping bridge; e.g., if it snoops on IGMP Membership Report and 407 Leave Group messages originating on subscriber lines, to prune the 408 set of subscriber lines on which to forward particular multicast 409 groups [RFC3376]. 411 An EAN must discard all IPv4 multicast packets received on a 412 subscriber line other than IGMP Membership Report and Leave Group 413 messages [RFC3376]. If a customer host wishes to source multicast 414 packets to a group, the host must tunnel them to an upstream 415 multicast router; e.g., an AR acting as a PIM-SM Designated Router . 416 An AR will forward them back into the access network if there are any 417 listening customer hosts. 419 EAN processing of IPv6 multicast packets is discussed in the next 420 section. 422 7. IPv6 Considerations 424 MAC-Forced Forwarding is not directly applicable for IPv6 access 425 networks, for the following reasons: 426 1. IPv6 access networks do not require the same efficiency of 427 address allocation as IPv4 access networks. It is expected that 428 customer premise networks will be allocated unique network 429 prefixes (e.g., /48) accommodating large numbers of customer 430 subnets and hosts [v6BB]. 431 2. IPv6 nodes do not use ARP, but instead use the Neighbor Discovery 432 protocol [RFC2461] for layer-2 address resolution. 434 To simultaneously support IPv6 and MAC-Forced Forwarding for IPv4, an 435 EAN can still implement the unicast, broadcast, and multicast 436 filtering rules described in Section 3.3. To correctly perform 437 unicast filtering, the EAN must learn the IPv6 and MAC addresses of 438 the legal ARs for a particular subscriber line. It can learn these 439 addresses either through static configuration, or by snooping Router 440 Discovery messages exchanged between the customer premises router and 441 one or more ARs [RFC2461]. 443 Multicast is an intrinsic part of the IPv6 protocol suite. 444 Therefore, an EAN must not indiscriminately filter IPv6 multicast 445 packets flowing upstream, although it may rate limit them. Detailed 446 IPv6 multicast filtering rules are not discussed in this document. 448 8. Security Considerations 450 MAC-Forced Forwarding is by its nature a security function, ensuring 451 layer-2 isolation of customer hosts sharing a broadcast access 452 medium. In that sense it provides security equivalent to alternative 453 PVC-based solutions. Security procedures appropriate for any shared 454 access medium are equally appropriate when MAC-Forced Forwarding is 455 employed. It does not introduce any additional vulnerabilities over 456 those of standard Ethernet bridging. 458 In addition to layer-2 isolation, An EAN implementing MAC-Forced 459 Forwarding must discard all upstream broadcast packets, except for 460 valid DHCP messages. In particular, the EAN must discard any DHCP 461 replies originated on a subscriber line. Further, an EAN may rate 462 limit upstream broadcast DHCP messages. 464 An EAN implementing MAC-Forced Forwarding must keep track of IPv4 465 addresses allocated on subscriber lines. The EAN therefore has 466 sufficient information to discard upstream traffic with spoofed IPv4 467 source addresses. 469 9. Acknowledgements 471 The authors would like to thank Ulf Jonsson, Thomas Narten, James 472 Carlson, Rolf Engstrand, Tomas Thyni, and Johan Kolhi for their 473 helpful comments. 475 10. References 477 10.1. Normative References 479 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 480 RFC 792, September 1981. 482 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 483 converting network protocol addresses to 48.bit Ethernet 484 address for transmission on Ethernet hardware", STD 37, 485 RFC 826, November 1982. 487 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 488 RFC 2131, March 1997. 490 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 491 Extensions", RFC 2132, March 1997. 493 [RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, 494 S., Handley, M., and V. Jacobson, "Protocol Independent 495 Multicast-Sparse Mode (PIM-SM): Protocol Specification", 496 RFC 2362, June 1998. 498 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 499 RFC 3046, January 2001. 501 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 502 Thyagarajan, "Internet Group Management Protocol, Version 503 3", RFC 3376, October 2002. 505 [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless 506 Static Route Option for Dynamic Host Configuration 507 Protocol (DHCP) version 4", RFC 3442, December 2002. 509 10.2. Informative References 511 [RFC1009] Braden, R. and J. Postel, "Requirements for Internet 512 gateways", RFC 1009, June 1987. 514 [RFC2338] Knight, S., Weaver, D., Whipple, D., Hinden, R., Mitzel, 515 D., Hunt, P., Higginson, P., Shand, M., and A. Lindem, 516 "Virtual Router Redundancy Protocol", RFC 2338, 517 April 1998. 519 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 520 Discovery for IP Version 6 (IPv6)", RFC 2461, 521 December 1998. 523 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 524 Autoconfiguration", RFC 2462, December 1998. 526 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., 527 and R. Wheeler, "A Method for Transmitting PPP Over 528 Ethernet (PPPoE)", RFC 2516, February 1999. 530 [RFC3069] McPherson, D. and B. Dykes, "VLAN Aggregation for 531 Efficient IP Address Allocation", RFC 3069, February 2001. 533 [v6BB] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and 534 J. Palet, "ISP IPv6 Deployment Scenarios in Broadband 535 Access Networks", work in progress. 537 Authors' Addresses 539 Torben Melsen 540 Ericsson 541 Faelledvej 542 Struer DK-7600 543 Denmark 545 Email: Torben.Melsen@ericsson.com 547 Steven Blake 548 Ericsson 549 920 Main Campus Drive 550 Suite 500 551 Raleigh, NC 27606 552 USA 554 Phone: +1 919 472 9913 555 Email: steven.blake@ericsson.com 557 Intellectual Property Statement 559 The IETF takes no position regarding the validity or scope of any 560 Intellectual Property Rights or other rights that might be claimed to 561 pertain to the implementation or use of the technology described in 562 this document or the extent to which any license under such rights 563 might or might not be available; nor does it represent that it has 564 made any independent effort to identify any such rights. Information 565 on the procedures with respect to rights in RFC documents can be 566 found in BCP 78 and BCP 79. 568 Copies of IPR disclosures made to the IETF Secretariat and any 569 assurances of licenses to be made available, or the result of an 570 attempt made to obtain a general license or permission for the use of 571 such proprietary rights by implementers or users of this 572 specification can be obtained from the IETF on-line IPR repository at 573 http://www.ietf.org/ipr. 575 The IETF invites any interested party to bring to its attention any 576 copyrights, patents or patent applications, or other proprietary 577 rights that may cover technology that may be required to implement 578 this standard. Please address the information to the IETF at 579 ietf-ipr@ietf.org. 581 Disclaimer of Validity 583 This document and the information contained herein are provided on an 584 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 585 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 586 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 587 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 588 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 589 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 591 Copyright Statement 593 Copyright (C) The Internet Society (2006). This document is subject 594 to the rights, licenses and restrictions contained in BCP 78, and 595 except as set forth therein, the authors retain all their rights. 597 Acknowledgment 599 Funding for the RFC Editor function is currently provided by the 600 Internet Society.