ip version 6 in technicolor gateways

E-DOC-CTC-20091204-0001 v4.0. Copyright © 2011 Technicolor. All rights reserved. This document contains Technicolor proprietary and confidential information. Passing on and copying of this document, use, extraction and communication of its contents, is not permitted without written authorization from Technicolor.

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

http://www.technicolor.com/

2

IP VERSION 6 IN TECHNICOLOR GATEWAYS

E-DOC-CTC-20091204-0001 v4.0. Copyright © 2011 Technicolor. All rights reserved. This document contains Technicolor proprietary and confidential information. Passing on and copying of this document, use,

extraction and communication of its contents, is not permitted without written authorization from Technicolor.

Table of Contents 1 ABBREVIATIONS AND REFERENCES .................................................................... 4

1.1 Abbreviations ............................................................................................ 4 1.2 References ............................................................................................... 6

2 INTRODUCTION ............................................................................................... 7

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

6 IPV6 FUNDAMENTALS ...................................................................................... 11 6.1 Addressing structure ................................................................................. 11

6.1.1 Basics ................................................................................................ 11

6.1.2 Some reserved prefixes and special addresses ................................................ 11

6.2 Stateless Address Auto Configuration ............................................................ 11 6.3 IPv6 Address Format .................................................................................. 12

6.3.1 Link-local address .................................................................................. 12

6.3.2 Global Unicast Address ............................................................................ 12

6.3.3 Multicast Address ................................................................................... 13

6.3.4 6to4 Address ........................................................................................ 13

7 IPV6 TECHNICOLOR GATEWAY: ROUTED SCENARIOS ............................................ 14 7.1 IPv4-only hosts ......................................................................................... 14 7.2 IPv6-only hosts ......................................................................................... 15 7.3 Mixture of IPv4 / IPv6 hosts .......................................................................... 16 7.4 Benefits and drawbacks .............................................................................. 17 7.5 Configuration ........................................................................................... 17

8 TRANSITION / TUNNELING ................................................................................ 18 8.1 6to4 ....................................................................................................... 18 8.2 6in4 ........................................................................................................ 19 8.3 6RD ........................................................................................................ 20

9 IPV6 TECHNICOLOR GATEWAY: SURROUNDING PROTOCOLS ................................. 21 9.1 PPPv6 ..................................................................................................... 21 9.2 DHCPv6 .................................................................................................. 22

9.2.1 Stateless versus stateful ........................................................................... 22

9.2.2 DHCPv6 Client ...................................................................................... 22

3



9.2.3 DHCPv6 Server ..................................................................................... 23

9.2.4 DHCPv6 Prefix Delegation ........................................................................ 23

9.2.5 Typical use case .................................................................................... 24

9.2.6 Configuration examples ............................................................................ 25

9.3 Router Advertisement Daemon ..................................................................... 25 9.4 DNSv6 Support ......................................................................................... 26 9.5 ICMPv6 ................................................................................................... 27 9.6 Multicast Forwarding .................................................................................. 27

10 TECHNICOLOR GATEWAY INVOLVEMENT IN IPV6 DEPLOYMENT .............................. 28 10.1 Technicolor Gateway: Feature Summary ......................................................... 29 10.2 Technicolor Gateway: Supported RFCs .......................................................... 30

11 TECHNICOLOR GATEWAY: COMING UP NEXT ... .................................................... 31 11.1 Additional Transition / tunnelling techniques: DS-Lite ........................................ 31 11.2 IPv6 Router Advertisement Options for DNS Configuration ~ RFC6106 ................... 32 11.3 Unique Local Address ................................................................................ 32 11.4 Other ...................................................................................................... 33

APPENDIX A CONFIGURATION COOKBOOK: OVERALL INFO ....................................... 34 A.1 Disclaimer ............................................................................................... 34 A.2 Executing CLI commands ............................................................................ 34 A.3 Some useful commands and additional info ..................................................... 34 A.4 Debug ..................................................................................................... 35 A.5 Typical Technicolor Gateway deployment ....................................................... 36

