﻿<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" consensus="true" docName="draft-moskowitz-intarea-ipnumber-00"
	category="std" ipr="trust200902" obsoletes="" submissionType="IETF"
	xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">

<front> <title abbrev="IP Number for SCHC">IP Number for SCHC</title>
    <seriesInfo name="Internet-Draft" value="draft-moskowitz-intarea-ipnumber-00"/>
	<author fullname="Robert Moskowitz" initials="R" surname="Moskowitz">
    <organization>HTT Consulting</organization>
    <address>
      <postal> 
	    <street></street>
        <city>Oak Park</city>
        <region>MI</region>
        <code>48237</code>
        <country>USA</country>
      </postal>
      <email>rgm@labs.htt-consult.com</email>
	</address>
	</author>
	<author fullname="Stuart W. Card" initials="S." surname="Card">
	<organization>AX Enterprize, LLC</organization>
	<address>
	  <postal>
	    <street>4947 Commercial Drive</street>
	    <city>Yorkville</city>
	    <region>NY</region>
	    <code>13495</code>
	    <country>USA</country>
	  </postal>
	  <email>stu.card@axenterprize.com</email>
	</address>
	</author>
	<author fullname="Adam Wiethuechter" initials="A." surname="Wiethuechter">
	<organization>AX Enterprize, LLC</organization>
	<address>
	  <postal>
	    <street>4947 Commercial Drive</street>
	    <city>Yorkville</city>
	    <region>NY</region>
	    <code>13495</code>
	    <country>USA</country>
	  </postal>
	  <email>adam.wiethuechter@axenterprize.com</email>
	</address>
	</author>
<date year="2022" />
   <area>Internet</area>
   <workgroup>INTAREA</workgroup>
    <keyword>RFC</keyword>
     <keyword>Request for Comments</keyword>
     <keyword>I-D</keyword>
     <keyword>Internet-Draft</keyword>
     <keyword>SCHC</keyword>
<abstract>
<t>
	This document requests an Internet Protocol Number assignment for 
	SCHC so that SCHC can be used for IP independent SCHC of other 
	transports such as UDP and ESP.
</t>
</abstract>
</front>
<middle>   
<section numbered="true" toc="default"> <name>Introduction</name>
<t> 
	LPWAN Static Context Header Compression (SCHC) <xref 
	target="I-D.ietf-lpwan-architecture" format="default"> 
	Architecture</xref> originally envisioned SCHC used at the Network 
	layer, encompassing IP and Transport, by the network provider.  
	Then SCHC would be used by the application; this would include any 
	security envelope.
</t>
<t>
	This approach brakes down when dealing with Diet ESP <xref 
	target="I-D.mglt-ipsecme-diet-esp" format="default"/>.  When Next 
	Header is ESP, it is challenging for the ESP process to determine 
	if an incoming ESP payload is regular ESP <xref target="RFC4303"/> 
	or a diet ESP payload.  Careful allocation of the incoming SPI 
	<xref target="I-D.mglt-ipsecme-ikev2-diet-esp-extension" 
	format="default"/> can mitigate this and have an implicit SCHC 
	header, but it is not sound protocol design.  If the Next Header in 
	the IP header were SCHC, not ESP, a clear segregation of incoming 
	traffic is directly supportable.
</t>
<t>
	Additionally, SCHC can then be the Next Header within the ESP 
	header with 'regular' SCHC rules for processing this content.  This 
	approach will greatly simplify <xref 
	target="I-D.mglt-ipsecme-diet-esp" format="default"/>.
</t>
<t>
	DTLS 1.3 <xref target="RFC9147"/> adds further complications.  DTLS 
	1.3 headers themselves are typically already very compressed and 
	SCHC would not provide much value.  But the UDP header in front of 
	DTLS would benefit of a separate compression from the IP Header 
	compression.  Where it is possible with ESP's SPI to mitigate 
	inbound packet processing challenges implicit SCHC would generate, 
	DTLS header does not safely even provide this and a SCHC IP number 
	is necessary to separate traffic.
</t>
<section anchor="B_Use_case" numbered="true" toc="default"> <name>Basic use case for SCHC as an IP Number</name>
<t>
	A mobile node, or network, may use different links over a period of 
	time.  In some cases the node has the multiple interfaces and, in 
	theory, could tune the compression to each interface.  In other 
	cases, it is the whole network that is mobile and individual nodes 
	have no "knowledge" of which link with what characteristics is 
	actively handling the traffic.  In either case, the node 
	administrator is aware that some links are constrained and use of 
	SCHC compression is highly recommended.
</t>
<t> 
	One example is an UA that uses different links 
	over the duration of an operation (i.e. flight).
</t>
	<ul spacing="normal">
		<li>
			Operation starts using Veriport's WiFi service.
		</li>
		<li>
			On gaining altitude, UA transitions to a Cellular service.
		</li>
		<li>
			On gaining more altitude, UA transitions to a constrained 
			700MHz UHF service.
		</li>
		<li>
			On approach to destination vertiport, link transition is reversed.
		</li>
	</ul>
<t> 
	The UA could use SCHC compression only on the UHF link, but this 
	may complicate the implementation.
