draft-ietf-dhc-addr-registration-02:
A Generic IPv6 Addresses Registration Solution Using DHCPv6
Author(s): Suresh Krishnan, Gang Chen, Sheng Jiang
In networks that are centrally managed, self-generated addresses cause traceability issues due to their decentralized nature. To minimize the issues due to lack of traceability, these self-generated addresses can be registered with the network for allowing centralized address...
DHC Working Group S. Jiang
Internet-Draft Huawei Technologies Co., Ltd
Intended status: Standards Track G. Chen
Expires: August 29, 2013 China Mobile
S. Krishnan
Ericsson
February 25, 2013
A Generic IPv6 Addresses Registration Solution Using DHCPv6
draft-ietf-dhc-addr-registration-02
Abstract
In networks that are centrally managed, self-generated addresses
cause traceability issues due to their decentralized nature. To
minimize the issues due to lack of traceability, these self-generated
addresses can be registered with the network for allowing centralized
address administration. This document defines a generic address
registration solution using DHCPv6, using a new ND option and a new
DHCPv6 option in order to communicate the use of self-generated
addresses. A new Addr-registration-request message type is defined
for initiate the address registration request, among with two new
Status codes to indicate registration errors on the server 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
Jiang, et al. Expires August 29, 2013 [Page 1]
Internet-Draft IPv6 Address Registration February 2013
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Generic Address Registration Solution . . . . . . . 3
4. Propagating the Address Registration Solicitation . . . . . . . 4
4.1. ND Address Registration Solicitation Option . . . . . . . . 5
4.2. DHCPv6 Address Registration Solicitation Option . . . . . . 5
5. DHCPv6 Addr-registration-request Message . . . . . . . . . . . 6
6. DHCPv6 Address Registration Procedure . . . . . . . . . . . . . 6
6.1. DHCPv6 Address Registration Request . . . . . . . . . . . . 6
6.2. DHCPv6 Address Registration Acknowledge . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Jiang, et al. Expires August 29, 2013 [Page 2]
Internet-Draft IPv6 Address Registration February 2013
1. Introduction
In several common network scenarios, IPv6 addresses are self-
generated by the end-hosts using some information propogated to them
by the network (i.e. the network prefix). Examples of self-generated
addresses include those created using IPv6 Stateless Address
Configuration [RFC4862] , temporary addresses [RFC4941] and
Cryptographically Generated Addresses (CGA) [RFC3972] etc. These
addresses are potentially incompatible with networks with a centrally
managed address architecture such as DHCPv6 [RFC3315] as they lack
traceability and stability.
Many operators of enterprise networks and similarly tightly
administered networks have expressed the desire to be at least aware
of the hosts' self-generated addresses when migrating to IPv6.
One potential way to provide network administrators with most of
their needs while retaining compatibility with normal stateless
configuration would be to register the self-generated addresses with
the systems in place to centrally administer the addresses. The edge
router that observes hosts' addresses through the Neighbor Discovery
protocol is the most suitable devices to register these addresses.
This document introduces a new IPv6 Neighbor Discovery option and a
new DHCPv6 option to solicite edge routers to register addresses.
The DHCPv6 protocol is used to perform the address registration
procedure while the address registration server role may be performed
by a DHCPv6 server or a stand-alone server, which is also considered
as a DHCPv6 server from the DHCPv6 protocol perspective. A new Addr-
registration-request DHCPv6 message type is defined to initiate the
address registration request, and two new Status codes is defined to
indicate registration errors on the server side.
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 [RFC 2119].
3. Overview of Generic Address Registration Solution
In the generic address registration solution, the network management
system solicits the edge routers to register addresses, by sending
solicitation messages from either upstream router (step 1a in Figure
1) or DHCPv6 server (step 1b in Figure 1).
Jiang, et al. Expires August 29, 2013 [Page 3]
Internet-Draft IPv6 Address Registration February 2013
After receiving such solicitations, an edge router implementing this
specification SHOULD send an Addr-registration-request message to the
address registration server (step 2 in Figure 1, defined in Section 5
of this document). The address registration server may be acted by a
DHCPv6 server. By received the address registration request, the
address registration server records the requested address in the
address registration database, which MAY be used by other network
functions, such as DNS or ACL, etc. An acknowledgement MAY be sent
back to the edge router (step 3 in Figure 1).
+----+ +-----------+ +---------------+ +---------------+
|Host| |Edge router| |Upstream Router| |Addr-Reg Server|
+----+ +-----------+ +---------------+ +---------------+
| ND | | |
|<--------->| | |
| | |
|Addr Register Solicitation(1a) |
|<------------------| |
| |
| Addr Register Solicitation(1b) |
|<-------------------------------------|
| |
| Addr-registration-request(2) |
|------------------------------------->|
| |Register
| Acknowledgment addr registration(3) |address
|<-------------------------------------|
Figure 1: Address Registration Procedure
4. Propagating the Address Registration Solicitation
In order to notify the edge routers the availabilityof the address
registration service, new solicitation options are needed. There is
more than one mechanism by which configuration parameters could be
pushed to the edge routers. The address registration solicitation
option can be carried in Router Advertisement (RA) message, which is
broadcasted by upstream routers. In the DHCPv6 managed network, it
can also be carried in DHCPv6 messages. This document defines a new
ND option and a new DHCPv6 option for this purpose. Since the
address registration process is through the standard DHCPv6 client/
server communication - send packets to ff02::1:2, the
All_DHCP_Relay_Agents_and_Servers multicast address, these
solicitation options do not contain the IP address of address
registration server.
After receving a message containing an address registration
solicitation option, an edge router implementing this specification
Jiang, et al. Expires August 29, 2013 [Page 4]
Internet-Draft IPv6 Address Registration February 2013
SHOULD register addresses to the address registration server.
4.1. ND Address Registration Solicitation Option
The ND Address Registration Solicitation Option allows an upstream
router to propagate the solicitation for edge routers to register
addresses. 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 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBA1
Length 1 (in units of 8 octets, Type and Length themselves
are included).
Reserved Padding bits. For future use also. The value MUST
be initialized to zero by the sender, and MUST be
ignored by the receiver.
ND Address Registration Solicitation Option
4.2. DHCPv6 Address Registration Solicitation Option
The DHCPv6 Address Registration Solicitation Option allows a DHCPv6
server to propagate the solicitation for edge routers to register
addresses. This option MAY be propagated together with DHCPv6 Prefix
Delegation Option, [RFC3633]. 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 (not including
option-code and option-len).
DHCPv6 Addr Registration Solicitation Option
Jiang, et al. Expires August 29, 2013 [Page 5]
Internet-Draft IPv6 Address Registration February 2013
5. DHCPv6 Addr-registration-request Message
A DHCPv6 client (the edge router) sends an Addr-registration-request
message to a server to request addresses to be registered. The
format of the Addr-registration-request message is described as
follows, compliant with Section 6 in [RFC3315]:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | transaction-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. options .
. (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type Identifies the DHCPv6 message type; (TBA3).
transaction-id The transaction ID for this message exchange.
options Options carried in this message.
DHCPv6 Addr-Registration-Request message
This Addr-registration-request message MUST NOT contain server-
identifier option and SHOULD only contain IA_NA option(s) and Client
Identifier option.
Clients MUST discard any received Addr-registration-request messages.
Servers MUST discard any Addr-Registration-Request messages that do
not include a Client Identifier option or that do include a Server
Identifier option.
6. DHCPv6 Address Registration Procedure
The DHCPv6 protocol is reused as the address registration protocol
while a DHCPv6 server can play the role of an address registration
server. The IA_NA DHCPv6 option [RFC3315] is reused in order to
fulfill the address registration interactions.
6.1. DHCPv6 Address Registration Request
The edge router sends a DHCPv6 Addr-registration-request message to
the address registration server to ff02::1:2, the
All_DHCP_Relay_Agents_and_Servers multicast address.
Jiang, et al. Expires August 29, 2013 [Page 6]
Internet-Draft IPv6 Address Registration February 2013
The edge router MUST include a Client Identifier option in the Addr-
registration-request message to identify itself to the server. The
DHCPv6 Addr-registration-request message SHOULD contain at least one
IA_NA option. The IA_NA option SHOULD contain at least one IA
Address option.
After receiving this Addr-Registration-Request message, the address
registration server MUST register the requested address(es) in its
address registration database, which may further be used by other
network functions, such as DNS, network access control lists, etc.
If the DHCPv6 server does not support address registration function,
a Reply message with includes a Status Code option with the value the
RegistrationNotSupported (TBA4) MAY be sent back to the initiated
client.
6.2. DHCPv6 Address Registration Acknowledge
After all the addresses have been processed, the address registration
server MAY send a Reply message as the response to registration
requests. The server generates a Reply message and includes a Status
Code option with value Success, a Server Identifier option with the
server's DUID, and a Client Identifier option with the client's DUID.
For each IA in the Release message for which the server does no
register, the server adds an IA option using the IAID from the Addr-
registration-request message, and includes a Status Code option with
the value RegistrationDenied (TBA5) in the IA option. No other
options are included in the IA option.
7. Security Considerations
An attacker may register large number of fake addresses with the
network in order to overwhelm the address registration server. These
attacks may be prevented generic DHCPv6 protection by using the AUTH
option [RFC3315] or Secure DHCPv6 [I-D.ietf-dhc-secure-dhcpv6].
8. IANA Considerations
This document defines a new IPv6 Neighbor Discovery option, the
Address Registration Solicitation Option (TBA1) described in Section
4.1, that requires an allocation out of the registry defined at
http://www.iana.org/assignments/icmpv6-parameters
This document defines a new DHCPv6 option, the
OPTION_ADDR_REG_SOLICITATION (TBA2) described in Section 4.2, that
requires an allocation out of the registry defined at
Jiang, et al. Expires August 29, 2013 [Page 7]
Internet-Draft IPv6 Address Registration February 2013
http://www.iana.org/assignments/dhcpv6-parameters/
This document defines a new DHCPv6 message, the Addr-registration-
request message (TBA3) described in Section 5, that requires an
allocation out of the registry defined at
http://www.iana.org/assignments/dhcpv6-parameters/
This document defines two new DHCPv6 Status code, the
RegistrationNotSupported (TBA4) and RegistrationDenied (TBA5)
described in Section 6, that requires an allocation out of the
registry defined at
http://www.iana.org/assignments/dhcpv6-parameters/
9. Acknowledgements
The authors would like to thank Ralph Droms, Ted Lemon, Bernie Volz,
Sten Carlsen, Erik Kline, Lorenzo Colitti, Joel Jaeggli, Sten
Carlsen, Mark Smith and other members of dhc and v6ops working groups
for their valuable comments.
10. References
10.1. Normative References
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC3633,
December 2003.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC3972, March 2005.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC4862, September 2007.
Jiang, et al. Expires August 29, 2013 [Page 8]
Internet-Draft IPv6 Address Registration February 2013
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC4941, September 2007.
10.2. Informative References
[I-D.ietf-dhc-secure-dhcpv6]
Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs",
draft-ietf-dhc-secure-dhcpv6-07 (work in progress),
September 2012.
Authors' Addresses
Sheng Jiang
Huawei Technologies Co., Ltd
Q14, Huawei Campus
No.156 Beiqing Road
Hai-Dian District, Beijing 100095
P.R. China
Email: jiangsheng@huawei.com
Gang Chen
China Mobile
53A, Xibianmennei Ave., Xuanwu District, Beijing
P.R. China
Phone: 86-13910710674
Email: phdgang@gmail.com
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com
Jiang, et al. Expires August 29, 2013 [Page 9]