APPENDIX B CONFIGURATION COOKBOOK: SCENARIOS ........................................... 37 B.1 IPoE ....................................................................................................... 37 B.2 IPoE (including stateless DHCPv6 server) ....................................................... 40 B.3 PPPoE .................................................................................................... 41 B.4 PPPoE (including stateless DHCPv6 server) .................................................... 42 B.5 Verification commands ............................................................................... 43

APPENDIX C REMOTE MANAGEMENT OF TECHNICOLOR GATEWAY ............................. 46

APPENDIX D CONFIGURATION COOKBOOK: DNS ...................................................... 47 D.1 Using PPPv4/v6 ........................................................................................ 47 D.2 Using IPoE ............................................................................................... 48 D.3 Static DNS ............................................................................................... 48 D.4 Templates ................................................................................................ 49 D.5 Rules ...................................................................................................... 49

APPENDIX E EUI-64 INTERFACE ID ......................................................................... 50

APPENDIX F TUNNELS ........................................................................................ 51 F.1 6to4 ....................................................................................................... 51 F.2 6in4 ........................................................................................................ 53 F.3 6rd ......................................................................................................... 54

4




1 Abbreviations and references

1.1 Abbreviations

6rd 6 Rapid Deployment

AFTR Address Family Transition Router

ALG Application Layer Gateway

B4 Basic Bridging BroadBand element

BBF BroadBand Forum

BNG Broadband Network Gateway

CGNAT Carrier Grade NAT

CIDR Classless Inter-Domain Routing

CPE Customer Premises Equipment

CWMP CPE WAN Management Protocol

DAD Duplicate Address Detection

DHCP Dynamic Host Configuration Protocol

(E-)DNS (Extension mechanisms for)Domain Name Service/System

DS Lite Dual Stack Lite

EUI-64 Extended Unique Identifier - 64 bits

FTP File Transfer Protocol

GUA Global Unicast Address

ICMP(v6) Internet Control Message Protocol

IETF Internet Engineering Task Force

IGMP Internet Group Management Protocol

IP Internet Protocol

IPCP(v6) Internet Protocol Control Protocol (related to PPP)

ISP Internet Service Provider

L2TP Layer 2 Tunnelling Protocol

5



6rd 6 Rapid Deployment

LCP Link Control Protocol

LSNAT LargeScale NAT

MLD Multicast Listener Discovery Protocol

MTU Maximum Transmission Unit

NA(P)T Network Address (Port) Translation

NCP Network Control Protocol

NA Neighbour Advertisements

ND Neighbour Discovery

NS Neighbour Solicitations

NTP Network Time Protocol

NUD Neighbour Unreachability Detection

PD Prefix Delegation

PPP Point to Point Protocol

QoS Quality of Service

RA Router Advertisements

RFC Request For Comment

RIR Regional Internet Registry

RS Router Solicitations

RTADVD RouTer ADVertisement Daemon

SLAAC Stateless Address Auto-Configuration

TG Technicolor Gateway

ULA Unique Local Address

VLAN Virtual LAN

6




1.2 References [1] www.ietf.org : See chapter "10.2 Technicolor Gateway: Supported RFCs" on page 30.

[2] www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml Some well-known multicast addresses with IANA

[3] www.broadband-forum.org

[4] www.census.gov/ipc/www/popclockworld.html

http://www.ietf.org/

http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml

http://www.broadband-forum.org/

http://www.census.gov/ipc/www/popclockworld.html

7



2 Introduction

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

And more info on EUI-64 (SLAAC-related):

▪ "Appendix E EUI-64 Interface ID" on page 50

8




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:

▪ "8 Transition / tunneling" on page 18

▪ "8.3 6RD" on page 20

▪ "11.1 Additional Transition / tunnelling techniques: DS-Lite" on page 31.

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.

9



