Technical White Paper

for The Evolution From

IPv4 to IPv6 (Access Part)
Contents
1 IPv6 Address Assignment Technology ....................... 2
1.1 IPv6 Stateless Address Autoconfiguration .................................... 2
1.2 IPv6 Stateful Address Autoconfiguration ...................................... 3
1.2.1 Stateless DHCPv6 ..................................................................... 4
1.2.2 IPv6 Stateful Address Autoconfiguration ................................... 6
1.2.3 Centralized Configuration of IPv6 Prefixes ................................. 7
1.3 Duplicate Link-local Address Detection Agent .............................. 8
1.4 PPP IPv6CP .................................................................................. 9
2 IPv6 Access Scenario .............................................. 10
2.1 Home Gateway Running in the Bridge Mode ............................ 10
2.2 Home Gateway Running in the Routing Mode .......................... 11
2.3 Home Gateway Running in Multiple Modes .............................. 12
2.4 Connecting PPP IPv6 Users to an IPv6 Network with L2TP .......... 12
3 Scenario Where IPv4 Broadband Access Services Transit
to IPv6 Broadband Access Services ......................... 13
4 Conclusion ............................................................. 14
5 Appendix A References .......................................... 14
6 Appendix B Acronyms and Abbreviations ............... 15
Technical White Paper for IPv6
Access

Key Words:
IPv6 Access, PPP, IPv6CP, ND, DHCPv6, IPv6 Prefix Allocation, BRAS,
Home Gateway, L2TP

Abstract:
With the development of the Internet, the shortage of IPv4 address
resources becomes increasingly serious, which prevents operators from
attracting new broadband access users and rolling out new services.
Upgrading IPv4 user access networks to IPv6 user access networks can
solve the problem of IP address shortage.
This chapter describes the applications of IPv6 access technologies in
different networking modes and service models. Operators can select
an optimal solution based on services and networks.

1
 1 IPv6 Address Assignment
Technology
During the upgrade from an IPv4 broadband access network to an
IPv6 broadband access network, the protocols used by access users to
obtain addresses change but the authentication, authorization, and
accounting mechanisms for access users do not change.
In IPv4, there is only one address assignment protocol, that is, the
Dynamic Host Configuration Protocol (DHCP). In IPv6, there are two
address configuration modes: stateful address autoconfiguration and
stateless address autoconfiguration.
On an IPv4 network, a PPPoX user uses an IPv4 address assigned by
IPCP. On an IPv6 network, IPv6CP assigns only link-local addresses;
therefore, a PPPoX user needs to obtain a global unicast address
through stateful address autoconfiguration or stateless address
autoconfiguration.

1.1 IPv6 Stateless Address Autoconfiguration

Stateless address autoconfiguration(SLAAC) uses the Neighbor
Discovery (ND) protocol. ND corresponds to a combination of IPv4
protocols such as the Address Resolution Protocol (ARP) and ICMP
Router Discovery, and provides other functions such as Neighbor
Unreachability Detection (NUD), Duplicate Address Detection (DAD),
and address autoconfiguration.
IPv6 stateless address configuration is implemented by the exchange
of Router Solicitation (RS) messages and Router Advertisement (RA)
messages of ND, as shown in Figure 1.

Figure 1 IPv6 stateless address autoconfiguration

1. The host sends an RS message.

2. After receiving the RS message, the router replies with an RA
message. The contents of the RA message are as follows:

2
Whether address autoconfiguration is used
Autoconfiguration type supported by the flag (stateful or stateless
address autoconfiguration, including the address configuration flag
M and other information configuration flag O)
One or more link prefixes (nodes on the local link can perform
address autoconfiguration by using these address prefixes) and
lifetime of the link prefixes
Whether the router advertised by the sending router can be used as
a default router (if the router can be used as the default router, the
lifetime, expressed in seconds, of the default router is also contained
in the packet.)
Other configuration information about the host, such as the hop
limit and the maximum MTU for the packet initiated by the host
3. If address autoconfiguration is specified in the RA message
received by the host, the M flag is set to 0, and the correct link
prefix is contained in the message, the host uses the link prefix
and interface ID to generate a global unicast address to complete
stateless address configuration.
In stateless address autoconfiguration, the host does not actively
extend the IP address lease. Instead, the router sends an RA carrying
the new lifetime to extend the IP address lease.
Stateless address autoconfiguration is simple. The nodes that support
IPv6 must support ND. Windows 2000 and Windows XP can support
IPv6 after the ipv6 install command is run on them, and support
stateless address autoconfiguration.