</t>
<t> 
	A more complex example is an Unmanned Cargo Aircraft that has 
	multiple avionics systems, all Ethernet connected to an onboard 
	router that has the multiple interfaces.  Here the nodes each 
	manage their own secure path to their ground-based server, but have 
	no knowledge of which link is in use to intelligently use 
	compression.
</t>
</section>
</section>
<section anchor="terms" numbered="true" toc="default"> <name>Terms and Definitions</name>
<section numbered="true" toc="default"> <name>Requirements Terminology</name>
	<t>
		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
		NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", 
		"MAY", and "OPTIONAL" in this document are to be interpreted as 
		described in BCP 14 <xref target="RFC2119" /> <xref 
		target="RFC8174" /> when, and only when, they appear in all 
		capitals, as shown here.
	</t>
</section>
</section>
<section anchor="SCHC_NH" numbered="true" toc="default"> <name>Internet Protocol Number for SCHC</name>
<t>
	SCHC as the IP payload SHOULD be indicated in the IPv4 "Protocol" 
	field or the IPv6 "Next Header" field with a value of TBD1 
	(recommended: 144) as shown below:
</t>
<table anchor="IPN_table" align="center"> <name>Internet Protocol Numbers</name>
	<thead>
		<tr>
			<th align="right">Decimal</th>
			<th align="left">Keyword</th>
			<th align="left">Protocol</th>
			<th align="left">IPv6 Extension Header</th>
			<th align="left">Reference</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td align="right">TBD1 (144)</td>
			<td align="left">SCHC</td>
			<td align="left">Static Context Header Compression</td>
			<td align="left"> </td>
			<td align="left">This RFC</td>
		</tr>
	</tbody>
</table>
<t>
	The SCHC compressed header with payload is shown below.  The size 
	of the SCHC RuleID is variable as described in <xref 
	target="RFC8724"/>.  An implementation should have a table of 
	source IP address and RuleID size.  The addresses should be 
	represented in prefix format to allow for groups of addresses 
	having the same RuleID size.
</t>
<figure anchor="SCHC_Packet"> <name>SCHC Packet</name>
<artwork name="" type="ascii-art" align="left" alt="">
<![CDATA[
    |------- Compressed Header -------|
    +---------------------------------+--------------------+ 
    |  RuleID  |  Compression Residue |      Payload       |
    +---------------------------------+--------------------+
]]>
</artwork>
</figure>
<t>
	The RuleID may be statically configured per <xref 
	target="RFC8724"/>, or may be negotiated within a protocol as in 
	IKE <xref target="I-D.mglt-ipsecme-ikev2-diet-esp-extension" 
	format="default"/>.
</t>
</section>
<section anchor="IANA" numbered="true" toc="default"> <name>IANA Considerations</name>
<section anchor="IANA_IPN_reg" numbered="true" toc="default"> <name>IANA IP Number Registry Update</name>
<t>
	  This document requests IANA to make the following change to the 
	  "Assigned Internet Protocol Numbers" <xref 
	  target="IANA-IPN" format="default"/> registry:
</t>
	<dl newline="true">
        <dt>IP Number:</dt>
        <dd>
			This document defines the new IP Number value TBD1 
			(suggested: 144) (<xref target="SCHC_NH" 
			format="default"/>) in the "Assigned Internet Protocol Numbers" 
			registry.
        </dd>
	</dl>
<table>
	<thead>
		<tr>
			<th align="right">Decimal</th>
			<th align="left">Keyword</th>
			<th align="left">Protocol</th>
			<th align="left">IPv6 Extension Header</th>
			<th align="left">Reference</th>
		</tr>
	</thead>
	<tbody>
		<tr>
			<td align="right">TBD1 (144)</td>
			<td align="left">SCHC</td>
			<td align="left">Static Context Header Compression</td>
			<td align="left"> </td>
			<td align="left">This RFC</td>
		</tr>
	</tbody>
</table>
</section>
</section>
<section anchor="security-considerations" numbered="true" toc="default"> <name>Security Considerations</name>
<t>
	TBD
</t>
</section>
</middle>
<back>
<displayreference target="I-D.ietf-lpwan-architecture" to="lpwan-architecture"/>
<displayreference target="I-D.mglt-ipsecme-diet-esp" to="diet-esp"/>
<displayreference target="I-D.mglt-ipsecme-ikev2-diet-esp-extension" to="ikev2-diet-esp"/>
<references> <name>References</name>
<references title="Normative References">
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
</references>
<references title="Informative References">
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4303.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8724.xml"/>
	<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.9147.xml"/>
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-lpwan-architecture.xml"/>
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-mglt-ipsecme-diet-esp.xml"/>
	<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-mglt-ipsecme-ikev2-diet-esp-extension.xml"/>
	<reference anchor="IANA-IPN"  target="https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml">
		<front>
			<title>Assigned Internet Protocol Numbers</title>
			<author><organization>IANA</organization></author>
		</front>
	</reference>
</references>
</references>
<section numbered="false" toc="default"> <name>Acknowledgments</name>
<t>
	Discussions with Pascal Thubert, lpwan co-chair, helped develop 
	this approach of using SCHC E2E below the current Transport Layers.
</t>
</section>
</back>
</rfc>
