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

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 19 Sep 2019 15:06:04 +0000

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: Fernando Gont <[email-masked]>
Date: Thu, 19 Sep 2019 19:53:33 +0300

On 19/9/19 18:06, Eric Vyncke (evyncke) wrote:
> 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).

Just a (mostly side) comment:

The hop limit thins is tricky:
Some 0-hop (non-routable?) protocols actually use a high (e.g. 255) TTL,
such that it can be enforced ("''''security''''-wise") that the parties
are actually on the same network segment.

Others (was it mld?) employ small hop limit values, such that you can
control how far packets can leak out.

So the protocol might actually use small or large hop limit, depending
on whether you want to make sure that packets cannot be injected, or
that packets cannot leak out.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Erik Kline <[email-masked]>
Date: Thu, 19 Sep 2019 14:28:17 -0700

Where do they want to use this, and why not request a new protocol value?

(What did [email-masked] say?)

On Thu, 19 Sep 2019 at 08:07, Eric Vyncke (evyncke) <[email-masked]>
wrote:

> 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:
>
>
>
> Please note that I do not ask for comments/reviews on the draft itself
> (they are welcome though on the [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
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 19 Sep 2019 17:37:13 -0400

Erik,

IP Protocol numbers are a scarce resource and the allocation policy is
"IESG Approval or Standards Action". They aren't interested in the latter,
so they would need the former. So if they can legitimately reuse 114, it
makes everyone's life easier.

Cheers,
Andy

---

From: John Gilmore <[email-masked]>
Date: Thu, 19 Sep 2019 17:02:04 -0700

Protocol 114 was unassigned in RFC 1700 in Oct 1994, which was the last
RFC tabulating protocol assignments.  In January 2002, RFCs ceased being
published for protocol number assignments, according to RFC 3232.
Sometime before Feb 1999, protocol 114 was assigned here:

  https://web.archive.org/web/19990203044112/http://www.isi.edu/in-notes/iana/assignments/protocol-numbers
  
The original IANA, Jon Postel, died on October 16, 1998.  There was some
turmoil in the relevant websites at the time.  The Internet Archive's
Wayback Machine does not appear to have captured the IANA.org or isi.edu
websites during an earlier time when this protocol number was not
assigned.  But, only five assignments in Feb 1999 had followed 114; the
next one was L2TP (protocol 115) by Bernard Aboba (April 1998).  The
preceding one was PGM (protocol 113) by Tony Speakman in January 1998.
So it's a pretty good bet that it was assigned by Postel between January
and April 1998.

(L2TP was documented in RFC 2661 of August 1999, and by that point it was
not using protocol #115; it ran over IP and UDP on port 1701.  A later
2005 evolution of L2TP, L2TPv3, used protocol 115.)

Does anyone have archives of the TCP-IP Distribution List from 1998?
The only copy I have found so far is at
http://securitydigest.org/tcp-ip/ but it ends in 1994 (with no apparent
"we're closing down the list" messages).

A separate issue:

Having read the draft-zhu-intarea-gma-03.txt, and skimmed the 2017
draft-kanugovi-intarea-mams-protocol-03 that it references, I don't see
how this protocol could in any way be seen as a 0-hop protocol.  The
whole design is to provide multiple paths to the Internet, which would
require that the relevant packets traverse routers.  The MAMS draft
explicitly says "MAMS routes user plane data packets at the IP layer".
0-hop protocols only operate on a single LAN and cannot be routed, by
definition.  (ARP, DHCP or its predecessor BOOTP are examples of 0-hop
protocols.)

Therefore, I think this draft should not be using protocol 114.

	John

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Fri, 20 Sep 2019 07:17:33 +0000

Thank you John for your 'archeology' work about this protocol number. I appreciate your time and effort.

About the draft itself, I will let the authors reply (as they should be part of int-area@) but my understanding is that the "multi-access gateway" is on the same link (3G or wifi) as the client so it is a layer-3 0-hop. And IMHO hop-limit should be 0 to scope the packets to the local-link (even if less secure than using HL=255).

Regards

-éric

On 20/09/2019, 02:02, "John Gilmore" <[email-masked]> wrote:

      

    
    A separate issue:

    
    	John

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 20 Sep 2019 09:24:53 -0500

> https://web.archive.org/web/19990203044112/http://www.isi.edu/in-notes/iana/assignments/protocol-numbers

I looked at this document.
It looks like many listed there are no longer used/exist.
Maybe deprecating them and thereby making the numbers available for
assignment seem like something IETF/IESG can do?

Behcet

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 20 Sep 2019 13:37:45 -0400

Behcet,

That was a historical list. The current assignments are in
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml .
If you want to go garbage collecting, that's the place to start.

Cheers,
Andy

On Fri, Sep 20, 2019 at 10:25 AM Behcet Sarikaya <[email-masked]>
wrote:

>> <https://web.archive.org/web/19990203044112/http://www.isi..edu/in-notes/iana/assignments/protocol-numbers>
>>
>>
>

---

From: Bob Hinden <[email-masked]>
Date: Fri, 20 Sep 2019 13:31:16 -0700

Andy,

> On Sep 20, 2019, at 10:37 AM, Andrew G. Malis <[email-masked]> wrote:
> 
> Behcet,
> 
> That was a historical list. The current assignments are in https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml . If you want to go garbage collecting, that's the place to start.

It's difficult to tell which are no longer used.  For example, I was recently asked about the Reliable Data Protocol, it’s IANA assignment:

27	RDP	Reliable Data Protocol		[RFC908][Bob_Hinden]

I assumed it was no longer used.   Later by happenstance, I learned it is specified by ETSI as mandatory to implement in eSIMs.  I had no idea.

Bob

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 20 Sep 2019 17:36:59 -0400

Bob,

I certainly agree, but I also wanted Behcet to at least have the most
up-to-date list.

Cheers,
Andy

On Fri, Sep 20, 2019 at 4:31 PM Bob Hinden <[email-masked]> wrote:

> . If you want to go garbage collecting, that's the place to start.
>
> It's difficult to tell which are no longer used.  For example, I was
> recently asked about the Reliable Data Protocol, it’s IANA assignment:
>
> I assumed it was no longer used.   Later by happenstance, I learned it is
> specified by ETSI as mandatory to implement in eSIMs.  I had no idea.
>
> Bob
>
>
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 20 Sep 2019 19:11:12 -0700

FWIW, there are many registries with such “dead” entries.

RFC6335 talks about the issue in trying to recover such entries.

In general, it recommends that even if they are recovered, at best they would be marked as “RESERVED” until other values have been assigned and the space requires reuse of those dead entries.

So the net effect is:
a) the list will never actually reflect what is deployed (as Bob notes below)
b) garbage-collecting will at best mark some subset as dead
c) but the available entries won’t be reused until we run out anyway

Given the number of remaining entries, the task of garbage collection seems of little value.

Joe

> On Sep 20, 2019, at 1:31 PM, Bob Hinden <[email-masked]> wrote:
> 
> Andy,
> 
> _______
> internet-history mailing list
> [email-masked]
> http://mailman.postel.org/mailman/listinfo/internet-history
> Contact [email-masked] for assistance.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Sep 2019 15:23:50 +1200

> FWIW, there are many registries with such “dead” entries.

114 is a bit special. By definition, all our normal traffic monitoring techniques will *never* see protocol 114 unless by chance they are installed on a layer 2 segment where it is in use. So even if no traces anywhere include it for ten years, we still can't assert that it is out of use. It seems harder to prove than most negatives :-).
 
> Given the number of remaining entries, the task of garbage collection seems of little value.

Until the day when it seems urgent...

    Brian

---

From: Erik Kline <[email-masked]>
Date: Fri, 20 Sep 2019 21:03:30 -0700

There's also the matter of whether allocating 114 for this doc would
establish a precedent.

On Fri, 20 Sep 2019 at 20:24, Brian E Carpenter <[email-masked]>
wrote:

> 114 is a bit special. By definition, all our normal traffic monitoring
> techniques will *never* see protocol 114 unless by chance they are
> installed on a layer 2 segment where it is in use. So even if no traces
> anywhere include it for ten years, we still can't assert that it is out of
> use. It seems harder to prove than most negatives :-).
>
> > In general, it recommends that even if they are recovered, at best they
> would be marked as “RESERVED” until other values have been assigned and the
> space requires reuse of those dead entries.
> >
> > So the net effect is:
> >> I assumed it was no longer used.   Later by happenstance, I learned it
> is specified by ETSI as mandatory to implement in eSIMs.  I had no idea.
> >>
> >> Bob
> >>
> >>
> >> _______

---

From: Joe Touch <[email-masked]>
Date: Fri, 20 Sep 2019 22:45:22 -0700

Hi, all,

I wouldn’t care if this doc used 114 - as long as it is very clear that 114 is for *ANY* 0-hop protocol, which means ANYONE else can also use it.

That means that it might be useful to treat that protocol a little like the experimental TCP codepoints as per RFC6994, i.e., to include a long (4-byte minimum) magic number and tolerate collisions.

Joe

