Network Working Group                                     S. Daniel Park
Internet-Draft                                    Samsung                                       SAMSUNG Electronics
  Expires : 26 September 2004                        A.K.
Expires: April 22, 2006                                 A. Vijayabhaskar
                                                        Hewlett-Packard
                                                          27 March 2004
                                                                      HP
                                                        October 22, 2005

             Configured Tunnel End Point Option for DHCPv6
                     draft-ietf-dhc-dhcpv6-ctep-opt-01.txt
                 draft-ietf-dhc-dhcpv6-ctep-opt-02.txt

Status of this Memo

     This document

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is an Internet-Draft aware
   have been or will be disclosed, and is any of which he or she becomes
   aware will be disclosed, in full conformance accordance with
     all provisions of Section 10 6 of RFC2026. BCP 79.

   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.

   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 April 22, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2004). (2005).  All Rights Reserved.

Abstract

   For the newly deployed IPv6 networks to interoperate with vastly
   deployed IPv4 networks, various transition mechanisms had been
   proposed.  One such mechanism is configured tunnels.  This document
   provides a tunnel discovery mechanism by which the DHCPv6 servers can
   provide information about the various available configured tunnel end points
   to reach the IPv6 nodes which are separated by IPv4 networks.

1.  Introduction

   In the initial deployment of IPv6, the IPv6 nodes may need to
   communicate with the other IPv6 nodes via IPv4 networks.  Configured
   tunnels [3] [RFC4213] provide a way to encapsulate the IPv6 packets in
   IPv4 packets and tunnel them in the IPv4 network.

   This document defines a new option called Configured Tunnel End Point
   by which the DHCPv6 [1] [RFC3315] server can notify the client with the
   list of end point of the configured tunnels to the various IPv6
   networks separated by the IPv4 networks.

2.  Background

   Configured Tunnel described in this document is a simple and
   temporary mechanism which allows isolated IPv6 networks or hosts,
   attached to a legacy IPv4 network which has no native IPv6
   connectivity, to communicate with other such IPv6 networks or hosts
   with manual configuration.  The configured tunnel end-point received
   from the DHCPv6 server is not used for IPv6 connectivity as long as
   IPv6 networks or hosts are communicating with other IPv6 networks or
   hosts via IPv6 network which has native IPv6 connectivity and only
   available when communicating with other IPv6 networks or hosts via
   IPv4 networks.

   In this scenario, 6to4 [4] [RFC3056] can be a possible alternative
   instead of configured tunnel and does not require IPv4-compatible IPv6
     addresses or configured tunnels. tunnel.

   As indicated in [4], [RFC3056], the mechanisms are intended as a start-up
   transition tool used during the period of co-existence of IPv4 and
   IPv6.  It is not intended as a permanent solution.

3.  Requirements

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
     SHOULD NOT, RECOMMENDED, MAY, key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and OPTIONAL, when they appear "OPTIONAL" in this
     document,
   document are to be interpreted as described in RFC 2119 [2] [RFC2119].

4.  Terminology

   This document uses terminology specific to IPv6 and DHCPv6 as defined
   in "Terminology" section of the DHCPv6 specification [1]. [RFC3315].

5.  Configured Tunnel End Point Option

   The Configured Tunnel End Point Option gives the information to the
   clients about the Configured Tunnel End Point [3] [RFC4213] to be
   contacted for reaching the nodes in the various IPv6 networks which
   are separated by IPv4 networks.  The clients are expected to install
   these routes in their machines.

   The format of the Configured Tunnel End Point Option is as shown
   below:

      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_CTEP         |           option-len          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   prefix-len  |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                                                               |
     |                 Destination Prefix (16 bytes)                 |
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                 Configured TEP Address (16 bytes)             |
     |                                                               |
     |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               | prefix-len    |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                 Destination Prefix (16 bytes)                 |
     |                                                               |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                                                               |
     |                Configured TEP Address (16 bytes)              |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                         . . .                                 |               |... (if multiple tunnels are in use)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   option-code: OPTION_CTEP (TBD)

   option-len: Total length of the prefix-len, Destination Prefix and Configured Tunnel Address
   lists in octets; It should be a multiple of 33. 17.

   prefix-len: prefix length of the Destination Prefix

     Destination Prefix: An IPv6 Prefix; this Configured TEP Address in bits.

   Configured TEP Address: IPv6 Address of the Configured TEP.  This
     address is a IPv4-compatible IPv6 address.

   The clients are expected to install the routes identified by the
   tuples <Destination Prefix/prefix-len, (prefix-len, Configured TEP Address> Address) once they receive this
   option from the server.

