tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4779

 
 
 

ISP IPv6 Deployment Scenarios in Broadband Access Networks

Part 4 of 4, p. 55 to 81
Prev RFC Part

 


prevText      Top      Up      ToC       Page 55 
8.  Wireless LAN

   This section provides a detailed description of IPv6 deployment and
   integration methods in currently deployed wireless LAN (WLAN)
   infrastructure.

8.1.  WLAN Deployment Scenarios

   WLAN enables subscribers to connect to the Internet from various
   locations without the restriction of staying indoors.  WLAN is
   standardized by IEEE 802.11a/b/g.

   Figure 8.1 describes the current WLAN architecture.

       Customer |             Access Provider        | Service Provider
       Premise  |                                    |

     +------+         +--+ +--------------+ +----------+ +------+
     |WLAN  |  ----   |  | |Access Router/| | Provider | |Edge  |
     |Host/ |-(WLAN)--|AP|-|Layer 2 Switch|-| Network  |-|Router|=>SP
     |Router|  ----   |  | |              | |          | |      |Network
     +------+         +--+ +--------------+ +----------+ +------+
                                                           |
                                                        +------+
                                                        |AAA   |
                                                        |Server|
                                                        +------+

                                 Figure 8.1

Top      Up      ToC       Page 56 
   The host should have a wireless Network Interface Card (NIC) in order
   to connect to a WLAN network.  WLAN is a flat broadcast network and
   works in a similar fashion as Ethernet.  When a host initiates a
   connection, it is authenticated by the AAA server located at the SP
   network.  All the authentication parameters (username, password,
   etc.) are forwarded by the Access Point (AP) to the AAA server.  The
   AAA server authenticates the host; once successfully authenticated,
   the host can send data packets.  The AP is located near the host and
   acts as a bridge.  The AP forwards all the packets coming to/from
   host to the Edge Router.  The underlying connection between the AP
   and Edge Router could be based on any access layer technology such as
   HFC/Cable, FTTH, xDSL, etc.

   WLANs operate within limited areas known as WiFi Hot Spots.  While
   users are present in the area covered by the WLAN range, they can be
   connected to the Internet given they have a wireless NIC and required
   configuration settings in their devices (notebook PCs, PDAs, etc.).
   Once the user initiates the connection, the IP address is assigned by
   the SP using DHCPv4.  In most of the cases, SP assigns a limited
   number of public IP addresses to its customers.  When the user
   disconnects the connection and moves to a new WiFi hot spot, the
   above-mentioned process of authentication, address assignment, and
   accessing the Internet is repeated.

   There are IPv4 deployments where customers can use WLAN routers to
   connect over wireless to their service provider.  These deployment
   types do not fit in the typical Hot Spot concept, but rather they
   serve fixed customers.  For this reason, this section discusses the
   WLAN router options as well.  In this case, the ISP provides a public
   IP address and the WLAN Router assigns private addresses [RFC1918] to
   all WLAN users.  The WLAN Router provides NAT functionality while
   WLAN users access the Internet.

   While deploying IPv6 in the above-mentioned WLAN architecture, there
   are three possible scenarios as discussed below.

   A. Layer 2 NAP with Layer 3 termination at NSP Edge Router

   B. Layer 3 aware NAP with Layer 3 termination at Access Router

   C. PPP-Based Model

8.1.1.  Layer 2 NAP with Layer 3 termination at NSP Edge Router

   When a Layer 2 switch is present between AP and Edge Router, the AP
   and Layer 2 switch continues to work as a bridge, forwarding IPv4 and
   IPv6 packets from WLAN Host/Router to Edge Router and vice versa.

Top      Up      ToC       Page 57 
   When initiating the connection, the WLAN Host is authenticated by the
   AAA server located at the SP network.  All the parameters related to
   authentication (username, password, etc.) are forwarded by the AP to
   the AAA server.  The AAA server authenticates the WLAN Hosts, and
   once the WLAN Host is authenticated and associated successfully with
   the WLAN AP, it acquires an IPv6 address.  Note that the initiation
   and authentication process is the same as used in IPv4.

   Figure 8.1.1 describes the WLAN architecture when a Layer 2 Switch is
   located between AP and Edge Router.

       Customer |             Access Provider        | Service Provider
       Premise  |                                    |

     +------+         +--+ +--------------+ +----------+ +------+
     |WLAN  |  ----   |  | |              | | Provider | |Edge  |
     |Host/ |-(WLAN)--|AP|-|Layer 2 Switch|-| Network  |-|Router|=>SP
     |Router|  ----   |  | |              | |          | |      |Network
     +------+         +--+ +--------------+ +----------+ +------+
                                                           |
                                                        +------+
                                                        |AAA   |
                                                        |Server|
                                                        +------+

                                 Figure 8.1.1

8.1.1.1.  IPv6 Related Infrastructure Changes

   IPv6 will be deployed in this scenario by upgrading the following
   devices to dual stack: WLAN Host, WLAN Router (if present), and Edge
   Router.

8.1.1.2.  Addressing

   When a customer WLAN Router is not present, the WLAN Host has two
   possible options to get an IPv6 address via the Edge Router.

   A.  The WLAN Host can get the IPv6 address from an Edge Router using
       stateless auto-configuration [RFC2462].  All hosts on the WLAN
       belong to the same /64 subnet that is statically configured on
       the Edge Router.  The IPv6 WLAN Host may use stateless DHCPv6 for
       obtaining other information of interest such as DNS, etc.

   B.  The IPv6 WLAN Host can use DHCPv6 [RFC3315] to get an IPv6
       address from the DHCPv6 server.  In this case, the DHCPv6 server
       would be located in the SP core network, and the Edge Router
       would simply act as a DHCP Relay Agent.  This option is similar

