draft-ietf-dhc-addr-registration-02.txt   draft-ietf-dhc-addr-registration-03.txt 
DHC 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: August 29, 2013 China Mobile Expires: March 2, 2014 China Mobile
S. Krishnan S. Krishnan
Ericsson Ericsson
February 25, 2013 August 29, 2013
A Generic IPv6 Addresses Registration Solution Using DHCPv6 Registering self-generated IPv6 Addresses in DNS using DHCPv6
draft-ietf-dhc-addr-registration-02 draft-ietf-dhc-addr-registration-03
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 some traceability issues due to their decentralized nature.
minimize the issues due to lack of traceability, these self-generated One of the most important issues in this regard is the inability to
addresses can be registered with the network for allowing centralized register such addresses in DNS. This document defines a mechanism to
address administration. This document defines a generic address register self-generated addresses in DNS through a DHCPv6 server.
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 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 August 29, 2013. This Internet-Draft will expire on March 2, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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. Solution Overview . . . . . . . . . . . . . . . . . . . . . . . 3
4. Propagating the Address Registration Solicitation . . . . . . . 4 4. DHCPv6 ADDR-REGISTRATION-REQUEST Message . . . . . . . . . . . 4
4.1. ND Address Registration Solicitation Option . . . . . . . . 5 5. DHCPv6 Address Registration Procedure . . . . . . . . . . . . . 5
4.2. DHCPv6 Address Registration Solicitation Option . . . . . . 5 5.1. DHCPv6 Address Registration Request . . . . . . . . . . . . 5
5. DHCPv6 Addr-registration-request Message . . . . . . . . . . . 6 5.2. Acknowledging successful registration . . . . . . . . . . . 5
6. DHCPv6 Address Registration Procedure . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6.1. DHCPv6 Address Registration Request . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6.2. DHCPv6 Address Registration Acknowledge . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . . 8
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 by appending a self-generated interface
by the network (i.e. the network prefix). Examples of self-generated identifier to a network-specified 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. In
addresses are potentially incompatible with networks with a centrally several tighly controlled networks, hosts with self-generated
managed address architecture such as DHCPv6 [RFC3315] as they lack addresses may face some limitations. One such limitation is related
traceability and stability. to the inability of nodes with self-generated addresses to register
their IPv6-address-to-FQDN bindings in DNS. This is related to the
Many operators of enterprise networks and similarly tightly fact that, in such networks, only certain nodes (e.g. The DHCPv6
administered networks have expressed the desire to be at least aware server) are allowed to update these bindings in order to prevent end-
of the hosts' self-generated addresses when migrating to IPv6. hosts from registering arbitrary addresses for their FQDNs or
associating their addresses with arbitrary domain names.
One potential way to provide network administrators with most of For nodes that obtain their addresses through DHCPv6, a solution has
their needs while retaining compatibility with normal stateless been specified in [RFC4704]. The solution works by including a
configuration would be to register the self-generated addresses with Client FQDN option in the SOLICIT, REQUEST, RENEW or REBIND messages
the systems in place to centrally administer the addresses. The edge during the process of acquiring an address through DHCPv6. This
router that observes hosts' addresses through the Neighbor Discovery document provides an analogous mechanism to register self-generated
protocol is the most suitable devices to register these addresses. addresses in DNS.
This document introduces a new IPv6 Neighbor Discovery option and a A new ADDR-REGISTRATION-REQUEST DHCPv6 message type is defined to
new DHCPv6 option to solicite edge routers to register addresses. initiate the address registration request, and two new Status codes
The DHCPv6 protocol is used to perform the address registration is defined to indicate registration errors on the server side.
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 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. Solution Overview
In the generic address registration solution, the network management After successfully assigning a self-generated IPv6 address on one of
system solicits the edge routers to register addresses, by sending its interfaces, an end-host implementing this specification SHOULD
solicitation messages from either upstream router (step 1a in Figure send an ADDR-REGISTRATION-REQUEST message to a DHCPv6 address
1) or DHCPv6 server (step 1b in Figure 1). registration server. After receiving the address registration
request, the DHCPv6 server registers the IPv6 address to FQDN binding
towards a configured DNS server. An acknowledgement MAY be sent back
to the end host to indicate whether or not the registration operation
succeeded..
After receiving such solicitations, an edge router implementing this +----+ +-----------+ +---------------+
specification SHOULD send an Addr-registration-request message to the |Host| |Edge router| |Addr-Reg Server|
address registration server (step 2 in Figure 1, defined in Section 5 +----+ +-----------+ +---------------+
of this document). The address registration server may be acted by a | SLAAC | |
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) | | ADDR-REGISTRATION-REQUEST |
|------------------------------------->| |------------------------------------->|
| |Register | |Register
| Acknowledgment addr registration(3) |address | |address
| Optional Acknowledgment |in DNS
|<-------------------------------------| |<-------------------------------------|
Figure 1: Address Registration Procedure Figure 1: Address Registration Procedure
4. Propagating the Address Registration Solicitation 4. DHCPv6 ADDR-REGISTRATION-REQUEST Message
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
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
5. DHCPv6 Addr-registration-request Message
A DHCPv6 client (the edge router) sends an Addr-registration-request The DHCPv6 client sends an ADDR-REGISTRATION-REQUEST message to a
message to a server to request addresses to be registered. The server to request an address to be registered in the DNS. The format
format of the Addr-registration-request message is described as of the ADDR-REGISTRATION-REQUEST message is described as follows:
follows, compliant with Section 6 in [RFC3315]:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | transaction-id | | msg-type | transaction-id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. options . . options .
. (variable) . . (variable) .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type Identifies the DHCPv6 message type; (TBA3). msg-type Identifies the DHCPv6 message type;
Set to ADDR-REGISTRATION-REQUEST (TBA1).
transaction-id The transaction ID for this message exchange. transaction-id The transaction ID for this message exchange.
options Options carried in this message. options Options carried in this message.
DHCPv6 Addr-Registration-Request message DHCPv6 ADDR-REGISTRATION-REQUEST message
This Addr-registration-request message MUST NOT contain server- The ADDR-REGISTRATION-REQUEST message MUST NOT contain server-
identifier option and SHOULD only contain IA_NA option(s) and Client identifier option and MUST contain the IA_NA option and the DHCPv6
Identifier option. FQDN option [RFC4704].
Clients MUST discard any received Addr-registration-request messages. Clients MUST discard any received ADDR-REGISTRATION-REQUEST messages.
Servers MUST discard any Addr-Registration-Request messages that do Servers MUST discard any ADDR-REGISTRATION-REQUEST messages that do
not include a Client Identifier option or that do include a Server not include a Client Identifier option or that do include a Server
Identifier option. Identifier option.
6. DHCPv6 Address Registration Procedure 5. 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.
The edge router MUST include a Client Identifier option in the Addr- The DHCPv6 protocol is used as the address registration protocol when
registration-request message to identify itself to the server. The a DHCPv6 server performs the role of an address registration server.
DHCPv6 Addr-registration-request message SHOULD contain at least one The DHCPv6 IA_NA option [RFC3315] and the DHCPv6 FQDN option
IA_NA option. The IA_NA option SHOULD contain at least one IA [RFC4704] are reused in order to fulfill the address registration
Address option. interactions.
After receiving this Addr-Registration-Request message, the address 5.1. DHCPv6 Address Registration Request
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 The end-host sends a DHCPv6 ADDR-REGISTRATION-REQUEST message to the
address registration server to the All_DHCP_Relay_Agents_and_Servers
multicast address (ff02::1:2).
After all the addresses have been processed, the address registration The end-host MUST include a Client Identifier option in the ADDR-
server MAY send a Reply message as the response to registration REGISTRATION-REQUEST message to identify itself to the server. The
requests. The server generates a Reply message and includes a Status DHCPv6 ADDR-REGISTRATION-REQUEST message MUST contain exactly one
Code option with value Success, a Server Identifier option with the IA_NA option and exactly one FQDN option. The IA_NA option MUST
server's DUID, and a Client Identifier option with the client's DUID. contain at least one IA Address option.
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 After receiving this ADDR-REGISTRATION-REQUEST message, the address
registration server MUST register the binding between the provided
FQDN and address(es) in DNS. If the DHCPv6 server does not support
address registration function, a Reply message with includes a Status
Code option with the value the RegistrationNotSupported (TBA2) MAY be
sent back to the initiated client.
An attacker may register large number of fake addresses with the 5.2. Acknowledging successful registration
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 After all the addresses have been successfully registered in DNS, 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 not succeed in registering, 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
(TBA3) in the IA option. No other options are included in the IA
option.
This document defines a new IPv6 Neighbor Discovery option, the 6. Security Considerations
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 An attacker may attempt to register large number of addresses in
quick succession 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].
This document defines a new DHCPv6 option, the 7. IANA Considerations
OPTION_ADDR_REG_SOLICITATION (TBA2) described in Section 4.2, that
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- This document defines a new DHCPv6 message, the ADDR-REGISTRATION-
request message (TBA3) described in Section 5, that requires an REQUEST message (TBA1) described in Section 5, that requires an
allocation out of the registry defined at allocation out of the registry defined at
http://www.iana.org/assignments/dhcpv6-parameters/ http://www.iana.org/assignments/dhcpv6-parameters/
This document defines two new DHCPv6 Status code, the This document defines two new DHCPv6 Status code, the
RegistrationNotSupported (TBA4) and RegistrationDenied (TBA5) RegistrationNotSupported (TBA2) and RegistrationDenied (TBA3)
described in Section 6, that requires an allocation out of the described in Section 6, that requires an allocation out of the
registry defined at registry defined at
http://www.iana.org/assignments/dhcpv6-parameters/ http://www.iana.org/assignments/dhcpv6-parameters/
9. Acknowledgements 8. Acknowledgements
The authors would like to thank Ralph Droms, Ted Lemon, Bernie Volz, The authors would like to thank Ralph Droms, Ted Lemon, Bernie Volz,
Sten Carlsen, Erik Kline, Lorenzo Colitti, Joel Jaeggli, Sten Sten Carlsen, Erik Kline, Lorenzo Colitti, Joel Jaeggli, Sten
Carlsen, Mark Smith and other members of dhc and v6ops working groups Carlsen, Mark Smith and other members of dhc and v6ops working groups
for their valuable comments. for their valuable comments.
10. References 9. References
10.1. Normative References 9.1. Normative References
[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 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. 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.
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for
IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN)
Option", RFC 4704, October 2006.
[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.
10.2. Informative References 9.2. Informative References
[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. 39 change blocks. 
216 lines changed or deleted 121 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/