6.  Appearance of this option

   The Configured Tunnel End Point Option MUST NOT appear in other than
   the following messages:  Solicit, Advertise, Request, Renew, Rebind,
   Information-Request and Reply.

   The option numbers of Configured Tunnel End Point option MAY appear
   in the Option Request Option [1] [RFC3315] in the following messages:
   Solicit, Request, Renew, Rebind, Information-Request and Reconfigure.

7.  multiple Tunnel End Point Considerations

   For the simple tunnel discovery, one tunnel endpoint is generally
   used and it assumes that all the networks will be reached through the
   same endpoint.  In this case, one Configured TEP field in the TEP
   option is used for configured tunnel service.

   The list of endpoints can be installed if the IPv6 host load-sharing
   is honored, but there may not be a need for installing multiple
   configured tunnel endpoints unless administrator wants two for
   redundancy purposes.  It is beyond scope of this document.

8.  Security Considerations

   The Configured Tunnel End Point Option may be used by an intruder
   DHCPv6 server to provide invalid or incorrect configured tunnel end
   point.  This makes the client unable to reach its destination IPv6
   node or to reach incorrect destination.  The latter one has very
   severe security issues as IPv6 destination is spoofed here.

   To avoid attacks through this option, the DHCPv6 client SHOULD use
   authenticated DHCP (see section "Authentication of DHCP messages" in
   the DHCPv6 specification [1]).

  8. [RFC3315]).

9.  IANA Considerations

   IANA is requested to assign an option code to the following options
   from the option-code space defined in "DHCPv6 Options" section of the
   DHCPv6 specification [1]. [RFC3315].

   Option Name      Value     Described in

   OPTION_CTEP       TBD        Section 4

  9.

10.  References

  9.1

10.1  Normative References

     [1]   Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and
           R.Droms (ed.), "Dynamic Host Configuration Protocol for IPv6
           (DHCPv6)", RFC 3315, July 2003.

     [2]

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

  9.2 Informative References

     [3]   Gilligan, R, Nordmark, E., "Transition Mechanisms

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
              M. Carney, "Dynamic Host Configuration Protocol for IPv6
           Hosts and Routers",
              (DHCPv6)", RFC 2893, August 2000.

     [4] 3315, July 2003.

10.2  Informative References

   [RFC3056]  Carpenter, B., Moore K., B. and K. Moore, "Connection of IPv6 Domains
              via IPv4 Clouds", RFC 3056, February 2001.

   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
              for IPv6 Hosts and Routers", RFC 4213, October 2005.

Authors' Addresses

   Soohong Daniel Park
     Mobile Platform Laboratory
     Samsung Electronics.
     Suwon
     Korea
   SAMSUNG Electronics
   416 Maetan-3dong, Yeongtong-gu
   Suwon-si, Gyeonggi-do  442-742
   KOREA

   Phone: +81-31-200-4508
     E-Mail: +82 31 200 4635
   EMail: soohong.park@samsung.com

   Vijayabhaskar A K
   Hewlett-Packard STSD-I
   29, Cunningham Road
   Bangalore -  560052
     India
   INDIA

   Phone: +91-80-2053085
     E-Mail: +91 80 205308582
   EMail: vijayak@india.hp.com

  Acknowledgements

     Thanks to the DHC Working Group for their time and input into the
     specification.  In particular, thanks to Pekka Savola, Bernie Volz,
     Ralph Droms, Margaret Wasserman for their valuable comments on this
     work.

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
     intellectual property
   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; neither nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the
     IETF's procedures with respect to rights in standards-track and
     standards-related documentation RFC documents can be
   found in BCP-11. BCP 78 and BCP 79.

   Copies of
     claims of rights IPR disclosures made available for publication 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 implementors implementers or users of this
   specification can be obtained from the IETF Secretariat. 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 which that may cover technology that may be required to practice implement
   this standard.  Please address the information to the IETF Executive
     Director.

  Full Copyright Statement

     Copyright (C) The Internet Society (2004).  All Rights Reserved.

     This document and translations of it may be copied and furnished to
     others, and derivative works that comment on or otherwise explain it
     or assist in its implementation may be prepared, copied, published
     and distributed, in whole or in part, without restriction of any
     kind, provided that the above copyright notice and this paragraph
     are included on all such copies and derivative works.  However, this
     document itself may not be modified in any way, such as by removing
     the copyright notice or references to the Internet Society or other
     Internet organizations, except as needed for the purpose at
   ietf-ipr@ietf.org.

Disclaimer of
     developing Internet standards in which case the procedures for
     copyrights defined in the Internet Standards process must be
     followed, or as required to translate it into languages other than
     English.

     The limited permissions granted above are perpetual and will not be
     revoked by the Internet Society or its successors or assigns. Validity

   This document and the information contained herein is 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 DISCLAIMS 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.

  Acknowledgement

Copyright Statement

   Copyright (C) The Internet Society (2005).  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.