[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06

Network Working Group                                     S. Daniel Park
Internet-Draft                                                    P. Kim
Expires: January 30, 2005                            Samsung Electronics
                                                             August 2004


           DHCP Option for Configuring IPv6-over-IPv4 Tunnels
                  draft-daniel-dhc-ipv6in4-opt-05.txt

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I 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 January 30, 2005.

Copyright Notice

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

Abstract

   This document provides a mechanism by which the DHCPv4 servers can
   provide information about the IPv6-over-IPv4 tunnel endpoint.  The
   IPv4/IPv6 dual stack nodes can use this information to set up a
   tunnel to the tunnel endpoint to obtain IPv6 connectivity without
   requiring manual intervention at any of the tunnel endpoints at
   tunnel establishment time.






Park & Kim              Expires January 30, 2005                [Page 1]


Internet-Draft    DHCP Option for IPv6-over-IPv4 Tunnel      August 2004


1.  Introduction

   In the initial deployment of IPv6, the IPv6 nodes may need to
   communicate with the other IPv6 nodes via IPv4 tunnel service.  The
   connectivity can be obtained by setting up an IPv6-over-IPv4 tunnel
   between a client and a tunnel router.

   This document defines a new option by which the DHCPv4 [RFC2131]
   server can notify the client with the list of endpoints of the
   possible IPv6-over-IPv4 tunnel defined in [RFC2893] in an automated
   manner.  Through this mechanism, dual stack users attached to IPv4
   only networks can connect its IPv6 connectivity to the endpoints as a
   tunnel router.

   Particularly, this mechanism is useful where the ISP is providing the
   IPv6 services but is doing it using tunneling over IPv4 to avoid
   upgrading all their infrastructure to support IPv6 on day one.

   Regarding IPv6-over-IPv4 tunnel, the tunnel broker [RFC3053]
   architecture has been widely deployed in the dual networks to obtain
   IPv6 connectivity via tunnel service because of easy configuration on
   the users.  After configuring IPv6-over-IPv4 tunnel between the users
   and the selected tunnel server, tunnel broker allows user to get
   access to the 6bone or any other IPv6 network the tunnel server is
   connected to.  In case of no tunnel broker, the proposed mechanism in
   this document can allow users to obtain the IPv6 connectivity
   efficiently.

1.1  Terminology

   The following terms pertaining to tunnel are used in this document as
   defined in [RFC2893]

   o  IPv6-over-IPv4 Tunnel:

      The technique of encapsulating IPv6 packets within IPv4 so that
      they can be carried across IPv4 routing infrastructures.
      IPv6-over-IPv4 tunnel where the IPv4 tunnel endpoint address is
      determined by configuration information learned from the DHCP
      Server on the encapsulating node.

   o  Tunnel endpoint address:

      Destination address of IPv4 encapsulating IPv6 packets.  It is an
      IPv4 address in the TEP Option originated from the DHCP Server.






Park & Kim              Expires January 30, 2005                [Page 2]


Internet-Draft    DHCP Option for IPv6-over-IPv4 Tunnel      August 2004


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.  IPv6-over-IPv4 Tunnel End Point Option

   This option specifies the IPv6-over-IPv4 tunnel endpoint that client
   should use when discovering the IPv4 address of the ISP's tunnel
   router somehow via the Dynamic Host Configuration Protocol.

   Once the IPv4 address has been learned, it is configured as the
   tunnel endpoint for the IPv6-over-IPv4 tunnel.

   The format of the IPv6-over-IPv4 Tunnel End Point Option is shown as
   below;

   The code for this option is TBD.  The length of this option is 4 (in
   case of single endpoint).




         Code            Length             TEP Order in Sequence
     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_TEP  |     Len       |             TEP Addr           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |         TEP Addr              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   In the above diagram, TEP Addr is 32-bit integers corresponding to
   DHCP options which specify the IP address of a different
   IPv6-over-IPv4 tunnel endpoint.

   All IPv6 traffic generated on the dual node SHOULD be encapsulated
   within IPv4 and forwarded to the endpoint assigned into the TEP Addr
   field of TEP option.

4.  DHCP Client Behavior

   The DHCP client will use this option to create a tunnel endpoint
   address for IPv6-over-IPv4 tunnel.  The client may receive tunnel
   services in this option that it does not support or has not been



Park & Kim              Expires January 30, 2005                [Page 3]


Internet-Draft    DHCP Option for IPv6-over-IPv4 Tunnel      August 2004


   configured to access.  Likewise, a client may receive an option that
   tunnel services for which no corresponding DHCP option was supplied.
   Clients will interpret this option in a system-specific manner whose
   specification is outside the scope of this document.

   As described in [RFC2893], the dual node received TEP option MUST
   store the tunnel endpoint address and this address is used as
   destination address for the encapsulating IPv4 header.

   Although the dual node obtains available tunnel endpoint address from
   the DHCP server, it can not receive any IPv6 packets from the tunnel
   router via IPv6-over-IPv4 tunnel because the tunnel router does not
   recognize which node is likely to configure its tunnel attached to
   the tunnel router.  As described in
   [I-D.nielsen-v6ops-zeroconf-goals] the tunnel protocol proposed in
   this document MUST allow for one tunnel endpoint to verify the
   reachability of other tunnel endpoint towards which it intends to
   send packets.  After verifying the reachability between them, IPv6
   Router Advertisement messages including address configuration
   information are reached to the dual node correctly, and the dual node
   configures its unique IPv6 address by itself in a stateless address
   autoconfiguration manner [RFC2461].  The dual node thus is able to
   forward its IPv6 traffics to the tunnel router learned from the TEP
   option of DHCP.

   One example of the reachability function is shown in Section 10 while
   specific considerations is beyond scope of this document.

   The determination of which packets to tunnel is usually made by
   routing information on the encapsulator.  This is usually done via a
   routing table, which directs packets based on their destination
   address using the prefix mask and match technique.  For more
   information, refer to section 4.  Configured Tunneling in [RFC2893].


















Park & Kim              Expires January 30, 2005                [Page 4]


Internet-Draft    DHCP Option for IPv6-over-IPv4 Tunnel      August 2004


   +---------------------------------------+
   |  IPv4 Network                         |
   |                                       |
   |                        +------------+ |
   |                        | DHCP Server| |
   | +-----------+          +-----+------+ |
   | | Dual Stack|                |        |
   | |    Node   |                |        |
   | +------**---+               /      +--------+       /------------\
   |        ||Tunnel Interface  /       | Tunnel |      /              \
   |        ||                 |        |Endpoint|------| IPv6 network |
   |        |==================+========|        |      \              /
   |              IPv6-over-IPv4 Tunnel +--------+       \------------/
   |                                       |
   |                                       |
   |                                       |
   |                                       |
   +---------------------------------------+



   Fig.  1, Simple network model for TEP option use case

5.  Multiple Tunnel End Point Considerations

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

   The list of endpoints can be installed as the default routes and the
   routes will be tried in a round robin fashion if the IPv6 host
   load-sharing is honored [I-D.ietf-ipv6-host-load-sharing].  Instead
   there can be specific default routes for the different destination.

   Generally, there may not be a need for installing multiple configured
   tunnel endpoints unless administrator wants two for redundancy
   purposes.  It is out of scope of this document.

6.  Security Considerations

   A rouge DHCP server can issue invalid or incorrect IPv6-over-IPv4
   tunnel endpoint.  This may cause denial of service due to
   unreachability or makes the client to reach incorrect destination.

   The latter has very severe security issues as the tunnel endpoint is
   on-the-path towards all the IPv6 destinations, and can trivially act
   as a man-in-the-middle attacker.



Park & Kim              Expires January 30, 2005                [Page 5]


Internet-Draft    DHCP Option for IPv6-over-IPv4 Tunnel      August 2004


   To increase secure exchange between users and tunnel endpoints, the
   tunnel broker or any tunnel agent can be used for configuring
   IPv6-over-IPv4 tunnels including authentication, security association
   and so on, but it is not scope of this document.

   The authenticated DHCP [RFC3118] can be also used for secure exchange
   between users and tunnel endpoints.

7.  Extended Usage

   As stated in Introduction, the tunnel broker is a nice tool for
   allowing user to get the IPv6 connectivity through IPv6-over-IPv4
   tunnel.  To configure tunnel between users and tunnel servers, users
   have to access to the tunnel broker by web registration and then
   tunnel broker set up tunnel between users and a selected tunnel
   server.  Prior to filling up the form on the tunnel broker, users
   have to know the IPv4 address of the tunnel broker (as described in
   [RFC3053], it may be IPv6 addressable but not mandatory).  Regarding
   this operation, this option proposed in this document can allow users
   to obtain an available tunnel broker address (or addresses) without
   any manual operations.

   For this operation, a new option (called Tunnel Broker Configuration
   Option: option name is OPTION_TBCO and value is TBD) can be simply
   made by DHCPv4 option extension which may be the same format as TEP
   option.

   To increase secure exchange between users and tunnel endpoints
   (tunnel servers or dual routers) this extended usage can be applied
   for configuring IPv6-over-IPv4 tunnel instead of direct tunnel
   configuration between them.  Specific method for secure exchange is
   beyond scope of this document.

8.  IANA Considerations

   IANA is requested to an assign value for the IPv6-over-IPv4 Tunnel
   End Point option code in accordance with [RFC2939].

   Option Name      Value     Described in

   OPTION_TEP       TBD        Section 3.

   OPTION_TBCO      TBD        Section 7.  (if necessary)

9.  Acknowledgements

   Special thanks to Pekka Savola, Vijayabhaskar A K, Eric Nordmark,
   Ralph Droms, Bernie Volz and Alain Durand for their many valuable



Park & Kim              Expires January 30, 2005                [Page 6]


Internet-Draft    DHCP Option for IPv6-over-IPv4 Tunnel      August 2004


   revisions and comments.  In particular, Pekka Savola kindly clarified
   the multiple tunnel end point considerations with his good experience
   as well.

   Specially, authors would like to acknowledge the implementation
   contributions by Minho Lee of Samsung Electronics.

10.  Impmenentation Experiences

   We have implemented TEP option using the Internet Systems Consortium
   DHCP source code (DHCP-3.0.1-rc13 version) on both DHCP server and
   client, particularly client is an IPv4/IPv6 dual stack based on Linux
   operating system.

   For the simple implementation, TCP/UDP port assigned both endpoints
   by operator in advance was used to verify the reachability in this
   document.

11.  References

11.1  Normative References

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

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol", RFC
              2131, March 1997.

   [RFC2939]  Droms, R., "Procedures and IANA Guidelines for Definition
              of New DHCP Options and Message Types", BCP 43, RFC 2939,
              September 2000.

   [RFC3118]  Droms, R. and W. Arbaugh, "Authentication for DHCP
              Messages", RFC 3118, June 2001.

11.2  Informative References

   [I-D.ietf-ipv6-host-load-sharing]
              Hinden, R., "IPv6 Host to Router Load Sharing",
              draft-ietf-ipv6-host-load-sharing-02 (work in progress),
              May 2004.

   [I-D.nielsen-v6ops-zeroconf-goals]
              Morelli, M., "Goals for Zero-Configuration Tunneling",
              draft-nielsen-v6ops-zeroconf-goals-01 (work in progress),
              September 2004.

   [RFC2461]  Narten, T., Nordmark, E. and W. Simpson, "Neighbor



Park & Kim              Expires January 30, 2005                [Page 7]


Internet-Draft    DHCP Option for IPv6-over-IPv4 Tunnel      August 2004


              Discovery for IP Version 6 (IPv6)", RFC 2461, December
              1998.

   [RFC2893]  Gilligan, R. and E. Nordmark, "Transition Mechanisms for
              IPv6 Hosts and Routers", RFC 2893, August 2000.

   [RFC3053]  Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6
              Tunnel Broker", RFC 3053, January 2001.


Authors' Addresses

   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


   Pyungsoo Kim
   Samsung Electronics
   416 Maetan-3dong, Yeongtong-gu
   Suwon-si, Gyeonggi-do  443-742
   KOREA

   Phone: +82 31 200 4635
   EMail: kimps@samsung.com





















Park & Kim              Expires January 30, 2005                [Page 8]


Internet-Draft    DHCP Option for IPv6-over-IPv4 Tunnel      August 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.




Park & Kim              Expires January 30, 2005                [Page 9]


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