Hi Tom, Thanks for your valuable comments. Please see my response inline.
> -----Original Message----- > From: Tom Herbert [mailto:[email protected]] > Sent: Friday, April 17, 2015 11:56 PM > To: Xuxiaohu > Cc: Internet Area; Softwires WG > Subject: Re: [Int-area] FW: New Version Notification for > draft-xu-intarea-ip-in-udp-00.txt > > 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. Your observation is correct that this proposal is just to encapsulate IP in UDP. Since all combinations of IP versions over one other (IPv4 over IPv6, IPv6 over IPv4, IPv4 over IPv4, IPv6 over IPv6) had ever been referred to as softwire encapsulation mechanisms in the IETF community (see https://tools.ietf.org/wg/softwire/charters), "softwire" is added to this proposal as a use case for IP-in-UDP. BTW, since I was told by the softwire co-chairs that the softwire WG is going to be shutdown and therefore would not be suitable for pursuing this proposal, I therefore renamed draft-xu-softwire-ip-in-udp (https://tools.ietf.org/html/draft-xu-softwire-ip-in-udp-03) and then submitted it to intarea WG. > - 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. I'm glad to see that IP-in-UDP has been implemented in Linux. Thanks for sharing this information. > - 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). Thanks for your above comments regarding UDP checksum. Those UDP checksum considerations which have been concluded in both RFC7510 (i.e., MPLS-in-UDP) and GRE-in-UDP draft and are applicable to IP-in-UDP case would be replicated to this draft later. Of course, if you have any additional suggestions based on your implementation of IP-in-UDP in Linux, that would be much appreciated. Best regards, Xiaohu > 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
