Experimental RFC Proposal Internet Draft Jim Bound (Editor) Document: draft-bound-dstm-exp-00.txt Hewlett Packard Expires: February 2004 August 2003 Dual Stack Transition Mechanism Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. This document is a submission by the Internet Protocol IPv6 Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ipng@sunroof.eng.sun.com mailing list. 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. Abstract The deployment of IPv6 will require a tightly coupled use of IPv4 addresses to support the interoperation of IPv6 and IPv4 within an IPv6 dominant network. Nodes will still need to communicate with IPv4 nodes that do not have a Dual IP layer supporting both IPv4 and IPv6. The Dual IP Layer Stack Transition Mechanism (DSTM) is based on the use of IPv4-over-IPv6 tunnels to carry IPv4 traffic within an IPv6 dominant network and provides a method to allocate a temporary IPv4 address to Dual IP Layer IPv6/IPv4 capable nodes. DSTM is also a way to avoid the use of Network Address Translation for early adopter IPv6 deployment to communicate with IPv4 legacy nodes and applications. draft-bound-dstm-exp-00.txt Expires February 2004 [Page 1] Internet Draft Dual Stack Transition Mechanism August 2003 Table of Contents: 1. Introduction................................................3 2. DSTM Terminology............................................4 3. DSTM Problem Statement and Assumptions......................5 4. DSTM Deployment Example.....................................7 5. DSTM Client.................................................8 5.1 DSTM Server Access Module...................................8 5.2 DSTM Dynamic Tunnel Interface (DTI).........................9 6. DSTM Server ................................................9 6.1 DSTM Client Access Module...................................9 6.2 DSTM Address Pool Access Module.............................9 6.3 DSTM Routing Information Access Module......................9 7. DSTM Border Router..........................................9 8. Applicability Statement....................................10 9. Security Considerations....................................10 Appendix A DHCPv6 Options for DSTM.............................11 Appendix B DSTM Port Options for DHCPv6........................16 Appendix C Tunnel Setup Protocol (TSP).........................18 Full Copyright Statement.......................................33 Acknowledgments................................................33 References.....................................................33 Authors Addresses..............................................34 draft-bound-dstm-exp-00.txt Expires February 2004 [Page 2] Internet Draft Dual Stack Transition Mechanism August 2003 1. Introduction The deployment of IPv6 will require a tightly coupled use of IPv4 addresses to support the interoperation of IPv6 and IPv4 within an IPv6 dominant network. Nodes will still need to communicate with IPv4 nodes that do not have a Dual IP layer supporting both IPv4 and IPv6. The Dual IP Layer Stack Transition Mechanism (DSTM) is based on the use of IPv4-over-IPv6 tunnels to carry IPv4 traffic within an IPv6 dominant network and provides a method to allocate a temporary IPv4 address to Dual IP Layer IPv6/IPv4 capable nodes. DSTM is also a way to avoid the use of Network Address Translation for early adopter IPv6 deployment to communicate with IPv4 legacy nodes and applications. DSTM is targeted to help the interoperation of IPv6 newly deployed networks with existing IPv4 networks, where the user wants to begin IPv6 adoption with an IPv6 dominant network plan, or later in the transition of IPv6, when IPv6 dominant networks will be more prevalent. When DSTM is deployed in a network, an IPv4 address can be allocated to a Dual IP Layer IPv6/IPv4 capable node to connect with IPv4 only capable nodes. DSTM permits dual IPv6/IPv4 nodes to communicate with IPv4 only nodes and applications, without modification to any IPv4 only node or application, or the IPv4 only application on the DSTM node. This allocation mechanism is coupled with the ability to perform IPv4-over-IPv6 tunneling of IPv4 packets inside the IPv6 dominant network. The DSTM architecture is composed of a DSTM address server, and DSTM capable nodes. The DSTM server is responsible for IPv4 address allocation to client nodes and MAY also provide tunnel end points (TEP) to the DSTM nodes. The DSTM server MUST guarantee the uniqueness of the IPv4 address for a period of time. The DSTM nodes will use TEPs to tunnel IPv4 packets within IPv6 to a DSTM Border router. The DSTM border router then decapsulates the IPv6 packets and transmits the IPv4 packets to the destination IPv4 node. The DSTM border router MUST cache the path back to the DSTM node for the IPv4 address to tunnel the packet in IPv6 to the original DSTM node. draft-bound-dstm-exp-00.txt Expires February 2004 [Page 3] Internet Draft Dual Stack Transition Mechanism August 2003 2. DSTM Terminology DSTM Domain The network areas on an Intranet where dual IPv6/IPv4 nodes use DSTM to assure IPv4 communication. An IPv4 address allocation server may be deployed inside the domain to manage an IPv4 address pool. IPv4 routing access may not be maintained within a DSTM domain. DSTM Client A Dual IP Layer IPv4/IPv6 Capable Node that has implemented the DSTM client software in this specification. DSTM Server A Dual IP Layer IPv4/IPv6 Capable Node that has implemented the DSTM server software in this specification. DSTM Border Router A Dual IP Layer IPv4/IPv6 Capable Node that has implemented the DSTM border router software in this specification. IPv6 Dominant Network A network that is using IPv6 as the dominant network transport for network operations. Dynamic Tunnel Interface This is an interface on a DSTM Client that will permit the sending of IPv4 packets within IPv6 to a DSTM Border Router, and receive IPv4 packets within IPv6 from an IPv4 node or application. draft-bound-dstm-exp-00.txt Expires February 2004 [Page 4] Internet Draft Dual Stack Transition Mechanism August 2003 3. DSTM Problem Statement and Assumptions Since the IPv4 globally routable address space available is becoming a scarce resource, it is assumed that users will deploy IPv6 to reduce the need and reliability on IPv4 within a portion of their networks. Some users will require an aggressive transition to IPv6 and will begin the deployment of IPv6 reducing immediately the reliance on IPv4 whereever possible. Under this premise, supporting native IPv4 and native IPv6 simultaneously largely increases the complexity and cost of network administration (e.g. address plan, routing infrastructure). It is proposed, in this case, to define the network strategy plan to support IPv6 only as soon as possible. Reliance on IPv4 infrastructure points like name service and address allocation for Dual IPv6/IPv4 capable nodes will move to an IPv6 strategy. Using DSTM, DHCPv4 [1] would not be used to assign IPv4 addresses to a DSTM Dual IP Layer IPv6/IPv6 nodes, since IPv4 routing is not maintained within an IPv6 Dominant Network implementation. Using DHCPv6 [2] reduces the reliance on IPv4 infrastructure for the transition to IPv6 with DSTM. But, DHCPv6 is not the only mechanism that can be supported to allocate IPv4 addresses to a DSTM client. DSTM is a transition mechanism that uses existing protocols. DSTM does not specify a protocol. However, DSTM defines client, server, and border router behavior and the properties of the temporary addresses allocation mechanisms. The core assumption within DSTM is that it is completely transparent to applications, which can continue to work with IPv4 addresses. It is also transparent to the network, which carries only IPv6 packets. DSTM assumes the user, has deployed IPv6 to support end-2-end applications and security, without translation. The DSTM architecture base assumptions are as follows: 1. The DSTM domain is within an Intranet not on the Internet. 2. Dual IPv6/IPv4 nodes do not maintain IPv4 addresses except on a temporary basis, to communicate with IPv4 Applications. 3. The temporary IPv4 address allocation is done by the DSTM server, different protocols such as DHCPv6 or other mechanism can be used to assign the IPv4 address. 4. DSTM will keep IPv4 routing tables to a minimum and use IPv6 routing, which will reduce the network management required for IPv4 during transition within a DSTM Dominant IPv6 Network. 5. Once IPv6 nodes have obtained IPv4 addresses Dynamic Tunneling is used to encapsulate the IPv4 packet within IPv6 and then forward that packet to an IPv6 TEP DSTM border router, where the packet will be decapsulated and forwarded using IPv4. The IPv4 allocation mechanism, from the DSTM server, can provide the TEP IPv6 address to the DSTM client, in addition to manual configuration. 6. Existing IPv4 applications or nodes do not have to be modified. draft-bound-dstm-exp-00.txt Expires February 2004 [Page 5] Internet Draft Dual Stack Transition Mechanism August 2003 Implementation defined software will have to exist to support DSTM: 1. DSTM server implementation is required to maintain configuration information about TEPs for encapsulating IPv4 packets between IPv6 nodes that can forward IPv4 packets to an IPv4 routing destination, and to maintain a pool of IPv4 addresses. 2. DSTM client implementation is required to support the dynamic tunneling mechanisms in this specification to encapsulate IPv4 packets within IPv6, and be able to communicate with the DSTM server to obtain IPv4 addresses and TEPs. 3. DSTM border router implementation is required to support the decapsulation of IPv6 packets from DSTM clients and forward them to the IPv4 destination, and cache the IPv6 address and the source IPv4 address used by the DSTM client. Schematic Overview of DSTM ------------------------------------------------- | IPv4 Intranet | DSTM Domain Intranet | Internet or Intranet | _____________________ | Applications Domain | | | | DSTM Server | | |_____________________| | ^ | | | __________________ | | | | | | | IPv6/IPv4 Node | | ---------------- |------------------| | | DSTM Border | | DSTM client | | | Router | | |<------- | | |------------------| | Address mapping| | DTI/Route | /------------------ |----------------| | | IPv4 in IPv6 | IPv6/IPv4 node | ------------------ ------------------/ ---------------- | ----------------------------------------------- draft-bound-dstm-exp-00.txt Expires February 2004 [Page 6] Internet Draft Dual Stack Transition Mechanism August 2003 4. DSTM Deployment Example In the example below, the following notation will be used: X will designate a dual IPv6/IPv4 node, X6 will be the IPv6 address of this node and X4 the IPv4 address Y will designate a DSTM border router at the boundary between an IPv6 DSTM domain and an IPv4-only domain. Z will designate an IPv4-only node and Z4 its address. ==> means an IPv6 packet --> means an IPv4 packet ++> means a tunneled IPv4 packet is encapsulated in an IPv6 packet ..> means a DNS query or response. The path taken by this packet does not matter in the examples "a" means the DNS name of a node This example describes the case where an application running on a dual IPv6/IPv4 node (X6) wants to establish a session with an IPv4 application (Z4). The IPv4 routing table of node X is configured to send IPv4 packets to the nodes Dynamic Tunnel Interface (DTI) interface. draft-bound-dstm-exp-00.txt Expires February 2004 [Page 7] Internet Draft Dual Stack Transition Mechanism August 2003 DSTM Server DNS X6 Y6/Y4 Z4 | | | |. . . . . . . .> Z | - IPv4 application asks the DNS for the A | | | RR for "Z". (IPv6 application asks the | | | DNS for the AAAA RR fo "Z".) | | | |<. . . . . . . . Z4 | - the answer is Z4 (or IPv4-mapped IPv6 | | | ::FFFF:Z4). | | | | | | - The IPv4 application sends its first | | | IPv4 packet which arrives to the DTI | | | interface. (The IPv6 application | | | can do this through an IPv4-mapped | | | address). | | | | | | - X6 needs an IPv4 address (first use) |====> | | - X6 queries the DSTM server for an | | | IPv4 address |<==== | | - The DSTM server locates the client | | | and provides a temporary IPv4 | | | global address and the IPv6 TEP address. |+++++++++++>| | - The DTI sends the IPv6 packet to the | | | TEP. | |----------->| - Y sends the packet to the destination Z4 | | | - Y caches the association | |<-----------| - Z4 answers. | | | |<+++++++++++| | - Y uses the mapping between X4 and X6 | | | to tunnel the packet to the destination When Z responds the packet returns back through Y. Y having cached the association between the IPv4 and the IPv6 address of X, is able to send the packet encapsulating the IPv4 packet within IPv6 back to X. 5. DSTM Client A DSTM client requires the implementation of a DSTM Server Access Module and a Dynamic Tunnel Interface. 5.1 DSTM Server Access Module A DSTM Server Access Module connects to the DSTM Server to obtain an IPv4 address and TEP. DSTM recommends the use of a DHCPv6 client implementation or using the Tunnel Setup Protocol (TSP) [see Appendix C], also used in the Tunnel Broker [3], The DSTM client may also receive an expiration life time for that IPv4 address, which when expired the DSTM client cannot continue to use that IPv4 address. draft-bound-dstm-exp-00.txt Expires February 2004 [Page 8] Internet Draft Dual Stack Transition Mechanism August 2003 The DSTM client must not perform any Dynamic upates to the DNS [4] for any IPv4 address returned to the DSTM Server Access Module. The TEP can also be manually configured on the DSTM client. 5.2 DSTM Dynamic Tunnel Interface (DTI) The DSTM client implementation after obtaining an IPv4 address and TEP configures its DTI to send an IPv4 packet to the IPv6 TEP of a DSTM border router, and receive IPv4 packets from an IPv6 TEP for an IPv4 application on a DSTM client. 6. DSTM Server A DSTM server implementation requires the implementation of a DSTM Client Access Module, Address Pool Access Module, and Routing Information Access Module. 6.1 DSTM Client Access Module The DSTM Client Access Module is required to accept requests from DSTM clients for an IPv4 address and TEPs, and then return an IPv4 address and TEPs to the DSTM client. DSTM recommends the use of a DHCPv6 server implementation or Tunnel Broker as the DSTM Client Access Module. 6.2 DSTM Address Pool Access Module The DSTM Address Pool Module is required to maintain a pool of IPv4 addresses for DSTM clients and maintain the lifetimes for those addresses. The lifetime for those IPv4 addresses can be provided to the DSTM client with the IPv4 address and TEPs. 6.3 DSTM Routing Information Access Module The DSTM Routing Information Access Module is required to learn or manually configure the TEPs within the DSTM domain to provide TEPs to the DSTM clients. 7. DSTM Border Router The DSTM border router is required to be able to receive IPv6 packets from DSTM clients and then decapsulate the inner IPv4 packets and send to the IPv4 destination address in the IPv4 packets. The DSTM draft-bound-dstm-exp-00.txt Expires February 2004 [Page 9] Internet Draft Dual Stack Transition Mechanism August 2003 border router is required to maintain the IPv6 address of the DSTM clients that send IPv6 packets with IPv4 encapsulated, so IPv4 packets sent to the DSTM clients IPv4 address can be tunneled back to the DSTM client. 8. Applicability Statement DSTM is applicable for use from within a DSTM Domain in which hosts need to communicate with IPv4-only hosts or through IPv4-only applications on a user Intranet or over the Internet. The motivation of DSTM is to allow dual IP layer nodes to communicate using global IPv4 addresses across an Intranet or Internet, where global addresses are required. However, the mechanisms used in DSTM can also be deployed using private IPv4 addresses to permit the Intranet use of DSTM where users require temporary access to IPv4 services within their Intranet. In DSTM, a mechanism is needed to perform the address allocation process. This can be decoupled in two functions: the management of the IPv4 address pool and the communication protocol between server and clients. A number of mechanisms, like DHCPv6, can perform these functions. The exact capacities of the DTI required by DSTM is implementation defined. Optionally, it is allowed that DSTM nodes configure manually (in a static manner) the tunnel to the TEP; but the recommendation is not to do this. The dynamic configuration of DTI as a result of the address allocation process is the right way to execute DSTM on an IPv6 Network. DSTM also assumes that all packets returning from an IPv4 node to a DSTM node are routed through the originating DSTM TEP who maintains the association of the DSTM client 's IPv4/IPv6 addresses. At this time it is beyond the scope of this proposal to permit IPv4 packets destined to a DSTM node to be forwarded through a non-originating DSTM TEP. 9. Security Considerations The DSTM mechanism can use all of the defined security specifications for each functional part of its operation. For DNS, the DNS Security Extensions/Update can be used. Concerning address allocation, when connections are initiated by the DSTM nodes, the risk of Denial of Service attacks (DOS) based on address pool exaustion is limited since DSTM is configured in an Intranet environement. In this scenario, If DHCPv6 is deployed, the DHCPv6 Authentication Message can be used too. Also, since the TEPs are inside an Intranet, they can not be used as an open relay. Finally, for IPv4 communications on DSTM nodes, once the node has an IPv4 address, IPsec can be used since DSTM does not break secure end-to-end communications at any point. Also TSP can be used with the Transport Layer Security protocol over a VPN. draft-bound-dstm-exp-00.txt Expires February 2004 [Page 10] Internet Draft Dual Stack Transition Mechanism August 2003 Appendix A DHCPv6 Options for DSTM Network Working Group B. Volz Internet-Draft Ericsson Expires: October 24, 2002 J. Bound Compaq Computer Corporation R. Droms Cisco Systems T. Lemon Nominum, Inc. April 25, 2002 DSTM Options for DHCP draft-ietf-dhc-dhcpv6-opt-dstm-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 October 24, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract The DSTM Global IPv4 Address option and the DSTM Tunnel Endpoint Option provide DSTM (Dual Stack Transition Mechanism) configuration information to DHCPv6 hosts. 1. Introduction This document describes two options for DHCPv6 [2] that provide information for hosts using the "Dual Stack Transition Mechanism" (DSTM) [3]. 2. Requirements draft-bound-dstm-exp-00.txt Expires February 2004 [Page 11] Internet Draft Dual Stack Transition Mechanism August 2003 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC2119 [1]. 3. Terminology This document uses terminology specific to IPv6 and DHCPv6 as defined in section "Terminology" of the DHCPv6 specification. 4. Identity Association for DSTM Global IPv4 Addresses The Identity Association for DSTM Global IPv4 Addresses (IA_DSTM) option is used to carry an IA, the parameters associated with the IA and the addresses associated with the IA. All of the addresses in this option are used by the client as DSTM Global IPv4 Addresses [3]. The format of the IA_DSTM option is: 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_DSTM | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IAID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . IA-options . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code: OPTION_IA_DSTM (TBD) option-len: 12 + length of IA-options field IAID: The unique identifier for this IA; the IAID must be unique among the identifiers for all of this client's IAs T1: The time at which the client contacts the server from which the addresses in the IA were obtained to extend the lifetimes of the addresses assigned to the IA; T1 is a time duration relative to the current time expressed in units of seconds T2: The time at which the client contacts any available server to extend the lifetimes of the addresses assigned to the IA; T2 is a time duration relative to the current time expressed in units of seconds IA-options: Options associated with this IA. The IA-options field encapsulates those options that are specific to this IA. For example, all of the Address Options carrying the addresses associated with this IA are in the IA-options field. draft-bound-dstm-exp-00.txt Expires February 2004 [Page 12] Internet Draft Dual Stack Transition Mechanism August 2003 An IA_DSTM option may only appear in the options area of a DHCP message. A DHCP message may contain multiple IA_DSTM options. The status of any operations involving this IA is indicated in a Status Code option in the IA-options field. Note that an IA has no explicit "lifetime" or "lease length" of its own. When the lifetimes of all of the addresses in an IA have expired, the IA can be considered as having expired. T1 and T2 are included to give servers explicit control over when a client recontacts the server about a specific IA. In a message sent by a client to a server, values in the T1 and T2 fields indicate the client's preference for those parameters. The client may send 0 if it has no preference for T1 and T2. In a message sent by a server to a client, the client MUST use the values in the T1 and T2 fields for the T1 and T2 parameters. The values in the T1 and T2 fields are the number of seconds until T1 and T2. The server selects the T1 and T2 times to allow the client to extend the lifetimes of any addresses in the IA before the lifetimes expire, even if the server is unavailable for some short period of time. Recommended values for T1 and T2 are .5 and .8 times the shortest preferred lifetime of the addresses in the IA, respectively. If the server does not intend for a client to extend the lifetimes of the addresses in an IA, the server sets T1 and T2 to 0. T1 is the time at which the client begins the lifetime extension process by sending a Renew message to the server that originally assigned the addresses to the IA. T2 is the time at which the client starts sending a Rebind message to any server. T1 and T2 are specified as unsigned integers that specify the time in seconds relative to the time at which the messages containing the option is received. A DSTM Tunnel End Point option (Section 5) MAY be encapsulated in an IA_DSTM option to specify one or more tunnel endpoints. 5. DSTM Tunnel Endpoint Option The DSTM Tunnel Endpoint option carries an IP address that is to be used as a tunnel endpoint (TEP) to encapsulate IP datagrams within IP. The format of the DSTM Tunnel Endpoint option is: 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_DSTM_TEP | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . tep . . (16 octets) . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code: OPTION_DSTM_TEP (TBD) draft-bound-dstm-exp-00.txt Expires February 2004 [Page 13] Internet Draft Dual Stack Transition Mechanism August 2003 option-length: 16 tep: Tunnel endpoint A DSTM Tunnel EndPoint Option MUST NOT be used except when encapsulated in an IA_DSTM option. 6. Appearance of these options The IA_DSTM option may appear in the same messages as the IA option and the IA_TA option [2]. A server may send a Reconfigure with an IA_DSTM option number in the Option Request option (see sections 19 and 22.7 of the DHCP specification [2]) to request that the client send a IA_DSTM option, with an IAID, in the Renew message the client subsequently sends to the server. The DSTM Tunnel Endpoint option MUST only appear as an encapsulated option in an IA_DSTM option. 7. Security Considerations The DSTM Global IPv4 Address option may be used by an intruder DHCP server to assign an invalid IPv4-mapped address to a DHCPv6 client in a denial of service attack. The DSTM Tunnel Endpoint option may be used by an intruder DHCP server to configure a DHCPv6 client with an endpoint that would cause the client to route packets thorugh an intruder system. To avoid these security hazards, a DHCPv6 client MUST use authenticated DHCPv6 to confirm that it is exchanging the DSTM options with an authorized DHCPv6 server. 8. IANA Considerations IANA is requested to assign an option code to this option from the option-code space defined in section "DHCPv6 Options" of the DHCPv6 specification [2]. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R. Droms (ed.), "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc-dhcpv6 (work in progress), April 2002. [3] Bound, J., "Dual Stack Transition Mechanism (DSTM)", draft-ietf- ngtrans-dstm (work in progress), November 2001. [4] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. Authors' Addresses draft-bound-dstm-exp-00.txt Expires February 2004 [Page 14] Internet Draft Dual Stack Transition Mechanism August 2003 Bernie Volz Ericsson 959 Concord Street Framingham, MA 01701 USA Phone: +1 508 875 3162 EMail: bernie.volz@ericsson.com Jim Bound Hewlett Packard ZK3-3/W20 110 Spit Brook Road Nashua, NH 03062-2698 USA Phone: +1 603 884 0062 EMail: Jim.Boundhp.com Ralph Droms Cisco Systems 250 Apollo Drive Chelmsford, MA 01824 USA Phone: +1 978 497 4733 EMail: rdroms@cisco.com Ted Lemon Nominum, Inc. 950 Charter Street Redwood City, CA 94043 USA EMail: mellon@nominum.com draft-bound-dstm-exp-00.txt Expires February 2004 [Page 15] Internet Draft Dual Stack Transition Mechanism August 2003 Appendix B DSTM Port Options for DHCPv6 Network Working Group Myung-Ki Shin Internet-Draft ETRI Expires: December 2002 June 2002 DSTM Ports Option for DHCPv6 draft-ietf-dhc-dhcpv6-opt-dstm-ports-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 docu- ments at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in pro- gress." 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 August 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract The DSTM Ports Option provides DSTM (Dual Stack Transition Mechanism) configuration information to DHCPv6 hosts. 1. Introduction This document describes the Ports Option for DHCPv6 [2] that provide information for hosts using the "Dual Stack Transition Mechanism" (DSTM) [3]. 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 RFC 2119 [1]. draft-bound-dstm-exp-00.txt Expires February 2004 [Page 16] Internet Draft Dual Stack Transition Mechanism August 2003 3. Terminology This document uses terminology specific to IPv6 and DHCPv6 as defined in section "Terminology" of the DHCPv6 specification. 4. DSTM Ports Option The DSTM Ports option carries a port range that is to be used for the associated IPv4-mapped IPv6 address in an IA_DSTM option [5]. The format of the DSTM Ports option is: 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_DSTM_PORTS | option-length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | start port | end port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code: OPTION_DSTM_PORTS (TBD) option-length: 4 start port: The start port number for the associated IPv4- mapped IPv6 address. end port: The end port number for the associated IPv4- mapped IPv6 address. A DSTM Ports option MAY be encapsulated in an IA_DSTM option [5] to specify the port range associted with the IPv4-mapped IPv6 address. A DSTM Ports option MUST NOT be used except when encapsulated in an IA_DSTM option [5]. 5. Appearance of these options The DSTM Ports option MUST only appear as an encapsulated option in an IA_DSTM option [5]. 6. Security Considerations The DSTM Ports option may be used by an intruder DHCP server to assign an invalid port range to a DHCP client in a denial of service attack. To avoid this security hazard, a DHCP client MUST use authenticated DHCP to confirm that it is exchanging the DSTM options with an authorized DHCP server. 7. IANA Considerations IANA is requested to assign an option code to this option from the draft-bound-dstm-exp-00.txt Expires February 2004 [Page 17] Internet Draft Dual Stack Transition Mechanism August 2003 option-code space defined in section "DHCP Option" of the DHCPv6 specification [2]. References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R. Droms (ed.), "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc-dhcpv6-26 (work in progress), June 2002. [3] Bound, J., "Dual Stack Transition Mechanism (DSTM)", draft-ietf- ngtrans-dstm-07 (work in progress), Feburary 2002. [4] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [5] Volz, B. et al., "DSTM Options for DHCPv6", draft-ietf-dhc-dhcpv6- opt-dstm-01.txt, (work in progress), April 2002. Authors' Addresses Myung-Ki Shin ETRI PEC 161 Kajong-Dong, Yusong-Gu, Taejon 305-350, Korea Tel : +82 42 860 4847 Fax : +82 42 861 5404 E-mail : mkshin@pec.etri.re.kr Appendix C Tunnel Setup Protocol (TSP) Network Working Group M. Blanchet Internet-Draft Viagenie Expires: December 30, 2002 O. Medina ENST Bretagne F. Parent Viagenie July 1, 2002 DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup Protocol(TSP) draft-blanchet-ngtrans-tsp-dstm-profile-01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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- draft-bound-dstm-exp-00.txt Expires February 2004 [Page 18] Internet Draft Dual Stack Transition Mechanism August 2003 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 December 30, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract Based on the actions they perform, The network model presented in DSTM [1] defines three types of equipments: a DSTM server, DSTM nodes and a Tunnel End Point (TEPs). Within this model, a protocol is required for configuration data exchange among these equipments. This document presents a method to perform these actions based on TSP [2]. Blanchet, et al. Expires December 30, 2002 [Page 1] Internet-Draft DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup Protocol(TSP) July 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. General Description of the Protocol . . . . . . . . . . . . . 4 2.1 Initial Address Allocation . . . . . . . . . . . . . . . . . . 5 2.2 Allocation Renewal . . . . . . . . . . . . . . . . . . . . . . 6 2.3 End of Allocation . . . . . . . . . . . . . . . . . . . . . . 7 3. TSP Profile for DSTM . . . . . . . . . . . . . . . . . . . . . 7 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Client element . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3 Server element . . . . . . . . . . . . . . . . . . . . . . . . 8 4. DSTM protocol using TSP . . . . . . . . . . . . . . . . . . . 8 4.1 Initial Address Allocation . . . . . . . . . . . . . . . . . . 8 4.2 Allocation Renewal . . . . . . . . . . . . . . . . . . . . . . 9 4.3 End of Allocation . . . . . . . . . . . . . . . . . . . . . . 11 5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 draft-bound-dstm-exp-00.txt Expires February 2004 [Page 19] Internet Draft Dual Stack Transition Mechanism August 2003 A. Appendix A. IPv4 over IPv6 tunnel DTD . . . . . . . . . . . . 13 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15 Blanchet, et al. Expires December 30, 2002 [Page 2] Internet-Draft DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup Protocol(TSP) July 2002 1. Introduction Based on the actions they perform, The network model presented in DSTM [1] defines three types of equipments: a DSTM server, DSTM nodes and a Tunnel End Point (TEPs). Within this model, a protocol is required for configuration data exchange among these equipments. This document presents a method to perform these actions based on TSP [2]. The Tunnel Setup Protocol, TSP, is a protocol designed to negotiate tunnel information, such as IP addresses, network prefixes and routing information. TSP provides optional authentication, transport over IPv6 and redundancy of the service. Other protocols, such as DHCPv6 [4], can be used to deploy DSTM but, in the short term, such protocols may be more complex to implement. The use of TSP for DSTM address allocation and tunnel set up demands the definition of four types of messages: o 'Tunnel Create' messages are used to request the establishment of a 4over6 tunnel between a node and a given TEP. For first-time draft-bound-dstm-exp-00.txt Expires February 2004 [Page 20] Internet Draft Dual Stack Transition Mechanism August 2003 requests, tunnel creation implies the allocation of a temporary IPv4 address to the requesting node. In addition, this type of message is also used to ask for extension of the validity of an already allocated address. o 'Tunnel Delete' messages are sent by the server to destroy an existing 4over6 tunnel. The server MUST send this type of message to the client (and to the TEP, if server and TEP are not co- located) when the allocation timer for a given address expires. o 'Tunnel Info' messages are sent as a reply to Tunnel Create or Tunnel Delete requests. This type of message may contain configuration data to be used by a node, or simply confirm the creation/deletion of a 4over6 tunnel. o Finally, Error Messages inform about the impossibility to allocate a temporary address or establish a 4over6 tunnel. TSP provides authentication services using SASL [5]. If DSTM client authentication is required, the DSTM server can be configured to negotiate with the client the authentication scheme that will be used. In this mode, only authenticated clients are authorized to receive an IPv4 address. If no authentication is required, the ANONYMOUS authentication scheme can be used to allow any client to receive a temporary IPv4 address. Blanchet, et al. Expires December 30, 2002 [Page 3] Internet-Draft DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup Protocol(TSP) July 2002 2. General Description of the Protocol Figure 2.1 presents the message exchanges required by DSTM when the allocation process is started by a DSTM node. In this document we do not explain the different mechanisms that can be put in place to detect the need of an IPv4 address in a Dual Stack node. As required by DSTM, all TSP message exchanges take place in IPv6 using TCP transport. Remark that exchanges between DSTM Servers and TEPs are not required if both functionalities are implemented in the same host. The allocation process greatly depends on a parameter called "Lifetime". It specifies the time (in seconds) over which an IPv4 address is assigned to a node, defining implicitly how often requests for allocation renewals are to be sent. TSP message exchange starts whenever a DSTM node requires an IPv4 address. The node may start the exchange, but it may also be possible that DSTM servers send Unsolicited Allocation messages to nodes. This would be useful for implementations where it is allowed to originate connections from outside the DSTM domain (probably using a DNS-ALG). The exact description of this possibility is outside the draft-bound-dstm-exp-00.txt Expires February 2004 [Page 21] Internet Draft Dual Stack Transition Mechanism August 2003 scope of this document. Blanchet, et al. Expires December 30, 2002 [Page 4] Internet-Draft DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup Protocol(TSP) July 2002 Address Allocation Process using SAAP DSTM node DSTM Server TEP | | | | Tunnel Create | | |------------------>| | | | Tunnel Create | | |------------------>| | | Tunnel Info | | Tunnel Info |<------------------| |<------------------| | | | | | 4over6 tunnel | |<=====================================>| | | | | Tunnel Create | | |------------------>| | | Tunnel Info | | |<------------------| | | | | . . . . . . draft-bound-dstm-exp-00.txt Expires February 2004 [Page 22] Internet Draft Dual Stack Transition Mechanism August 2003 . . . | Tunnel Delete | Tunnel Delete | |<------------------|------------------>| | | | | Tunnel Info | Tunnel Info | |..................>|<..................| | | | As shown in the figure, DSTM makes use of three types of TSP message: Create, Delete and Info. 'Tunnel Create' messages are sent by a DSTM node to ask for 4over6 Tunnel Configuration Parameters (implicitly including the request for a temporary IPv4 address). The same type of message is used by the DSTM server to configure the TEP and by the DSTM node to ask for renewal of the allocation. 'Tunnel Info' messages are usually sent as a reply to a previous 'Tunnel Create' request. Such a message may also be used to acknowledge the reception of a 'Tunnel Delete' command. Finally, DSTM servers send 'Tunnel Delete' messages to destroy 4over6 tunnels when the allocation time for an address expires. 2.1 Initial Address Allocation As described in TSP [2], the first phase in TSP involves authentication (which can be ANONYMOUS). If authentication fails, an 'Authentication Failure' error message (type 300) is generated and no Blanchet, et al. Expires December 30, 2002 [Page 5] Internet-Draft DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup Protocol(TSP) July 2002 address is allocated to the requesting node. If authentication succeeds, TSP enters into command phase and the allocation process can take place. As shown on figure 2.1, the address allocation process starts when a DSTM node sends a 'Tunnel Create' request to the DSTM Server. This message contains the Link-Local address of the node and the Global IPv6 address that the node would use to establish the 4over6 tunnel. No other information is needed. Next, the DSTM server processes the request. It may result in an error due to Address Pool exhaustion (error type 306). If an IPv4 address is available, the server configures the TEP using another 'Tunnel Create' message. The message includes the global IPv6 and the allocated IPv4 addresses of the requesting node. The TEP MUST be configured to accept TSP messages only from a valid DSTM server. At the arrival of a 'Tunnel Create' Request, the TEP updates its IPv4/IPv6 mapping table and sets up the 4over6 tunnel as requested. If, for some reason, it is not possible to update the table, or the 4over6 tunnel cannot be set up, the TEP replies with an error message (error type 307). In that case, the DSTM server SHOULD forward the error message to the requesting node. draft-bound-dstm-exp-00.txt Expires February 2004 [Page 23] Internet Draft Dual Stack Transition Mechanism August 2003 If tunnel configuration succeeds, the DSTM server receives a 'Tunnel Info' message from the TEP. This message contains the IPv6 and IPv4 addresses of the TEP for the new tunnel. At this point, the server updates its own tables and sends a 'Tunnel Info' message to the requesting node. This message contains the temporary IPv4 address of the node, its period of validity (the 'Life Time') and address information of the TEP. TEP information MUST be the same that the TEP provided. Finally, the IPv4 stack of the node is configured. A 4over6 tunnel is established between the node and the TEP. An IPv4 default route is added pointing to the 4over6 tunnel. Communication in IPv4 can take place. A timer configured with the 'Life Time' parameter informs the node when to ask for renewal of allocation, if needed. 2.2 Allocation Renewal As long as an IPv4 address is needed at the node, 'Tunnel Create' messages are sent to the DSTM Server as a request for allocation renewal. The frequency of such requests depends on the 'Life Time' parameter. The temporary IPv4 address for which allocation renewal is requested MUST be included in the messages. Blanchet, et al. Expires December 30, 2002 [Page 6] Internet-Draft DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup Protocol(TSP) July 2002 Based on the contents of the message and local policy, the server may reply with a 'Tunnel Info' message. At the node, the reception of such a message means that allocation time has been extended: the timer is reset to the value contained in the 'Life Time' field. No modification is needed in the IPv4 stack nor in the TEP. If allocation cannot be extended, an error message MUST be sent to the node (error type 308) and tunnel information MUST be deleted at the TEP. 2.3 End of Allocation If properly configured, there will be a time where the node will no longer need an IPv4 address. At this time, it will stop sending 'Tunnel Create' requests for renewal. At the server, when allocation time expires, a 'Tunnel Delete' message MUST be sent to both the node and the corresponding TEP. The server SHOULD NOT wait for an acknowledge from the node before updating its own tables and deleting the configuration at the TEP. However, implementations may wait until the server receives a reply before releasing the address. A 'Tunnel Delete' message contains the IPv4 and IPv6 addresses of the node for which the entry in the mapping table is to be deleted. The TEP MUST stop forwarding packets for that node as a reaction to this type of message. Depending on implementation, TEPs may acknowledge tunnel deletion using a 'Tunnel Info' message. draft-bound-dstm-exp-00.txt Expires February 2004 [Page 24] Internet Draft Dual Stack Transition Mechanism August 2003 3. TSP Profile for DSTM This section describes the TSP profile for IPv4 over IPv6 tunnels in DSTM. 3.1 Overview The TSP profile uses the included DTD for the XML format of the message. The DTD (c.f. Annexe) contains the description of the tunnel XML message. This message is used by a TSP-DSTM compliant server to provide the necessary information to DSTM nodes and the TEP in order to establish 4over6 tunnels. Three types of action are defined in a 'tunnel' message: Create, Delete and Info. The 'Create' action is used to request a new tunnel or to renew an address allocation. The 'Delete' action is used by the server to remove an existing tunnel from a node and the TEP. The 'Info' action is used by the server to send tunnel configuration data. It is also used by nodes and the TEP to acknowledge a previous Blanchet, et al. Expires December 30, 2002 [Page 7] Internet-Draft DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup Protocol(TSP) July 2002 command (Create or Delete). The 'tunnel' message may have one or two elements: o client: Client's information o server: Server's information Server is used in the context of the other party in the TSP connection. It can be the DSTM server if the client is the DSTM node, or the TEP if the client is the DSTM server. 3.2 Client element The client element contains 'address' elements. The 'address' element is used to identify the client IPv6 endpoint of the 4over6 tunnel. The client MUST send its link- local and global IPv6 addresses to the server. The server will then return a temporary IPv4 address inside the 'client' element when the tunnel is created or allocation is renewed. 3.3 Server element The 'server' element contains 'address' elements. This element is used to identify the addresses at the TEP. The 'address' element provides both IPv4 and IPv6 addresses of the TEP. draft-bound-dstm-exp-00.txt Expires February 2004 [Page 25] Internet Draft Dual Stack Transition Mechanism August 2003 4. DSTM protocol using TSP TSP message exchanges are done using TCP over IPv6 transport. Once the TCP session is established between the DSTM node and server, it MAY be kept connected for the duration of the address allocation lease time. This TCP connection can be used by the server to send requests to the client on a communication channel already established (and potentially authenticated) by the client. This section presents an example of a DSTM host requesting an IPv4 address allocation to a DSTM server. As described in TSP[ref], the first TSP phase involves authentication (which can be ANONYMOUS) followed by a command phase that takes care of the allocation negotiation. 4.1 Initial Address Allocation Allocation Requests coming from a node consist of a 'tunnel' element using the attributes action set to 'create' and type set to 'v4v6'. The 'tunnel' element contains one 'client' element. Blanchet, et al. Expires December 30, 2002 [Page 8] Internet-Draft DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup Protocol(TSP) July 2002 Simple tunnel request made by a client. -- Successful TCP Connection -- C:VERSION=1.0 CR LF S:CAPABILITY TUNNEL=V4V6 AUTH=DIGEST-MD5 AUTH=ANONYMOUS CR LF C:AUTHENTICATE ANONYMOUS CR LF S:OK Authentication successful CR LF C:Content-length: 228 CR LF
fe80:0000:0000:0000:0000:0000:0000:0001
3ffe:0b00:0c18:ffff:0000:0000:0000:0001
 CR LF If the allocation request is accepted, the DSTM server will acknowledge the allocation to the client by sending a 'tunnel' element with the attribute 'action' set to 'info', 'type' set to 'v4v6' and the 'lifetime' attribute set to the period of validity or lease time of the allocation. The 'tunnel' element contains 'server' and 'client' elements. Server response draft-bound-dstm-exp-00.txt Expires February 2004 [Page 26] Internet Draft Dual Stack Transition Mechanism August 2003 S: Content-length: 370 CR LF 200 OK CR LF
