IPv6 Delegated Prefix Verification Tool

IPv6 Prefix Options for Dynamic Host Configuration Protocol version 6 (DHCP-PD) is defined as RFC3633,IPv6 Rapid Deployment (6rd) is defined as RFC5969. Both of technologies provide IPv6 prefix to edge device on the access network. Delegated edge devices are assigned IPv6 address to the interface from delegated prefix. Prefix Delegation is effective approach to assign IPv6 address hierarchical with scalability. But there are some issues from maintenance perspective. -DHCP-PD server does not care interface address of CPE. -6rd PE does not know which CE are using 6rd delegate prefix. This document proposes new ICMPv6 type to verify delegated prefix on CPE and CE.

The stateless tunnel and prefix delegation technology provides much scalability network to the customer. On one hand, these technologies are difficult to plan additional capacity and hard to know current deployment status unless the devices are completely managed.

6rd[RFC5969] is automatic IPv6 over IPv4 technology. If the operator provides 6rd parameter such as 6rd BR address/6rd prefix/prefix-length and IPv6 internet then CE always can connect without additional configuration for PE from 6rd domains. 6rd is stateless technology so the PE operator can not know how many user already connects/configured.

Service provider delegates large prefix to CPE. And CPE assigns ipv6 prefix to the client from the delegated prefix. ISP does not need maintenance each of client prefix , the architecture provides address hierarchy, thus it can build scalable network. But if the RIR policy and address planning would be changed , ISP can not check how the delegated prefixes are using.

Monitor real traffic data using by IPFIX/Netflow could analyze traffic to the internet on both 6rd and DHCP-PD cases. But CPE internal traffic can not find.

IPv6 Node Information Queries is defined RFC4620 as experimental. It may resolve the problem if the RFC4620 improved as standard.

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Nonce + | | +---------------------------------------------------------------+ | | + + | | + Delegated Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix-length | +-+-+-+-+-+-+-+-+ IPv6 Fields: Destination Address Any legal IPv6 address. In 6rd case, the destination address should be calculated from outer IPv4 address automatically. ICMPv6 Fields: Type TBD will be assigned by IANA. Code 0: verification request Nonce :64-bit field to help avoid spoofing. The value in a "verification request" is chosen automatically by Sender. Delegated Prefix(128bit): the delegate prefix which is the operators would like to know. Prefix-length 8bit

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Nonce + | | +---------------------------------------------------------------+ | index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 interface address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + IPv6 interface address + IPv6 Fields: Destination Address Copied from the Source Address field of the invoking packet. ICMPv6 Fields: Type TBD will be assigned by IANA. Code 1: verification reply Nonce :64-bit field to help avoid spoofing.The value in a "verification reply" is copied from the value of "verification request". index: the value must be copied from SNMP ifindex IPv6 interface address: The interface address are matched Delegated Prefix and prefix-length of verification request.

1. The request node make "verification request" with delegated prefix which are the operator would like to check. 2. The received node compares interface address and Delegated Prefix/prefix-length in the packets. 3-a. If the received node's interface address match the Delegated Prefix/prefix-length, then it contains the interface address and snmp ifindex in the "verification reply". 3-b. If the receives node's interface address does not match the Delegated Prefix/prefix-length, then it makes "does not match any."

If the delegated prefix also delegates to another router. The ISP can not check any even if the protocol is executed.

-00 published -01 add problem statement,another solution,deployment consideration add "nonce" to the packets modify security consideration

The author would like to thank Lorenzo Colitti, Vízdal Aleš, Owen DeLong and Gunter Van de Velde for their useful comment.

IANA should assign New type and code of ICMPv6.

This protocol shares the security issues of ICMPv6 that are documented in the "Security Considerations" section of RFC4443 This protocol has potential risk, because the configuration information be shared by "verification reply" message. The nonce mechanism could avoid spoofing "verification reply"/"does not response". But it is not protect from attacker. The implementation SHOULD be accepted from this NEW TYPE of ICMPv6 message from only authorized node such as 6rd BR and DHCP-PD server.