4 IPv6 in a nutshell

Introduction

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.

10




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:

▪ "8 Transition / tunneling" on page 18

▪ "11.1 Additional Transition / tunnelling techniques: DS-Lite" on page 31

▪ "8.3 6RD" on page 20

▪ "11.4 Other" on page 33

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.

11



6 IPv6 fundamentals

6.1 Addressing structure

6.1.1 Basics ▪ 128-bits address

▪ Address type:

Unicast

Multicast

Anycast

▪ Address Notation:

Format: XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX (hex)

Leading zeroes can be skipped

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

12




6.3 IPv6 Address Format Several RFCs describe the IPv6 addressing format: RFC4291 (global Unicast IPv6), RFC3056 (6to4),…

This chapter shows a small overview of a few common-used IPv6 address types.

6.3.1 Link-local address Characteristics:

▪ For use on a "local network" or on a point-to-point link (for example PPP).

▪ No routable addresses, only local significance

▪ Used in SLAAC

▪ Used for neighbour discovery

▪ Fixed prefix fe80::/10

Format:

1111 1110 10 Interface ID0

64 bits54 bits10 bits

Link-local Address

128 bits

Figure 1 Address format: Link Local IPv6 Address

6.3.2 Global Unicast Address Characteristics:

▪ Global significance.

▪ Composed of Prefix/subnet-id/interface-id

Prefix blocks assigned via IANA / Local RIRs.

Subnet-ID to identify different subnets

Interface-ID to complete unique address

Format:

Global Routing Prefix Interface IDSubnet ID

64 bits64-n bitsn bits

Global Unicast Address

Figure 2 Address format: Global Unicast Address

13



6.3.3 Multicast Address Characteristics:

▪ Prefix defines the scope of the multicast address

▪ Fixed prefix ff00::/8

▪ Some well-known multicast addresses with IANA (http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml)

Format:

1111 1111 Interface IDFlags0RPT


Scope

4 bits

Multicast Address

Figure 3 Address format: Multicast Address

6.3.4 6to4 Address Characteristics:

▪ Specific address for transition to IPv6.

▪ Used as tunnel to encapsulate IPv6 packets in IPv4.

▪ Fixed prefix 2002::/16

Format:

TLA0X0002 Interface IDPublic IPv4

Address


FP

13 bits

SLAID

16 bits

6to4 Address

Figure 4 Address format: 6to4 Address

14




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.

15



7.2 IPv6-only hosts

Figure 6 IPv6-only hosts on LAN

Configuration

1

▪ Link-local IPv6 address

▪ Global Unicast IPv6 Address (GUA)

▪ SLAAC or static configuration

▪ (optional) DHCPv6 client for other configuration retrieval

2


▪ 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.

16




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








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.

17



7.4 Benefits and drawbacks Benefits:

▪ No encapsulation overhead, i.e. native IP forwarding.

Drawbacks:

▪ Does not solve the Public IPv4 address shortage as each device must still get a public IPv4 address

▪ All involved equipment must support IPv6, so upgrades (both soft- and/or hardware) might be required.

7.5 Configuration Technicolor CPE configuration examples, see: "Appendix Configuration cookbook: scenarios" on page 37

18




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


▪ Same configuration as "Figure 7 Mixture of IPv4 / IPv6 LAN hosts" on page 16

2





19



▪ 6to4 tunnel

▪ Router Advertisement Daemon for IPv6 (6to4 specific) prefix delegation to LAN


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.

20




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


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.

21



9 IPv6 Technicolor Gateway: Surrounding protocols

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.

Figure 10 Routed PPPv4/v6

22




Configuration

1

▪ Mixture of IPv4 and IPv6 LAN hosts:


2



▪ PPPv4/v6 on WAN interface (PPPoA or PPPoE)





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.

23



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.

24




9.2.5 Typical use case

Figure 11 DHCPv6 with Prefix Delegation

Configuration

1



2



