Network Working Group M. Blanchet Internet-Draft R. Desmeules Expires: January 11, 2002 A. Cormier Viagenie inc. July 13, 2001 IPv6 over IPv4 profile for Tunnel Setup Protocol (TSP) draft-vg-ngtrans-tsp-v6v4profile-00 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 January 11, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This document proposes a tunnel profile to setup IPv6 over IPv4 tunnels to be used with the Tunnel Setup Protocol (TSP) [9]. Blanchet, editor, et. al. Expires January 11, 2002 [Page 1] Internet-Draft IPv6 over IPv4 profile for TSP July 2001 Table of Contents 1. Rationale for an IPv6 tunnel setup protocol . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Why a Tunnel Setup Protocol . . . . . . . . . . . . . . . . . 4 4. The IPv6 over IPv4 tunnel profile . . . . . . . . . . . . . . 4 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2 Client element . . . . . . . . . . . . . . . . . . . . . . . . 5 4.3 Server element . . . . . . . . . . . . . . . . . . . . . . . . 5 4.4 broker element . . . . . . . . . . . . . . . . . . . . . . . . 5 5. Tunnel request . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1 Host Tunnel request and Reply . . . . . . . . . . . . . . . . 6 5.2 Router Tunnel request with a /48 prefix delegation, and reply 6 5.3 Router Tunnel Request with a /48 prefix delegation and RIP routing, and Reply . . . . . . . . . . . . . . . . . . . . . . 7 5.4 Router Tunnel Request with a /48 prefix delegation and BGP peering, and Reply . . . . . . . . . . . . . . . . . . . . . . 8 6. Error codes . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 8. Security considerations . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11 A. IPv6 over IPv4 tunnel DTD . . . . . . . . . . . . . . . . . . 12 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13 Blanchet, editor, et. al. Expires January 11, 2002 [Page 2] Internet-Draft IPv6 over IPv4 profile for TSP July 2001 1. Rationale for an IPv6 tunnel setup protocol Many IPv6 transition techniques uses tunnelling to overlay an IPv6 network over an IPv4 network. Some are manual, some are automatic like 6to4 by embedding the IPv4 address of the gateway in the IPv6 address, some are semi-automatic like the tunnel broker. The operation of the protocol defined in this document, known as IPv6 Tunnel Setup Protocol, allows dual stack (IPv4/IPv6) nodes to negotiate the establishment of a configured tunnel (IPv6 over IPv4) to a Tunnel Broker according to the IPv6 Tunnel Broker model proposed in RFC 3053 [1] The protocol solves the problem of authentication and the negotiation between any dual stack node and Tunnel Broker by proposing a set of messages to be exchanged between nodes and Tunnel Brokers. However, TSP protocol doesn't try to compete against other transition mechanisms like 6to4. Also, it doesn' t try to solve general problems related to the use of IPv6 over IPv4 networks. In particular, this protocol doesn't solve: o end-users passing through a NAT configured in NAPT , dynamic or port redirection mode to reach Tunnel Server o malicious users trying differents IPv4 addresses loopback addresses, multicast addresses, class E address and broadcast addresses to attemps to crash Tunnel Server 2. Terminology Tunnel Broker (TB) In a Tunnel Broker model, the broker is taking charge of all communication between Tunnel Servers (TS) and Tunnel Clients (TC). Tunnel clients query brokers for a tunnel and the broker find a suitable tunnel server, ask the Tunnel server to setup the tunnel and send the tunnel information to the Tunnel Client. Tunnel Server (TS) Tunnel Servers are providing the specific tunnel service to a Tunnel Client. It can reveive the tunnel request from a Tunnel Broker (as in the Tunnel Broker model) or directly from the Tunnel Client as in the Tunnel Setup Protocol option. Tunnel Client (TC) The Tunnel Client is the entity that need a tunnel for a particular service or connectivity. A Tunnel Client can be a host or a router. Blanchet, editor, et. al. Expires January 11, 2002 [Page 3] Internet-Draft IPv6 over IPv4 profile for TSP July 2001 3. Why a Tunnel Setup Protocol There are current proposals about deploying configured tunnels over IPv4 network. The Tunnel Broker method (RFC3053) [1] intends to use Web browers and servers to allow end-users to request configured tunnel but there is no real negociation between end-user and Tunnel Broker. If end-users use dynamic IPv4 addresses, a manual operation must be done to update the Tunnel Broker. This manual operation implies to be done over a security layer to ensure a secure authentication of end-users. The IPv6 over IPv4 tunnels for home to Internet access method [6] is proposing a secure method to solve the problem of dynamic IP address changes at end-users sides by using neighbor discovery protocol [2] functions and IPsec. This proposed method is dependant of IPsec implementors that have to modify their implementations to handle virtual interfaces for IPv6. A Tunnel Broker implementation with a web interface revealed many practical problems : o Using Web interfaces for Tunnel Broker limits the scalability of deploying IPv6 networks and hosts at very large scale over Internet. Web interface requires manual operation from end-users. o End-users that uses dynamic IPv4 addresses must go back manually to the Tunnel Broker's web interface each time their IPv4 address changes The Tunnel Setup Protocol (TSP) approach proposes a negociation of tunnel parameters between Tunnel clients and Tunnel Servers. The proposed protocol is able to handle different kinds of tunnel over IPv4 such as IPv6 configured tunnel, DVMRP tunnels over IPv4 for multicast and others. In the current document, examples of the protocol are focused on IPv6 configured tunnel. 4. The IPv6 over IPv4 tunnel profile 4.1 Overview This profile uses the included DTD for the xml format of the message. The dtd contains the description of the tunnel XML message. This message is used by the TSP compliant server to provide IPv6 over tunnels service. Action for the specified tunnel is provided in the 'action' atribute of the 'tunnel' message. Valid actions for this profile are : 'create', 'info' and 'delete'. The 'create' action is used to request a new tunnel or update an Blanchet, editor, et. al. Expires January 11, 2002 [Page 4] Internet-Draft IPv6 over IPv4 profile for TSP July 2001 existing tunnel. The 'info' action is used to request current properties of an existing tunnel. The 'delete' action is used to remove an existing tunnel from the server. The 'tunnel' message contains three elements: client Client's information server Server's information broker List of other server's 4.2 Client element The client element contains 2 elements: 'address' and 'router'. These elements are used to describe the client needs and will be used by the server to create the appropriate tunnel. This is the only element sent by a client. The 'address' element is used to identify the client IPv4 endpoint of the tunnel. The client MUST send only an IPv4 address to the server. The server will then return the IPv6 address endpoint and domain name inside the 'client' element when the tunnel is created or updated. Optionaly a client can send a 'router' element to ask for a prefix delegation. The 'router' element contains the 'router protocol' attribute which specify the routing method to be use between the server and the client. If no attribute is specified the the routing will use static routes. Routing method may include 'rip' or 'bgp'. If 'bgp' is used, the client MUST sent a valid AS number within the 'as' element. 4.3 Server element The 'server' element contains 2 elements: 'address' and 'router'. These elements are used to describe the server's tunnel endpoint. The 'address' element is used to provide both IPv4 and IPv6 addresses of the server's tunnel endpoint, while the 'router' element provides information for the routing method choosen by the client. 4.4 broker element The 'broker' element is used by a server to provide a alternate list of servers to a client in the case where the server is not able to provide the requested tunnel. The 'broker' element will contain a series of 'address' element. Blanchet, editor, et. al. Expires January 11, 2002 [Page 5] Internet-Draft IPv6 over IPv4 profile for TSP July 2001 5. Tunnel request This section presents multiple examples of requests. 5.1 Host Tunnel request and Reply A simple tunnel request consist of a 'tunnel' element which contains only an 'address' element Simple tunnel request made by a client. -- Successful TCP Connection -- C:VERSION=1.0 CR LF S:CAPABILITY TUNNEL=V6V4 AUTH=ANONYMOUS CR LF C:AUTHENTICATE ANONYMOUS CR LF S:200 Authentication successful CR LF C:Content-length: 123 CR LF
1.1.1.1
 CR LF S: Content-length: 234 CR LF 200 OK CR LF