206.123.31.2
3ffe:b00:c18:ffff:0000:0000:0000:0002
206.123.31.1
3ffe:b00:c18:ffff::0000:0000:0000:0001
 CR LF 4.2 Allocation Renewal A DSTM host asks for renewal of an IPv4 address allocation by sending a 'Tunnel Create' message to a DSTM server. The request consists of a 'tunnel' element using the attributes action set to 'create' and Blanchet, et al. Expires December 30, 2002 [Page 9] Internet-Draft DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup Protocol(TSP) July 2002 type set to 'v4v6'. The 'tunnel' element contains one 'client' element. The temporary IPv4 address for which allocation renewal is requested MUST be included in the messages. Renewal of the same client C:Content-length: 228 CR LF
fe80:0000:0000:0000:0000:0000:0000:0001
3ffe:0b00:0c18:ffff:0000:0000:0000:0001
206.123.31.1
 CR LF If the allocation request is accepted, the DSTM server will acknowledge the renewal to the client by sending a 'tunnel' element with the attribute 'action' set to 'info', 'type' set to 'v4v6' and the 'lifetime' attribute set to the period of validity or lease time of the allocation. No message is sent to the TEP in this case. At the node, the reception of such a message means that allocation time has been extended; the timer is reset to the value contained in the draft-bound-dstm-exp-00.txt Expires February 2004 [Page 27] Internet Draft Dual Stack Transition Mechanism August 2003 'lifetime' field. Server's response to the renewal S: Content-length: 370 CR LF 200 OK CR LF