Top      Up      ToC       Page 58 
       to what is done today in case of DHCPv4.  It is important to note
       that host implementation of stateful auto-configuration is rather
       limited at this time, and this should be considered if choosing
       this address assignment option.

   When a customer WLAN Router is present, the WLAN Host has two
   possible options as well for acquiring IPv6 address.

   A.  The WLAN Router may be assigned a prefix between /48 and /64
       [RFC3177] depending on the SP policy and customer requirements.
       If the WLAN Router has multiple networks connected to its
       interfaces, the network administrator will have to configure the
       /64 prefixes to the WLAN Router interfaces connecting the WLAN
       Hosts on the customer site.  The WLAN Hosts connected to these
       interfaces can automatically configure themselves using stateless
       auto-configuration.

   B.  The WLAN Router can use its link-local address to communicate
       with the ER.  It can also dynamically acquire through stateless
       auto-configuration the address for the link between itself and
       the ER.  This step is followed by a request via DHCP-PD for a
       prefix shorter than /64 that, in turn, is divided in /64s and
       assigned to its interfaces connecting the hosts on the customer
       site.

   In this option, the WLAN Router would act as a requesting router and
   the Edge Router would act as a delegating router.  Once the prefix is
   received by the WLAN Router, it assigns /64 prefixes to each of its
   interfaces connecting the WLAN Hosts on the customer site.  The WLAN
   Hosts connected to these interfaces can automatically configure
   themselves using stateless auto-configuration.  The uplink to the ISP
   network is configured with a /64 prefix as well.

   Usually it is easier for the SPs to stay with the DHCP-PD and
   stateless auto-configuration model and point the clients to a central
   server for DNS/domain information, proxy configurations, etc.  Using
   this model, the SP could change prefixes on the fly, and the WLAN
   Router would simply pull the newest prefix based on the valid/
   preferred lifetime.

   The prefixes used for subscriber links and the ones delegated via
   DHCP-PD should be planned in a manner that allows maximum
   summarization at the Edge Router.

   Other information of interest to the host, such as DNS, is provided
   through stateful [RFC3315] and stateless [RFC3736] DHCPv6.

Top      Up      ToC       Page 59 
8.1.1.3.  Routing

   The WLAN Host/Router is configured with a default route that points
   to the Edge Router.  No routing protocols are needed on these
   devices, which generally have limited resources.

   The Edge Router runs the IGP used in the SP network such as OSPFv3 or
   IS-IS for IPv6.  The connected prefixes have to be redistributed.
   Prefix summarization should be done at the Edge Router.  When DHCP-PD
   is used, the IGP has to redistribute the static routes installed
   during the process of prefix delegation.

8.1.2.  Layer 3 Aware NAP with Layer 3 Termination at Access Router

   When an Access Router is present between the AP and Edge Router, the
   AP continues to work as a bridge, bridging IPv4 and IPv6 packets from
   WLAN Host/Router to Access Router and vice versa.  The Access Router
   could be part of the SP network or owned by a separate Access
   Provider.

   When the WLAN Host initiates the connection, the AAA authentication
   and association process with WLAN AP will be similar, as explained in
   Section 8.1.1.

   Figure 8.1.2 describes the WLAN architecture when the Access Router
   is located between the AP and Edge Router.

       Customer |             Access Provider        | Service Provider
       Premise  |                                    |

     +------+         +--+ +--------------+ +----------+ +------+
     |WLAN  |  ----   |  | |              | | Provider | |Edge  |
     |Host/ |-(WLAN)--|AP|-|Access Router |-| Network  |-|Router|=>SP
     |Router|  ----   |  | |              | |          | |      |Network
     +------+         +--+ +--------------+ +----------+ +------+
                                                           |
                                                        +------+
                                                        |AAA   |
                                                        |Server|
                                                        +------+

                                  Figure 8.1.2

8.1.2.1.  IPv6 Related Infrastructure Changes

   IPv6 is deployed in this scenario by upgrading the following devices
   to dual stack: WLAN Host, WLAN Router (if present), Access Router,
   and Edge Router.

Top      Up      ToC       Page 60 
8.1.2.2.  Addressing

   There are three possible options in this scenario for IPv6 address
   assignment:

   A.  The Edge Router interface facing towards the Access Router is
       statically configured with a /64 prefix.  The Access Router
       receives/ configures a /64 prefix on its interface facing towards
       the Edge Router through stateless auto-configuration.  The
       network administrator will have to configure the /64 prefixes to
       the Access Router interface facing toward the customer premise.
       The WLAN Host/Router connected to this interface can
       automatically configure itself using stateless auto-
       configuration.

   B.  This option uses DHCPv6 [RFC3315] for IPv6 prefix assignments to
       the WLAN Host/Router.  There is no use of DHCP PD or stateless
       auto-configuration in this option.  The DHCPv6 server can be
       located on the Access Router, the Edge Router, or somewhere in
       the SP network.  In this case, depending on where the DHCPv6
       server is located, the Access Router or the Edge Router would
       relay the DHCPv6 requests.

   C.  It can use its link-local address to communicate with the ER.  It
       can also dynamically acquire through stateless auto-configuration
       the address for the link between itself and the ER.  This step is
       followed by a request via DHCP-PD for a prefix shorter than /64
       that, in turn, is divided in /64s and assigned to its interfaces
       connecting the hosts on the customer site.

       In this option, the Access Router would act as a requesting
       router, and the Edge Router would act as a delegating router.
       Once the prefix is received by the Access Router, it assigns /64
       prefixes to each of its interfaces connecting the WLAN Host/
       Router on the customer site.  The WLAN Host/Router connected to
       these interfaces can automatically configure itself using
       stateless auto-configuration.  The uplink to the ISP network is
       configured with a /64 prefix as well.

   It is easier for the SPs to stay with the DHCP PD and stateless auto-
   configuration model and point the clients to a central server for
   DNS/domain information, proxy configurations, and others.  Using this
   model, the provider could change prefixes on the fly, and the Access
   Router would simply pull the newest prefix based on the valid/
   preferred lifetime.

Top      Up      ToC       Page 61 
   As mentioned before, the prefixes used for subscriber links and the
   ones delegated via DHCP-PD should be planned in a manner that allows
   the maximum summarization possible at the Edge Router.  Other
   information of interest to the host, such as DNS, is provided through
   stateful [RFC3315] and stateless [RFC3736] DHCPv6.

8.1.2.3.  Routing

   The WLAN Host/Router is configured with a default route that points
   to the Access Router.  No routing protocols are needed on these
   devices, which generally have limited resources.

   If the Access Router is owned by an Access Provider, then the Access
   Router can have a default route, pointing towards the SP Edge Router.
   The Edge Router runs the IGP used in the SP network such as OSPFv3 or
   IS-IS for IPv6.  The connected prefixes have to be redistributed.  If
   DHCP-PD is used, with every delegated prefix a static route is
   installed by the Edge Router.  For this reason the static routes must
   be redistributed.  Prefix summarization should be done at the Edge
   Router.

   If the Access Router is owned by the SP, then the Access Router will
   also run IPv6 IGP, and will be part of the SP IPv6 routing domain
   (OSPFv3 or IS-IS).  The connected prefixes have to be redistributed.
   If DHCP-PD is used, with every delegated prefix a static route is
   installed by the Access Router.  For this reason, the static routes
   must be redistributed.  Prefix summarization should be done at the
   Access Router.

8.1.3.  PPP-Based Model

   PPP Terminated Aggregation (PTA) and L2TPv2 Access Aggregation (LAA)
   models, as discussed in Sections 6.2.2 and 6.2.3, respectively, can
   also be deployed in IPv6 WLAN environment.

8.1.3.1.  PTA Model in IPv6 WLAN Environment

   While deploying the PTA model in IPv6 WLAN environment, the Access
   Router is Layer 3 aware and it has to be upgraded to support IPv6.
   Since the Access Router terminates the PPP sessions initiated by the
   WLAN Host/Router, it has to support PPPoE with IPv6.

   Figure 8.1.3.1 describes the PTA Model in IPv6 WLAN environment.

Top      Up      ToC       Page 62 
       Customer |             Access Provider        | Service Provider
       Premise  |                                    |
     +------+         +--+ +--------------+ +----------+ +------+
     |WLAN  |  ----   |  | |              | | Provider | |Edge  |
     |Host/ |-(WLAN)--|AP|-|Access Router |-| Network  |-|Router|=>SP
     |Router|  ----   |  | |              | |          | |      |Network
     +------+         +--+ +--------------+ +----------+ +------+
                                                           |
       |---------------------------|                    +------+
                   PPP                                  |AAA   |
                                                        |Server|
                                                        +------+

                                Figure 8.1.3.1

8.1.3.1.1.  IPv6 Related Infrastructure Changes

   IPv6 is deployed in this scenario by upgrading the following devices
   to dual stack: WLAN Host, WLAN Router (if present), Access Router,
   and Edge Router.

8.1.3.1.2.  Addressing

   The addressing techniques described in Section 6.2.2.2 apply to the
   IPv6 WLAN PTA scenario as well.

8.1.3.1.3.  Routing

   The routing techniques described in Section 6.2.2.3 apply to the IPv6
   WLAN PTA scenario as well.

8.1.3.2.  LAA Model in IPv6 WLAN Environment

   While deploying the LAA model in IPv6 WLAN environment, the Access
   Router is Layer 3 aware and has to be upgraded to support IPv6.  The
   PPP sessions initiated by the WLAN Host/Router are forwarded over the
   L2TPv2 tunnel to the aggregation point in the SP network.  The Access
   Router must have the capability to support L2TPv2 for IPv6.

   Figure 8.1.3.2 describes the LAA Model in IPv6 WLAN environment.

Top      Up      ToC       Page 63 
       Customer |             Access Provider        | Service Provider
       Premise  |                                    |

     +------+         +--+ +--------------+ +----------+ +------+
     |WLAN  |  ----   |  | |              | | Provider | |Edge  |
     |Host/ |-(WLAN)--|AP|-|Access Router |-| Network  |-|Router|=>SP
     |Router|  ----   |  | |              | |          | |      |Network
     +------+         +--+ +--------------+ +----------+ +------+
                                                           |
       |-------------------------------------------------- |
                               PPP                         |
                                    |--------------------- |
                                               L2TPv2      |
                                                        +------+
                                                        |AAA   |
                                                        |Server|
                                                        +------+

                                Figure 8.1.3.2

8.1.3.2.1.  IPv6 Related Infrastructure Changes

   IPv6 is deployed in this scenario by upgrading the following devices
   to dual stack: WLAN Host, WLAN Router (if present), Access Router,
   and Edge Router.

8.1.3.2.2.  Addressing

   The addressing techniques described in Section 6.2.3.2 apply to the
   IPv6 WLAN LAA scenario as well.

8.1.3.2.3.  Routing

   The routing techniques described in Section 6.2.3.3 apply to the IPv6
   WLAN LAA scenario as well.

8.2.  IPv6 Multicast

   The typical multicast services offered are video/audio streaming
   where the IPv6 WLAN Host joins a multicast group and receives the
   content.  This type of service model is well supported through PIM-
   SSM, which is enabled throughout the SP network.  MLDv2 is required
   for PIM-SSM support.  Vendors can choose to implement features that
   allow routers to map MLDv1 group joins to predefined sources.

Top      Up      ToC       Page 64 
   It is important to note that in the shared wireless environments,
   multicast can have a significant bandwidth impact.  For this reason,
   the bandwidth allocated to multicast traffic should be limited and
   fixed, based on the overall capacity of the wireless specification
   used in 802.11a, 802.11b, or 802.11g.

   The IPv6 WLAN Hosts can also join desired multicast groups as long as
   they are enabled to support MLDv1 or MLDv2.  If WLAN/Access Routers
   are used, then they have to be enabled to support MLDv1 and MLDv2 in
   order to process the requests of the IPv6 WLAN Hosts.  The WLAN/
   Access Router also needs to be enabled to support PIM-SSM in order to
   send PIM joins up to the Edge Router.  When enabling this
   functionality on a WLAN/Access Router, its limited resources should
   be taken into consideration.  Another option would be for the WLAN/
   Access Router to support MLD proxy routing.

   The Edge Router has to be enabled to support MLDv1 and MLDv2 in order
   to process the requests coming from the IPv6 WLAN Host or WLAN/Access
   Router (if present).  The Edge Router has also needs to be enabled
   for PIM-SSM in order to receive joins from IPv6 WLAN Hosts or WLAN/
   Access Router (if present), and send joins towards the SP core.

   MLD authentication, authorization, and accounting are usually
   configured on the Edge Router in order to enable the SP to do billing
   for the content services provided.  Further investigation should be
   made in finding alternative mechanisms that would support these
   functions.

   Concerns have been raised in the past related to running IPv6
   multicast over WLAN links.  Potentially these are the same kind of
   issues when running any Layer 3 protocol over a WLAN link that has a
   high loss-to-signal ratio, where certain frames that are multicast
   based are dropped when settings are not adjusted properly.  For
   instance, this behavior is similar to an IGMP host membership report,
   when done on a WLAN link with a high loss-to-signal ratio and high
   interference.

   This problem is inherited by WLAN that can impact both IPv4 and IPv6
   multicast packets; it is not specific to IPv6 multicast.

   While deploying WLAN (IPv4 or IPv6), one should adjust their
   broadcast/multicast settings if they are in danger of dropping
   application dependent frames.  These problems are usually caused when
   the AP is placed too far (not following the distance limitations),
   high interference, etc.  These issues may impact a real multicast
   application such as streaming video or basic operation of IPv6 if the
   frames were dropped.  Basic IPv6 communications uses functions such
   as Duplicate Address Detection (DAD), Router and Neighbor

Top      Up      ToC       Page 65 
   Solicitations (RS, NS), Router and Neighbor Advertisement (RA, NA),
   etc., which could be impacted by the above mentioned issues as these
   frames are Layer 2 Ethernet multicast frames.

   Please refer to Section 6.3 for more IPv6 multicast details.

8.3.  IPv6 QoS

   Today, QoS is done outside of the WiFi domain, but it is nevertheless
   important to the overall deployment.

   The QoS configuration is particularly relevant on the Edge Router in
   order to manage resources shared amongst multiple subscribers
   possibly with various service level agreements (SLAs).  However, the
   WLAN Host/Router and Access Router could also be configured for QoS.
   This includes support for appropriate classification criteria, which
   would need to be implemented for IPv6 unicast and multicast traffic.

   On the Edge Router, the subscriber-facing interfaces have to be
   configured to police the inbound customer traffic and shape the
   traffic outbound to the customer, based on the SLA.  Traffic
   classification and marking should also be done on the Edge Router in
   order to support the various types of customer traffic: data, voice,
   and video.  The same IPv4 QoS concepts and methodologies should be
   applied for the IPv6 as well.

   It is important to note that when traffic is encrypted end-to-end,
   the traversed network devices will not have access to many of the
   packet fields used for classification purposes.  In these cases,
   routers will most likely place the packets in the default classes.
   The QoS design should take into consideration this scenario and try
   to use mainly IP header fields for classification purposes.

8.4.  IPv6 Security Considerations

   There are limited changes that have to be done for WLAN the Host/
   Router in order to enhance security.  The privacy extensions
   [RFC3041] for auto-configuration should be used by the hosts with the
   same consideration for host traceability as described in Section 6.5.
   IPv6 firewall functions should be enabled on the WLAN Host/Router, if
   present.

   The ISP provides security against attacks that come from its own
   subscribers, but it could also implement security services that
   protect its subscribers from attacks sourced from outside its
   network.  Such services do not apply at the access level of the
   network discussed here.

Top      Up      ToC       Page 66 
   If the host authentication at hotspots is done using a web-based
   authentication system, then the level of security would depend on the
   particular implementation.  User credentials should never be sent as
   clear text via HTTP.  Secure HTTP (HTTPS) should be used between the
   web browser and authentication server.  The authentication server
   could use RADIUS and LDAP services at the back end.

   Authentication is an important aspect of securing WLAN networks prior
   to implementing Layer 3 security policies.  For example, this would
   help avoid threats to the ND or stateless auto-configuration
   processes. 802.1x [IEEE8021X] provides the means to secure the
   network access; however, the many types of EAP (PEAP, EAP-TLS, EAP-
   TTLS, EAP-FAST, and LEAP) and the capabilities of the hosts to
   support some of the features might make it difficult to implement a
   comprehensive and consistent policy.

   The 802.11i [IEEE80211i] amendment has many components, the most
   obvious of which are the two new data-confidentiality protocols,
   Temporal Key Integrity Protocol (TKIP) and Counter-Mode/CBC-MAC
   Protocol (CCMP). 802.11i also uses 802.1X's key-distribution system
   to control access to the network.  Because 802.11 handles unicast and
   broadcast traffic differently, each traffic type has different
   security concerns.  With several data-confidentiality protocols and
   the key distribution, 802.11i includes a negotiation process for
   selecting the correct confidentiality protocol and key system for
   each traffic type.  Other features introduced include key caching and
   pre-authentication.

   The 802.11i amendment is a step forward in wireless security.  The
   amendment adds stronger encryption, authentication, and key
   management strategies that could make wireless data and systems more
   secure.

   If any Layer 2 filters for Ethertypes are in place, the NAP must
   permit the IPv6 Ethertype (0X86DD).

   The device that is the Layer 3 next hop for the subscribers (Access
   or Edge Router) should protect the network and the other subscribers
   against attacks by one of the provider customers.  For this reason
   uRPF and ACLs should be used on all interfaces facing subscribers.
   Filtering should be implemented with regard for the operational
   requirements of IPv6 [IPv6-Security].

   The Access and the Edge Router should protect their processing
   resources against floods of valid customer control traffic such as:
   RS, NS, and MLD Requests.  Rate limiting should be implemented on all

