draft-ietf-dhc-host-gen-id-01.txt   draft-ietf-dhc-host-gen-id-02.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: May 24, 2012 Huawei Technologies Expires: November 24, 2012 Huawei Technologies
November 21, 2011 May 23, 2012
Prefix Assignment in DHCPv6 Prefix Assignment in DHCPv6
draft-ietf-dhc-host-gen-id-01.txt draft-ietf-dhc-host-gen-id-02
Abstract Abstract
This document describes a procedure for configuring hosts' IPv6 This document introduce a procedure for configuring hosts' IPv6
address which the prefix is assigned from a DHCPv6 server through address which the prefix is assigned from a DHCPv6 server through
DHCPv6 protocol while the interface identifiers are independently DHCPv6 protocol while the interface identifiers are independently
generated by the hosts. The method is applicable to generated by the hosts. The method is applicable to
Cryptographically Generated Addresses (CGA), and other IPv6 addresses Cryptographically Generated Addresses (CGA), and other IPv6 addresses
with host-generated interface identifiers. with host-generated interface identifiers.
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.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 May 24, 2012. This Internet-Draft will expire on November 24, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
skipping to change at page 3, line 7 skipping to change at page 3, line 7
7. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 8 7. IANA consideration . . . . . . . . . . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
[RFC3315] describes the operation of address assignment by a DHCPv6 A host IPv6 address is combined by a prefix and an interface
server. A client uses a Solicit message to discover DHCPv6 servers identifier. Currently, there are two mechanisms to configure a host
configured to assign addresses. A server sends an Advertise message IPv6 address. [RFC3315] describes the operation of address
in response to announce the availability of the server to the client. assignment by a DHCPv6 server. The operation assumes that the server
The client then uses a Request message to request addresses. The is responsible for the assignment of an integral address which
server then returns addresses in a Reply message. The operation includes prefix and interface identifier parts as described in
assumes that the server is responsible for the assignment of an [RFC4291]. In the Stateless Address Autoconfiguration (SLACC,
integral address which includes prefix and interface identifier parts [RFC4862]) model, the interface Identifier is generated by the host
as described in [RFC4291]. itself while the prefix is configured through Router Advertisement
message defined in [RFC4861].
This document introduces a new DHCPv6 procedure to configure hosts' Up to now, there is no mechanism that allows host self-generated
IPv6 addresses. In this new procedure, the prefix is advertised from addresses to be used in the DHCPv6-managed network.
a DHCPv6 server through DHCPv6 protocol while the interface
identifiers are independently generated by the hosts.
[RFC3633] defines Prefix Delegation options providing a mechanism for [RFC3633] defines Prefix Delegation options providing a mechanism for
automated delegation of IPv6 prefixes using the DHCPv6. This automated delegation of IPv6 prefixes using the DHCPv6. This
mechanism is intended for delegating a long-lived prefix from a mechanism is intended for delegating a long-lived prefix from a
delegating router to a requesting router. This mechanism "is not delegating router to a requesting router. This mechanism "is not
bound to the assignment of IP addresses or other configuration bound to the assignment of IP addresses or other configuration
information to hosts" [RFC3633]. It delegates prefixes to a routable information to hosts" [RFC3633]. It delegates prefixes to a routable
device for itself use only. It does not support the host-genarated device for itself use only. It does not support the host-genarated
interface identifiers model, in which prefix(es) need to be interface identifiers model, in which prefix(es) need to be
advertised or assigned to hosts. advertised or assigned to hosts.
This document introduces a new DHCPv6 procedure to configure hosts'
IPv6 addresses. In this new procedure, the prefix is advertised from
a DHCPv6 server through DHCPv6 protocol while the interface
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 [RFC3972] describes a method for binding a public signature key to an
IPv6 address in the Secure Neighbor Discovery (SEND) protocol IPv6 address. The basic idea is to generate the interface identifier
[RFC3971]. The basic idea is to generate the interface identifier
(i.e., the rightmost 64 bits) of the IPv6 address by computing a (i.e., the rightmost 64 bits) of the IPv6 address by computing a
cryptographic hash of the public key. That is, the host decides its cryptographic hash of the public key. That is, the host decides its
interface identifier. As for the prefix part of the CGA, it is interface identifier. As for the prefix part of the CGA, it is
probably got through Router Advertisement message defined in probably got through Router Advertisement message defined in
[RFC4861], or through DHCPv6 operations defined in this document. [RFC4861], or through DHCPv6 operations defined in this document.
[I-D.ietf-csi-dhcpv6-cga-ps] describes potential issues in the
interaction between DHCPv6 and CGA. In that document , the usage of
DHCPv6 for assigning prefixes is proposed to facilitate separation of
prefix assignment and interface identifier generation.
There are also other host-generated IPv6 addresses, which are There are also other host-generated IPv6 addresses, which are
combined by prefixes obtained from network configuration and combined by prefixes obtained from network configuration and
ingerface identifiers generated by hosts, such as modified EUI-64 ingerface identifiers generated by hosts, such as modified EUI-64
interface identifier [EUI-64], temporary addresses for privacy interface identifier [EUI-64], temporary addresses for privacy
[RFC4941],etc. The DHCPv6 operations defined in this document also [RFC4941],etc. The DHCPv6 operations defined in this document also
supports such address methods. supports such address methods.
The DHCPv6 operations defined in this document also supports the The DHCPv6 operations defined in this document also supports the
assigned prefix to be shared across multiple hosts. assigned prefix to be shared across multiple hosts.
skipping to change at page 9, line 17 skipping to change at page 9, line 17
The authors would like to thanks Suresh Krishnan, Ted Lemon and other The authors would like to thanks Suresh Krishnan, Ted Lemon and other
members of DHC WG for their valuable comments. 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.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[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.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[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.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007. IPv6", RFC 4941, September 2007.
10.2. Informative references 10.2. Informative references
[RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16
Based Networks", RFC 4968, August 2007.
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards", Generation Partnership Project (3GPP) Standards",
RFC 3314, September 2002. RFC 3314, September 2002.
[I-D.ietf-csi-dhcpv6-cga-ps] [RFC4968] Madanapalli, S., "Analysis of IPv6 Link Models for 802.16
Jiang, S., Shen, S., and T. Chown, "DHCPv6 and CGA Based Networks", RFC 4968, August 2007.
Interaction: Problem Statement",
draft-ietf-csi-dhcpv6-cga-ps-07 (work in progress),
May 2011.
[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-03 (work in progress), draft-ietf-dhc-secure-dhcpv6-06 (work in progress),
June 2011. March 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
 End of changes. 16 change blocks. 
45 lines changed or deleted 43 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/