Network Working Group Sheng Jiang
Internet Draft Huawei Technologies Co., Ltd
Intended status: Standards Track October 16, 2009
Expires: April 13, 2010
Addresses Registration Through DHCPv6
draft-jiang-dhc-addr-registration-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 16, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Jiang Expires April 16, 2010 [Page 1]
Internet-Draft draft-jiang-dhc-addr-registration-00.txt October 2009
Abstract
In the IPv6 address allocation scenarios, node self-generated
addresses are notionally conflicted with the network managed address
architecture. These addresses need to be registered in the networking
management plate for the purposes of central address administration.
This document extends Dynamic Host Configuration Protocol for IPv6
(DHCPv6) and Router Advertisement to enable the address registration
processing from nodes to network management.
Table of Contents
1. Introduction & Motivation.....................................3
2. Terminology...................................................3
3. Address Registration through DHCPv6...........................3
4. New Options...................................................5
4.1. Address Registry Request Option for Router Advertisement.5
4.2. Address Registry Request Option for DHCPv6...............6
4.3. Address Registration Acknowledgement Option..............6
5. Security Considerations.......................................7
6. IANA Considerations...........................................7
7. Acknowledgments...............................................8
8. References....................................................8
8.1. Normative References.....................................8
8.2. Informative References...................................8
Author's Addresses...............................................9
Jiang Expires April 13, 2010 [Page 2]
Internet-Draft draft-jiang-dhc-addr-registration-00.txt October 2009
1. Introduction & Motivation
In the IPv6 address allocation scenarios, node self-generated
addresses, such as addresses in IPv6 Stateless Address Configuration
[RFC4862, RFC4941] scenario and Cryptographically Generated Addresses
(CGA, [RFC3972]), is notionally conflicted with the network managed
address architecture, such as DHCPv6-managed network or network with
Access Control List, in which addresses are assigned and managed by
the network management plate.
The current IPv4 address allocation mode in DHCPv4-managed network is
that the DHCPv4 server assigns addresses. Many operators of
enterprise networks and similarly tightly administered networks have
expressed the desire to hold on to this model when moving to IPv6,
because they don't want to have hosts end up with essentially random
IPv6 addresses. However, the notion that a server assigns an address
is for the most part incompatible with IPv6 stateless configuration.
A useful way to give network administrators most of what they want,
while at the same time retaining compatibility with normal stateless
configuration would be: if the self-generated IPv6 addresses are used,
they may need to be registered in and granted by the networking
management plate. The node may be required to perform this
registration since only granted IPv6 addresses are allowed to be used
to access the network.
This document extends Dynamic Host Configuration Protocol for IPv6
(DHCPv6) and Router Advertisement to propagate the address
registration request from network management to nodes. A new Router
Advertisement option and a new DHCPv6 option are defined. Two
existing DHCPv6 options are re-used in the address registration
interaction from nodes to network management.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119].
3. Address Registration through DHCPv6
By current default, the nodes with self-generated addresses do not
register their addresses to any network devices. However, this may
result that the network may reject the access request from these
devices.
Jiang Expires April 13, 2010 [Page 3]
Internet-Draft draft-jiang-dhc-addr-registration-00.txt October 2009
As showed in below Figure 1, in the generic address registration
procedure, the network management plate should firstly propagate the
request of registering self-generated addresses. By received such
requests, a node using the self-generated address should send an
address registration message to the network management. The network
management should check whether the requested address is accepted,
for example, performing a Duplicated Address Detect or checking the
address does not use the Reserved IPv6 Interface Identifiers
[RFC5453]. If the requested address is accepted by the network
management, it is registered in the address manage database, which
may be used by other network functions, such as DNS or ACL. An
acknowledgement is sent to the node, granting the usage of this
address. If the requested address is not accepted by the network
management, a rejected acknowledgement is sent to the node to
indicate that it must generate a new address.
+--------------------+ +---------+
| Network Management | | Node |
+--------------------+ +---------+
| |
| Request Node to register addr |
|----------------------------------------->|
| |
|Send self-generation addr for registration|
|<-----------------------------------------|
register | |
the addr |Reply granting or rejected acknowledgment |
|----------------------------------------->|
Figure 1: address registration procedure
The request of registering self-generated addresses can be carried in
either DHCPv6 messages or Router Advertisement, but both need to
define new options. The registration requests can use DHCPv6 protocol
with the existing DHCPv6 options. The current DHCPv6 protocol allows
for a host to communicate a set of "preferred" addresses to the
server by listing these addresses in IA options [RFC3315]. In order
to response to registration requests, an acknowledgement DHCPv6
option should be defined, too.
Among the mechanisms in which configuration parameters could be
pushed to the end hosts and self-generated addresses sent back to a
central administration, we discuss the stateful configuration
mechanism based on DCHPv6 in this document. Other mechanisms may also
provide similar functions, but out of scope.
Jiang Expires April 13, 2010 [Page 4]
Internet-Draft draft-jiang-dhc-addr-registration-00.txt October 2009
4. New Options
4.1. Address Registry Request Option for Router Advertisement
Address Registration Request Option (AR_REG) for Router Advertisement
[RFC4861] is broadcasted by a router to request hosts to register
their self-generated address(es), if there are any, to a certain
DHCPv6 server.
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 | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| DHCPv6 Server Address (128-bit) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Router Advertisement AR_REG Option Format
Type 8-bit identifier of the RDNSS option type as
assigned by the IANA: (TBA0)
Length 3, 8-bit unsigned integer. The length of the
option (including the Type and Length fields) is
in units of 8 octets.
Reserved A 48-bit field reserved for future use. The
value MUST be initialized to zero by the sender,
and MUST be ignored by the receiver.
DHCPv6 Server Address The IPv6 address of the DHCPv6 server that
the client should register its self-generated
address to. This field should be set to all 0,
if do not assign a DHCPv6 server.
By receiving this AR_REQ Option, the client MUST register its self-
generated address(es), if there are any, by sending a DHCPv6 request
message that contains IA option(s), in which each self-generated
address is listed, to the DHCPv6 server indicated in the AR_REG
Option.
Jiang Expires April 13, 2010 [Page 5]
Internet-Draft draft-jiang-dhc-addr-registration-00.txt October 2009
{undecided question: is it possible here to have multiple DHCPv6
servers?}
4.2. Address Registry Request Option for DHCPv6
DHCPv6 Address Registration Request Option (AR_REG) is sent by a
DHCPv6 server to request a host to register its self-generated
address(es), if there are any. It is carried in DHCPv6 messages from
server to the client.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_AR_REQ | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_AR_REG (TBA1).
option-len 0.
By receiving this AR_REQ Option, the client MUST register its self-
generated address(es), if there are any, by sending a DHCPv6 request
message that contains IA option(s), in which each self-generated
address is listed.
4.3. Address Registration Acknowledgement Option
DHCPv6 Address Registration Acknowledgement Option is sent by a
DHCPv6 server in a response message for address registry message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_AR_ACK | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Acceptance | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 address (128 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_AR_ACK (TBA2).
Jiang Expires April 13, 2010 [Page 6]
Internet-Draft draft-jiang-dhc-addr-registration-00.txt October 2009
option-len 20, length of this option in octets (option-code
and option-len are not included).
Acceptance Indicates whether this IPv6 address are accepted
and registered by the network management or
rejected. 0, accepted; 1, rejected.
Reserved A 24-bit field reserved for future use. The
value MUST be initialized to zero by the sender,
and MUST be ignored by the receiver.
IPv6 address The IPv6 address that this option is associated.
Each Address Registration Acknowledgement Option only indicates the
acceptance information of one IPv6 address. In order to acknowledge
the registration request of multiple addresses, multiple AR_ACK
Options are used.
5. Security Considerations
An attacker could generate IPv6 address registration requests in
order to exhaust the server resources (or to impact on any other
operation that depend on the registration of the address). It is as
vulnerable as all other mechanisms based on DHCPv6 to DOS attacks to
the server. Proper use of DHCPv6 autoconfiguration facilities
[RFC3315], such as AUTH option or Secure DHCP [SDHCP] can prevent
these threats.
If Secure Neighbor Discovery (SEND) protocol is used as the security
mechanism for ND, all the ND options including RDNSS option are also
automatically included in the signatures [RFC3971], so the RDNSS
transport is integrity-protected.
6. IANA Considerations
This document defines a new IPv6 Neighbor Discovery option, which
must be assigned Option Type values within the option numbering space
for ICMPv6 parameters:
The Address Registry Request Option (TBA0) for Router
Advertisement, described in Section 4.1.
This document defines two new DHCPv6 [RFC3315] options, which must be
assigned Option Type values within the option numbering space for
DHCPv6 messages:
Jiang Expires April 13, 2010 [Page 7]
Internet-Draft draft-jiang-dhc-addr-registration-00.txt October 2009
The DHCPv6 Address Registry Request Option (TBA1), described in
Section 4.2.
The DHCPv6 Address Registry Acknowledgement Option (TBA2),
described in Section 4.3.
7. Acknowledgments
The authors would like to thank Cao Wei, Huawei, Stig Venaas, Cisco
for been involved in the early requirement identification and early
discussion.
8. References
8.1. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC2119, March 1997.
[RFC3315] R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins and
M. Carne, "Dynamic Host Configure Protocol for IPv6",
RFC3315, July 2003.
[RFC3971] J. Arkko, J. Kempf, B. Zill and P. Nikander, "SEcure
Neighbor Discovery (SEND) ", RFC 3971, March 2005.
[RFC3972] T. Aura, "Cryptographically Generated Address", RFC3972,
March 2005.
[RFC4861] T. Narten, E. Nordmark, W. Simpson and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] S. Thomson, T. Narten and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC4862, September 2007.
[RFC4941] T. Narten, R. Draves and S. Krishnan, "Privacy Extensions
for Stateless Address Autoconfiguration in IPv6", RFC 4941,
September 2007.
[RFC5453] S. Krishnan, "Reserved IPv6 Interface Identifiers", RFC
4543, February 2009.
8.2. Informative References
[SDHCP] S. Jiang, "Secure DHCPv6 Using CGAs", draft-jiang-dhc-
secure-dhcpv6-02.txt (work in progress), July, 2009.
Jiang Expires April 13, 2010 [Page 8]
Internet-Draft draft-jiang-dhc-addr-registration-00.txt October 2009
Author's Addresses
Sheng Jiang
Huawei Technologies Co., Ltd
KuiKe Building, No.9 Xinxi Rd.,
Shang-Di Information Industry Base, Hai-Dian District, Beijing 100085
P.R. China
Phone: 86-10-82836774
Email: shengjiang@huawei.com
Jiang Expires April 13, 2010 [Page 9]