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 <[email protected]> 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: [email protected] [mailto:[email protected]] >> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