1.2 IPv6 Stateful Address Autoconfiguration

During the exchange of RS and RA messages, if the M flag is set
to 0 and the O flag is set to 1, it indicates that the host obtains
configuration information except the address through stateless
DHCPv6. If the M flag is set to 1 in the RA message by the router, it
indicates that the host obtains the address and other configuration
information through stateful address autoconfiguration.
In stateless DHCPv6 and stateful address autoconfiguration, a
DHCPv6 host sends a request to the DHCPv6 server for required
configuration information, and the DHCPv6 server then replies with
the required configuration information.

3
 1.2.1 Stateless DHCPv6
Stateless DHCPv6 is used to obtain configuration information except
the address through two steps, as shown in Figure 2.

Figure 2 Stateless DHCPv6

1. After receiving an RA message in which the M flag is set to 0 and

the O flag is set to 1, the host sends a DHCPv6 Information-Request
packet to obtain the configuration information such as the DNS.
Figure 3 shows the format of packets exchanged between the host
and the server. The contents of the packets are put in the options
field.

Figure 3 Format of messages exchanged between the DHCPv6 client and server

Msg-type: identifies the type of the DHCP messages exchanged

between the DHCPv6 client and server.
transaction-id: indicates the message transaction ID used to match
responses with replies initiated either by a client or server.
options: indicates Options carried in this message.
2. If ROUTE functions as a DHCPv6 server, ROUTE directly sends a
DHCPv6 Reply message to the host. The format of the DHCPv6 Reply
message is shown in Figure 6.
3. If ROUTE functions as a DHCPv6 relay agent, ROUTE encapsulates
the message received from the host as a DHCPv6 Relay-Forward
message, and then sends it to the DHCPv6 server. The format of the
DHCPv6 Relay-Forward massage is shown in Figure 4.

4
 Figure 4 Format of messages exchanged between the DHCPv6 relay agent and server

Msg-type: indicates the type of the messages exchanged between

the DHCPv6 relay agent and server.
hop-count: indicates the number of relay agents that have relayed
this message. When the value of this field is 0, it is increased by 1
when the message passes through each subsequent relay agent.
link-address: indicates a global or site-local address that will be used
by the server to identify the link on which the client is located. It is
the IPv6 address of the interface from which the relay agent receives
a message. The relay agent directly connected to the client must fill
in the field. The DHCPv6 server assigns an address according to the
field.
peer-address: indicates the source IPv6 address of a DHCPv6
message received by a relay agent. This field is used to guide the
forwarding of the return message.
options: must include a "Relay Message option" and may include
other options added by the relay agent. The DHCPv6 message
received by a relay agent from a client or another relay agent is put
into the Relay Message option.
4. After receiving the DHCPv6 Relay-Forward message, the DHCPv6
server sends the required Relay-Reply message to the relay agent.
The format of the Relay-Reply message is shown in Figure 4.
5. After receiving the Relay-Reply message, the DHCPv6 relay
agent obtains the DHCPv6 message from the Relay Message option,
re-encapsulates the message with an IPv6 header, and sends the
message to the peer address contained in the most outer relay agent
header.

5
 1.2.2 IPv6 Stateful Address Autoconfiguration
Stateful address autoconfiguration can complete the
configuration of an address and configuration information
through four or two steps, as shown in Figure 5. After receiving
an RA message with the M flag being 1, the client initiates the
exchange of DHCPv6 messages.

Figure 5 IPv6 stateful address autoconfiguration

