MMUSIC Working Group E. Cooper
Internet Draft P. Matthews
Expires: December 2006 Avaya
June 15, 2006
Eliminating Duplicate Connectivity Checks in ICE
draft-matthews-mmusic-ice-eliminating-duplicates-00.txt
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 December 15, 2006.
Abstract
The ICE (Interactive Connectivity Establishment) protocol is designed
to find the best possible transmission path between two endpoints in
the presence of intervening NAT (Network Address Translation) boxes.
It is a very versatile protocol, designed to operate in all possible
network topologies. This versatility occasionally results in a large
exchange of messages between the two endpoints.
This document proposes a modification which reduces the amount of
messaging ICE requires, without affecting the effectiveness of ICE.
Cooper & Matthews Expires December 15, 2006 [Page 1]
Internet-Draft Eliminating Duplicate Checks June 2006
This modification suppresses the transmission of Binding Requests
from server-reflexive candidates. The result is increased efficiency
due to the suppressed connectivity checks, leading to fewer overall
messages and faster discovery of working paths.
Conventions used in this document
The terminology of this document follows that of [ICE-08]. In
particular, the terms "candidate", "transport address", "native" vs.
"remote", "peer-reflexive", "server-reflexive", and "local" are all
used as per [ICE-08].
Table of Contents
1. Introduction...................................................3
2. Summary of Proposed Changes....................................4
3. Details of Proposed Changes....................................6
3.1. Candidate Pairs and State Machines........................6
3.2. Rx State Machine..........................................8
3.3. Tx State Machine..........................................9
3.3.1. Ordering the Tx State Machines......................10
3.4. Adding Candidates........................................11
3.4.1. Adding Native Candidates - Non Peer Reflexive.......11
3.4.2. Adding Native Candidates - Peer Reflexive...........11
3.4.3. Adding Remote Candidates - Non Peer Reflexive.......11
3.4.4. Adding Remote Candidates - Peer Reflexive...........12
3.5. Promoting Candidates.....................................12
3.6. Removing Candidates......................................12
3.7. Queuing Incoming Binding Requests for Later Processing...12
3.8. Processing Received Binding Requests.....................13
3.9. Processing Received Binding Responses....................14
4. Security Considerations.......................................15
5. IANA Considerations...........................................15
6. Acknowledgments...............................................15
7. References....................................................17
7.1. Normative References.....................................17
7.2. Informative References...................................17
Author's Addresses...............................................17
Intellectual Property Statement..................................17
Disclaimer of Validity...........................................18
Copyright Statement..............................................18
Acknowledgment...................................................18
Cooper & Matthews Expires December 15, 2006 [Page 2]
Internet-Draft Eliminating Duplicate Checks June 2006
1. Introduction
[ICE-08] pairs every native candidate with every remote candidate,
and then checks for connectivity in each direction. When some of the
candidates are server-reflexive candidates, this can lead to
redundant checks. This is because, from a network topology point-of-
view, sending a message from a server-reflexive candidate is the same
as sending from the candidate from which it was derived. Thus
messages sent from server-reflexive candidates do not discover new
network paths.
To understand this more clearly, consider the following network
topology:
..Internet .......................
. .
. +------+ .
. |STUN | .
. |Server| .
. +------+ .
. .
. .
. +--------+ +--------+ .
.. | NAT NL | .............. | NAT NR | ..
+--------+ +--------+
---- ----
/\ /\
/L \ / R\
---- ----
Here L and R are each behind a [BEHAVE-UDP] compliant NAT. Endpoints
L and R both use a public STUN server, but this server does not
support the STUN Relay usage. Thus L has two candidates:
o L1 - a local candidate on L
o L2 - a server-reflexive candidate for L discovered by sending a
Binding Request to the STUN server from L1
Similarly, R has two candidates: R1 and R2.
Cooper & Matthews Expires December 15, 2006 [Page 3]
Internet-Draft Eliminating Duplicate Checks June 2006
Forming the candidate pairs and considering the connectivity checks
required for each pair gives the following:
Check from Check from
Pair L to R Comment R to L Comment
==== ========== ======= ========== =======
(L1,R1) (L1 -> R1) (L1 <- R1)
(L1,R2) (L1 -> R2) (L1 <- R2) Dup of L1<-R1
(L2,R1) (L2 -> R1) Dup of L1->R1 (L2 <- R1)
(L2,R2) (L2 -> R2) Dup of L1->R2 (L2 <- R2) Dup of L2<-R1
As shown in the table, any check that originates from L2 is a
duplicate of a check that originates from L1. Similarly checks
originating from R2 are duplicates of R1's checks. In this example
eliminating these duplicates reduces the total number of checks by
50%.
Eliminating checks in this manner has two advantages:
o It reduces the number of messages that need to be exchanged
between endpoints; and
o The remaining checks start earlier, because there are fewer 50msec
delays between the start of successive checks. This results in
faster identification of desirable paths.
Compared with [ICE-08], the modification described here typically
results in 25% - 50% fewer messages when multiple NATs are involved.
Similarly, the highest-priority working candidate can be promoted to
the m/c line 25% - 50% faster. Since the savings are a result of
eliminating checks from server-reflexive candidates, the reductions
are less significant when one of the endpoints has a public IP
address.
This document is intended only as a contribution to the discussion
around [ICE-08], and is not intended to propose a new standard or
extension to ICE. Rather, it is our hope that the ideas described in
this draft might be incorporated into a future revision of ICE.
2. Summary of Proposed Changes
This document defines a "base candidate" as any candidate that
represents a unique sending point. Local candidates are base
candidates, as are relay candidates, but server-reflexive and peer-
reflexive candidates are not base candidates.
Cooper & Matthews Expires December 15, 2006 [Page 4]
Internet-Draft Eliminating Duplicate Checks June 2006
Connectivity checks only need to be sent from base candidates, as a
check sent from a non-base candidate is equivalent to a check sent
from the base candidate from which it was derived.
In reformulating the procedures of [ICE-08] to send only from base
candidates, we found it necessary to split the state machine of [ICE-
08] into separate receive (Rx) and transmit (Tx) state machines.
Trying to express the modification _without_ this split leads to the
following:
o The state machine for a native non-base candidate must suppress
the sending of Binding Requests;
o The Tx side of the state machine for a native base candidate must
somehow drive the Tx side of all state machines for all native
non-base candidates derived from that base candidate;
o The Rx side of all the state machines for a given native candidate
must somehow be linked together, since the remote endpoint is only
sending from remote base candidates.
Consider the example of section 1. In that scenario, the only
candidate pair that works is (L2, R2). Note that neither L2 nor R2
are base candidates. On node L, the state machine for (L2, R2) will
not send packets (since L2 is not a base candidate), nor will it
receive packets (since R will not send from the non-base candidate
R2). Thus the Tx side of the state machine for the (L2, R2) pair must
somehow be linked with the Tx side of the state machine for (L1, R2),
while the Rx side of the state machine for the (L2, R2) pair must
somehow be linked with the state machine for (L2, R1).
In addition, when we considered how to order or promote candidate
pairs when their state machines are tied together in this manner, it
seemed evident to us that the simplest approach is to split the state
machine of [ICE-08] into separate Rx and Tx state machines.
Splitting the state machine into separate Rx and Tx state machines
results in two other changes:
First, the concept of a candidate pair is divided into an Rx
candidate pair (representing a receiving path from a remote candidate
to a native candidate) and a Tx candidate pair (representing a
transmission path from a native (base) candidate to a remote
candidate).
Second, promotion of a candidate is based on its receiving status
only, and not on its transmitting status. In other words, the
Cooper & Matthews Expires December 15, 2006 [Page 5]
Internet-Draft Eliminating Duplicate Checks June 2006
promotion of a candidate is driven solely by whether or not the
remote endpoint has discovered a sending path to that candidate. This
is consistent with the SDP rule that the m/c line specifies only the
address at which an endpoint wishes to receive data.
3. Details of Proposed Changes
3.1. Candidate Pairs and State Machines
The following figure shows the relationships between candidates,
pairs and state machines on a single endpoint:
CNC List +--------+ +--------+ CRC List
+---------+ |Tx State| |Tx State| +---------+
| | | Machine| |Machine | | |
| | +--------+ +--------+ | |
| | \ / | |
| | \ / | |
+---------+ Tx Candidate \ / +---------+
| | Pair (Nc -> Rc) \ / | |
| Native |--------------------------------------->| Remote |
|Candidate| |Candidate|
| (Nc) |<---------------------------------------| (Rc) |
| | Rx Candidate / \ | |
+---------+ Pair (Nc <- Rc) / \ +---------+
| | / \ | |
| | / \ | |
| | +--------+ +--------+ | |
| | |Rx State| |Rx State| | |
+---------+ | Machine| |Machine | +---------+
| | +--------+ +--------+ | |
| | | |
| | | |
| | | |
+---------+ +---------+
Each peer maintains a list of all the native and remote candidates.
In this document, these are referred to as the Current Native
Candidate (CNC) list and the Current Remote Candidate (CRC) list.
Whenever a new candidate is added to one of these lists, the Tx and
Rx candidate pairs are created. Each Tx candidate pair (Nc -> Rc)
describes a unique outgoing path from the native candidate Nc to the
remote candidate Rc. Similarly, an Rx candidate pair (Nc <- Rc)
represents a unique incoming path. Each Tx candidate pair has a
number of Tx state machines associated with it, one for each
component in the candidate. For example, two Tx state machines are
required when both RTP and RTCP are used. Similarly, each Rx
Cooper & Matthews Expires December 15, 2006 [Page 6]
Internet-Draft Eliminating Duplicate Checks June 2006
candidate pair has one Rx state machine for each component in the
candidate.
On each endpoint, an Rx candidate pair (Nc <- Rc) is created for
every combination of a native candidate (Nc) with a remote candidate
(Rc). By contrast, a Tx candidate pair (Nbc -> Rc) is only created
for every combination of a native _base_ candidate (Nbc) with a
remote candidate (Rc).
Peer reflexive candidates are an exception to these rules. A remote
peer reflexive candidate (Rprc) generates no Rx candidate pairs and
only a single Tx candidate pair (Ngc -> Rprc), where Ngc is the
native candidate involved in the generation of Rprc (see section 3.8.
for details). Note that, in this special case, Ngc may not be a base
candidate. Similarly, a native peer reflexive candidate (Nprc)
generates a single Rx candidate pair (Nprc <- Rgc) and no Tx
candidate pairs.
Cooper & Matthews Expires December 15, 2006 [Page 7]
Internet-Draft Eliminating Duplicate Checks June 2006
3.2. Rx State Machine
The Rx state machine tracks the receipt of Binding Requests from the
remote peer. Each Rx state machine monitors a single component of a
native candidate.
The state transition diagram for the Rx state machine is:
Start
|
v
+------------+
-- | Waiting |
| +------------+
| |
| | Rx Req
| | ------
| | -
| v
10s timeout | +------------+
----------- | | Valid |
- | +------------+
| |
| | Rx ERROR
| | --------
| | -
| V
| +------------+
-> | Invalid |
+------------+
The Rx state machine starts out in the WAITING state. In this state,
it is waiting for the first Binding Request to arrive. Once the
Binding Request is received, the state machine transitions to the
VALID state. Note that the Binding Response is sent as part of the
processing of the Binding Request (see section 3.8. which happens
before the Binding Request is passed to the Rx state machine. If no
Binding Request arrives within 10 seconds, the state machine moves to
the INVALID state, where it remains until it is destroyed.
When the Rx state machine transitions to the VALID state, it
signifies that a successful incoming path has been found from the
remote endpoint. Once the Rx state machine is in the VALID state, it
stays there until the state machine is destroyed as a result of a
signaling message, or an error occurs.
Cooper & Matthews Expires December 15, 2006 [Page 8]
Internet-Draft Eliminating Duplicate Checks June 2006
3.3. Tx State Machine
The Tx state machine probes a transmission path to the remote peer.
It does this by sending Binding Requests and waiting for the
corresponding Responses. Each Tx state machine probes a single
component of a remote candidate.
The state transition diagram for the Tx state machine is as follows:
Start
|
v
+-----------+
| Waiting |
+-----------+
|
| Rx PROCEED
| ----------
Rx ERROR | Tx Req
-------- v
- +-----------+
------------| Testing |
| +-----------+
v |
+-----------+ | Rx SUCCESS
| Invalid | | ----------
+-----------+ | -
^ v
| +-----------+
------------| Valid |<-
Rx ERROR +-----------+ | Timer Tr
-------- | | --------
- --------- -
The Tx state machine starts out in the WAITING state. In this state,
it is waiting until it is allowed to proceed. (see section 3.3.1.
When the Tx state machine transitions to the TESTING state it sends a
Binding Request. This starts a little STUN state machine (not shown)
associated with the Tx state machine which resends the Binding
Request according to the exponential backoff procedure described in
[STUNbis].
At this point, the Tx state machine can receive either:
Cooper & Matthews Expires December 15, 2006 [Page 9]
Internet-Draft Eliminating Duplicate Checks June 2006
o A SUCCESS event, indicating that a successful Response was
received, OR
o An ERROR event, indicating that either a fatal error response was
received, or the retry limit was reached.
The SUCCESS event causes the Tx state machine to transition to the
VALID state, indicating that a successful outbound path to the remote
endpoint has been found. In this state, the Tx state machine resends
the Binding Request every Tr seconds.
3.3.1. Ordering the Tx State Machines
As per [ICE-08], the bindings created by ICE in intervening NATs must
be carefully rate-limited to ensure that the NAT is not overwhelmed
when creating new mapping and filtering entries. To achieve this,
most Tx state machines are initially placed on a 'pacing' queue.
Every Ta milliseconds, one state machine is removed from the queue
and started. A Tx state machine may be removed from the queue and
started early if an incoming STUN Binding Request reveals that the
intermediate NATs must already have the appropriate mapping and
filtering entries.
Since Tx state machines created for remote peer reflexive addresses
are only created as a result of incoming binding requests, they
always meet the above condition for early commencement. Tx state
machines of this type always go directly to the TESTING state and
bypass the 'pacing' queue.
[ICE-08] defines some sophisticated rules for ordering state machines
to ensure that both endpoints start their state machines in the same
order. With the splitting of the state machines into the Rx and Tx
state machines, having the same ordering on both endpoints is less
important. Simpler ordering rules could be adopted. However, we
stick with the [ICE-08] ordering rules to make direct comparison with
[ICE-08] simple.
Thus the ordering of Tx state machines follows the rules specified in
[ICE-08]. Specifically, and endpoint first orders the Tx candidate
pairs following the rules given in section 7.5 of [ICE-08], then sub-
orders the Tx state machines by component number.
One addition to the rules of section 7.5 of [ICE-08] required. When
moving the Tx candidate pair (Nac -> Rac) to the top of the list,
where Nac and Rac are the active candidates, it may be that there is
no such Tx candidate pair because Nac is not a base candidate. In
Cooper & Matthews Expires December 15, 2006 [Page 10]
Internet-Draft Eliminating Duplicate Checks June 2006
that case, select the Tx candidate pair (Nbc -> Rac) where Nbc is the
base candidate from which the active candidate Nac was derived.
3.4. Adding Candidates
Adding a candidate to either the CNC or CRC list is a key ICE
activity. Whenever this occurs, a number of Tx and Rx candidate
pairs are built, which leads to the creation of the Tx and Rx state
machines. The rules for creating candidate pairs and state machines
are given below.
3.4.1. Adding Native Candidates - Non Peer Reflexive
Whenever a (non-peer reflexive) native candidate is added to the CNC
list a number of Rx candidate pairs are made. Specifically, an Rx
candidate pair is created between the candidate and every remote
candidate in the CRC. These pairs cause the creation of an Rx state
machine for each pair of transport addresses with matching component
IDs. In addition, if the newly added native candidate is a base
candidate then a Tx candidate pair is created with every entry in the
CRC. These Tx candidate pairs result in the creation of a Tx state
machine for each pair of transport address with matching component
IDs.
3.4.2. Adding Native Candidates - Peer Reflexive
When adding a native peer reflexive candidate to the CNC list, the
newly added native candidate is only matched with the remote
generating candidate. As a result, only one Rx candidate pair is
created. This creates an Rx state machine for each pair of transport
addresses with matching component IDs. Peer reflexive candidates are
not base candidates, so no Tx candidate pairs or Tx state machines
are built.
3.4.3. Adding Remote Candidates - Non Peer Reflexive
When adding a (non-peer reflexive) candidate to the CRC list, an Rx
candidate pair is created with every candidate in the CNC list.
These pairs result in the creation of an Rx state machine for each
pair of transport addresses with matching component IDs. Tx
candidate pairs are also created, but only for the base candidates in
the CNC list. The Tx candidate pairs that are created result in Tx
state machines for every pair of transport addresses with matching
component IDs.
Cooper & Matthews Expires December 15, 2006 [Page 11]
Internet-Draft Eliminating Duplicate Checks June 2006
3.4.4. Adding Remote Candidates - Peer Reflexive
A newly created remote peer reflexive candidate is matched only with
the native generating candidate. This creates a single Tx candidate
pair and subsequent Tx state machines for each pair of transport
addresses with matching component IDs. No Rx candidate pairs or Rx
state machines are created for remote peer reflexive transport
addresses.
3.5. Promoting Candidates
If a native candidate has at least one Rx candidate pair for which
every associated Rx state machine is VALID, then the native candidate
is eligible for promotion. Following [ICE-08]:
o If the native candidate is currently the active candidate, then it
is already specified in the m/c line. Nothing more needs to be
done and no re-offer is triggered.
o If the native candidate is the highest priority candidate, then
the candidate is immediately promoted.
o Otherwise, the timer Tws is started (if it is not already
running). When the timer expires, the eligible candidate with the
highest priority (q value) is promoted.
As per [ICE-08], when a candidate is promoted the endpoint must
encode the remote candidate into the 'a-remote-candidate' attribute.
If there is more than one Rx candidate pair to choose from, the
remote candidate with the highest priority is selected.
3.6. Removing Candidates
A native candidate or remote candidate can be removed from one of the
current lists of candidates for reasons described in section 7.11 of
[ICE-08]. When this happens, all Rx and Tx candidate pairs and state
machines related to that candidate are destroyed.
3.7. Queuing Incoming Binding Requests for Later Processing
It is possible for an endpoint to receive a Binding Request where the
native and/or remote candidate is not known, but will become known
shortly. (Note: This situation also exists in [ICE-08]). For example,
the remote candidate will not be known on the Offerer if a Binding
Request from the Answerer arrives before the Answer itself.
Cooper & Matthews Expires December 15, 2006 [Page 12]
Internet-Draft Eliminating Duplicate Checks June 2006
To handle such cases efficiently, an endpoint does some initial
processing of the incoming Binding Request, and then queues the
Request until the native and/or remote candidate becomes known.
Since it is possible for the candidate to never become known, the
Binding Request must be discarded after some suitable time (say
100msec).
Whenever a candidate is added to the CRC or CNC list, the queue is
inspected (in message arrival order) for messages that can now be
processed.
3.8. Processing Received Binding Requests
This section describes, in bullet form, the processing when a Binding
Request arrives on a socket:
o Extract username and parse into "<native candidate id> ':' <native
component id> ':' <remote candidate id> ':' <remote component
id>". If there is no username or the parse fails, then this is not
an ICE connectivity check, but may be a STUN Binding Request for
some other usage.
o Look for a native candidate whose candidate id is a prefix of
<native candidate id>. Call this the <native candidate prefix>. If
none, discard packet.
[This will happen if the native candidate is a peer-reflexive
candidate. Doing the initial processing using the <native
candidate prefix> allows for faster discovery of working paths
in the cases described in section 3.7.
o Using the password associated with <native candidate prefix>,
check the message integrity of the packet. If it fails, discard
packet.
o Check packet for various other errors (e.g., <native component id>
out of range or not equal to <remote component id>). If it fails,
discard packet and (depending on the error) send an error
response.
o Extract the source transport address (SA) and destination
transport address (DA) from the packet.
o Send a Success Response. The DA of the Response is the SA of the
Request, and the Response is sent on the socket that the request
was received.
Cooper & Matthews Expires December 15, 2006 [Page 13]
Internet-Draft Eliminating Duplicate Checks June 2006
o Search for a Tx state machine whose remote candidate (component)
address is equal to SA of the Request, and whose native candidate
(component) address is equal to the DA from the Request. If such a
Tx state machine is found:
o If state == WAITING, remove it from the queue (which causes the
Tx state machine to transition to the TESTING state and send a
Binding Request).
o If state == TESTING, retransmit the Request.
o Otherwise, do nothing.
[This Tx state machine is sending with the same SA and DA as the
Response that was just sent. Since the endpoint just received a
Request in the opposite direction, we know that all bindings and
permissions are now in place and any previous Request that may
been lost should now get through.]
o If <native candidate id> is not in list of current native
candidates or if <remote candidate id> is not in list of current
remote candidates, then queue the request until both candidates
become known or until some wait time is exceeded. [See section
3.7. for why this is done].
o Generate an "Rx Req" event into the Rx state machine corresponding
to (<native candidate id>, <native component id>, <remote
candidate id>, <remote component id>).
o If the SA of the Request does not match the address of any
component of any remote candidate in the list of current
candidates, then we have learned a new remote peer-reflexive
address. This address is associated with component <remote
component id> of a remote candidate with id equal to "<remote
candidate id> <native candidate id>". This new peer-reflexive
candidate has the same number of components and the same q value
as the candidate <remote candidate id>. Learning this new address
may or may not complete the construction of this new remote
candidate, since there may still be other component addresses to
learn. If this new address does complete construction of the
candidate, then add it to the remote candidate list.
3.9. Processing Received Binding Responses
This section describes, in bullet form, the processing when a Binding
Response arrives on a socket:
Cooper & Matthews Expires December 15, 2006 [Page 14]
Internet-Draft Eliminating Duplicate Checks June 2006
o Extract the transaction ID, locate the corresponding request, and
determine the <remote candidate id>, <remote component id>,
<native candidate id> and <native component id> of the Request,
along with the Tx state machine that send the Request. If there is
no such Request, or if the Tx state machine no longer exists,
discard the packet.
o Check the message integrity of the packet using the password
associated with <remote candidate id>. If it fails, discard the
packet.
o If the Response is a non-fatal error response, then ignore it (let
the Tx state machine retry) and discard the packet.
o If the Response is a fatal error response, then send an ERROR
event into the Tx state machine and discard the packet.
o Else the Response is success response. Send a SUCCESS event into
the Tx state machine.
o If the mapped address from the packet does not match the transport
address of any component of any native candidate in the list of
native candidates, then we have learned a new native peer-
reflexive address. The address is associated with component
<native component id> of a new native candidate with id equal to
"<native candidate id> <remote candidate id>". This new peer-
reflexive candidate has the same number of components and the same
q value as the candidate <native candidate id>. Learning this new
address may or may not complete the construction of the candidate,
since there may still be other component addresses to learn. If
the new address does complete construction of the candidate, then
add it to the native candidate list.
4. Security Considerations
This document does not introduce any new security considerations
beyond those introduced by [ICE-08].
5. IANA Considerations
This document does not introduce any IANA considerations.
6. Acknowledgments
The authors would like to thank all those who read over a preliminary
version of this document and gave comments, most particularly Alan
Cooper & Matthews Expires December 15, 2006 [Page 15]
Internet-Draft Eliminating Duplicate Checks June 2006
Johnston, Benny Rodrig, and Dan Romascanu of Avaya, and Guylain
Lavoie of SIP stack vendor M5T.
Cooper & Matthews Expires December 15, 2006 [Page 16]
Internet-Draft Eliminating Duplicate Checks June 2006
7. References
7.1. Normative References
[ICE-08] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Methodology for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", draft-ietf-mmusic-
ice-08, work in progress.
[STUNbis] Rosenberg, J. et al, "Simple Traversal of UDP Through
Network Address Translators (NAT) (STUN), draft-ietf-
behave-rfc3489bis, work in progress.
[BEHAVE-UDP] Audet, F. and Jennings, C., "NAT Behavioral
Requirements for Unicast UDP", draft-ietf-behave-nat-udp,
work in progress.
7.2. Informative References
None
Author's Addresses
Eric Cooper
Avaya
1135 Innovation Drive
Ottawa, Ontario K2K 3G7
Canada
Phone: 613-592-4343 x228
Email: ecooper@avaya.com
Philip Matthews
Avaya
1135 Innovation Drive
Ottawa, Ontario K2K 3G7
Canada
Phone: 613-592-4343 x224
Email: philip.matthews@magma.ca
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
Cooper & Matthews Expires December 15, 2006 [Page 17]
Internet-Draft Eliminating Duplicate Checks June 2006
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 (2006).
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.
Cooper & Matthews Expires December 15, 2006 [Page 18]