> On Sep 20, 2019, at 9:03 PM, Erik Kline <[email-masked]> wrote:
> 
> There's also the matter of whether allocating 114 for this doc would establish a precedent.
> 
> On Fri, 20 Sep 2019 at 20:24, Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> >> On Sep 20, 2019, at 1:31 PM, Bob Hinden <[email-masked] <mailto:[email-masked]>> wrote:
> >>
> >> Andy,
> >>
> >>> On Sep 20, 2019, at 10:37 AM, Andrew G. Malis <[email-masked] <mailto:[email-masked]>> wrote:
> >>>
> >>> Behcet,
> >>>
> >>> That was a historical list. The current assignments are in https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml <https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml> . If you want to go garbage collecting, that's the place to start.
> >>
> >> [email-masked] <mailto:[email-masked]>
> >> http://mailman.postel.org/mailman/listinfo/internet-history <http://mailman.postel.org/mailman/listinfo/internet-history>
> >> Contact [email-masked] <mailto:[email-masked]> for assistance.
> > 
> > _______
> > [email-masked] <mailto:[email-masked]>
> > http://mailman.postel.org/mailman/listinfo/internet-history <http://mailman.postel.org/mailman/listinfo/internet-history>
> > Contact [email-masked] <mailto:[email-masked]> for assistance.
> > 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/int-area <https://www.ietf.org/mailman/listinfo/int-area>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 22 Sep 2019 09:20:18 +1200

> That means that it might be useful to treat that protocol a little like the experimental TCP codepoints as per RFC6994, i.e., to include a long (4-byte minimum) magic number and tolerate collisions.

Or add a protocol number following this ambiguous protocol number.

(See what I did there?)

    Brian

> 
> Joe
> 
>> On Sep 20, 2019, at 9:03 PM, Erik Kline <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Joe Touch <[email-masked]>
Date: Sat, 21 Sep 2019 17:28:41 -0700

> On Sep 21, 2019, at 2:20 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Sure, that’s what the ID does - but it’s also a value that’s presumably unlikely to come up otherwise (that’s why it’s not just a single byte).

Joe

---

From: Bob Hinden <[email-masked]>
Date: Sun, 22 Sep 2019 08:07:46 -0700

Brian, Joe,

> On Sep 20, 2019, at 8:23 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Until the day when it seems urgent…

Yes to both.   Especially since we are not close to running out.  From the registry:

143-252		Unassigned		[Internet_Assigned_Numbers_Authority]

109 available out of 256, or 42%.    The last two assignments listed were in 2015.

I think it would be fine for this draft to request a new one that accurately described its usage.

Bob

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 22 Sep 2019 16:20:41 +0100

Hi Bob,

> I think it would be fine for this draft to request a new one that accurately described its usage.

For what it's worth, the assignment policy for the registry is IESG Approval or Standards Action.

The draft concerned (draft-zhu-intarea-gma) doesn't seem to have gained much traction in the IETF - at least not enough to be likely to qualify for "Standards Action". Unless the IESG seems likely to grant an assignment, that avenue appears to be closed off.

Adrian

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sun, 22 Sep 2019 12:25:38 -0400

Assuming your interpretation is correct (which seems to match what I 
have seen), that would also seem to indicate that allowing them to 
hijack an existing code point for their use is also not appropriate.

Yours,
Joel

---

From: Bob Hinden <[email-masked]>
Date: Sun, 22 Sep 2019 11:16:08 -0700

Adrian,

> On Sep 22, 2019, at 8:20 AM, Adrian Farrel <[email-masked]> wrote:
> 
> Hi Bob,
> 

It is what it is.   I think they should update the draft to request a new code point.   If they can’t meet the requirements then they won’t get one, if they do (for example, convince an AD to ask IANA to assign it), then they get one.

This is much better than deploying something that misuses an exiting code point.

BTW, since I have started doing a little Wireshark development, I think it’s important that new protocols be possible to parse in network debugging tools like Wireshark.   Misusing a code point doesn’t allow for that.

Bob

---

From: John Gilmore <[email-masked]>
Date: Mon, 23 Sep 2019 14:27:44 -0700

> 109 available out of 256, or 42%.

The catch is that when this breaks, it will break lots of big stuff.
This 1-byte value is shared between IPv4 and IPv6(!), so exhausting it
in one will also exhaust the other.  And it occurs in every IP packet,
describing the protocol of what it contains (e.g. UDP or TCP, or an IPv6
packet, or an IPv6-Fragment header).

Or, perhaps the IP packet contains ISO-TP4, MERIT Internodal Protocol,
the "Cross Net Debugger", or "TRUNK-2" from the ARPANET days.  That
one-of-a-kind stuff really should get cleaned out.

I have asked several people who allocated ancient entries to determine if
those early protocols are dead, and if so, to formally relinquish the
allocation via email to IANA.  You'll see several marked as "deprecated"
which have resulted from those asks.  Some of those people, however, are
dead now, and there's no obvious way to clean up the detritis they left
lying around in the IP protocol.

For example, I have an ask pending to Barry Boehm, who seems to only
have been the formal owner (as head of the DARPA IPTO office) and not
the actual user (those entries were allocated by Barry Leiner, then
moved to Saul Amarel, then to Barry).  And I haven't heard back.  He has
four, almost certainly obsolete, protocol numbers, and IANA doesn't
even seem to have his current email address ([email-masked]?  But he
appears to be at USC now.).

	John