The DHCPv6 client can obtain an address from the DHCPv6

server through two steps. That is, the DHCPv6 client sends a
solicit message to the DHCPv6 server to apply for an address,
and the DHCPv6 server returns a Reply message carrying an IP
address to the client after receiving the solicit message. Note
that the solicit message and reply message must carry the Rapid
Commit Option field. Because there is no step for confirming
a DHCPv6 server, you need to take required actions to ensure
that the address of the server that is not selected by the client
is withdrawn as soon as possible, for example, configuring only
one DHCPv6 server on the network to respond to the client or
configuring the DHCPv6 server that is not assigned by the client
to assign an address with a short lease.
When a DHCPv6 server assigns an IPv6 address to a client, the
server sends a message containing the preferred lifetime, valid
lifetime, lease renew time, and rebind time. The relationship
among the preferred lifetime, valid lifetime, lease renew time,
rebind time is: Lease renew time < Rebind time < Preferred
lifetime < Valid lifetime. The preferred lifetime is used to limit
the lease renew time and rebind time. By default, the lease

6
renew time and rebind time account for 50% and 80%
respectively of the preferred lifetime. The valid lifetime
is the lease of an IPv6 address/prefix. When the valid
lifetime of an IPv6 address/prefix expires, the DHCP
server withdraws the IP address/prefix. To keep using the
IP address/prefix, the DHCPv6 client needs to renew the
IPv6 address lease before the valid lifetime expires.
When the lease renew time expires, the DHCPv6 client
automatically sends a Renew message to the DHCPv6
server to renew the IPv6 address lease. After receiving
the Renew message, the DHCPv6 server replies with
a Reply message. When the rebind time expires, the
DHCPv6 client sends a Rebind message to the DHCPv6
server if it does not complete the renewing of the IPv6
address. After receiving the Rebind message, the DHCPv6
server replies with a Reply message.
Windows 2000 and Windows XP do not support DHCPv6
clients, whereas Windows Vista and Windows 7 support
DHCPv6 clients.
DHCPv6 is defined in RFC 3315. For more information
about DHCPv6, refer to RFC 3315.

1.2.3 Centralized Configuration of IPv6

Prefixes Home network
In RFC 3633, the IPv6 prefix options are defined and the
typical application scenario is given. As shown in Figure 6,
the DHCPv6 server assigns an IPv6 prefix to the router at
the user side, and the router then sends the IPv6 prefix ISP core network
to the corresponding host.
DHCPv6 server
IPv6 prefix allocation process is basically the same as the (Delegating
router)
IPv6 address allocation process. The difference is that
the options carried by packets in the two processes are
different. Figure 6 scenario where IPv6 prefixes are assigned in a centralized manner

When the home gateway runs in the routing mode, the

home gateway can initiate the request. The operator
authenticates the home gateway, and assigns an IPv6
prefix to the home gateway through DHCPv6 if the

7
 home gateway passes the authentication. The home gateway uses
the IPv6 prefix to assign IPv6 addresses to the devices that need to
access devices on the operator's network. DHCPv6 is applicable to
the upgrade from an IPv4 network to an IPv6 network when the
home gateway runs in the routing mode.

1.3 Duplicate Link-local Address Detection Agent

The mechanism of duplicate address detection is as follows:
1. The client generates a link-local address or a global unicast
address.
2. The client sends a Neighbor Solicitation (NS) message with
the source IPv6 address being 0 and the destination address being
the multicast address of the solicited node to which the detected
address corresponds.
3. After receiving the NS message, other devices in the network
check whether the target address of the message and the IPv6
address of the interface that receives the NS message conflict. If
not, the devices do not make any response. If yes, the devices send
a Neighbor Advertisement (NA) message to the device that performs
duplicate address detection.
4. If the client does not receive any NA message after the
retransmission time (the default value is 1s) expires, the client
resends an NS message if the set number of retransmission times (the
default value is 1) is greater than 1.
5. When the client sends an NS message for the set number of
transmission times, but does not receive any NA message after the
transmission time expires, the client considers that the address is
not a duplicate address and can be used. Otherwise, the address is
considered as a duplicate address. If the detected address is a link-
local address, the client needs to regenerate or be configured with a
link-local address.
On an IPoX access network, the IPv6 link-local address of the
interface through which a user device accesses the ISP network is
automatically generated or configured. Generally, the address is
used as the source IP address of DHCPv6 packets. To ensure that the
router functioning as a relay agent can correctly forward DHCPv6
messages sent from the DHCPv6 server to users according to the
peer address, you need to ensure that the IPv6 link-local addresses
of the user devices accessing the same interface of the router do not

8
conflict, as shown in Figure 7.
On an ISP network, different users cannot access each other before
going online. That is, the duplicate link-local address detection packet
sent by a user can be sent to the router rather than any other users.
Therefore, the router needs to function as the duplicate link-local
address detection agent. Thus, the router needs to detect whether
the link-local address of the user conflicts with the IPv6 link-local
address of the router interface and whether the link-local address of
the user conflicts with the IPv6 link-local addresses of other users that
access the same router interface as the user. If yes, the router sends a
message to the device that initiates duplicate address detection.

CPE1
link-address1

CPE2 link-address2

link-address3 ISP core network

PC1
Route
link-address4

PC2

Figure 7 Scenario for duplicate link-local address detection

1.4 PPP IPv6CP

In RFC 2472, IP Version 6 over PPP is defined, and two IPV6CP
options, that is, Interface-Identifier and IPv6-Compression-Protocol,
are defined. After the interface ID is negotiated, the link-local address
is generated in the format of FE80::0/64 (link-local prefix) + interface
ID. RFC 5072 and RFC 5172 extend RFC 2472. In RFC 5172, the
negotiation of the IPv6 compression protocol in the IPv6CP option
is defined. In RFC 5072, the negotiation of the interface ID in the
IPv6CP option is defined, and the solution to the generation of a
global unicast address on a PPP link is provided.
As defined in RFC 5072, the interface ID used to generate a global
unicast address on a PPP link should be different from the interface ID
negotiated by IPv6CP, and a global unicast address can be generated
through stateful address autoconfiguration and stateless address
autoconfiguration.

9
 2 IPv6 Access Scenario

On a broadband access network, the service models

of different operators are different, and the running
modes of home gateways are different. The
running modes of home gateways include terminal
mode, bridge mode, and routing mode. When a
home gateway runs in the terminal mode, it can
initiate a connection for a terminal without any IP
address. For example, it can initiate a connection to
the NMS for a VoIP telephone terminal. Therefore,
the associated operator can manage the device
through the connection. When the home gateway
runs in the terminal mode, the access mode of the
home gateway is the same as other terminals such
as PCs and STBs.
During the initial stage of the transition from IPv4
to IPv6, address allocation is performed through
L2TP at the side of the LNS that functions as the
BRAS, and the packets of PPP users running IPv6
or IPv4/IPv6 dual-stack are sent to the BRAS for
processing. In this case, the LAC does not need to
be upgraded to an IPv6 device.

2.1 Home Gateway Running in the

Bridge Mode
When the home gateway runs in the bridge
mode, each terminal in the home needs to be ISP core network

authenticated separately and obtain an address BRAS

from the operator, as shown in Figure 8.
A terminal in the home initiates a PPP or ND/
DHCPv6 connection. The DSLAM records the

Figure 8 Scenario where the home gateway runs in the bridge mode

10
position of the terminal. The BRAS performs
authentication, authorization, and accounting
for the user, and then assigns an IPv6 address or
prefix to the user based on the IPv6 address or
prefix received from the local or remote DHCPv6
server.
When the terminal supports only stateless address
autoconfiguration, the BRAS needs to function as
the DHCPv6-PD proxy, and applies to the remote
DHCPv6 server for an IPv6 prefix instead of the
terminal, and then forward an IPv6 prefix received
from the DHCPv6 server to the terminal through
an RA message. If the terminal supports DHCPv6,
the BRAS needs to function as a DHCPv6 relay
agent, and forwards the DHCPv6 message of the
terminal to the remote DHCPv6 server, and the
forwards the message sent by the DHCPv6 server
to the terminal.

