Hi, I will say also that there is something broken about IP-in-UDP without combining with GUE. If the tunnel needs to fragment, the only option is to fragment at the IP layer and not the tunnel layer. But then, if the outer IP layer is IPv4, we are limited by the 16-bit ID field. If the outer IP layer is IPv6, there are concerns for dropping of IPv6 fragments as has been reported in v6ops and 6man.
Combining with GUE allows for tunnel fragmentation, which is the correct layer for fragmentation to take place: https://datatracker.ietf.org/doc/draft-herbert-gue-fragmentation/ Thanks - Fred [email protected] > -----Original Message----- > From: Int-area [mailto:[email protected]] On Behalf Of Templin, Fred L > Sent: Tuesday, April 28, 2015 3:16 PM > To: Lucy yong; Joe Touch; Tom Herbert > Cc: [email protected] > Subject: Re: [Int-area] Why combine IP-in-UDP with GUE? > > Hi Lucy, > > > -----Original Message----- > > From: Lucy yong [mailto:[email protected]] > > Sent: Tuesday, April 28, 2015 2:51 PM > > To: Joe Touch; Templin, Fred L; Tom Herbert > > Cc: [email protected] > > Subject: RE: [Int-area] Why combine IP-in-UDP with GUE? > > > > Joe and Fred, > > > > If a packet/payload is IP protocol, it is fine to check the first nibble of > > it to determine IPv4 or IPv6. > > > > But we don't adopt this encoding into another protocol and identify IP (v4 > > or v6) from it, i.e., the compression mechanism. > > Then, you miss the opportunity to have the best of both worlds in a single > packaging. Call it GUE or something else, but there is no reason to split it > into two docs and miss out on a useful header compression. > > Thanks - Fred > [email protected] > > > Lucy > > > > -----Original Message----- > > From: Joe Touch [mailto:[email protected]] > > Sent: Tuesday, April 28, 2015 3:14 PM > > To: Lucy yong; Templin, Fred L; Tom Herbert > > Cc: [email protected] > > Subject: Re: [Int-area] Why combine IP-in-UDP with GUE? > > > > > > >> [Lucy] since GUE aims to encapsulation for a payload, it needs a > > > payload field. > > > > If GUE encapsulates only IPv4 and IPv6, it would need no payload type field. > > > > If GUE encapsulates other payloads as well as IPv4 and IPv6, then it needs > > a payload type field. However, one type should be "IP". > > > > There is no reason for having the GUE header differentiate between > > payload=IPv4 and payload=IPv6. The IP version is addressed by the version > > field of the IP header. If GUE encapsulates both type of > IP > > the same way (and it should), it should NOT differentiate between them in > > its (GUE) header. > > > > > You suggest that making exception for IPv4 and IPv6, i.e. > > > using first nibble to determine. I am not sure when the first nibble > > > indicate IPv4, does it mean Fred's compression case or GUE header with > > > IPv4 payload. > > > > In this case, you would want a way to differentiate between the following > > UDP payloads: > > > > - IP payload (IPv4 or IPv6) > > - compressed IPv4 or IPv6 payload > > - GUE payload > > which could have IPv4 or IPv6 inside > > > > If these are the first thing after the UDP header, then the UDP header is > > the only way to differentiate - that's what we use > destination > > transport port numbers for. > > > > However, once you say "it's IP", then the IP payload - whether inside UDP > > directly (IP-in-UDP), inside GUE inside UDP, or inside a > > compression header inside UDP, then the IP payload ought to indicate what > > type of IP it is. > > > > The point is simple: > > > > IP is a protocol that has versions > > > > We should treat it as such, not treat every individual version of IP as a > > separate encapsulation. > > > > Joe > > > > > > > > > > Lucy > > > > > > Joe > > > > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
