Network Working Group F. Parent Internet-Draft Hexago Expires: June 16, 2005 P. Savola CSC/FUNET A. Durand SUN Microsystems,inc. December 16, 2004 v6tc Protocol Exploration draft-parent-v6tc-protocol-exploration-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 16, 2005. Copyright Notice Copyright (C) The Internet Society (2004). Abstract This document aims to provide a rough sketch on different approaches to meet the zeroconf/assisted tunneling requirements for a simple IPv6-in-IPv4 tunnel set-up mechanism. Parent, et al. Expires June 16, 2005 [Page 1] Internet-Draft v6tc protocol exploration December 2004 Table of Contents 1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Implicit Tunnel Setup . . . . . . . . . . . . . . . . . . 4 2.1.1 DHCPv6 . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.2 Router Advertisement . . . . . . . . . . . . . . . . . 6 2.2 Negotiated Tunnel Setup . . . . . . . . . . . . . . . . . 8 2.2.1 Tunnel Setup Messages . . . . . . . . . . . . . . . . 9 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1 Normative References . . . . . . . . . . . . . . . . . . . . 13 5.2 Informative References . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 15 Parent, et al. Expires June 16, 2005 [Page 2] Internet-Draft v6tc protocol exploration December 2004 1. Goals Meet assisted tunneling and zero-conf tunneling requirement documents. o Simple mode o Ipv6 endpoint o v6v4 tunneling o Nat traversal o User authentication o IPv6 prefix TBD. 2. Approaches A Reusing existing standardized protocols as far as possible: DHCPv6, Router Advertisements: these will establish the tunnel implicitly. B Define a tunnel setup protocol to exchange the tunnel information. DHCPv6 and RA are not defined to establish configured tunnels, but instead to assign addresses/prefixes and other related information on the link after one has been established. Therefore, there are two possibly separate problems that need to be addressed: 1. Setting up an IPv4 tunnel over which IPv6 packets can be sent; this link may or may not have more than a link-local address. 2. Configuring information related to the tunnel, e.g., global addresses, default routes, etc. Additionally, one may want to configure other parameters (such as recursive DNS server addresses, SIP server addresses, etc.) unrelated to obtaining simple IPv6 connectivity, but that is considered a non-problem for this work. As the main issue in v6tc is finding a means to establish the link (problem #1), we assume that the tunnel link must be established as part of the v6tc solution. Parent, et al. Expires June 16, 2005 [Page 3] Internet-Draft v6tc protocol exploration December 2004 Obviously, DHCPv6 and RA can be used for problem #2 when a separate protocol (e.g., explicit tunnel setup as described in Section 2.2) has been used for #1, but it is debatable whether this is useful. This is not discussed at this point. 2.1 Implicit Tunnel Setup Existing mechanisms such as DHCPv6 and RA can be used to assign an address or use a prefix (problem #2), but are not suitable *as-is* to establish a configured tunnel (problem #1). With a small change, this shortcoming can be fixed. With the implicit tunnel creation, the first DHCPv6 solicit/RS message sent by the client is received by the server, and triggers the creation of the tunnel link, on top of which a reply is sent back. The messaging uses link-local addresses automatically assigned for tunnel links. DAD can be disabled as long as the generation of the link-local address is unique enough (e.g., derives the address from the IPv4 address, as is typical for v6-over-v4 implementations). The DHCPv6 and RA approaches are described in more length below, in Section 2.1.1 and Section 2.1.2. The following generic issues/considerations apply to both DHCPv6 and RA approaches: o Cannot negotiate tunnel encapsulation type (always over UDP) o NAT detection is no longer necessary since UDP is always used. There can be no keepalive negotiation (for the benefit of both firewalls and NATs); it is assumed that keepalives are always sent by the host except when disabled in the host. o ISPs will likely not use authentication for their own users, but instead rely on IP-address based filtering. o Implementation is likely a process which listens at the UDP port and directs packets relating to existing tunnels to those tunnel interfaces, and demultiplexes he incoming initial packets by creating new interfaces based on need, and when created, injects the initial DHCPv6/RS messages on that interface, so they'll end up in the local unmodified DHCPv6 server process or RA process. 2.1.1 DHCPv6 The steps are as follows: Parent, et al. Expires June 16, 2005 [Page 4] Internet-Draft v6tc protocol exploration December 2004 1. Client configures IPv6/UDP/IPv4 interface towards tunnel server. (The address has been discovered using the discovery mechanism, e.g., DNS.) 2. Client sends DHCP solicit over tunnel using the rapid commit option ([RFC3315] section 22.14). 3. Tunnel server listening on UDP port receives message and configures tunnel interface link (based on the IPv4 source address). 4. DHCPv6 solicit message is received by DHCPv6 server through the tunnel link that was just created. 5. DHCPv6 advertise IPv6 address to client. client server 1.Configure | | tunnel o| | | 2.DHCP solicit | | (rapid commit) | DHCP/IPv6/UDP/IPv4 |------------------------->| | | | |o 3.configure tunnel | | 4.message to DHCPv6 | 5.DHCP advertise | server |<------------------------ | Figure 1: DHCPv6 in simple mode If the client uses authentication, DHCP delayed authentication is used [RFC3118]. This requires the client and server to share a known secret. This differs from the above in that Rapid Commit option cannot be used at step 2, above, and Advertise option (at step 5) carries the authentication and requires a couple of additional steps: o Client sends Request with auth options. At this point, the server is able to validate the authenticity of the user. If that fails, the request is dropped and the tunnel may be removed. o Server sends Reply + auth options. Parent, et al. Expires June 16, 2005 [Page 5] Internet-Draft v6tc protocol exploration December 2004 client server 1.Configure | | tunnel o| | | 2.DHCP solicit | DHCP/IPv6/UDP/IPv4 |------------------------->| | | | |o 3.configure tunnel | | 4.message to DHCPv6 | 5.DHCP advertise | server |<------------------------ | | DHCP request | |------------------------->|o client identity | DHCP reply | verified here. |<------------------------ | Figure 2: DHCPv6 in authenticated mode DHCP delayed authentication [RFC3118] is used to provide a user authentication based on shared secrets. The secrets are not sent in clear. Prefix delegation may be done using IPv6 prefix options [RFC3633]. In the non-authenticated case, prefix delegation can be accomplished in one round-trip using the rapid commit option. Notes/Issues o Might be an issue about using DHCPv6 for address assignment. What are the host requirements? 2.1.2 Router Advertisement ICMPv6 Neighbor Discovery [RFC2461] Router Advertisements are very similar to DHCPv6, with a few notable differences: o Authentication where needed can be done using SEND [I-D.ietf-send-ndopt]. o Prefix delegation is not supported, but multiple nodes can use the same prefix if using bridging or ND-proxy [I-D.ietf-ipv6-ndproxy]. o Requires no DHCPv6 implementation (for address assignment, at least) on hosts. The steps are as follows: Parent, et al. Expires June 16, 2005 [Page 6] Internet-Draft v6tc protocol exploration December 2004 1. Client configures IPv6/UDP/IPv4 interface towards tunnel server. (The address has been discovered using the discovery mechanism, e.g., DNS.) 2. Client sends Router Solicitation over tunnel. 3. Tunnel server listening on UDP port receives message and configures tunnel interface link (based on the IPv4 source address) 4. The RA/RS handling process receives the RS message from the new link that was just set up. 5. Route Advertisement message is sent in response through the tunnel link. client server 1.Configure | | tunnel o| | | 2.ND/Router Solicitation | RS/IPv6/UDP/IPv4 |------------------------->| | | | |o 3.configure tunnel | | 4.message to RA | 5. Router Advertisement | process |<------------------------ | Figure 3: RA in simple mode If SEND is used for authentication, Router Solicitation additionally includes the CGA, RSA Signature, Nonce, and Timestamp options. The server has the user's public key in file, and checks the CGA address against that. The fact that the client has been able to sign the ND message with the private key is sufficient for the server to ascertain user's identity. In a similar fashion, the server uses CGA in its replies, allowing the client to ensure no one is able to thwart the signalling. The Certification Path Discovery and Certificates are not required as the link is point-to-point. The use of SEND incurs no additional roundtrips. Parent, et al. Expires June 16, 2005 [Page 7] Internet-Draft v6tc protocol exploration December 2004 Notes: o If the client needs to configure any other IPv6 parameters than a global address, running DHCPv6(-lite) or the like may be necessary. 2.2 Negotiated Tunnel Setup An alternative approach is to define a new protocol to exchange the tunnel parameters explicitly. The tunnel setup protocol is done over UDP and NAT detection is done to determine if IPv6-over-IPv4 tunneling or IPv6 over UDP tunnel will be used. The characteristics of this protocol are similar to TSP ([I-D.blanchet-v6ops-tunnelbroker-tsp]), with simplified signaling. o Tunnel signaling is transported over UDP/IPv4. o Tunnel parameters are explicitly exchanged o NAT detection/traversal o Tunnel is explicitly configured from tunnel parameters exchanged after signaling o Simple mode supported (no authentication, one round trip); note that getting to one roundtrip requires that the protocol is also used for assigning the IPv6 address or prefix. o Prefix delegation The steps are as follows: 1. Client sends tunnel request over UDP/IPv4 2. Tunnel server listening on UDP port receives message and determines if client behind NAT (based on IPv4 header information and client IPv4 address in message) 3. Server sends tunnel information to client 4. Client and server configure tunnel endpoint. Parent, et al. Expires June 16, 2005 [Page 8] Internet-Draft v6tc protocol exploration December 2004 client server | 1.Tunnel request | UDP/IPv4 |----------------------------->| | | 2.NAT detection | 3.Tunnel reply | |<---------------------------- | | Tunnel established | 4.configure tunnel |==============================| Figure 4: Tunnel setup protocol in simple mode 2.2.1 Tunnel Setup Messages The tunnel request from the client must contain: o Client IPv4 address (used for NAT detection) o Tunnel encapsulation mode requested The tunnel request from the client may contain (optional parameters): o Prefix delegation request o Authentication information o Keepalive information A possible protocol message structure is to use a fixed message header followed by one or more TLV. This header is used in every packets sent during the tunnel signaling. Other information is added as TLV. Parent, et al. Expires June 16, 2005 [Page 9] Internet-Draft v6tc protocol exploration December 2004 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xF |M|KA |0| Encapsulation | Type | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Tunnel setup protocol UDP header The first 8 bytes is the standard UDP header. 0xF Marker. Used to differentiate a signaling packet from an IPv6 datagram. M One bit mode flag. Set to 0 for no authentication. Set to 1 if authentication is requested. KA Two bits keepalive flags. Set to 10 for no keepalive. Set to 01 if keepalive requested. Set to 11 if don't care (server reply will decide on what to do). Encapsulation Indicates the type of encapsulation requested. Set to 41 for IPv6-over-IPv4 tunnels, ? for IPv6 over UDP. May need to define new value here to define "IPv6 over foo" (let server decide after NAT detection) Type Message type (request, response) 2.2.1.1 Client IPv4 address A client request uses the tunnel setup header, plus an extra TLV containing the client IPv4 address. Including the IPv4 address inside the payload can be used by the server to detect if the client is behind a NAT. Should address obfuscation be used? According to Teredo spec, it is. [I-D.ietf-ipsec-nat-t-ike] uses a HASH of the address (and port). The server can compute the HASH and validate if it corresponds to what the client sees. If not, an address translation occurred. Parent, et al. Expires June 16, 2005 [Page 10] Internet-Draft v6tc protocol exploration December 2004 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Client IPv4 address TLV 2.2.1.1.1 Authentication information (optional) If the M bit is set to 1, client is requesting authentication. A TLV representing the identity of the client is sent. The server will need to sent a challenge. TLV details to be worked out. 2.2.1.1.2 Prefix delegation request (optional) If a prefix delegation TLV is included in the request, it indicates to the server that the client is requesting a prefix. TLV details to be worked out. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Prefix delegation request TLV 2.2.1.2 Server response Message type is X (response) In simple mode (no prefix delegation, no auth), the server will provide the following information in its response o IPv4 server endpoint (IPv6 in IPv4 tunnel) o IPv6 address of client Parent, et al. Expires June 16, 2005 [Page 11] Internet-Draft v6tc protocol exploration December 2004 o IPv6 address of server o Encapsulation type Keepalive TLV is sent by server if requested by client. TLV holds the keepalive time interval to be used by the client. If authentication is requested, the server will send a challenge to the client. The authentication can be based on HTTP authentication (RFC2617) or something like DHCP delayed authentication (RFC3118). This needs to be further defined. Likely to add one round trip (challenge-response). If a prefix delegation is requested by the client, the server response includes a TLV specifying the delegated prefix. Some notes o When keepalive is requested, should the client supply a keepalive time interval that will be used? This can be useful from the server point of view to decide when a tunnel is inactive o The server could only return its IPv4 address to the client and use RA to configure the client (IPv6 address, default route). Doing so would have the advantage of using an existing mechanism at the cost of an extra packet sent from the server to the client. o DAD disabled by default on the tunnel link. o Some authentication mechanism may depend on transport layer to reliably deliver packets. Since UDP is used, may need to handle this in protocol ([I-D.blanchet-v6ops-tunnelbroker-tsp]) 3. IANA Considerations None at this point. 4. Security Considerations Creating tunnel state based on the first UDP packet is can open the server to a DoS attack with spoofed source addresses. There are a couple of ways to mitigate this: o Use ingress filtering towards your customers and at your own borders, and provide the service to your own customers only. The threat is eliminated. Parent, et al. Expires June 16, 2005 [Page 12] Internet-Draft v6tc protocol exploration December 2004 o As above, but apply rate-limiting or other IP-address based controls to those who desire to use the service from outside networks. o Require authentication from the outside users. 5. References 5.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. 5.2 Informative References [I-D.blanchet-v6ops-tunnelbroker-tsp] Parent, F. and M. Blanchet, "IPv6 Tunnel Broker with the Tunnel Setup Protocol(TSP)", draft-blanchet-v6ops-tunnelbroker-tsp-01 (work in progress), June 2004. [I-D.ietf-ipsec-nat-t-ike] Kivinen, T., "Negotiation of NAT-Traversal in the IKE", draft-ietf-ipsec-nat-t-ike-08 (work in progress), February 2004. [I-D.ietf-ipv6-ndproxy] Thaler, D., "Bridge-like Neighbor Discovery Proxies (ND Proxy)", draft-ietf-ipv6-ndproxy-00 (work in progress), December 2004. [I-D.ietf-send-ndopt] Parent, et al. Expires June 16, 2005 [Page 13] Internet-Draft v6tc protocol exploration December 2004 Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06 (work in progress), July 2004. [RFC3053] Durand, A., Fasano, P., Guardini, I. and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001. Authors' Addresses Florent Parent Hexago 2875 boul. Laurier, suite 300 Sainte-Foy, QC G1V 2M2 Canada EMail: Florent.Parent@hexago.com Pekka Savola CSC - Scientific Computing Ltd. Espoo Finland EMail: psavola@funet.fi Alain Durand SUN Microsystems,inc. 17 Network circle UMPK17-202 Menlo Park, CA 94025 USA EMail: Alain.Durand@sun.com Parent, et al. Expires June 16, 2005 [Page 14] Internet-Draft v6tc protocol exploration December 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. Parent, et al. Expires June 16, 2005 [Page 15]