Top      Up      ToC       Page 67 
   subscriber-facing interfaces.  The emphasis should be placed on
   multicast-type traffic, as it is most often used by the IPv6 control
   plane.

8.5.  IPv6 Network Management

   The necessary instrumentation (such as MIB modules, NetFlow Records,
   etc) should be available for IPv6.

   Usually, NSPs manage the edge routers by SNMP.  The SNMP transport
   can be done over IPv4 if all managed devices have connectivity over
   both IPv4 and IPv6.  This would imply the smallest changes to the
   existing network management practices and processes.  Transport over
   IPv6 could also be implemented and it might become necessary if IPv6
   only islands are present in the network.  The management applications
   may be running on hosts belonging to the NSP core network domain.
   Network Management Applications should handle IPv6 in a similar
   fashion to IPv4; however, they should also support features specific
   to IPv6 (such as neighbor monitoring).

   In some cases, service providers manage equipment located on
   customers' LANs.

9.  Broadband Power Line Communications (PLC)

   This section describes the IPv6 deployment in Power Line
   Communications (PLC) Access Networks.  There may be other choices,
   but it seems that this is the best model to follow.  Lessons learnt
   from cable, Ethernet, and even WLAN access networks may be applicable
   also.

   Power Line Communications are also often called Broadband Power Line
   (BPL) and sometimes even Power Line Telecommunications (PLT).

   PLC/BPL can be used for providing, with today's technology, up to
   200Mbps (total, upstream+downstream) by means of the power grid.  The
   coverage is often the last half mile (typical distance from the
   medium-to-low voltage transformer to the customer premise meter) and,
   of course, as an in-home network (which is out of the scope of this
   document).

   The bandwidth in a given PLC/BPL segment is shared among all the
   customers connected to that segment (often the customers connected to
   the same medium-to-low voltage transformer).  The number of customers
   can vary depending on different factors, such as distances and even
   countries (from a few customers, just 5-6, up to 100-150).

Top      Up      ToC       Page 68 
   PLC/BPL could also be used in the medium voltage network (often
   configured as Metropolitan Area Networks), but this is also out of
   the scope of this document, as it will be part of the core network,
   not the access one.

9.1.  PLC/BPL Access Network Elements

   This section describes the different elements commonly used in PLC/
   BPL access networks.

   Head End (HE): Router that connects the PLC/BPL access network (the
   power grid), located at the medium-to-low voltage transformer, to the
   core network.  The HE PLC/BPL interface appears to each customer as a
   single virtual interface, all of them sharing the same physical
   media.

   Repeater (RPT): A device that may be required in some circumstances
   to improve the signal on the PLC/BPL.  This may be the case if there
   are many customers in the same segment or building.  It is often a
   bridge, but it could also be a router if, for example, there is a lot
   of peer-to-peer traffic in a building and due to the master-slave
   nature of the PLC/BPL technology, is required to improve the
   performance within that segment.  For simplicity within this
   document, the RPT will always be considered a transparent Layer 2
   bridge, so it may or may not be present (from the Layer 3 point of
   view).

   Customer Premise Equipment (CPE): Modem (internal to the host),
   modem/bridge (BCPE), router (RCPE), or any combination among those
   (i.e., modem+bridge/router), located at the customer premise.

   Edge Router (ER)

   Figure 9.1 depicts all the network elements indicated above.

   Customer Premise | Network Access Provider | Network Service Provider

    +-----+  +------+  +-----+        +------+   +--------+
    |Hosts|--| RCPE |--| RPT |--------+ Head +---+ Edge   |    ISP
    +-----+  +------+  +-----+        | End  |   | Router +=>Network
                                      +--+---+   +--------+
    +-----+  +------+  +-----+           |
    |Hosts|--| BCPE |--| RPT |-----------+
    +-----+  +------+  +-----+

                                    Figure 9.1

Top      Up      ToC       Page 69 
   The logical topology and design of PLC/BPL is very similar to
   Ethernet Broadband Networks as discussed in Section 7.  IP
   connectivity is typically provided in a Point-to-Point model, as
   described in Section 7.2.1

9.2.  Deploying IPv6 in IPv4 PLC/BPL

   The most simplistic and efficient model, considering the nature of
   the PLC/BPL networks, is to see the network as a point-to-point, one
   to each customer.  Even if several customers share the same physical
   media, the traffic is not visible among them because each one uses
   different channels, which are, in addition, encrypted by means of
   3DES.

   In order to maintain the deployment concepts and business models
   proven and used with existing revenue-generating IPv4 services, the
   IPv6 deployment will match the IPv4 one.  Under certain circumstances
   where new service types or service needs justify it, IPv4 and IPv6
   network architectures could be different.  Both approaches are very
   similar to those already described for the Ethernet case.

9.2.1.  IPv6 Related Infrastructure Changes

   In this scenario, only the RPT is Layer 3 unaware, but the other
   devices have to be upgraded to dual stack Hosts, RCPE, Head End, and
   Edge Router.

9.2.2.  Addressing

   The Hosts or the RCPEs have the HE as their Layer 3 next hop.

   If there is no RCPE, but instead a BCPE, all the hosts on the
   subscriber site belong to the same /64 subnet that is statically
   configured on the HE.  The hosts can use stateless auto-configuration
   or stateful DHCPv6-based configuration to acquire an address via the
   HE.

   If an RCPE is present:

   A.  It is statically configured with an address on the /64 subnet
       between itself and the HE, and with /64 prefixes on the
       interfaces connecting the hosts on the customer site.  This is
       not a desired provisioning method, being expensive and difficult
       to manage.

   B.  It can use its link-local address to communicate with the HE.  It
       can also dynamically acquire through stateless auto-configuration
       the address for the link between itself and the HE.  This step is

