Network Working Group S. Jiang
Internet Draft Huawei Technologies Co., Ltd
Intended status: Standards Track G. Chen
Expires: January 04, 2012 China Mobile
July 01, 2011
A Generic IPv6 Addresses Registration Solution
Using DHCPv6
draft-jiang-dhc-addr-registration-01.txt
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 January 04, 2012.
Copyright Notice
Copyright (c) 2011 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
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.
Jiang & Chen Expires January 04, 2012 [Page 1]
Internet-Draft draft-jiang-dhc-addr-registration-00.txt July 2011
Abstract
In the IPv6 address allocation scenarios, host 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 introduces a generic address registration solution
using DHCPv6, and defines one new ND option and three new DHCPv6
options.
Table of Contents
1. Introduction & Requirements .................................. 3
2. Terminology .................................................. 3
3. Overview of Generic Address Registration Solution ............ 3
4. Propagating the Address Registration Request with Prefix
Assignment ...................................................... 4
4.1. RA Address Registration Request Option .................. 5
4.2. DHCPv6 Address Registration Request Option .............. 6
5. DHCPv6 Address Registration Options .......................... 6
5.1. DHCPv6 Address Registration Option ...................... 7
5.2. DHCPv6 Address Registration Acknowledgement Option ...... 7
6. Security Considerations ...................................... 8
7. IANA Considerations .......................................... 9
8. Change Log [RFC Editor please remove] ........................ 9
9. Acknowledgments .............................................. 9
10. References ................................................. 10
10.1. Normative References .................................. 10
10.2. Informative References ................................ 10
Author's Addresses ............................................. 11
Jiang & Chen Expires January 04, 2012 [Page 2]
Internet-Draft draft-jiang-dhc-addr-registration-00.txt July 2011
1. Introduction & Requirements
In the IPv6 address allocation scenarios, there are many host self-
generated addresses, such as addresses in IPv6 Stateless Address
Configuration [RFC4862, RFC4941] scenario and Cryptographically
Generated Addresses (CGA, [RFC3972]), and etc. These addresses are
notionally conflicted with the network managed address architecture,
such as Dynamic Host Configuration Protocol for IPv6 (DHCPv6,
[RFC3315]) managed network or network with Access Control List.
Many operators of enterprise networks and similarly tightly
administered networks have expressed the desire to be at least aware
the hosts' addresses when moving to IPv6. Furthermore, they may want
to stop the usage of some hosts' addresses for various reasons.
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 host may be required to perform this
registration since only granted IPv6 addresses are allowed to be used
to access the network.
In order to fulfill the abovementioned practice, this document
introduces a new Neighbor Discovery (ND) option and a new DHCPv6
option to propagate the address registration solicitation from
network management to hosts. DHCPv6 protocol is suitable to perform
the address registration procedure while DHCPv6 servers play as the
address registration server. Two new DHCPv6 options are defined, the
Address Registration Request Option and the Address Registration
Acknowledgement Option.
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. Overview of Generic Address Registration Solution
By current default, the hosts 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 & Chen Expires January 04, 2012 [Page 3]
Internet-Draft draft-jiang-dhc-addr-registration-00.txt July 2011
As showed in below Figure 1, in the generic address registration
solution, proposed by this document, the network management plate
firstly propagates the solicitations of registering self-generated
addresses, by messages from either local router (step 1a in Figure 1)
or DHCPv6 server (step 1b in Figure 1).
By received such solicitations, a host using the self-generated
address SHOULD send an address registration request message to the
network management (step 2 in Figure 1). The network management MAY
check whether the requested address is accepted, for example,
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 database, which
MAY be used by other network functions, such as DNS or ACL, etc. An
acknowledgement is sent to the host, granting the usage of this
address (step 3 in Figure 1). If the requested address is not
accepted by the network management, a rejected acknowledgement is
sent to the host to indicate that it SHOULD generate a new address.
+--------+ +------------+ +-------------+
| Host | |Local Router| |DHCPv6 Server|
+--------+ +------------+ +-------------+
| | |
|Addr Register Solicitation(1a)| |
|<-----------------------------| |
| Addr Register Solicitation(1b) |
|<------------------------------------------------|
| |
|Send self-generation addr registration request(2)|
|------------------------------------------------>|
| |Register
| |the addr
| Reply granting or rejected acknowledgment (3) |
|<------------------------------------------------|
Figure 1: address registration procedure
4. Propagating the Address Registration Solicitation with Prefix
Assignment
In order to indicate or force the hosts with self-generated addresses
to register their addresses and the appointed address registration
server, new solicitation options need to be defined.
There are more than one mechanism in which configuration parameters
could be pushed to the end hosts. The address registration
solicitation option can be carried in Router Advertisement (RA)
Jiang & Chen Expires January 04, 2012 [Page 4]
Internet-Draft draft-jiang-dhc-addr-registration-00.txt July 2011
message, which is broadcasted by local routers. In the DHCPv6 managed
network, it can also be carried in DHCPv6 messages.
By receiving the address registration solicitation option(s), a host
SHOULD register its self-generated addresses, if there are any, to
the appointed registration server. The solicitation options may
include the IPv6 address(es) of address registration server.
In principle, hosts must receive a prefix from either RA message
[RFC4861] or DHCPv6 message [I-D.ietf-dhc-host-gen-id] so that they
can generate an IPv6 address by themselves. The Address Registration
Solicitation options could be propagated together with prefix
assignment information.
4.1. ND Address Registration Solicitation Option
The ND Address Registration Solicitation Option allows routers to
propagate the solicitation for hosts to register their self-generated
address. This option also carries an IPv6 address of the default
address registration server. This option SHOULD be propagated
together with ND Prefix Information Option, Section 4.6.2, [RFC4861].
The format of the ND Address Registration Solicitation Option is
described as follows:
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 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ Address (Address +
| Registration Server) |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[Open Question to WG] Should the new ND option carry IPv6 address
of the default address registration server? Or this can be
discovered by DHCPv6 discovery mechanism. Should we design a mark
bit for the scenario that ND does NOT appoint an address
registration server? Should we use FQDN instead of Address?
Multiple address registration servers?
Jiang & Chen Expires January 04, 2012 [Page 5]
Internet-Draft draft-jiang-dhc-addr-registration-00.txt July 2011
Fields:
Type (TBA1)
Length 4 (in units of 8 octets, Type and Length themselves
are included).
Address 128-bit IPv6 address of the default Address
Registration Server
Reserved Padding bits. For future use also. The value MUST
be initialized to zero by the sender, and MUST be
ignored by the receiver.
4.2. DHCPv6 Address Registration Solicitation Option
The DHCPv6 Address Registration Solicitation Option allows DHCPv6
server to propagate the solicitation for hosts to register their
self-generated address. Assuming the DHCPv6 server itself is the
address registration server, this option does NOT carries the IPv6
address of the default address registration server. This option
SHOULD be propagated together with DHCPv6 Prefix Information Option,
Section 5, [I-D.ietf-dhc-host-gen-id]. The format of the DHCPv6
Address Registration Solicitation Option is described as follows:
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_Addr_Reg_Solicitation | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_Addr_Reg_Solicitation (TBA2).
option-len 0. length of this option in octets (option-code
and option-len are not included).
[Open Question to WG: is 0 allowed?]
5. DHCPv6 Address Registration Options
The current DHCPv6 protocol is reused as the address registration
protocol while a DHCPv6 serve plays as address registration server.
Two new DHCPv6 options, the Address Registration Request Option and
the Address Registration Acknowledgement Option, are defined in this
section in order to fulfill the address registration interactions.
Jiang & Chen Expires January 04, 2012 [Page 6]
Internet-Draft draft-jiang-dhc-addr-registration-00.txt July 2011
5.1. DHCPv6 Address Registration Request Option
A new DHCPv6 Address Registration Request Option is defined in order
to carry the requested address from hosts to the address registration
server. The format of the DHCPv6 Address Registration Request Option
is described as follows:
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_Addr_Registration_Reques| option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ IPv6 Address +
| (host requested address) |
+ +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_Addr_Registration_Request (TBA3).
option-len 16. length of this option in octets (option-code
and option-len are not included).
Address 128-bit requested IPv6 address, which generated
by the host
By received, the DHCPv6 server MAY check whether the requested
address is accepted, for example, checking the address does not use
the Reserved IPv6 Interface Identifiers [RFC5453]. If the requested
address is accepted, the DHCPv6 server MUST register it in the
address database, which MAY be used by other network functions, such
as DNS or ACL, etc. A DCHPv6 reply message with the below-defined
Acknowledgement Option is sent back to the host for notification.
[Open Question to WG] Should we ack only when address is rejected or
both accepted and rejected?
5.2. DHCPv6 Address Registration Acknowledgement Option
In order to response to registration requests, an acknowledgement
DHCPv6 option is also defined below. It is used to indicate whether
the registration of an IPv6 address is accepted. The format of the
DHCPv6 Address Registration Acknowledgement Option is described as
follows:
Jiang & Chen Expires January 04, 2012 [Page 7]
Internet-Draft draft-jiang-dhc-addr-registration-00.txt July 2011
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_Addr_Registration_Ack | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ack Info | |
+-+-+-+-+-+-+-+-+ +
| |
+ Associated Address +
| (host requested address) |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
option-code OPTION_Addr_Registration_Ack (TBA4).
option-len 17. length of this option in octets (option-code
and option-len are not included).
Ack Info 8 bit. Indicate the associated address is
correctly registered or rejected. All zero means
correctly registered. Otherwise, the associated
address is rejected.
[Open Question to WG] With in the rejected scenarios, should we
also give the different reasons by different value?
Associated Address 128-bit IPv6 address. Indicate the
acknowledgement is associated with which
address.
An acknowledgement is sent to the host, granting the usage of this
address (step 3 in Figure 1). If the requested address is not
accepted by the network management, a rejected acknowledgement is
sent to the host to indicate that it SHOULD generate a new address.
6. Security Considerations
An attacker may use a faked address registration request option to
indicate hosts reports their address to a malicious server and
collect the user information. These attacks may be prevented by using
Secure Neighbor Discovery (SEND, [RFC3971]) if RA Address
Registration Request Option is used, or AUTH option or Secure DHCP
[I-D.ietf-dhc-secure-dhcpv6] if DHCPv6 Address Registration Request
Option is used.
Jiang & Chen Expires January 04, 2012 [Page 8]
Internet-Draft draft-jiang-dhc-addr-registration-00.txt July 2011
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).
The DHCPv6 address registration procedure 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 [I-D.ietf-dhc-secure-dhcpv6] can prevent these
threats.
7. IANA Considerations
This document defines a new Neighbor Discovery [RFC4861] option,
which MUST be assigned Option Type values within the option numbering
space for Neighbor Discovery Option Type:
The Address Registration Solicitation Option (TBA1), 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 options:
The OPTION_Addr_Reg_Solicitation (TBA2), described in
Section 4.2;
The OPTION_Addr_Registration_Request (TBA3), described in Section
5.1;
The OPTION_Addr_Registration_Ack (TBA4), described in
Section 5.2.
8. Change Log [RFC Editor please remove]
draft-jiang-dhc-addr-registration-00, original version, 2011-07-01
9. Acknowledgments
The authors would like to thank Ralph Dorm, Ted Lemon and other
member of DHC WG for valuable comments.
Jiang & Chen Expires January 04, 2012 [Page 9]
Internet-Draft draft-jiang-dhc-addr-registration-00.txt July 2011
10. References
10.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, 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.
10.2. Informative References
[I-D.ietf-dhc-secure-dhcpv6]
S. Jiang and S. Shen, "Secure DHCPv6 Using CGAs", draft-
ietf-dhc-secure-dhcpv6 (work in progress), June, 2011.
[I-D.ietf-dhc-host-gen-id]
S. Jiang, F. Xia, and B. Sarikaya, "Prefix Assignment in
DHCPv6", draft-ietf-dhc-host-gen-id (work in progress),
April, 2011.
Jiang & Chen Expires January 04, 2012 [Page 10]
Internet-Draft draft-jiang-dhc-addr-registration-00.txt July 2011
Author's Addresses
Sheng Jiang
Huawei Technologies Co., Ltd
Huawei Building, No.3 Xinxi Rd.,
Hai-Dian District, Beijing 100085
P.R. China
Phone: 86-10-82882681
Email: jiangsheng@huawei.com
Gang Chen
China Mobile
53A,Xibianmennei Ave.,
Xuanwu District,
Beijing 100053
China
Phone: +86-13910710674
Email: phdgang@gmail.com
Jiang & Chen Expires January 04, 2012 [Page 11]