Subject: Re: [BEHAVE] WGLC: TURN and TURN-IPv6 (draft-ietf-behave-turn-11, draft-ietf-behave-turn-ipv6-05)

From: Magnus Westerlund <[email-masked]>
Date: Thu, 04 Dec 2008 13:29:03 +0100

Philip Matthews skrev:
>>>>
>>>> 4. Section 12: IPv4 fragmentation field:
>>>>
>>>> I think the preferred behavior needs to mention the need to refuse
>>>> sending a packet if it requires fragmentation and the DF was set on the
>>>> incoming packet. Which also includes the need to generate an ICMP
>>>> message. This should never happen in the client to peer direction but
>>>> may happen in the reverse direction due to the encapsulation.
>>>
>>> This was in the text in this section in TURN-09, and I considered
>>> keeping it in TURN-11. However, in my opinion, the text in section 12 of
>>> TURN-11 describes the forwarding behavior from the point-of-view of an
>>> application that sits on top of the OS, whereas the behavior you
>>> describe would be implemented by the OS itself. But, if you can provide
>>> me a reference to a section of an RFC that describes this behavior, I
>>> will be happy to insert the reference.
>>>
>>
>> The reference would be to 1812 and the need to support both
>> fragmentation and the capability of sending ICMP, i.e. section 5.2.7.1
>> of RFC 1812.
>>
>> In general I don't think there is a good reference because we are moving
>> router functionality partially into an end-host. Thus things like this
>> needs to be clearly defined. That is why I do like this to be explicitly
>> mentioned as expected behavior.
> 
> 
> I have two concerns:
> *) First, in most implementations, the code to do fragmentation will be
> inside the kernel and not under the control of the implementor of the
> TURN server.
> *) Second, this code will not send any ICMP error message, because it
> views the IP packet as originating from the server itself.
> 
> So I propose to add the following sentence:
>      In both the Preferred and Alternate Behaviors, the resulting
>      packet may be too large for the outgoing link. If this is the
>      case, then the normal fragmentation rules apply [RFC1122].
> 
> The Host Requirements RFC seems to me to be the most appropriate
> reference for this behavior.
> 
> Is this acceptable?

Philip, I don't understand why fragmentation gets different treatment.
We have the differentiation between preferred and alternative because to
implement TURN with preferred behavior you need to have low level
access. So why is handling fragmentation so much more difficult than to
handle ECN field or TTL field? I know that it is a bit more writing to
do, but I think we know what the right behavior would be.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave