draft-ietf-tram-turnbis-03.txt   draft-ietf-tram-turnbis-04.txt 
TRAM WG T. Reddy, Ed. TRAM WG T. Reddy, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track A. Johnston, Ed. Intended status: Standards Track A. Johnston, Ed.
Expires: October 11, 2015 Avaya Expires: October 17, 2015 Avaya
P. Matthews P. Matthews
Alcatel-Lucent Alcatel-Lucent
J. Rosenberg J. Rosenberg
jdrosen.net jdrosen.net
April 9, 2015 April 15, 2015
Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Using Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN) Traversal Utilities for NAT (STUN)
draft-ietf-tram-turnbis-03 draft-ietf-tram-turnbis-04
Abstract Abstract
If a host is located behind a NAT, then in certain situations it can If a host is located behind a NAT, then in certain situations it can
be impossible for that host to communicate directly with other hosts be impossible for that host to communicate directly with other hosts
(peers). In these situations, it is necessary for the host to use (peers). In these situations, it is necessary for the host to use
the services of an intermediate node that acts as a communication the services of an intermediate node that acts as a communication
relay. This specification defines a protocol, called TURN (Traversal relay. This specification defines a protocol, called TURN (Traversal
Using Relays around NAT), that allows the host to control the Using Relays around NAT), that allows the host to control the
operation of the relay and to exchange packets with its peers using operation of the relay and to exchange packets with its peers using
skipping to change at page 1, line 49 skipping to change at page 1, line 49
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 11, 2015. This Internet-Draft will expire on October 17, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 33, line 21 skipping to change at page 33, line 21
includes a LIFETIME attribute with the requested value. The server includes a LIFETIME attribute with the requested value. The server
then computes a new time-to-expiry value in the same way as it does then computes a new time-to-expiry value in the same way as it does
for an Allocate transaction, with the exception that a requested for an Allocate transaction, with the exception that a requested
lifetime of 0 causes the server to immediately delete the allocation. lifetime of 0 causes the server to immediately delete the allocation.
7.2. Receiving a Refresh Request 7.2. Receiving a Refresh Request
When the server receives a Refresh request, it processes it as per When the server receives a Refresh request, it processes it as per
Section 4 plus the specific rules mentioned here. Section 4 plus the specific rules mentioned here.
If the server receives a Refresh Request with an ADDITIONAL-ADDRESS- If the server receives a Refresh Request with an REQUESTED-ADDRESS-
FAMILY attribute and the attribute value does not match the address FAMILY attribute and the attribute value does not match the address
family of the allocation, the server MUST reply with a 443 (Peer family of the allocation, the server MUST reply with a 443 (Peer
Address Family Mismatch) Refresh error response. Address Family Mismatch) Refresh error response.
The server computes a value called the "desired lifetime" as follows: The server computes a value called the "desired lifetime" as follows:
if the request contains a LIFETIME attribute and the attribute value if the request contains a LIFETIME attribute and the attribute value
is 0, then the "desired lifetime" is 0. Otherwise, if the request is 0, then the "desired lifetime" is 0. Otherwise, if the request
contains a LIFETIME attribute, then the server computes the minimum contains a LIFETIME attribute, then the server computes the minimum
of the client's requested lifetime and the server's maximum allowed of the client's requested lifetime and the server's maximum allowed
lifetime. If this computed value is greater than the default lifetime. If this computed value is greater than the default
skipping to change at page 54, line 12 skipping to change at page 54, line 12
attribute in a subsequent Allocate request to request the server use attribute in a subsequent Allocate request to request the server use
that relayed transport address for the allocation. that relayed transport address for the allocation.
The attribute value is 8 bytes and contains the token value. The attribute value is 8 bytes and contains the token value.
15.11. ADDITIONAL-ADDRESS-FAMILY 15.11. ADDITIONAL-ADDRESS-FAMILY
This attribute is used by clients to request the allocation of a IPv4 This attribute is used by clients to request the allocation of a IPv4
and IPv6 address type from a server. It is encoded in the same way and IPv6 address type from a server. It is encoded in the same way
as REQUESTED-ADDRESS-FAMILY Section 15.6. The ADDITIONAL-ADDRESS- as REQUESTED-ADDRESS-FAMILY Section 15.6. The ADDITIONAL-ADDRESS-
FAMILY attribute MAY be present in Allocate or Refresh requests. The FAMILY attribute MAY be present in Allocate request. The attribute
attribute value of 0x02 (IPv6 address) is the only valid value in value of 0x02 (IPv6 address) is the only valid value in Allocate
Allocate request. request.
15.12. ADDRESS-ERROR-CODE Attribute 15.12. ADDRESS-ERROR-CODE Attribute
This attribute is used by servers to signal the reason for not This attribute is used by servers to signal the reason for not
allocating the requested address family. The following is the format allocating the requested address family. The following is the format
of the ADDRESS-ERROR-CODE attribute. of the ADDRESS-ERROR-CODE attribute.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 End of changes. 6 change blocks. 
8 lines changed or deleted 8 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/