▪ PPPv4/v6 on WAN interface (PPPoA or PPPoE)


▪ DHCPv6 client on WAN interface, requesting prefix and other configuration options (1) to (4)

▪ Router Advertisement Daemon for IPv6 prefix delegation to LAN (5)

▪ (optional) DHCPv6 stateless server configuration to support DHCPv6 LAN clients (for example DNS server information) (6) and (7)

25



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).

26




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.

27



Figure 13 DNS Proxy

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.

28




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).

29



10.1 Technicolor Gateway: Feature Summary

Feature Description

Dual IP stack Dual IP stack implementation. Unified CLI for configuration.

6to4 tunnels Support for 6to4 tunnelling, both manual and automatic tunnel setup.

Addressing SLAAC

Link-Local addresses - Global Unicast addresses - Multicast addresses

DHCPv6 Stateless / Stateful v6 Client - Stateless v6 Server

Prefix Delegation

Non-Temporary Addresses

ICMPv6 ND (NS / NA) - RS / RA - DAD - NUD

SLAAC

PING / Traceroute

ICMP Re-direct

Path MTU Discovery

Route Information Option

PPPv6 Single PPP interface with IPv4 and/or IPv6 on top

DNSv6 DNSv6 server

DNS v4/v6 Proxy

Support for E-DNS and DNS over TCP

MLDv1/v2 host Support for MLDv1/v2 - host-part only

Stateful firewall Stateful firewall for IPv6

QoS QoS, similar to IPv4

Telnet / FTP Telnet / FTP support for IPv6

30




10.2 Technicolor Gateway: Supported RFCs

RFC number Description

1981 Path MTU Discovery.

2460 / 5095 IPv6 Specification / Deprecation of Type 0 Routing Headers in IPv6

2464 Transmission of IPv6 Packets over Ethernet Networks

2473 Generic Packet tunnelling in IPv6

2671 Extension Mechanisms for DNS (E-DNS)

2710 / 3810 MLD v1/v2 (host-part only)

3056 6to4 Tunnelling

3315 DHCP for IPv6 (DHCPv6)

3587 IPv6 Global Unicast Address Format

3596 DNS Extensions for IPv6

3633 IPv6 Prefix Options for DHCPv6

3769 Requirements for IPv6 PD

3901 DNS IPv6 Transport Operational Guidelines

4007 IPv6 Scoped Address Architecture

4191 Default Router Preference and More Specific Routes

4213 Basic Transition Mechanisms for IPv6 Hosts and Routers (subset only)

4242 Information Refresh Option for DHCPv6

4291 IPv6 Addressing Architecture

4294 IPv6 Node Requirements

4443 ICMPv6

4861 ND for IPv6

4862 SLAAC

5072 IPv6 over PPP

For consulting the RFCs, please visit www.ietf.org.


31



11 Technicolor Gateway: Coming up next ...

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.

11.1 Additional Transition / tunnelling techniques: DS-Lite

Scenario

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)


32





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.

33



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.

34




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.

35



Some examples of popular list commands:

:ip iplist [expand=enabled] :ip rtlist [expand=enabled] :dhcp clientv6 iflist [expand=enabled]

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.

Some examples:

:ip debug traceconfig state=enabled/disabled forward=all drop=all :ip rt6advd debug traceconfig state=enabled/disabled :ppp ifconfig trace=enabled/disabled

"help" or "?" can be executed within each CLI topic to find the correct syntax, available parameters and some help information on the commands/parameters.

36




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.

37



Appendix B Configuration cookbook: scenarios

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).

:eth vlan add name=vlan_eth vid=2 addrule=disabled :eth ifadd intf=vlan_eth :eth ifconfig intf=vlan_eth dest=eth_ge vlan=vlanXX :eth ifconfig intf=vlan_eth wan=enabled priotag=disabled :eth ifattach intf=vlan_eth

Proceed as follows:

1 To add a WAN IP interface, execute:

:ip ifadd intf=wan_ip dest=eth_ge (or vlan_eth in vlan-scenario) :ip ifconfig intf=wan_ip mtu=1500 linksensing=enabled group=wan ipv4=enabled ipv6=enabled dadtransmits=1 retranstimer=1000 acceptra=enabled :ip ifattach intf=wan_ip

2 To enable IPv6 on the Local Network Interface, execute:

:ip ifconfig intf=LocalNetwork ipv6=enabled

3 To enable DHCP Client v6 configuration on the WAN IP Interface, execute:

:dhcp clientv6 ifadd intf=wan_ip :dhcp clientv6 ifconfig intf=wan_ip listenra=enabled stateless=disabled rapidcommit=disabled leasetime=7200 irt=86400 iana=1 iapd=1 duidtype=duid-llt leasehist=enabled (define options:) :dhcp clientv6 oro add intf=wan_ip option=domain-name-servers required=disabled :dhcp clientv6 oro add intf=wan_ip option=domain-name-search required=disabled :dhcp clientv6 oro add intf=wan_ip option=ia-prefix-delegation required=disabled :dhcp clientv6 ifattach intf=wan_ip

38




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:

:dhcp client ifadd intf wan_ip :dhcp client rqoptions add option domain-name-servers intf wan_ip :dhcp client rqoptions add intf wan_ip option classless-static-routes :dhcp client rqoptions add intf wan_ip option default-routers :dhcp client ifattach intf wan_ip

5 To activate NAT on the WAN IP Interface (similar as in previous releases):, execute:

:nat ifconfig intf wan_ip translation enabled

6 To configure the Router Advertisement Daemon, execute:

:ip rt6advd ifdetach intf=LocalNetwork :ip rt6advd ifconfig intf=LocalNetwork maxinterval=600 mininterval=200 mflag=no oflag=no reachabletime=0 curhoplimit=64 deflifetime=1800 :ip rt6advd pdadd intf=LocalNetwork subnet-id=0:0:0:1::/64 origin=wan_ip :ip rt6advd ifattach intf=LocalNetwork :ip rt6advd config zerotime=disabled

Subnet-id

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:

:ip rt6advd pdadd intf=LocalNetwork subnet-id=0:0:0:1::/64 origin=wan_ip

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).

Example:

Delegated Prefix: 2001:db8::/56

Possible combinations:

Subnet-id Prefix

0:0:0:0::/64 2001:db8::/64

0:0:0:1::/64 2001:db8:0:1::/64

0:0:0:2::/64 2001:db8:0:2::/64

0:0:0:3::/64 2001:db8:0:3::/64

0:0:0:4::/64 2001:db8:0:4::/64

39



0:0:0:5::/64 2001:db8:0:5::/64

... ...

0:0:0:ff::/64 2001:db8:0:ff::/64

40




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:

:ip rt6advd ifdetach intf=LocalNetwork :ip rt6advd ifconfig intf=LocalNetwork oflag=enabled :ip rt6advd ifattach intf=LocalNetwork

41



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.

Proceed as follows:

1 To configure the PPP interface, execute:

:ppp ifadd intf=PPP_Internet :ppp ifconfig intf=PPP_Internet dest=eth_ge class=12 accomp=enabled trace=enabled echo=10 doddelay=120 dnsmetric=0 :ppp ifconfig intf=PPP_Internet user=PPP_userID password=PPP_passwd :ppp ifattach intf=PPP_Internet

2 To enable IPv6 on the Local Network Interface, execute:

:ip ifconfig intf=LocalNetwork ipv6=enabled

3 To enable the DHCPv6 client on the PPP Interface, execute:

