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.