draft-ietf-dhc-host-gen-id-02.txt   draft-ietf-dhc-host-gen-id-03.txt 
Network Working Group S. Jiang Network Working Group S. Jiang
Internet-Draft F. Xia Internet-Draft F. Xia
Intended status: Standards Track B. Sarikaya Intended status: Standards Track B. Sarikaya
Expires: November 24, 2012 Huawei Technologies Expires: February 22, 2013 Huawei Technologies
May 23, 2012 August 21, 2012
Prefix Assignment in DHCPv6 Prefix Assignment in DHCPv6
draft-ietf-dhc-host-gen-id-02 draft-ietf-dhc-host-gen-id-03
Abstract Abstract
This document introduce a procedure for configuring hosts' IPv6 This document introduces a generic prefix announcement mechanism
address which the prefix is assigned from a DHCPv6 server through using DHCPv6. In this new address configuration procedure, the
DHCPv6 protocol while the interface identifiers are independently prefix is propagated from a DHCPv6 server to hosts through DHCPv6
generated by the hosts. The method is applicable to message exchanging while the interface identifiers are independently
Cryptographically Generated Addresses (CGA), and other IPv6 addresses generated by the hosts. It enables both integral address assignment
with host-generated interface identifiers. and self-generated addresses in one single mechanism, DHCPv6. It
also enables stateless address configuration without RA attendance.
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 November 24, 2012. This Internet-Draft will expire on February 22, 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
skipping to change at page 2, line 14 skipping to change at page 2, line 15
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Address Auto-configuration . . . . . . . . . . . . . . . . . . 4 3. Address Auto-configuration . . . . . . . . . . . . . . . . . . 4
4. DHCPv6 Operation . . . . . . . . . . . . . . . . . . . . . . . 5 4. DHCPv6 Operation . . . . . . . . . . . . . . . . . . . . . . . 5
5. DHCPv6 IA_PA Option . . . . . . . . . . . . . . . . . . . . . 6 5. DHCPv6 IA_PA Option . . . . . . . . . . . . . . . . . . . . . 6
5.1. Identity Association for Prefix Assignment Option . . . . 6 5.1. Identity Association for Prefix Assignment Option . . . . 7
5.2. IA_PA Prefix Option . . . . . . . . . . . . . . . . . . . 7 5.2. IA_PA Prefix Option . . . . . . . . . . . . . . . . . . . 8
6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
10.2. Informative references . . . . . . . . . . . . . . . . . . 9 10.2. Informative references . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
A host IPv6 address is combined by a prefix and an interface A host IPv6 address is combined by a prefix and an interface
identifier. Currently, there are two mechanisms to configure a host identifier. Currently, there are two mechanisms to configure a host
IPv6 address. [RFC3315] describes the operation of address IPv6 address. [RFC3315] describes the operation of address
assignment by a DHCPv6 server. The operation assumes that the server assignment by a DHCPv6 server. The operation assumes that the server
is responsible for the assignment of an integral address which is responsible for the assignment of an integral address which
includes prefix and interface identifier parts as described in includes both prefix and interface identifier parts as described in
[RFC4291]. In the Stateless Address Autoconfiguration (SLACC, [RFC4291]. In the Stateless Address Autoconfiguration (SLACC,
[RFC4862]) model, the interface Identifier is generated by the host [RFC4862]) model, the interface Identifier is generated by the host
itself while the prefix is configured through Router Advertisement itself while the prefix is configured through Router Advertisement
message defined in [RFC4861]. message defined in [RFC4861].
Up to now, there is no mechanism that allows host self-generated However, in a DHCPv6-managed network, assigning 128-bit address is
addresses to be used in the DHCPv6-managed network. insufficient. Some hosts may want to use self-generated address,
which are combined by prefixes obtained from network configuration
and interface identifiers generated by hosts. The examples include
CGA [RFC3972], modified EUI-64 interface identifier [EUI-64],
temporary addresses for privacy [RFC4941] and etc.
[RFC3633] defines Prefix Delegation options providing a mechanism for In these scenarios, the address configuration precedure has to be
automated delegation of IPv6 prefixes using the DHCPv6. This splitted in two motheds: integral address assignment through DHCPv6
mechanism is intended for delegating a long-lived prefix from a and prefix announcement by RA advertisement. Some ISPs desire to
delegating router to a requesting router. This mechanism "is not manage address configuration using one set of protocol, rather than
bound to the assignment of IP addresses or other configuration mixture of DHCPv6 and Neighbor Discovery.
information to hosts" [RFC3633]. It delegates prefixes to a routable
device for itself use only. It does not support the host-genarated
interface identifiers model, in which prefix(es) need to be
advertised or assigned to hosts.
This document introduces a new DHCPv6 procedure to configure hosts' There are also some network environments in that perfix annoucement
IPv6 addresses. In this new procedure, the prefix is advertised from through RAs may not be the best choice. For example, hosts may
a DHCPv6 server through DHCPv6 protocol while the interface connect through tunnels, either layer 2 tunnels or layer 3 tunnels.
identifiers are independently generated by the hosts. The usage of
DHCPv6 for assigning prefixes separats prefix assignment and
interface identifier generation.
[RFC3972] describes a method for binding a public signature key to an While a RA is only able to announce prefix on a single link, DHCPv6
IPv6 address. The basic idea is to generate the interface identifier configuration can be used to manage multiple links by setup DHCPv6
(i.e., the rightmost 64 bits) of the IPv6 address by computing a relay.
cryptographic hash of the public key. That is, the host decides its
interface identifier. As for the prefix part of the CGA, it is
probably got through Router Advertisement message defined in
[RFC4861], or through DHCPv6 operations defined in this document.
There are also other host-generated IPv6 addresses, which are Up to now, there is no mechanism for the prefix announcement/
combined by prefixes obtained from network configuration and assignment in DHCPv6. [RFC3633] defines Prefix Delegation options
ingerface identifiers generated by hosts, such as modified EUI-64 providing a mechanism for automated delegation of IPv6 prefixes using
interface identifier [EUI-64], temporary addresses for privacy the DHCPv6. This mechanism is intended for delegating a long-lived
[RFC4941],etc. The DHCPv6 operations defined in this document also prefix from a delegating router to a requesting router. This
supports such address methods. mechanism "is not bound to the assignment of IP addresses or other
configuration information to hosts" [RFC3633]. It delegates prefixes
to a routable device for itself use only. It does not support the
host-generated interface identifiers model, in which prefix(es) need
to be advertised or assigned to hosts.
The DHCPv6 operations defined in this document also supports the This document introduces a generic prefix announcement mechanism
assigned prefix to be shared across multiple hosts. using DHCPv6. In this new address configuration procedure, the
prefix is propagated from a DHCPv6 server to hosts through DHCPv6
message exchanging while the interface identifiers are independently
generated by the hosts. It is alternative of RA prefix assignment/
announcement. It enables both integral address assignment and self-
generated addresses in one single mechanism, DHCPv6. Note, in many
scenarios, neighbor discovery is still needed for routing and
reachability. In other scenarios, this mechanism enables stateless
address configuration while RA absents.
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].
The terminology in this document is based on the definitions in The terminology in this document is based on the definitions in
[RFC3315], in addition to the ones specified in this section [RFC3315], in addition to the ones specified in this section
skipping to change at page 5, line 10 skipping to change at page 5, line 15
o An interface identifier. Modified EUI-64 interface identifier o An interface identifier. Modified EUI-64 interface identifier
[EUI-64] is a widely-used host generated interface identifier. It [EUI-64] is a widely-used host generated interface identifier. It
generates interface identifier from the host MAC address. The generates interface identifier from the host MAC address. The
interface identifier of [RFC3972] is generated by computing a interface identifier of [RFC3972] is generated by computing a
cryptographic hash of a public key of a host. The host is cryptographic hash of a public key of a host. The host is
responsible for interface identifier generation. responsible for interface identifier generation.
In the ND-managed environment, RA is used to assign the prefix. In the ND-managed environment, RA is used to assign the prefix.
So far, there is no mechanism to support the scenario that prefixes So far, there is no mechanism to support the scenario that prefixes
are managed by a DHCPv6 server. The DHCPv6 operation defined in this are managed by a DHCPv6 server. This document targets to meet this
document enables the DHCPv6 server to assign a prefix, rather than a gap. The DHCPv6 operation defined in this document enables the
integral address, to the host, so that the host can obtain an IPv6 DHCPv6 server to assign a prefix, rather than a integral address, to
address by combining the prefix with its own generated interface the host, so that the host can obtain an IPv6 address by combining
identifier. It actually enables the auto address configuration the prefix with its own generated interface identifier. It actually
through DHCPv6. enables the auto address configuration through DHCPv6.
This document targets to meet this gap.
4. DHCPv6 Operation 4. DHCPv6 Operation
Figure 1 shows the operation of separating prefix assignment and Figure 1 shows the operation of separating prefix assignment and
interface identifier generation in the DHCPv6. interface identifier generation in the DHCPv6.
+------------+ +-------------+ +------------+ +-------------+
|Host(Client)| |DHCPv6 Server| |Host(Client)| |DHCPv6 Server|
+------------+ +-------------+ +------------+ +-------------+
| 1 Solicit | | 1 Solicit/Request |
|---------------------> | |---------------------> |
| 2 Advertise | | 2 Advertise/Reply |
| with IA_PA Option |
|<--------------------- | |<--------------------- |
3 Combination of Prefix | 3 Combination of Prefix |
and Interface Identifier | and Interface Identifier |
| | | |
Figure 1: DHCPv6 Operation Figure 1: DHCPv6 Operation
1. A host uses a Solicit message to discover DHCPv6 servers that 1. A host uses a Solicit message to discover DHCPv6 servers that
have been configured to assign prefixes for the host. Identity have been configured to assign prefixes for the host. Identity
Association for Prefix Delegation Option (IA_PD) is defined in Association for Prefix Delegation Option (IA_PD) is defined in
[RFC3633] for prefix delegation between a requesting router and [RFC3633] for prefix delegation between a requesting router and
delegating router. Referring to the definition, a new Identity delegating router. Referring to the definition, a new Identity
Association for Prefix Assignment (IA-PA) option is defined in Association for Prefix Assignment (IA-PA) option is defined in
Section 5.1 to enable the prefix assignment from a DHCPv6 server Section 5.1 to enable the prefix assignment from a DHCPv6 server
to a host. to a host. A host MAY include a Option Request Option requesting
IA_PA in a Solicit or a IA_PA Option in a Request message to
request prefix assignment explicitly.
2. The DHCPv6 server assigns one or more prefixes to the host in 2. The DHCPv6 server assigns one or more prefixes to the host in
Advertise messages or in the Reply messages to the prefix Advertise messages or in the Reply messages responding to the
requests from the hosts. The assigned prefixes SHOULD be a prefix requests from the hosts. When the prefix assignment in
advertise model, even if a host does not request, DHCPv6 server
can push it initiatively. The assigned prefixes SHOULD be a
subset of the authorized prefixes or derivative prefixes of the subset of the authorized prefixes or derivative prefixes of the
authorized prefixes. Identity Association for Prefix Assignment authorized prefixes. Identity Association for Prefix Assignment
Option in Section 5.1 is used for conveying the assigned Option in Section 5.1 is used for conveying the assigned
prefixes. If there is not a proper prefix available, a status- prefixes. If there is not a proper prefix available, a
code is returned to the host and the procedure is terminated. NoPrefixAvail (defined in [RFC3633])status-code is returned to
When receiving multiple prefixes, the host may use pre-configured the host and the procedure is terminated. When receiving
hints for prefix assignment preference. The hints are authorized multiple prefixes, the host may use pre-configured hints for
prefixes advertised by an authorized router through Certification prefix assignment preference. The hints are authorized prefixes
Path Advertisement defined in [RFC3971]. advertised by an authorized router through Certification Path
Advertisement defined in [RFC3971].
3. The host generates an interface identifier and formulates a 3. The host generates an interface identifier and formulates a
combined IPv6 address by concatenating the assigned prefix and combined IPv6 address by concatenating the assigned prefix and
the self-generated interface identifier. There are many ways to the self-generated interface identifier. There are many ways to
generate interface identifier. [RFC3972] defines a method to generate interface identifier. [RFC3972] defines a method to
generate the interface identifier by computing a cryptographic generate the interface identifier by computing a cryptographic
hash of a public key of the host. Modified EUI-64 interface hash of a public key of the host. Modified EUI-64 interface
identifier [EUI-64] is generated based on the host MAC address. identifier [EUI-64] is generated based on the host MAC address.
After the host generates an IPv6 address using the above procedure, After the host generates an IPv6 address using the above procedure,
the host may send a Request message to the DHCPv6 server in order to the host may send a Request message to the DHCPv6 server in order to
confirm the usage of the new address. The confirmation procedure may confirm the usage of the new address. The confirmation procedure may
be completed together with the address registration procedure. be completed together with the address registration procedure
However, the confirmation procedure is out of scope. [I-D.ietf-dhc-addr-registration]. However, the confirmation
procedure is out of scope.
When the host reaches T1 or T2 defined in Section 5.1, it SHOULD use
the same message exchanges, as described in section 18, "DHCP Client-
Initiated Configuration Exchange" of [RFC3315], to obtain or update
prefix(es) from a DHCPv6 server.
A DHCPv6 server MAY initiatively send a reconfiguration message to
the host, as described in section 19, "DHCP Server-Initiated
Configuration Exchange" of [RFC3315], to cause prefix(es) information
update.
5. DHCPv6 IA_PA Option 5. DHCPv6 IA_PA Option
In this section, one new option is defined, Identity Association for In this section, one new option is defined, Identity Association for
Prefix Assignment Option . The format of this new DHCPv6 IA_PA Prefix Assignment Option . The format of this new DHCPv6 IA_PA
Option has been deliberately designed to be the same with IA_PD Option has been deliberately designed to be the same with IA_PD
option[RFC3633]. The IA_PD Prefix and IA Address sub-options from option[RFC3633]. The IA_PD Prefix and IA Address sub-options from
IA_PD option are also reused. However, the two options are different IA_PD option are also reused. However, the two options are different
on the semantics and usage models. on the semantics and usage models.
skipping to change at page 9, line 7 skipping to change at page 9, line 37
Security considerations in DHCPv6 are described in [RFC3315]. Security considerations in DHCPv6 are described in [RFC3315].
To guard against attacks through prefix assignment, a host and a To guard against attacks through prefix assignment, a host and a
DHCPv6 server SHOULD use DHCPv6 authentication as described in DHCPv6 server SHOULD use DHCPv6 authentication as described in
Section 21, "Authentication of DHCP messages" of [RFC3315] or Secure Section 21, "Authentication of DHCP messages" of [RFC3315] or Secure
DHCPv6 [I-D.ietf-dhc-secure-dhcpv6] . DHCPv6 [I-D.ietf-dhc-secure-dhcpv6] .
9. Acknowledgements 9. Acknowledgements
The authors would like to thanks Suresh Krishnan, Ted Lemon and other The authors would like to thanks Suresh Krishnan, Ted Lemon, Bing
members of DHC WG for their valuable comments. Liu, Andre Kostur, Gaurav Halwasia, Bernie Volz and other members of
DHC WG for their valuable comments.
10. References 10. References
10.1. Normative References 10.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
skipping to change at page 10, line 11 skipping to change at page 10, line 47
RFC 3314, September 2002. RFC 3314, September 2002.
[RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16 [RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16
Based Networks", RFC 4968, August 2007. Based Networks", RFC 4968, August 2007.
[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-06 (work in progress), draft-ietf-dhc-secure-dhcpv6-06 (work in progress),
March 2012. March 2012.
[I-D.ietf-dhc-addr-registration]
Jiang, S. and G. Chen, "A Generic IPv6 Addresses
Registration Solution Using DHCPv6",
draft-ietf-dhc-addr-registration-00 (work in progress),
May 2012.
[EUI-64] "Guidelines for 64-bit Global Identifier (EUI-64) [EUI-64] "Guidelines for 64-bit Global Identifier (EUI-64)
Registration Authority", http://standards.ieee.org/ Registration Authority", http://standards.ieee.org/
regauth/oui/tutorials/EUI64.html", March 1997. regauth/oui/tutorials/EUI64.html", March 1997.
Authors' Addresses Authors' Addresses
Sheng Jiang Sheng Jiang
Huawei Technologies Huawei Technologies
Q14, Huawei Campus, No.156, BeiQing Road Q14, Huawei Campus, No.156, BeiQing Road
Hai-Dian District, Beijing 100095 Hai-Dian District, Beijing 100095
 End of changes. 23 change blocks. 
72 lines changed or deleted 101 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/