RFC 4779
ISP IPv6 Deployment Scenarios in Broadband Access Networks
RFC 4779 💖 ISP IPv6 Deployment Scenarios in Broadband Access Networks
okay bestie, this one is a total glow-up doc for ISPs ✨ It's from the Network Working Group and it's labelled Category: Informational 🎀, so it's sharing info, not setting a standard.
- Authors: S. Asadullah, A. Ahmed, C. Popoviciu (Cisco Systems), P. Savola (CSC/FUNET), and J. Palet (Consulintel) 🫶
- Date: January 2007 📅
- Obsoletes/Updates: the header doesn't list anything it obsoletes or updates, so it stands on its own 🦋
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 IETF Trust (2007). 🌸
Abstract
This doc is a deep dive into IPv6 deployment in today's Service Provider (SP) Broadband (BB) networks, and it's all about how IPv6 gets along with the IPv4 services that are already running 🧚 The main BB technologies covered are Cable/HFC, BB Ethernet, xDSL, and WLAN 💜 It also talks about the emerging Broadband Power Line Communications (PLC/BPL) access technology, just for completeness 🌈
It goes over the main parts of IPv6 BB networks, how they're different from IPv4 BB networks, and how IPv6 gets deployed and integrated into each one. The methods include tunneling mechanisms and native IPv6 🔥
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Common Terminology . . . . . . . . . . . . . . . . . . . . . . 5
3. Core/Backbone Network . . . . . . . . . . . . . . . . . . . . 5
3.1. Layer 2 Access Provider Network . . . . . . . . . . . . . 5
3.2. Layer 3 Access Provider Network . . . . . . . . . . . . . 6
4. Tunneling Overview . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Access over Tunnels - Customers with Public IPv4
Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Access over Tunnels - Customers with Private IPv4
Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Transition a Portion of the IPv4 Infrastructure . . . . . 8
5. Broadband Cable Networks . . . . . . . . . . . . . . . . . . . 9
5.1. Broadband Cable Network Elements . . . . . . . . . . . . . 9
5.2. Deploying IPv6 in Cable Networks . . . . . . . . . . . . . 10
5.2.1. Deploying IPv6 in a Bridged CMTS Network . . . . . . . 12
5.2.2. Deploying IPv6 in a Routed CMTS Network . . . . . . . 14
5.2.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . 23
5.2.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . 24
5.2.5. IPv6 Security Considerations . . . . . . . . . . . . . 24
5.2.6. IPv6 Network Management . . . . . . . . . . . . . . . 25
6. Broadband DSL Networks . . . . . . . . . . . . . . . . . . . . 26
6.1. DSL Network Elements . . . . . . . . . . . . . . . . . . . 26
6.2. Deploying IPv6 in IPv4 DSL Networks . . . . . . . . . . . 28
6.2.1. Point-to-Point Model . . . . . . . . . . . . . . . . . 29
6.2.2. PPP Terminated Aggregation (PTA) Model . . . . . . . . 30
6.2.3. L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 33
6.2.4. Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 36
6.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 38
6.3.1. ASM-Based Deployments . . . . . . . . . . . . . . . . 39
6.3.2. SSM-Based Deployments . . . . . . . . . . . . . . . . 39
6.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 41
6.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 42
7. Broadband Ethernet Networks . . . . . . . . . . . . . . . . . 42
7.1. Ethernet Access Network Elements . . . . . . . . . . . . . 42
7.2. Deploying IPv6 in IPv4 Broadband Ethernet Networks . . . . 43
7.2.1. Point-to-Point Model . . . . . . . . . . . . . . . . . 44
7.2.2. PPP Terminated Aggregation (PTA) Model . . . . . . . . 46
7.2.3. L2TPv2 Access Aggregation (LAA) Model . . . . . . . . 48
7.2.4. Hybrid Model for IPv4 and IPv6 Service . . . . . . . . 50
7.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 52
7.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 53
7.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 54
7.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 55
8. Wireless LAN . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.1. WLAN Deployment Scenarios . . . . . . . . . . . . . . . . 55
8.1.1. Layer 2 NAP with Layer 3 termination at NSP Edge
Router . . . . . . . . . . . . . . . . . . . . . . . . 56
8.1.2. Layer 3 Aware NAP with Layer 3 Termination at
Access Router . . . . . . . . . . . . . . . . . . . . 59
8.1.3. PPP-Based Model . . . . . . . . . . . . . . . . . . . 61
8.2. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 63
8.3. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 65
8.4. IPv6 Security Considerations . . . . . . . . . . . . . . . 65
8.5. IPv6 Network Management . . . . . . . . . . . . . . . . . 67
9. Broadband Power Line Communications (PLC) . . . . . . . . . . 67
9.1. PLC/BPL Access Network Elements . . . . . . . . . . . . . 68
9.2. Deploying IPv6 in IPv4 PLC/BPL . . . . . . . . . . . . . . 69
9.2.1. IPv6 Related Infrastructure Changes . . . . . . . . . 69
9.2.2. Addressing . . . . . . . . . . . . . . . . . . . . . . 69
9.2.3. Routing . . . . . . . . . . . . . . . . . . . . . . . 70
9.3. IPv6 Multicast . . . . . . . . . . . . . . . . . . . . . . 71
9.4. IPv6 QoS . . . . . . . . . . . . . . . . . . . . . . . . . 71
9.5. IPv6 Security Considerations . . . . . . . . . . . . . . . 71
9.6. IPv6 Network Management . . . . . . . . . . . . . . . . . 71
10. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 71
11. Security Considerations . . . . . . . . . . . . . . . . . . . 74
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 74
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 74
13.1. Normative References . . . . . . . . . . . . . . . . . . . 74
13.2. Informative References . . . . . . . . . . . . . . . . . . 761. Introduction 🌸
okay so this section sets the whole vibe 💅 It's about the options for deploying IPv6 services in the access part of a BB Service Provider (SP) network. The access options are Cable/HFC, BB Ethernet, xDSL, WLAN, and PLC/BPL 🦋
The doc also gives a quick look at the other elements of a provider network. It covers different viable IPv6 deployment and integration techniques, plus models for each of those BB technologies on their own. The example list isn't exhaustive, but it tries to be representative 🧚
It also analyzes how all the important components of today's IPv4-based Cable/HFC, BB Ethernet, xDSL, WLAN, and PLC/BPL networks will behave once IPv6 is integrated and deployed 👑
The important pieces it talks about are:
- A. Available tunneling options
- B. Devices that would have to be upgraded to support IPv6
- C. Available IPv6 address assignment techniques and their use
- D. Possible IPv6 Routing options and their use
- E. IPv6 unicast and multicast packet transmission
- F. Required IPv6 Quality of Service (QoS) parameters
- G. Required IPv6 Security parameters
- H. Required IPv6 Network Management parameters
⚠️ Important tea: the addressing rules in this doc are an example that follows the current assignment policies and recommendations of the registries. ISPs can adapt them to fit their own network and business model needs 💖
The scope is all about advising on ways to upgrade an existing infrastructure so it can support IPv6 services 🎀 Upgrading a device to dual stack doesn't stop an SP from adding a new device to its network to do the necessary IPv6 functions discussed here. And honestly? The costs of that approach could be offset by a lower impact on the existing IPv4 services 🫶
2. Common Terminology 📖
the glossary, bestie 💜
- BB: Broadband
- CPE: Customer Premise Equipment
- GWR: Gateway Router
- ISP: Internet Service Provider
- NAP: Network Access Provider
- NSP: Network Service Provider
- QoS: Quality of Service
- SP: Service Provider
3. Core/Backbone Network 🍓
this section is a quick peek at the core 🧚 It covers the provider-network bits that matter for IPv6 deployment. A more detailed description of the core network is in other documents [RFC4029] 🌈
There are two types of networks in BB deployments:
- A. Access Provider Network: this network gives broadband access and aggregates the subscribers. The subscriber traffic is handed over to the Service Provider at Layer 2 or 3 ✨
- B. Service Provider Network: this network gives Intranet and Internet IP connectivity to the subscribers 🦋
The Service Provider network structure beyond the Edge Routers that interface with the Access provider is out of scope for this doc 💅
3.1. Layer 2 Access Provider Network 🫧
this is the one where the access provider just vibes at Layer 2 🌷 The Access Provider can deploy a Layer 2 network and do no routing of the subscriber traffic to the SP 💖
The devices that support each specific access technology get aggregated into a highly redundant, resilient, and scalable Layer 2 core. That core can involve various technologies, like Ethernet, Asynchronous Transfer Mode (ATM), etc. 🎀 The Service Provider Edge Router connects to the Access Provider core 🛤️
This type of network may be transparent to the Layer 3 protocol 👑 Some changes may come up to support IPv6 provisioning mechanisms, and also to filter and monitor IPv6 traffic based on Layer 2 information. That includes the IPv6 Ether Type Protocol ID 0x86DD or the IPv6 multicast specific Media Access Control (MAC) addresses 33:33:xx:xx:xx:xx 🔥😭
3.2. Layer 3 Access Provider Network ✨
okay so the Access Provider can also choose to terminate the Layer 2 domain and route the IP traffic straight to the Service Provider network 🛣️ Access Routers pick up all the subscriber traffic, aggregate it, and send it over a Layer 3 core to the SP Edge Routers 💅 And in this setup, the impact of the IPv6 deployment is significant 😭
The case studies in this doc only look at the parts that matter here: Customer Premise Equipment, Access Router, and Edge Router 🎀 In real networks, the link between the Access Router and the Edge Router has other routers in the middle, which are part of the aggregation and core layers of the Access Provider network. Those get skipped for now 🌸
The Access Provider can push IPv6 traffic through its Layer 3 core in three possible ways:
- A. IPv6 Tunneling: As a temporary fix, the Access Provider can wrap the subscriber IPv6 traffic in a tunnel to the Service Provider Edge Router 🦋 This has the least impact on the Access Provider network, BUT as more users join and the IPv6 traffic grows, the ISP will have to level up to one of the scenarios below 📈
- B. Native IPv6 Deployment: The Access Provider routers get upgraded to support IPv6 and become dual stack 👑 In a dual-stack network, an IPv6 Interior Gateway Protocol (IGP) gets turned on, like OSPFv3 [RFC2740] or IS-IS [ISISv6]. [RFC4029] digs into the IGP selection options, including their benefits and drawbacks 🧚
- C. MPLS 6PE Deployment [6PE]: If the Access Provider already runs MPLS in its IPv4 core, it can use 6PE to forward IPv6 traffic across it 💜 Only a subset of routers near the edge of the network need to be IPv6 aware here, and BGP becomes important to make 6PE work 🫶
The 6PE approach is super chill because it has minimal impact on the Access Provider network 🌈 Fewer devices need upgrading and configuring, and the MPLS core just keeps switching traffic, totally unaware that it's carrying both IPv4 and IPv6 💅 6PE should only be used if MPLS is already deployed in the network. At the time of writing, the big downside of 6PE is that it does not support multicast IPv6 traffic 💀
The native approach, on the other hand, supports IPv6 multicast traffic ✨ but it may mean a big impact on the IPv4 operational network, in terms of software configuration and possibly hardware upgrades 🔥
More detailed Core Network deployment recommendations live in other documents [RFC4029]. The handling of IPv6 traffic in the Core of the Access Provider Network won't be covered for the rest of this document 🙈
4. Tunneling Overview 🦋
If SPs can't deploy native IPv6 yet, they might use tunneling-based transition mechanisms to kick off an IPv6 service, then move to native IPv6 deployment later 🌸
Several tunneling mechanisms were built specifically to carry IPv6 over existing IPv4 infrastructure 🎀 Quite a few of them have been standardized, and which one works best depends on the existing SP IPv4 network and how the IPv6 service is structured 💖 The requirements for the most suitable mechanisms are described in [v6tc], with more updates to follow. Deploying IPv6 with tunneling can involve as few changes to the network as upgrading software on the tunnel endpoints 🧚 A Service Provider could use tunneling to deploy IPv6 in the following scenarios:
4.1. Access over Tunnels - Customers with Public IPv4 Addresses 🌐
If the customer is a residential user, they can start the tunnel directly from their IPv6-capable host to a tunnel termination router sitting in the NAP or ISP network 💅 The SP gets to decide which tunnel type to use, but it should take into account whether that type is available on commonly used software running on the host machine 🫶 There are a bunch of tunneling mechanisms out there, including IPv6 Tunnel Broker [RFC3053], Connection of IPv6 Domains via IPv4 Clouds [RFC3056], Generic Packet Tunneling in IPv6 [RFC2473], ISATAP [RFC4214], Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC4213], and Transmission of IPv6 over IPv4 Domains without Explicit Tunnels [RFC2529]. Some are way more popular than others 👑 At the time of writing, the IETF Softwire Working Group was tasked with standardizing a single tunneling protocol [Softwire] for this use case ✨
If the end customer has a GWR installed, it can be used to originate the tunnel, which gives native IPv6 access to multiple hosts on the customer network 🌈 In this case, the GWR would need to be upgraded to dual stack to support IPv6 🔥 The GWR can be owned by either the customer or the SP 🧚
4.2. Access over Tunnels - Customers with Private IPv4 Addresses 🙈
If the end customer gets a private IPv4 address and needs to start a tunnel through Network Address Translation (NAT), techniques like 6to4 may not work, because they rely on a public IPv4 address 😭 In this case, unless the existing GWRs support protocol-41-forwarding [Protocol41], the end user might have to use tunnels that can operate through NATs, such as Teredo [RFC4380] 💜 Most GWRs support protocol-41-forwarding, which means hosts can start the tunnels themselves, and then the GWR isn't affected by the IPv6 service at all 🎀
The customer also has the option to start the tunnel from the device doing the NAT functionality (the GWR), similar to the GWR scenario in Section 4.1. This will mean hardware replacement or a software upgrade, plus a native IPv6 environment behind the GWR 🛠️
It's also worth noting that initiating an IPv6 tunnel over IPv4 through IPv4 IPsec sessions that are already established would give the IPv6 traffic a certain level of security 🔐🫶
4.3. Transition a Portion of the IPv4 Infrastructure 🦋
Tunnels can also carry IPv6 traffic across a defined segment of the network 🛣️ For example, the customer might connect natively to the Network Access Provider, and then a tunnel transits the traffic over IPv4 to the ISP 💅 In this case, the tunnel choice depends on its capabilities (like whether or not it supports multicast), the routing protocols used (there are several types that can transport Layer 2 messages, such as GRE [RFC2784], L2TPv3 [RFC3931], or pseudowire), manageability, and scalability (dynamic versus static tunnels) ✨
This scenario means the access portion of the network has already been upgraded to support dual stack, so the savings from tunneling here are very small compared with the previous two scenarios 😬 Depending on how many sites need the service, and the costs of managing the tunnels (some tunnels are static while others are dynamic [DynamicTunnel]), SPs might find the native approach is worth the extra investment 💖
In all the scenarios above, the tunnel selection process should consider IPv6 multicast forwarding capabilities if that service is planned 🔥 For example, 6to4 tunnels do not support IPv6 multicast traffic 💀
The operation, capabilities, and deployment of the various tunnel types have been discussed extensively in the documents referenced earlier, as well as in [RFC4213] and [RFC3904] 📚 The next section of this document covers a tunnel-based deployment in Cable Access, where the current Data Over Cable Service Interface Specification (DOCSIS 2.0) [RF-Interface] and earlier specifications don't support native IPv6 access 🎀 Sections 6, 7, 8, and 9 focus on native IPv6 deployments over DSL, Fiber to the Home (FTTH), wireless, and PLC/BPL. Since this approach is fully supported today, tunnel-based solutions are also possible in those cases, following the guidelines in this section and some of the recommendations in Section 5 🌈
5. Broadband Cable Networks 🎀
This section describes the infrastructure that exists today in cable networks providing BB services to the home 🏠 It also describes IPv6 deployment options in these cable networks ✨
DOCSIS standardizes and documents how data gets carried over cable networks 📜 DOCSIS 2.0 and earlier specifications have limitations that stop a smooth implementation of native IPv6 transport 😭 Some of those limitations are discussed in this section. Because of that, the IPv6 deployment scenarios for existing cable networks in this section are tunnel based 💅 The tunneling examples here could also be applied to the other BB technologies described in Sections 6, 7, 8, and 9 🫶
5.1. Broadband Cable Network Elements 🔌
Broadband cable networks can carry IP traffic to and from users, which gives them high-speed Internet access and Voice over IP (VoIP) services 🌸 The mechanism for carrying IP traffic over cable networks is outlined in the DOCSIS specification [RF-Interface] 📜
Here are some of the key elements of a cable network 💖
- Cable (HFC) Plant: Hybrid Fiber Coaxial plant, used as the underlying transport
- CMTS: Cable Modem Termination System (can be a Layer 2 bridging or Layer 3 routing CMTS)
- GWR: Residential Gateway Router (provides Layer 3 services to hosts)
- Host: PC, notebook, etc., which is connected to the CM or GWR
- CM: Cable Modem
- ER: Edge Router
- MSO: Multiple Service Operator
- Data Over Cable Service Interface Specification (DOCSIS): Standards defining how data should be carried over cable networks
Figure 5.1 shows the key elements of a Cable Network 🦋
|--- ACCESS ---||------ HFC ------||----- Aggregation / Core -----|
+-----+ +------+
|Host |--| GWR |
+-----+ +--+---+
| _ _ _ _ _ _
+------+ | |
| CM |---| |
+------+ | |
| HFC | +------+ +--------+
| | | | | Edge |
+-----+ +------+ | Network |---| CMTS |---| |=>ISP
|Host |--| CM |---| | | | | Router | Network
+-----+ +--+---+ | | +------+ +--------+
|_ _ _ _ _ _|
+------+ |
+-----+ | GWR/ | |
|Host |--| CM |---------+
+-----+ | |
+------+
Figure 5.15.2. Deploying IPv6 in Cable Networks 🎀
okay so one big reason an MSO wants IPv6 over its cable network is to make management way less of a headache 💅 IPv6 can be enabled on the CM, CMTS, and ER for management purposes. Right now parts of the cable infrastructure use IPv4 address space [RFC1918], but there's only a finite amount of that 😭 So IPv6 could be super useful in cable land by starting on the management plane and then focusing on the data plane for end-user services later. If you want more deets on using IPv6 for management in cable networks, check out Section 5.6.1 🧚
There are two deployment modes in current cable networks: a bridged CMTS environment and a routed CMTS environment. IPv6 can be deployed in both of these 🌈
- Bridged CMTS Network 🌸 In this scenario, both the CM and CMTS bridge all data traffic. Traffic to/from host devices is forwarded through the cable network to the ER. The ER then routes traffic through the ISP network to the Internet. The CM and CMTS support a certain degree of Layer 3 functionality for management purposes.
- Routed CMTS Network 🦋 In a routed network, the CMTS forwards IP traffic to/from hosts based on Layer 3 information using the IP source/destination address. The CM acts as a Layer 2 bridge for forwarding data traffic and supports some Layer 3 functionality for management purposes.
Some of the factors that hinder deployment of native IPv6 in current routed and bridged cable networks include:
- A. Changes need to be made to the DOCSIS specification [RF-Interface] to include support for IPv6 on the CM and CMTS. This is imperative for deploying native IPv6 over cable networks. 🔥
- B. Problems with IPv6 Neighbor Discovery (ND) on CM and CMTS. In IPv4, these devices rely on Internet Group Multicast Protocol (IGMP) join messages to track membership of hosts that are part of a particular IP multicast group. In order to support ND, a multicast-based process, the CM and CMTS will need to support IGMPv3/Multicast Listener Discovery Version 2 (MLDv2) or v1 snooping. 🙈
- C. Classification of IPv6 traffic in the upstream and downstream direction. The CM and CMTS will need to support classification of IPv6 packets in order to give them the appropriate priority and QoS. Service providers that wish to deploy QoS mechanisms also have to support classification of IPv6 traffic. 💜
Due to the above mentioned limitations in deployed cable networks, at the time of writing this document, the only option available for cable operators is to use tunneling techniques in order to transport IPv6 traffic over their current IPv4 infrastructure. The following sections will cover tunneling and native IPv6 deployment scenarios in more detail. ✨
5.2.1. Deploying IPv6 in a Bridged CMTS Network 🌷
In IPv4, the CM and CMTS act as Layer 2 bridges and forward all data traffic to/from the hosts and the ER. The hosts use the ER as their Layer 3 next hop. If there is a GWR behind the CM it can act as a next hop for all hosts and forward data traffic to/from the ER.
When deploying IPv6 in this environment, the CM and CMTS will continue to act as bridging devices in order to keep the transition smooth and reduce operational complexity. The CM and CMTS will need to bridge IPv6 unicast and multicast packets to/from the ER and the hosts. If there is a GWR connected to the CM, it will need to forward IPv6 unicast and multicast traffic to/from the ER.
IPv6 can be deployed in a bridged CMTS network either natively or via tunneling. This section discusses the native deployment model. The tunneling model is similar to ones described in Sections 5.2.2.1 and 5.2.2.2.
Figure 5.2.1 illustrates the IPv6 deployment scenario. 👀
+-----+ +-----+
|Host |--| GWR |
+-----+ +--+--+
| _ _ _ _ _ _
| +------+ | |
+--| CM |---| |
+------+ | |
| HFC | +------+ +--------+
| | | | | Edge |
+-----+ +------+ | Network |---| CMTS |--| |=>ISP
|Host |--| CM |---| | | | | Router |Network
+-----+ +------+ | | +------+ +--------+
|_ _ _ _ _ _|
|-------------||---------------------------------||---------------|
L3 Routed L2 Bridged L3 Routed
Figure 5.2.15.2.1.1. IPv6 Related Infrastructure Changes 🛠️
In this scenario, the CM and the CMTS bridge all data traffic so they will need to support bridging of native IPv6 unicast and multicast traffic. The following devices have to be upgraded to dual stack: Host, GWR, and ER. 💖
5.2.1.2. Addressing 📬
The proposed architecture for IPv6 deployment includes two components that must be provisioned: the CM and the host. Additionally if there is a GWR connected to the CM, it will also need to be provisioned. The host or the GWR use the ER as their Layer 3 next hop.
5.2.1.2.1. IP Addressing for CM
The CM will be provisioned in the same way as in currently deployed cable networks, using an IPv4 address on the cable interface connected to the MSO network for management functions. During the initialization phase, it will obtain its IPv4 address using Dynamic Host Configuration Protocol (DHCPv4), and download a DOCSIS configuration file identified by the DHCPv4 server.
5.2.1.2.2. IP Addressing for Hosts
If there is no GWR connected to the CM, the host behind the CM will get a /64 prefix via stateless auto-configuration or DHCPv6.
If using stateless auto-configuration, the host listens for routing advertisements (RAs) from the ER. The RAs contain the /64 prefix assigned to the segment. Upon receipt of an RA, the host constructs its IPv6 address by combining the prefix in the RA (/64) and a unique identifier (e.g., its modified EUI-64 (64-bit Extended Unique Identifier) format interface ID).
If DHCPv6 is used to obtain an IPv6 address, it will work in much the same way as DHCPv4 works today. The DHCPv6 messages exchanged between the host and the DHCPv6 server are bridged by the CM and the CMTS.
5.2.1.2.3. IP Addressing for GWR
The GWR can use stateless auto-configuration (RA) to obtain an address for its upstream interface, the link between itself and the ER. This step is followed by a request via DHCP-PD (Prefix Delegation) for a prefix shorter than /64, typically /48 [RFC3177], which in turn is divided into /64s and assigned to its downstream interfaces connecting to the hosts.
5.2.1.3. Data Forwarding 📡
The CM and CMTS must be able to bridge native IPv6 unicast and multicast traffic. The CMTS must provide IP connectivity between hosts attached to CMs, and must do so in a way that meets the expectation of Ethernet-attached customer equipment. In order to do that, the CM and CMTS must forward Neighbor Discovery (ND) packets between ER and the hosts attached to the CM.
Communication between hosts behind different CMs is always forwarded through the CMTS. IPv6 communication between the different sites relies on multicast IPv6 ND [RFC2461] frames being forwarded correctly by the CM and the CMTS.
In order to support IPv6 multicast applications across DOCSIS cable networks, the CM and bridging CMTS need to support IGMPv3/MLDv2 or v1 snooping. MLD is almost identical to IGMP in IPv4, only the name and numbers are changed. MLDv2 is identical to IGMPv3 and also supports ASM (Any-Source Multicast) and SSM (Source-Specific Multicast) service models. Implementation work on CM/CMTS should be minimal because the only significant difference between IPv4 IGMPv3 and IPv6 MLDv2 is the longer addresses in the protocol. 🦄
5.2.1.4. Routing 🗺️
The hosts install a default route that points to the ER or the GWR. No routing protocols are needed on these devices, which generally have limited resources. If there is a GWR present, it will also use static default route to the ER.
The ER runs an IGP such as 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 ER. For this reason, the static routes must also be redistributed. Prefix summarization should be done at the ER. 💅
5.2.2. Deploying IPv6 in a Routed CMTS Network 🌈
In an IPv4/IPv6 routed CMTS network, the CM still acts as a Layer 2 device and bridges all data traffic between its Ethernet interface and cable interface connected to the cable operator network. The CMTS acts as a Layer 3 router and may also include the ER functionality. The hosts and the GWR use the CMTS as their Layer 3 next hop.
When deploying IPv6, the CMTS/ER will need to either tunnel IPv6 traffic or natively support IPv6.
There are five possible deployment scenarios for IPv6 in a routed CMTS network:
- IPv4 Cable (HFC) Network 💜 In this scenario, the cable network, including the CM and CMTS, remain IPv4 devices. The host and ER are upgraded to dual stack. This is the easiest way for a cable operator to provide IPv6 service, as no changes are made to the cable network.
- IPv4 Cable (HFC) Network, GWR at Customer Site 🍓 In this case, the cable network, including the CM and CMTS, remain IPv4 devices. The host, GWR, and ER are upgraded to dual stack. This scenario is also easy to deploy since the cable operator just needs to add GWR at the customer site.
- Dual-stacked Cable (HFC) Network, CM, and CMTS Support IPv6 🔥 In this scenario, the CMTS is upgraded to dual stack to support IPv4 and IPv6. Since the CMTS supports IPv6, it can act as an ER as well. The CM will act as a Layer 2 bridge, but will need to bridge IPv6 unicast and multicast traffic. This scenario is not easy to deploy since it requires changes to the DOCSIS specification. The CM and CMTS may require hardware and software upgrades to support IPv6.
- Dual-stacked Cable (HFC) Network, Standalone GWR, and CMTS Support IPv6 🧚 In this scenario there is a stand-alone GWR connected to the CM. Since the IPv6 functionality exists on the GWR, the CM does not need to be dual stack. The CMTS is upgraded to dual stack and it can incorporate the ER functionality. This scenario may also require hardware and software changes on the GWR and CMTS.
- Dual-stacked Cable (HFC) Network, Embedded GWR/CM, and CMTS Support IPv6 😭 In this scenario, the CM and GWR functionality exists on a single device, which needs to be upgraded to dual stack. The CMTS will also need to be upgraded to a dual-stack device. This scenario is also difficult to deploy in existing cable network since it requires changes on the Embedded GWR/CM and the CMTS.
The DOCSIS specification will also need to be modified to allow native IPv6 support on the Embedded GWR/CM. ⚠️
5.2.2.1. IPv4 Cable Network, Host, and ER Upgraded to Dual Stack
okay so this is one of the most cost-effective ways for a cable operator to offer IPv6 to its customers 💅 Since the cable network stays IPv4, turning on IPv6 service doesn't cost much. All IPv6 traffic goes between the hosts and the ER 🦋
Figure 5.2.2.1 shows what this looks like 🌸
+-----------+ +------+ +--------+
+-----+ +-------+ | Cable | | | | Edge |
|Host |--| CM |----| (HFC) |---| CMTS |---| |=>ISP
+-----+ +-------+ | Network | | | | Router |Network
+-----------+ +------+ +--------+
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
IPv6-in-IPv4 tunnel
|---------||---------------------------------------||------------|
IPv4/v6 IPv4 only IPv4/v6
Figure 5.2.2.15.2.2.1.1. IPv6 Related Infrastructure Changes
in this one, the CM and the CMTS only need to support IPv4 🎀 so you don't have to touch them or the cable network at all. just the host and the ER need upgrading to dual stack: Host and ER ✨
5.2.2.1.2. Addressing
the only device at the customer site that needs an IPv6 address is the host 🫶 There are a bunch of ways to hand that address out. Depending on the tunneling mechanism, it could be automatic, or it might need manual configuration.
the host still gets its IPv4 address through DHCPv4, same as it does in cable networks that are already out there 💜 To actually get IPv6 connectivity, the host also needs an IPv6 address and some way to talk to the ER 🧚
5.2.2.1.3. Data Forwarding
all IPv6 traffic goes to and from the ER and the host 🌈 To carry IPv6 packets across the cable operator's IPv4 network, the host and the ER have to use one of the available IPv6-in-IPv4 tunneling mechanisms.
the host uses its IPv4 address as the source of the tunnel to the ER. All IPv6 traffic gets forwarded to the ER, wrapped up in IPv4 packets. The IPv4 nodes in the middle just forward that traffic like regular IPv4 packets 🦋 The ER is the one that terminates the tunnel and/or provides any other IPv6 services ✨
5.2.2.1.4. Routing
routing config on the host depends on which tunneling technique you use 💅 Sometimes you'll need a default or static route to push traffic to the next hop.
The ER runs an IGP such as OSPFv3 or ISIS 👑
5.2.2.2. IPv4 Cable Network, Host, GWR and ER Upgraded to Dual Stack
the cable operator can give its customers IPv6 in this one too, just by adding a GWR behind the CM 🎀 The GWR handles all the IPv6 traffic between the host and the ER, so the cable network (CM and CMTS included) doesn't need IPv6 support and can stay as IPv4 devices 🌸
Figure 5.2.2.2 shows the setup 🍓
+-----+
|Host |
+--+--+
| +-----------+ +------+ +--------+
+---+---+ +-------+ | Cable | | | | Edge |
| GWR |--| CM |----| (HFC) |---| CMTS |---| |=>ISP
+-------+ +-------+ | Network | | | | Router |Network
+-----------+ +------+ +--------+
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
IPv6-in-IPv4 tunnel
|---------||--------------------------------------||-------------|
IPv4/v6 IPv4 only IPv4/v6
Figure 5.2.2.25.2.2.2.1. IPv6 Related Infrastructure Changes
same vibe as before: the CM and the CMTS only need IPv4 🫶 so no changes to them or the cable network. The devices that have to be upgraded to dual stack are: Host, GWR, and ER 💖
5.2.2.2.2. Addressing
the only devices at the customer site that need an IPv6 address are the host and the GWR ✨ The GWR's downstream interface can have its IPv6 address assigned statically. The GWR sends out RA messages on that downstream interface, and the hosts use those to auto-configure themselves with an IPv6 address 🧚
The GWR can also set up its upstream interface using RA messages from the ER, and it can use DHCP-PD to request a /48 [RFC3177] prefix from the ER 🌈 That /48 is used to configure /64s on the hosts connected to the GWR's downstream interfaces. The uplink to the ISP network gets a /64 prefix too 🦋
The GWR still gets a global IPv4 address on its upstream interface through DHCPv4, same as in cable networks that already exist 💅 To reach the Internet over IPv6, the GWR has to communicate with the ER.
5.2.2.2.3. Data Forwarding
all IPv6 traffic goes to and from the ER and the GWR, and the GWR forwards IPv6 traffic to and from the host 🎀 To carry IPv6 packets over the cable operator's IPv4 network, the GWR and the ER need to use one of the available IPv6-in-IPv4 tunneling mechanisms. Once the tunnel is up, all IPv6 traffic has to go through it 💜
the GWR uses its IPv4 address as the source of the tunnel to the ER. The tunnel endpoint is the ER's IPv4 address. All IPv6 traffic is forwarded to the ER wrapped in IPv4 packets, and the IPv4 nodes in between forward it as regular IPv4 packets 🌸 If you're using 6to4 tunneling, the ER needs to support 6to4 relay functionality so the GWR (and therefore the hosts behind it) can reach IPv6 Internet 🔥
5.2.2.2.4. Routing
depending on the tunneling technique, the GWR and the ER might need some extra config 🧚 If the ER is also running a 6to4 relay service, a default route needs to be added to the GWR pointing to the ER, for all non-6to4 traffic 👑
if you're using manual tunneling, the GWR and the ER can use static routing or an IGP such as RIPng [RFC2080] 🌈 RIPng updates can be carried over a manual tunnel, but that doesn't work with 6to4 tunneling, because 6to4 doesn't support multicast 😭
customer routes can be carried to the ER using RIPng updates 🦋 The ER can advertise those routes in its IGP, and prefix summarization should be done at the ER ✨
If DHCP-PD is used for address assignment, a static route gets installed on the ER automatically for each delegated /48 prefix 💅 Those static routes need to be redistributed into the IGP at the ER, so there's no need for a routing protocol between the ER and the GWR 🫶
The ER runs an IGP such as OSPFv3 or ISIS 👑
5.2.2.3. Dual-Stacked Cable (HFC) Network, CM, and CMTS Support IPv6
this is the big one 🌈 The cable operator can offer native IPv6 services here, because the cable network (CMTS included) supports IPv6 💖 The ER functionality can live inside the CMTS, or it can sit on a separate router connected to the CMTS upstream interface. The CM needs to bridge IPv6 unicast and multicast traffic 🦋
Figure 5.2.2.3 shows the setup 🌸
+-----------+ +-------------+
+-----+ +-------+ | Cable | | CMTS / Edge |
|Host |--| CM |----| (HFC) |---| |=>ISP
+-----+ +-------+ | Network | | Router | Network
+-----------+ +-------------+
|-------||---------------------------||---------------|
IPv4/v6 IPv4/v6 IPv4/v6
Figure 5.2.2.35.2.2.3.1. IPv6 Related Infrastructure Changes
the CM still acts as a Layer 2 bridge, so it doesn't need to be dual stack 🎀 But it does need to support bridging of IPv6 unicast and multicast traffic, plus IGMPv3/MLDv2 or v1 snooping, and that requires changes in the DOCSIS specification 🔥 In this scenario, the devices that have to be upgraded to dual stack are: Host and CMTS/ER ✨
5.2.2.3.2. Addressing
in cable networks today, the CM gets a private IPv4 address through DHCPv4 for management 🫶 In an IPv6 environment, the CM keeps using an IPv4 address for management. The cable operator can also give the CM an IPv6 address for management, but the CM has to be upgraded to support that 💜
IPv6 address assignment for the CM and the host can be done via DHCP or stateless auto-configuration 🧚 If the CM uses an IPv4 address for management, it gets that address through DHCPv4, and the CMTS needs to act as a DHCPv4 relay agent. If the CM uses an IPv6 address for management, it can use DHCPv6 (with the CMTS acting as a DHCPv6 relay agent), or the CMTS can be statically configured with a /64 prefix and send out RA messages on the cable interface 🌈 The CMs connected to the cable interface can use those RA messages to auto-configure themselves with an IPv6 address. All CMs connected to the cable interface are in the same subnet 🦋
The hosts can get their IPv6 address via DHCPv6 or stateless auto-configuration 💅 With DHCPv6, the CMTS may need to act as a DHCPv6 relay agent and forward DHCP messages between the hosts and the DHCP server. With stateless auto-configuration, the CMTS is configured with multiple /64 prefixes and sends out RA messages to the hosts 🌸 If the CMTS isn't also acting as an ER, the RA messages come from the ER connected to the CMTS upstream interface. The CMTS needs to forward those RA messages downstream or act as an ND proxy ✨
5.2.2.3.3. Data Forwarding
all IPv6 traffic goes to and from the CMTS and the hosts 🎀 Data forwarding works the same way it does in cable networks that are already deployed 👑 The CMTS forwards IPv6 traffic to and from hosts based on the IP source and destination address 💖
5.2.2.3.4. Routing
no routing protocols are needed between the CMTS and the host, because the CM and host are directly connected to the CMTS cable interface 🫶 Since the CMTS supports IPv6, hosts use the CMTS as their Layer 3 next hop 🔥
If the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 or IS-IS 🌈
5.2.2.4. Dual-Stacked Cable (HFC) Network, Stand-Alone GWR, and CMTS Support IPv6 🎀
okay so in this one, the cable operator can give its customers IPv6 by slotting a GWR between the CM and the host 💅 the GWR handles the IPv6 chat between the host and the CMTS/ER. The CMTS gets upgraded to dual stack so it can do IPv6, and it can also be the ER 🧚 The CM just acts as a bridge for data traffic, so it does not need to support IPv6 at all. no cap, that's a lot less work for the CM 🫶
this is giving the same vibe as Section 5.2.2.2. the only real difference is that the ER lives on the CMTS instead of on a separate router in the cable operator network ✨
here's the picture 🦋
+-----------+ +-----------+
+------+ +-------+ +-------+ | Cable | |CMTS / Edge|
| Host |--| GWR |--| CM |---| (HFC) |---| |=>ISP
+------+ +-------+ +-------+ | Network | | Router |Network
+-----------+ +-----------+
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _()
IPv6-in-IPv4 tunnel
|-----------------||-----------------------------||--------------|
IPv4/v6 IPv4 IPv4/v6Figure 5.2.2.4 🌸
5.2.2.4.1. IPv6 Related Infrastructure Changes 🍓
since the CM still acts as a Layer 2 bridge, it doesn't need to be dual stack, and it doesn't need IPv6 support either 🙈 in this setup, only three devices need the upgrade: the Host, the GWR, and the CMTS/ER. that's the whole glow-up list 💜
5.2.2.4.2. Addressing 🌈
the CM still gets a private IPv4 address through DHCPv4, same as in today's cable networks, totally normal and iconic 🫶 the CMTS acts as a DHCPv4 relay agent.
the host and GWR get their addresses in a similar way to what's described in Section 5.2.2.2.2 ✨
5.2.2.4.3. Data Forwarding 🦋
data moves between the host and the CMTS/ER with the GWR doing the work, and it happens in a similar way to Section 5.2.2.2.3 💅
5.2.2.4.4. Routing 👑
routing here is very similar to the story in Section 5.2.2.2.4 ✨ the one new thing is that the CMTS now has the ER job too, so it's going to need to run an IGP like OSPFv3 or IS-IS 🔥
5.2.2.5. Dual-Stacked Cable (HFC) Network, Embedded GWR/CM, and CMTS Support IPv6 🧚
okay this is where it gets extra iconic 😭 the cable operator can give customers native IPv6 services, because the cable network, including the CM/Embedded GWR and the CMTS, all support IPv6 🌈 the ER can be built into the CMTS, or it can be its own router hooked up to the CMTS upstream interface. the CM/Embedded GWR acts as a Layer 3 device, bestie 💖
here's the picture 🦋
+-----------+ +-------------+
+-----+ +-----------+ | Cable | | CMTS / Edge |
|Host |---| CM / GWR |---| (HFC) |---| |=>ISP
+-----+ +-----------+ | Network | | Router |Network
+-----------+ +-------------+
|---------------------------------------------------------|
IPv4/v6Figure 5.2.2.5 🌸
5.2.2.5.1. IPv6 Related Infrastructure Changes 💜
since the CM/GWR acts as a Layer 3 device, IPv6 can be deployed end-to-end 🔥 in this one, the devices that need the dual stack upgrade are the Host, the CM/GWR, and the CMTS/ER 🎀
5.2.2.5.2. Addressing 🍓
since the CM/GWR is dual stack, it can get an IPv4 or IPv6 address through DHCP for management purposes 💅 and because the GWR functionality lives inside the CM, the CM/GWR needs an IPv6 address for moving data traffic.
IPv6 address assignment for the CM/GWR and the host can happen through DHCPv6 or DHCP-PD 🧚
if you go with DHCPv6, the CMTS needs to act as a DHCPv6 relay agent 🫶 the host and CM/GWR get IPv6 addresses from pools of /64 prefixes that are configured on the DHCPv6 server. the CMTS has to glean the useful info from the DHCP Offer messages (sent from the DHCP server to the DHCP clients, the host and the CM/GWR), kind of like it already does with DHCPv4 today ✨ all the CM/GWRs on the same cable interface of the CMTS belong to the same management /64 prefix. the hosts on that same cable interface can belong to different /64 customer prefixes, since the CMTS can have multiple /64 prefixes configured under its cable interfaces 🌈
DHCP-PD is also an option for IPv6 address assignment 👑 in that case, the CM/GWR uses stateless auto-configuration to give its upstream interface an IPv6 address, using the /64 prefix that the CMTS/ER sends in an RA message. once the CM/GWR has an IPv6 address on its upstream interface, it asks the CMTS/ER for a /48 [RFC3177] prefix and chops that /48 into /64s to hand out to hosts 🦋 the uplink to the ISP network is also configured with a /64 prefix 💖
5.2.2.5.3. Data Forwarding ✨
the host uses the CM/GWR as its Layer 3 next hop 💅 the CM/GWR forwards all IPv6 traffic to and from the CMTS/ER and the hosts. the CMTS/ER forwards IPv6 traffic to and from hosts based on the IP source and destination address 🧚
5.2.2.5.4. Routing 🌸
the CM/GWR can use a static default route that points to the CMTS/ER, or it can run a routing protocol like RIPng or OSPFv3 between itself and the CMTS 🎀 customer routes behind the CM/GWR can be carried up to the CMTS through routing updates.
if DHCP-PD is used for address assignment, a static route gets installed on the CMTS/ER automatically for each delegated /48 prefix 🔥 those static routes need to be redistributed into the IGP at the CMTS/ER, so there's no need for a routing protocol between the CMTS/ER and the GWR 🫶
if the CMTS is also acting as an ER, it runs an IGP such as OSPFv3 or IS-IS 👑
5.2.3. IPv6 Multicast 🦋
so to support IPv6 multicast apps across DOCSIS cable networks, the CM and bridging CMTS need to support IGMPv3/MLDv2 or v1 snooping 💜 MLD is almost identical to IGMP in IPv4, the only things that change are the name and the numbers, ngl 🙈 MLDv2 is almost identical to IGMPv3, and it also supports ASM (Any-Source Multicast) and SSM (Source-Specific Multicast) service models ✨
SSM is more suited for deployments where the SP wants to offer paid content to users (video or audio) 💰 these types of services are expected to be the main ones people care about. and honestly the simplicity of the SSM model often outweighs the scalability issues that an ASM model would solve 🌈 ASM is still an option though, and it's discussed in Section 6.3.1 🍓
the Layer 3 CM, GWR, and Layer 3 routed CMTS/ER need to be enabled with PIM-SSM, which requires defining and supporting IGMPv3/MLDv1 or v2 snooping, so they can track join and leave messages from the hosts 💖 another option is for the Layer 3 CM or GWR to support MLD proxy routing 🧚 and the Layer 3 next hop for the hosts needs to support MLD 🫶
for more IPv6 multicast details, check out Section 6.3 💅
5.2.4. IPv6 QoS 💅
IPv6 doesn't change or add any queuing or scheduling functions that already exist in the DOCSIS specifications 🙌 but the QoS mechanisms on the CMTS and CM do need to be IPv6 capable 🔥 that includes support for IPv6 classifiers, so data traffic to and from host devices can get classified into the right service flows and given the right priority ✨ the classification criteria need to be set up for both unicast and multicast traffic 🎀
traffic classification and marking should happen at the CM for upstream traffic, and at the CMTS/ER for downstream traffic 🦋 this helps support the different kinds of services: data, voice, and video 💜 the same IPv4 QoS concepts and methods should be applied to IPv6 too 🌸
⚠️ okay real talk: when traffic is encrypted end-to-end, the devices in the middle can't see a lot of the packet fields that are used for classification 😭 in those cases, routers will most likely put the packets in the default classes. so the QoS design should keep that scenario in mind and try to rely mainly on IP header fields for classification 🫶
5.2.5. IPv6 Security Considerations 🔐
security in a DOCSIS cable network is provided by Baseline Privacy Plus (BPI+) 🛡️ the only piece that depends on IP addresses is encrypted multicast 💫 semantically, multicast encryption would work the same way in an IPv6 environment as it does in IPv4 🌈 however, the DOCSIS specification will need some enhancements to support encrypted IPv6 multicast 🍓
there are only limited changes needed on hosts to boost security 💜 the privacy extensions [RFC3041] for auto-configuration should be used by hosts 🧚 IPv6 firewall functions can be turned on too, if they're available on the host or GWR 🔥
the ISP protects against attacks coming from its own subscribers, but it could also run security services that protect its subscribers from attacks sourced from outside its network 👑 those services don't apply at the access level of the network discussed here 💅
the CMTS/ER should protect the ISP network and the other subscribers from attacks by one of its own customers 😤 for this reason, Unicast Reverse Path Forwarding (uRPF) [RFC3704] and Access Control Lists (ACLs) should be used on all interfaces facing subscribers 🛡️ filtering should be done with regard for the operational requirements of IPv6 [IPv6-Security] ✨
the CMTS/ER should also protect its processing resources from floods of valid customer control traffic, such as Router and Neighbor Solicitations and MLD Requests 🌊
all the other security features used with the IPv4 service should be applied to IPv6 in a similar way 🫶
5.2.6. IPv6 Network Management 🧚
IPv6 can have lots of applications in cable networks 🌈 MSOs can start by putting IPv6 on the control plane and using it to manage the thousands of devices connected to the CMTS 💖 this is a great way to introduce IPv6 into a cable network 🎀 later on, the MSO can extend IPv6 to the data plane and use it to carry customer traffic as well as management traffic 👑
5.2.6.1. Using IPv6 for Management in Cable Networks
okay bestie, so IPv6 can be turned on in a cable network to manage devices like CM, CMTS, and ER 🦋 With advanced stuff like VoIP and Video-over-IP blowing up, MSOs are juggling a massive number of devices hooked up to the CMTS 😭 In IPv4, each of those gets an RFC1918 address just for management, and there's only a finite pile of those, so it's getting really hard to keep up 💀
By using IPv6 for management, MSOs can scale their management systems to fit their needs ✨ The CMTS/ER can be set up with a /64 management prefix that's shared by all the CMs on the CMTS cable interface 🎀 CMs can get addressed through stateless auto-configuration or DHCPv6. Once a CM gets a /64 prefix, it can configure itself with an IPv6 address, which is so iconic 💅
If there are devices behind the CM that the MSO needs to manage, another /64 prefix can be defined on the CMTS/ER 🌸 Those devices can also use stateless auto-configuration to give themselves an IPv6 address.
Traffic that comes from or goes to the management prefix should not cross the MSO's network boundaries 🔒
In this setup, IPv6 is only used for managing devices on the cable network. The CM won't need an IPv4 address for management anymore, as described in DOCSIS 3.0 [DOCSIS3.0-Reqs] 🫶
5.2.6.2. Updates to MIB Modules/Standards to Support IPv6
The current DOCSIS, PacketCable, and CableHome MIB modules are already designed to support IPv6 objects 🍓 So IPv6 won't add or change any of their functionality, which is honestly a vibe ✨ The Textual Convention used to represent the IP addresses in SMIv2 objects was updated [RFC4001], and a new Textual Convention, InetAddressType, was added to identify which type of IP address is used for the IP address objects in MIB modules 🧚
There are some exceptions, though 👀 The MIB modules that might need to add IPv6 support are defined in the DOCSIS 3.0 OSSI specification [DOCSIS3.0-OSSI] 💜
6. Broadband DSL Networks 🌐
This section walks through the IPv6 deployment options in today's high-speed DSL networks 🦋
6.1. DSL Network Elements
Digital Subscriber Line (DSL) broadband services give users IP connectivity over the existing twisted-pair telephone lines, called the local-loop 📞 There's a whole range of bandwidth on offer, depending on the quality of the line and the distance between the Customer Premise Equipment and the DSL Access Multiplexer (DSLAM) ✨
These are the network elements you'll typically find in a DSL network:
- DSL Modem: It can be a stand-alone device, be built into the host, include router functionality, and also be able to act as a CPE router 💖
- Customer Premise Router (CPR): It provides Layer 3 services for customer premise networks. It's usually there for firewalling and for splitting broadcast domains for a small business 🔥
- DSL Access Multiplexer (DSLAM): It terminates multiple twisted-pair telephone lines and aggregates them toward the BRAS 🌈
- Broadband Remote Access Server (BRAS): It aggregates or terminates multiple Permanent Virtual Circuits (PVCs) that match the subscriber DSL circuits 👑
- Edge Router (ER): It provides the Layer 3 interface to the ISP network 💅
Figure 6.1 shows all of the network elements we just mentioned 🎀
Customer Premise | Network Access Provider | Network Service Provider
CP NAP NSP
+-----+ +------+ +------+ +--------+
|Hosts|--|Router| +--+ BRAS +---+ Edge | ISP
+-----+ +--+---+ | | | | Router +==> Network
| | +------+ +--------+
+--+---+ |
| DSL +-+ |
|Modem | | |
+------+ | +-----+ |
+--+ | |
+------+ |DSLAM+--+
+-----+ | DSL | +--+ |
|Hosts|--+Modem +-+ +-----+
+-----+ +--+---+
Figure 6.16.2. Deploying IPv6 in IPv4 DSL Networks
There are three main design approaches for providing IPv4 connectivity over a DSL infrastructure 🧁
- Point-to-Point Model: Each subscriber connects to the DSLAM over a twisted pair and gets a unique PVC that links them to the service provider 🦋 These PVCs can be terminated at the BRAS or at the Edge Router. This design isn't super scalable if the PVCs aren't terminated as close to the DSLAM as possible (at the BRAS), because then a big pile of Layer 2 circuits has to be kept up over a huge chunk of the network 😩 The Layer 2 domains can be terminated at the ER in three ways:
A. In a common bridge group with a virtual interface that routes traffic out.
B. By enabling a Routed Bridged Encapsulation feature, so all users can be part of the same subnet. This is the most common way to deploy IPv4 over DSL, but it might not be the best choice in IPv6, where address availability isn't an issue 🌸
C. By terminating the PVC at Layer 3, so each PVC gets its own prefix. This is the approach that seems more suitable for IPv6, and it's covered in Section 6.2.1 ✨
None of these ways requires the CPE (DSL modem) to be upgraded 💖
- PPP Terminated Aggregation (PTA) Model: PPP sessions are opened between each subscriber and the BRAS. The BRAS terminates the PPP sessions and provides Layer 3 connectivity between the subscriber and the ISP. This model is covered in Section 6.2.2 🫶
- Layer 2 Tunneling Protocol (L2TP) Access Aggregation (LAA) Model: PPP sessions are opened between each subscriber and the ISP Edge Router. The BRAS tunnels the subscriber PPP sessions to the ISP by encapsulating them into L2TPv2 [RFC2661] tunnels 🎀 This model is covered in Section 6.2.3 🌈
In aggregation models, the BRAS terminates the subscriber PVCs and aggregates their connections before giving access to the ISP 🧚
To keep the deployment concepts and business models that already work for revenue-generating IPv4 services, the IPv6 deployment will match the IPv4 one 💜 This approach is covered in Sections 6.2.1 - 6.2.3, which describe current IPv4 over DSL broadband access deployments. If new service types or service needs justify it, the IPv4 and IPv6 network logical architectures could be different, as described in Section 6.2.4 👑
6.2.1. Point-to-Point Model
In this scenario, the Ethernet frames from the Host or the Customer Premise Router are bridged over the PVC assigned to the subscriber 🦋
Figure 6.2.1 describes the protocol architecture of this model 🍓
Customer Premise NAP NSP
|-------------------------| |---------------| |------------------|
+-----+ +-------+ +-----+ +--------+ +----------+
|Hosts|--+Router +--+ DSL +--+ DSLAM +--------+ Edge | ISP
+-----+ +-------+ |Modem| +--------+ | Router +=>Network
+-----+ +----------+
|----------------------------|
ATM
Figure 6.2.16.2.1.1. IPv6 Related Infrastructure Changes
In this scenario, the DSL modem and the entire NAP are Layer 3 unaware, so no changes are needed to support IPv6 🙈 The following devices have to be upgraded to dual stack: Host, Customer Router (if present), and Edge Router 🔥
6.2.1.2. Addressing
The Hosts or the Customer Routers have the Edge Router as their Layer 3 next hop 🧚
If there's no Customer Router, all the hosts on the subscriber site belong to the same /64 subnet, which is statically configured on the Edge Router for that subscriber PVC. The hosts can use stateless auto-configuration or stateful DHCPv6-based configuration to get an address through the Edge Router 💖
However, manual configuration for each customer is a provisioning challenge, so implementers are encouraged to develop mechanisms that automatically map the PVC (or some other customer-specific information) to an IPv6 subnet prefix, and advertise the customer-specific prefix to all the customers with minimal configuration 🌸
If a Customer Router is present:
A. It's statically configured with an address on the /64 subnet between itself and the Edge Router, and with /64 prefixes on the interfaces that connect the hosts on the customer site. This isn't a desired provisioning method, since it's expensive and difficult to manage 😩
B. It can use its link-local address to communicate with the ER. It can also dynamically acquire, through stateless auto-configuration, the prefix for the link between itself and the ER. This later option lets it contact a remote DHCPv6 server, if needed. After that, it makes a request via DHCP-PD for a prefix shorter than /64, which is then divided into /64s and assigned to its downstream interfaces 🦋
The Edge Router has a /64 prefix configured for each subscriber PVC. Each PVC should be enabled to relay DHCPv6 requests from the subscribers to DHCPv6 servers in the ISP network 🎀 PVCs that provide access for subscribers who use DHCP-PD as well have to be enabled to support that feature. The uplink to the ISP network is also configured with a /64 prefix ✨
The prefixes used for subscriber links and the ones delegated via DHCP-PD should be planned so they allow as much summarization as possible at the Edge Router 🧁
Other information of interest to the host, such as DNS, is provided through stateful DHCPv6 [RFC3315] and stateless DHCPv6 [RFC3736] 🌈
6.2.1.3. Routing
The CPE devices are 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 IPv6 IGP used in the NSP, which is OSPFv3 or IS-IS 👑 The connected prefixes have to be redistributed. If DHCP-PD is used, the Edge Router installs a static route for every delegated prefix, so those static routes must also be redistributed 🔥 Prefix summarization should be done at the Edge Router 🫶
6.2.2. PPP Terminated Aggregation (PTA) Model ✨
okay so the PTA model is built on PPP-based protocols, specifically PPPoA [RFC2364] and PPPoE [RFC2516] 🎀 The PPP sessions get started by the Customer Premise Equipment and then terminate at the BRAS. The BRAS authorizes the session, authenticates the subscriber, and hands out an IP address on behalf of the ISP. After that, it does Layer 3 routing of the subscriber traffic to the NSP Edge Router 🦋
when the NSP is also the NAP, the BRAS and the NSP Edge Router could literally be the same box and cover all of that functionality 💅
there are two types of PPP encapsulation you can use with this model 👑
A. Connection using PPPoA
Customer Premise NAP NSP
|--------------------| |----------------------| |----------------|
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----------+
+-----+ +-------+ +--------+ +----+-----+ +-----------+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
|--------------------------| +-----------+
PPPFigure 6.2.2.1
the PPP sessions are initiated by the Customer Premise Equipment 🌸 The BRAS authenticates the subscriber against a local or a remote database. Once the session is up, the BRAS gives the user an address and maybe a DNS server too. That info comes from the subscriber profile or from a DHCP server 🧚
this solution scales better than Point-to-Point, but there's only one PPP session per ATM PVC, so the subscriber can only pick one ISP service at a time 🥺
B. Connection using PPPoE
Customer Premise NAP NSP
|--------------------------| |-------------------| |---------------|
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----------+
|
+-----+ +-------+ +--------+ +-----+----+ +-----------+
|Hosts|--+Router +-----------+ DSLAM +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +----------+ | Router +=>O
| | R
|--------------------------------| +-----------+ E
PPPFigure 6.2.2.2
the operation of PPPoE is pretty similar to PPPoA, except that with PPPoE you can run multiple sessions over the same PVC 🫶 That means the subscriber can connect to multiple services at the same time 🔥 The hosts can start PPPoE sessions too. Just remember that PPPoE encapsulation reduces the IP MTU available for customer traffic because of the extra headers 💀
the network design and operation of the PTA model is the same no matter which PPP encapsulation type you pick 💖
6.2.2.1. IPv6 Related Infrastructure Changes 🛠️
in this scenario the BRAS is Layer 3 aware, and it has to be upgraded to support IPv6 🦋 Since the BRAS terminates the PPP sessions, it has to support these PPP protocols running with IPv6 🌈 The following devices have to be upgraded to dual stack: Host, Customer Router (if present), BRAS, and Edge Router 👑
6.2.2.2. Addressing 🎀
the BRAS terminates the PPP sessions and gives the subscriber an IPv6 address from the defined pool for that profile ✨ The subscriber profile for authorization and authentication can live on the BRAS or on an Authentication, Authorization, and Accounting (AAA) server. The Hosts or the Customer Routers use the BRAS as their Layer 3 next hop 💅
the PPP session can be started by a host or by a Customer Router 🌸 In the latter case, once the session is established with the BRAS and an address is negotiated for the uplink to the BRAS, DHCP-PD can be used to get prefixes for the Customer Router's other interfaces 🧚
the BRAS has to be enabled to support DHCP-PD and to relay the DHCPv6 requests of the hosts on the subscriber sites 🫶
the BRAS has /64 prefixes configured on the link to the Edge Router. The Edge Router links are also configured with /64 prefixes so they can provide connectivity to the rest of the ISP network 🦋
the prefixes used for subscribers, and the ones delegated via DHCP-PD, should be planned so they allow maximum summarization at the BRAS 🔥
other info the host cares about, like DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6 💜
6.2.2.3. Routing 🗺️
the CPE devices are configured with a default route that points to the BRAS router. No routing protocols are needed on these devices, which generally have limited resources 🥹
the BRAS runs an IGP toward the Edge Router: OSPFv3 or IS-IS. Since the addresses assigned to the PPP sessions are represented as connected host routes, connected prefixes have to be redistributed. If DHCP-PD is used, the Edge Router installs a static route for every delegated prefix. For this reason, the static routes must also be redistributed 😭 Prefix summarization should be done at the BRAS 💖
the Edge Router runs the IGP used in the ISP network: OSPFv3 or IS-IS 🌈
a separation between the routing domains of the ISP and the Access Provider is recommended if they're managed independently. Controlled redistribution will be needed between the Access Provider IGP and the ISP IGP 🎀
6.2.3. L2TPv2 Access Aggregation (LAA) Model 🌷
in the LAA model, the BRAS forwards the CPE-initiated session to the ISP over an L2TPv2 tunnel that's set up between the BRAS and the Edge Router 🦋 In this case, the ISP itself handles authentication, authorization, and subscriber configuration 👑 There are two types of PPP encapsulation you can use with this model 💅
A. Connection via PPPoA
Customer Premise NAP NSP
|--------------------| |----------------------| |----------------|
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
|----------------------------------------|
PPP
|------------|
L2TPv2Figure 6.2.3.1
B. Connection via PPPoE
Customer Premise NAP NSP
|--------------------------| |--------------------| |---------------|
+-----------+
| AAA |
+------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +----+------+
|Hosts|--+Router +-----------+ DSLAM +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +----------+ | Router +=>O
| | R
+-----------+ E
|-----------------------------------------------|
PPP
|--------------|
L2TPv2Figure 6.2.3.2
the network design and operation of the PTA model is the same regardless of which PPP encapsulation type is used 🫶
6.2.3.1. IPv6 Related Infrastructure Changes 🛠️
in this scenario, the BRAS forwards the PPP sessions the subscriber started over the L2TPv2 tunnel to the L2TP Network Server (LNS), which is the aggregation point in the ISP network 🌈 The L2TPv2 tunnel between the L2TP Access Concentrator (LAC) and the LNS can run over IPv6 or IPv4, and the BRAS has to support both of those capabilities 🔥 The following devices have to be upgraded to dual stack: Host, Customer Router, and Edge Router. If the tunnel is set up over IPv6, then the BRAS must be upgraded to dual stack too 💜
6.2.3.2. Addressing 💖
okay so the Edge Router is the one that terminates the PPP sessions, and it hands the subscriber an IPv6 address from the pool defined for that profile 🎀. The subscriber profile for authorization and authentication can live on the Edge Router or on an AAA server 🔐. The Hosts or the Customer Routers treat the Edge Router as their Layer 3 next hop ✨.
The PPP session can be started by a host or by a Customer Router 🦋. If it's a Customer Router, then once the session is up with the Edge Router, DHCP-PD can be used to grab prefixes for the Customer Router interfaces 💅. The Edge Router has to be enabled to support DHCP-PD and to relay the DHCPv6 requests that come from the hosts on the subscriber sites 🫶.
The BRAS has a /64 prefix configured on the link to the Edge Router 🌸. The Edge Router links are also configured with /64 prefixes so they can reach the rest of the ISP network 🌈. Anything else the host cares about, like DNS, comes through stateful [RFC3315] and stateless [RFC3736] DHCPv6 ✨.
Now for the big difference vs IPv4, and this is the tea 🍓. In IPv4, the customer router or CPE can end up on any Edge Router (acting as LNS), and the assumption is that there are at least two of them for redundancy 🙈. Once authenticated, the customer gets an address from the IP pool of whichever ER (LNS) it connected to, which lets the ERs (LNSs) aggregate the addresses they hand out 💜. With IPv6, an important constraint that will likely be enforced is that the customer keeps its own address no matter which ER (LNS) it connects to 😭. That could seriously reduce how well the ER (LNS) can aggregate prefixes 💀. Compare that to IPv4, where addressing is dynamic and the same user can get different addresses depending on which LNS they land on 🧚.
One possible fix is to make sure a given BRAS always connects to the same ER (LNS) unless that LNS is down ✨. That way customers from a given prefix range always land on the same ER: the primary if it's up, or the secondary if not 👑. Each ER (LNS) can carry summary statements in its routing protocol configuration for the prefixes it's primary for, as well as the ones it's secondary for 🦋. This way the prefixes get summarized any time they become "active" on the ER (LNS) 💖.
6.2.3.3. Routing 🛣️
The CPE devices are configured with a default route that points to the Edge Router that terminates the PPP sessions 🎀. No routing protocols are needed on these devices, which generally have limited resources 🥺.
The BRAS runs an IPv6 IGP to the Edge Router: OSPFv3 or IS-IS 💅. Different processes should be used if the NAP and the NSP are managed by different organizations 🫶. In that case, controlled redistribution should be enabled between the two domains 🔐.
The Edge Router is running the IPv6 IGP used in the ISP network: OSPFv3 or IS-IS ✨.
6.2.4. Hybrid Model for IPv4 and IPv6 Service 🧚
It was recommended throughout this section that the IPv6 service implementation should map the existing IPv4 one. This approach simplifies manageability and minimizes the training needed for personnel operating the network 📚. In certain circumstances, though, that mapping isn't feasible 🙃. This typically happens when a Service Provider plans to expand its service offering with the new IPv6 deployed infrastructure. If this new service isn't well supported in a network design like the one used for IPv4, then a different design might be used for IPv6 🌈.
An example of this is a provider using an LAA design for its IPv4 services 🐣. In this case, all the PPP sessions are bundled and tunneled across the entire NAP infrastructure, which is made of multiple BRAS routers, aggregation routers etc. The end point of these tunnels is the ISP Edge Router 🚇. If the provider decides to offer multicast services over such a design, it will face the problem of NAP resources being over utilized 😩. The multicast traffic can be replicated only at the end of the tunnels by the Edge Router, and the copies for all the subscribers are carried over the entire NAP 💀.
A Modified Point-to-Point (as described in Section 6.2.4.2) or PTA model is more suitable for multicast services, because the packet replication can be done closer to the destination at the BRAS 👑. Such a topology saves NAP resources 💖.
So in this sense, IPv6 deployment can be viewed as an opportunity to build an infrastructure that might better support the expansion of services ✨. In this case, an SP using the LAA design for its IPv4 services might choose a modified Point-to-Point or PTA design for IPv6 🦋.
6.2.4.1. IPv4 in LAA Model and IPv6 in PTA Model 🎀
The coexistence of the two PPP-based models, PTA and LAA, is relatively straightforward 🫶. The PPP sessions are terminated on different network devices for the IPv4 and IPv6 services. The PPP sessions for the existing IPv4 service, deployed in an LAA model, are terminated on the Edge Router. The PPP sessions for the new IPv6 service, deployed in a PTA model, are terminated on the BRAS 💅.
The logical design for IPv6 and IPv4 in this hybrid model is presented in Figure 6.2.4.1 🌸.
IPv6 |--------------------------|
PPP +-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
IPv4 |----------------------------------------|
PPP
|------------|
L2TPv2Figure 6.2.4.1
6.2.4.2. IPv4 in LAA Model and IPv6 in Modified Point-to-Point Model 🧚♀️
In this particular scenario, the Point-to-Point model used for the IPv6 service is a modified version of the model described in section 6.2.1 🌈.
For the IPv4 service in the LAA model, the PVCs are terminated on the BRAS, and the PPP sessions are terminated on the Edge Router (LNS). For IPv6 service in the Point-to-Point model, the PVCs are terminated at the Edge Router as described in Section 6.2.1 💜. In this hybrid model, the Point-to-Point link could be terminated on the BRAS, a NAP-owned device. The IPv6 traffic is then routed through the NAP network to the NSP 🚀. To make this hybrid model work, the BRAS has to be upgraded to a dual-stack router. The functionalities of the Edge Router, as described in Section 6.2.1, are now implemented on the BRAS 🙌.
Another aspect of this deployment model is that the BRAS has to be capable of distinguishing between the IPv4 PPP traffic that has to be bridged across the L2TPv2 tunnel and the IPv6 packets that have to be routed to the NSP 🫣. IPv6 Routing and Bridging Encapsulation (RBE) has to be enabled on all interfaces with PVCs supporting both IPv4 and IPv6 services in this hybrid design 🎀.
The logical design for IPv6 and IPv4 in this hybrid model is presented in Figure 6.2.4.2 🌸.
IPv6 |----------------|
ATM +-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ DSLAM +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
IPv4 |----------------------------------------|
PPP
|------------|
L2TPv2Figure 6.2.4.2
6.3. IPv6 Multicast 📡
The deployment of IPv6 multicast services relies on MLD, which is identical to IGMP in IPv4, and on PIM for routing 🔀. The ASM (Any Source Multicast) and SSM (Single Source Multicast) service models operate almost the same as in IPv4 💫. Both have the same benefits and disadvantages as in IPv4 ⚖️. Nevertheless, the larger address space and the scoped address architecture provide major benefits for multicast IPv6 🌟. Through RFC 3306, the large address space provides the means to assign global multicast group addresses to organizations or users that were assigned unicast prefixes. It's a significant improvement over the IPv4 GLOP mechanism [RFC3180] 🙌.
This facilitates the deployment of multicast services 🎉. The discussion in this section applies to all the multicast sections in the document 🫶.
6.3.1. ASM-Based Deployments 🎯
Any Source Multicast (ASM) is useful for Service Providers that intend to support the forwarding of multicast traffic of their customers 💅. It is based on the Protocol Independent Multicast - Sparse Mode (PIM-SM) protocol, and it's more complex to manage because of the use of Rendezvous Points (RPs) 😵💫. With IPv6, a static RP and a Bootstrap Router [BSR] can be used for RP-to-group mapping, similar to IPv4 🧠. Additionally, the larger IPv6 address space allows for building up group addresses that incorporate the address of the RP. This RP-to-group mapping mechanism is called Embedded RP, and it is specific to IPv6 ✨.
In inter-domain deployments, Multicast Source Discovery Protocol (MSDP) [RFC3618] is an important element of IPv4 PIM-SM deployments 🌐. MSDP is meant to be a solution for the exchange of source registration information between RPs in different domains. This solution was intended to be temporary 🕰️. This is one of the reasons why it was decided not to implement MSDP in IPv6 [IPv6-Multicast] 🙃.
For multicast reachability across domains, Embedded RP can be used 🦋. As Embedded RP provides roughly the same capabilities as MSDP, but in a slightly different way, the best management practices for ASM multicast with Embedded RP still remain to be developed 🚧.
6.3.2. SSM-Based Deployments ✨
okay so SSM deployments are giving simplicity 💅. Based on PIM-SSM, they don't need an RP or related protocols (like BSR or MSDP) 🌸, but they rely on the listeners to already know the source of the multicast traffic they want to receive. The lack of an RP makes SSM not only simpler to run, but also robust 🛡️. It isn't impacted by RP failures or inter-domain constraints, which is so iconic. It also has a higher level of security, because there's no RP to be targeted by attacks 🔒. For more discussion on IPv6 multicast, see [IPv6-Multicast] 🦋.
The typical multicast service for residential and very small businesses is video/audio streaming, where the subscriber joins a multicast group and receives the content 📺. This kind of service model is super well supported through PIM-SSM, which is very simple and easy to manage 💖. PIM-SSM has to be enabled throughout the SP network. MLDv2 is required for PIM-SSM support. Vendors can choose to implement features that let routers map MLDv1 group joins to predefined sources 🧚.
Subscribers might use a set-top box that handles the control piece of the multicast service (it does the group joins and leaves) 📦. Subscriber hosts can also join the groups they want, as long as they're enabled to support MLDv1 or MLDv2 🙌. If a customer premise router is used, then it has to be enabled to support MLDv1 and MLDv2 so it can process the requests from the hosts. It also has to be enabled to support PIM-SSM so it can send PIM joins and leaves up to its Layer 3 next hop, whether that's the BRAS or the Edge Router 🌈. When you turn this on for a CPR, its limited resources should be taken into consideration 🥺. Another option would be for the CPR to support MLD proxy routing ✨.
The router that is the Layer 3 next hop for the subscriber (BRAS in the PTA model, or the Edge Router in the LAA and Point-to-Point model) has to be enabled to support MLDv1 and MLDv2, so it can process requests coming from subscribers without CPRs 👑. It has to be enabled for PIM-SSM too, so it can receive joins and leaves from customer routers and send joins and leaves to the next hop towards the multicast source (the Edge Router or the NSP core) 💜.
MLD authentication, authorization and accounting are usually configured on the Edge Router 🍓. That lets the ISP control subscriber access to the service and do billing for the content provided 💅. Alternative mechanisms that would support these functions should be investigated further 🔍.
6.4. IPv6 QoS 🎀
The QoS configuration is especially relevant on the router that is the Layer 3 next hop for the subscriber (BRAS in the PTA model, or the Edge Router in the LAA and Point-to-Point model). That's where you manage resources shared among multiple subscribers, who might have various service level agreements 📊.
In the DSL infrastructure, it's expected that there's already a level of traffic policing and shaping implemented for IPv4 connectivity 🌸. This is implemented throughout the NAP and is beyond the scope of this document 🙈.
On the BRAS or the Edge Router, the subscriber-facing interfaces have to be configured to police the inbound customer traffic and shape the outbound traffic to the customer, based on the service level agreements (SLAs) ⭐. Traffic classification and marking should also be done on the router closest (at Layer 3) to the subscriber, so it can support the different types of customer traffic (data, voice, and video) and use the infrastructure resources optimally 🧚. Each provider (NAP, NSP) could implement its own QoS policies and services, so reclassification and marking might be performed at the boundary between the NAP and the NSP. That way the traffic is properly handled by the ISP 🦋. The same IPv4 QoS concepts and methodologies should be applied with IPv6 as well 💖.
It's important to note that when traffic is encrypted end-to-end, the network devices along the way won't have access to many of the packet fields used for classification 😭. In these cases, routers will most likely put the packets in the default classes 💀. The QoS design should take this scenario into consideration and try to use mainly IP header fields for classification 🫶.
6.5. IPv6 Security Considerations 🔐
There are limited changes that have to be made to CPEs to enhance security 🎀. The privacy extensions for auto-configuration [RFC3041] should be used by the hosts. ISPs can track the prefixes they assign to subscribers relatively easily 👀. If, however, the ISPs are required by regulation to track their users at a /128 address level, the privacy extensions may be implemented in parallel with network management tools that could provide traceability of the hosts 🕵️♀️. IPv6 firewall functions should be enabled on the hosts or the CPR, if one is present 🔥.
The ISP protects 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 don't apply at the access level of the network discussed here 🙅♀️.
The device that is the Layer 3 next hop for the subscribers (BRAS or Edge Router) should protect the network and the other subscribers against attacks by one of the provider's 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 BRAS and the Edge Router should protect their processing resources against floods of valid customer control traffic, such as Router and Neighbor Solicitations and MLD Requests 😤. Rate limiting should be implemented on all subscriber-facing interfaces 🚦. The emphasis should be placed on multicast-type traffic, since it's the kind most often used by the IPv6 control plane ✨.
All other security features used with the IPv4 service should be similarly applied to IPv6 as well 🫶.
6.6. 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, which is very chill 🧘♀️. 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. The management of equipment at customers' LANs is out of scope of this memo 🙈.
7. Broadband Ethernet Networks 🌐
This section describes the IPv6 deployment options in currently deployed Broadband Ethernet Access Networks 🦋.
7.1. Ethernet Access Network Elements 🔌
In environments that support the infrastructure deploying RJ-45 or fiber (Fiber to the Home (FTTH) service) to subscribers, 10/100 Mbps Ethernet broadband services can be provided 💖. Such services are generally available in metropolitan areas in multi-tenant buildings, where an Ethernet infrastructure can be deployed in a cost-effective manner 🏙️. In such environments, Metro-Ethernet services can be used to provide aggregation and uplink to a Service Provider ✨.
The following network elements are typical of an Ethernet network 📋:
- Access Switch: It is used as a Layer 2 access device for subscribers.
- Customer Premise Router: It is used to provide Layer 3 services for customer premise networks.
- Aggregation Ethernet Switches: Aggregates multiple subscribers.
- Broadband Remote Access Server (BRAS)
- Edge Router (ER)
Figure 7.1 depicts all the network elements mentioned 🧚.
Customer Premise | Network Access Provider | Network Service Provider
CP NAP NSP
+-----+ +------+ +------+ +--------+
|Hosts|--|Router| +-+ BRAS +--+ Edge | ISP
+-----+ +--+---+ | | | | Router +===> Network
| | +------+ +--------+
+--+----+ |
|Access +-+ |
|Switch | | |
+-------+ | +------+ |
+--+Agg E | |
+-------+ |Switch+-+
+-----+ |Access | +--+ |
|Hosts|--+Switch +-+ +------+
+-----+ +-------+
Figure 7.1The logical topology and design of Broadband Ethernet Networks are very similar to the DSL Broadband Networks discussed in Section 6 🌸.
It's worth noting that the general operation, concepts and recommendations described in this section apply similarly to a HomePNA-based network environment 🏠. In such an environment, some of the network elements might be named differently 💅.
7.2. Deploying IPv6 in IPv4 Broadband Ethernet Networks 🚀
There are three main design approaches to providing IPv4 connectivity over an Ethernet infrastructure 👑:
- A. Point-to-Point Model: Each subscriber connects to the network Access switch over RJ-45 or fiber links. Each subscriber is assigned a unique VLAN on the access switch. The VLAN can be terminated at the BRAS or at the Edge Router. The VLANs are 802.1Q trunked to the Layer 3 device (BRAS or Edge Router). This model is presented in Section 7.2.1.
- B. PPP Terminated Aggregation (PTA) Model: PPP sessions are opened between each subscriber and the BRAS. The BRAS terminates the PPP sessions and provides Layer 3 connectivity between the subscriber and the ISP. This model is presented in Section 7.2.2.
- C. L2TPv2 Access Aggregation (LAA) Model: PPP sessions are opened between each subscriber and the ISP termination devices. The BRAS tunnels the subscriber PPP sessions to the ISP by encapsulating them into L2TPv2 tunnels. This model is presented in Section 7.2.3.
In aggregation models, the BRAS terminates the subscriber VLANs and aggregates their connections before providing access to the ISP 🌈.
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 💰. This approach is presented in Sections 7.2.1 - 7.2.3, which describe currently deployed IPv4 over Ethernet broadband access deployments 📚. Under certain circumstances, where new service types or service needs justify it, IPv4 and IPv6 network architectures could be different, as described in Section 7.2.4 🦄.
7.2.1. Point-to-Point Model 🔗
In this scenario, the Ethernet frames from the Host or the Customer Premise Router are bridged over the VLAN assigned to the subscriber 🎀.
Figure 7.2.1 describes the protocol architecture of this model 🧩.
| Customer Premise | | NAP | NSP |
+-----+ +------+ +------+ +--------+ +----------+
|Hosts|--+Router+--+Access+--+ Switch +--------+ Edge | ISP
+-----+ +------+ |Switch| +--------+ 802.1Q | Router +=>Network
+------+ +----------+
|----------------------------|
Ethernet/VLANs
Figure 7.2.17.2.1.1. IPv6 Related Infrastructure Changes ✨
okay so in this setup the Access Switch sits on the customer site and the whole NAP is Layer 3 unaware 🫶, which means literally no changes are needed there for IPv6. the devices that need a glow-up to dual stack are the Host, the Customer Router, and the Edge Router 💅
the Access switches might need upgrades for some IPv6 features, like MLD Snooping 🦋
7.2.1.2. Addressing 🌸
Hosts or Customer Routers treat the Edge Router as their Layer 3 next hop 💖. If there's no Customer Router, all the hosts on the subscriber site live in the same /64 subnet, which is statically configured on the Edge Router for that subscriber VLAN. The hosts can use stateless auto-configuration or stateful DHCPv6-based configuration to grab an address via the Edge Router.
manual config for every customer is a whole provisioning nightmare 😭, so implementations are encouraged to build mechanism(s) that automatically map the VLAN (or some other customer-specific info) to an IPv6 subnet prefix, and then advertise that customer-specific prefix to all the customers with minimal config ✨.
If a Customer Router is present:
A. It's statically configured with an address on the /64 subnet between itself and the Edge Router, plus /64 prefixes on the interfaces connecting the hosts on the customer site. this is not the desired method, since it's expensive and hard to manage 💀.
B. It can use its link-local address to talk to the ER. It can also dynamically acquire, through stateless auto-configuration, the address for the link between itself and the ER. then it sends a request via DHCP-PD for a prefix shorter than /64, which gets split into /64s and assigned to its interfaces connecting the hosts on the customer site 🧚.
The Edge Router has a /64 prefix configured for each subscriber VLAN. each VLAN should be enabled to relay DHCPv6 requests from the subscribers to DHCPv6 servers in the ISP network. The VLANs providing access for subscribers that use DHCP-PD have to be enabled to support the feature. The uplink to the ISP network is configured with a /64 prefix as well.
The prefixes used for subscriber links and the ones delegated via DHCP-PD should be planned so that as much summarization as possible happens at the Edge Router 🎀.
Other info the host cares about, like DNS, comes through stateful [RFC3315] and stateless [RFC3736] DHCPv6 🍓.
7.2.1.3. Routing 🛣️
The CPE devices are 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 IPv6 IGP used in the NSP: OSPFv3 or IS-IS. The connected prefixes have to be redistributed. If DHCP-PD is used, the Edge Router installs a static route for every delegated prefix, so those static routes must also be redistributed. Prefix summarization should be done at the Edge Router 👑.
7.2.2. PPP Terminated Aggregation (PTA) Model 💜
the PTA architecture relies on PPP-based protocols (PPPoE). The PPP sessions are initiated by Customer Premise Equipment and terminated at the BRAS. The BRAS authorizes the session, authenticates the subscriber, and provides an IP address on behalf of the ISP. Then the BRAS does Layer 3 routing of the subscriber traffic to the NSP Edge Router 🦋.
When the NSP is also the NAP, the BRAS and the NSP Edge Router could be the same piece of equipment and provide all of the functionality above ✨.
The PPPoE logical diagram in an Ethernet Broadband Network is shown in Fig 7.2.2.1 💅.
| Customer Premise | | NAP | | NSP |
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----------+
+-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+
|Hosts|-+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O
|---------------- PPP ----------------| | | R
+-----------+ E
Figure 7.2.2.1The PPP sessions are initiated by the Customer Premise Equipment (Host or Router). The BRAS authenticates the subscriber against a local or remote database. Once the session is established, the BRAS provides an address and maybe a DNS server to the user, and this info is acquired from the subscriber profile or a DHCP server 🌈.
This model allows multiple PPPoE sessions over the same VLAN, so the subscriber can connect to multiple services at the same time 🙌. The hosts can initiate the PPPoE sessions as well. It's important to remember that the PPPoE encapsulation reduces the IP MTU available for the customer traffic ⚠️.
7.2.2.1. IPv6 Related Infrastructure Changes 🎀
In this scenario, the BRAS is Layer 3 aware and has to be upgraded to support IPv6. Since the BRAS terminates the PPP sessions, it has to support PPPoE with IPv6. The following devices have to be upgraded to dual stack: Host, Customer Router (if present), BRAS and Edge Router 💖.
7.2.2.2. Addressing 🌸
The BRAS terminates the PPP sessions and provides the subscriber with an IPv6 address from the defined pool for that profile. The subscriber profile for authorization and authentication can be located on the BRAS, or on an AAA server. The Hosts or the Customer Routers have the BRAS as their Layer 3 next hop 🫶.
The PPP session can be initiated by a host or by a Customer Router. In the latter case, once the session is established with the BRAS, DHCP-PD can be used to acquire prefixes for the Customer Router interfaces. The BRAS has to be enabled to support DHCP-PD and to relay the DHCPv6 requests of the hosts on the subscriber sites 🧚.
The BRAS has a /64 prefix configured on the link facing the Edge Router. The Edge Router links are also configured with /64 prefixes to provide connectivity to the rest of the ISP network.
The prefixes used for subscribers and the ones delegated via DHCP-PD should be planned so that maximum summarization happens at the BRAS 🍓.
Other info the host cares about, like DNS, comes through stateful [RFC3315] and stateless [RFC3736] DHCPv6.
7.2.2.3. Routing 🛣️
The CPE devices are configured with a default route that points to the BRAS router. No routing protocols are needed on these devices, which generally have limited resources.
The BRAS runs an IGP to the Edge Router: OSPFv3 or IS-IS. Since the addresses assigned to the PPP sessions are represented as connected host routes, the connected prefixes have to be redistributed. If DHCP-PD is used, the BRAS installs a static route for every delegated prefix, so those static routes must also be redistributed. Prefix summarization should be done at the BRAS 👑.
The Edge Router is running the IGP used in the ISP network: OSPFv3 or IS-IS. A separation between the routing domains of the ISP and the Access Provider is recommended if they are managed independently. Controlled redistribution will be needed between the Access Provider IGP and the ISP IGP 🌸.
7.2.3. L2TPv2 Access Aggregation (LAA) Model 🦋
In the LAA model, the BRAS forwards the CPE initiated session to the ISP over an L2TPv2 tunnel established between the BRAS and the Edge Router. In this case, the ISP itself performs the authentication, authorization, and subscriber configuration 💅.
| Customer Premise | | NAP | | NSP |
+-----------+
| AAA |
+------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +--------+ +----+-----+ +-----------+
|Hosts|-+Router +-+A Switch+-+ Switch +-+ BRAS +-+ Edge | C
+-----+ +-------+ +--------+ +--------+ +----------+ | Router +=>O
| | R
+-----------+ E
|-----------------------------------------------|
PPP
|--------------|
L2TPv2
Figure 7.2.3.17.2.3.1. IPv6 Related Infrastructure Changes ✨
In this scenario, the BRAS is Layer 3 aware and has to be upgraded to support IPv6. The PPP sessions initiated by the subscriber are forwarded over the L2TPv2 tunnel to the aggregation point in the ISP network. The BRAS (LAC) can aggregate IPv6 PPP sessions and tunnel them to the LNS using L2TPv2. The L2TPv2 tunnel between the LAC and LNS could run over IPv6 or IPv4. These capabilities have to be supported on the BRAS. The following devices have to be upgraded to dual stack: Host, Customer Router (if present), BRAS and Edge Router 💖.
7.2.3.2. Addressing 🌸
The Edge Router terminates the PPP sessions and provides the subscriber with an IPv6 address from the defined pool for that profile. The subscriber profile for authorization and authentication can be located on the Edge Router or on an AAA server. The Hosts or the Customer Routers have the Edge Router as their Layer 3 next hop 🫶.
The PPP session can be initiated by a host or by a Customer Router. In the latter case, once the session is established with the Edge Router and an IPv6 address is assigned to the Customer Router by the Edge Router, DHCP-PD can be used to acquire prefixes for the Customer Router other interfaces. The Edge Router has to be enabled to support DHCP-PD and to relay the DHCPv6 requests of the hosts on the subscriber sites. The uplink to the ISP network is configured with a /64 prefix as well 🧚.
The BRAS has a /64 prefix configured on the link to the Edge Router. The Edge Router links are also configured with /64 prefixes to provide connectivity to the rest of the ISP network.
Other info the host cares about, like DNS, comes through stateful [RFC3315] and stateless [RFC3736] DHCPv6 🍓.
The address assignment and prefix summarization issues discussed in Section 6.2.3.2 are relevant in the same way for this media access type as well 🙈.
7.2.3.3. Routing 🛣️
The CPE devices are configured with a default route that points to the Edge Router that terminates the PPP sessions. No routing protocols are needed on these devices, which have limited resources.
The BRAS runs an IPv6 IGP to the Edge Router: OSPFv3 or IS-IS. Different processes should be used if the NAP and the NSP are managed by different organizations. In this case, controlled redistribution should be enabled between the two domains 👑.
The Edge Router is running the IPv6 IGP used in the ISP network: OSPFv3 or IS-IS 💜.
7.2.4. Hybrid Model for IPv4 and IPv6 Service ✨
okay so it was recommended all through this section that the IPv6 service should map the existing IPv4 one 🎀. it keeps manageability simple and means the people running the network don't need a ton of retraining 💅. ngl though, sometimes mapping just isn't feasible. that usually happens when a Service Provider wants to expand its offerings with the new IPv6 infrastructure it deployed 🚀. if the new service isn't well supported in a network design like the one used for IPv4, then a different design might be used for IPv6 🦋.
an example is a provider using an LAA design for its IPv4 services 🌸. in that setup, all the PPP sessions are bundled and tunneled across the entire NAP infrastructure, which is made of multiple BRAS routers, aggregation routers, etc. 🧚 the end point of those tunnels is the ISP Edge Router. now if the SP decides to offer multicast services over a design like this, it's going to run into NAP resources being over-utilized 😭. the multicast traffic can only be replicated at the end of the tunnels by the Edge Router, so the copies for all the subscribers get carried over the entire NAP. not ideal, bestie 💀.
a Modified Point-to-Point (see Section 7.2.4.2) or a PTA model is more suitable for multicast because the packet replication can happen closer to the destination, at the BRAS 💜. that kind of topology saves NAP resources. main character energy 👑.
so yeah, IPv6 deployments can be seen as an opportunity to build an infrastructure that better supports the expansion of services ✨. in this case, an SP using the LAA design for its IPv4 services might choose a modified Point-to-Point or PTA design for IPv6 🫶.
7.2.4.1. IPv4 in LAA Model and IPv6 in PTA Model 🎀
the coexistence of the two PPP-based models, PTA and LAA, is pretty straightforward 🍓. it's a straight overlap of the two deployment models. the PPP sessions are terminated on different network devices for IPv4 and IPv6. the PPP sessions for the existing IPv4 service, deployed in an LAA model, are terminated on the Edge Router. the PPP sessions for the new IPv6 service, deployed in a PTA model, are terminated on the BRAS 🌈.
here's the logical design for IPv6 and IPv4 in this hybrid model, shown in Figure 7.2.4.1 🦋:
IPv6 |--------------------------|
PPP +-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ Switch +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
IPv4 |----------------------------------------|
PPP
|------------|
L2TPv2
Figure 7.2.4.17.2.4.2. IPv4 in LAA Model and IPv6 in Modified Point-to-Point Model 💖
the coexistence of the modified Point-to-Point and LAA models comes with a few specific changes 🧚.
for the IPv4 service in the LAA model, the VLANs are terminated on the BRAS, and the PPP sessions are terminated on the Edge Router (LNS) 🌸. for the IPv6 service in the Point-to-Point model, the VLANs are terminated at the Edge Router, as described in Section 6.2.1. in this hybrid model, the Point-to-Point link could be terminated on the BRAS, which is a NAP-owned device 🏠. the IPv6 traffic is then routed through the NAP network to the NSP. to make this hybrid model happen, the BRAS has to be upgraded to a dual-stack router ⭐. the functionalities of the Edge Router, as described in Section 6.2.1, are now implemented on the BRAS 👑.
here's the logical design for IPv6 and IPv4 in this hybrid model, in Figure 7.2.4.2 🦋:
IPv6 |----------------|
Ethernet
+-----------+
| AAA |
+-------+ Radius |
| | TACACS |
| +-----+-----+
| |
+-----+ +-------+ +--------+ +----+-----+ +-----+-----+
|Hosts|--+Router +------+ Switch +-+ BRAS +-+ Edge |
+-----+ +-------+ +--------+ +----------+ | Router +=>Core
+-----------+
IPv4 |----------------------------------------|
PPP
|------------|
L2TPv2
Figure 7.2.4.27.3. IPv6 Multicast 🎶
the typical multicast services offered to residential and very small business customers are video/audio streaming, where the subscriber joins a multicast group and receives the content 📺. this type of service model is well supported through PIM-SSM, which is very simple and easy to manage 💅. PIM-SSM has to be enabled throughout the ISP 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 🌈.
subscribers might use a set-top box that handles the control piece of the multicast service (it does the group joins and leaves) 📦. the subscriber hosts can also join the multicast groups they want, as long as they're enabled to support MLDv1 or MLDv2 🫶. if a CPR is used, then it has to be enabled to support MLDv1 and MLDv2 so it can process the requests from the hosts. it also has to be enabled to support PIM-SSM so it can send PIM joins and leaves up to its Layer 3 next hop, whether that's the BRAS or the Edge Router 🧚. when enabling this on a CPR, keep its limited resources in mind 🙈. another option is for the CPR to support MLD proxy routing. MLD snooping or similar Layer 2 multicast-related protocols could be enabled on the NAP switches 🌸.
the router that is the Layer 3 next hop for the subscriber (the BRAS in the PTA model, or the Edge Router in the LAA and Point-to-Point models) has to be enabled to support MLDv1 and MLDv2, so it can process requests coming from subscribers without CPRs 💜. it has to be enabled for PIM-SSM so it can receive joins and leaves from customer routers and send joins and leaves to the next hop towards the multicast source (the Edge Router or the NSP core) 🔥.
MLD authentication, authorization, and accounting are usually configured on the edge router so the ISP can control subscriber access to the service and do billing for the content provided 💅. alternative mechanisms that would support these functions should be investigated further 🔍.
please refer to section 6.3 for more IPv6 multicast details 🎀.
7.4. IPv6 QoS 💖
QoS configuration matters a lot on the router that's the Layer 3 next hop for the subscriber (the BRAS in the PTA model, or the Edge Router in the LAA and Point-to-Point models) 👑. that's where you manage resources shared among multiple subscribers, possibly with different service level agreements 🍓.
on the BRAS or the Edge Router, the subscriber-facing interfaces have to be configured to police the inbound customer traffic and shape the outbound traffic to the customer based on the SLAs 🚦. traffic classification and marking should also happen on the router closest to the subscriber at Layer 3, so the various kinds of customer traffic (data, voice, video) get supported and network resources are used well 🎧. this infrastructure is a great chance to use the QoS capabilities of Layer 2 devices 🌈. Diffserv-based QoS used for IPv4 should be expanded to IPv6 ✨.
each provider (NAP, NSP) could implement its own QoS policies and services, so reclassification and marking might be performed at the boundary between the NAP and the NSP, making sure the traffic is handled properly by the ISP 🦋. the same IPv4 QoS concepts and methodologies should be applied to IPv6 as well 💅.
it's important to note that when traffic is encrypted end-to-end, the network devices along the way won't have access to many of the packet fields used for classification 😭. in these cases, routers will most likely place the packets in the default classes. the QoS design should take this scenario into account and mainly try to use IP header fields for classification 🔐.
7.5. IPv6 Security Considerations 🔐
there are limited changes that have to be made for CPEs to enhance security 🛡️. hosts should use the privacy extensions [RFC3041] for auto-configuration, with the same considerations for host traceability discussed in Section 6.5. IPv6 firewall functions should be enabled on the hosts or the Customer Premise Router, if one is present 🧱.
the ISP protects 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 🏰. those services don't apply at the access level of the network discussed here.
if any Layer 2 filters for Ethertypes are in place, the NAP must permit the IPv6 Ethertype (0X86DD). don't forget this one, bestie 🚨
the device that is the Layer 3 next hop for the subscribers (the BRAS or Edge Router) should protect the network and the other subscribers against attacks by one of the provider's 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 BRAS and the Edge Router should protect their processing resources against floods of valid customer control traffic, such as Router and Neighbor Solicitations and MLD Requests 🚨. rate limiting should be implemented on all subscriber-facing interfaces. the emphasis should be on multicast-type traffic, since it's what the IPv6 control plane uses most often 🎯.
all other security features used with the IPv4 service should be applied to IPv6 in a similar way too 💜.
7.6. 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 mean the smallest changes to 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 run 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 IPv6-specific features such as neighbor monitoring 🔭.
in some cases, service providers manage equipment located on customers' LANs 🏡.
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 🌸
okay so WLAN lets subscribers connect to the Internet from all kinds of places, no staying indoors required 🦋 It's standardized as IEEE 802.11a/b/g, and honestly it's the reason we can scroll in the park 🧚
Figure 8.1 is the current WLAN architecture, and it's giving main character energy ✨
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.1So the host needs a wireless Network Interface Card (NIC) to join a WLAN 📱 WLAN is a flat broadcast network and works a lot like Ethernet, lowkey iconic 💜 When a host starts a connection, the AAA server at the SP network authenticates it. All the authentication parameters (username, password, etc.) get forwarded by the Access Point (AP) to the AAA server. The AAA server checks the host, and once it passes, the host can finally send data packets 🎀 The AP sits close to the host and acts as a bridge. It forwards every packet going to and from the host over to the Edge Router. The connection between the AP and Edge Router can be built on any access layer tech, like HFC/Cable, FTTH, xDSL, etc. 🌈
WLANs run inside small zones called WiFi Hot Spots 📶 While users are in range, they can get online as long as they have a wireless NIC and the right settings on their devices (notebook PCs, PDAs, etc.) 💖 Once the user starts the connection, the SP hands out an IP address using DHCPv4. Most of the time the SP only gives its customers a limited number of public IP addresses, so it's a bit of a scarcity moment 🙈 When the user disconnects and moves to a new WiFi hot spot, the whole thing repeats: authentication, address assignment, and then accessing the Internet 🔁
There are also IPv4 deployments where customers use WLAN routers to connect wirelessly to their service provider. These don't really fit the typical Hot Spot idea, because they serve fixed customers instead 🏠 So this section covers the WLAN router options too. In this setup, the ISP gives a public IP address, and the WLAN Router gives private addresses [RFC1918] to all the WLAN users. The WLAN Router handles NAT while the WLAN users are reaching the Internet 🦋
When deploying IPv6 in the WLAN architecture above, there are three possible scenarios, and we'll go through each one 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 sits between the AP and Edge Router, the AP and Layer 2 switch keep working as a bridge. They forward IPv4 and IPv6 packets from the WLAN Host/Router to the Edge Router and back again 🫶
When the connection starts, the WLAN Host gets authenticated by the AAA server at the SP network. All the authentication parameters (username, password, etc.) are forwarded by the AP to the AAA server. The AAA server authenticates the WLAN Host, and once that's done and the host is associated with the WLAN AP, it acquires an IPv6 address ✨ Note that the initiation and authentication process is the same one used in IPv4, so no new drama there 🙌
Figure 8.1.1 shows the WLAN architecture when a Layer 2 Switch sits between the 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.18.1.1.1. IPv6 Related Infrastructure Changes 💜
okay so for this scenario, IPv6 gets deployed by upgrading these devices to dual stack: the WLAN Host, the WLAN Router (if there is one), and the Edge Router 🔥
8.1.1.2. Addressing 🎀
When there's no customer WLAN Router, the WLAN Host has two possible options for getting an IPv6 address from the Edge Router 🦋
- A. The WLAN Host can get its IPv6 address from an Edge Router using stateless auto-configuration [RFC2462]. All hosts on the WLAN belong to the same /64 subnet, which is statically configured on the Edge Router 💖 The IPv6 WLAN Host may use stateless DHCPv6 to get other info of interest, like DNS, etc. 📇
- B. The IPv6 WLAN Host can use DHCPv6 [RFC3315] to get an IPv6 address from a DHCPv6 server. In this case the DHCPv6 server lives in the SP core network, and the Edge Router just acts as a DHCP Relay Agent 🌸 This is similar to what happens today with DHCPv4. It's important to note that host support for stateful auto-configuration is rather limited right now, so keep that in mind if you're picking this option 🙈
When there's a customer WLAN Router, the WLAN Host again has two possible options for acquiring an 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 onto the WLAN Router interfaces that connect the WLAN Hosts on the customer site. The WLAN Hosts connected to those interfaces can configure themselves automatically using stateless auto-configuration ✨
- B. The WLAN Router can use its link-local address to talk to the ER. It can also dynamically acquire, through stateless auto-configuration, the address for the link between itself and the ER 🦋 After that, it sends a request via DHCP-PD for a prefix shorter than /64. That prefix gets split into /64s and assigned to its interfaces that connect the hosts on the customer site 💅
In this option, the WLAN Router acts as a requesting router, and the Edge Router acts as a delegating router 👑 Once the WLAN Router receives the prefix, it assigns /64 prefixes to each of its interfaces that connect the WLAN Hosts on the customer site. The WLAN Hosts on those interfaces can configure themselves automatically using stateless auto-configuration 🫶 The uplink to the ISP network is configured with a /64 prefix as well 🔗
Usually it's easier for SPs to stick with the DHCP-PD and stateless auto-configuration model, and point the clients to a central server for DNS/domain information, proxy configurations, etc. 🧚 With this model the SP can change prefixes on the fly, and the WLAN Router will just pull the newest prefix based on the valid/preferred lifetime. Literally seamless 🌷
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 info of interest to the host, such as DNS, is provided through stateful [RFC3315] and stateless [RFC3736] DHCPv6 📇
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, so no extra work for them 🙌
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 prefix delegation process 🌈
8.1.2. Layer 3 Aware NAP with Layer 3 Termination at Access Router 🦋
When an Access Router sits between the AP and Edge Router, the AP keeps working as a bridge, bridging IPv4 and IPv6 packets from the WLAN Host/Router to the Access Router and back 💅 The Access Router could be part of the SP network, or it could be owned by a separate Access Provider 🏢
When the WLAN Host starts the connection, the AAA authentication and association process with the WLAN AP is similar to what we went over in Section 8.1.1 ✨
Figure 8.1.2 shows the WLAN architecture when the Access Router is 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.28.1.2.1. IPv6 Related Infrastructure Changes 🌸
IPv6 is deployed in this scenario by upgrading these devices to dual stack: the WLAN Host, the WLAN Router (if present), the Access Router, and the Edge Router 🔥💜
8.1.2.2. Addressing 🎀
okay bestie, 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 🌸. main character energy, no cap 👑.
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 🍓.
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.18.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 💅.
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.28.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 ✨.
it is important to note that in 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 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 ✨
Okay so QoS is done outside the WiFi domain right now 💅, but it still matters for the whole deployment, no cap. 🎀
QoS config is especially important on the Edge Router 👑, because that's where you manage shared resources across multiple subscribers, possibly with different service level agreements (SLAs). The WLAN Host/Router and Access Router can be configured for QoS too 🦋. That includes support for the right classification criteria, and those criteria would need to work for both 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 outbound traffic going to the customer, based on the SLA 📊. Traffic classification and marking should also happen on the Edge Router so it can handle the different kinds of customer traffic: data, voice, and video 🎶. The same IPv4 QoS concepts and methodologies SHOULD be applied to IPv6 as well ✨.
It's really important to know that when traffic is encrypted end-to-end 🔒, the network devices along the path won't have access to many of the packet fields used for classification. In these cases, routers will most likely put the packets into the default classes 😭. The QoS design SHOULD take this scenario into consideration and try to use mainly IP header fields for classification 🧚.
8.4. IPv6 Security Considerations 🛡️
There are only limited changes needed on the WLAN Host/Router to boost security 🔐. Hosts SHOULD use the privacy extensions [RFC3041] for auto-configuration, keeping in mind the same host traceability concerns described in Section 6.5 🙈. IPv6 firewall functions SHOULD be enabled on the WLAN Host/Router, if one is present 🔥.
The ISP protects against attacks coming from its own subscribers 👀, and it could also run security services that protect subscribers from attacks launched from outside its network. Those services don't apply at the access level of the network discussed here 🙅♀️.
If host authentication at hotspots is done with a web-based authentication system, the level of security depends on the specific implementation 🤷♀️. User credentials SHOULD never be sent as clear text via HTTP 😱. HTTPS SHOULD be used between the web browser and the authentication server 🔒. The authentication server could use RADIUS and LDAP services on the back end 💻.
Authentication is a huge deal for securing WLAN networks before you implement Layer 3 security policies 🧠. For example, it helps avoid threats to the ND or stateless auto-configuration processes 🚫. 802.1x [IEEE8021X] gives you the means to secure network access 🔑. However, the many types of EAP (PEAP, EAP-TLS, EAP-TTLS, EAP-FAST, and LEAP) and the differing capabilities of hosts to support some of the features might make it hard to build a comprehensive and consistent policy 💀.
The 802.11i [IEEE80211i] amendment has lots of components 📚, and the most obvious ones 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 its own security concerns 🌈. With several data-confidentiality protocols and the key distribution, 802.11i includes a negotiation process for picking the right confidentiality protocol and key system for each traffic type 🤝. It also introduces key caching and pre-authentication 🎀.
The 802.11i amendment is a real step forward in wireless security 👑. It adds stronger encryption, authentication, and key management strategies that could make wireless data and systems way 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 from attacks by one of the provider's 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 subscriber-facing interfaces 🚦. The emphasis SHOULD be placed on multicast-type traffic, since that's what the IPv6 control plane uses most 💜.
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 with SNMP 🖥️. The SNMP transport can run over IPv4 if all managed devices have connectivity over both IPv4 and IPv6 🙌. This would mean 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 exist in the network 🏝️. The management applications MAY be running on hosts that belong to the NSP core network domain 🏢. Network Management Applications SHOULD handle IPv6 in a similar fashion to IPv4 ✨, but 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 IPv6 deployment in Power Line Communications (PLC) Access Networks 🌟. There MAY be other choices, but this looks like the best model to follow 🏆. Lessons learnt from cable, Ethernet, and even WLAN access networks MAY also be applicable 🧠.
Power Line Communications are also often called Broadband Power Line (BPL) and sometimes even Power Line Telecommunications (PLT) 🤓.
PLC/BPL can provide up to 200Mbps (total, upstream+downstream) over the power grid with today's technology 🚀. The coverage is often the last half mile (the typical distance from the medium-to-low voltage transformer to the customer premise meter) and, of course, in-home networks 🏡, which are out of scope for 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 varies depending on factors like distances and even countries, from just 5-6 customers up to 100-150 👯♀️.
PLC/BPL could also be used in the medium voltage network (often configured as Metropolitan Area Networks), but that's out of scope for this document too 🙅♀️, since 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): A router that connects the PLC/BPL access network (the power grid), located at the medium-to-low voltage transformer, to the core network 🔌. To each customer, the HE PLC/BPL interface looks like a single virtual interface, with 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's a lot of peer-to-peer traffic in a building and, due to the master-slave nature of the PLC/BPL technology, a router is needed to improve performance within that segment 🔁. For simplicity within this document, the RPT will always be treated as a transparent Layer 2 bridge, so it MAY or MAY NOT be present from the Layer 3 point of view 🧚.
- Customer Premise Equipment (CPE): A modem (internal to the host), a modem/bridge (BCPE), a router (RCPE), or any combination of those (i.e., modem+bridge/router), located at the customer premise 🏠.
- Edge Router (ER) 👑
Figure 9.1 shows all the network elements mentioned above 🎨.
Customer Premise | Network Access Provider | Network Service Provider
+-----+ +------+ +-----+ +------+ +--------+
|Hosts|--| RCPE |--| RPT |--------+ Head +---+ Edge | ISP
+-----+ +------+ +-----+ | End | | Router +=>Network
+--+---+ +--------+
+-----+ +------+ +-----+ |
|Hosts|--| BCPE |--| RPT |-----------+
+-----+ +------+ +-----+
Figure 9.1The 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 simplest and most efficient model, given the nature of PLC/BPL networks, is to see the network as point-to-point, one link to each customer 💫. Even if several customers share the same physical media, the traffic isn't visible among them, because each one uses different channels, which are also encrypted with 3DES 🔐.
To keep the deployment concepts and business models that already work with revenue-generating IPv4 services, the IPv6 deployment will match the IPv4 one 💅. In 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 the ones already described for the Ethernet case 🙌.
9.2.1. IPv6 Related Infrastructure Changes 🛠️
In this scenario, only the RPT is unaware of Layer 3 😌, but the other devices have to be upgraded to dual-stack: Hosts, RCPE, Head End, and Edge Router 🚀.
9.2.2. Addressing 🏠✨
Okay so the Hosts or the RCPEs have the HE as their Layer 3 next hop 💖
If there is no RCPE, but instead a BCPE, bestie, 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. Lowkey so simple 🫶
If an RCPE is present, here's the tea:
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 🦋 Then it sends a request via DHCP-PD for a prefix shorter than /64 (typically /48 [RFC3177]). That prefix gets divided into /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 🤑 It's giving main character energy ✨
Now the Edge Router needs to have a prefix 👑, because each customer in general will receive a /48 prefix, and each HE will accommodate customers. So 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. That would reduce the network setup, operation, and maintenance cost, which is iconic 🧚
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. Easy peasy 🍓 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, every delegated prefix gets a static route 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 🔥
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's important 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. These aspects 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, so QoS can be provided. These issues are addressed in a recent proposal made to Cable Labs for DOCSIS 3.0 [DOCSIS3.0-Reqs] 💜
B. Section 6 stated that current RBE-based IPv4 deployment might not be the best approach for IPv6. 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 subscribers are expected to keep their assigned prefix, regardless of LNS. A deployment approach was proposed that would maintain the addressing schemes contiguous and offer 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, but 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 as 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 and 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 the prefixes assigned to subscribers relatively easily. 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 🔒
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 or 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 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 than 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] 🔑
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
Okay bestie, these are the references the spec needs you to read 🎀📚
- [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.
- [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.
- [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
These ones are the extra-cozy reading list 🧚💜 They help explain the vibes but aren't strictly required.
- [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.
- [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.
- [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.
Authors' Addresses 👑
Meet the squad who wrote this! 🫶 Here's how to reach each of them:
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
Jordi Palet Martinez
Consulintel
San Jose Artesano, 1
Alcobendas, Madrid E-28108
Spain
Phone: +34 91 151 81 99
EMail: jordi.palet@consulintel.esFull Copyright Statement 💅
Legal time, but make it cute 🌸 Here's the copyright situation:
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 🦋
Who owns what, the IETF edition:
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 🌈
Last but not least, the funding situation ✨
Funding for the RFC Editor function is currently provided by the Internet Society. 🫶💖
📦 where this page comes from
- ietf: rfc4779 2007-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms