Re: [spring] SRv6 Network Programming: ENH = 59

["Joel M. Halpern" <[e-mail]>]

Two separate things.
First, it clearly is not just about IP processing or we would have no 
next-headers for TCP, UDP, or tunnels.  Which we do.
Second, we have a value that means that Ethernet Follows.  So clearly it 
is no-header is no for the Ethernet case.
Finally, since we have a value thaqt means Ethernet, why would we 
instead stretch some other value to sometimes mean Ethernet.

While there may have been some thought that it might be an extension 
mechanism, I have never read it as meaning that, and I have never seen a 
case where we would want to use "no-next-header" to mean "next header of 
some other kind."

Since we don't need it for this case, I guess we can disagree about 
whether in theory some other case might be allowed.

Yours,
Joel

On 5/9/19 8:52 AM, Ole Troan wrote:
> Joel,
> 
>> No next header means exactly what the original request, and the documentation, says.  There is nothing in the packet past this IP header.  It does not mean that there is some next header defined by some other context.
> 
> Why allow for payload to follow and a "must" requirement to forward it, unless as a future extension point.
> 
> And kre also alludes to a "or something" and "other in the future"...
> 
> It certainly does not mean nothing is past this IP header. Nor does it mean that there is some next header defined by some other context.
> It is an extension point. If people found some use for that, what's the harm? That middle boxes get confused? Isn't that a feature? ;-)
> 
> Cheers,
> Ole
> 
>>
>> Yours,
>> Joel
>>
>> On 5/9/19 8:36 AM, Ole Troan wrote:
>>>> I think it is equally important to note that given an existing way of encapsulating Ethernet in IP, one ought to have a good reason for creating a different one.  There is no indication that this use case needs anything different than next-header 97.
>>>>
>>>> And Ole, no next-header does not, as far as I can tell from 8200 and its predecessors mean "the end of IP processing."
>>> Huh? What do you think it means then?
>>> Btw, here is the original request for the no-next-header:
>>> Date: Mon, 28 Nov 1994 14:46:50 +1100
>>> Message-Id: <[e-mail]>
>>> From: Robert Elz <[e-mail]>
>>> Sender: [e-mail]
>>> Precedence: bulk
>>> Reply-To: [e-mail]
>>> If I wanted to send an IP6 packet without any TCP, UDP, ICMP,
>>> or similar, data, just, say, end to end options, or something,
>>> which may be useful for sopme purpose or other in the futuew,
>>> what do I stick in the next header field?
>>> The length from the packet header will indicate that there's
>>> nothing after the last processed header, but just sticking in
>>> a random "next header" value and relying on the length field
>>> seems wrong to me.
>>> Alternatively, can someone say that its illegal to not have
>>> one of the transport level protocols in every IP6 packet,
>>> and will be for all (relevant) time?
>>> kre
>