Network Working Group S. Tsuchiya, Ed. Internet-Draft Cisco Systems Updates: 4443 (if approved) February 25, 2013 Intended status: Standards Track Expires: August 29, 2013 IPv6 Delegated Prefix Verification Tool draft-shishio-v6ops-dpvt-01 Abstract IPv6 Prefix Options for Dynamic Host Configuration Protocol version 6 (DHCP-PD) and IPv6 Rapid Deployment (6rd) are technology to provide IPv6 prefix, not IPv6 address themselves. Delegated Prefix are controlled by Customer Premise Equipment (CPE) and 6rd Customer Edge (6rd CE). The service provider can not confirm utilization of delegated prefix on CE and CPE. This document describes mechanism of verification for delegated prefix on CPE and CE from service provider side. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 29, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Tsuchiya Expires August 29, 2013 [Page 1] Internet-Draft Delegated Prefix Verification Tool February 2013 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. problem statement . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. 6rd[RFC5969] case . . . . . . . . . . . . . . . . . . . . . 3 2.2. DHCP-PD[RFC3633] case . . . . . . . . . . . . . . . . . . . 3 3. Another solution . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. IPFIX/Netflow . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. IPv6 Node Information Queries . . . . . . . . . . . . . . . 4 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. verification request . . . . . . . . . . . . . . . . . . . 4 4.2. verification reply . . . . . . . . . . . . . . . . . . . . 5 4.3. does not match . . . . . . . . . . . . . . . . . . . . . . 6 5. packet processing . . . . . . . . . . . . . . . . . . . . . . . 7 6. development consideration . . . . . . . . . . . . . . . . . . . 7 7. history . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . . 8 11.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Tsuchiya Expires August 29, 2013 [Page 2] Internet-Draft Delegated Prefix Verification Tool February 2013 1. Introduction 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. 2. problem statement 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. 2.1. 6rd[RFC5969] case 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. 2.2. DHCP-PD[RFC3633] case 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. Tsuchiya Expires August 29, 2013 [Page 3] Internet-Draft Delegated Prefix Verification Tool February 2013 But if the RIR policy and address planning would be changed , ISP can not check how the delegated prefixes are using. 3. Another solution 3.1. IPFIX/Netflow 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. 3.2. IPv6 Node Information Queries IPv6 Node Information Queries is defined RFC4620 as experimental. It may resolve the problem if the RFC4620 improved as standard. 4. Message Format 4.1. verification request 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 Tsuchiya Expires August 29, 2013 [Page 4] Internet-Draft Delegated Prefix Verification Tool February 2013 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 4.2. verification reply 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 Tsuchiya Expires August 29, 2013 [Page 5] Internet-Draft Delegated Prefix Verification Tool February 2013 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. 4.3. does not match 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 + | | +---------------------------------------------------------------+ | MBZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 Fields: Destination Address Copied from the Source Address field of the invoking packet. ICMPv6 Fields: Type TBD will be assigned by IANA. Code 2: does not match any. Nonce :64-bit field to help avoid spoofing.The value in a "does not match" is copied from the value of "verification request". Tsuchiya Expires August 29, 2013 [Page 6] Internet-Draft Delegated Prefix Verification Tool February 2013 MBZ:Must be Zero 5. packet processing 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." 6. development consideration If the delegated prefix also delegates to another router. The ISP can not check any even if the protocol is executed. 7. history -00 published -01 add problem statement,another solution,deployment consideration add "nonce" to the packets modify security consideration 8. Acknowledgements The author would like to thank Lorenzo Colitti, VAzdal AleAe!, Owen DeLong and Gunter Van de Velde for their useful comment. 9. IANA Considerations IANA should assign New type and code of ICMPv6. 10. Security Considerations This protocol shares the security issues of ICMPv6 that are Tsuchiya Expires August 29, 2013 [Page 7] Internet-Draft Delegated Prefix Verification Tool February 2013 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. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. [RFC4620] Crawford, M. and B. Haberman, "IPv6 Node Information Queries", RFC 4620, August 2006. [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010. 11.2. Informative References Author's Address Shishio Tsuchiya (editor) Cisco Systems Midtown Tower, 9-7-1,Akasaka Minato-Ku, Tokyo 107-6227 Japan Phone: +81 3 6434 6543 Email: shtsuchi@cisco.com Tsuchiya Expires August 29, 2013 [Page 8]