A Generic IPv6 Addresses Registration Solution Using DHCPv6
draft-ietf-dhc-addr-registration-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Sheng Jiang , Gang Chen | ||
| Last updated | 2012-05-07 | ||
| Replaces | draft-jiang-dhc-addr-registration | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-dhc-addr-registration-00
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
Using DHCPv6
draft-ietf-dhc-addr-registration-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute working
documents as Internet-Drafts. The list of current Internet-Drafts is
at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 8, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Jiang & Chen Expires November 8, 2012 [Page 1]
Internet-Draft draft-ietf-dhc-addr-registration-00 May 2012
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
1. Introduction & Requirements .................................. 3
2. Terminology .................................................. 3
3. Overview of Generic Address Registration Solution ............ 3
4. Propagating the Address Registration Solicitation ............ 4
4.1. ND Address Registration Solicitation Option ............. 5
4.2. DHCPv6 Address Registration Solicitation Option ......... 7
5. DHCPv6 Address Registration Procedure ........................ 7
5.1. DHCPv6 Address Registration Request ..................... 7
5.2. DHCPv6 Address Registration Acknowledge ................. 8
6. Security Considerations ...................................... 8
7. IANA Considerations .......................................... 9
8. Acknowledgments .............................................. 9
9. References ................................................... 9
9.1. Normative References .................................... 9
9.2. Informative References ................................. 10
Author's Addresses ............................................. 10
Jiang & Chen Expires November 8, 2012 [Page 2]
Internet-Draft draft-ietf-dhc-addr-registration-00 May 2012
1. Introduction & Requirements
In the IPv6 address allocation scenarios, there are many host self-
generated addresses, such as addresses in IPv6 Stateless Address
Configuration [RFC4862, RFC4941] scenario and Cryptographically
Generated Addresses (CGA, [RFC3972]), and etc. These addresses are
notionally conflicted with the network managed address architecture,
such as Dynamic Host Configuration Protocol for IPv6 (DHCPv6,
[RFC3315]) managed network or network with Access Control List.
Many operators of enterprise networks and similarly tightly
administered networks have expressed the desire to be at least aware
the hosts' addresses when moving to IPv6. Furthermore, they may want
to stop the usage of some hosts' addresses for various reasons.
A useful way to give network administrators most of what they want,
while at the same time retaining compatibility with normal stateless
configuration would be: if the self-generated IPv6 addresses are
used, they may need to be registered in the networking management
plate. The host may be required to perform this registration since
only registered IPv6 addresses may access the network resources in
some scenarios.
In order to fulfill the abovementioned practice, this document
introduces a new Neighbor Discovery (ND) option and a new DHCPv6
option to propagate the address registration solicitation from
network management to hosts. DHCPv6 protocol is suitable to perform
the address registration procedure while the address registration
server may play by a DHCPv6 server or a stand-alone server. The
existing IA_NA in the DHCPv6 protocol is reused for the registration
procedure.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119].
3. Overview of Generic Address Registration Solution
By current default, the hosts with self-generated addresses do not
register their addresses to any network devices. However, this may
result that the network may reject the access request from these
devices if the address registration is requested.
Jiang & Chen Expires November 8, 2012 [Page 3]
Internet-Draft draft-ietf-dhc-addr-registration-00 May 2012
As showed in below Figure 1, in the generic address registration
solution, proposed by this document, the network management plate
firstly propagates the solicitations of registering self-generated
addresses, by messages from either local router (step 1a in Figure 1)
or DHCPv6 server (step 1b in Figure 1).
By received such solicitations, a host using the self-generated
address SHOULD send an address registration request message to the
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).
+--------+ +------------+ +---------------+
| Host | |Local Router| |Addr-Reg Server|
+--------+ +------------+ +---------------+
| | |
|Addr Register Solicitation(1a)| |
|<-----------------------------| |
| |
| Addr Register Solicitation(1b) |
|<------------------------------------------------|
| |
|Send self-generation addr registration request(2)|
|------------------------------------------------>|
| |Register
| Reply acknowledgment with assigned lifetimes(3) |the addr
|<------------------------------------------------|
Figure 1: address registration procedure
By received the acknowledgement, the host can use the registered
address. It SHOULD use the assigned preferred and valid lifetime for
the corresponded address.
4. Propagating the Address Registration Solicitation
In order to indicate or force the hosts with self-generated addresses
to register their addresses and the appointed address registration
server, new solicitation options need to be defined.
There are more than one mechanism in which configuration parameters
could be pushed to the end hosts. The address registration
Jiang & Chen Expires November 8, 2012 [Page 4]
Internet-Draft draft-ietf-dhc-addr-registration-00 May 2012
solicitation option can be carried in Router Advertisement (RA)
message, which is broadcasted by local routers. In the DHCPv6 managed
network, it can also be carried in DHCPv6 messages.
More precisely it defines one new ND option and one new DHCPv6 option
that convey a Fully Qualified Domain Name (FQDN, as per Section 3.1
of [RFC1035]) of address registration(s). In order to make use of
these options, this document assumes appropriate name resolution
means (see Section 6.1.1 of [RFC1123]) are available on the host
client. The use of the FQDN may benefit for load-balancing purposes.
By receiving the address registration solicitation option(s), a host
SHOULD register its self-generated addresses, if there are any, to
the appointed registration server. The solicitation options may
include the IPv6 address(es) of address registration server.
In principle, hosts must receive a prefix from either RA message
[RFC4861] or DHCPv6 message [I-D.ietf-dhc-host-gen-id] so that they
can generate an IPv6 address by themselves. The Address Registration
Solicitation options could be propagated together with prefix
assignment information.
4.1. ND Address Registration Solicitation Option
The ND Address Registration Solicitation Option allows routers to
propagate the solicitation for hosts to register their self-generated
address. This option also carries a domain name of the appointed
address registration server. This option SHOULD be propagated
together with ND Prefix Information Option, Section 4.6.2, [RFC4861].
That is also applied to the case of Neighbor Discovery Proxies
[RFC4389]. The format of the ND Address Registration Solicitation
Option is described as follows:
Jiang & Chen Expires November 8, 2012 [Page 5]
Internet-Draft draft-ietf-dhc-addr-registration-00 May 2012
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 | Pad Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Domain Name .
. (Address Registration Server) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Padding .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type (TBA1)
Length The length of the option in units of 8 octets,
including the Type and Length fields. The value 0
is invalid. The receiver MUST discard a message
that contains this value.
Pad Length The number of padding octets beyond the end of the
Domain Name field but within the length specified
by the Length field.
Reserved Padding bits. It is for future use also. The value
MUST be initialized to zero by the sender, and MUST
be ignored by the receiver.
Domain Name A fully qualified domain name of the appointed
address registration server. The domain name is
encoded as specified in Section 8 of [RFC3315]. Any
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
multiple of 8, containing as many octets as
specified in the Pad Length field. Padding octets
MUST be set to zero by senders and ignored by
receivers.
Jiang & Chen Expires November 8, 2012 [Page 6]
Internet-Draft draft-ietf-dhc-addr-registration-00 May 2012
4.2. DHCPv6 Address Registration Solicitation Option
The DHCPv6 Address Registration Solicitation Option allows DHCPv6
server to propagate the solicitation for hosts to register their
self-generated address. 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
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).
option-len Length of this option in octets (option-code and
option-len are not included).
Domain Name A fully qualified domain name of the appointed
address registration server. The domain name is
encoded as specified in Section 8 of [RFC3315]. Any
possible future updates to Section 8 of the Section
8 of [RFC3315] also apply to this option.
5. DHCPv6 Address Registration Procedure
The current DHCPv6 protocol is reused as the address registration
protocol while a DHCPv6 serve plays as address registration server.
Identity Association for Non-temporary Addresses (IA_NA) [RFC3315] is
reused in order to fulfill the address registration interactions.
5.1. DHCPv6 Address Registration Request
The host with self-generated address(es) sends a DHCPv6 Request
message to the appointed address registration server, which may be a
DHCPv6 server.
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
Jiang & Chen Expires November 8, 2012 [Page 7]
Internet-Draft draft-ietf-dhc-addr-registration-00 May 2012
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.
By received, the address registration server MUST register the
requested address in its address database, which MAY be used by other
network functions, such as DNS or ACL, etc. The 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 address registration server sends a Reply message as the response
to registration requests.
The DHCPv6 Reply message SHOULD contain at least one IA_NA option.
The IA_NA option SHOULD contain at least one IA Address option. The
server 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 following the rules defined in Section 22 in [RFC3315].
By received the acknowledgement from the server, the host can use the
registered address to access the network. It SHOULD use the values in
the preferred and valid lifetime fields for the preferred and valid
lifetimes of the address.
Note: the host MAY continue to use expired address, such as Locators
as Upper-Layer Identifiers (ULID) in Shim6 protocol [RFC5533], etc.;
but the network MAY refuse the network access from such addresses.
6. Security Considerations
An attacker may use a faked address registration request option to
indicate hosts reports their address to a malicious server and
collect the user information. Or, an attacker may register a faked
address to spoof the networking management plate. In either cases,
these attacks may be prevented by using Secure Neighbor Discovery
(SEND, [RFC3971]) if RA Address Registration Request Option is used,
or AUTH option [RFC3315] or Secure DHCPv6
[I-D.ietf-dhc-secure-dhcpv6] if DHCPv6 Address Registration Request
Option is used.
Jiang & Chen Expires November 8, 2012 [Page 8]
Internet-Draft draft-ietf-dhc-addr-registration-00 May 2012
7. IANA Considerations
This document defines a new Neighbor Discovery [RFC4861] option,
which MUST be assigned Option Type values within the option numbering
space for Neighbor Discovery Option Type:
The Address Registration Solicitation Option (TBA1), described in
Section 4.1.
This document defines one new DHCPv6 [RFC3315] option, which MUST be
assigned Option Type values within the option numbering space for
DHCPv6 options:
The OPTION_Addr_Reg_Solicitation (TBA2), described in
Section 4.2;
8. Acknowledgments
The authors would like to thank Ralph Dorm, Ted Lemon, Bernie Volz
and other member of DHC WG for valuable comments.
9. References
9.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC2119, March 1997.
[RFC3315] R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins and
M. Carne, "Dynamic Host Configure Protocol for IPv6",
RFC3315, July 2003.
[RFC3971] J. Arkko, J. Kempf, B. Zill, and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] T. Aura, "Cryptographically Generated Address", RFC3972,
March 2005.
[RFC4861] T. Narten, E. Nordmark, W. Simpson, and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
Jiang & Chen Expires November 8, 2012 [Page 9]
Internet-Draft draft-ietf-dhc-addr-registration-00 May 2012
[RFC4862] S. Thomson, T. Narten and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC4862, September 2007.
[RFC4941] T. Narten, R. Draves and S. Krishnan, "Privacy Extensions
for Stateless Address Autoconfiguration in IPv6", RFC 4941,
September 2007.
[RFC5533] E. Nordmark, and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009.
9.2. Informative References
[RFC4389] D. Thaler, M. Talwar, and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC4389, April 2006.
[I-D.ietf-dhc-secure-dhcpv6]
S. Jiang and S. Shen, "Secure DHCPv6 Using CGAs", draft-
ietf-dhc-secure-dhcpv6 (work in progress), December, 2011.
[I-D.ietf-dhc-host-gen-id]
S. Jiang, F. Xia, and B. Sarikaya, "Prefix Assignment in
DHCPv6", draft-ietf-dhc-host-gen-id (work in progress),
November, 2011.
Author's Addresses
Sheng Jiang
Huawei Technologies Co., Ltd
Q14, Huawei Campus
No.156 Beiqing Road
Hai-Dian District, Beijing 100095
Email: jiangsheng@huawei.com
Gang Chen
China Mobile
53A, Xibianmennei Ave., Xuanwu District, Beijing
P.R. China
Phone: 86-13910710674
Email: phdgang@gmail.com
Jiang & Chen Expires November 8, 2012 [Page 10]