[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/