One document matched: draft-fairhurst-dccp-behave-update-00.txt
DCCP Working Group G. Fairhurst
Internet-Draft G. Renker
Intended status: Standards Track University of Aberdeen
Expires: April 3, 2008 November 12, 2007
An update for DCCP connection establishment to assist NAT & Firewall
Traversal
draft-fairhurst-dccp-behave-update-00
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 April 3, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Fairhurst & Renker Expires April 3, 2008 [Page 1]
Internet-Draft DCCP NAT Traversal November 2007
Abstract
This document proposes an update to the Datagram Congestion Control
Protocol (DCCP) transport protocol. It describes a method that adds
support to assist traversal of firewalls, Network Address Translators
and other middleboxes that require simultaneous packets to be sent
from the client and server to establish middlebox state.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope of this document . . . . . . . . . . . . . . . . . . 3
1.2. Scope of the problem to be tackled . . . . . . . . . . . . 4
1.3. Discussion of traversal techniques for traditional NAT
devices . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1. Near Simultaneous-open of Connections . . . . . . . . 5
1.3.2. Role reversal . . . . . . . . . . . . . . . . . . . . 6
2. Solution for DCCP NAT traversal . . . . . . . . . . . . . . . 7
2.1. Conventions and Terminology . . . . . . . . . . . . . . . 7
2.2. DCCP-Listen Packet format . . . . . . . . . . . . . . . . 7
2.3. Protocol method . . . . . . . . . . . . . . . . . . . . . 8
2.4. Processing by Routers and Middleboxes . . . . . . . . . . 9
2.5. Examples of use . . . . . . . . . . . . . . . . . . . . . 9
2.6. Backwards Compatibility with RFC4340 . . . . . . . . . . . 10
3. Discussion of design decisions . . . . . . . . . . . . . . . . 11
3.1. Generation of Listen Packets . . . . . . . . . . . . . . . 11
3.2. Repetition of Listen Packets . . . . . . . . . . . . . . . 11
3.3. Client/Server relationship . . . . . . . . . . . . . . . . 12
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Normative References . . . . . . . . . . . . . . . . . . . 15
6.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Fairhurst & Renker Expires April 3, 2008 [Page 2]
Internet-Draft DCCP NAT Traversal November 2007
1. Introduction
UDP Network Address Translator (NAT) traversal is well understood and
widely implemented. NAT traversal for connection-oriented protocols,
such as TCP, uses similar principles, but in some cases requires more
complex and expensive solutions, such as dedicated relay servers.
DCCP RFC4340 is both datagram-based and connection-oriented and thus
NAT traversal of DCCP faces the same problems as TCP NAT traversal,
without being able to reap the benefits of datagram-based NAT
traversal as in UDP. In addition, DCCP suffers from the problem that
it can not exploit the use of simultaneous-open, a TCP-inherent
characteristic which greatly simplifies TCP NAT traversal.
After discussing the problem space for DCCP NAT traversal, this
document proposes a solution to natively support NAT traversal in
DCCP. Among the discussed solutions, it requires the least changes.
It is based on an indicator message. A new DCCP packet type is
introduced that is sent by the server and addressed to the expected
client. Since the use of this packet type is tied to an optional
condition, it facilitates robust and native support for NAT
traversal, while at the same time leaving the standard operational
procedure of DCCP untouched.
1.1. Scope of this document
The solution proposed by this document assists in connection
establishment when one or both peers are located behind a middlebox.
While the solution is specifically targeted at NAT traversal, due to
the similarity of involved principles, it may also be of similar use
to the traversal of other types of middlebox, such as firewalls.
For the scope of this document we consider traditional (outbound)
types of NAT as defined in RFC2663 and further discussed in RFC3022.
We consider NAT traversal to involve one or more NAT devices of this
type in the path (i.e. hierarchies of nested NAT devices are
possible). It is assumed that all NATs in the path between endpoints
are BEHAVE-compliant [DRAFT-APP].
We consider NAT devices which provide a minimum of DCCP protocol
support, in that layer-4 checksums can be updated to account for
changes in the pseudo-header. Since this document tackles an
inherent problem of DCCP NAT traversal, we do not specify any further
requirements for DCCP support in NAT devices. These may be described
by a separate document.
This discussion is relevant to both client/server and peer-to-peer
applications, such as VoIP, file sharing, or online gaming. The
Fairhurst & Renker Expires April 3, 2008 [Page 3]
Internet-Draft DCCP NAT Traversal November 2007
update assists connections that utilise prior out-of-band signaling
between the client and server (e.g. a well-known rendezvous server,
RFC3261"/>, [H.323]) to notify both endpoints of the connection
parameters [RFC3235] [DRAFT-APP].
1.2. Scope of the problem to be tackled
We refer to DCCP hosts located behind one or more NAT devices as
having "private" addresses and to DCCP hosts located in the global
address realm as having "public" addresses.
We consider DCCP NAT traversal with regard to the following example
scenarios:
1. Private client connects to public server
2. Public server connects to private client
3. Private client connects to private server
A defining characteristic of traditional NAT devices RFC 3022 is that
private hosts can connect to external hosts, but not vice versa.
Hence the case (1) is always possible, whereas cases (2) and (3)
require NAT traversal techniques and update of the DCCP specification
(as described in this document). For the discussion of 2/3 we leave
aside the possibility of configuring static NAT address maps to allow
outside hosts to connect into the private network.
1.3. Discussion of traversal techniques for traditional NAT devices
This section is a brief review of some existing techniques to
establish connectivity across NAT devices, the basic idea being to
make peer-to-peer sessions look like "outbound" sessions on each NAT
device.
The term 'hole punching' was coined in [FSK05] and refers to creating
soft state in a traditional NAT device by initiating an outbound
connection. A well-behaved NAT can subsequently exploit this to
allow a reverse connection back to the host in the private address
realm.
Often a rendezvous server, located in the public address realm, is
used to enable clients to discover their NAT topology and the
addresses of peers.
The adaptation of the basic hole punching principle to TCP NAT
traversal was introduced in section 4 of [FSK05] and relies on the
simultaneous-open feature of TCP RFC0793. UDP and TCP hole punching
Fairhurst & Renker Expires April 3, 2008 [Page 4]
Internet-Draft DCCP NAT Traversal November 2007
use nearly the same protocol, the main difference lies in the way the
clients perform connectivity checks after obtaining the address pairs
from the server: whereas in UDP a single socket is sufficient, TCP
clients require several sockets for the same address/port tuple:
o a passive socket to listen for connectivity tests from peers and
o multiple active connections from the same address to test
connectivity of other peers.
The SYN sent out by client A to its peer B creates soft state in A's
NAT. At the same time, B tries to connect to A:
o if the SYN from B has left B's NAT before the arrival of A's SYN,
both endpoints perform simultaneous open (4-way handshake of SYN/
SYNACK);
o otherwise A's SYN may not enter B's NAT, which leads to B
performing a normal open (SYN_SENT => ESTABLISHED) and A
performing a simultaneous open (SYN_SENT => SYN_RCVD =>
ESTABLISHED).
In the latter case it is necessary that the NAT does not interfere
with a RST segment (REQ-4 in [GBF+07]). The simultaneous-open
solution is convenient due to its simplicity, and is thus a preferred
mode of operation in the TCP extension for ICE [Ros07a, sec. 2].
The considerations in this section and the following subsections
motivate a discussion as to whether and how the DCCP state machine
can be enhanced to natively facilitate easier midbox traversal.
1.3.1. Near Simultaneous-open of Connections
Among the various TCP NAT traversal approaches, simultaneous-open
suggests itself due to its simplicity [GF05], [DRAFT-APP]. A
characteristic of simultaneous-open is that the clear distinction
between client and server is erased: both sides enter through active
(SYN_SENT) as well as passive (SYN_RCVD) states. This characteristic
is in conflict with several ideas underlying DCCP, as a clear
separation between client and server has been one of the initial
design decisions ([RFC4340], 4.6). Furthermore, several mechanisms
implicitly rely on clearly-defined client/server roles:
Fairhurst & Renker Expires April 3, 2008 [Page 5]
Internet-Draft DCCP NAT Traversal November 2007
o Feature Negotiation: with few exceptions, almost all of DCCP's
negotiable feature use the "server-priority" reconciliation rule
(section 6.3.1 of RFC4340), whereby peers exchange their
preference lists of feature values, and the server decides the
outcome.
o Closing States: only servers may generate CloseReq packets (asking
the peer to hold timewait state), while clients are only permitted
to send Close or Reset packets to terminate a connection
([RFC4340], 8.3)
o Service Codes: passive sockets may associate multiple service
codes, while active/connecting sockets must have exactly one
associated service code ([RFC4340], 8.1.2).
o Init Cookies: may only be used by the server and on DCCP-Response
packets ([RFC4340], 8.1.4).
The latter two points are not obstacles per se, but hinder the
transition from a passive to an active socket. The assumption that
"all DCCP hosts are clients", on the other hand, must be dismissed
since it limits application programming. As a consequence, retro-
fitting simultaneous open into DCCP does not seem a very sensible
idea.
1.3.2. Role reversal
After the simultaneous-open, one of the simplest TCP NAT traversal
schemes involves role traversal ([Epp05] and [GTF04]), where a peer
first opens an active connection for the single purpose of punching a
hole in the firewall, and then reverts to a listening socket to
accept incoming connections arriving via the new path.
This solution has several disadvantages for DCCP: First, A DCCP
client would be required to change its role from initially 'client'
to 'server'. This makes common server processing difficult: it is
not clear how to assign multiple service codes (this would have to be
done after the transition), a similar issue arises with Init Cookies.
Further, the the client must not yet have started feature
negotiation, since its choice of initial options may rely on its role
(i.e. if an endpoint knows it is the server, it can make a priori
assumptions about the preference lists of features it is negotiating
with the client, thereby enforcing a particular policy). We
therefore do not recommend this approach for DCCP.
Fairhurst & Renker Expires April 3, 2008 [Page 6]
Internet-Draft DCCP NAT Traversal November 2007
2. Solution for DCCP NAT traversal
This section revises packet processing for a DCCP Client and Server,
to assists in connection establishment when one or both peers are
located behind a middlebox. The method does not employ role
reversal; both endpoints start out with their designated roles, as
specified in RFC4340.
2.1. Conventions and Terminology
The document uses the terms and definitions provided in RFC4340.
Familiarity with this specification is assumed, and note that
[RFC4340], 3.1 states:
"Each DCCP connection runs between two hosts, which we often name
DCCP A and DCCP B. Each connection is actively initiated by one of
the hosts, which we call the client; the other, initially passive
host is called the server"
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2.2. DCCP-Listen Packet format
The document updates DCCP by adding a new packet type: DCCP-Listen.
The format of the packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Dest Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Offset | CCVal | CsCov | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Res | Type |X| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
DCCP-Listen Packet Format
The Reserved (Res) field is specified by RFC4340, and it successors.
This document does not modify this definition.
The Type field has the value XX-IANA-assigned-XX, which indicates
that this is a DCCP-Listen packet.
For this type of packet the following protocol fields MUST be set to
Fairhurst & Renker Expires April 3, 2008 [Page 7]
Internet-Draft DCCP NAT Traversal November 2007
zero:
Data Offset (the connection has not been established)
CCVal (the connection has not been established)
CsCov (there is no payload)
X (extended mode is not permitted)
Sequence Number (no initial sequence number has been negotiated)
A DCCP-Listen Packet MUST NOT include any DCCP options (since this
packet does not modify the receiver protocol state) and MUST NOT
include a payload field.
2.3. Protocol method
A server in the DCCP-Listen state ([RFC4340], 4.3) that passively
listens, but does not fully specify the DCCP connection (assigned a
pair of IP addresses, a pair of port numbers, and a Service Code)
MUST use the method defined in RFC4340. It does not send a DCCP-
Listen packet (the corresponding endpoint is anyway unspecified).
A server in DCCP-Listen state that has been bound to a fully-
specified connection SHOULD use this method to send a single DCCP-
Listen packet to the remote endpoint. The server SHOULD treat ICMP
error messages received in response to a DCCP-Listen packet as "soft
errors", that do not abort a connection.
A DCCP Client that implements RFC4340 and receives a DCCP-Listen
would issue a DCCP-Reset (as it would for all unknown types of
packet).
This document updates RFC4340, so that a DCCP Client in any state
that receives a DCCP-Listen packet, MUST silently discard the packet.
The packet indicates only a willingness to accept a connection, if
the client has already established a connection, this has no meaning.
If the client is awaiting the response to a DCCP-Request, the client
does not need to take specific action, and should continue to use the
protocol method defined in RFC4340.
Receipt of a DCCP-Listen packet by a server in the LISTEN state must
necessarily lead to a Reset (here Code 7, "Connection Refused" would
also make sense). This is the expected behaviour for RFC4340.
Fairhurst & Renker Expires April 3, 2008 [Page 8]
Internet-Draft DCCP NAT Traversal November 2007
2.4. Processing by Routers and Middleboxes
Routers and Middleboxes need to forward DCCP packets. This document
does not specify the rules for forwarding these packets, but notes
that DCCP-Listen packets do not require special treatment and should
be forwarded end-to-end across the internet path. Middle boxes may
utilise the connection information (address, port, Service Code) to
establish local forwarding state.
2.5. Examples of use
In the examples below, DCCP A is the client and DCCP B is the server.
NAT/Firewall device NA is placed before DCCP A, and NAT/Firewall
device NB is placed before DCCP B. Both NA and NB use a policy that
permits DCCP packets to traverse the device for outgoing links, but
only permit incoming DCCP packets when a previous packet has been
sent for the same connection.
DCCP A and DCCP B decide to communicate using some out of band
mechanism, and the client and server are started. DCCP A initiates a
connection by sending a DCCP-Request. DCCP B actively indicates its
state by sending a Listen message. This fulfils the requirement of
punching a hole in NB so that DCCP A can retransmit the DCCP-Request
and connect through it.
DCCP A DCCP B
------ NA NB ------
+------------------+ +-+ +-+ +-----------------+
|(1) Initiation | | | | | | |
|DCCP-Request --> +--+-+---X| | | |
| |<-+-+----+-+--+<-- DCCP-Listen |
| | | | | | | |
|DCCP-Request --> +--+-+----+-+->| |
| |<-+-+----+-+--+<-- DCCP-Response|
|DCCP-Ack --> +--+-+----+-+->| |
| | | | | | | |
|(2) Data transfer | | | | | | |
|DCCP-Data --> +--+-+----+-+->| |
+------------------+ +-+ +-+ +-----------------+
Sequence of events when a client (DCCP A) is been started before the
server
The diagram below reverses this sequencing:
Fairhurst & Renker Expires April 3, 2008 [Page 9]
Internet-Draft DCCP NAT Traversal November 2007
DCCP A DCCP B
------ NA NB ------
+------------------+ +-+ +-+ +-----------------+
|(1) Initiation | | | | | | |
| | | |X---+-+--+<-- DCCP-Listen |
|DCCP-Request --> +--+-+----+-+->| |
| | <+-+----+-+--+<-- DCCP-Response|
|DCCP-Ack --> +--+-+----+-+> | |
| | | | | | | |
|(2) Data transfer | | | | | | |
|DCCP-Data --> +--+-+----+-+> | |
+------------------+ +-+ +-+ +-----------------+
Sequence of events when a server (DCCP B) is been started before the
client
2.6. Backwards Compatibility with RFC4340
This does not modify communication for a server that implements
RFC4340 and a client that implements the update described in this
document.
This does not also does not modify communication for any server that
implements a passive open without fully binding the addresses, ports
and service codes to be used.
A change in the protocol exchange does occur when a server implements
this update and binds to a client that implements RFC4340:
If DCCP A and B were not behind NAT devices, the receipt of a DCCP
Listen packet at A by a Server that implements RFC 43430 would lead
to a DCCP-Reset (presumably Code 3, "No Connection", since Code 7,
"Connection Refused" applies to DCCP-Requests only). This would
abort the connection.
Since the out-going DCCP-Listen packet is expected to open a hole in
the firewall, the same conclusion is expected when using NATs, as in
the examples presented in the previous section.
The authors do not however expect these issues to introduce practical
deployment problems.
Fairhurst & Renker Expires April 3, 2008 [Page 10]
Internet-Draft DCCP NAT Traversal November 2007
3. Discussion of design decisions
This section identifies a number of design decisions that were made
in defining the current approach.
3.1. Generation of Listen Packets
Since DCCP-Listen packets solve a particular problem (NAT and/or
firewall traversal), the generation of DCCP-Listen packets on passive
sockets has been tied to a condition (i.e. the server is aware of the
expected client connection request), so as to not interfere with the
general case of "normal" DCCP connections.
In the TCP world, the analogue is a transition from LISTEN to
SYN_SENT by virtue of sending data: "A fully specified passive call
can be made active by the subsequent execution of a SEND" ([RFC0793],
3.8).
Unlike TCP, this proposal does not perform a role change from passive
to active. Like TCP, we require as condition for the generation of
DCCP-Listen packets that the listening socket for DCCP B be fully
specified, i.e. both source address/port and destination address/port
are set. In the above case, this would for example mean that DCCP B
opens a passive socket listening on DCCP B's local address/port and
bound to DCCP A's public address/port (as assigned on the public side
of NA).
If this condition were considered too weak (or introduces
unacceptable backwards compatibility issues with RFC4340), it could
be coupled with a socket option to trigger generation of DCCP-Listen
packets on fully specified passive sockets.
3.2. Repetition of Listen Packets
Section 4.3 of RFC4340 defines the LISTEN state as:
"Represents server sockets in the passive listening state. LISTEN
and CLOSED are not associated with any particular DCCP
connection."
This document revises this definition by establishing a specific case
where a server that has been bound to a fully-specified DCCP
connection (assigned a pair of IP addresses, a pair of port numbers,
and a Service Code).
In the current revision of this document, this is represented as an
additional transition, but the authors also acknowledge the
possibility of introducing a new state. This state would allow a
Fairhurst & Renker Expires April 3, 2008 [Page 11]
Internet-Draft DCCP NAT Traversal November 2007
LISTEN packet to be re-issued periodically to refresh firewall state.
This approach would ad robustness to the proposed mechanism, but has
the disadvantage that the DCCP-Listen packets could then contribute
unwanted load in a mis-configured network and procedures may be
needed to limit the rate and number of packets sent.
3.3. Client/Server relationship
The DCCP protocol differentiates between client and server functions
([RFC4340, section 1.2.1). It is therefore necessary that peer-to-
peer connections are able to differentiate the two roles, which may
be need to be signaled to the DCCP hosts as part of the address/port
setup.
Fairhurst & Renker Expires April 3, 2008 [Page 12]
Internet-Draft DCCP NAT Traversal November 2007
4. IANA Considerations
This document requires IANA action by allocation of a new Packet Type
from the IANA Packet Types Registry. The Registry entry is to
reference this document. This allocation requires IESG review and
approval and standards-track IETF RFC publication.
Fairhurst & Renker Expires April 3, 2008 [Page 13]
Internet-Draft DCCP NAT Traversal November 2007
5. Security Considerations
The method specified in this document exposes the state of a DCCP
server that has been explicitly configured to accept a connection
from a client. This requires prior out of band signaling between the
client and server (e.g. via SIP) to establish this state. The method
generates a packet addressed to the expected client.
This increases the vulnerability of the DCCP host by revealing which
ports are in a passive listen state to the expected client (this
information is not encrypted, and therefore could be seen on the path
to the client through the network). We do not believe this change
significantly increases the complexity or vulnerability of a DCCP
implementation that conforms to RFC 4340.
Reception of a DCCP-Listen packet would trigger a DCCP-Reset in
RFC4340, but is ignored by the method described in this protocol.
This does not introduce new security concerns.
Fairhurst & Renker Expires April 3, 2008 [Page 14]
Internet-Draft DCCP NAT Traversal November 2007
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
6.2. Informative References
[DRAFT-APP] B. Ford, P. Srisuresh, D. Kegel, Application Design
Guidelinesfor Traversal through Network Address
Translators, Work in Progress, draft-ford-behave-app-05.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999.
[RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC 3235, January 2002.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley, M.,
and E. Schooler, "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[FSK05] Ford, Bryan, Pyda Srisuresh and Dan Kegel. Peer-to-Peer
Communication Across Network Address Translators.
Proceedings of USENIX-05, pages 179--192. 2005.
[GTF04] Guha, Saikat, Yukata Takeda and Paul Francis. NUTSS: A SIP
based approach to UDP and TCP connectivity. Proceedings of
SIGCOMM'04 Workshops, Portland, OR, pages 43--48. 2004.
[GF05] Guha, Saikat and Paul Francis. Characterization and
Measurement of TCP Traversal through NATs and Firewalls.
Proceedings of Interet Measurement Conference (IMC-05),
pages 199-211. 2005.
[H.323] "Packet-based Multimedia Communications Systems", ITU-T
Recommendation H.323, July 2003.
Fairhurst & Renker Expires April 3, 2008 [Page 15]
Internet-Draft DCCP NAT Traversal November 2007
Appendix A. Change Log
This is the first public draft.
Fairhurst & Renker Expires April 3, 2008 [Page 16]
Internet-Draft DCCP NAT Traversal November 2007
Authors' Addresses
Godred Fairhurst
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen AB24 3UE
Scotland
Email: gorry@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk
Gerrit Renker
University of Aberdeen
School of Engineering
Fraser Noble Building
Aberdeen AB24 3UE
Scotland
Email: gerrit@erg.abdn.ac.uk
URI: http://www.erg.abdn.ac.uk
Fairhurst & Renker Expires April 3, 2008 [Page 17]
Internet-Draft DCCP NAT Traversal November 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Fairhurst & Renker Expires April 3, 2008 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-23 22:54:37 |