206.123.31.114
3ffe:b00:c18:ffff:0000:0000:0000:0000
1.1.1.1
3ffe:b00:c18:ffff::0000:0000:0000:0001
userid.domain
 CR LF 5.2 Router Tunnel request with a /48 prefix delegation, and reply A tunnel request with prefix consist of a 'tunnel' element which contains 'address' element and a 'router' element. Tunnel request with prefix and static routes. C: Content-length: 234 CR LF
1.1.1.1
Blanchet, editor, et. al. Expires January 11, 2002 [Page 6] Internet-Draft IPv6 over IPv4 profile for TSP July 2001
2.3.4.5
2.3.4.6
3ffe:0c00::1
 CR LF S: Content-length: 234 CR LF 200 OK CR LF
206.123.31.114
3ffe:b00:c18:ffff:0000:0000:0000:0000
1.1.1.1
3ffe:b00:c18:ffff::0000:0000:0000:0001
userid.domain
3ffe:0b00:c18:1234::
2.3.4.5
2.3.4.6
3ffe:0c00::1
 CR LF 5.3 Router Tunnel Request with a /48 prefix delegation and RIP routing, and Reply A tunnel request with prefix consist of a 'tunnel' element which contains 'address' element and a 'router' element. Tunnel request with prefix and RIP routing. C: Content-length: 234 CR LF
