Re: [Softwires] [Int-area] FW: New Version Notification for draft-xu-intarea-ip-in-udp-00.txt

[Tom Herbert <[e-mail]>]

Hi Xuxiaohu,

A few comments...

- It seems like the proposal is just to encapsulate IP in UDP
analogous to IPIP, so I'm not sure that the references to softwire are
particularly necessary.

- IP-in-UDP is already implement in Linux using foo-over-udp (as is
GRE-in-UDP, and IPv6-in-UDP), https://lwn.net/Articles/614348/. You
might also want to look at
http://people.netfilter.org/pablo/netdev0.1/papers/UDP-Encapsulation-in-Linux.pdf
for implementation details of UDP encapsulation.

- GUE can also be used to solve this same problem at the cost of four
additional bytes, but with the advantages of an extensible and generic
protocol (draft-ietf-nvo3-gue).

- I don't believe that it is a good to recommend not using IPv4
checksum in a protocol specification. This should be a MAY to set zero
for IPv4 checksum and the operator should decide what to do.  This is
because:

1) The UDP destination port is not covered by the IPv4 header
checksum. The IPv4 checksum protects against mis-delivery to wrong
address, but not to the wrong port. The UDP checksum does cover the
ports so would protect against mis-delivery to wrong port. Arguably,
mis-delivery to a port may be worse than mis-delivery to an address.
If a UDP packet is sent to wrong address but right port the receiver
will likely correctly interpret the packet as IP-in-UDP and will
either drop the packet because if it has no tunnel with the source
established, or will just decapsulate and forward the packet to the
inner destination. If the destination port is corrupted, the packet is
crossing applications so the results are nondeterministic.

2) Presumably, the rationale for not using the UDP checksum is to
avoid the performance hit in checksum calculation. However we have
found that for hosts using the most common deployed NICs, using the
UDP checksum with encapsulation is actually a performance benefit. See
the paper I linked above.

- Conversely, requiring the UDP checksum to be used with IPv6 is
probably not necessary. RFC6935 and RFC6936 provide conditions when a
tunneling protocol such as this can use a zero checksum for IPv6.
GRE-in-UDP defines specific requirements for zero checksum mode, some
of that could be replicated here (most likely as a subset since GRE
allows non-IP protocols which needed to be considered wrt checksum).

Tom




On Fri, Apr 17, 2015 at 12:28 AM, Xuxiaohu <[e-mail]> wrote:
> Hi all,
>
> This draft is a replacement of draft-xu-softwire-ip-in-udp (https://tools.ietf.org/html/draft-xu-softwire-ip-in-udp-03). Any comments are welcome.
>
> Best regards,
> Xiaohu
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> Sent: Friday, April 17, 2015 3:19 PM
>> To: Lucy yong; Yiu Lee; Xuxiaohu; Rajiv Asati; Xuxiaohu; Lucy yong; Iljitsch van
>> Beijnum; Yiu Lee; Yongbing Fan; Rajiv Asati; Iljitsch van Beijnum; Fan Yongbing
>> Subject: New Version Notification for draft-xu-intarea-ip-in-udp-00.txt
>>
>>
>> A new version of I-D, draft-xu-intarea-ip-in-udp-00.txt has been successfully
>> submitted by Xiaohu Xu and posted to the IETF repository.
>>
>> Name:         draft-xu-intarea-ip-in-udp
>> Revision:     00
>> Title:                Encapsulating IP in UDP
>> Document date:        2015-04-17
>> Group:                Individual Submission
>> Pages:                10
>> URL:
>> http://www.ietf.org/internet-drafts/draft-xu-intarea-ip-in-udp-00.txt
>> Status:         https://datatracker.ietf.org/doc/draft-xu-intarea-ip-in-udp/
>> Htmlized:       http://tools.ietf.org/html/draft-xu-intarea-ip-in-udp-00
>>
>>
>> Abstract:
>>    Existing Softwire encapsulation technologies are not adequate for
>>    efficient load balancing of Softwire service traffic across IP
>>    networks.  This document specifies additional Softwire encapsulation
>>    technology, referred to as IP-in-User Datagram Protocol (UDP), which
>>    can facilitate the load balancing of Softwire service traffic across
>>    IP networks.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area