doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc4562.txt b/doc/rfc/rfc4562.txt
new file mode 100644
index 0000000..0144e55
--- /dev/null
+++ b/doc/rfc/rfc4562.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group                                          T. Melsen
+Request for Comments: 4562                                      S. Blake
+Category: Informational                                         Ericsson
+                                                               June 2006
+
+
+                         MAC-Forced Forwarding:
+    A Method for Subscriber Separation on an Ethernet Access Network
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes a mechanism to ensure layer-2 separation of
+   Local Area Network (LAN) stations accessing an IPv4 gateway over a
+   bridged Ethernet segment.
+
+   The mechanism - called "MAC-Forced Forwarding" - implements an
+   Address Resolution Protocol (ARP) proxy function that prohibits
+   Ethernet Media Access Control (MAC) address resolution between hosts
+   located within the same IPv4 subnet but at different customer
+   premises, and in effect directs all upstream traffic to an IPv4
+   gateway.  The IPv4 gateway provides IP-layer connectivity between
+   these same hosts.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melsen & Blake               Informational                      [Page 1]
+
+RFC 4562                 MAC-Forced Forwarding                 June 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Access Network Requirements ................................3
+      1.2. Using Ethernet as an Access Network Technology .............4
+   2. Terminology .....................................................5
+   3. Solution Aspects ................................................6
+      3.1. Obtaining the IP and MAC Addresses of the Access Routers ...6
+      3.2. Responding to ARP Requests .................................7
+      3.3. Filtering Upstream Traffic .................................8
+      3.4. Restricted Access to Application Servers ...................8
+   4. Access Router Considerations ....................................8
+   5. Resiliency Considerations .......................................9
+   6. Multicast Considerations ........................................9
+   7. IPv6 Considerations ............................................10
+   8. Security Considerations ........................................10
+   9. Acknowledgements ...............................................11
+   10. References ....................................................11
+      10.1. Normative References .....................................11
+      10.2. Informative References ...................................12
+
+1.  Introduction
+
+   The main purpose of an access network is to provide connectivity
+   between customer hosts and service provider access routers (ARs),
+   typically offering reachability to the Internet and other IP networks
+   and/or IP-based applications.
+
+   An access network may be decomposed into a subscriber line part and
+   an aggregation network part.  The subscriber line - often referred to
+   as "the first mile" - is characterized by an individual physical (or
+   logical, in the case of some wireless technologies) connection to
+   each customer premises.  The aggregation network - "the second mile"
+   - performs aggregation and concentration of customer traffic.
+
+   The subscriber line and the aggregation network are interconnected by
+   an Access Node (AN).  Thus, the AN constitutes the border between
+   individual subscriber lines and the common aggregation network.  This
+   is illustrated in the following figure.
+
+
+
+
+
+
+
+
+
+
+
+
+Melsen & Blake               Informational                      [Page 2]
+
+RFC 4562                 MAC-Forced Forwarding                 June 2006
+
+
+        Access       Aggregation  Access    Subscriber    Customer
+        Routers      Network      Nodes     Lines         Premises
+                                                          Networks
+        +----+           |
+      --+ AR +-----------|        +----+
+        +----+           |        |    +----------------[]--------
+                         |--------+ AN |
+                         |        |    +----------------[]--------
+                         |        +----+
+                         |
+                         |        +----+
+                         |        |    +----------------[]--------
+                         |--------+ AN |
+                         |        |    +----------------[]--------
+                         |        +----+
+                         |
+                         |        +----+
+                         |        |    +----------------[]--------
+                         |--------+ AN |
+        +----+           |        |    +----------------[]--------
+      --+ AR +-----------|        +----+
+        +----+           |
+
+1.1.  Access Network Requirements
+
+   There are two basic requirements that an access network solution must
+   satisfy:
+
+   1. Layer-2 separation between customer premises.
+
+   2. High IPv4 address assignment efficiency.
+
+   It is required that all traffic to and from customer hosts located at
+   different premises (i.e., accessed via different subscriber lines or
+   via different access networks) be forwarded via an AR, and not
+   bridged or switched at layer-2 (Requirement 1; see also requirement
+   R-40 in [TR101]).  This enables the access network service provider
+   to use the AR(s) to perform security filtering, policing, and
+   accounting of all customer traffic.  This implies that within the
+   access network, layer-2 traffic paths should not exist that
+   circumvent an AR (with some exceptions; see Section 3.4).
+
+   In ATM-based access networks, the separation of individual customer
+   hosts' traffic is an intrinsic feature achieved by the use of ATM
+   permanent virtual connections (PVCs) between the customers' access
+   device (e.g., DSL modem) and the AR (typically co-located/integrated
+   with access control functionality in a Broadband Remote Access Server
+
+
+
+
+Melsen & Blake               Informational                      [Page 3]
+
+RFC 4562                 MAC-Forced Forwarding                 June 2006
+
+
+   (BRAS)).  In this case, the AN is an ATM-based Digital Subscriber
+   Line Access Multiplexer (DSLAM).
+
+   This document, however, targets Ethernet-based access networks.
+   Techniques other than ATM PVCs must be employed to ensure the desired
+   separation of traffic to and from individual customer hosts.
+
+   Efficient address assignment is necessary to minimize consumption of
+   the scarce IPv4 address space (Requirement 2).  See [RFC3069] for
+   further discussion.  Address assignment efficiency is improved if
+   host addresses are assigned out of one or more large pools, rather
+   than by being assigned out of separate, smaller subnet blocks
+   allocated to each customer premises.  IPv6 address assignment
+   efficiency is of much less concern, and it is anticipated that IPv6
+   deployments will allocate separate IPv6 subnet blocks to each
+   customer premises [v6BB].
+
+1.2.  Using Ethernet as an Access Network Technology
+
+   A major aspect of using Ethernet as an access technology is that
+   traffic pertaining to different customer hosts is conveyed over a
+   shared broadcast network.  Layer-2 isolation between customer
+   premises networks could be provided by implementing access router
+   functionality in each EAN, treating each subscriber line as a
+   separate IP interface.  However, there are a variety of reasons why
+   it is often desirable to avoid IP routing in the access network,
+   including the need to satisfy regulatory requirements for direct
+   layer-2 accessibility to multiple IP service providers.  In addition,
+   this solution would not solve Requirement 2.
+
+   To avoid IP routing within the access network, the Ethernet
+   aggregation network is bridged via EANs to individual Ethernet
+   networks at the customers' premises.  If the EANs were standard
+   Ethernet bridges, then there would be direct layer-2 visibility
+   between Ethernet stations (hosts) located at different customers'
+   premises.  Specifically, hosts located within the same IP subnet
+   would have this visibility.  This violates Requirement 1 (Section
+   1.1) and introduces security issues, as malicious end-users thereby
+   can attack hosts at other customers' premises directly at the
+   Ethernet layer.
+
+   Existing standardized solutions may be deployed to prevent layer-2
+   visibility between stations:
+
+   o  PPP over Ethernet [RFC2516].  The use of PPPoE creates individual
+      PPP sessions between hosts and one or more BRASes over a bridged
+      Ethernet topology.  Traffic always flows between a BRAS and hosts,
+
+
+
+
+Melsen & Blake               Informational                      [Page 4]
+
+RFC 4562                 MAC-Forced Forwarding                 June 2006
+
+
+      never directly between hosts.  The AN can force upstream traffic
+      to flow only to the BRAS initially selected by the host.
+
+   o  VLAN per-customer premises network [RFC3069].  Traffic to/from
+      each customer premises network can be separated into different
+      VLANs across the aggregation network between the AN and the AR.
+
+   Both solutions provide layer-2 isolation between customer hosts, but
+   they are not considered optimal for broadband access networks,
+   because:
+
+   o  PPPoE does not support efficient multicast: packets must be
+      replicated on each PPPoE session to hosts listening on a specific
+      multicast group.  This negates one of the major advantages of
+      using Ethernet (instead of ATM) as an access technology.  This is
+      an especially problematic limitation for services such as IPTV,
+      which require high bandwidth per-multicast group (channel), and
+      which may often have hundreds or thousands of listening customer
+      hosts per group.
+
+   o  Using VLANs to isolate individual customer premises networks also
+      forces multicast packets to be replicated to each VLAN with a
+      listening host.  Furthermore, the basic limit of a maximum of 4096
+      VLANs per-Ethernet network limits the scalability of the solution.
+      This scalability limit can be removed by deploying VLAN stacking
+      techniques within the access network, but this approach increases
+      provisioning complexity.
+
+   The solution proposed in this document avoids these problems.
+
+2.  Terminology
+
+   Access Node (AN)
+      The entity interconnecting individual subscriber lines to the
+      shared aggregation network.
+
+   Access Router (AR)
+      The entity interconnecting the access network to the Internet or
+      other IP-based networks.  The AR provides connectivity between
+      hosts on the access network at different customer premises.  It is
+      also used to provide security filtering, policing, and accounting
+      of customer traffic.
+
+   Application Server (AS)
+      A server, usually owned by a service provider, that attaches
+      directly to the aggregation network and is directly reachable at
+      layer-2 by customer hosts.
+
+
+
+
+Melsen & Blake               Informational                      [Page 5]
+
+RFC 4562                 MAC-Forced Forwarding                 June 2006
+
+
+   Ethernet Access Node (EAN)
+      An Access Node supporting Ethernet-based subscriber lines and
+      uplinks to an Ethernet-based aggregation network and MAC-Forced
+      Forwarding.  For example, for xDSL access, the EAN is an
+      Ethernet-centric DSLAM.  The EAN is a special type of filtering
+      bridge that does not forward Ethernet broadcast and multicast
+      frames originating on a subscriber line to other subscriber lines,
+      but either discards them or forwards them upstream (towards the
+      aggregation network).  The EAN also discards unicast Ethernet
+      frames that originate on a subscriber line and are not addressed
+      to an AR.
+
+3.  Solution Aspects
+
+   The basic property of the solution is that the EAN ensures that
+   upstream traffic is always sent to a designated AR, even if the IP
+   traffic should ultimately flow between customer hosts located within
+   the same IP subnet.
+
+   The solution has three major aspects:
+
+   1. Initially, the EAN obtains the IP and MAC addresses of the allowed
+      target ARs for each customer host.
+
+   2. The EAN replies to any upstream ARP request [RFC0826] from
+      customer hosts with the MAC address of an allowed target AR.
+
+   3. The EAN discards any upstream unicast traffic to MAC addresses
+      other than the allowed target ARs.  The EAN also discards all
+      non-essential broadcast and multicast packets received on
+      subscriber lines.
+
+   These aspects are discussed in the following sections.
+
+3.1.  Obtaining the IP and MAC Addresses of the Access Routers
+
+   An access network may contain multiple ARs, and different hosts may
+   be assigned to different (groups of) ARs.  This implies that the EAN
+   must register the assigned AR addresses on a per-customer host basis.
+
+   For each customer host, one of the ARs is acting as the default
+   gateway.  If a customer has simultaneous access to multiple ARs, the
+   other ARs typically will provide access to other IP networks.
+
+   The EAN learns the IPv4 address of the allowed target ARs in one of
+   two ways, depending on the host IPv4 address assignment method.  For
+   each host using Dynamic Host Configuration Protocol (DHCP), the EAN
+   learns the AR IPv4 addresses dynamically by snooping the DHCPACK
+
+
+
+Melsen & Blake               Informational                      [Page 6]
+
+RFC 4562                 MAC-Forced Forwarding                 June 2006
+
+
+   reply to a host [RFC2131].  If a host using DHCP shall have
+   simultaneous access to multiple ARs, DHCP option 121 [RFC3442] or
+   DHCP option 33 [RFC2132] must be used to specify them for that host.
+   If static address assignment is used instead of DHCP, then AR IPv4
+   addresses must be pre-provisioned in the EAN by the network operator.
+   In both cases, the EAN will ARP to determine the ARs' corresponding
+   MAC addresses.  This can be done immediately after the IPv4 addresses
+   are learned or when the MAC addresses are first required.
+
+   The DHCP server can associate customer hosts with subscriber lines if
+   the EAN uses the DHCP Relay Agent Information Option (82) to convey a
+   subscriber line identifier to the DHCP server in DHCP messages
+   flowing upstream from the customer host [RFC3046].
+
+3.2.  Responding to ARP Requests
+
+   If all customer networks were assigned individual IP subnet blocks
+   (and if routing protocols were blocked inside the access network),
+   then all upstream traffic would normally go to an AR (typically the
+   default gateway), and the EAN could validate all upstream traffic by
+   checking that the destination MAC address matched that of an AR.
+
+   However, to comply with Requirement 2 of Section 1.1, residential
+   customer networks are not (usually) assigned individual IPv4 subnet
+   blocks.  In other words, several hosts located at different premises
+   are within the same IPv4 subnet.  Consequently, if a host wishes to
+   communicate with a host at another premises, an ARP request is issued
+   to obtain that host's corresponding MAC address.  This request is
+   intercepted by the EAN's ARP proxy, and an ARP reply is sent,
+   specifying an allowed AR MAC address (typically the default
+   gateway's) as the requested layer-2 destination address, in a manner
+   similar to the "proxy ARP" mechanism described in [RFC1812].  In this
+   way, the ARP table of the requesting host will register an AR MAC
+   address as the layer-2 destination for any host within that IPv4
+   subnet (except those at the same customer premises; see below).
+
+   ARP requests for an IPv4 address of an allowed target AR are replied
+   to by the EAN's ARP proxy with that AR's MAC address, rather than the
+   MAC address of the default gateway AR.
+
+   An exception is made when a host is ARPing for another host located
+   within the same premises network.  If this ARP request reaches the
+   EAN, it should be discarded, because it is assumed to be answered
+   directly by the target host within the premises network.  The EAN
+   must keep track of all assigned IPv4 addresses on a subscriber line
+   so that it can detect these ARP requests and discard them.
+
+
+
+
+
+Melsen & Blake               Informational                      [Page 7]
+
+RFC 4562                 MAC-Forced Forwarding                 June 2006
+
+
+3.3.  Filtering Upstream Traffic
+
+   Since the EAN's ARP proxy will always reply with the MAC address of
+   an AR, the requesting host will never learn MAC addresses of hosts
+   located at other premises.  However, malicious customers or
+   malfunctioning hosts may still try to send traffic using other
+   unicast destination MAC addresses.  The EAN must discard all unicast
+   frames received on a subscriber line that are not addressed to a
+   destination MAC address for an allowed AR (with some exceptions; see
+   Section 3.4.
+
+   Similarly, broadcast or multicast packets received on a subscriber
+   line must never be forwarded on other subscriber lines, but only on
+   EAN uplinks to the aggregation network.  An EAN must discard all
+   non-ARP broadcast packets received on subscriber lines, except when
+   DHCP is in use, in which case, the EAN must forward client-to-server
+   DHCP broadcast messages (DHCPDISCOVER, DHCPREQUEST, DHCPDECLINE,
+   DHCPINFORM) [RFC2131] upstream.  An EAN should rate limit upstream
+   broadcast packets.
+
+   Broadcast packets forwarded on an EAN uplink may be forwarded to
+   other EANs by the aggregation network.  EANs should discard all
+   broadcast packets received from the aggregation network, except ARPs
+   from ARs for subscriber hosts and server-to-client DHCP messages
+   (DHCPOFFER, DHCPACK, DHCPNAK) [RFC2131], when DHCP is in use.
+
+   Filtering of multicast packets to and from an EAN uplink is discussed
+   in Section 6.
+
+3.4.  Restricted Access to Application Servers
+
+   The previous discussion (Section 3.1) describes how customer hosts
+   are allowed direct layer-2 connectivity only to one or more ARs.
+   Similarly, a customer host could be allowed direct layer-2 access to
+   one or more Application Servers (ASes) which are directly connected
+   to the aggregation network.  There is no functional difference in the
+   way MAC-Forced Forwarding treats access to ARs and ASes.
+
+4.  Access Router Considerations
+
+   Traffic between customer hosts that belong to the same IPv4 subnet
+   but are located at different customer premises will always be
+   forwarded via an AR.  In this case, the AR will forward the traffic
+   to the originating network, i.e., on the same interface from where it
+   was received.  This normally results in an ICMP redirect message
+   [RFC0792] being sent to the originating host.  To prevent this
+   behavior, the ICMP redirect function for aggregation network
+   interfaces must be disabled in the AR.
+
+
+
+Melsen & Blake               Informational                      [Page 8]
+
+RFC 4562                 MAC-Forced Forwarding                 June 2006
+
+
+5.  Resiliency Considerations
+
+   The operation of MAC-Forced Forwarding does not interfere with or
+   delay IP connectivity recovery in the event of a sustained AR
+   failure.  Use of DHCP to configure hosts with information on
+   multiple, redundant ARs, or use of Virtual Router Redundancy Protocol
+   (VRRP) [RFC3768] to implement AR redundancy, allows IP connectivity
+   to be maintained.
+
+   MAC-Forced Forwarding is a stateful protocol.  If static IPv4 address
+   assignment is used in the access network, then the EAN must be pre-
+   provisioned with state information for the customer hosts which may
+   be reached via a subscriber line, and the ARs associated with those
+   hosts.  In the event of a transient EAN failure, the EAN's state
+   database can be quickly recovered from its configuration storage.
+
+   If DHCP is used to assign IPv4 addresses in the access network, then
+   MAC-Forced Forwarding operates as a soft-state protocol.  Since the
+   DHCP and ARP messages that are snooped to construct the EAN state
+   database are usually sent infrequently, a transient failure may not
+   be detected by either the AR(s) or the customer hosts.  Therefore, a
+   transient failure of an EAN could lead to an extended loss of
+   connectivity.  To minimize connectivity loss, an EAN should maintain
+   its dynamic state database in resilient storage to permit timely
+   database and connectivity restoration.
+
+   The EAN is a single point of attachment between a subscriber line and
+   the aggregation network; hence, the EAN is a single point of
+   connectivity failure.  Customers seeking more resilient connectivity
+   should multi-home.
+
+6.  Multicast Considerations
+
+   Multicast traffic delivery for streams originating within the
+   aggregation network or further upstream and delivered to one or more
+   customer hosts in an access network is supported in a scalable manner
+   by virtue of Ethernet's native multicast capability.  Bandwidth
+   efficiency can be enhanced if the EAN behaves as an IGMP snooping
+   bridge; e.g., if it snoops on IGMP Membership Report and Leave Group
+   messages originating on subscriber lines to prune the set of
+   subscriber lines on which to forward particular multicast groups
+   [RFC3376].
+
+   An EAN must discard all IPv4 multicast packets received on a
+   subscriber line other than IGMP Membership Report and Leave Group
+   messages [RFC3376].  If a customer host wishes to source multicast
+   packets to a group, the host must tunnel them upstream to a multicast
+   router; e.g., an AR acting as a Protocol Independent Multicast -
+
+
+
+Melsen & Blake               Informational                      [Page 9]
+
+RFC 4562                 MAC-Forced Forwarding                 June 2006
+
+
+   Sparse Mode (PIM-SM) Designated Router [RFC2362].  An AR will forward
+   them back into the access network if there are any listening customer
+   hosts.
+
+   EAN processing of IPv6 multicast packets is discussed in the next
+   section.
+
+7.  IPv6 Considerations
+
+   MAC-Forced Forwarding is not directly applicable for IPv6 access
+   networks for the following reasons:
+
+   1. IPv6 access networks do not require the same efficiency of address
+      allocation as IPv4 access networks.  It is expected that customer
+      premises networks will be allocated unique network prefixes (e.g.,
+      /48) accommodating large numbers of customer subnets and hosts
+      [v6BB].
+
+   2. IPv6 nodes do not use ARP, but instead use the Neighbor Discovery
+      Protocol [RFC2461] for layer-2 address resolution.
+
+   To simultaneously support both IPv6 and MAC-Forced Forwarding for
+   IPv4, an EAN can implement the unicast, broadcast, and multicast
+   filtering rules described in Section 3.3.  To correctly perform
+   unicast filtering, the EAN must learn the IPv6 and MAC addresses of
+   the allowed ARs for a particular subscriber line.  It can learn these
+   addresses either through static configuration or by snooping Router
+   Discovery messages exchanged between the customer premises router and
+   one or more ARs [RFC2461].
+
+   Multicast is an intrinsic part of the IPv6 protocol suite.
+   Therefore, an EAN must not indiscriminately filter IPv6 multicast
+   packets flowing upstream, although it may rate limit them.  Detailed
+   IPv6 multicast filtering rules are not discussed in this document.
+
+8.  Security Considerations
+
+   MAC-Forced Forwarding is, by its nature, a security function,
+   ensuring layer-2 isolation of customer hosts sharing a broadcast
+   access medium.  In that sense, it provides security equivalent to
+   alternative PVC-based solutions.  Security procedures appropriate for
+   any shared access medium are equally appropriate when MAC-Forced
+   Forwarding is employed.  It does not introduce any additional
+   vulnerabilities over those of standard Ethernet bridging.
+
+   In addition to layer-2 isolation, an EAN implementing MAC-Forced
+   Forwarding must discard all upstream broadcast packets, except for
+   valid DHCP messages, and ARP requests (which are proxied by the EAN).
+
+
+
+Melsen & Blake               Informational                     [Page 10]
+
+RFC 4562                 MAC-Forced Forwarding                 June 2006
+
+
+   In particular, the EAN must discard any DHCP server replies
+   originating on a subscriber line.  Further, an EAN may rate limit
+   upstream broadcast DHCP messages.
+
+   An EAN implementing MAC-Forced Forwarding must keep track of IPv4
+   addresses allocated on subscriber lines.  Therefore, the EAN has
+   sufficient information to discard upstream traffic with spoofed IPv4
+   source addresses.
+
+9.  Acknowledgements
+
+   The authors would like to thank Ulf Jonsson, Thomas Narten, James
+   Carlson, Rolf Engstrand, Tomas Thyni, and Johan Kolhi for their
+   helpful comments.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
+              RFC 792, September 1981.
+
+   [RFC0826]  Plummer, D., "Ethernet Address Resolution Protocol:  Or
+              converting network protocol addresses to 48.bit Ethernet
+              address for transmission on Ethernet hardware", STD 37,
+              RFC 826, November 1982.
+
+   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol", RFC
+              2131, March 1997.
+
+   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
+              Extensions", RFC 2132, March 1997.
+
+   [RFC2362]  Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering,
+              S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L.
+              Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM):
+              Protocol Specification", RFC 2362, June 1998.
+
+   [RFC3046]  Patrick, M., "DHCP Relay Agent Information Option", RFC
+              3046, January 2001.
+
+   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
+              Thyagarajan, "Internet Group Management Protocol, Version
+              3", RFC 3376, October 2002.
+
+   [RFC3442]  Lemon, T., Cheshire, S., and B. Volz, "The Classless
+              Static Route Option for Dynamic Host Configuration
+              Protocol (DHCP) version 4", RFC 3442, December 2002.
+
+
+
+Melsen & Blake               Informational                     [Page 11]
+
+RFC 4562                 MAC-Forced Forwarding                 June 2006
+
+
+10.2.  Informative References
+
+   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers", RFC
+              1812, June 1995.
+
+   [RFC3768]  Hinden, R., "Virtual Router Redundancy Protocol (VRRP)",
+              RFC 3768, April 2004.
+
+   [RFC2461]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor
+              Discovery for IP Version 6 (IPv6)", RFC 2461, December
+              1998.
+
+   [RFC2516]  Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
+              and R. Wheeler, "A Method for Transmitting PPP Over
+              Ethernet (PPPoE)", RFC 2516, February 1999.
+
+   [RFC3069]  McPherson, D. and B. Dykes, "VLAN Aggregation for
+              Efficient IP Address Allocation", RFC 3069, February 2001.
+
+   [TR101]    DSL Forum, "Migration to Ethernet-Based DSL Aggregation",
+              Technical Report TR-101, April 2006.
+
+   [v6BB]     Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and
+              J.  Palet, "ISP IPv6 Deployment Scenarios in Broadband
+              Access Networks", Work in Progress.
+
+Authors' Addresses
+
+   Torben Melsen
+   Ericsson
+   Faelledvej
+   Struer  DK-7600
+   Denmark
+
+   EMail: Torben.Melsen@ericsson.com
+
+
+   Steven Blake
+   Ericsson
+   920 Main Campus Drive
+   Suite 500
+   Raleigh, NC  27606
+   USA
+
+   Phone: +1 919 472 9913
+   EMail: steven.blake@ericsson.com
+
+
+
+
+
+Melsen & Blake               Informational                     [Page 12]
+
+RFC 4562                 MAC-Forced Forwarding                 June 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78 and at www.rfc-editor.org/copyright.html, and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Melsen & Blake               Informational                     [Page 13]
+