:dhcp clientv6 ifadd intf=PPP_Internet :dhcp clientv6 ifconfig intf=PPP_Internet listenra=enabled stateless=disabled rapidcommit=disabled leasetime=7200 irt=86400 iana=1 iapd=1 duidtype=duid-llt leasehist=enabled (define some options:) :dhcp clientv6 oro add intf=PPP_Internet option=domain-name-servers required=disabled :dhcp clientv6 oro add intf=PPP_Internet option=domain-name-search required=disabled :dhcp clientv6 oro add intf=PPP_Internet option=ia-prefix-delegation required=disabled :dhcp clientv6 ifattach intf=PPP_Internet

4 To enable Nat on the PPP Interface, execute:

:nat ifconfig intf PPP_Internet translation enabled

5 To configure the Router Advertisement Daemon, execute:

:ip rt6advd ifdetach intf=LocalNetwork :ip rt6advd ifconfig intf=LocalNetwork maxinterval=200 mininterval=120 mflag=no oflag=no reachabletime=0 curhoplimit=64 deflifetime=1800 :ip rt6advd pdadd intf=LocalNetwork subnet-id=0:0:0:1::/64 origin=PPP_Internet :ip rt6advd ifattach intf=LocalNetwork

42




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:

:ip rt6advd ifdetach intf=LocalNetwork :ip rt6advd ifconfig intf=LocalNetwork oflag=enabled :ip rt6advd ifattach intf=LocalNetwork

43



B.5 Verification commands Proceed as follows:

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.

44




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:

45



=>:ip rt6advd pdlist Subnet-ID Interface-ID Adv. Intf. Origin intf. ---------------------------------------------- ---------------------------------------------- ---------------- -------------- 0:0:0:1::/64 LocalNetwork Internet 0:0:0:2::/64 ::a:bebe loop Internet =>

6 To show the result of applying the configuration of the prefix delegation onto the received prefix, execute:

=>:ip rt6advd pfxlist Flags legend: [A]utonomous [D]ynamic On-[L]ink Prefix Interface Valid Preferred Flags ---------------------------------------------- ---------------- --------------- --------------- ----- 2001:db8:9388:1001::/64 LocalNetwork 77100/86400 77100/86400 [ADL] 2001:db8:9388:1002::a:bebe/64 loop infinite infinite [ADL] =>

46




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:

:ip rt6advd ifadd intf=loop :ip rt6advd ifconfig intf=loop maxinterval=600 mininterval=200 mflag=no oflag=no reachabletime=0 curhoplimit=64 deflifetime=1800 :ip rt6advd pdadd intf=loop subnet-id=0:0:0:2::/64 interface-id=::bebe origin=PPP_Internet :ip rt6advd ifattach intf=loop

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.

To configure this, execute:

:ip rt6advd ifdetach intf=LocalNetwork :ip rt6advd ifconfig intf=LocalNetwork maxinterval=600 mininterval=200 mflag=no oflag=no reachabletime=0 curhoplimit=64 deflifetime=1800 :ip rt6advd pdadd intf=LocalNetwork subnet-id=::/64 origin=PPP_Internet :ip rt6advd pdadd intf=LocalNetwork subnet-id=::/64 interface-id=::bebe origin=PPP_Internet :ip rt6advd ifattach intf=LocalNetwork

Use subnet-id=::/64:

▪ without specifying interface-id to configure RA to LocalNetwork, i.e. to LAN hosts

▪ including interface-id configuration to assign an IPv6 address on the LocalNetwork interface of the Technicolor Gateway

47



Appendix D Configuration cookbook: DNS

Key Functionality

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:

:dhcp clientv6 ifconfig intf=Internet dnsmetric=10

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

48




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.

To configure this for DHCPv4, execute:

:dhcp client ifconfig intf=Internet dnsmetric=10

To configure this for DHCPv6, execute:

:dhcp clientv6 ifconfig intf=Internet dnsmetric=10

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.


: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


: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

49



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


: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


: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 *

50




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

51



Appendix F Tunnels

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.

1 To disable ipv6 on a PPP interface, execute:

:ppp ifconfig intf=Internet ipv6=disabled

2 To add a 6to4 tunnel, execute:

:tunnel 6to4 add ifname=6to4tunnel

