draft-ietf-dhc-addr-registration-00.txt   draft-ietf-dhc-addr-registration-01.txt 
Network Working Group S. Jiang
Internet Draft Huawei Technologies Co., Ltd
Intended status: Standards Track G. Chen
Expires: November 8, 2012 China Mobile
May 8, 2012
A Generic IPv6 Addresses Registration Solution 6man Working Group S. Jiang
Using DHCPv6 Internet-Draft Huawei Technologies Co., Ltd
draft-ietf-dhc-addr-registration-00.txt Intended status: Standards Track G. Chen
Expires: April 25, 2013 China Mobile
S. Krishnan
Ericsson
October 22, 2012
A Generic IPv6 Addresses Registration Solution Using DHCPv6
draft-ietf-dhc-addr-registration-01
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.
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 working Task Force (IETF). Note that other groups may also distribute
documents as Internet-Drafts. The list of current Internet-Drafts is working documents as Internet-Drafts. The list of current Internet-
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 November 8, 2012. This Internet-Draft will expire on April 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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.
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 one new DHCPv6 option
in order to propagate the solicitations of registering self-generated
addresses. The registration procedure reuses the existing IA_NA in
the DHCPv6 protocol.
Table of Contents Table of Contents
1. Introduction & Requirements .................................. 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 ......... 7 4.2. DHCPv6 Address Registration Solicitation Option . . . . . 6
5. DHCPv6 Address Registration Procedure ........................ 7 5. DHCPv6 Address Registration Procedure . . . . . . . . . . . . 7
5.1. DHCPv6 Address Registration Request ..................... 7 5.1. DHCPv6 Address Registration Request . . . . . . . . . . . 7
5.2. DHCPv6 Address Registration Acknowledge ................. 8 5.2. DHCPv6 Address Registration Acknowledge . . . . . . . . . 8
6. Security Considerations ...................................... 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations .......................................... 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgments .............................................. 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. References ................................................... 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References .................................... 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References ................................. 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Author's Addresses ............................................. 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction & Requirements 1. Introduction
In the IPv6 address allocation scenarios, there are many host self- In several common network scenarios, IPv6 addresses are self-
generated addresses, such as addresses in IPv6 Stateless Address generated by the end-hosts using some information propogated to them
Configuration [RFC4862, RFC4941] scenario and Cryptographically by the network (i.e. the network prefix). Examples of self-generated
Generated Addresses (CGA, [RFC3972]), and etc. These addresses are addresses include those created using IPv6 Stateless Address
notionally conflicted with the network managed address architecture, Configuration [RFC4862] , temporary addresses [RFC4941] and
such as Dynamic Host Configuration Protocol for IPv6 (DHCPv6, Cryptographically Generated Addresses (CGA) [RFC3972] etc. These
[RFC3315]) managed network or network with Access Control List. 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 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
the hosts' addresses when moving to IPv6. Furthermore, they may want of the hosts' self-generated addresses when migrating to IPv6.
to stop the usage of some hosts' addresses for various reasons.
A useful way to give network administrators most of what they want, One potential way to provide network administrators with most of
while at the same time retaining compatibility with normal stateless their needs while retaining compatibility with normal stateless
configuration would be: if the self-generated IPv6 addresses are configuration would be to register the self-generated addresses with
used, they may need to be registered in the networking management the systems in place to centrally administer the addresses. The host
plate. The host may be required to perform this registration since may be required to perform this registration in some scenarios since
only registered IPv6 addresses may access the network resources in only registered IPv6 addresses may be granted access to the network
some scenarios. resources .
In order to fulfill the abovementioned practice, this document This document introduces a new IPv6 Neighbor Discovery option and a
introduces a new Neighbor Discovery (ND) option and a new DHCPv6 new DHCPv6 option to propagate the address registration information
option to propagate the address registration solicitation from from the hosts to the network. The DHCPv6 protocol is used to
network management to hosts. DHCPv6 protocol is suitable to perform perform the address registration procedure while the address
the address registration procedure while the address registration registration server role may be performed by a DHCPv6 server or a
server may play by a DHCPv6 server or a stand-alone server. The stand-alone server.
existing IA_NA in the DHCPv6 protocol is reused for the registration
procedure.
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 [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Overview of Generic Address Registration Solution
By current default, the hosts with self-generated addresses do not 3. Overview of Generic Address Registration Solution
register their addresses to any network devices. However, this may
result that the network may reject the access request from these
devices if the address registration is requested.
As showed in below Figure 1, in the generic address registration In the generic address registration solution, the network management
solution, proposed by this document, the network management plate system solicits hosts to register their self-generated addresses, by
firstly propagates the solicitations of registering self-generated sending solicitation messages from either local router (step 1a in
addresses, by messages from either local router (step 1a in Figure 1) Figure 1) or DHCPv6 server (step 1b in Figure 1).
or DHCPv6 server (step 1b in Figure 1).
By received such solicitations, a host using the self-generated After receiving such solicitations, a host implementing this
address SHOULD send an address registration request message to the specification and using a self-generated address SHOULD send an
address registration server (step 2 in Figure 1). The address address registration request message to the address registration
registration server may be acted by a DHCPv6 server. By received the server (step 2 in Figure 1). The address registration server may be
address registration request, the address registration server records acted by a DHCPv6 server. By received the address registration
the requested address in the address database, which MAY be used by request, the address registration server records the requested
other network functions, such as DNS or ACL, etc. The address address in the address database, which MAY be used by other network
registration server should also assign lifetimes for the requested functions, such as DNS or ACL, etc. The address registration server
address. An acknowledgement is sent back to the host with the should also assign lifetimes for the requested address. An
assigned lifetimes (step 3 in Figure 1). acknowledgement is sent back to the host with the assigned lifetimes
(step 3 in Figure 1).
+--------+ +------------+ +---------------+ +--------+ +------------+ +---------------+
| Host | |Local Router| |Addr-Reg Server| | Host | |Local Router| |Addr-Reg Server|
+--------+ +------------+ +---------------+ +--------+ +------------+ +---------------+
| | | | | |
|Addr Register Solicitation(1a)| | |Addr Register Solicitation(1a)| |
|<-----------------------------| | |<-----------------------------| |
| | | |
| Addr Register Solicitation(1b) | | Addr Register Solicitation(1b) |
|<------------------------------------------------| |<------------------------------------------------|
| | | |
|Send self-generation addr registration request(2)| |Send self-generation addr registration request(2)|
|------------------------------------------------>| |------------------------------------------------>|
| |Register | |Register
| Reply acknowledgment with assigned lifetimes(3) |the addr | Reply acknowledgment with assigned lifetimes(3) |address
|<------------------------------------------------| |<------------------------------------------------|
Figure 1: address registration procedure Figure 1: Address Registration Procedure
By received the acknowledgement, the host can use the registered By received the acknowledgement, the host can continue use the
address. It SHOULD use the assigned preferred and valid lifetime for registered address. It SHOULD use the assigned preferred and valid
the corresponded address. lifetime for the correspondeding address.
4. Propagating the Address Registration Solicitation 4. Propagating the Address Registration Solicitation
In order to indicate or force the hosts with self-generated addresses In order to request the hosts with self-generated addresses to
to register their addresses and the appointed address registration register their addresses and the appointed address registration
server, new solicitation options need to be defined. server, new solicitation options are defined.
There are more than one mechanism in which configuration parameters There is more than one mechanism by which configuration parameters
could be pushed to the end hosts. The address registration could be pushed to the end hosts. The address registration
solicitation option can be carried in Router Advertisement (RA) solicitation option can be carried in Router Advertisement (RA)
message, which is broadcasted by local routers. In the DHCPv6 managed message, which is broadcasted by local routers. In the DHCPv6
network, it can also be carried in DHCPv6 messages. managed network, it can also be carried in DHCPv6 messages.
More precisely it defines one new ND option and one new DHCPv6 option This document defines a new ND option and one new DHCPv6 option that
that convey a Fully Qualified Domain Name (FQDN, as per Section 3.1 convey a Fully Qualified Domain Name (FQDN, as per Section 3.1 of
of [RFC1035]) of address registration(s). In order to make use of [RFC1035] to be used as the destination of the address registration
these options, this document assumes appropriate name resolution messages. In order to make use of these options, this document
means (see Section 6.1.1 of [RFC1123]) are available on the host assumes that appropriate name resolution mechanisms (see Section
client. The use of the FQDN may benefit for load-balancing purposes. 6.1.1 of [RFC1123] are available on the host.
By receiving the address registration solicitation option(s), a host After receving a message containing an address registration
SHOULD register its self-generated addresses, if there are any, to solicitation option, a host implementing this specification SHOULD
the appointed registration server. The solicitation options may register its self-generated addresses, if any, to the announced
include the IPv6 address(es) of address registration server. address 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 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 [RFC4861] or DHCPv6 message [I-D.ietf-dhc-host-gen-id] so that they
can generate an IPv6 address by themselves. The Address Registration can generate an IPv6 address by themselves. The Address Registration
Solicitation options could be propagated together with prefix Solicitation options are expected to be propagated along with prefix
assignment information. 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 routers to
propagate the solicitation for hosts to register their self-generated propagate the solicitation for hosts to register their self-generated
address. This option also carries a domain name of the appointed address. This option also carries the fully qualified domain name of
address registration server. This option SHOULD be propagated the address registration server. This option SHOULD be propagated
together with ND Prefix Information Option, Section 4.6.2, [RFC4861]. together with the Prefix Information Option, Section 4.6.2,
That is also applied to the case of Neighbor Discovery Proxies [RFC4861]. The format of the ND Address Registration Solicitation
[RFC4389]. 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 | Pad Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Domain Name . . Domain Name .
. (Address Registration Server) . . (Address Registration Server) .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Padding . . Padding .
. . . .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields: Fields:
Type (TBA1) Type TBA1
Length The length of the option in units of 8 octets, Length The length of the option in units of 8 octets,
including the Type and Length fields. The value 0 including the Type and Length fields. The value 0
is invalid. The receiver MUST discard a message is invalid. The receiver MUST discard a message
that contains this value. that contains this value.
Pad Length The number of padding octets beyond the end of the Pad Length The number of padding octets beyond the end of the
Domain Name field but within the length specified Domain Name field but within the length specified
by the Length field. by the Length field.
Reserved Padding bits. It is for future use also. The value Reserved Padding bits. It is for future use also. The value
MUST be initialized to zero by the sender, and MUST MUST be initialized to zero by the sender, and
be ignored by the receiver. MUST be ignored by the receiver.
Domain Name A fully qualified domain name of the appointed Domain Name Fully qualified domain name of the announced
address registration server. The domain name is address registration server. The domain name is
encoded as specified in Section 8 of [RFC3315]. Any encoded as specified in Section 8 of [RFC3315].
possible future updates to Section 8 of the Section
8 of [RFC3315] also apply to this option.
Padding: A variable-length field making the option length a Padding A variable-length field making the option length a
multiple of 8, containing as many octets as multiple of 8, containing as many octets as
specified in the Pad Length field. Padding octets specified in the Pad Length field. Padding octets
MUST be set to zero by senders and ignored by MUST be set to zero by senders and ignored by
receivers. receivers.
4.2. DHCPv6 Address Registration Solicitation Option 4.2. DHCPv6 Address Registration Solicitation Option
The DHCPv6 Address Registration Solicitation Option allows DHCPv6 The DHCPv6 Address Registration Solicitation Option allows DHCPv6
server to propagate the solicitation for hosts to register their server to propagate the solicitation for hosts to register their
self-generated address. This option also carries a domain name of the self-generated address. This option also carries a domain name of
appointed address registration server. This option SHOULD be the appointed address registration server. This option SHOULD be
propagated together with DHCPv6 Prefix Information Option, Section 5, propagated together with DHCPv6 Prefix Information Option, Section 5,
[I-D.ietf-dhc-host-gen-id]. The format of the DHCPv6 Address [I-D.ietf-dhc-host-gen-id]. The format of the DHCPv6 Address
Registration Solicitation Option is described as follows: Registration Solicitation 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_Addr_Reg_Solicitation | option-len | | OPTION_ADDR_REG_SOLICITATION | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
. Domain Name . . Domain Name .
. (Address Registration Server) . . (Address Registration Server) .
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_Addr_Reg_Solicitation (TBA2). option-code OPTION_ADDR_REG_SOLICITATION (TBA2).
option-len Length of this option in octets (option-code and option-len Length of this option in octets (not including
option-len are not included). option-code and option-len).
Domain Name A fully qualified domain name of the appointed Domain Name A fully qualified domain name of the appointed
address registration server. The domain name is address registration server. The domain name
encoded as specified in Section 8 of [RFC3315]. Any is encoded as specified in Section 8 of
possible future updates to Section 8 of the Section [RFC3315].
8 of [RFC3315] also apply to this option.
5. DHCPv6 Address Registration Procedure 5. DHCPv6 Address Registration Procedure
The current DHCPv6 protocol is reused as the address registration The DHCPv6 protocol is reused as the address registration protocol
protocol while a DHCPv6 serve plays as address registration server. while a DHCPv6 server can play the role of an address registration
Identity Association for Non-temporary Addresses (IA_NA) [RFC3315] is server. The IA_NA DHCPv6 option [RFC3315] is reused in order to
reused in order to fulfill the address registration interactions. fulfill the address registration interactions.
5.1. DHCPv6 Address Registration Request 5.1. DHCPv6 Address Registration Request
The host with self-generated address(es) sends a DHCPv6 Request The host with one or more self-generated addresses sends a DHCPv6
message to the appointed address registration server, which may be a Request message to the address registration server received in the
DHCPv6 server. address registration solicitation option.
The DHCPv6 Request message SHOULD contain at least one IA_NA 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 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 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 preferred-lifetime and valid-lifetime fields in the IA Address
options to 0. options to 0.
By received, the address registration server MUST register the After receiving this address registration request, the address
requested address in its address database, which MAY be used by other registration server MUST register the requested address in its
network functions, such as DNS or ACL, etc. The address registration address database, which may further be used by other network
server SHOULD also assign the lifetimes for these registered functions, such as DNS, network access control lists, etc. The
addresses. address registration server SHOULD also assign the lifetimes for
these registered addresses.
The address database contains both the self-generated addresses and
the DHCPv6 assigned addresses. They MAY be marked different in the
database.
5.2. DHCPv6 Address Registration Acknowledge The centrally managed address database contains both self-generated
addresses and the DHCPv6 assigned addresses. They MAY be marked and
treated differently in the database.
The address registration server sends a Reply message as the response 5.2. DHCPv6 Address Registration Acknowledge
to registration requests.
The DHCPv6 Reply message SHOULD contain at least one IA_NA option. The address registration server then sends a Reply message as the
The IA_NA option SHOULD contain at least one IA Address option. The response to registration requests. The DHCPv6 Reply message SHOULD
server SHOULD set the T1 and T2 fields in any IA_NA options, and the contain at least one IA_NA option. The IA_NA option SHOULD contain
preferred-lifetime and valid-lifetime fields in the IA Address at least one IA Address option. The server SHOULD set the T1 and T2
options following the rules defined in Section 22 in [RFC3315]. fields in any IA_NA options, and the preferred-lifetime and valid-
lifetime fields in the IA Address options following the rules defined
in Section 22 of [RFC3315].
By received the acknowledgement from the server, the host can use the After receiving the acknowledgement from the server, the host can use
registered address to access the network. It SHOULD use the values in the registered address to access the network. It SHOULD use the
the preferred and valid lifetime fields for the preferred and valid values in the preferred and valid lifetime fields of the received
lifetimes of the address. message to determine the preferred and valid lifetimes of the
address.
Note: the host MAY continue to use expired address, such as Locators Please note that the host MAY continue to use expired address, such
as Upper-Layer Identifiers (ULID) in Shim6 protocol [RFC5533], etc.; as Upper-Layer Identifiers (ULID) in Shim6 protocol [RFC5533], etc.
but the network MAY refuse the network access from such addresses. but the network could potentially refuse the network access from such
addresses.
6. Security Considerations 6. Security Considerations
An attacker may use a faked address registration request option to An attacker may use a faked address registration request option to
indicate hosts reports their address to a malicious server and indicate hosts reports their address to a malicious server and
collect the user information. Or, an attacker may register a faked collect the user information. An attacker may also register large
address to spoof the networking management plate. In either cases, number of fake addresses with the network in order to overwhelm the
these attacks may be prevented by using Secure Neighbor Discovery address registration server. In either case, these attacks may be
(SEND, [RFC3971]) if RA Address Registration Request Option is used, prevented by using Secure Neighbor Discovery [RFC3971] if the RA
or AUTH option [RFC3315] or Secure DHCPv6 Address Registration Request Option is used, and the AUTH option
[I-D.ietf-dhc-secure-dhcpv6] if DHCPv6 Address Registration Request [RFC3315] or Secure DHCPv6 [I-D.ietf-dhc-secure-dhcpv6] if the DHCPv6
Option is used. Address Registration Request Option is used.
7. IANA Considerations 7. IANA Considerations
This document defines a new Neighbor Discovery [RFC4861] option, This document defines a new IPv6 Neighbor Discovery option, the
which MUST be assigned Option Type values within the option numbering Address Registration Solicitation Option (TBA1) described in Section
space for Neighbor Discovery Option Type: 4.1, that requires an allocation out of the registry defined at
The Address Registration Solicitation Option (TBA1), described in http://www.iana.org/assignments/icmpv6-parameters
Section 4.1.
This document defines one new DHCPv6 [RFC3315] option, which MUST be This document defines a new DHCPv6 option, the
assigned Option Type values within the option numbering space for OPTION_ADDR_REG_SOLICITATION (TBA2) described in Section 4.2, that
DHCPv6 options: requires an allocation out of the registry defined at
The OPTION_Addr_Reg_Solicitation (TBA2), described in http://www.iana.org/assignments/dhcpv6-parameters/
Section 4.2;
8. Acknowledgments 8. Acknowledgements
The authors would like to thank Ralph Dorm, Ted Lemon, Bernie Volz The authors would like to thank Ralph Droms, Ted Lemon, Bernie Volz
and other member of DHC WG for valuable comments. and other members of dhc working group for their valuable comments.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins and [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
M. Carne, "Dynamic Host Configure Protocol for IPv6", and M. Carney, "Dynamic Host Configuration Protocol for
RFC3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3971] J. Arkko, J. Kempf, B. Zill, 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] T. Aura, "Cryptographically Generated Address", RFC3972, [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
March 2005. RFC 3972, March 2005.
[RFC4861] T. Narten, E. Nordmark, W. Simpson, and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC4862] S. Thomson, T. Narten and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC4941] T. Narten, R. Draves and S. Krishnan, "Privacy Extensions [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
for Stateless Address Autoconfiguration in IPv6", RFC 4941, Extensions for Stateless Address Autoconfiguration in
September 2007. IPv6", RFC 4941, September 2007.
[RFC5533] E. Nordmark, and M. Bagnulo, "Shim6: Level 3 Multihoming [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009. Shim Protocol for IPv6", RFC 5533, June 2009.
9.2. Informative References 9.2. Informative References
[RFC4389] D. Thaler, M. Talwar, and C. Patel, "Neighbor Discovery [I-D.ietf-dhc-host-gen-id]
Proxies (ND Proxy)", RFC4389, April 2006. 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]
S. Jiang and S. Shen, "Secure DHCPv6 Using CGAs", draft- Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs",
ietf-dhc-secure-dhcpv6 (work in progress), December, 2011. draft-ietf-dhc-secure-dhcpv6-07 (work in progress),
September 2012.
[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),
November, 2011.
Author's Addresses Authors' Addresses
Sheng Jiang Sheng Jiang
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
Q14, Huawei Campus Q14, Huawei Campus
No.156 Beiqing Road No.156 Beiqing Road
Hai-Dian District, Beijing 100095 Hai-Dian District, Beijing 100095
P.R. China
Email: jiangsheng@huawei.com Email: jiangsheng@huawei.com
Gang Chen Gang Chen
China Mobile China Mobile
53A, Xibianmennei Ave., Xuanwu District, Beijing 53A, Xibianmennei Ave., Xuanwu District, Beijing
P.R. China P.R. China
Phone: 86-13910710674 Phone: 86-13910710674
Email: phdgang@gmail.com 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
 End of changes. 85 change blocks. 
274 lines changed or deleted 267 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/