Subject: Re: [Int-area] Existing use of IP protocol 114 (any 0-hop protocol)

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 23 Sep 2019 08:40:37 +0000

Thank you all for your unicast, multicast replies and the educated pieces of information sent. I even went in the Internet history museum ;-)

Based on the provided information, I will recommend to the draft-zhu-intarea-gma authors:

  1.  As it is an informational independent stream with little traction, to keep using the IP protocol 114;
  2.  BUT, the I-D should be revised to specify a hop-limit of 0 for IPv6 (RFC 8200) and time-to-live of 1 for IPv4 (RFC 791). The balance of local-only packet leak prevention (HL=0) and security (HL=255) in this case should be on preventing the leak of the local-only packets outside the ‘local domain’ to the Internet or to another domain which could use this IP protocol.
  3.  Any other standard track IETF stream document (including this one may be in the future) should request a new IP protocol number if required. The last assigned IP protocol number AFAIK was for HIP in 2015 and there are more than 40% remaining.

Now, it would nice to have a volunteer to write a document to finally document those “Any bla” protocol number by putting common sense restrictions/constraints on them (protocols 9/IGP, 61/host internal, 63/local network, 68/distributed FS, 99/private encryption scheme, 114/0-hop).

Regards

-éric

From: Int-area <[email-masked]> on behalf of Eric Vyncke <[email-masked]>
Date: Thursday, 19 September 2019 at 17:07
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [Int-area] Existing use of IP protocol 114 (any 0-hop protocol)

The authors of https://tools.ietf.org/id/draft-zhu-intarea-gma-03.txt would like to use IP protocol 114 as it is described as “Any 0-hop protocol” on the IANA page[1]. Alas, on the IANA page, there is no reference to this “Any 0-hop protocol”.

Obviously, we all understand that this must be a protocol using hop limit = 0 (or TTL=0 for the legacy protocol).

When there is no reference for a IANA number, this means that this number was assigned _before_ IANA, possibly by J. Postel and nobody at IANA and in the IESG know more. Hence, my questions to the community:

Q1) does anyone know about a more formal reference / specification for this protocol 114

Q2) does anyone know about a RFC or a protocol using this protocol 114 ?

Please note that I do not ask for comments/reviews on the draft itself (they are welcome though on the [email-masked]<mailto:[email-masked]> mailing list even if this is not a WG document). And it is also mostly obvious that only one transport layer can exist on the top of this protocol.

Regards,

-éric (INT AD)

[1] https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

---

From: Joe Touch <[email-masked]>
Date: Sat, 28 Sep 2019 08:15:36 -0700

Hi, Eric,

> On Sep 23, 2019, at 1:40 AM, Eric Vyncke (evyncke) <[email-masked]> wrote:
> 

For the same reasons Bob mentions, I think this isn’t needed.

We don’t need to encourage playing with these code points for experiments; better a protocol designer go through the standards-track process, at which point they can either use one of these codepoints or get a new one.

Joe

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 30 Sep 2019 19:03:45 +0900

Joe Touch wrote:

>> Now, it would nice to have a volunteer to write a document to
>> finally document those “Any bla” protocol number by putting common
>> sense restrictions/constraints on them (protocols 9/IGP, 61/host
>> internal, 63/local network, 68/distributed FS, 99/private
>> encryption scheme, 114/0-hop).
> 
> We don’t need to encourage playing with these code points for
> experiments; better a protocol designer go through the
> standards-track process, at which point they can either use one of
> these codepoints or get a new one.

I don't think we need a document either, but, to clarify who
choose the actual protocol (not IESG, nor protocol developers),
the following footnote in the IANA page may be helpful:

	The actual protocol used with the number is determined
	at the discretion of local administrator as long as
	the protocol is locally unique.

Though it may make wireshark developers unhappy, it was the
intention of IANA.

						Masataka Ohta

---

From: Joe Touch <[email-masked]>
Date: Mon, 30 Sep 2019 07:05:27 -0700

> On Sep 30, 2019, at 3:03 AM, Masataka Ohta <[email-masked]> wrote:
> ...

That footnote is accurate for nearly every code point on the Internet - code points have known meaning only in the domain of use and must be unique within that domain.

A note might be useful to indicate that the RFC isn’t accidentally missing, i.e.,:

	This protocol is not specified and varies.

JOe

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 30 Sep 2019 18:50:06 +0000

Masataka, Joe and Bob,

I think we agree even if my wording was ambiguous: the community should define 'what to do' with those 'any *' IP protocols that are not specified anywhere. And the definition could be "do not use" but follow the process to get a new IP protocol with some 'fences' to avoid wasting the remaining 42% of those IP protocol numbers.

=> the current 'ambiguous' situation does not seem too good to me

-éric

On 30/09/2019, 12:04, "ietf on behalf of Masataka Ohta" <[email-masked] on behalf of [email-masked]> wrote:

    

    
    						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 1 Oct 2019 05:20:59 +0900

Joe Touch wrote:

> That footnote is accurate for nearly every code point on the Internet
> - code points have known meaning only in the domain of use and must
> be unique within that domain.

If we ignore IANA registration, we are free to use any protocol
with any protocol number. However, footnote in an IANA page
is for people following the IANA registration.