1.1.1.1
Blanchet, editor, et. al. Expires January 11, 2002 [Page 7] Internet-Draft IPv6 over IPv4 profile for TSP July 2001
2.3.4.5
2.3.4.6
3ffe:0c00::1
 CR LF S: Content-length: 234 CR LF 200 OK CR LF
206.123.31.114
3ffe:b00:c18:ffff:0000:0000:0000:0000
1.1.1.1
3ffe:b00:c18:ffff::0000:0000:0000:0001
userid.domain
3ffe:0b00:c18:1234::
2.3.4.5
2.3.4.6
3ffe:0c00::1
 5.4 Router Tunnel Request with a /48 prefix delegation and BGP peering, and Reply A tunnel request with prefix consist of a 'tunnel' element which contains 'address' element and a 'router' element. Tunnel request with prefix and BGP peering. C: Content-length: 234
1.1.1.1
2.3.4.5
Blanchet, editor, et. al. Expires January 11, 2002 [Page 8] Internet-Draft IPv6 over IPv4 profile for TSP July 2001
2.3.4.6
3ffe:0c00::1
 S: Content-length: 234 200 OK
206.123.31.114
3ffe:b00:c18:ffff:0000:0000:0000:0000
1.1.1.1
3ffe:b00:c18:ffff::0000:0000:0000:0001
userid.domain
3ffe:0b00:c18:1234::
2.3.4.5
2.3.4.6
3ffe:0c00::1
 6. Error codes This profile dependant error codes are : 501 Invalid IPv4 address 502 Invalid or duplicate nicname 503 Invalid AS number 504 Router function not supported 505 No more tunnels available Blanchet, editor, et. al. Expires January 11, 2002 [Page 9] Internet-Draft IPv6 over IPv4 profile for TSP July 2001 506 IPv4 prefix already used for existing tunnel 507 Requested prefix length cannot be assigned 508 Routing protocol setup error 509 DNS delegation setup error 514 Protocol error 517 Unsupported router protocol 518 Unsupported prefix length 519 Invalid as number 520 Missing prefix length if a list of tunnel servers is following the error code as a referal service, then 1000 is added to the error code. 7. IANA Considerations The TUNNELTYPE "v6v4" is registered for this document. 8. Security considerations This protocol is also in accordance with guidelines for IPv6 transition [7] about possible abuse against IPv6 transition technologies. 9. Acknowledgements Jun-Ichiro Itojun Hagino was, as usual, a great helper in refining and commenting this work. This work has been done on a team basis so all people here contributed to the original work: Andre Cormier, Regis Desmeules, Florent Parent, Jocelyn Picard, Guy Turcotte. References [1] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001. [2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. Blanchet, editor, et. al. Expires January 11, 2002 [Page 10] Internet-Draft IPv6 over IPv4 profile for TSP July 2001 [3] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. [4] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000. [5] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. [6] Durand, A., "IPv6 over IPv4 tunnels for home to Internet access method", July 2000. [7] Hagino, J., "Possible abuse against IPv6 transition technologies", July 2000. [8] 2, 1., "MIME-type extension for IPv6 configured tunnels", 1 1. [9] Blanchet, M., "Tunnel Setup Protocol", July 2001. Authors' Addresses Marc Blanchet Viagenie inc. 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/ Regis Desmeules Viagenie inc. 2875 boul. Laurier, bureau 300 Sainte-Foy, QC G1V 2M2 Canada Phone: +1 418 656 9254 EMail: Regis.Desmeules@viagenie.qc.ca URI: http://www.viagenie.qc.ca/ Blanchet, editor, et. al. Expires January 11, 2002 [Page 11] Internet-Draft IPv6 over IPv4 profile for TSP July 2001 Andre Cormier Viagenie inc. 2875 boul. Laurier, bureau 300 Sainte-Foy, QC G1V 2M2 Canada Phone: +1 418 656 9254 EMail: Andre.Cormier@viagenie.qc.ca URI: http://www.viagenie.qc.ca/ Appendix A. IPv6 over IPv4 tunnel DTD DTD ]> Blanchet, editor, et. al. Expires January 11, 2002 [Page 12] Internet-Draft IPv6 over IPv4 profile for TSP July 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). 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, editor, et. al. Expires January 11, 2002 [Page 13]