2.2 Home Gateway Running in the

Routing Mode
When the home gateway runs in the routing
mode, it initiates a request. The operator
authenticates the home gateway, and then assigns
an IPv6 prefix to the home gateway if the home
gateway passes the authentication. The home
gateway then uses the IPv6 prefix to assign IPv6
addresses to the terminals that need to access the ISP core network

network of the operator. In this case, the operator BRAS

manages only the home gateway, and the
terminals in the home are managed by the home
gateway, as shown in Figure 9.

The home gateway initiates a PPP connection.

Figure 9 Scenario where the home gateway runs in the routing mode
After the PPP connection is set up, the home
gateway sends a DHCPv6-PD request. Or, the
home gateway directly sends a DHCPv6-PD
request. The DSLAM records the position of the
terminal. The BRAS performs authentication,
authorization, and accounting on the terminal,
and then assigns an IPv6 address or prefix to
the terminal based on the IPv6 address or prefix
11
 received from the local or remote DHCPv6 server.

NMS The home gateway uses ND or DHCPv6 to assign IPv6

VOIP VOIP
addresses to the terminals that need to access the
network of the operator.
IPTV ISP core network

BRAS
IPTV 2.3 Home Gateway Running in Multiple
Modes
_For TR69 services, the home gateway initiates a connection,
and runs in the terminal mode. A home gateway can run in multiple modes. For
_For VolP services, the home gateway initiates a connection, example, a home gateway needs to work in routing
and runs in the terminal mode instead of the telephone.
mode for go-online services, and needs to work in the
-For IPTV servlces, the STB initiates a connection, and the
home gateway runs in the bridge mode. bridge mode for IPTV services. In addition, the home
-For online services, the home gateway initiates a connection, gateway functions as a terminal and runs VoIP and
and runs in the routing mode.
TR69 (NMS services) services, as shown in Figure 10.
Figure 10 Scenario where the home gateway runs in multiple modes

2.4 Connecting PPP IPv6 Users to an

IPv6 Network with L2TP
On an IPv4 access network, L2TP is used for service
wholesale. In the networking shown in Figure 11,
the LAC can set up L2TP tunnels with the BRASs of
each ISP beforehand or temporarily. When a user gets
ISP1 online, the LAC can determine the ISP that the user
BRAS
IPv4
LNS wants to access based on the domain-name suffix
BRAS contained in the user name. Then, the LAC forwards
LAC ISP2 the packet of the user to the BRAS in the associated
BRAS
LNS ISP through an L2TP tunnel.
CPv6
By using L2TP to assign IP addresses on the LNS, you
can configure L2TPv4 tunnels to bear PPP IPv6 or IPv4/
IPv6 dual-stack services. Address allocation is not
Figure 11 Networking diagram of service wholesale through L2TP tunnels
involved at the LAC side. Therefore, the LAC does not
need to be upgraded to an IPv6 device, and you need
to upgrade only the LNS to be an IPv6 device.
Configuring L2TPv4 tunnels to bear PPP IPv6 or dual-
stack services does not affect the running mode of
the home gateway. In this case, however, only the PPP
access mode can be used.

12
3 Scenario Where IPv4 Broadband Access Services
Transit to IPv6 Broadband Access Services

As shown in Figure 10, there are multiple services on

