Re: [tram] AD Evaluation of draft-ietf-tram-turnbis-23

["Konda, Tirumaleswar Reddy" <[e-mail]>]

Thanks Magnus for the clarification, I will update the new section and publish revised draft.

Cheers,
-Tiru

From: Magnus Westerlund <[e-mail]>
Sent: Friday, May 10, 2019 9:16 PM
To: Konda, Tirumaleswar Reddy <[e-mail]>; [e-mail]; [e-mail]
Subject: Re: [tram] AD Evaluation of draft-ietf-tram-turnbis-23


CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.


________________________________
Hi,

Regarding the two questions.


On 2019-05-05 08:08, Konda, Tirumaleswar Reddy wrote:


 IPv4 Options



      Preferred Behavior: The outgoing packet is sent without any IPv4

      options.



 [TR] I will add IPv4 options.



IPv6 Extensions Headers:



      Set per default for originated IPv6 packets.



[TR] The behavior is already discussed in IPv6-to-IPv6 translations, https://tools.ietf.org/html/draft-ietf-tram-turnbis-24#section-14 (IP header fields)section does not discuss extension headers.

Like before this is section 14 text, and not a translation scenario.

[TR2] I meant section 14 (IP Header Fields) for UDP-to-UDP translation does not discuss IPv6 extension header, any specific reason the new section (IP Headers fields for TCP-to-UDP translation) should discuss IPv6 Extension headers (it is already covered in Sections 13.1 and 13.2) ?

So my reasoning is that Section 14 covers packets that are considered sourced by the TURN server, while 13.2 only covers translation scenarios where there are a one-to-one correspondence and there are possible to do a information transfer. As that isn't possible in the TCP <-> UDP context we are discussing I think you can either include it in Section 14. Alternatively expand section 13.1 and 13.2 to include this case also. But I think the later requires more text to clarify which cases where there are no one-to-one correspondence?



Fragmentation:



Any fragmented packets are reassembled in server and then forwarded to the client over the TCP connection.

ICMP messages resulting from sent UDP packets, MUST be forward to client using TURN's mechanism for relevant ICMP types.



IPv4 Options are processed by server if possible, else ignored



[TR] Let’s use the same behavior as UDP-to-UDP translation for IPv4 options.

I can't find that there are anything at all written about this, and that is likely fine. Or did you have any particular text in mind? In that case please quote.

[TR2] I will add the following lines:
   IPv4 Options

      Preferred Behavior: The outgoing packet is sent without any IPv4
      options.

      Alternate Behavior: Same as preferred.


If the peer avoids UDP fragmentation, I don’t get the use of the proposed line “Any fragmented packets are reassembled in server and then forwarded to the client over the TCP connection.”

I don't think the peer are mandated to set the DF bit, and thus fragmented packets could arrive at the TURN server from the peer. In that case re-assembly do need to happen at the TURN server. It is fairly obvious that this is what should be happening. But this description is already at the level of details that enables a IP packet level implementation  to not forget things, so why leave this out?



Cheers



Magnus Westerlund



----------------------------------------------------------------------

Network Architecture & Protocols, Ericsson Research

----------------------------------------------------------------------

Ericsson AB                 | Phone  [phone]

Torshamnsgatan 23           | Mobile [phone]

SE-164 80 Stockholm, Sweden | mailto: [e-mail]<mailto:[e-mail]>

----------------------------------------------------------------------