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

2

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:

3

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

4

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.

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.

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

Figure 2 Stateless DHCPv6

1.2.1 Stateless DHCPv6

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

5

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.

6

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

1.2.2 IPv6 Stateful Address Autoconfiguration

Stateful address autoconf igurat ion 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

7

1.2.3 Centralized Configuration of IPv6 Prefixes

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 to the corresponding host.

IPv6 prefix allocation process is basically the same as the IPv6 address allocation process. The difference is that the options carried by packets in the two processes are different.

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

Figure 6 scenario where IPv6 prefixes are assigned in a centralized manner

Home network

ISP core network

DHCPv6 server(Delegating

router)

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.

8

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

9

Figure 7 Scenario for duplicate link-local address detection

CPE1link-address1

link-address2

link-address3

link-address4Route

CPE2

PC1

PC2

ISP core network

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.

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.

10

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 authenticated separately and obtain an address 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

BRAS

ISP core network

11

The home gateway initiates a PPP connection. 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

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 init iates 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 network of the operator. In this case, the operator manages only the home gateway, and the terminals in the home are managed by the home gateway, as shown in Figure 9.

BRAS

ISP core network

Figure 9 Scenario where the home gateway runs in the routing mode

12

received from the local or remote DHCPv6 server.

The home gateway uses ND or DHCPv6 to assign IPv6 addresses to the terminals that need to access the network of the operator.

2.3 Home Gateway Running in Multiple Modes

A home gateway can run in multiple modes. For example, a home gateway needs to work in routing mode for go-online services, and needs to work in the bridge mode for IPTV services. In addition, the home gateway functions as a terminal and runs VoIP and TR69 (NMS services) services, as shown in Figure 10.

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 online, the LAC can determine the ISP that the user wants to access based on the domain-name suffix contained in the user name. Then, the LAC forwards the packet of the user to the BRAS in the associated ISP through an L2TP tunnel.

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

BRAS

NMS

ISP core networkIPTV

VOIP

IPTV

VOIP

BRAS LAC

CPv6

BRASLNS

BRASLNS

ISP1

ISP2

IPv4

Figure 10 Scenario where the home gateway runs in multiple modes

Figure 11 Networking diagram of service wholesale through L2TP tunnels

_For TR69 services, the home gateway initiates a connection, and runs in the terminal mode.

_For VolP services, the home gateway initiates a connection, and runs in the terminal mode instead of the telephone.

-For IPTV servlces, the STB initiates a connection, and the home gateway runs in the bridge mode.

-For online services, the home gateway initiates a connection, and runs in the routing mode.

13

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 dual-stack, tunneling, and translation technologies are required to enable users to access IPv4 and IPv6 networks. For details about the applications of these technologies, see IPv4-IPv6 transition technologies.

When the IPv4/IPv6 dual-stack technology is used, for a PPP access user, IPv4 address allocation and IPv6 address allocation require only one PPP connection; for an IP access user, two connections are required. The BRAS needs to be configured 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.

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

Figure 12 Scenario where different services adopt different upgrade solutions

IPv6

IPv6

IPv6

IPv6

IPv6

IPv4

IPTV

IPv4IPTV

VOIP

VOIP

BRAS

NMS

14

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

15

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

16

Huawei Technologies Co., Ltd.Address: Huawei Industrial Base

Bantian, LonggangShenzhen 518219People's Republic of China

Website: http://www.huawei.comEmail: support@huawei.com

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.

NoticeThe 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 warranty of any kind, expressed or implied.The information in this document is subject to change without notice. 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 warranty of any kind, expressed or implied.