This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
APPLICATION NOTE IP version 6 in Technicolor Gateways
DATE: April 2011
VERSION: v4.0
ABSTRACT: This application note provides an overview of IPv6 features and its impact on, and role in Technicolor Gateway offerings.
APPLICABILITY: This application note applies to Technicolor Gateway products that are released with IPv6-enabled platform software.
UPDATES Technicolor continuously develops new solutions, but is also committed to improve its existing products. For more information on Technicolor’s latest technological innovations, documents and software releases, visit us at www.technicolor.com
3 WHAT ABOUT IPV4 AND IPV5? ............................................................................ 8 3.1 Why Introducing IPv6, and is IPv4 Still Needed Then? ......................................... 8 3.2 What happened to IPv5? .............................................................................. 8
4 IPV6 IN A NUTSHELL ......................................................................................... 9
5 WHAT IS NEEDED? .......................................................................................... 10 5.1 Initial goal ................................................................................................ 10 5.2 Hardware / software / other impact? ............................................................... 10
Everyone now seems to agree that IPv6 will play a key role in Internet growth the next coming years.
▪ But does this mean we do not longer need IPv4?
▪ And what happened to IPv5?
Answers to the above questions and a lot more can be found in this document.
Main part of this document however will be about Technicolor Gateway products and IPv6, more exactly: what IPv6 support and implementation is present in the current Technicolor platform software releases and what can be expected in future releases.
This document covers:
General IPv6 information:
▪ "3 What about IPv4 and IPv5?" on page 8
▪ "4 IPv6 in a nutshell" on page 9
▪ "5 What is needed?" on page 10
▪ "6 IPv6 fundamentals" on page 11
IPv6 Technicolor Gateway:
▪ "7 IPv6 Technicolor Gateway: Routed scenarios" on page 14
▪ "9 IPv6 Technicolor Gateway: Surrounding protocols" on page 21
▪ "10 Technicolor Gateway involvement in IPv6 deployment" on page 28
▪ "11 Technicolor Gateway: Coming up next ..." on page 31
In Appendices, Configuration cookbook:
▪ "Appendix A Configuration cookbook: overall info" on page 34
▪ "Appendix B Configuration cookbook: scenarios" on page 37
▪ "Appendix C Remote Management of Technicolor Gateway" on page 46
▪ "Appendix D Configuration cookbook: DNS" on page 47
extraction and communication of its contents, is not permitted without written authorization from Technicolor.
3 What about IPv4 and IPv5?
3.1 Why Introducing IPv6, and is IPv4 Still Needed Then? Will we still need IPv4? The answer is simple: YES!
At the moment of introducing IPv6, there was not yet an issue on public IPv4 address pool-depletion. A long, smooth transition period was targeted for transitioning to IPv6. Today we can state that for many years, nothing really took off for migration to IPv6! Instead, a lot of companies have been postponing their investments and efforts for IPv6 introduction as long as possible.
The result of this is that a large portion of the network and services are still IPv6-unaware, calling for a "dual stack" approach, i.e. introducing devices and services that can "talk" both IPv4 and IPv6.
On top, quite a few transition techniques get/got introduced. These try to overcome both the public IPv4 depletion issue as well as the lack of IPv6 support on some devices/services. For more information on transition techniques, see:
3.2 What happened to IPv5? IPv6 "started" somewhere between 1996 and 1998.
Idea at that moment was to get rid of the limited 32-bit addressing and move to the more powerful 128-bit addresses, as they are known in IPv6.
But why IPv6, and not IPv5? What happened to IPv5?
Version 5 already got "assigned" to the Internet Stream Protocol, aka ST (later also ST-II) late 80s, begin 90s. It was a package of experimenting protocols and, although never deployed commercially, v5 could not be used anymore for the later-to-be-founded IP protocol, so it became IPv6.
Although the lifetime of IPv4 has been extended in various ways, for example applying NA(P)T, CIDR and other techniques, the public IPv4 address space is coming close to depletion. Depending on the used source and geographical area, it is predicted to end somewhere between 2010 and 2012 (today, January-March 2011 seems to be set as the final date for availability now however, this can change day-to-day). At that moment, the local RIRs will still have some public ipv4 addresses left to hand out, but not enough to serve everyone, so it's jeopardising the Internet growth.
IPv6 quadruples (compared to IPv4) the network address bits (from 32 to 128) which provides more than enough globally unique addresses for each IP-device on the planet.
Usage of IPv6 also adds some improvements towards reach ability and end-to-end security/QoS that are crucial for additional applications and services which are driving the demand for extra address space.
Short summary of (some of the) key IPv6 benefits:
▪ Increased address space:
IPv4: 32 bits ~ 232 ~ +/- 4.3 billion addresses.
IPv6: 128 bits ~2128 ~ +/- 3.4×1038 addresses!!!
Currently about 6.8 billion people live on our planet today (see "[4] www.census.gov/ipc/www/popclockworld.html" on page 6")
▪ Address scoping:
Link-local / Unique Local / Unique Global
"Scoped"-Multicast (increased efficiency for multicast)
Anycast
No more broadcast!
▪ StateLess Address Auto-Configuration (SLAAC):
Eases up renumbering
Eases up adding devices to your network (plug-and-play)
No track state per host
▪ Simplified header:
Improves routing efficiency and aggregation as well as performance
▪ Availability (mandatory) of IPSec for ALL IPv6 devices
▪ Mobile IP
▪ Limited need for NA(P)T and Application Layer Gateway
It is unclear whether all of the above statements eventually will proof their benefit and/or will be used in "full force"; however it is clear that lots of people can/will benefit from most of them.
Some of course will also have some drawbacks, for example SLAAC, which makes it a lot more difficult (impossible ??) to track back a device by its IPv6 address, etc.
As a network will consist of a mixture of devices and services, “talking” IPv4 and/or IPv6, some transition scenarios must be put in place. This means that IPv4 won’t be ruled out very soon, so moving to IPv6-only will take many years.
extraction and communication of its contents, is not permitted without written authorization from Technicolor.
5 What is needed?
5.1 Initial goal Although chapter "4 IPv6 in a nutshell" on page 9, shows some clear benefits of using IPv6, it is not that easy / simple to "transition" to IPv6.
Initially, at the time the IPv6 protocol got developed, there was not yet an issue of "public IPv4 pool depletion". In fact, the general idea was to allow enough time for everybody to move gently and gradually to IPv6. However, this did not happen at all, in fact: very little has happened to get IPv6 enabled! The majority of ISPs/Providers did not act at all, probably not fully realizing there could be some v4-shortage in the very near future, ending up in today's situation where the move to IPv6 has become an increasingly important fact for many companies, potentially blocking their growth if not being enabled!
Following this, quite a few "transition techniques" have been put in place. More on transitioning/tunnelling, see sections:
5.2 Hardware / software / other impact? Introducing IPv6 has an impact on both hardware and software. Some of the current used devices are not IPv6-capable at all, or need some firmware upgrade. This means that both hardware and software "updates" will most likely be needed to move to IPv6.
Apart from the hardware/software adjustments in the network, it's also about peoples' knowledge and habits. The move from IPv4 to IPv6 in someone's mind should not be underestimated either.
Double colon can replace (only once in each address!) consecutive zeroes
▪ Prefix Notation:
IPv6 Address / Prefix Length
6.1.2 Some reserved prefixes and special addresses
Address types
Hexadecimal binary (leftmost bits)
Unassigned: ::0/8 00000000
Global Unicast: 2000::/3 00100000
Link-Local Unicast FE80::/10 1111111010000000
Multicast: FF::/8 1111111100000000
Special address
Loopback Address: 0:0:0:0:0:0:0:1/128 or ::1/128
6.2 Stateless Address Auto Configuration SLAAC is a technique for "auto-configuration" of IPv6 hosts. It uses ICMPv6 (router discovery) to get its IPv6 prefix information and appends an interface ID next to it to complete the IPv6 address.
The interface Identification(interface ID) can be composed in different ways. Most commonly it is using the EUI-64 interface ID, based on the device's MAC Address.
Example of EUI-64 interface ID: see "Appendix E EUI-64 Interface ID" on page 50.11.4Appendix E
extraction and communication of its contents, is not permitted without written authorization from Technicolor.
7 IPv6 Technicolor Gateway: Routed scenarios
Different scenarios are possible. This chapter will describe a few typical IPv6 deployment scenario's.
This in fact the simplest and "cleanest" solution to deploy/introduce IPv6. It is using a dual stack CPE with both IPv4 and IPv6 uplink to the WAN, so the CPE device "talks" IPv4 and IPv6 in all directions.
This scenario will use native IP forwarding, i.e. the IPv4 traffic will use the IPv4 link (typically with NA(P)T enabled); the IPv6 traffic will use the IPv6 link. The link as such can be either a single IP interface, supporting both IPv4 and IPv6 or an interface for each IP version separately, or some combination of interfaces supporting IPv4, IPv6, or both.
There can be 3 types of LAN hosts:
▪ IPv4-only hosts
▪ IPv6-only hosts
▪ Hosts supporting both IPv4 and IPv6
Each of these types might require specific configuration for the dual stack CPE.
The Technicolor CPE supports native IP forwarding using Dual Stack IP.
7.1 IPv4-only hosts
Figure 5 IPv4-only hosts on LAN
Configuration
1
▪ Private IPv4 addresses
▪ DHCPv4 client or static configuration
2
▪ Dual IP stack (IPv4/IPv6)
▪ DHCPv4 server towards LAN, handing out private IPv4 addresses to the LAN hosts
▪ IPv4 on WAN-link (IPoE, IPoA, PPPoA or PPPoE)
▪ NA(P)T enabled on WAN interface
As Figure 5 shows: in this situation, the Dual Stack CPE does not require any IPv6-specific configuration. It will operate similar to what's been happening over the past decades with IPv4 on CPEs.
▪ (optional) DHCPv6 client for other configuration retrieval
2
▪ Dual IP stack (IPv4/IPv6)
▪ DHCPv6 client on WAN interface, requesting prefix and other configuration options
▪ Router Advertisement Daemon for IPv6 prefix delegation to LAN
▪ (optional)DHCPv6 stateless server to support DHCPv6 LAN clients (for example DNS)
▪ No NA(P)T enabled on WAN interface as IPv6-only
As Figure 6 shows: in this situation, the Dual Stack CPE does not require any IPv4-specific configuration. In fact, this is not totally correct. Some LAN host Operating systems (for example Microsoft Windows XP) have no DHCPv6 client functionality on board, making it impossible to derive for example DNS info via DHCPv6, so in this case, either an external DHCPv6 client has to be installed (which is very unlikely to happen) or Microsoft makes this functionality available via some patch or service pack. Alternatively, DHCPv4 client functionality can be used for retrieval of DNS information, but in this case it is no longer about IPv6-only hosts.
extraction and communication of its contents, is not permitted without written authorization from Technicolor.
7.3 Mixture of IPv4 / IPv6 hosts
Figure 7 Mixture of IPv4 / IPv6 LAN hosts
Configuration
1
▪ Mixture of IPv4 and IPv6 LAN hosts.
▪ IPv4-specific:
Private IPv4 addresses
DHCPv4 client or static configuration
▪ IPv6-specific:
Link-local IPv6 address
Global Unicast IPv6 Address (GUA)
SLAAC or static configuration
(optional) DHCPv6 client for other configuration retrieval
2
▪ Dual IP stack (IPv4/IPv6)
▪ DHCPv4 server towards LAN, handing out private IPv4 addresses to the LAN hosts
▪ IPv4 on WAN-link (IPoE, IPoA, PPPoA or PPPoE)
▪ NA(P)T enabled on WAN interface
▪ DHCPv6 client on WAN interface, requesting prefix and other configuration options
▪ Router Advertisement Daemon for IPv6 prefix delegation to LAN
▪ (optional)DHCPv6 stateless server to support DHCPv6 LAN clients (for example DNS)
The DNS server on the Technicolor Gateway is a DNS proxy. This means that any type of DNS requests from the LAN, A-records (IPv4 DNS records) or AAAA-records (IPv6 DNS records) shall be forwarded to either the IPv4 DNS server(s) and/or the IPv6 DNS server(s).
More details on the Technicolor DNS implementation and configuration can be found in "9.4 DNSv6 Support" on page 26 and "Appendix D Configuration cookbook: DNS" on page 47.
extraction and communication of its contents, is not permitted without written authorization from Technicolor.
8 Transition / tunneling
Introducing native IPv4/IPv6 forwarding will not be possible for all customers (hardware/software not IPv6-ready, ...). To cope with that, a transition technique (tunnel) can be used.
This chapter describes 3 possible approaches, each of them is tunneling IPv6 traffic in an IPv4 tunnel.
8.1 6to4 There are various techniques available; 6to4 tunnelling is one of them.
The idea behind this is to tunnel IPv6 packets in an IPV4 tunnel. Some extra encapsulation is being added, i.e. the IPv4 traffic will use native IPv4 forwarding, while the IPv6-traffic will be encapsulated into IPv4 and transported over the 6to4 tunnel. By doing this, not all the devices along the path have to support IPv6, hence limited investment will be required.
To enable 6to4, the Technicolor Gateway must support dual stack IP, as it will be handling both IPv4 and IPv6 traffic. Tunnel setup between CPE and remote tunnel end point can be done either manually or automatic.
The Technicolor Gateway supports 6to4 tunnels, both manual and automatically configured.
scenario
Figure 8 6to4 tunnel
Configuration
1
▪ Mixture of IPv4 and IPv6 LAN hosts.
▪ Same configuration as "Figure 7 Mixture of IPv4 / IPv6 LAN hosts" on page 16
2
▪ Dual IP stack (IPv4/IPv6)
▪ DHCPv4 server towards LAN, handing out private IPv4 addresses to the LAN hosts
▪ Router Advertisement Daemon for IPv6 (6to4 specific) prefix delegation to LAN
▪ (optional)DHCPv6 stateless server to support DHCPv6 LAN clients (for example DNS)
Benefits and drawbacks
Benefits:
▪ Limited investment to be done as not all devices along the end-to-end path must become IPv6-capable. As a result of this, it can be deployed in rather short and cost-efficient timeframe.
▪ No service impact as it re-uses the available IPv4 service.
But, as drawbacks:
▪ Extra encapsulation overhead due to tunnelling.
▪ Does not solve the public IPv4 shortage as each device must still get a public IPv4 address.
▪ Devices along the path still don't need to be IPv6-capable; this might lead to them remaining IPv6-unaware, potentially jeopardizing future IPv6 introductions.
▪ Tunnels and multicast are not always very good "friends", so potential multicast issues.
▪ Any form of tunnel introduction will need extra attention towards scalability, performance and security.
▪ Common IPv6 6to4 prefix(2002::/16) must be used. This means that the ISP won't have full control on end-to-end traffic forwarding as he does not know that the traffic actually belongs to his customers, so traffic might traverse competitor's networks and might be dropped.
8.2 6in4 An alternative for 6to4 is 6in4.
6in4 is very closely related to 6to4. Both are:
▪ tunneling IPv6 traffic over an IPv4 tunnel, hence use the same encapsulation.
▪ targeting access to an IPv6 network without the ISP itself offering the IPv6 support.
But, 6to4:
▪ uses the predefined 2002::/16 prefix and incorporates the IPv4 address into the /64 IPv6 prefix for the hosts.
▪ uses an anycast endpoint for the tunnel, i.e. 192.88.99.1 (or some proprietary one).
While 6in4:
▪ uses a prefix outside of the 2002::/16 prefix.
▪ uses a fixed endpoint for the tunnel.
Both approaches have some advantages and benefits, e.g. fixed endpoint looks more reliable than anycast endpoint, but anycast endpoint allows for automatic setup while fixed endpoints need manual intervention.
extraction and communication of its contents, is not permitted without written authorization from Technicolor.
8.3 6RD A 3rd possibility is 6rd. 6rd builts further on 6to4.
It basically builds further on the well-known 6to4 tunnelling; in fact, it could be looked at as an improved version of 6to4 tunnelling. 6to4 can be an alternative, sharing similar benefits and drawbacks.
6RD is being described in RFC5569/5969.
Scenario
Figure 9 6RD network setup
Benefits and drawbacks
Each implementation holds some benefits and drawbacks, 6RD is no difference to that.
Benefits
▪ As not all devices on the end-to-end path must become IPv6-capable, only a limited investment has to be done to enable 6RD
▪ It can be deployed in a rather short timeframe
▪ Typically re-uses the public IPv4 address infrastructure, but deployments with private IPv4 addresses are possible as well.
▪ When using this tunnel in combination with assignments of public IPv4 address to a Technicolor Gateway, it allows for smooth transition at own pace (not needed to migrate all devices at the same time)
▪ When combining with private IPv4 address assignment to CPE, it's tackling the public IPv4 address depletion issue, however, introducing a full new way of working.
▪ Specific 6rd prefix per ISP
But:
▪ Extra encapsulation overhead is being inserted
▪ It does not solve the Public IPv4 address shortage if public IPv4 address assignment to Technicolor Gateway remains as it is
▪ Devices along the path do not need to be IPv6-aware; this might lead them to remain IPv6-unaware, potentially jeopardizing future developments/deployments
▪ A new device type (i.e. a 6RD Border Relay) must be introduced in the ISP network.
9.1 PPPv6 The PPP protocol, currently still the most popular connection model in CPE deployment, has been adapted to support IPv6. A single PPP interface will support both IPv4 and IPv6; both protocols can be separately enabled. This allows to deploy Technicolor IPv6 Gateway products without immediately enabling IPv6 on it. The introduction of IPv6 on these Technicolor Gateway products can be done gradually.
IPv6 over PPP will share a lot with IPv4 over PPP, i.e. LCP will remain unchanged; for NCP: IPCP will be used for IPv4 and IPCPv6 for IPv6, both IPv4 and IPv6 must work independent from each other. IPCPv6 will be added specifically for IPv6. Opposite to IPv4, it will NOT deliver any IPv6-related info (for example IPv4 address for WAN interface, DNS IPv4 addresses, etc). Its only target is to exchange the local/remote ID info, to be able to setup a PPPv6 connection using link-local IPv6 addresses.
Extra IPv6 configuration information (DNSv6 servers, ...) on top of PPP will have to be provided via DHCPv6; static configuration is always an alternative.
Assigning a Global Unicast Address (GUA) is optional. The link-local addressing on PPPv6 is enough. Not providing a GUA means of course that the Technicolor Gateway will not be remotely manageable. This can be solved in different ways, a very common way is to "borrow" a /64 prefix from the delegated prefix and to compose an IPv6 address for it on the loopback interface.
For more information, see:
▪ "9.2.4 DHCPv6 Prefix Delegation" on page 23
▪ "9.3 Router Advertisement Daemon" on page 25
▪ "Appendix C Remote Management of Technicolor Gateway" on page 46
The PPP retry mechanism will be shared for both IPv4 and IPV6, but the IPCP/IPCPv6 part must work independently from each other.
extraction and communication of its contents, is not permitted without written authorization from Technicolor.
Configuration
1
▪ Mixture of IPv4 and IPv6 LAN hosts:
▪ Same configuration as "Figure 7 Mixture of IPv4 / IPv6 LAN hosts" on page 16
2
▪ Dual IP stack (IPv4/IPv6)
▪ DHCPv4 server towards LAN, handing out private IPv4 addresses to the LAN hosts
▪ PPPv4/v6 on WAN interface (PPPoA or PPPoE)
▪ NA(P)T enabled on WAN interface
▪ DHCPv6 client on WAN interface, requesting prefix and other configuration options
▪ Router Advertisement Daemon for IPv6 prefix delegation to LAN
▪ (optional)DHCPv6 stateless server to support DHCPv6 LAN clients (for example DNS)
The Technicolor Gateway supports PPPv4/v6.
Technicolor Gateway configuration examples, see "Appendix B Configuration cookbook: scenarios" on page 37.
9.2 DHCPv6 DHCPv6 is not backwards compatible with DHCPv4; it has been developed specifically and exclusively for IPv6.
9.2.1 Stateless versus stateful In stateless mode, the DHCPv6 server does not need to store any "state" information of the DHCPv6 clients. The client will compose its address via auto-configuration, based on RAs.
A stateless DHCPv6 client will fetch only "other useful configuration" (for example DNS, NTP, etc) info from the DHCPv6 server, not the IP address(es) itself.
For deployment of residential IPv6 networks it is most common to use a stateless configuration. Reason is that it is not needed to keep individual state for each individual LAN host.
9.2.2 DHCPv6 Client A DHCPv6 client can run in 2 "modes":
▪ Stateless
▪ Stateful
In a CPE environment, a DHCPv6 client will be configured on the WAN interface (for both IP(oE) and PPP deployment scenarios) to obtain the "other configuration info". Next to this, it is also very common to request one (or several) IPv6 prefixes for Prefix Delegation.
For more information on Prefix Delegation, see:
▪ "9.2.4 DHCPv6 Prefix Delegation" on page 23
▪ "9.2.5 Typical use case" on page 24
▪ "9.3 Router Advertisement Daemon" on page 25.
Both stateless and stateful client are supported by the Technicolor Gateway.
9.2.3 DHCPv6 Server Similar as the client, a DHCPv6 server can be deployed:
▪ Stateless
▪ Stateful
In a CPE environment, it is not mandatory to configure a DHCPv6 server on the CPE (as opposite to IPv4 where the server part will typically hand out private IPv4 addresses). Optionally, it can be configured in stateless mode to provide the "other configuration info" to the DHCPv6 clients in the network. In some occasions however, the LAN host will (by default) hold NO support for DHCPv6 client (for example when using Microsoft Windows XP on a LAN host), hence the usage of the DHCPv6 server on the CPE will have no effect.
The Technicolor Gateway supports stateless DHCPv6 server.
9.2.4 DHCPv6 Prefix Delegation DHCPv6 Prefix delegation is the most common approach of configuring the Network for IPv6. The DHCPv6 client on the WAN interface will request an IPv6 prefix. The CPE will delegate this prefix towards its LAN interface(s) via RAs. The LAN hosts in their turn will use auto-configuration to configure an IPv6 address, using the received IPv6 prefix.
The Technicolor CPE supports DHCPv6 Prefix Delegation.
9.2.6 Configuration examples Technicolor Gateway configuration examples are available in "Appendix B Configuration cookbook: scenarios" on page 37.
9.3 Router Advertisement Daemon The concept of Prefix Delegation already is explained already in "9.2 DHCPv6" on page 22.
The Technicolor Gateway must include a functionality to delegate its prefixes, via DHCPv6-received or manually configured, to the LAN hosts (to make sure (5) on 9.2.6 is being done). A new function, the Router Advertisement Daemon (RTADVD), will take up this role in the Technicolor CPE.
The received prefix-value will be anything between /48 and /64, where /56 seems to be(come) the industry standard at this moment. The LAN segments however will typically get a /64 prefix. These can be configured via the RTADVD daemon on the Technicolor Gateway. At the same time, some configuration parameters (for example minimum/maximum RA interval) can be configured for better control of RA messaging.
This RTADVD daemon will also allow configuration to "borrow" a prefix from the received delegated prefix and to compose an IPv6 address with it to be placed on any IP interface (typically the loop interface). This will allow to remotely manage the Technicolor Gateway without having to assign a separate IPv6 prefix on its WAN interfaces.
The Technicolor Gateway supports a Router Advertisement Daemon which can delegate prefixes based on DHCP-received prefixes and/or manually configured prefixes. On top, it holds configuration possibilities to use the Route Information Option, both host and router part (RFC4191).
extraction and communication of its contents, is not permitted without written authorization from Technicolor.
An example to make this clear:
Figure 12 RA Daemon
▪ (1): 2001:db8::/56 received via DHCP Prefix Delegation
▪ (2): RA daemon configuration (8 bits left for further subnetting into /64 prefixes):
(2A): 2001:db8::/64 prefix for all LAN hosts
(2B): 2001:db8::1:aaaa:bbbb:cccc:dddd/64 for IPv6 address on loopback interface
Technicolor Gateway configuration examples are available in "Appendix B Configuration cookbook: scenarios" on page 37
9.4 DNSv6 Support The DNS server implementation of the Technicolor Gateway got adapted to include support for DNSv6, i.e. to support AAAA-records (DNSv6 records).
Moreover, the DNS server will now function as a Proxy. When receiving DNS request from its downstream LAN hosts, no matter A- or AAAA-records, it will forward them to the available IPv4 and IPv6 DNS servers.
Extra filtering/configuration have been put in place to provide more control on the forwarding of DNS requests. In this way, filtering/forwarding can be done on for example record-type (A versus AAAA).
Support for Extension Mechanisms for DNS (E-DNS) and DNS over TCP has been added as well.
Technicolor Gateway configuration examples are available in "Appendix D Configuration cookbook: DNS" on page 47
9.5 ICMPv6 ICMPv6 is not just the counterpart for ICMP in IPv4, it's a lot more!
Where ICMP in IPv4 is typically being used to sent some error messages (Packet too big, network unreachable, ...) and to perform diagnostics (ping, traceroute) ICMPv6 will also be used for connectivity (Neighbour solicitation (NS)/Neighbour Discovery (ND), Router Solicitation (RS) /Router Advertisement (RA), Duplicate Address Detection (DAD), Neighbour Unreachability Detection (NUD), ...).
Moreover, broadcast is no longer used in IPv6, in fact has been replaced by multicast (with destination scopes), making ICMPv6 even more important.
MLD is using ICMPv6 as transport protocol as well, so ICMPv6 is a key component in IPv6 development and usage.
The Technicolor Gateway supports ICMPv6.
9.6 Multicast Forwarding Multicast Listener Discovery protocol (MLD) v1/v2 is in fact the counterpart of IGMPv2/v3 from IPv4.
An extract from RFC3810, MLDv2:
The Multicast Listener Discovery Protocol (MLD) is used by IPv6 routers to discover the presence of multicast listeners (i.e., nodes that wish to receive multicast packets) on their directly attached links, and to discover specifically which multicast addresses are of interest to those neighbouring nodes. Note that a multicast router may itself be a listener of one or more multicast addresses; in this case it performs both the "multicast router part" and the "multicast address listener part" of the protocol, to collect the multicast listener information needed by its multicast routing protocol on the one hand, and to inform itself and other neighbouring multicast routers of its listening state on the other hand.
The host part of MLDv1/v2 has been implemented in the Technicolor Gateway.
extraction and communication of its contents, is not permitted without written authorization from Technicolor.
10 Technicolor Gateway involvement in IPv6 deployment
This chapter will describe how a Technicolor Gateway can be used in an IPv6 deployment, i.e. what IPv6-specific capabilities it has in the current firmware. "11 Technicolor Gateway: Coming up next ..." on page 31 will describe what can be expected on IPv6 in Technicolor Gateway products in the near future.
The Technicolor Gateway plays a key role in the Internet, as such it is also key to understand its role in the IPv6 transitioning/IPv4 depletion. Does this mean all Technicolor Gateway products will switch to IPv6 immediately? Of course not, as it is not scalable to do so. It's not only about the IPv6-capabilities of the Technicolor Gateway, but also about the complete network infrastructure, so impact on the full path between end-to-end devices. As the Technicolor Gateway is the main gate to the Internet it plays a vital role in it and will need some flexible positioning to participate in all kind of deployment scenarios.
From a very simple point-of-view, the current deployment looks like:
while it will move to an IPv6 deployment like this:
The link between Technicolor Gateway and WAN can be IPv4-only, IPv6-only or both. Same applies for the link between Technicolor Gateway and end-device(s).
Section "10 Technicolor Gateway involvement in IPv6 deployment" on page 28 describes what IPv6 features are already supported by current IPv6-ready Technicolor Gateway products, however, for some more IPv6 features this is either in development, being discussed and or development ongoing.
This section makes a non-exclusive, nor limiting summary of IPv6 features that are currently under investigation by Technicolor.
Technicolor is not committed to develop the features listed and described in this chapter. They appear in random order with no guarantee if and when they will become available on Technicolor Gateway products.
DualStackLite, i.e. transport IPv4 packets into IPv6. Often another terminology is used: CGNAT, later renamed to LargeScale NAT (LSNAT), as it is moving the NA(P)T part to the network instead of the CPE.
DSLite is not (yet) an IETF standard RFC, although several draft RFCs are in place, describing DSLite and its surrounding components. For more info see www.ietf.org, browse to RFC pages and search on "dslite" keyword.
Figure 14 DSLite network setup
Description
1
▪ LAN hosts
2
▪ DSLite component: Basic Bridging BroadBand element (B4)
3
▪ DSLite component: Address Family Transition Router (AFTR)
extraction and communication of its contents, is not permitted without written authorization from Technicolor.
Benefits and drawbacks
Benefits:
▪ "Solves" the Public IPv4 shortage/depletion, however it's more a work-around
▪ Limited investment to be done as not all devices on the end-to-end path must be IPv6-capable
But, as drawbacks:
▪ Extra encapsulation overhead
▪ Sharing IPv4 addresses might lead to issues and "degraded" services.
▪ NA(P)T moves to Broadband Network Gateway (BNG), (potentially) introducing issues with address translation as well as the use of Application Layer Gateways (ALG)
▪ The devices in the access/aggregation network need to be IPv6 capable as soon as DS-Lite is deployed.
This kind of deployment must be avoided if possible, although this technique might be the only possibility for certain customers (depending on public IPv4 address availability and equipment within the infrastructure).
11.2 IPv6 Router Advertisement Options for DNS Configuration ~ RFC6106
From the start of IPv6 development, everyone seemed to agree upon using RA's for prefix-info, while DHCPv6 client must be used for retrieving other configuration information.
In the mean time however, RFC6106 has been accepted as standards track in the IETF and gets increased attention in BroadBand Forum(BBF). The fact that an end-device no longer would need DHCPv6 client functionality for retrieving its DNS information is the key driver for this.
Currently, the options described in RFC6106 are limited to DNS. However, it has been modelled as such that other protocols can jump onto this track (for example NTP, ...) too.
The benefits are clear:
▪ No need for DHCPv6 client functionality on the LAN hosts
▪ RA already in place, so it just needs to be extended to include support for option sending
▪ The RFC opens the possibility to not limit this for DNS only (for example NTP, ...)
But the drawbacks are clear too:
▪ Increased complexity due to multiple ways of providing this "other configuration information". Intelligence to be put in place to cope with this:
What to do if same option gets provided via both RA and DHCPv6?
What if provided info is has different content ? (for example different DNS servers being provided etc)
11.3 Unique Local Address A unique Local Address (ULA) is an address that has a local scope, i.e. that should not be routed outside the company, or in other words not be used for Internet browsing.
It is the successor of the site local address (that got depreciated some time ago), but with a different address block and that is more clear towards what is allowed with regards to routing.
It should not be used for, for example DNS purposes as it is not guaranteed to be globally unique.
11.4 Other Some other topics to be tackled (in random order):
▪ DHCPv6 relay
The Technicolor Gateway can also be used as relay for DHCPv6, similar to DHCPv4 relay. As a DHCPv6 relay, it relays its DHCPv6 messages to/from a DHCPv6 server.
▪ DHCPv6 stateful server
In stateless DHCPv6 mode, the Technicolor Gateway will only provide other configuration options to the LAN hosts. Stateful server will also be able to hand-out IPv6 addresses, and keep state of what device is using what IPv6 address.
▪ L2TPv2 support
A tunnel can be used as transition technique for introducing IPv6 in a network. 6RD and DSLite are getting the most attention, however, L2TPv2 could also be a candidate, either to extend the PPP tunnel further into the BNG (to bridge devices that do not support IPv6) or to initiate an L2TP tunnel from the Technicolor Gateway.
▪ Device2 data model (WT181) (Remote Management)
BBF is introducing a new data model for remote management, called device2. This is replacing the InternetGatewayDevice(IGD) data model and adds additional modelling for IPv6.
▪ IPv6 on GUI
Extend the Technicolor Gateway GUI for IPv6 support.
▪ MLD Router
As mentioned in "9.6 Multicast Forwarding" on page 27, the Technicolor Gateway currently supports the host part of MLDv1/v2, so the routing part must still be implemented.
▪ Application support (voice, CWMP, ...)
Adapt all applications to support IPv6, some examples are CWMP (TR-069) and voice.
▪ DNSv6: client functionality / local resolving
Currently, a DNS proxy is in place to proxy DNS requests from the LAN. The local resolving part is currently not supported yet.
extraction and communication of its contents, is not permitted without written authorization from Technicolor.
Appendix A Configuration cookbook: overall info
This document highlights all features of the Technicolor Gateway. It shows what it is capable of and in what scenarios it can be used, in its current condition as well as a glimpse into the future.
It is time now to show how all of these scenarios can be configured with a Technicolor Gateway.
Current configuration is CLI-only!
Due to the fact that Technicolor has developed its own IP stack, for both IPv4 and IPv6, lots of flexibility has been built in for configuration purposes.
A.1 Disclaimer This document contains guidelines to configure IPv6 on a Technicolor Gateway via the Command Line Interface CLI. Technicolor has the right to change both content and look and feel of it at any time without written confirmation!
A.2 Executing CLI commands Any CLI command can be executed from the root, by adding its full path with “:” in front, or from within the CLI topic:
For example to add an IP interface, you can execute:
=>ip [ip]=> [ip]=>ifadd XXXXXXXXXXXXXXX
Or simply execute:
=>:ip ifadd XXXXXXXXXXXXXXX
Most of the configuration can be provided from customized factory defaults and/or customization. This will heavily limit the amount of configuration to add. Typically, some username/password (for example for PPP) might have to be provided (although other mechanisms can be in place), nothing more. A unified CLI model has been used, building further on the existing CLI infrastructure as known in the Thomson/Technicolor CPEs for many years.
A.3 Some useful commands and additional info
Save
The saveall command can be executed form all CLI topics
Help
Execute help within a CLI topic will list all commands / groups available in this topic.
Execute help command will give more detailed help info on the specific command.
Lists
Most of the CLI topics will have some list commands available. Use help to find their names.
The (optional) expand=enabled parameter reveals more detailed information. Some other filtering parameters are available in some list commands, for example the proto=XXXX in :ip rtlist command will filter the information for a specific protocol, for example only of the IPv6-info.
A.4 Debug Quite some debug possibilities exist in the Technicolor Gateway CLI. These can typically be enabled per configuration topic; any debug information will be sent to console.
"help" or "?" can be executed within each CLI topic to find the correct syntax, available parameters and some help information on the commands/parameters.
extraction and communication of its contents, is not permitted without written authorization from Technicolor.
A.5 Typical Technicolor Gateway deployment A typical deployment scenario for a dual IPv4/IPv6 stack Gateway is using following components:
▪ A Mixture of IPv4 and IPV6 devices in the LAN.
▪ IPoE and/or PPPoA/PPPoE WAN interface(s).
▪ DHCPv6 client functionality towards WAN, requesting a prefix for PD.
▪ DHCPv6 stateless server functionality towards the LAN.
▪ A Router Advertisement daemon for delegating the received prefix to the LAN segment(s).
▪ SLAAC for LAN hosts to compose IPv6 address(es).
▪ Optionally, the Router Advertisement daemon can also be used for delegating an IPv6 address to the loopback interface. This IPv6 address can be used for remote management purposes. (see RA* in "Figure 12 RA Daemon" on page 26).
For IPv4 hosts, nothing will change in this scenario. They will typically receive private IPv4 addresses handed out via de Technicolor Gateway DHCPv4 server, while NAT will be enabled on the Gateway to translate the private IPv4 addresses towards the WAN.
For IPv6 hosts (the IPv6-part of a dual stack host), it typically will look as shown in Figure 15:
Figure 15 Dual stack Gateway with DHCPv6 Prefix delegation
Figure 15 is of course just showing some example. Each customer can add/remove some components from/to it.
B.1 IPoE In this scenario, eth_ge (5th eth port on TG789vn) is being used as WAN interface.
An alternative could be to separate a port from the Technicolor Gateway Ethernet switch to be used as “wan-port”, but that specific configuration is not covered by this appendix. In fact, this is just re-using functionality already present for many years in Technicolor Gateways.
DHCPv6 server on Technicolor Gateway:
▪ No DHCPv6 server, only DHCPv6 client with PD. DNS info being provided to LAN hosts via DHCPv4.
Ethernet configuration:
▪ No extra Ethernet configuration changes are needed in this scenario. Everything already provided/configured by default.
Due to internal architecture, it is recommended to enable VLAN on the bridge. This is applicable on platforms having all internal ports on the switch. It is not mandatory (depends on use case), but if use case requires this, the following configuration MUST be added:
:eth bridge config vlan=enabled
When using VLANs, the following configuration must be added (for example vlan=2). Please note that to use VLAN on a certain eth interface, an additional logical eth interface on top of the existing one must be added, defining the VLAN in this new logical interface (this functionality is present in Technicolor CPEs already for many years).
extraction and communication of its contents, is not permitted without written authorization from Technicolor.
The "listenra=enabled" parameter enables the auto-detect of stateless / stateful, based upon received RAs (in this case, the stateless parameter will be ignored). If however, if the RAs are being sent with both Managed(M)- and Other(O)-bit to 0, the DHCPv6 client will not be able to get to BOUND state. In this case, the server-side configuration is inline with the DHCPv6 RFCs, but can be overruled by disabling the listenra and using the stateless=enabled/disabled parameter.
4 To enable DHCP Client v4 configuration (similar as in previous releases), execute:
The number of bits for subnet-id of a Global Unique Address is being calculated from the received prefix size, i.e. subnet-id=64 bits minus the number of bits of the received prefix (see "6 IPv6 fundamentals" on page 11).
For example: if a /56 prefix is being delegated to the CPE, the subnet-id=64-56=8. This means 8 bits can be used for the subnet-id. Example from CLI:
Syntax of subnet-id=XXXX:XXXX:XXXX:XXXX::/64. This is just the hexadecimal presentation for IPv6 addresses. If you have 8 bits for configuration, this means the last 8 bits can be used for creating prefixes for the LAN segment(s).
extraction and communication of its contents, is not permitted without written authorization from Technicolor.
B.2 IPoE (including stateless DHCPv6 server) A similar scenario as "B.1 IPoE" on page 37, but now adding Stateless DHCPv6 server on Technicolor Gateway on top (i.e. the DHCPv6 stateless server is enabled to pass the Gateway IPv6 address via the domain name server's option towards the DHCPv6 clients in the LAN.).
LAN hosts must have DHCPv6 client functionality to be able to use this (for example NO DHCPv6 client functionality on Microsoft Windows XP (an external client can be used but this is not really a straightforward approach)).
Proceed as follows:
1 Apply the configuration as described in "B.1 IPoE" on page 37.
2 To enable stateless DHCPv6 server on the Technicolor Gateway, execute:
:dhcp serverv6 config state enabled :dhcp serverv6 pool add name=lan6_pool :dhcp serverv6 pool config name=lan6_pool state=enabled intf=LocalNetwork localdns=enabled
3 To enable the O-flag (other configuration) in RA-messages, execute:
B.3 PPPoE In this scenario, PPPoE (PPPoA is being supported as well) is being configured over eth_ge (5th Ethernet port on the Technicolor Gateway) as WAN protocol (DSL can be used instead). No stateless DHCP server is being configured on the Technicolor Gateway, only DHCPv6 with PD.
extraction and communication of its contents, is not permitted without written authorization from Technicolor.
B.4 PPPoE (including stateless DHCPv6 server) Similar scenario as described in "B.3 PPPoE" on page 41, but now adding a stateless DHCPv6 server on the Technicolor Gateway (i.e. the DHCPv6 stateless server is enabled to pass the Gateway IPv6 address via the domain name server's option towards the DHCPv6 clients in the LAN).
Proceed as follows:
1 Apply the configuration as described in "B.3 PPPoE" on page 41.
2 To enable DHCPv6 stateless server configuration, execute:
:dhcp serverv6 config state enabled :dhcp serverv6 pool add name=lan6_pool :dhcp serverv6 pool config name=lan6_pool state=enabled intf= LocalNetwork localdns=enabled
3 To enable the O-flag (other configuration) in RA-messages, execute:
1 To show all PPP interface-related information, the following command can be executed:
=>:ppp iflist Internet: dest RELAY [00:00:05] retry : 10 admin state = up oper state = up link state = connected flags = echo magic accomp restart trace mru addr route savepwd ipv4 ipv6 pap class = 12 echointerval = 10 echofail = 5 echototaltolerance = 50 administrative mru = 1500 negotiation mru = 1492 auth type = auto [user name = XXX@YYY] [password = ********] mode = numbered dns metric = 10 route : dst=0.0.0.0/0 - src=0.0.0.0/0 (metric 10) LCP : state = opened restartintv = 0 retransm = 0 term. reason = IPCP : state = opened restartintv = 0 retransm = 0 term. reason = IPV6CP : state = opened restartintv = 0 retransm = 0 term. reason = negotiated local interface id = ::21f:9fff:fef1:59f4 negotiated remote interface id = ::90:1a00:43a3:44e4 PPPoE Client info [configured backoffscale = 1] [configured backofflimit = 8] [configured service = None] [ac service = None] [ac name = E120] [ac mac address = 00:1f:9f:f1:59:f4] [session id = 1] =>
By executing a single CLI command, all PPP interface related configuration is shown.
2 To show the DHCPv6 client configuration, execute:
=>:dhcp clientv6 iflist intf Internet expand enabled DHCPv6 Client Info : Interface : Internet Mode : stateful DHCPv6 Client State : [BOUND] Client DUID : 00:01:00:14:00:00:b7:75:00:1f:9f:f1:59:f4 Non Temporary Adress list : Prefix list : IA ID : 00:1f:9f:f1 Renew value : 0 days, 12:00:00 Rebind value : 0 days, 19:12:00 Prefix : 2001:db8:9388:1000::/56 [active] Preferred lifetime : 1 day, 0:00:00 Valid lifetime : 1 day, 0:00:00 Timeout till depreferred : 0 days, 23:58:07 Listen to RA messages : enabled RA Managed flag : enabled RA Other Config flag : enabled RA flags lifetime : 0 days, 0:30:00 Rapid commit : disabled Proposed leasetime : 0 days, 2:00:00 Number of IA NA options proposed : 0 Number of IA PD options proposed : 1 Lease history : enabled DNS metric : 10 Link state : up DHCPv6 Options : Transmitted : 1 (client-identifier) Requested : 23 (domain-name-servers) 25 (ia-prefix-delegation) Stateful lease will be renewed within : 0 days, 11:58:07 =>
This command shows DHCPv6 client information only. DHCPv6 client functionality has been configured on the WAN interface. It is requesting prefix information and some DHCP options.
extraction and communication of its contents, is not permitted without written authorization from Technicolor.
3 To show the DHCPv6 server configuration, execute:
=>:dhcp serverv6 config State: enabled =>:dhcp serverv6 pool list name LAN6_pool expand enabled Idx Pool Intf Admin State 0 LAN6_pool LocalNetwork up up Local DNS : enabled (fe80::21f:9fff:fef1:59f4) =>
4 To retrieve the route list for IPv6, execute:
=>:ip rtlist proto=ipv6 expand enabled Flags legend: [D]ynamic, [A]uto, [M]odified, [R]eject, [B]lackhole, [G]ateway, [H]ost, [I]nterface Destination Label Interface Admin Oper Mtr Gateway ----------- ----- --------- ----- ---- --- ------- 2001:db8:9388:1002::a:bebe/128 loop UP [UP] 0 Flags : DA....HI Origin : kernel Use Count : 0 fe80::21f:9fff:fef1:59f4/128 loop UP [UP] 0 Flags : DA....HI Origin : kernel Use Count : 5 fe80::1/128 loop UP [UP] 0 Flags : DA....HI Origin : kernel Use Count : 0 ::1/128 loop UP [UP] 0 Flags : DA....HI Origin : kernel Use Count : 0 2001:db8:9388:1002::/64 loop UP [UP] 0 Flags : DA.....I Origin : kernel Use Count : 0 fe80::/64 loop UP [UP] 0 Flags : DA.....I Origin : kernel Use Count : 0 2001:db8:20::2/128 Internet UP UP 10 Flags : D.....HI Origin : dns Use Count : 0 2001:db8:9388:1001::/64 LocalNetwork UP [UP] 0 Flags : D......I Origin : rtadvd Use Count : 0 fe80::/64 Internet UP UP 0 Flags : DA.....I Origin : kernel Use Count : 0 fe80::/64 LocalNetwork UP [UP] 0 Flags : DA.....I Origin : kernel Use Count : 0 2001:db8:9388:1000::/56 <none> UP [UP] 0 Flags : D...B... Origin : rtadvd Use Count : 0 ::/0 Internet UP UP 0 fe80::90:1a00:43a3:44e4 Flags : DA...G.I Origin : neighdisc Use Count : 1 Expire : 1667 =>
This shows the IPv6 route list.
An IPv6 address has been borrowed from the delegated prefix, and assigned to the loopback interface.
An IPv6 prefix is being assigned to the Local Network Interface.
A blackhole route has been installed in the routing list to prevent routing loops. This route entry holds a "B" as flag to indicate it as a black hole route.
5 To show the prefix delegation configuration (to LocalNetwork and Loopback Interfaces), execute:
extraction and communication of its contents, is not permitted without written authorization from Technicolor.
Appendix C Remote Management of Technicolor Gateway
Non /64 prefix delegation
IPCPv6 does not support the exchange of public IP prefix information, only link-local prefix is being used. In order to make the Technicolor Gateway remotely manageable over IPv6, it needs a global IPv6 address.
This can be approached in different ways. DHCPv6 client can be used to get a global IPv6 address assigned on the WAN interface. This however means a separate prefix must be used; this will cause some administrative overhead, i.e. keeping track of the assigned GUA address for all the gateways (on top of the delegated prefix), as well as extra cost.
Instead, to avoid administrative overhead and separate prefixes, a prefix can be borrowed from the Delegated prefix (in case Delegated prefix is not equal to 64) and be assigned to another IP interface. Typically, the loopback interface will be used; however, any IP interface is a valid candidate.
This can be used in all scenarios with IPv6 support, IPoE, PPPoE/PPPoA, with or without stateless DHCPv6 server enabled.
To configure this on as Technicolor Gateway, execute:
Assigning an IPv6 address to the loopback interface is NOT possible if the delegated prefix is of size /64. This does not mean that these devices cannot be managed remotely, but only that no additional prefix is available to use for delegating an IPv6 address onto the loopback interface.
/64 prefix delegation
In case of a /64 prefix delegation, the /64 prefix is being delegated to the LocalNetwork (in stead of the loopback interface). This is being done in a similar way as for a non-/64 delegated prefix. However, from this same prefix, 1 address will be taken and configured on the LocalNetwork Interface itself (so not on the loopback interface). Doing this, the device can be managed remotely. On top, it will make sure the DNS proxy will work properly. For DNs, please see "Appendix D Configuration cookbook: DNS" on page 47.
The Technicolor Gateway DNS implementation features extended configuration functionality.
Some key functionality:
▪ Conditional DNS
▪ DNS Proxy
▪ Forwarding based on
source IPv4/IPv6
source Interface
Qtype (A versus AAAA-records)
▪ Support for E-DNS.
▪ Support for DNS over TCP
To accommodate this, the Technicolor Gateway Command Line Interface configuration has been extended with some extra topics and parameters. The remaining of this appendix covers the Technicolor Gateway DNS configuration in more detail.
D.1 Using PPPv4/v6 PPPv4 (IPCP) will make sure some (ipv4) DNS servers are being provided to the Technicolor Gateway, while DHCPv6 will do a similar thing for IPv6.
To add a DNS metric for DNS servers received via PPP, execute:
:ppp ifconfig intf=Internet dnsmetric=10
To add a DNS metric for DNS servers received via DHCPv6, execute:
This is the default configuration, it makes sure that DNSv4 servers, derived via PPP IPCP will get metric=10 assigned. Same will apply for DNSv6 servers derived via DHCPv6.
To list DNS server configuration, execute:
:dns server forward list Forwarding Rules ================ Idx Set Source addr / prefix Source Interface Qtyp Domain --- --- ------------------------------------------- ------------------------------- ----------------------------------------- 999 0 Forwarding Servers (flags: [*]Dynamic [D]HCP [P]PP [I]PSEC [T]rigger) ================== Set Metric Flg DNS-Server EDNS Label Intf State --- ------ --- --------------------------------------- ---- --------------- ------------------------------- ----- 0 10 P* 10.A.B.C Internet UP 0 10 P* 10.A.B.D Internet UP 0 10 D* 2001:db8::1 Internet UP
extraction and communication of its contents, is not permitted without written authorization from Technicolor.
D.2 Using IPoE In case IPoE is being used, the DNSv4 servers will no longer be provided via PPP IPCP, so DHCP v4/v6 must be used for both DNS v4/v6 server retrieval.
This is the default configuration, it makes sure that DNSv4 servers, derived via PPP IPCP will get metric=10 assigned. Same will apply for DNSv6 servers derived via DHCPv6.
To list DNS server configuration, execute:
:dns server forward list Forwarding Rules ================ Idx Set Source addr / prefix Source Interface Qtyp Domain --- --- ------------------------------------------- -------------------------- ---- ----------------------------------------- 999 0 Forwarding Servers (flags: [*]Dynamic [D]HCP [P]PP [I]PSEC [T]rigger) ================== Set Metric Flg DNS-Server EDNS Label Intf State --- ------ --- --------------------------------------- ---- --------------- ------------------------------- ----- 0 10 D* 10.A.B.C Internet UP 0 10 D* 10.A.B.D Internet UP 0 10 D* 2001:db8::1 Internet UP
D.3 Static DNS To statically add DNS servers, execute:
:dns server forward dnsset add set 50 dns 2001:db8::1 metric 20
To list DNS server configuration, execute:
:dns server forward list Forwarding Servers (flags: [*]Dynamic [D]HCP [P]PP [I]PSEC [T]rigger) ================== Set Metric Flg DNS-Server EDNS Label Intf State --- ------ --- --------------------------------------- ---- --------------- ------------------------------- ----- 0 10 D* 10.A.B.C Internet UP 0 10 D* 10.A.B.D Internet UP 0 10 D* 2001:db8::1 Internet UP 50 20 2001:db8:db8::1 * UP
D.4 Templates Static configuration injects some forwarding servers into the CPE. As an alternative (or combined), a template can be used, matching some criteria.
To configure a DNS template for IPv6, execute:
:dns server forward dnsset add set=60 dns=:: intf=Internet
To configure a DNS template for IPv4, execute:
:dns server forward dnsset add set=70 dns=0.0.0.0 intf=Internet
To list DNS server configuration, execute:
:dns server forward list Forwarding Templates ==================== Set Metric Owner DNS-Server EDNS Label Interface --- ------ ----- --------------------------------------- ---- --------------- ------------------------------- 60 0 <learned IPv6 server> Internet 70 0 <learned IPv4 server> Internet Forwarding Servers (flags: [*]Dynamic [D]HCP [P]PP [I]PSEC [T]rigger) ================== Set Metric Flg DNS-Server EDNS Label Intf State --- ------ --- --------------------------------------- ---- --------------- ------------------------------- ----- 0 10 D* 10.A.B.C Internet UP 0 10 D* 10.A.B.D Internet UP 0 10 D* 2001:db8::1 Internet UP 50 20 2001:db8:db8::1 * UP
D.5 Rules Besides configuring DNS servers, either statically of dynamically, some rules can be applied for better guidance of DNS traffic.
To add a DNS rule for matching a DNS record type, execute:
:dns server forward rule add idx=50 set=60 qtype=AAAA
To add a DNS rule for matching a Domain, execute:
:dns server forward rule add idx=60 set=60 domain=mydomain.com
To list DNS server configuration, execute:
:dns server forward list Forwarding Rules ================ Idx Set Source addr / prefix Source Interface Qtyp Domain --- --- ------------------------------------------- ------------------------------- ---- ----------------------------------------- 50 60 AAAA 60 60 ANY mydomain.com 999 0 Forwarding Templates ==================== Set Metric Owner DNS-Server EDNS Label Interface --- ------ ----- --------------------------------------- ---- --------------- ------------------------------- 60 0 <learned IPv6 server> Internet 70 0 <learned IPv4 server> Internet Forwarding Servers (flags: [*]Dynamic [D]HCP [P]PP [I]PSEC [T]rigger) ================== Set Metric Flg DNS-Server EDNS Label Intf State --- ------ --- --------------------------------------- ---- --------------- ------------------------------- ----- 0 10 D* 10.A.B.C Internet UP 0 10 D* 10.A.B.D Internet UP 0 10 D* 2001:db8::1 Internet UP 50 20 2001:db8:db8::1 *
extraction and communication of its contents, is not permitted without written authorization from Technicolor.
Appendix E EUI-64 Interface ID
Appendix A of RFC4291 explains how to create EUI-64 identifiers.
Addresses in the 001 to 111 prefix range should use a 64-bit identifier, which follows the IEEE EUI-64 format, except for multicast addresses.
A host uses an identifier following EUI-64 format during auto-configuration.
For example on an Ethernet interface, the 48-bit MAC address is used to create the EUI-64 bit interface ID. 0xFF-FE is being inserted between third and fourth byte of the MAC address. Applying this, MAC address 01-02-03-04-05-06 becomes 01-02-03-FF-FE-04-05-06 as EUI-64 interface ID.
The local bit (bit 7) will be inverted, it becomes: 03-02-03-FF-FE-04-05-06
The link-local address of a node combines prefix fe80::/64 and EUI-64 bit interface ID, so from above example, the node IPv6 Link-local address would become fe80::302:03FF:FE04:506
The configurations in this chapter are using a PPP interface as tunnel source interface. The TG also offers the ability to use an IPoE interface as source interface for the tunnel.
F.1 6to4 In this scenario, a 6to4 tunnel will be configured over an IPv4-only PPP interface. Enabling IPv6 on this PPP interface makes no sense, as the WAN-link in this scenario is IPv4-only anyway.
Depending on the configuration on the BNG side, enabling op IPv6 on this interface can interfere, as default route might be injected and so on.
Where sourceintf is the interface on top of which the 6to4 will be applied and rrs is the 6to4 relay routers list.
4 To add a default route for IPv6 to the 6to4tunnel, execute:
:ip rtadd dst=::/0 intf=6to4tunnel
5 To advertise the 6to4prefix towards the LAN, the Router Advertisement Daemon will be used (similar as in a DHCPv6 PD configuration), so no changes are needed from default configuration (although it can be tweaked a little to 6to4-only, but not mandatory).
However, it is recommended to enable zerotime, as the public IPv4 address, used for the 6to4 prefix, is a dynamic one, and as such can change over time. In this case, the "old" 6to4" prefix must be invalidated with lifetime=0. To do this, execute:
:ip rt6advd config zerotime enabled
Please note that this zerotime enabling will inform the host properly that a certain 6to4 prefix should no longer be used. However, the Operating Systems of the LAN hosts can be different and as such might react differently to this change; it can hence not be 100% guaranteed that a proper switch-over to the new prefix is done.
F.2 6in4 In this scenario, a 6in4 tunnel will be configured over an IPv4-only PPP interface. Enabling IPv6 on this PPP interface makes no sense, as the WAN-link in this scenario is IPv4-only anyway.
Depending on the configuration on the BNG side, enabling op IPv6 on this interface can interfere, as default route might be injected and so on.
1 To disable ipv6 on a PPP interface, execute:
:ppp ifconfig intf=Internet ipv6=disabled
As specified in "8.2 6in4" on page 19, the configuration for 6in4 will look very similar as the one for 6to4. The big difference is that 6in4 is point-to-point and that it needs a lot of manual configuration.
6 To add a blackhole or reject route for the aggregated prefix, execute:
:ip rtadd dst=2001:db8:9583::/48 type=reject
You can choose to insert a reject or blackhole route. In this example, the tunnel broker has offered a /48 prefix over the 6in4 tunnel, hence a blackhole/reject route of size /48 must be injected to prevent loops.
7 To make sure the a GUA is available for source IPv6 (for packets from the Technicolor Gateway), execute:
Alternative configurations are possible. For example, an IPv6 GUA can also be configured on the loop or other IP interface.
To list some 6in4 info, execute:
{Administrator}=>:tunnel 6in4 list flags: [D]ynamic copy [T]OS dynamic [M]TU # ifname encap mtu sourceintf source destination flags 5 6in4tunnel 6in4 1280 Internet source_ip_addr dest_ip_addr ...
The source_ip_addr was not configured when defining the tunnel, it was derived from settings the source interface. The dest_ip_addr will be provided by e.g. the tunnel broker.
F.3 6rd In this scenario, a 6rd tunnel will be configured over an IPv4-only PPP interface. Enabling IPv6 on this PPP interface makes no sense, as the WAN-link in this scenario is IPv4-only anyway.
Depending on the configuration on the BNG side, enabling IPv6 on this interface can interfere, as default route might be injected and so on.
1 To disable IPv6 on a PPP interface, execute:
:ppp ifconfig intf=Internet ipv6=disabled
The Technicolor Gateway 6rd implementation offers the possibility to configure a 6rd tunnel interface in 2 ways: static, or dynamic. Static configuration of 6rd will not be scalable for most use cases, so this chapter will only cover the dynamic example. Static configuration might be useful however for some test setup.
2 In order to use 6rd in dynamic mode, DHCPv4 client functionality must be enabled on the WAN interface. 6rd will only require to add the 6rd option (option 212) into the list of rqoptions of the DHCPv4 client. To add DHCPv4 client + 6rd option, execute:
3 Similar to 6to4, the public IPv4 address where tunnel is based upon is a dynamic one, hence can change over time. In order to invalidate the "old" 6rd prefix, execute:
:ip rt6advd config zerotime enabled
Please note that this zerotime enabling will inform the host properly that a certain 6rd prefix should no longer be used. However, The OSs of the LAN hosts can be different and as such might react different to this change, hence no 100% guarantee for proper switch-over to new prefix.
No other configuration is needed as it will use the info from the 6rd option to configure the tunnel and inject the 6rd prefix delegation for the LAN hosts.
To see the results of the prefix delegation, execute:
extraction and communication of its contents, is not permitted without written authorization from Technicolor.
END OF DOCUMENT
Acknowledgements
Special thanks to all colleagues who contributed directly or indirectly to this document.
Author
This paper was written by Carl Wuyts.
Carl Wuyts is an external consultant supporting the Networking team of Technicolor's Digital Home Business Division as a system architect. As IP expert he assists in the introduction of IPv6 in Technicolor Gateways.
Comments
Your comments are important to us! If have comments on, or suggestions for this document, feel free to post them to:
Carl Wuyts Prins Boudewijnlaan 47 2650 Edegem (Belgium) [email protected]