Subject: [BEHAVE] I-D Action:draft-ietf-behave-turn-ipv6-07.txt

From: [email-masked]
Date: Wed, 14 Oct 2009 05:45:02 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.

	Title           : Traversal Using Relays around NAT (TURN) Extension for IPv6
	Author(s)       : S. Perreault, et al.
	Filename        : draft-ietf-behave-turn-ipv6-07.txt
	Pages           : 13
	Date            : 2009-10-14

This document adds IPv6 support to Traversal Using Relays around NAT
(TURN).  IPv6 support in TURN includes IPv4-to-IPv6, IPv6-to-IPv6,
and IPv6-to-IPv4 relaying.  This document defines the REQUESTED-
ADDRESS-FAMILY attribute for TURN.  The REQUESTED-ADDRESS-FAMILY
attribute allows a client to explicitly request the address type the
TURN server will allocate (e.g., an IPv4-only node may request the
TURN server to allocate an IPv6 address).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-ipv6-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 14 Oct 2009 08:52:07 -0400

On Wednesday 14 October 2009 08:45:02 [email-masked] wrote:
> 	Title           : Traversal Using Relays around NAT (TURN) Extension for
> IPv6 Author(s)       : S. Perreault, et al.

As requested by the authors, I took on the role of editor. My task was to 
bring this draft up to date with the current version of the TURN draft.

After careful review, I did not find any changes in the TURN draft that 
warranted changes in TURN-IPv6. I only updated the references and adjusted 
some wording.

One thing caught my attention: it seems that this draft implicitly ignores the 
presence of the DONT-FRAGMENT attribute. I made this fact explicit by adding 
the sentence "If present, the DONT-FRAGMENT attribute MUST be ignored by the 
server." This makes DONT-FRAGMENT only applicable to IPv4-IPv4 relay. Is this 
right? Discuss. ;)

I know of no other issue with this draft.

Thanks,
Simon
-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 19 Oct 2009 10:19:04 -0700

Some comments on this I-D:

- Section 1, 2nd paragraph: "This document also defines and registers a new
error response code with the value 444[...]"

The document also defines error response code 443.

- Section 3, 2nd paragraph: "Assuming the request is authenticated and has not
been tampered with[...]"

"has not been tampered with" is redundant.

- Section 4.2, 1st paragraph:

The action and error code to use in case of RESERVATION-TOKEN present are missing.

- Section 4.2, 5th and 6th:

I think that it should be explicitly specified that a TURN server implementing
this I-D but not supporting IPv4 allocation (i.e. only IPv4-IPv6 and IPv6-IPv6)
must return a 440 if the Allocate request received does not contain a
REQUESTED-ADDRESS-FAMILY attribute.

- Section 5.2:

Returning a 443 is probably better, at least if the family does not match the
Allocation.

- Section 8.3, last paragraph:

The DONT-FRAGMENT attribute should be followed for an IPv6 to IPv4 translation.

- Section 10.2:

The 443 error code is missing.

-- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Simon Perreault <[email-masked]>
Date: Thu, 22 Oct 2009 08:30:45 -0400

> The document also defines error response code 443.

Indeed. I also added it to the IANA considerations section.

> "has not been tampered with" is redundant.

True. I removed it.

> The action and error code to use in case of RESERVATION-TOKEN present are missing.

I added the following:

If it contains both a RESERVATION-TOKEN and a REQUESTED-ADDRESS-FAMILY, the
server replies with a 400 (Bad Request) Allocate Error Response.

> REQUESTED-ADDRESS-FAMILY attribute.

I added the following:

If allocation of IPv4 addresses is disabled by local policy, the server returns
a a 440 (Address Family not Supported) Allocate Error Response.

> Returning a 443 is probably better, at least if the family does not match the

Agreed. I changed it to the following:

If a server receives a Refresh Request with a REQUESTED-ADDRESS-FAMILY
attribute, and the attribute's value doesn't match the address family of the
allocation, the server MUST reply with a 443 (Peer Address Family Mismatch)
Refresh Error Response.

> The DONT-FRAGMENT attribute should be followed for an IPv6 to IPv4 translation.

That's what I thought too, but [draft-ietf-behave-v6v4-xlate-02] says to set
DF=1 systematically, except when you receive a fragment header.

Can you help me figure out what to replace the two ?'s below with?

- Preferred behaviour
  - DONT-FRAGMENT absent
    - Fragment header absent
      => Set DF=1
    - Fragment header present
      => Set DF=0
  - DONT-FRAGMENT present
    - Fragment header absent
      => Set DF=1
    - Fragment header present
      => Set DF=?
- Alternative behaviour
   - DONT-FRAGMENT absent
     => Set DF=?
   - DONT-FRAGMENT present
     => Set DF=1

> The 443 error code is missing.

Added.

Thanks,
Simon