206.123.31.2
3ffe:b00:c18:ffff:0000:0000:0000:0002
206.123.31.1
3ffe:b00:c18:ffff::0000:0000:0000:0001
 CR LF Blanchet, et al. Expires December 30, 2002 [Page 10] Internet-Draft DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup Protocol(TSP) July 2002 4.3 End of Allocation A DSTM server uses a 'Tunnel Delete' message to end the IPv4 address allocation of a client. The release request consists of a 'tunnel' element using the attributes action set to 'delete' and type set to 'v4v6'. The 'tunnel' element contains 'server' and 'client' elements representing the address allocation that is released. Server sending a release request S: Content-length: 370 CR LF 200 OK CR LF
206.123.31.2
3ffe:b00:c18:ffff:0000:0000:0000:0002
206.123.31.1
3ffe:b00:c18:ffff::0000:0000:0000:0001
 CR LF 5. Error Codes This list describes the error codes used in this document. 300 Authentication failed 306 Address Pool Exhausted 307 Configuration Error at TEP 308 Requested Address Unavailable 309 Invalid IPv6 address 310 IPv4 Invalid Address 6. IANA Considerations The TUNNELTYPE "v4v6" is registered for this document. Blanchet, et al. Expires December 30, 2002 [Page 11] Internet-Draft DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup Protocol(TSP) July 2002 7. Security TSP provides authentication services using SASL [RFC2222]. If DSTM client authentication is required, TSP can be configured at the server to negotiate with the client the authentication scheme that will be used. In the context where the server sends a request to the client, some form of authentication is required so that the client can be sure that the request comes from a trusted DSTM server. This document proposes that in the case where the client initially authenticates to the DSTM server, this TCP session MAY be kept connected for the duration of the address allocation lease time. This TCP connection can be used by the server to send requests to the client on a communication channel already established by the client. A more secure solution would be to provide mutual authentication between the parties. References [1] Bound, J., "Dual Stack Transition Mechanism (DSTM)", draft-ietf- ngtrans-dstm-05 (work in progress), November 2001. draft-bound-dstm-exp-00.txt Expires February 2004 [Page 29] Internet Draft Dual Stack Transition Mechanism August 2003 [2] Blanchet, M., "Tunnel Setup Protocol", July 2001. [3] Hagino, J., "Possible abuse against IPv6 transition technologies", July 2000. [4] Droms, R., Perkins, C., Bound, J. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc- dhcpv6-21 (work in progress), November 2001. [5] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. Authors' Addresses Marc Blanchet Viagenie 2875 boul. Laurier, bureau 300 Sainte-Foy, QC G1V 2M2 Canada Phone: +1 418 656 9254 EMail: Marc.Blanchet@viagenie.qc.ca URI: http://www.viagenie.qc.ca/ Blanchet, et al. Expires December 30, 2002 [Page 12] Internet-Draft DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup Protocol(TSP) July 2002 Octavio Medina ENST Bretagne BP 78 Cesson Sevigne, Cedex 35512 France Phone: +33 2 99 12 70 23 EMail: Octavio.Medina@enst-bretagne.fr URI: http://www.enst-bretagne.fr Florent Parent Viagenie 2875 boul. Laurier, bureau 300 Sainte-Foy, QC G1V 2M2 Canada Phone: +1 418 656 9254 EMail: Florent.Parent@viagenie.qc.ca URI: http://www.viagenie.qc.ca/ Appendix A. Appendix A. IPv4 over IPv6 tunnel DTD draft-bound-dstm-exp-00.txt Expires February 2004 [Page 30] Internet Draft Dual Stack Transition Mechanism August 2003 Blanchet, et al. Expires December 30, 2002 [Page 13] Internet-Draft DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup Protocol(TSP) July 2002 DTD ]> Blanchet, et al. Expires December 30, 2002 [Page 14] draft-bound-dstm-exp-00.txt Expires February 2004 [Page 31] Internet Draft Dual Stack Transition Mechanism August 2003 Internet-Draft DSTM IPv4 over IPv6 tunnel profile for Tunnel Setup Protocol(TSP) July 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). 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 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. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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 Funding for the RFC Editor function is currently provided by the Internet Society. Blanchet, et al. Expires December 30, 2002 [Page 15] draft-bound-dstm-exp-00.txt Expires February 2004 [Page 32] Internet Draft Dual Stack Transition Mechanism August 2003 Full Copyright Statement Copyright (C) The Internet Society (2002). 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 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. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgments The authors would like to thank the following persons for their hard work to build the DSTM options in DHCPv6 as follows: Ted Lemon, Ralph Droms, Myung-Ki Shin, and Bernie Volz. References Normative References [1] Droms, R. (ed) "Dynamic Host Configuration Protocol" RFC 2131, March 1997. [2] Droms. R. (ed) et. al. "Dynamic Host Configuration Protocol for IPv6 (DHCPv6), RFC 3315, July 2003. [3] Durand, Fasano, Guardini, and Lento, "IPv6 Tunnel Broker" RFC 3053, January 2001. [4] Vixie P. (ed) et. al. "Dynamic Updates in the Domain Name System, RFC 2136, April 1997. draft-bound-dstm-exp-00.txt Expires February 2004 [Page 33] Internet Draft Dual Stack Transition Mechanism August 2003 Authors Addresses Jim Bound Hewlett Packard ZK3-3/W20 110 Spit Brook Road Nashua, NH 03062-2698 USA Phone: +1 603 884 0062 EMail: Jim.Boundhp.com Laurent Toutain ENST Bretagne BP 78 35512 Cesson Sevigne Cedex, FR. Phone : +33 2 99 12 70 26 Email : Laurent.Toutain@enst-bretagne.fr Octavio Medina ENST Bretagne BP 78 35512 Cesson Sevigne Cedex, FR. Phone : +33 2 99 12 70 23 Email : Octavio.Medina@enst-bretagne.fr Francis Dupont ENST Bretagne BP 78 35 512 Cesson Sevigne Cedex, FR. Phone : +33 2 99 12 70 33 Email : Francis.Dupont@enst-bretagne.fr Myung-Ki Shin ETRI PEC 161 Kajong-Dong, Yusong-Gu, Taejon 305-350, Korea Phone: +82 42 860 4847 Fax : +82 42 861 5404 E-mail : mkshin@pec.etri.re.kr Jaehwoon Lee Dongguk University 26, 3 Pil-dong, Chung-gu, Seoul, 100-715, Korea Phone: +82-2-22603849 Email : jaehwoon@dongguk.edu Hee-Cheol Lee ETRI PEC 161 Gajong-Dong, Yusong-Gu, Daejon 305-350, Korea Phone: +82 42 860 1833 Email: hclee_shep@etri.re.kr Eva Castro Universidad Rey Juan Carlos Escuela Superior de Ciencias Experimentales Tecnologia Departamento de Informatica, Estadistica y Telematica C/ Tulipan s/n - 28933 Mostoles - Madrid SPAIN E-mail: eva@gsyc.escet.urjc.es draft-bound-dstm-exp-00.txt Expires February 2004 [Page 34]