the network of the operator, and each service has
its feature. Therefore, a proper upgrade solution is
required during the upgrade from IPv4 to IPv6.
There are few service providers of NMS services
and IPTV serves, and the users running the services
do not interact with each other. Therefore, these
services can be directly upgraded to IPv6 services.
The interaction between VoIP users is single and
there are few VoIP service providers. Therefore, VoIP
services can be directly upgraded to IPv6 services.
There are many Internet service providers and the
interaction between the go-online users is complex.
Therefore, proper transition technologies such as
VOIP
dual-stack, tunneling, and translation technologies NMS
are required to enable users to access IPv4 and IPv6 VOIP IPv6
IPv6 IPv4
networks. For details about the applications of these IPv4
IPTV
technologies, see IPv4-IPv6 transition technologies. IPv6
IPv6
When the IPv4/IPv6 dual-stack technology is used, BRAS
for a PPP access user, IPv4 address allocation IPv6
IPTV
and IPv6 address allocation require only one PPP
connection; for an IP access user, two connections
are required. The BRAS needs to be configured Figure 12 Scenario where different services adopt different upgrade solutions

with the policy for identifying IPv4/IPv6 dual-stack

users. For example, the BRAS can identify an IPv4/
IPv6 dual-stack user based on the MAC address or a
DHCP Option.

13
 4 Conclusion

During the upgrade from an IPv4 broadband access network

to an IPv6 broadband access network, the addresses of users
are upgraded from IPv4 addresses to IPv6 addresses; the
authentication, authorization, and accounting mechanisms of
users do not change; the service models do not change. Services
have their own features. For example, TR69, IPTV, and VoIP
services can be directly upgraded to IPv6 services, whereas go-
online services require different transition technologies during the
upgrade so that users can access IPv4 and IPv6 networks.

5 Appendix A References

(1) RFC4861, Neighbor Discovery for IP version 6 (IPv6)

(2) RFC4862, IPv6 Stateless Address Autoconfiguration
(3) RFC5006, IPv6 Router Advertisement Option for DNS
Configuration
(4) RFC5072, IP Version 6 over PPP
(5) RFC5172, Negotiation for IPv6 Datagram Compression Using
IPv6 Control Protocol
(6) RFC3162, RADIUS and IPv6
(7) RFC3315, Dynamic Host Configuration Protocol for IPv6
(DHCPv6)
(8) RFC3633, IPv6 Prefix Options for Dynamic Host Configuration
Protocol (DHCP) version6
(9) RFC3646, DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)
(10) RFC3736, Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6

14
6 Appendix B Acronyms and
Abbreviations
Abbreviations
PPP Point-to-Point
IPCP PPP IPv4 Control Potocol
IPv6CP PPP IPv6 Control Protocol
ARP Address Resolution Protocol
SLAAC Stateless Address Autoconfiguration
ND Neighbor Discovery
ICMP Internet Control Message Protocol
DUD Neighbor Unreachability Detection
DAD Duplicate Address Detection
RS Router Solicitation
RA Router Advertisement
DHCPv6 Dynamic Host Configuration Protocol for IPv6
DNS Domain Name Service
NS Neighbor Solicitation
NA Neighbor Advertisement
NMS Network Management System
STB Set-top Box
VoIP Voice over Internet Protocol
BRAS Broadband Remote Access Server
DSLAM Digital Subscriber Line Access Multiplexer
DHCPv6-PD DHCPv6 Prefix Delegation
L2TP Layer 2 Tunneling Protocol
LAC L2TP Access Concentrator
LNS L2TP Network Server

15
 Copyright 2010 Huawei Technologies Co., Ltd. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior written
consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions

and other Huawei trademarks are the property of Huawei Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective holders.

Notice
The product, service, or feature that you purchase should be restricted by
the Huawei commercial contract and the clauses in the contract. All or a
part of products, services, or features described in this document may not
be purchased or used. Every effort has been made in the preparation of this
document to ensure the accuracy of the contents, but the statements,
information, and recommendations in this document do not constitute a Huawei Technologies Co., Ltd.
warranty of any kind, expressed or implied. Address: Huawei Industrial Base
Bantian, Longgang
The information in this document is subject to change without notice. Every
Shenzhen 518219
effort has been made in the preparation of this document to ensure the People's Republic of China
accuracy of the contents, but the statements, information, and
recommendations in this document do not constitute a warranty of any Website: http://www.huawei.com
kind, expressed or implied. Email: support@huawei.com
16