Internet DRAFT - draft-shishio-v6ops-dpvt
draft-shishio-v6ops-dpvt
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]
