Generic Multi-Access (GMA) Encapsulation Protocol
draft-zhu-intarea-gma-14

(Via drafts-eval@iana.org): IESG/Authors/ISE:

The IANA Functions Operator has reviewed draft-zhu-intarea-gma and has the following comments:

We understand that this document doesn't require any registry actions.

This document does say the following:

Note that this experiment "re-uses" the IP protocol identifier 114
as described in Section 4.4. Part of this experiment is to assess
the safety of doing this.

Also in section 4.4 it says:

4.4. IP Protocol Identifier

As described in Section 4.1, IP encapsulated GMA PDUs are
indicated using the IP Protocol Type 114. This is designated and
recorded by IANA [IANA] to indicate "any 0-Hop Protocol". No
reference is given in the IANA registry for the definition of this
Protocol Type, and IANA has no record of why the assignment was
made or how it is used, although it was probably assigned in 1995.

There is some risk associated with "re-using" Protocol Type 114
because there may be implementations of other protocols also using
this Protocol Type. However, because the protocol described in
this document is used only between adjacent devices specifically
configured for this purpose, the use of Protocol Type 114 should
be safe.

As described in Section 1.1, one of the purposes of the experiment
described in this document is to verify the safety of using this
Protocol Type. Deployments should be aware of the risk of a clash
with other uses of this Protocol Type.

Are there any issues with using this existing assignment?

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Michelle Cotton
Protocol Parameters Engagement Sr. Manager
IANA Services

draft-zhu-intarea-gma has been presented for publication as an
Experimental RFC on the Independent Submission Stream.

==Purpose==

This document describes an experimental encapsulation protocol to
carry multiple access protocols across IP networks using IP or UDP
encapsulation.

The protocol operates between endpoints that have been explicitly
configured to use it. This configuration can be through any procedures,
including, for example, Multi-Access Management Services [RFC8743].

== History==

This document has been a work in progress since January 2019. It is
related to the work previously published as RFC 8743, but is independent
except that RFC 8743 could be used to configure the use of this protocol.

The draft was brought to the ISE in April 2019 at revision -02.

==Non-IETF Work==

The Abstract and Introduction contain clear statements that the work
does not have IETF consensus and is not endorsed by the IETF.

==Experiment==

The authors discussed with the ISE whether this should be published as
Informational or Experimental. While the authors initially pushed for
Informational, there is only one experimental implementation, and there
are no deployments. This means that Experimental is more appropriate.

Section 1.1 describes the scope of the Experiment.

==IANA==

This document makes no requests for IANA action, BUT...

The protocol does require an IP Protocol value to identify the payload.
Allocations of new IP Protocol values require Standards Action or IESG
Approval. Thus, a new allocation would only be possible on the
Independent Stream with support from the IESG.
https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml

This protocol spec makes use of IP Protocol value 114. That value
appears in the IANA registry as "Any 0-Hop Protocol".

IANA has discussed this issue with the ISE. There is no record of why
the code point was allocated or what it is intended to be used for.
After discussion, Eric Vyncke started a thread on the IETF Discussion
list to see whether there was any mode information
https://mailarchive.ietf.org/arch/msg/ietf/A3qOAVg5z3Ox4-iBmnoQbeHgQao/

There were a number of responses on the thread:
- No indications of any current (or historic) uses of 114
- Observation that a 0-hop protocol is, by definition, used between
  consenting devices on the link that connects them
- Protocol numbers are a scarce resource and assigning new values
  should be done with care

Eric's conclusion was:
1. As it is an independent stream with little traction, to keep using
  the IP protocol 114
2. The I-D should specify a hop-limit of 0 for IPv6 (RFC 8200) and TTL
  of 1 for IPv4 (RFC 791).
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.
  There are more than 40% remaining.

Since this document is Experimental, and given the current limited
scope, it is considered relatively safe to use 114.

The document highlights the potential risks and mitigations in Section
4.4, and makes investigating any possible adverse consequences part of
the experiment in Section 1.1.

==Implementation==

One of the authors has an implementation that they have tested
extensively. It is not publicly available or in a product.

==Reviews==

The ISE had particular difficulty finding reviewers. A lot of requests
were sent out to people with an interest in the technology, but it took
a very long time to get enough input.

Reviews were performed for the ISE by Donald Eastlake, Dhruv Dhody, and
Radhika Mittal.

An INT Dir review was done by Tommy Pauly.

The ISE also did a substantial review.

The authors updated the draft to address all reviews

Details of the reviews are extensive, but can be retrieved on request.