draft-ietf-dhc-addr-registration-01.txt   draft-ietf-dhc-addr-registration-02.txt 
6man Working Group S. Jiang DHC Working Group S. Jiang
Internet-Draft Huawei Technologies Co., Ltd Internet-Draft Huawei Technologies Co., Ltd
Intended status: Standards Track G. Chen Intended status: Standards Track G. Chen
Expires: April 25, 2013 China Mobile Expires: August 29, 2013 China Mobile
S. Krishnan S. Krishnan
Ericsson Ericsson
October 22, 2012 February 25, 2013
A Generic IPv6 Addresses Registration Solution Using DHCPv6 A Generic IPv6 Addresses Registration Solution Using DHCPv6
draft-ietf-dhc-addr-registration-01 draft-ietf-dhc-addr-registration-02
Abstract Abstract
In networks that are centrally managed, self-generated addresses In networks that are centrally managed, self-generated addresses
cause traceability issues due to their decentralized nature. To cause traceability issues due to their decentralized nature. To
minimize the issues due to lack of traceability, these self-generated minimize the issues due to lack of traceability, these self-generated
addresses can be registered with the network for allowing centralized addresses can be registered with the network for allowing centralized
address administration. This document defines a generic address address administration. This document defines a generic address
registration solution using DHCPv6, using a new ND option and a new registration solution using DHCPv6, using a new ND option and a new
DHCPv6 option in order to communicate the use of self-generated DHCPv6 option in order to communicate the use of self-generated
addresses. 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 Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2013. This Internet-Draft will expire on August 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Generic Address Registration Solution . . . . . . 3 3. Overview of Generic Address Registration Solution . . . . . . . 3
4. Propagating the Address Registration Solicitation . . . . . . 4 4. Propagating the Address Registration Solicitation . . . . . . . 4
4.1. ND Address Registration Solicitation Option . . . . . . . 5 4.1. ND Address Registration Solicitation Option . . . . . . . . 5
4.2. DHCPv6 Address Registration Solicitation Option . . . . . 6 4.2. DHCPv6 Address Registration Solicitation Option . . . . . . 5
5. DHCPv6 Address Registration Procedure . . . . . . . . . . . . 7 5. DHCPv6 Addr-registration-request Message . . . . . . . . . . . 6
5.1. DHCPv6 Address Registration Request . . . . . . . . . . . 7 6. DHCPv6 Address Registration Procedure . . . . . . . . . . . . . 6
5.2. DHCPv6 Address Registration Acknowledge . . . . . . . . . 8 6.1. DHCPv6 Address Registration Request . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6.2. DHCPv6 Address Registration Acknowledge . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
In several common network scenarios, IPv6 addresses are self- In several common network scenarios, IPv6 addresses are self-
generated by the end-hosts using some information propogated to them generated by the end-hosts using some information propogated to them
by the network (i.e. the network prefix). Examples of self-generated by the network (i.e. the network prefix). Examples of self-generated
addresses include those created using IPv6 Stateless Address addresses include those created using IPv6 Stateless Address
Configuration [RFC4862] , temporary addresses [RFC4941] and Configuration [RFC4862] , temporary addresses [RFC4941] and
Cryptographically Generated Addresses (CGA) [RFC3972] etc. These Cryptographically Generated Addresses (CGA) [RFC3972] etc. These
addresses are potentially incompatible with networks with a centrally addresses are potentially incompatible with networks with a centrally
managed address architecture such as DHCPv6 [RFC3315] as they lack managed address architecture such as DHCPv6 [RFC3315] as they lack
traceability and stability. traceability and stability.
Many operators of enterprise networks and similarly tightly Many operators of enterprise networks and similarly tightly
administered networks have expressed the desire to be at least aware administered networks have expressed the desire to be at least aware
of the hosts' self-generated addresses when migrating to IPv6. of the hosts' self-generated addresses when migrating to IPv6.
One potential way to provide network administrators with most of One potential way to provide network administrators with most of
their needs while retaining compatibility with normal stateless their needs while retaining compatibility with normal stateless
configuration would be to register the self-generated addresses with configuration would be to register the self-generated addresses with
the systems in place to centrally administer the addresses. The host the systems in place to centrally administer the addresses. The edge
may be required to perform this registration in some scenarios since router that observes hosts' addresses through the Neighbor Discovery
only registered IPv6 addresses may be granted access to the network protocol is the most suitable devices to register these addresses.
resources .
This document introduces a new IPv6 Neighbor Discovery option and a This document introduces a new IPv6 Neighbor Discovery option and a
new DHCPv6 option to propagate the address registration information new DHCPv6 option to solicite edge routers to register addresses.
from the hosts to the network. The DHCPv6 protocol is used to The DHCPv6 protocol is used to perform the address registration
perform the address registration procedure while the address procedure while the address registration server role may be performed
registration server role may be performed by a DHCPv6 server or a by a DHCPv6 server or a stand-alone server, which is also considered
stand-alone server. 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 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Overview of Generic Address Registration Solution 3. Overview of Generic Address Registration Solution
In the generic address registration solution, the network management In the generic address registration solution, the network management
system solicits hosts to register their self-generated addresses, by system solicits the edge routers to register addresses, by sending
sending solicitation messages from either local router (step 1a in solicitation messages from either upstream router (step 1a in Figure
Figure 1) or DHCPv6 server (step 1b in Figure 1). 1) or DHCPv6 server (step 1b in Figure 1).
After receiving such solicitations, a host implementing this
specification and using a self-generated address SHOULD send an
address registration request message to the address registration
server (step 2 in Figure 1). 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 database, which MAY be used by other network
functions, such as DNS or ACL, etc. The address registration server
should also assign lifetimes for the requested address. An
acknowledgement is sent back to the host with the assigned lifetimes
(step 3 in Figure 1).
+--------+ +------------+ +---------------+ After receiving such solicitations, an edge router implementing this
| Host | |Local Router| |Addr-Reg Server| 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
|Addr Register Solicitation(1a)| | 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
| Addr Register Solicitation(1b) | functions, such as DNS or ACL, etc. An acknowledgement MAY be sent
|<------------------------------------------------| back to the edge router (step 3 in Figure 1).
| | +----+ +-----------+ +---------------+ +---------------+
|Send self-generation addr registration request(2)| |Host| |Edge router| |Upstream Router| |Addr-Reg Server|
|------------------------------------------------>| +----+ +-----------+ +---------------+ +---------------+
| |Register | ND | | |
| Reply acknowledgment with assigned lifetimes(3) |address |<--------->| | |
|<------------------------------------------------| | | |
|Addr Register Solicitation(1a) |
|<------------------| |
| |
| Addr Register Solicitation(1b) |
|<-------------------------------------|
| |
| Addr-registration-request(2) |
|------------------------------------->|
| |Register
| Acknowledgment addr registration(3) |address
|<-------------------------------------|
Figure 1: Address Registration Procedure Figure 1: Address Registration Procedure
By received the acknowledgement, the host can continue use the
registered address. It SHOULD use the assigned preferred and valid
lifetime for the correspondeding address.
4. Propagating the Address Registration Solicitation 4. Propagating the Address Registration Solicitation
In order to request the hosts with self-generated addresses to In order to notify the edge routers the availabilityof the address
register their addresses and the appointed address registration registration service, new solicitation options are needed. There is
server, new solicitation options are defined. more than one mechanism by which configuration parameters could be
pushed to the edge routers. The address registration solicitation
There is more than one mechanism by which configuration parameters option can be carried in Router Advertisement (RA) message, which is
could be pushed to the end hosts. The address registration broadcasted by upstream routers. In the DHCPv6 managed network, it
solicitation option can be carried in Router Advertisement (RA) can also be carried in DHCPv6 messages. This document defines a new
message, which is broadcasted by local routers. In the DHCPv6 ND option and a new DHCPv6 option for this purpose. Since the
managed network, it can also be carried in DHCPv6 messages. address registration process is through the standard DHCPv6 client/
server communication - send packets to ff02::1:2, the
This document defines a new ND option and one new DHCPv6 option that All_DHCP_Relay_Agents_and_Servers multicast address, these
convey a Fully Qualified Domain Name (FQDN, as per Section 3.1 of solicitation options do not contain the IP address of address
[RFC1035] to be used as the destination of the address registration registration server.
messages. In order to make use of these options, this document
assumes that appropriate name resolution mechanisms (see Section
6.1.1 of [RFC1123] are available on the host.
After receving a message containing an address registration After receving a message containing an address registration
solicitation option, a host implementing this specification SHOULD solicitation option, an edge router implementing this specification
register its self-generated addresses, if any, to the announced SHOULD register addresses to the address registration server.
address registration server. The solicitation options MAY include
the IPv6 address(es) of address registration server.
In principle, hosts need to 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 are expected to be propagated along with prefix
assignment information.
4.1. ND Address Registration Solicitation Option 4.1. ND Address Registration Solicitation Option
The ND Address Registration Solicitation Option allows routers to The ND Address Registration Solicitation Option allows an upstream
propagate the solicitation for hosts to register their self-generated router to propagate the solicitation for edge routers to register
address. This option also carries the fully qualified domain name of addresses. The format of the ND Address Registration Solicitation
the address registration server. This option SHOULD be propagated
together with the Prefix Information Option, Section 4.6.2,
[RFC4861]. The format of the ND Address Registration Solicitation
Option is described as follows: Option is described as follows:
0 1 2 3 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 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 | Pad Length | Reserved | | Type | Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| | | Reserved |
. Domain Name .
. (Address Registration Server) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Type TBA1
Type TBA1 Length 1 (in units of 8 octets, Type and Length themselves
are included).
Length The length of the option in units of 8 octets, Reserved Padding bits. For future use also. The value MUST
including the Type and Length fields. The value 0 be initialized to zero by the sender, and MUST be
is invalid. The receiver MUST discard a message ignored by the receiver.
that contains this value.
Pad Length The number of padding octets beyond the end of the ND Address Registration Solicitation Option
Domain Name field but within the length specified
by the Length field.
Reserved Padding bits. It is for future use also. The value 4.2. DHCPv6 Address Registration Solicitation Option
MUST be initialized to zero by the sender, and
MUST be ignored by the receiver.
Domain Name Fully qualified domain name of the announced The DHCPv6 Address Registration Solicitation Option allows a DHCPv6
address registration server. The domain name is server to propagate the solicitation for edge routers to register
encoded as specified in Section 8 of [RFC3315]. 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:
Padding A variable-length field making the option length a 0 1 2 3
multiple of 8, containing as many octets as 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
specified in the Pad Length field. Padding octets +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
MUST be set to zero by senders and ignored by | OPTION_ADDR_REG_SOLICITATION | option-len |
receivers. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_ADDR_REG_SOLICITATION (TBA2).
4.2. DHCPv6 Address Registration Solicitation Option option-len 0, Length of this option in octets (not including
option-code and option-len).
The DHCPv6 Address Registration Solicitation Option allows DHCPv6 DHCPv6 Addr Registration Solicitation Option
server to propagate the solicitation for hosts to register their
self-generated address. This option also carries a domain name of
the appointed 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 5. DHCPv6 Addr-registration-request Message
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Domain Name .
. (Address Registration Server) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_ADDR_REG_SOLICITATION (TBA2). 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]:
option-len Length of this option in octets (not including 0 1 2 3
option-code and option-len). 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).
Domain Name A fully qualified domain name of the appointed transaction-id The transaction ID for this message exchange.
address registration server. The domain name
is encoded as specified in Section 8 of
[RFC3315].
5. DHCPv6 Address Registration Procedure 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 The DHCPv6 protocol is reused as the address registration protocol
while a DHCPv6 server can play the role of an address registration while a DHCPv6 server can play the role of an address registration
server. The IA_NA DHCPv6 option [RFC3315] is reused in order to server. The IA_NA DHCPv6 option [RFC3315] is reused in order to
fulfill the address registration interactions. fulfill the address registration interactions.
5.1. DHCPv6 Address Registration Request 6.1. DHCPv6 Address Registration Request
The host with one or more self-generated addresses sends a DHCPv6
Request message to the address registration server received in the
address registration solicitation option.
The DHCPv6 Request message SHOULD contain at least one IA_NA option.
The IA_NA option SHOULD contain at least one IA Address option. The
host SHOULD set the T1 and T2 fields in any IA_NA options, and the
preferred-lifetime and valid-lifetime fields in the IA Address
options to 0.
After receiving this address registration request, the address
registration server MUST register the requested address in its
address database, which may further be used by other network
functions, such as DNS, network access control lists, etc. The
address registration server SHOULD also assign the lifetimes for
these registered addresses.
The centrally managed address database contains both self-generated The edge router sends a DHCPv6 Addr-registration-request message to
addresses and the DHCPv6 assigned addresses. They MAY be marked and the address registration server to ff02::1:2, the
treated differently in the database. All_DHCP_Relay_Agents_and_Servers multicast address.
5.2. DHCPv6 Address Registration Acknowledge 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.
The address registration server then sends a Reply message as the After receiving this Addr-Registration-Request message, the address
response to registration requests. The DHCPv6 Reply message SHOULD registration server MUST register the requested address(es) in its
contain at least one IA_NA option. The IA_NA option SHOULD contain address registration database, which may further be used by other
at least one IA Address option. The server SHOULD set the T1 and T2 network functions, such as DNS, network access control lists, etc.
fields in any IA_NA options, and the preferred-lifetime and valid- If the DHCPv6 server does not support address registration function,
lifetime fields in the IA Address options following the rules defined a Reply message with includes a Status Code option with the value the
in Section 22 of [RFC3315]. RegistrationNotSupported (TBA4) MAY be sent back to the initiated
client.
After receiving the acknowledgement from the server, the host can use 6.2. DHCPv6 Address Registration Acknowledge
the registered address to access the network. It SHOULD use the
values in the preferred and valid lifetime fields of the received
message to determine the preferred and valid lifetimes of the
address.
Please note that the host MAY continue to use expired address, such After all the addresses have been processed, the address registration
as Upper-Layer Identifiers (ULID) in Shim6 protocol [RFC5533], etc. server MAY send a Reply message as the response to registration
but the network could potentially refuse the network access from such requests. The server generates a Reply message and includes a Status
addresses. 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.
6. Security Considerations 7. Security Considerations
An attacker may use a faked address registration request option to An attacker may register large number of fake addresses with the
indicate hosts reports their address to a malicious server and network in order to overwhelm the address registration server. These
collect the user information. An attacker may also register large attacks may be prevented generic DHCPv6 protection by using the AUTH
number of fake addresses with the network in order to overwhelm the option [RFC3315] or Secure DHCPv6 [I-D.ietf-dhc-secure-dhcpv6].
address registration server. In either case, these attacks may be
prevented by using Secure Neighbor Discovery [RFC3971] if the RA
Address Registration Request Option is used, and the AUTH option
[RFC3315] or Secure DHCPv6 [I-D.ietf-dhc-secure-dhcpv6] if the DHCPv6
Address Registration Request Option is used.
7. IANA Considerations 8. IANA Considerations
This document defines a new IPv6 Neighbor Discovery option, the This document defines a new IPv6 Neighbor Discovery option, the
Address Registration Solicitation Option (TBA1) described in Section Address Registration Solicitation Option (TBA1) described in Section
4.1, that requires an allocation out of the registry defined at 4.1, that requires an allocation out of the registry defined at
http://www.iana.org/assignments/icmpv6-parameters http://www.iana.org/assignments/icmpv6-parameters
This document defines a new DHCPv6 option, the This document defines a new DHCPv6 option, the
OPTION_ADDR_REG_SOLICITATION (TBA2) described in Section 4.2, that OPTION_ADDR_REG_SOLICITATION (TBA2) described in Section 4.2, that
requires an allocation out of the registry defined at requires an allocation out of the registry defined at
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/ http://www.iana.org/assignments/dhcpv6-parameters/
8. Acknowledgements 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
The authors would like to thank Ralph Droms, Ted Lemon, Bernie Volz http://www.iana.org/assignments/dhcpv6-parameters/
and other members of dhc working group for their valuable comments.
9. References 9. Acknowledgements
9.1. Normative References 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.
[RFC1035] Mockapetris, P., "Domain names - implementation and 10. References
specification", STD 13, RFC 1035, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application 10.1. Normative References
and Support", STD 3, RFC 1123, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007. IPv6", RFC 4941, September 2007.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 10.2. Informative References
Shim Protocol for IPv6", RFC 5533, June 2009.
9.2. Informative References
[I-D.ietf-dhc-host-gen-id]
Jiang, S., Xia, F., and B. Sarikaya, "Prefix Assignment in
DHCPv6", draft-ietf-dhc-host-gen-id-04 (work in progress),
August 2012.
[I-D.ietf-dhc-secure-dhcpv6] [I-D.ietf-dhc-secure-dhcpv6]
Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs", Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs",
draft-ietf-dhc-secure-dhcpv6-07 (work in progress), draft-ietf-dhc-secure-dhcpv6-07 (work in progress),
September 2012. September 2012.
Authors' Addresses Authors' Addresses
Sheng Jiang Sheng Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
 End of changes. 50 change blocks. 
226 lines changed or deleted 196 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/