Top      Up      ToC       Page 70 
       followed by a request via DHCP-PD for a prefix shorter than /64
       (typically /48 [RFC3177]) that, in turn, is divided in /64s and
       assigned to its interfaces connecting the hosts on the customer
       site.  This should be the preferred provisioning method, being
       cheaper and easier to manage.

   The Edge Router needs to have a prefix, considering that each
   customer in general will receive a /48 prefix, and that each HE will
   accommodate customers.  Consequently, each HE will require n x /48
   prefixes.

   It could be possible to use a kind of Hierarchical Prefix Delegation
   to automatically provision the required prefixes and fully auto-
   configure the HEs, and consequently reduce the network setup,
   operation, and maintenance cost.

   The prefixes used for subscriber links and the ones delegated via
   DHCP-PD should be planned in a manner that allows as much
   summarization as possible at the Edge Router.

   Other information of interest to the host, such as DNS, is provided
   through stateful [RFC3315] and stateless [RFC3736] DHCPv6.

9.2.3.  Routing

   If no routers are used on the customer premise, the HE can simply be
   configured with a default route that points to the Edge Router.  If a
   router is used on the customer premise (RCPE), then the HE could also
   run an IGP (such as OSPFv3, IS-IS or even RIPng) to the ER.  The
   connected prefixes should be redistributed.  If DHCP-PD is used, with
   every delegated prefix a static route is installed by the HE.  For
   this reason, the static routes must also be redistributed.  Prefix
   summarization should be done at the HE.

   The RCPE requires only a default route pointing to the HE.  No
   routing protocols are needed on these devices, which generally have
   limited resources.

   The Edge Router runs the IPv6 IGP used in the NSP: OSPFv3 or IS-IS.
   The connected prefixes have to be redistributed, as well as any
   routing protocols (other than the ones used on the ER) that might be
   used between the HE and the ER.

Top      Up      ToC       Page 71 
9.3.  IPv6 Multicast

   The considerations regarding IPv6 Multicast for Ethernet are also
   applicable here, in general, assuming the nature of PLC/BPL is a
   shared media.  If a lot of Multicast is expected, it may be worth
   considering using RPT which are Layer 3 aware.  In that case, one
   extra layer of Hierarchical DHCP-PD could be considered, in order to
   facilitate the deployment, operation, and maintenance of the network.

9.4.  IPv6 QoS

   The considerations introduced for QoS in Ethernet are also applicable
   here.  PLC/BPL networks support QoS, which basically is the same
   whether the transport is IPv4 or IPv6.  It is necessary to understand
   that there are specific network characteristics, such as the
   variability that may be introduced by electrical noise, towards which
   the PLC/BPL network will automatically self-adapt.

9.5.  IPv6 Security Considerations

   There are no differences in terms of security considerations if
   compared with the Ethernet case.

9.6.  IPv6 Network Management

   The issues related to IPv6 Network Management in PLC networks should
   be similar to those discussed for Broadband Ethernet Networks in
   Section 7.6.  Note that there may be a need to define MIB modules for
   PLC networks and interfaces, but this is not necessarily related to
   IPv6 management.

10.  Gap Analysis

   Several aspects of deploying IPv6 over SP Broadband networks were
   highlighted in this document, aspects that require additional work in
   order to facilitate native deployments, as summarized below:

   A.  As mentioned in section 5, changes will need to be made to the
       DOCSIS specification in order for SPs to deploy native IPv6 over
       cable networks.  The CM and CMTS will both need to support IPv6
       natively in order to forward IPv6 unicast and multicast traffic.
       This is required for IPv6 Neighbor Discovery to work over DOCSIS
       cable networks.  Additional classifiers need to be added to the
       DOCSIS specification in order to classify IPv6 traffic at the CM
       and CMTS in order to provide QoS.  These issues are addressed in
       a recent proposal made to Cable Labs for DOCSIS 3.0
       [DOCSIS3.0-Reqs].

Top      Up      ToC       Page 72 
   B.  Section 6 stated that current RBE-based IPv4 deployment might not
       be the best approach for IPv6, where the addressing space
       available gives the SP the opportunity to separate the users on
       different subnets.  The differences between IPv4 RBE and IPv6 RBE
       were highlighted in Section 6.  If, however, support and reason
       are found for a deployment similar to IPv4 RBE, then the
       environment becomes NBMA and the new feature should observe
       RFC2491 recommendations.

   C.  Section 6 discussed the constraints imposed on an LAA-based IPv6
       deployment by the fact that it is expected that the subscribers
       keep their assigned prefix, regardless of LNS.  A deployment
       approach was proposed that would maintain the addressing schemes
       contiguous and offers prefix summarization opportunities.  The
       topic could be further investigated for other solutions or
       improvements.

   D.  Sections 6 and 7 pointed out the limitations (previously
       documented in [IPv6-Multicast]) in deploying inter-domain ASM;
       however, SSM-based services seem more likely at this time.  For
       such SSM-based services of content delivery (video or audio),
       mechanisms are needed to facilitate the billing and management of
       listeners.  The currently available feature of MLD AAA is
       suggested; however, other methods or mechanisms might be
       developed and proposed.

   E.  In relation to Section 8, concerns have been raised related to
       running IPv6 multicast over WLAN links.  Potentially, these are
       the same kind of issues when running any Layer 3 protocol over a
       WLAN link that has a high loss-to-signal ratio; certain frames
       that are multicast based are dropped when settings are not
       adjusted properly.  For instance this behavior is similar to an
       IGMP host membership report, when done on a WLAN link with high
       loss-to-signal ratio and high interference.  This problem is
       inherited by WLAN that can impact both IPv4 and IPv6 multicast
       packets; it is not specific to IPv6 multicast.

   F.  The privacy extensions were mentioned as a popular means to
       provide some form of host security.  ISPs can track relatively
       easily the prefixes assigned to subscribers.  If, however, the
       ISPs are required by regulations to track their users at host
       address level, the privacy extensions [RFC3041] can be
       implemented only in parallel with network management tools that
       could provide traceability of the hosts.  Mechanisms should be
       defined to implement this aspect of user management.