3 To configure the 6to4 tunnel, execute:

:tunnel 6 to4 modify ifname=6to4tunnel sourceintf=Internet rrs=192.88.99.1 pltime=604800 vltime=2592000

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.

52




To list some 6to4 info, execute:

=>:tunnel 6to4 list flags: [D]ynamic copy [T]OS # ifname encap mtu sourceintf source subnet relay router(s) pref lifetime valid lifetime flags 4 6to4tunnel 6to4 1280 Internet source_ip_addr none 192.88.99.1 604800 2592000 .. =>

Where the source IP address will be taken from the lower interface, in this example the PPP interface.

To list the router advertisement daemon information, execute:

=>:ip rt6advd pdlist Flags legend: [A]utonomous On-[L]ink Subnet-ID Interface-ID Adv. Intf. Origin intf. Type Flags ------------------------ ------------------------ ---------------- ---------------- ---- ----- ::/64 ::ef:ef:ef:ef LocalNetwork Internet D6T [AL] =>

It shows the template for the delegation of prefix(es) to the LocalNetwork.

Or execute:

=>:ip rt6advd pfxlist Flags legend: [A]utonomous [D]ynamic On-[L]ink [C]onst lifetime Prefix Interface Valid Preferred Type Flags ----------------------------------- ---------------- --------------- --------------- ---- ------ 2002:XXXX:XXXX:0:ef:ef:ef:ef/64 LocalNetwork 2592000/2592000 604800/604800 6to4 [ADLC] =>

Where XXXX:XXXX is the hexadecimal representation of the IPv4 address of the PPP interface. Ie. Source IP address from the 6to4 tunnel.

53



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:


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.

2 To create a 6in4 tunnel, execute:

:tunnel 6in4 add ifname=6in4tunnel

3 To configure the 6in4 tunnel, execute:

:tunnel 6in4 modify ifname=6in4tunnel sourceintf=Internet destination=A.B.C.D

Where destination is the IPv4 address of the 6in4 tunnel endpoint.

4 To add a default route for IPv6 traffic to this 6in4 tunnel, execute:

:ip rtadd dst=::/0 intf=6in4tunnel

5 To configure the "prefix delegation" of the received (e.g. from a tunnel broker), execute:

:ip rt6advd ifdetach intf=LocalNetwork :ip rt6advd pfxadd intf=LocalNetwork prefix=2001:db8:9583::/64 vltime=2592000 pltime=604800 aflag=enabled lflag=enabled :ip rt6advd ifattach intf=LocalNetwork

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:

:ip ipadd intf=LocalNetwork addr=2001:db8:9583::1/64 addroute=enabled

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.

54




To list the router advertisement daemon information, execute:

{Administrator}=>:ip rt6advd pfxlist Flags legend: [A]utonomous [D]ynamic On-[L]ink [C]onst lifetime Prefix Interface Valid Preferred Type Flags ------------------------ ---------------- --------------- --------------- ---- ------ 2001:db8:9583::/64 LocalNetwork 2592000/2592000 604800/604800 USER [A.LC]

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:


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:

:dhcp client ifadd intf=Internet :dhcp client ifconfig intf=Internet metric=1 dnsmetric=0 broadcast=enabled serverroute=disabled followlabel=disabled forcerenew=disabled :dhcp client rqoptions add intf=Internet option=6rd ifattach intf=Internet

Option=6rd can be replaced with option=212.

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:

=>:ip rt6advd pfxlist Flags legend: [A]utonomous [D]ynamic On-[L]ink [C]onst lifetime Prefix Interface Valid Preferred Type Flags ------------------------------------------------- ---------------- --------------- --------------- ---- ------ 2001:db8:9388:3a07::/64 LocalNetwork 2074/3599 1624/3149 6RD [ADL.] =>

This in fact is similar as with DHCPv6 PD.

55



56




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]

mailto:[email protected]

ip version 6 in technicolor gateways

Documents