One document matched: draft-parent-v6tc-protocol-exploration-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 18:57:11 |