Eric Vyncke (evyncke) wrote:> Masataka, Joe and Bob,

 > => the current 'ambiguous' situation does not seem too good to me

If you want to change the current situation, you certainly need
an rfc. But, I'm just conservative.

Note also that protocol number for IGP is not very ambiguous, because
it is reasonable to assume there is only one IGP used in a domain.

							Masataka Ohta

---

From: Dick Franks <[email-masked]>
Date: Mon, 30 Sep 2019 21:40:05 +0100

The pragmatic alternative might be a short document listing protocol
numbers believed to be lying fallow.
Protocol numbers may then be reclaimed by interested parties filing
appropriate documentation before some sunset date TBD, beyond which
said code points would be marked "unassigned" in the IANA registry.

Dick Franks
________________________

---

From: Bob Hinden <[email-masked]>
Date: Mon, 30 Sep 2019 14:36:18 -0700

Eric,

> On Sep 30, 2019, at 11:50 AM, Eric Vyncke (evyncke) <[email-masked]> wrote:
> 
> Masataka, Joe and Bob,
> 

My take is doing anything isn’t necessary.  Two reasons:

1) We aren’t close to running out.  The registry shows:

143-252		Unassigned

That a lot of room in the registry given the current assignment rate.

2)  The second reason is that I think the reason for few IANA allocation requests in this registry is that it is likely that packets containing any new assignments will be blocked in firewalls and middle boxes.   It’s hard to get a new protocol deployed.   I am doubtful this will change anytime soon.   I suspect we will never run out, unless the Internet changes significantly.

The most I can see doing is to ask IANA to let the IETF community know when we have reached some milestone, like 90% of the space has been assigned.

Thanks,
Bob

---

From: Keith Moore <[email-masked]>
Date: Mon, 30 Sep 2019 23:15:46 -0400

> 2)  The second reason is that I think the reason for few IANA allocation requests in this registry is that it is likely that packets containing any new assignments will be blocked in firewalls and…

I'm always amused, and a bit concerned, by the assumption that the 
Internet will not change significantly.   From my perspective, the 
Internet seems to constantly change.   Not long ago it was hard to 
imagine any new transport protocol getting much traction, for example.  
And the tussles between the application writers and enterprise network 
operators haven't gone away.

Keith

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 1 Oct 2019 12:34:12 +0900

Bob Hinden wrote:

 > My take is doing anything isn’t necessary.

OK.

> 2)  The second reason is that I think the reason for few IANA
> allocation requests in this registry is that it is likely that
> packets containing any new assignments will be blocked in firewalls
> and middle boxes.   It’s hard to get a new protocol deployed.   I am
> doubtful this will change anytime soon.   I suspect we will never run
> out, unless the Internet changes significantly.

Your argument is not applicable to protocols used between routers,
though there won't be so many such protocols standardized.

						Masataka Ohta

---

From: Nico Williams <[email-masked]>
Date: Mon, 30 Sep 2019 23:21:12 -0500

On Mon, Sep 30, 2019 at 11:15:46PM -0400, Keith Moore wrote:
> > doubtful this will change anytime soon.   I suspect we will never
> > run out, unless the Internet changes significantly.
> 
> I'm always amused, and a bit concerned, by the assumption that the Internet
> will not change significantly.   From my perspective, the Internet seems to
> constantly change.   Not long ago it was hard to imagine any new transport
> protocol getting much traction, for example.  And the tussles between the
> application writers and enterprise network operators haven't gone away.

The Internet could change so much as to disappear, or so little as to be
recognizable in 30 years.  Who knows.  But the forseeable future as to
new transport protocols atop IP is pretty easy to forecast: as long as
default middle box behavior is to drop protocols they don't speak, new
transport protocols won't get deployed.  And these middleboxs... many of
them are cheap, update-less consumer devices that will be with us for
many years yet.

On the plus side, there may be no need for NAT for IPv6, on the minus
side, firewalls are still a selling point, and NAT is part of it.

Perhaps we could just have a common header for new transports that
bears port numbers so that middle boxes can NAT them without knowing
anything about them...  Still, we'd be at least half a decade from being
able to deploy new transports.  Maybe a killer app could materialize
that makes consumers upgrade their middleboxes?

Nico
--

---

From: Keith Moore <[email-masked]>
Date: Tue, 1 Oct 2019 00:49:25 -0400

On 10/1/19 12:21 AM, Nico Williams wrote:

> transport protocols won't get deployed.

Or maybe they'll get deployed, but have a degraded fallback mode in 
which they impersonate other protocols.   Which, after all, is pretty 
much what has been happening for many years now.

> And these middleboxs... many of

If they're cheap they can be replaced for one reason or another. All it 
takes is for some popular app to perform more poorly in the presence of 
such middleboxes, and perhaps for ISPs to have to deal with support 
calls caused by such boxes.   Or some fad that can be used to sell new, 
slightly less dysfunctional, boxes.

Lots of things, of course, can happen.   If you're looking for a path 
back to the good old days in which the IP layer was transparent, I also 
have a hard time finding a likely scenario that gets us there.  
Meanwhile there are still clever people trying to do new things with the 
Internet, in spite of the middleboxes and unscrupulous operators trying 
to keep applications in cages.    And those clever people don't 
necessarily feel compelled to play by the old rules either.

Keith