Network Working Group S. Madanapalli
Internet-Draft S. Kumar
Expires: May 26, 2005 Samsung ISO
S. Park
Samsung Electronics
November 25, 2004
Service-Oriented Address Assignment using DHCPv6
draft-ietf-dhc-soa-option-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 26, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document introduces a new option in DHCPv6 for Service-Oriented
Address assignment for a particular type of service that DHCPv6
Clients provide. The Service-Oriented Address can be either
Anycast/Shared Unicast or a Well-known Unicast Address. This
address assignment is much similar to other address type assignments,
Madanapalli, et al. Expires May 26, 2005 [Page 1]
Internet-Draft Service-Oriented Address Assignment Using DHCPv6
November 2004
except that Service-Oriented Address assignment requires the
specification of Service Type of the node that is requesting the
address.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Applicability Statements . . . . . . . . . . . . . . . . . . . 3
4. DHCPv6 specification dependency . . . . . . . . . . . . . . . 4
5. Identity Association for Service-Oriented Addresses . . . . . 4
5.1 IA_SA Option Format . . . . . . . . . . . . . . . . . . . 4
6. Overview of Service-Oriented Address Assignment . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 7
10.2 Informative References . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . 9
Madanapalli, et al. Expires May 26, 2005 [Page 2]
Internet-Draft Service-Oriented Address Assignment Using DHCPv6
November 2004
1. Introduction
IPv6 Addressing Architecture [RFC3513] defines a new addressing
scheme called "anycast address" that is an identifier for a set of
interfaces (typically belonging to different nodes). A packet sent
to an anycast address is routed to the "nearest" interface having
that address, depending on the distance of the routing path. Anycast
addresses can be used as unique service identifiers for many services
such as Domain Name System (DNS) Servers, Web-Servers etc.
Also usage of Well-known Unicast Addresses is being increasing for
acheiving Zero-configuration.
DHCPv6 base specification [RFC3315] provides a way for the DHCPv6
clients to get permanent/temporary unicast addresses from a DHCPv6
Server. This document provides a way for assigning an address to a
Service provided by the DHCPv6 Clients. An address that is assigned
to a service is called Service-Oriented Address (SOA). The
Service-Oriented Address can be Anycast/Shared Unicast or a
Well-known Unicast Address. This document introduces a new IA_SA
option in DHCPv6 for Service-Oriented Address assignment for a
particular type of service that DHCPv6 Client provides. This address
assignment is much similar to other address types assignments, except
that the Service-Oriented Address assignment requires the
specification of Service Type while requesting this address
assignement.
2. Requirements
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. Applicability Statements
IPv6 Anycast has been adopted by IPv6 and has been defined in
[RFC3513]. But its usage has been restricted to nodes which are
routers. However, [I-D.ietf-ipngwg-ipv6-anycast-analysis] provides
few guidelines to extend its usage to Hosts and also provides various
other forms of anycasting usages that are in practice (e.g. Shared
Anycast Addresses).
Anycast addresses can be used as unique service identifiers. Many
services such as Domain Name System (DNS) and HTTP proxy are operated
on the Internet. It is troublesome that users have to know IP
addresses of servers for accessing these services at each site. If
each service had its own unique anycast address as its service
identifier and its servers used the address for their network
Madanapalli, et al. Expires May 26, 2005 [Page 3]
Internet-Draft Service-Oriented Address Assignment Using DHCPv6
November 2004
interfaces, users could access the service only with the anycast
address. This mechanism can ease users into using services.
Currently no mechanism exists to automatically configure the hosts
with a specific (anycast) address for a particular service. Also
usage of Well-Known Addresses is increasing for achieving
zero-configuration. Currently these addresses are being preloaded
into the devices before shipping them to the end-users.
This draft is applicable to the Nodes that provide well-known
services (e.g. DNS Servers) and administrator defined servers using
Anycast/Shared Unicast Addressing (e.g. Web Servers) for dynamically
assigning the addresses corresponding the services they provide using
DHCPv6.
4. DHCPv6 specification dependency
This document describes new DHCPv6 option for service-oriented
address assignment. This document should be read in conjunction with
the DHCPv6 specification [RFC3315]. Definitions for terms and
acronyms not specifically defined in this document are defined in
[RFC3315].
5. Identity Association for Service-Oriented Addresses
An IA_SA is a construct through which a server and a client can
identify, group and manage a set of related IPv6 service-oriented
addresses. Each IA_SA consists of an IAID and associated
configuration information. An IA_SA for Service-Oriented Address is
similar to IA_NA as described in [RFC3315] for unicast permanent
addresses.
The choosing of IA_SA IAID is similar to IA_NA IAID and IA_TA IAID.
More details on choosing an IAID is given in [RFC3315].
The configuration information in an IA_SA consists of one or more
IPv6 Service- Oriented Addresses for each Service Type along with the
times T1 and T2 for the IA_AA.
5.1 IA_SA Option Format
The Identity Association for Service-Oriented Addresses (IA_SA)
option is used to carry an IA_SA, the parameters associated with the
IA_SA, and the anycast/shared unicast addresses or well-known unicast
addresses associated with the IA_SA.
The format of the IA_SA option is:
Madanapalli, et al. Expires May 26, 2005 [Page 4]
Internet-Draft Service-Oriented Address Assignment Using DHCPv6
November 2004
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_IA_SA | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service-Type |A| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. IA_SA-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Field description
o option-code: OPTION_IA_SA (TBD).
o option-len: 16 + length of IA_SA-options field.
o IAID: The unique identifier for this IA_SA; the IAID must be
unique among the identifiers for all of this client's IA_SAs. The
number space for IA_SA IAIDs is separate from the number space for
IA_NA IAIDs and IA_TA IAIDs.
o Service-Type: The Service Type for which Anycast/Shared Unicast/
Well-Known Address to be assigned.
A: 1-bit Flag, indicates if the address is an anycast address.
o T1: The time at which the client contacts the server from which
the addresses in the IA_SA were obtained to extend the lifetimes of
the addresses assigned to the IA_SA; T1 is a time duration relative
to the current time expressed in units of seconds.
o T2: The time at which the client contacts any available server to
extend the lifetimes of the addresses assigned to the IA_SA; T2 is a
time duration relative to the current time expressed in units of
seconds.
o IA_SA-options: Options associated with this IA_SA.
Madanapalli, et al. Expires May 26, 2005 [Page 5]
Internet-Draft Service-Oriented Address Assignment Using DHCPv6
November 2004
The IA_SA-Options field encapsulates those options that are specific
to this IA_SA. For example, all of the IA Address Options [RFC3315]
carrying the addresses associated with this IA_SA are in the
IA_SA-options field.
An IA_SA option may only appear in the options area of a DHCP
message. A DHCP message may contain multiple IA_SA options.
The T1 and T2 parameters in IA_SA option are similar to T1 and T2
parameters in IA_NA option, refer [RFC3315] for more details.
6. Overview of Service-Oriented Address Assignment
The DHCPv6 Client that wants to get Service-Oriented Address for a
specific service Type includes IA_SA option in the Solicitation
and/or Request that it sends to DHCPv6 Server with the Service-Type.
If the client requires Service-Oriented addresses for multiple
service types, it can include multiple IA_SA option fields in
Solicitation and/or Request Messages.
The DHCPv6 server then checks the availability of the
Service-Oriented Address for the requested service type. If the
Service-Oriented Address pertinent to the Service Type is configured
in the DHCPv6 Server to assign to the clients, then the server fills
the Service-Oriented Address in IA Address Option which will be
included in IA_SA Option that will be sent in Advertise/Reply Message
to the DHCPv6 Client. If there are multiple Service-Oriented Address
available for the same service type the server can typically includes
multiple IA Address Options in IA_SA Option.
7. Security Considerations
The DHCPv6 Option defined here allows a malicious server providing
incorrect address information to the client, causing users with valid
service-oriented address unable to use services. This is a well
known property of the DCHP protocol [RFC3315]. This option does not
create any additional risk of such attacks.
To guard against such "man in the middle" attacks, the DHCPv6 client
SHOULD use authenticated DHCP as described in section 21,
"Authentication of DHCP messages" of RFC 3315.
8. IANA Considerations
This document defines the following new DHCPv6 option that IANA needs
assign a code from DHCPv6 Option codes name space:
Option Name Value Described in
Madanapalli, et al. Expires May 26, 2005 [Page 6]
Internet-Draft Service-Oriented Address Assignment Using DHCPv6
November 2004
OPTION_IA_AA TBD Section 5.1
This document introduces a new name space for Service-Type. The DHC
WG needs to identify the relevant Service Types for which IANA will
later need to assign the codes.
9. Future Work
o Identifying & Defining of Service Types
o Defining similar option for DHCPv4.
10. References
10.1 Normative References
[I-D.ietf-ipngwg-ipv6-anycast-analysis]
Hagino, J. and K. Ettican, "An analysis of IPv6 anycast",
draft-ietf-ipngwg-ipv6-anycast-analysis-02 (work in
progress), June 2003.
[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.
10.2 Informative References
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
Authors' Addresses
Syam Madanapalli
Samsung India Software Operations
J. P. Techno Park, 3/1
Millers Road, Bangalore 560052
INDIA
Phone: +91 80 51197777
EMail: syam@samsung.com
Madanapalli, et al. Expires May 26, 2005 [Page 7]
Internet-Draft Service-Oriented Address Assignment Using DHCPv6
November 2004
Suraj Kumar
Samsung India Software Operations
J. P. Techno Park, 3/1
Millers Road, Bangalore 560052
INDIA
Phone: +91 80 51197777
EMail: suraj.kumar@samsung.com
Soohong Daniel Park
Samsung Electronics
416 Maetan-3dong, Yeongtong-gu
Suwon-si, Gyeonggi-do 443-742
KOREA
Phone: +82 31 200 4508
EMail: soohong.park@samsung.com
Madanapalli, et al. Expires May 26, 2005 [Page 8]
Internet-Draft Service-Oriented Address Assignment Using DHCPv6
November 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Madanapalli, et al. Expires May 26, 2005 [Page 9]
