rfc8822xml2.original.xml   rfc8822.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2119.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC2516 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2516.xml">
]>
<rfc submissionType="IETF" docName="draft-allan-5g-fmc-encapsulation-08" categor
y="info" ipr="trust200902">
<!-- Generated by id2xml 1.5.0 on 2021-02-26T02:20:32Z -->
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="no"?>
<?rfc text-list-symbols="-o*+"?>
<?rfc toc="yes"?>
<front>
<title abbrev="5G Wireless Wireline Convergence User Pl">5G Wireless Wire
line Convergence User Plane Encapsulation (5WE)</title>
<author initials="D." surname="Allan" fullname="Dave Allan" role="editor"
>
<organization>Ericsson</organization>
<address><postal><street>2455 Augustine Drive</street>
<city>San Jose</city> <region>CA</region> <code>95054</code>
<country>USA</country>
</postal>
<email>david.i.allan@ericsson.com</email>
</address>
</author>
<author initials="D." surname="Eastlake 3rd" fullname="Donald E. Eastlake
3rd">
<organization>Futurewei Technologies</organization>
<address><postal><street>2386 Panoramic Circle</street>
<city>Apopka</city> <region>FL</region> <code>32703</code>
<country>USA</country>
</postal>
<phone>+1-508-333-2270</phone>
<email>d3e3e3@gmail.com</email>
</address>
</author>
<author initials="D." surname="Woolley" fullname="David Woolley">
<organization>Telstra Corporation</organization>
<address><postal><street>242 Exhibition St</street>
<city>Melbourne</city> <region></region> <code>3000</code>
<country>Australia</country>
</postal>
<email>david.woolley@team.telstra.com</email>
</address>
</author>
<date year="2021" month="March"/> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<abstract><t>
As part of providing wireline access to the 5G Core (5GC), deployed
wireline networks carry user data between 5G residential gateways
and the 5G Access Gateway Function (AGF). The encapsulation method
specified in this document supports the multiplexing of traffic for
multiple PDU sessions within a VLAN delineated access circuit,
permits legacy equipment in the data path to inspect certain packet
fields, carries 5G QoS information associated with the packet data,
and provides efficient encoding. It achieves this by specific points
of similarity with the RFC 2516 PPPoE data packet encapsulation.</t>
</abstract> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-allan-5g-fmc-enca
</front> psulation-08" number="8822" submissionType="IETF" category="info" consensus="tru
e" ipr="trust200902" obsoletes="" updates="" xml:lang="en" symRefs="true" sortRe
fs="true" tocInclude="true" version="3">
<middle> <front>
<section title="Introduction" anchor="sect-1"><t>
Converged 5G ("fifth generation") wireline networks carry user data
between 5G residential gateways (5G-RG) and the 5G Access Gateway
Function (identified as a Wireline-AGF (W-AGF) by 3GPP in [TS23316])
across deployed access networks based on Broadband Forum <xref target="TR101"
/> and
<xref target="TR178"/>. This form of wireline access is considered to be trus
ted
non-3GPP access by the 5G system.</t>
<t> <title abbrev="5G WWC User Plane Encapsulation">5G Wireless Wireline Converg
The transport encapsulation used needs to meet a variety of ence User Plane Encapsulation (5WE)</title>
requirements including the following:</t>
<t><list style="symbols"><t>The ability to multiplex multiple logical con <seriesInfo name="RFC" value="8822"/>
nections (Protocol Data Unit <author initials="D." surname="Allan" fullname="Dave Allan" role="editor">
(PDU) Sessions as defined by 3GPP) within a VLAN identified point to <organization>Ericsson</organization>
point logical circuit between a 5G-RG and a W-AGF.</t> <address>
<postal>
<street>2455 Augustine Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95054</code>
<country>United States of America</country>
</postal>
<email>david.i.allan@ericsson.com</email>
</address>
</author>
<author initials="D." surname="Eastlake 3rd" fullname="Donald E. Eastlake 3r
d">
<organization>Futurewei Technologies</organization>
<address>
<postal>
<street>2386 Panoramic Circle</street>
<city>Apopka</city>
<region>FL</region>
<code>32703</code>
<country>United States of America</country>
</postal>
<phone>+1-508-333-2270</phone>
<email>d3e3e3@gmail.com</email>
</address>
</author>
<author initials="D." surname="Woolley" fullname="David Woolley">
<organization>Telstra Corporation</organization>
<address>
<postal>
<street>242 Exhibition St</street>
<city>Melbourne</city>
<region/>
<code>3000</code>
<country>Australia</country>
</postal>
<email>david.woolley@team.telstra.com</email>
</address>
</author>
<date month="April" year="2021"/>
<t>To allow unmodified legacy equipment in the data path to identify the <keyword>PPPoE</keyword>
encapsulation and inspect specific fields in the payload. Some access <keyword>W-AGF</keyword>
nodes in the data path between the 5G-RG and the W-AGF (Such as digital <keyword>QFI</keyword>
subscriber loop access multiplexers (DSLAMs) and optical line <keyword>RQI</keyword>
terminations (OLTs)) currently inspect packets identified by specific <keyword>WWC</keyword>
Ethertypes to identify protocols such as the point to point protocol over
ethernet (PPPoE), IP, ARP, and IGMP. This may be for the purpose of
enhanced QoS, policing of identifiers and other applications. Some
deployments are dependent upon this inspection. Such devices are able to
do this for PPPoE or IP over ethernet (IPoE) packet encodings but would
be unable to do so if a completely new encapsulation, or an existing
encapsulation using a new Ethertype, were used.</t>
<t>To carry per packet 5G QoS information.</t> <abstract>
<t>
As part of providing wireline access to the 5G Core (5GC), deployed
wireline networks carry user data between 5G residential gateways and the
5G Access Gateway Function (AGF). The encapsulation method specified in
this document supports the multiplexing of traffic for multiple PDU
sessions within a VLAN-delineated access circuit, permits legacy equipment
in the data path to inspect certain packet fields, carries 5G QoS
information associated with the packet data, and provides efficient
encoding. It achieves this by specific points of similarity with the
Point-to-Point Protocol over Ethernet (PPPoE) data packet
encapsulation (RFC 2516).</t>
</abstract>
</front>
<middle>
<section anchor="sect-1" numbered="true" toc="default">
<name>Introduction</name>
<t>Fixed access residential gateways are sensitive to the complexity <t>
of packet processing, therefore an encapsulation that minimizes Converged 5G ("fifth generation") wireline networks carry user data between
processing is an important consideration.</t> 5G residential gateways (5G-RGs) and the 5G Access Gateway Function
(identified as a Wireline-AGF (W-AGF) by 3GPP in <xref target="TS23316"
format="default"/>) across deployed access networks based on Broadband
Forum <xref target="TR101" format="default"/> and <xref target="TR178"
format="default"/>. This form of wireline access is considered to be
trusted non-3GPP access by the 5G system.</t>
<t>
The transport encapsulation used needs to meet a variety of requirements,
including the following:</t>
<ul spacing="normal">
<li>The ability to multiplex multiple logical connections (Protocol
Data Unit (PDU) sessions as defined by 3GPP) within a VLAN-identified
point-to-point logical circuit between a 5G-RG and a W-AGF.</li>
</list> <li>To allow unmodified legacy equipment in the data path to identify
</t> the encapsulation and inspect specific fields in the payload. Some
access nodes in the data path between the 5G-RG and the W-AGF (such as
digital subscriber loop access multiplexers (DSLAMs) and optical line
terminations (OLTs)) currently inspect packets identified by specific
Ethertypes to identify protocols such as the Point-to-Point Protocol
over Ethernet (PPPoE), IP, ARP, and IGMP. This may be for the purpose
of enhanced QoS, the policing of identifiers, and other applications. So
me
deployments are dependent upon this inspection. Such devices are able
to do this for PPPoE or IP-over-Ethernet (IPoE) packet encodings but
would be unable to do so if a completely new encapsulation, or an
existing encapsulation using a new Ethertype, were used.</li>
<li>To carry per-packet 5G QoS information.</li>
<li>An encapsulation that minimizes processing since fixed access
residential gateways are sensitive to the complexity of packet
processing. While not a strict requirement, this is an important
consideration.</li>
<t> </ul>
A data encapsulation that uses a common Ethertype and has certain
fields appearing at the same offset as the PPPoE <xref target="RFC2516"/> dat
a
encapsulation can address these requirements. This data
encapsulation is referred to as the 5G WWC user plane Encapsulation
or 5WE. Currently deployed access nodes do not police the VER, TYPE
and CODE fields of an RFC 2516 header, and only perform limited
policing of stateful functions with respect to the procedures
documented in RFC 2516. Therefore, these fields have a different
definition for 5WE and are used to:</t>
<t><list style="symbols"><t>Identify that the mode of operation for packe <t>
ts encapsulated in A data encapsulation that uses a common Ethertype and has certain fields
such a fashion uses non-access stratum (NAS, a logical control appearing at the same offset as the PPPoE data encapsulation <xref target="RF
interface between user equipment (UE) and 5GC as specified by C2516"
3GPP) based 5G WWC session establishment and life cycle format="default"/> can address these requirements. This
maintenance procedures as documented in [TS23502][TS23316] instead data encapsulation is referred to as the 5G WWC user plane encapsulation or
of legacy PPP/PPPoE session establishment procedures (i.e. PADI 5WE. Currently deployed access nodes do not police the VER, TYPE, or CODE
discipline, LCP, NCP etc.). In this scenario "discovery" is fields of an RFC 2516 PPPoE header and only perform limited policing of stat
performed by means outside the scope of this document.</t> eful
functions with respect to the procedures documented in RFC 2516. Therefore,
these fields have a different definition for 5WE and are used to:</t>
<ul spacing="normal">
<t>Permit the session ID field to be used to identify the 5G PDU <li>Identify that the mode of operation for packets encapsulated in
session the encapsulated packet is part of.</t> such a fashion uses 5G WWC session establishment based on non-access
stratum (NAS, a logical control interface between user equipment (UE)
and a 5th Generation Core Network (5GC) as specified by 3GPP) and
life-cycle maintenance procedures as documented in <xref
target="TS23502" format="default"/> and <xref target="TS23316"
format="default"/> instead of legacy PPP/PPPoE session establishment
<t>Communicate per-packet 5G QoS Flow Identifier (QFI) and procedures <xref target="RFC2516"/> (i.e., PADI discipline, LCP, NCP,
etc.). In this scenario, "discovery" is performed by means outside the
scope of this document.</li>
<li>Permit the session ID field to be used to identify the 5G PDU
session the encapsulated packet is part of.</li>
<li>Communicate per-packet 5G QoS Flow Identifier (QFI) and
Reflective QoS Indication (RQI) information from the 5GC to the Reflective QoS Indication (RQI) information from the 5GC to the
5G-RG.</t> 5G-RG.</li>
</ul>
</list>
</t>
<t> <t>
This 5G specific redesign of fields not inspected by deployed This 5G-specific redesign of fields not inspected by deployed
equipment results in an encapsulation uniquely applicable to the equipment results in an encapsulation uniquely applicable to the
requirements for the communication of PDU session traffic between requirements for the communication of PDU session traffic between
the subscriber premises and the 5G system over wireline networks. the subscriber premises and the 5G system over wireline networks.
The 6 byte RFC 2516 data packet header followed by a 2 byte PPP The 6-byte RFC 2516 data packet header followed by a 2-byte PPP
protocol ID is also the most frugal of the encapsulations that are protocol ID is also the most frugal of the encapsulations that are
currently supported by legacy access equipment that could be adapted currently supported by legacy access equipment that could be adapted
to meet these requirements.</t> to meet these requirements.</t>
<t>
<t>
This encapsulation is expected to be used in environments where RFC This encapsulation is expected to be used in environments where RFC
2516 is deployed. Therefore, implementations MUST examine the 2516 is deployed. Therefore, implementations <bcp14>MUST</bcp14> examine the
version number:</t> version number:</t>
<ul spacing="normal">
<t><list style="symbols"><t>if the version number is 1, and PPPoE <xref t <li>If the version number is 1 and PPPoE <xref target="RFC2516" format="
arget="RFC2516"/> is supported, default"/> is supported,
process the frame further, else silently discard it.</t> process the frame further; else, silently discard it.</li>
<li>If the version number is 2 and 5WE is supported, process the frame
<t>if the version number is 2 and 5WE is supported, process the frame further; else, silently discard it.</li>
further, else silently discard it.</t> </ul>
<t>
</list> In both cases, frames for the supported version number should have
</t>
<t>
In both cases frames for the supported version number should have
session IDs corresponding to established sessions for the respective session IDs corresponding to established sessions for the respective
protocol models. A 5WE frame with an unrecognized session ID MUST be protocol models. A 5WE frame with an unrecognized session ID <bcp14>MUST</bcp 14> be
silently discarded.</t> silently discarded.</t>
<t>
<t>
This encapsulation may have MTU issues when used for Ethernet This encapsulation may have MTU issues when used for Ethernet
multiplexing in networks where the underlying Ethernet payload is multiplexing in networks where the underlying Ethernet payload is
limited to 1500 bytes.</t> limited to 1500 bytes.</t>
<t>
<t>
This encapsulation is not suitable for other network environments, This encapsulation is not suitable for other network environments,
e.g., general use over the public Internet.</t> e.g., general use over the public Internet.</t>
<section anchor="sect-1.1" numbered="true" toc="default">
<name>Requirements Language</name>
<section title="Requirements Language" anchor="sect-1.1"><t> <t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"MAY", and "OPTIONAL" in this document are to be interpreted as NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, a RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
nd only when, they "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
appear in all capitals, as shown here.</t> be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
</section> when, and only when, they appear in all capitals, as shown here.
</t>
<section title="Acronyms" anchor="sect-1.2"><t> </section>
<section anchor="sect-1.2" numbered="true" toc="default">
<name>Acronyms</name>
<t>
This document uses the following acronyms:</t> This document uses the following acronyms:</t>
<dl indent="10">
<figure><artwork><![CDATA[ <dt>3GPP</dt> <dd>3rd Generation Partnership Project</dd>
3GPP 3rd Generation Partnership Project <dt>5WE</dt> <dd> 5G Wireless Wireline Convergence User Plane Encapsulation</dd
5WE 5G WWC Encapsulation >
5GC 5th Generation Core (network) <dt>5GC</dt> <dd> 5th Generation Core (network)</dd>
DSLAM Digital Subscriber Loop Access Multiplexer <dt>DSLAM</dt> <dd>Digital Subscriber Loop Access Multiplexer</dd>
W-AGF Wireline Access Gateway Function <dt>W-AGF</dt> <dd>Wireline Access Gateway Function</dd>
IPoE IP over Ethernet <dt>IPoE</dt> <dd>IP over Ethernet</dd>
NAS Non-Access Stratum <dt>NAS</dt> <dd>Non-Access Stratum</dd>
OLT Optical Line Termination <dt>OLT</dt> <dd>Optical Line Termination</dd>
PDU Protocol Data Unit <dt>PDU</dt> <dd>Protocol Data Unit</dd>
PPPoE PPP over Ethernet <dt>PPPoE</dt> <dd>PPP over Ethernet</dd>
QFI QoS Flow Identifier <dt>QFI</dt> <dd>QoS Flow Identifier</dd>
QoS Quality of Service <dt>QoS</dt> <dd>Quality of Service</dd>
RG Residential Gateway <dt>RG</dt> <dd> Residential Gateway</dd>
RQI Reflective QoS Indicator <dt>RQI</dt> <dd> Reflective QoS Indicator</dd>
WWC Wireless Wireline Convergence <dt>WWC</dt> <dd>Wireless Wireline Convergence</dd>
]]></artwork> </dl>
</figure> </section>
</section> </section>
<section anchor="sect-2" numbered="true" toc="default">
</section> <name>Data Encapsulation Format</name>
<t>
<section title="Data Encapsulation Format" anchor="sect-2"><t> The Ethernet payload <xref target="IEEE802" format="default"/> for PPPoE <xre
The Ethernet payload [IEEE802] for PPPoE <xref target="RFC2516"/> is indicate f target="RFC2516" format="default"/> is indicated by
d by
an Ethertype of 0x8864. The information following that Ethertype an Ethertype of 0x8864. The information following that Ethertype
uses a value of 2 in the VER field for the repurposing of the PPPoE uses a value of 2 in the VER field for the repurposing of the PPPoE
data encapsulation as the 5G WWC user plane encapsulation (5WE). The data encapsulation as the 5G WWC user plane encapsulation (5WE). The
5G WWC User Plane encapsulation is structured as follows:</t> 5G WWC user plane encapsulation is structured as follows:</t>
<figure><artwork><![CDATA[ <artwork name="" type="" align="left" alt=""><![CDATA[
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VER | TYPE | QFI |R|0| SESSION_ID | | VER | TYPE | QFI |R|0| SESSION_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LENGTH | PROTOCOL ID | | LENGTH | PROTOCOL ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DATA PAYLOAD ~ | DATA PAYLOAD ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
]]></artwork> ]]></artwork>
</figure> <t>The description of each field is as follows:
</t>
<t>The description of each field is as follows:
<list>
<t>VER is the version. It MUST be set to 0x02.</t>
<t>TYPE is the message type. It MUST be set to 0x01.</t>
<t>QFI encodes the 3GPP 5G QoS Flow Identifier [TS38415] to be used for
mapping 5G QoS to IP DSCP/802.1 P-bits [IEEE802].</t>
<t>R (short for Reflective QoS Indication [TS38415]) encodes the one bit
RQI. It is set by the network side 5WE termination for downstream
traffic and ignored by the network for upstream traffic.</t>
<t>0 indicates the bit(s) MUST be sent as zero and ignored on
receipt.</t>
<t>SESSION_ID is a 16-bit unsigned integer in network byte order. It is
used to distinguish different PDU sessions that are in the VLAN
delineated multiplex. A value of 0xffff is reserved for future use and
MUST NOT be used.</t>
<t>LENGTH is the length in bytes of the data payload including <dl indent="9">
the initial Protocol ID. It is 16 bits in network byte order.</t>
<t>PROTOCOL ID is the 16 bit identifier of the data payload type encoded <dt>VER:
using values from the IANA PPP DLL protocol numbers registry. (<eref </dt>
target="https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xhtml#ppp <dd>The version. It <bcp14>MUST</bcp14> be set to 0x02.
-numbers-2"/>) </dd>
<list> <dt>TYPE:
<t>The following values are valid in this field for 5G WWC use: </dt>
<dd>The message type. It <bcp14>MUST</bcp14> be set to 0x01.
</dd>
<list> <dt>QFI:
<t>0x0021: IPv4</t> </dt>
<dd>Encodes the 3GPP 5G QoS Flow Identifier <xref target="TS38415"
format="default"/> to be used for mapping 5G QoS to IP DSCP/802.1 P-bits <xref
target="IEEE802" format="default"/>.
</dd>
<t>0x0031: Ethernet (referred to in PPP as "bridging")</t> <dt>R:
</dt>
<dd>(Short for Reflective QoS Indication <xref target="TS38415"
format="default"/>) Encodes the one-bit RQI. It is set by the network-side 5WE
termination for downstream traffic and ignored by the network for upstream
traffic.
</dd>
<t>0x0057: IPv6</t> <dt>0:
</dt>
<dd>Indicates the bit(s) that <bcp14>MUST</bcp14> be sent as zero and ignored on
receipt.
</dd>
</list> <dt>SESSION_ID:
</t> </dt>
<dd>A 16-bit unsigned integer in network byte order. It is used to distinguish
different PDU sessions that are in the VLAN-delineated multiplex. A value of
0xffff is reserved for future use and <bcp14>MUST NOT</bcp14> be used.
</dd>
<t> <dt>LENGTH:
Packets received that do not contain one of the above protocol IDs are </dt>
silently discarded.</t>
</list> <dd>The length in bytes of the data payload, including the initial Protocol
</t> ID. It is 16 bits in network byte order.
</dd>
</list> <dt>PROTOCOL ID:
</t> </dt>
<t><list style="hanging" hangIndent="3"><t> <dd><t>The 16-bit identifier of the data payload type encoded using values
DATA PAYLOAD is encoded as per the protocol ID.</t> from the IANA "PPP DLL Protocol Numbers" registry <eref
target="https://www.iana.org/assignments/ppp-numbers" brackets="angle"/>.</t>
<t>The following values are valid in this field for 5G WWC use:</t>
</list> <ul>
</t> <li>0x0021: IPv4
</li>
<li>0x0031: Bridging PDU (Ethernet)
</li>
<li>0x0057: IPv6
</li>
</ul>
<t>Packets received that do not contain one of the above protocol IDs are silent
ly discarded.
</t>
</section> </dd>
<section title="Acknowledgements" anchor="sect-3"><t> <dt>DATA PAYLOAD:
This memo is a result of comprehensive discussions by the Broadband </dt>
Forum's Wireline Wireless Convergence Work Area. <dd>Encoded as per the protocol ID.
The authors would also like to thank Joel Halpern and Dirk Von Hugo </dd>
for their detailed review of this draft.</t>
</section> </dl>
<section title="Security Considerations" anchor="sect-4"><t> </section>
5G NAS procedures used for session life cycle maintenance employ
ciphering and integrity protection [TS23502]. They can be considered
to be a more secure session establishment discipline than existing
RFC 2516 procedures, at least against on path attackers.
The design of the 5WE encapsulation will not circumvent existing
anti-spoofing and other security procedures in deployed equipment.
The existing access equipment will be able to identify fields that
they normally process and policed as per existing RFC 2516 traffic.</t>
<t> <section anchor="sect-4" numbered="true" toc="default">
<name>Security Considerations</name>
<t>
5G NAS procedures used for session life-cycle maintenance employ cipherin
g
and integrity protection <xref target="TS23502" format="default"/>. They
can be considered a more secure session establishment discipline than
existing RFC 2516 procedures, at least against on-path attackers. The
design of the 5WE encapsulation will not circumvent existing anti-spoofing
and other security procedures in deployed equipment. The existing access
equipment will be able to identify fields that they normally process and
police as per existing RFC 2516 traffic.</t>
<t>
Therefore, the security of a fixed access network using 5WE will be Therefore, the security of a fixed access network using 5WE will be
equivalent or superior to current practice.</t> equivalent or superior to current practice.</t>
<t>
5WE-encapsulated traffic is used on what the 5GC considers to be trusted
non-3GPP interfaces; therefore, it is not ciphered. 5WE is not suitable for
use over an untrusted non-3GPP interface.</t>
<t>
The security requirements of the 5G system are documented in
<xref target="TS33501" format="default"/>.</t>
</section>
<section anchor="sect-5" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>
IANA has created the following registry on the "Point-to-Point (PPP)
Protocol Field Assignments" page:</t>
<t> <dl>
5WE encapsulated traffic is used on what the 5GC considers to be
trusted non-3GPP interfaces, therefore is not ciphered. 5WE is not
suitable for use over an untrusted non-3GPP interface.</t>
<t> <dt>Registry Name:
The security requirements of the 5G system are documented in </dt>
[TS33501]</t> <dd>PPP Over Ethernet Versions
</dd>
</section> <dt>Registration Procedure:
</dt>
<dd>Specification Required
</dd>
<section title="IANA Considerations" anchor="sect-5"><t> <dt>References:
IANA is requested to create a registry on the Point-to-Point (PPP) </dt>
Protocol Field Assignments IANA Web page as follows:</t> <dd><xref target="RFC2516"/> [this document]
</dd>
<figure><artwork><![CDATA[ </dl>
Registry Name: PPP Over Ethernet Versions
Registration Procedure: Specification Required
References: [RFC2516] [this document]
VER Description Reference <table anchor="iana_table">
----- ----------------------------- ----------- <name>PPP Over Ethernet Versions</name>
0 reserved [this document] <thead>
1 PPPoE [RFC2516] <tr>
2 5G WWC User Plane Encapsulation [this document] <th>VER</th>
3-15 unassigned [this document] <th>Description</th>
]]></artwork> <th>Reference</th>
</figure> </tr>
<t> </thead>
IANA is requested to add [this document] as an additional reference for <tbody>
Ethertype 0x8864 in the Ethertypes table on the IANA "IEEE 802 Numbers" web <tr>
page.(<eref target="https://www.iana.org/assignments/ieee-802-numbers/ieee-80 <td>0</td>
2-numbers.xhtml#ieee-802-numbers-1"/>)</t> <td>Reserved</td>
<td>[this document]</td>
</tr>
<tr>
<td>1</td>
<td>PPPoE</td>
<td><xref target="RFC2516"/></td>
</tr>
<tr>
<td>2</td>
<td>5G WWC User Plane Encapsulation</td>
<td>[this document]</td>
</tr>
<tr>
<td>3-15</td>
<td>unassigned</td>
<td></td>
</tr>
</tbody>
</table>
</section> <t>
IANA has added this document as an additional reference for
Ethertype 0x8864 in the "Ether Types" registry on the IANA "IEEE 802 Numbers"
page <eref
target="https://www.iana.org/assignments/ieee-802-numbers"
brackets="angle"/>.</t>
</section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2516.xml"/>
</middle> <reference anchor="TS38415">
<front>
<title>NG-RAN; PDU session user plane protocol</title>
<author>
<organization>3GPP</organization>
</author>
<date month="March" year="2018" />
</front>
<seriesInfo name="TS" value="38.415" />
<refcontent>Release 15</refcontent>
</reference>
<back> <reference anchor="TS23502">
<references title="Normative References"> <front>
&RFC2119; <title>Procedures for the 5G System (5GS)</title>
&RFC8174; <author>
&RFC2516; <organization>3GPP</organization>
</author>
<date month="December" year="2016" />
</front>
<seriesInfo name="TS" value="23.502" />
<refcontent>Release 15</refcontent>
</reference>
<!-- <reference anchor="TS23316">
draft-allan-5g-fmc-encapsulation-08-manual.txt(315): Warning: Failed parsing <front>
a <title>Wireless and wireline convergence access support for the 5G System
reference. Are all elements separated by commas (not periods, not just (5GS)</title>
spaces)?: <author>
[TS38415] 3rd Generation Partnership Project, Technical <organization>3GPP</organization>
Specification Group Radio Access Network, NG-RAN, PDU </author>
Session User Plane Protocol (Release 15), 3GPP TS38.415 <date month="December" year="2018" />
--> </front>
<seriesInfo name="TS" value="23.316" />
<refcontent>Release 16</refcontent>
</reference>
<!-- </references>
draft-allan-5g-fmc-encapsulation-08-manual.txt(319): Warning: Failed parsing <references>
a <name>Informative References</name>
reference. Are all elements separated by commas (not periods, not just
spaces)?:
[TS23502] 3rd Generation Partnership Project, Technical
Specification Group Services and System Aspects,
Procedures for the 5G System (Release 16), 3GPP TS23.502
-->
<!-- <reference anchor="TR101">
draft-allan-5g-fmc-encapsulation-08-manual.txt(323): Warning: Failed parsing <front>
a <title>Migration to Ethernet Based Broadband Aggregation</title>
reference. Are all elements separated by commas (not periods, not just <author>
spaces)?: <organization>Broadband Forum</organization>
[TS23316] 3rd Generation Partnership Project, Technical </author>
Specification Group Services and System Aspects, <date month="July" year="2011"/>
Wireless and wireline convergence access support </front>
for the 5G System (5GS) (Release 16), 3GPP TS23.316, <refcontent>TR-101, issue 2</refcontent>
November 2018 </reference>
</references>
<references title="Informative References">
<reference anchor="TR101"><front>
<title>Migration to Ethernet Based Broadband Aggregation</title>
<author>
</author>
<date month="July" year="2011"/>
</front>
<seriesInfo name="Broadband" value="Forum Technical Report: TR-101 issue
2"/>
</reference>
<reference anchor="TR178"><front> <reference anchor="TR178">
<title>Multi-service Broadband Network Architecture and Nodal Requirement <front>
s</title> <title>Multi-service Broadband Network Architecture and Nodal Requir
<author> ements</title>
</author> <author>
<date month="September" year="2014"/> <organization>Broadband Forum</organization>
</front> </author>
<seriesInfo name="Broadband" value="Forum Technical Report: TR-178"/> <date month="September" year="2014"/>
</reference> </front>
<refcontent>TR-178, issue 1</refcontent>
<!-- </reference>
draft-allan-5g-fmc-encapsulation-08-manual.txt(339): Warning: Failed parsing
a
reference. Are all elements separated by commas (not periods, not just
spaces)?:
[IEEE802] 802, IEEE, "IEEE Standard for Local and Metropolitan
Networks: Overview and Architecture", IEEE Std 802-2014.
-->
<!-- <reference anchor="IEEE802">
draft-allan-5g-fmc-encapsulation-08-manual.txt(342): Warning: Failed parsing <front>
a <title>IEEE Standard for Local and Metropolitan Networks: Overview and
reference. Are all elements separated by commas (not periods, not just Architecture</title>
spaces)?: <author>
[TS33501] 3rd Generation Partnership Project, Technical <organization>IEEE</organization>
Specification Group Services and System Aspects, </author>
Security Architecture and Procedures for 5G System <date month="June" year="2014" />
(Release 16), 3GPP TS33.501, December 2019 </front>
</references> <seriesInfo name="Std" value="802-2014"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2014.6847097"/>
</reference>
</back> <reference anchor="TS33501">
<front>
<title>Security architecture and procedures for 5G System</title>
<author>
<organization>3GPP</organization>
</author>
<date month="December" year="2019" />
</front>
<seriesInfo name="TS" value="33.501"/>
<refcontent>Release 16</refcontent>
</reference>
</rfc> </references>
</references>
<section anchor="sect-3" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>
This memo is a result of comprehensive discussions by the Broadband Forum's
Wireline Wireless Convergence Work Area. The authors would also like to
thank <contact fullname="Joel Halpern"/> and <contact fullname="Dirk Von
Hugo"/> for their detailed review of this document.</t>
</section>
</back>
</rfc>
 End of changes. 65 change blocks. 
360 lines changed or deleted 432 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/