A Generic IPv6 Addresses Registration Solution Using DHCPv6
draft-ietf-dhc-addr-registration-01
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 , Suresh Krishnan | ||
| Last updated | 2012-10-22 | ||
| 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-01
6man Working Group S. Jiang
Internet-Draft Huawei Technologies Co., Ltd
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
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 April 25, 2013.
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
Jiang, et al. Expires April 25, 2013 [Page 1]
Internet-Draft IPv6 Address Registration October 2012
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Generic Address Registration Solution . . . . . . 3
4. Propagating the Address Registration Solicitation . . . . . . 4
4.1. ND Address Registration Solicitation Option . . . . . . . 5
4.2. DHCPv6 Address Registration Solicitation Option . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Jiang, et al. Expires April 25, 2013 [Page 2]
Internet-Draft IPv6 Address Registration October 2012
1. Introduction
In several common network scenarios, IPv6 addresses are self-
generated by the end-hosts using some information propogated to them
by the network (i.e. the network prefix). Examples of self-generated
addresses include those created using IPv6 Stateless Address
Configuration [RFC4862] , temporary addresses [RFC4941] and
Cryptographically Generated Addresses (CGA) [RFC3972] etc. These
addresses are potentially incompatible with networks with a centrally
managed address architecture such as DHCPv6 [RFC3315] as they lack
traceability and stability.
Many operators of enterprise networks and similarly tightly
administered networks have expressed the desire to be at least aware
of the hosts' self-generated addresses when migrating to IPv6.
One potential way to provide network administrators with most of
their needs while retaining compatibility with normal stateless
configuration would be to register the self-generated addresses with
the systems in place to centrally administer the addresses. The host
may be required to perform this registration in some scenarios since
only registered IPv6 addresses may be granted access to the network
resources .
This document introduces a new IPv6 Neighbor Discovery option and a
new DHCPv6 option to propagate the address registration information
from the hosts to the network. The DHCPv6 protocol is used to
perform the address registration procedure while the address
registration server role may be performed by a DHCPv6 server or a
stand-alone server.
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].
3. Overview of Generic Address Registration Solution
In the generic address registration solution, the network management
system solicits hosts to register their self-generated addresses, by
sending solicitation messages from either local router (step 1a in
Figure 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
Jiang, et al. Expires April 25, 2013 [Page 3]
Internet-Draft IPv6 Address Registration October 2012
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) |address
|<------------------------------------------------|
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
In order to request the hosts with self-generated addresses to
register their addresses and the appointed address registration
server, new solicitation options are defined.
There is more than one mechanism by which configuration parameters
could be pushed to the end hosts. The address registration
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.
This document defines a new ND option and one new DHCPv6 option that
convey a Fully Qualified Domain Name (FQDN, as per Section 3.1 of
[RFC1035] to be used as the destination of the address registration
Jiang, et al. Expires April 25, 2013 [Page 4]
Internet-Draft IPv6 Address Registration October 2012
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
solicitation option, a host implementing this specification SHOULD
register its self-generated addresses, if any, to the announced
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
The ND Address Registration Solicitation Option allows routers to
propagate the solicitation for hosts to register their self-generated
address. This option also carries the fully qualified domain name of
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:
Jiang, et al. Expires April 25, 2013 [Page 5]
Internet-Draft IPv6 Address Registration October 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 Fully qualified domain name of the announced
address registration server. The domain name is
encoded as specified in Section 8 of [RFC3315].
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.
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
Jiang, et al. Expires April 25, 2013 [Page 6]
Internet-Draft IPv6 Address Registration October 2012
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 (not including
option-code and option-len).
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].
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.
5.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
Jiang, et al. Expires April 25, 2013 [Page 7]
Internet-Draft IPv6 Address Registration October 2012
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
addresses and the DHCPv6 assigned addresses. They MAY be marked and
treated differently in the database.
5.2. DHCPv6 Address Registration Acknowledge
The address registration server then 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 of [RFC3315].
After receiving 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 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
as Upper-Layer Identifiers (ULID) in Shim6 protocol [RFC5533], etc.
but the network could potentially 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. An attacker may also register large
number of fake addresses with the network in order to overwhelm the
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
This document defines a new IPv6 Neighbor Discovery option, the
Address Registration Solicitation Option (TBA1) described in Section
Jiang, et al. Expires April 25, 2013 [Page 8]
Internet-Draft IPv6 Address Registration October 2012
4.1, that requires an allocation out of the registry defined at
http://www.iana.org/assignments/icmpv6-parameters
This document defines a new DHCPv6 option, the
OPTION_ADDR_REG_SOLICITATION (TBA2) described in Section 4.2, that
requires an allocation out of the registry defined at
http://www.iana.org/assignments/dhcpv6-parameters/
8. Acknowledgements
The authors would like to thank Ralph Droms, Ted Lemon, Bernie Volz
and other members of dhc working group for their 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] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
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
Address Autoconfiguration", RFC 4862, September 2007.
Jiang, et al. Expires April 25, 2013 [Page 9]
Internet-Draft IPv6 Address Registration October 2012
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
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]
Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs",
draft-ietf-dhc-secure-dhcpv6-07 (work in progress),
September 2012.
Authors' Addresses
Sheng Jiang
Huawei Technologies Co., Ltd
Q14, Huawei Campus
No.156 Beiqing Road
Hai-Dian District, Beijing 100095
P.R. China
Email: jiangsheng@huawei.com
Gang Chen
China Mobile
53A, Xibianmennei Ave., Xuanwu District, Beijing
P.R. China
Phone: 86-13910710674
Email: phdgang@gmail.com
Jiang, et al. Expires April 25, 2013 [Page 10]
Internet-Draft IPv6 Address Registration October 2012
Suresh Krishnan
Ericsson
8400 Decarie Blvd.
Town of Mount Royal, QC
Canada
Phone: +1 514 345 7900 x42871
Email: suresh.krishnan@ericsson.com
Jiang, et al. Expires April 25, 2013 [Page 11]