Re: [Int-area] Why combine IP-in-UDP with GUE?

["Templin, Fred L" <[e-mail]>]

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
[e-mail]

> -----Original Message-----
> From: Int-area [mailto:[e-mail]] On Behalf Of Templin, Fred L
> Sent: Tuesday, April 28, 2015 3:16 PM
> To: Lucy yong; Joe Touch; Tom Herbert
> Cc: [e-mail]
> Subject: Re: [Int-area] Why combine IP-in-UDP with GUE?
> 
> Hi Lucy,
> 
> > -----Original Message-----
> > From: Lucy yong [mailto:[e-mail]]
> > Sent: Tuesday, April 28, 2015 2:51 PM
> > To: Joe Touch; Templin, Fred L; Tom Herbert
> > Cc: [e-mail]
> > 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
> [e-mail]
> 
> > Lucy
> >
> > -----Original Message-----
> > From: Joe Touch [mailto:[e-mail]]
> > Sent: Tuesday, April 28, 2015 3:14 PM
> > To: Lucy yong; Templin, Fred L; Tom Herbert
> > Cc: [e-mail]
> > 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area