Top      Up      ToC       Page 73 
   G.  Tunnels are an effective way to avoid deployment dependencies on
       the IPv6 support on platforms that are out of the SP control
       (GWRs or CPEs) or over technologies that did not standardize the
       IPv6 support yet (cable).  They can be used in the following
       ways:

        i.  Tunnels directly to the CPE or GWR with public or private
            IPv4 addresses.

        ii. Tunnels directly to hosts with public or private IPv4
            addresses.  Recommendations on the exact tunneling
            mechanisms that can/should be used for last-mile access need
            to be investigated further and should be addressed by the
            IETF Softwire Working Group.

   H.  Through its larger address space, IPv6 allows SPs to assign
       fixed, globally routable prefixes to the links connecting each
       subscriber.

       This approach changes the provisioning methodologies that were
       used for IPv4.  Static configuration of the IPv6 addresses for
       all these links on the Edge Routers or Access Routers might not
       be a scalable option.  New provisioning mechanisms or features
       might need to be developed in order to deal with this issue, such
       as automatic mapping of VLAN IDs/PVCs (or other customer-specific
       information) to IPv6 prefixes.

   I.  New deployment models are emerging for the Layer 2 portion of the
       NAP where individual VLANs are not dedicated to each subscriber.
       This approach allows Layer 2 switches to aggregate more then 4096
       users.  MAC Forced Forwarding [RFC4562] is an example of such an
       implementation, where a broadcast domain is turned into an NBMA-
       like environment by forwarding the frames based on both Source
       and Destination MAC addresses.  Since these models are being
       adopted by the field, the implications of deploying IPv6 in such
       environments need to be further investigated.

   J.  The deployment of IPv6 in continuously evolving access service
       models raises some issues that may need further investigation.
       Examples of such topics are [AUTO-CONFIG]:

        i.  Network Service Selection & Authentication (NSSA) mechanisms
            working in association with stateless auto-configuration.
            As an example, NSSA relevant information, such as ISP
            preference, passwords, or profile ID, can be sent by hosts
            with the RS [RFC4191].

Top      Up      ToC       Page 74 
        ii. Providing additional information in Router Advertisements to
            help access nodes with prefix selection in multi-ISP/
            multi-homed environments.

   Solutions to some of these topics range from making a media access
   capable of supporting native IPv6 (cable) to improving operational
   aspects of native IPv6 deployments.

11.  Security Considerations

   Please refer to the individual "IPv6 Security Considerations"
   technology sections for details.

12.  Acknowledgements

   We would like to thank Brian Carpenter, Patrick Grossetete, Toerless
   Eckert, Madhu Sudan, Shannon McFarland, Benoit Lourdelet, and Fred
   Baker for their valuable comments.  The authors would like to
   acknowledge the structure and information guidance provided by the
   work of Mickles, et al., on "Transition Scenarios for ISP Networks"
   [ISP-CASES].

13.  References

13.1.  Normative References

   [RFC1918]         Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot,
                     G., and E. Lear, "Address Allocation for Private
                     Internets", BCP 5, RFC 1918, February 1996.

   [RFC2080]         Malkin, G. and R. Minnear, "RIPng for IPv6",
                     RFC 2080, January 1997.

   [RFC2364]         Gross, G., Kaycee, M., Lin, A., Malis, A., and J.
                     Stephens, "PPP Over AAL5", RFC 2364, July 1998.

   [RFC2461]         Narten, T., Nordmark, E., and W. Simpson, "Neighbor
                     Discovery for IP Version 6 (IPv6)", RFC 2461,
                     December 1998.

   [RFC2462]         Thomson, S. and T. Narten, "IPv6 Stateless Address
                     Autoconfiguration", RFC 2462, December 1998.

   [RFC2473]         Conta, A. and S. Deering, "Generic Packet Tunneling
                     in IPv6 Specification", RFC 2473, December 1998.

Top      Up      ToC       Page 75 
   [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.

   [RFC2529]         Carpenter, B. and C. Jung, "Transmission of IPv6
                     over IPv4 Domains without Explicit Tunnels",
                     RFC 2529, March 1999.

   [RFC2661]         Townsley, W., Valencia, A., Rubens, A., Pall, G.,
                     Zorn, G., and B. Palter, "Layer Two Tunneling
                     Protocol "L2TP"", RFC 2661, August 1999.

   [RFC2740]         Coltun, R., Ferguson, D., and J. Moy, "OSPF for
                     IPv6", RFC 2740, December 1999.

   [RFC2784]         Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
                     Traina, "Generic Routing Encapsulation (GRE)",
                     RFC 2784, March 2000.

   [RFC3041]         Narten, T. and R. Draves, "Privacy Extensions for
                     Stateless Address Autoconfiguration in IPv6",
                     RFC 3041, January 2001.

   [RFC3053]         Durand, A., Fasano, P., Guardini, I., and D. Lento,
                     "IPv6 Tunnel Broker", RFC 3053, January 2001.

   [RFC3056]         Carpenter, B. and K. Moore, "Connection of IPv6
                     Domains via IPv4 Clouds", RFC 3056, February 2001.

   [RFC3177]         IAB and IESG, "IAB/IESG Recommendations on IPv6
                     Address Allocations to Sites", RFC 3177,
                     September 2001.

   [RFC3180]         Meyer, D. and P. Lothberg, "GLOP Addressing in
                     233/8", BCP 53, RFC 3180, September 2001.

   [RFC3315]         Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
                     C., and M. Carney, "Dynamic Host Configuration
                     Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3618]         Fenner, B. and D. Meyer, "Multicast Source
                     Discovery Protocol (MSDP)", RFC 3618, October 2003.

   [RFC3704]         Baker, F. and P. Savola, "Ingress Filtering for
                     Multihomed Networks", BCP 84, RFC 3704, March 2004.

