IPv6 Plug & Play with Prefix Delegation Part 2 Proposals to Make Prefix Delegation a Reality

IPv6 Plug & Play with Prefix Delegation Part 2 Proposals to Make Prefix Delegation a Reality

tags:
Yasuhiro Shirasaki
NTT Communications



Part 1 introduced why we need Prefx Delegation (PD), as well as its basic mechanism and its difference with multilink subnet. In Part 2, I will explain the details of the protocols proposed for PD.


Two Methods for Prefix Delegation

At present, there are two main proposals for PD at IETF. One is based on extension to ICMPv6, and the other uses DHCPv6.

Proposal with ICMPv6

The first proposal for PD protocol was “Automatic Prefix Delegation Protocol for Internet Protocol Version 6” (draft-haberman-ipngwg-auto-prefix-02,APD) by B. Haberman and J. Martin. It defined a new ICMPv6 message type and delegates Prefix through 4-way communications: Delegator Query, Prefix Delegator, Initial Request, and Prefix Delegated. It uses IPsec for authentication. The proposal offers necessary features for PD, from request and delegation to return.

This Internet-Draft is expired, and is inherited by “Hierarchical Prefix Delegation Protocol for Internet Protocol Version 6 (IPv6)” (draft-bykim-ipv6-hpd-00) by B. Kim (ETRI) and others. The new I-D recommends Cryptography Generated Address (CGA)(dreft-ietf-send-cga-04) for authentication, but there is no other major differences.

Proposal Using DHCPv6

Dynamic Host Configuration Protocol for IPv6 (DHCPv6) is a protocol for Stateful Address Autoconfiguration, just like DHCPv4. It contrasts with IPv6 Stateless Address Autoconfiguration defined in RFC 2462. It can assign IPv6 adresses to IPv6 nodes. The protocol is based on 4-way communication: DHCPv6 server solicitation by DHCPv6 client, DHCPv6 server advertisement, address request by DHCPv6 client, and DHCPv6 server reply.

DHCPv6 itself only allocates IPv6 addresses. But various DHCPv6 options are being standardized, such as SIP server advertisement (RFC3319), DNS server advertisement (RFC3646), and SNTP server advertisement (draft-ietf-dhc-dhcpv6-opt-sntp-00). These options can be included in the packets from DHCPv6 servers to supply useful information for the activities of IPv6 nodes. This is the same as DHCPv4 used in IPv4.

In addition to DHCPv6, “IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6” (RFC3633,DHCPv6-PD) can be used to realize PD. DHCPv6-PD uses the packet format and server-client communication procedures of DHCPv6, and includes prefix as an optional information instead of IPv6 address information.

DHCP-PD uses information refresh timer values (T1, T2), as well as Preferred Lifetime and Valid Lifetime values for prefix, in the same manner as IPv6 address assignment values for DHCPv6, enabling more minute lifecycle management than APD. Another advantage of DHCP-PD over APD is that it can convey information about SIP, DNS, SNTP and other servers by including it as option, as DHCP-PD uses DHCPv6 format. APD needs defining such options in order to carry such information.

DHCPv6-PD authentication utilizes DHCPv6 authentication mechanisms or IPsec.

Client Authentication

APD and DHCPv6-PD documents specify use of IPsec, CGA or DHCP authentication. But in reality, some form of physical-layer authentication can be assumed to take place before PD. For example, CHAP or PAP is used for PPP connection, and 802.1x or MAC address based authentication is performed for 802.11 or 802.3. For ADSL and FTTH, ATM VC or VLAN tag can be used to associate user information with physical connection. Such authentication can make PD authentication unnecessary, and can be used to determine which prefix to assign.

For example, ADSL dual stack service by OCN, currently in service, uses PPPoE (PPP over Ethernet) CHAP for user authentication. This authentication information is used to choose IPv4 address and IPv6 prefix to assign. During the authentication process, ISP router asks RADIUS authentication server and get authentication result as well as IPv4 address information (whether specific address is assigned or available address is assigned from address pool) and IPv6 prefix. As a result, ISP router can determine user site prefix before PD process begins.

Figure 1 shows the protocols actually used in the OCN dual stack service. Some of the I-Ds in the figure have become RFCs, but implemented features are not much different.




Node Autoconfiguration at User Sites

PD can be used to notify prefix to user router, and the prefix can be used by nodes on the user network to configure their own addresses. In actual use of these nodes, however, DNS server address for name resolution might be required for PC, for example, while temperature sensors would not need such function. Current Router Advertisement only carries prefix information. It doesn’t include any DNS-related information.

One proposal for DNS server address configuration designated specific site local addresses (FEC0:0:0:FFFF::1, FEC0:0:0:FFFF::2, and FEC0:0:0:FFFF::3) as DNS addresses. But site local addresses was deprecated, requiring an alternative method for DNS information. There are three proposals currently being discussed at dnsop working group.
  1. Use only DHCPv6 Information-Request and Reply (DHCPv6 lite)
  2. Specific global addresses designated as DNS addresses
  3. New option in Router Announcement
The first proposal utilizes RFC3315 provisions. Not only DNS but other server address information can be passed through this mechanism, but the nodes need to implement DHCPv6-lite application.

The second proposal doesn’t require a new protocol, as DNS server address can be specified in OS or other components. But use of fixed address may require additional IP-layer management, using anycast or modify routing configuration at each site.

The third method has an advantage over DHCPv6-lite in that it takes less time, as nodes can obtain DNS information at the same time as address configuration using Router Announcement. But it requires a new option for DNS server address and implementing it in RA-related components.

At present, none of these options has gained wide support. Further discussions would influence the implementation of this feature on user router and in ISP services.

この記事のトラックバックURL

http://www.ipv6style.jp/trackback/519
Ads by Google