Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-ipv6-05

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 01 Mar 2009 13:09:50 +0200

Hi Philip,

thanks for your comments. I am adding them to my working copy of the
next revision of the draft (06), which I will try to submit shortly. My
answers inline:

> *) I would like to see the abstract, Introduction, and Overview
> sections focus more on the overall idea of adding IPv6 support to
> TURN, with the associated concepts of relaying v6-to-v6 and
> v4-to-v6/v6-to-v4. Personally, I think that is the big concept that
> this draft needs to define. Once that is done, adding a way for the
> client to specify the address family of the relayed-transport-address
> seems just a little add-on.

Done.

> *) Must a TURN server implementing this draft support
> v4-to-v6/v6-to-v4 relaying? What about v6-to-v6 relaying? Personally,
> I feel that a server should be able to conform to this draft if it
> just supports the REQUESTED-ADDRESS-TYPE attribute and only relays 
> v4-to-v4. Whatever decision is made, I think the draft should make a
> definite statement on these points.

There was another comment on the list on this topic stating that
supporting this extension should imply that the server can handle IPv6
packets. Once a server can handle IPv6 packets, it is assumed it can
perform the three types of relaying you list above. If there are no good
reasons for a server to support only a subset of them, we do not need to
add any more complexity here. I have added the following text:

"A TURN server that supports a set of address families is assumed to be
able to relay packets between them. If a server does not support the
address family requested by a client, the server returns a 440
(Address Family not Supported) error response."

> *) I think the draft needs to state the following: a) That the client
> transport address and the server transport address must use the same
> address family; b) That the relayed-transport-address and all peer
> transport addresses must use the same address family; c) That the
> addresses in permissions and channel bindings are of the same family
> as the relayed-transport-address. Actually, points (a) and (b) need
> more words, since the actual address families can differ if a NAT64
> or NAT46 sits in the path between the client and the server, or the
> server and a peer. What must be true is that the address families as
> seen by the client and as seen by the server must be the same.

I do not think we need to say anything about a) because from the point
of view of the server and of the client, the address families will
always be the same.

Statements b) and c) go together. I have specified c), which also covers b).

> *) This draft proposes an error code 440 "Address Family not
> supported". But I think this error code needs to be redefined as
> "Requested address family relaying not supported". For example, if a
> server supports only v4-to-v4 and v6-to-v6 relaying, and it receives
> an Allocate request with a REQUESTED-ADDRESS-TYPE attribute
> specifying IPv6 on a IPv4 server address, then the problem is not
> that IPv6 is not supported, but that v4-to-v6 relaying is not 
> supported.

See discussion on this point above.

> *) I think this draft needs to define an additional error code: "Peer
>  address family mismatch". This error code is returned whenever a 
> CreatePermission or ChannelBind request is received with an 
> XOR-PEER-ADDRESS attribute whose address family does not match the 
> address family of the relayed-transport-address. Similarly, I think
> this draft needs to define what happens when a Send or Data
> indication is received where the XOR-PEER-ADDRESS attribute contains
> an address of the wrong family.

Done as part of the specification of c) above.

> *) This draft defines how a TURN server reacts if a Refresh request 
> contains an (unexpected) REQUESTED-ADDRESS-TYPE attribute. This may
> be desirable, but I will note that the base TURN spec says nothing
> similar about all the other attribute of TURN. Furthermore, this
> draft says nothing about an unexpected REQUESTED-ADDRESS-TYPE
> attribute in a CreatePermission, ChannelBind, Send, or Data message. 
> So I think the WG needs to decide that either such behavior needs to
> be specified, or that it does not need to be specified, and the two
> drafts updated appropriately.

You are right that specifications cannot specify every possible error
case. However, they should specify those error cases that appear more
often or that are particularly confusing. I think this error case is one
of them. So, I suggest we leave it as is.

> *) The draft references the SIIT spec (RFC 2765) for the details of
> how to translate v4-to-v6 and v6-to-v4. However, the base TURN
> specification is carefully written so that a TURN server can be
> implemented by a userland process without special privileges, and
> unfortunately most of the translations specified by SIIT require
> detailed header access of the kind not normally available to an
> un-privileged userland process. In my opinion, we want to preserve
> this property of TURN, and thus this draft should define translations
> that satisfy this constraint.

Done.

> *) The above comment also applies to the v6-to-v6 relaying rules 
> specified in section 6 of this draft. Some of the v6-to-v6 rules 
> specified cannot normally be implemented by an un-privileged userland
>  process. For example, un-privileged userland processes cannot
> typically send ICMP messages.

Done.

> *) Section 12 of the base TURN spec describes header field processing
> in terms of Preferred and Alternate behaviors. I think that section 6
> of this draft should do the same.
> 
> 
> *) Suggestion: rename REQUESTED-ADDRESS-TYPE to 
> REQUESTED-ADDRESS-FAMILY. I feel this would make the purpose of the 
> attribute clearer.

Done.

 From a different email:

> Two additional comments.
> 
> *) If the RESERVATION-TOKEN attribute is present in the Allocate
> request, then I think the REQUESTED-ADDRESS-TYPE attribute must not
> be present, and the address family is determined from the reserved
> transport address. Furthermore, I suggest that we allow the Allocate
> request containing the RESERVATION-TOKEN attribute to arrive over any
> transport (as is done today), including over a different address
> family -- thus it is possible that this subsequent request will
> involve a different form of relaying. (I.e., the first request might
> be v4-to-v4 relaying, while the second is v6-to-v4 relaying).

Done.

> *) The draft says:
> 
> If the REQUESTED-ADDRESS-TYPE attribute is absent, the server MUST 
> allocate an IPv4 transport address to the TURN client.
> 
> If the request does not contain a REQUESTED-ADDRESS-TYPE attribute,
> then it is from an client that supports only v4-to-v4 relaying. So I
> am thinking that the server should reject this request if it arrives
> on a v6 server transport address.

See discussion on this point above.

Thanks,

Gonzalo

---

From: Christian Huitema <[email-masked]>
Date: Sun, 1 Mar 2009 18:35:02 -0800

> (Address Family not Supported) error response."

I think that the draft confuses relaying and translation. TURN is "a transport relay". The client uses TURN to obtain an address + port pair that will be reachable by its peers. Packets received by the server on that address are forwarded to the client, and the client can send packets from that address.

As stated in Philip's original comment, the implementation will be much simpler and much less error prone if we specify that "the relayed-transport-address and all peer transport addresses must use the same address family."

That means the TURN server should not engage in explicit packet conversion. If the client obtained from the server the address "1.2.3.4" and tries to send a packet through that address to "2001:2::3:4", the SEND request should fail.

If the client needs both IPv4 and IPv6 connectivity from a TURN server, it should request two separate relay addresses.

-- Christian Huitema

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 02 Mar 2009 09:56:45 +0200

Hi,

> As stated in Philip's original comment, the implementation will be
> much simpler and much less error prone if we specify that "the
> relayed-transport-address and all peer transport addresses must use
> the same address family."

yes, and I agreed to that in my previous email. We are on the same page.

Thanks,

Gonzalo