Top      Up      ToC       Page 76 
   [RFC3736]         Droms, R., "Stateless Dynamic Host Configuration
                     Protocol (DHCP) Service for IPv6", RFC 3736,
                     April 2004.

   [RFC3904]         Huitema, C., Austein, R., Satapati, S., and R. van
                     der Pol, "Evaluation of IPv6 Transition Mechanisms
                     for Unmanaged Networks", RFC 3904, September 2004.

   [RFC3931]         Lau, J., Townsley, M., and I. Goyret, "Layer Two
                     Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931,
                     March 2005.

   [RFC4001]         Daniele, M., Haberman, B., Routhier, S., and J.
                     Schoenwaelder, "Textual Conventions for Internet
                     Network Addresses", RFC 4001, February 2005.

   [RFC4029]         Lind, M., Ksinant, V., Park, S., Baudot, A., and P.
                     Savola, "Scenarios and Analysis for Introducing
                     IPv6 into ISP Networks", RFC 4029, March 2005.

   [RFC4191]         Draves, R. and D. Thaler, "Default Router
                     Preferences and More-Specific Routes", RFC 4191,
                     November 2005.

   [RFC4213]         Nordmark, E. and R. Gilligan, "Basic Transition
                     Mechanisms for IPv6 Hosts and Routers", RFC 4213,
                     October 2005.

   [RFC4214]         Templin, F., Gleeson, T., Talwar, M., and D.
                     Thaler, "Intra-Site Automatic Tunnel Addressing
                     Protocol (ISATAP)", RFC 4214, October 2005.

   [RFC4380]         Huitema, C., "Teredo: Tunneling IPv6 over UDP
                     through Network Address Translations (NATs)",
                     RFC 4380, February 2006.

13.2.  Informative References

   [6PE]             De Clercq, J., Ooms, D., Prevost, S., and F. Le
                     Faucheur, "Connecting IPv6 Islands across IPv4
                     Clouds with BGP", Work in Progress, December 2006.

   [AUTO-CONFIG]     Wen, H., Zhu, X., Jiang, Y., and R. Yan, "The
                     deployment of IPv6 stateless auto-configuration in
                     access network", 8th International Conference on
                     Telecommunications, ConTEL 2005, June 2005.

Top      Up      ToC       Page 77 
   [BSR]             Bhaskar, N., Gall, A., Lingard, J., and S. Venaas,
                     "Bootstrap Router (BSR) Mechanism for PIM", Work
                     in Progress, June 2006.

   [DOCSIS3.0-OSSI]  CableLabs, CL., "DOCSIS 3.0 OSSI Specification(CM-
                     SP-OSSIv3.0-D02-060504)", May 2006.

   [DOCSIS3.0-Reqs]  Droms, R., Durand, A., Kharbanda, D., and J-F.
                     Mule, "DOCSIS 3.0 Requirements for IPv6 Support",
                     Work in Progress, March 2006.

   [DynamicTunnel]   Palet, J., Diaz, M., and P. Savola, "Analysis of
                     IPv6 Tunnel End-point Discovery Mechanisms", Work
                     in Progress, January 2005.

   [IEEE80211i]      IEEE, "IEEE Standards for Information Technology:
                     Part 11: Wireless LAN Medium Access Control (MAC)
                     and Physical Layer (PHY) specifications, Amendment
                     6: Medium Access Control (MAC) Security
                     Enhancements", July 2004.

   [IEEE8021X]       IEEE, "IEEE Standards for Local and Metropolitan
                     Area Networks: Port based Network Access Control,
                     IEEE Std 802.1X-2001", June 2001.

   [IPv6-Multicast]  Savola, P., "IPv6 Multicast Deployment Issues",
                     Work in Progress, April 2004.

   [IPv6-Security]   Convery, S. and D. Miller, "IPv6 and IPv4 Threat
                     Comparison and Best-Practice Evaluation",
                     March 2004.

   [ISISv6]          Hopps, C., "Routing IPv6 with IS-IS", Work
                     in Progress, October 2005.

   [ISP-CASES]       Mickles, C., "Transition Scenarios for ISP
                     Networks", Work in Progress, September 2002.

   [Protocol41]      Palet, J., Olvera, C., and D. Fernandez,
                     "Forwarding Protocol 41 in NAT Boxes", Work
                     in Progress, October 2003.

   [RF-Interface]    CableLabs, CL., "DOCSIS 2.0(CM-SP-RFIv2.0-I10-
                     051209)", December 2005.

   [RFC4562]         Melsen, T. and S. Blake, "MAC-Forced Forwarding: A
                     Method for Subscriber Separation on an Ethernet
                     Access Network", RFC 4562, June 2006.

Top      Up      ToC       Page 78 
   [Softwire]        Dawkins, S., Ed., "Softwire Problem Statement",
                     Work in Progress, May 2006.

   [v6tc]            Palet, J., Nielsent, K., Parent, F., Durand, A.,
                     Suryanarayanan, R., and P. Savola, "Goals for
                     Tunneling Configuration", Work in Progress,
                     August 2005.

Top      Up      ToC       Page 79 
Authors' Addresses

   Salman Asadullah
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Phone: 408 526 8982
   EMail: sasad@cisco.com


   Adeel Ahmed
   Cisco Systems
   2200 East President George Bush Turnpike
   Richardson, TX  75082
   USA

   Phone: 469 255 4122
   EMail: adahmed@cisco.com


   Ciprian Popoviciu
   Cisco Systems
   7025-6 Kit Creek Road
   Research Triangle Park, NC  27709
   USA

   Phone: 919 392 3723
   EMail: cpopovic@cisco.com


   Pekka Savola
   CSC - Scientific Computing Ltd.
   Espoo
   Finland

   EMail: psavola@funet.fi

Top      Up      ToC       Page 80 
   Jordi Palet Martinez
   Consulintel
   San Jose Artesano, 1
   Alcobendas, Madrid  E-28108
   Spain

   Phone: +34 91 151 81 99
   EMail: jordi.palet@consulintel.es

Top      Up      ToC       Page 81 
Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, 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, THE IETF TRUST 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 currently provided by the
   Internet Society.