On 4/28/2015 10:36 AM, Templin, Fred L wrote: > Hi Joe, > >> -----Original Message----- >> From: Joe Touch [mailto:[email protected]] >> Sent: Tuesday, April 28, 2015 10:29 AM >> To: Templin, Fred L; Tom Herbert >> Cc: [email protected] >> Subject: Re: [Int-area] Why combine IP-in-UDP with GUE? >> >> >> >> On 4/28/2015 10:13 AM, Templin, Fred L wrote: >>> Hi Tom, >> >> ... >>>>>> Without any optional fields or flags, the difference with GUE is an >>>>>> additional four byte header between the UDP header and the >>>>>> encapsulated IP header. For IPv4 that header is 0x00040000, and for >>>>>> IPv6 the header is 0x00290000 >> >> ... >>> This loops back again to whether the first four bits of the payload could >>> be used such as: >>> >>> 4 - a native IPv4 packet >>> 6 - a native IPv6 packet >>> X - a GUE-encapsulated packet >> >> It loops back to what the service is. >> >> Encapsulation of IP is a service. >> >> There is no justification for differentiating between encapsulation of >> IPv4 and IPv6 at the GUE or IP-in-UDP layer. >> >> Nothing on the path should need to see what kind of IP packet it is. If >> it does, it can easily parse the first for bits of the IP-in-UDP or GUE >> payload - NOT the UDP payload. > > What I mean to say is "the first four bits immediately following the UDP > header". At least, that is what IP-in-UDP and AERO say. Were you thinking > there would be some other four bits?
It's more clear if we just say "the first four bits of the IP header" - wherever the encapsulation puts that header. If that's the case, there's no issue in interpreting X=4 or X=6. We can't assign meanings to other values without a standards-track doc. We CAN put a flag bit/field in a shim header that explains that the service carries more than just IP, and the flag bit/field indicates "next protocol=IP" or "next protocol=signal", etc. Joe _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
