draft-ietf-anima-autonomic-control-plane-30.original.xml   draft-ietf-anima-autonomic-control-plane-30.original.v2v3.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='utf-8'?>
<!-- This template is for creating an Internet Draft using xml2rfc, <!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. --> which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" [
<!-- Not needed, found better option how to do this
<!ENTITY rfc8422 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8422.xml'>
-->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors --> <!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), <!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. --> please see http://xml.resource.org/authoring/README.html. -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-anima-autonomic-control-plane-30" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="5" symRefs="true" sortRefs="true" consensus="true" version="3">
<rfc
xmlns:xi="http://www.w3.org/2001/XInclude"
category="std"
docName="draft-ietf-anima-autonomic-control-plane-30"
ipr="trust200902"
obsoletes=""
updates=""
submissionType="IETF"
xml:lang="en"
tocInclude="true"
tocDepth="5"
symRefs="true"
sortRefs="true"
consensus="true"
version="3">
<!-- REMOVED in version 12: updates="4291,4193" --> <!-- REMOVED in version 12: updates="4291,4193" -->
<!-- ***** FRONT MATTER ***** --> <!-- ***** FRONT MATTER ***** -->
<front> <front>
<title abbrev="An Autonomic Control Plane (ACP)">An Autonomic Control Plane (ACP)</title> <title abbrev="An Autonomic Control Plane (ACP)">An Autonomic Control Plane (ACP)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-autonomic-control-plane-30"/> <seriesInfo name="Internet-Draft" value="draft-ietf-anima-autonomic-control-plane-30"/>
<author role="editor" fullname="Toerless Eckert" surname="Eckert"> <author role="editor" fullname="Toerless Eckert" surname="Eckert">
<organization abbrev="Futurewei USA"> <organization abbrev="Futurewei USA">
skipping to change at line 449 skipping to change at line 427
</section> </section>
<!-- usage --> <!-- usage -->
<section anchor="requirements" numbered="true" toc="default"> <section anchor="requirements" numbered="true" toc="default">
<name>Requirements (Informative)</name> <name>Requirements (Informative)</name>
<t>The following requirements were identified for the design of the ACP based on the above use-cases (<xref target="usage" format="default"/>). These requirements are informative. The ACP as specified in the normative parts of this document is meeting or exceeding these use-case requirements:</t> <t>The following requirements were identified for the design of the ACP based on the above use-cases (<xref target="usage" format="default"/>). These requirements are informative. The ACP as specified in the normative parts of this document is meeting or exceeding these use-case requirements:</t>
<ol type="ACP%d:" spacing="compact"> <ol type="ACP%d:" spacing="compact">
<li>The ACP should provide robust connectivity: As far as possible, it should be independent of configured addressing, configuration and routing. Requirements 2 and 3 build on this requirement, but also have value on their own.</li> <li>The ACP should provide robust connectivity: As far as possible, it should be independent of configured addressing, configuration and routing. Requirements 2 and 3 build on this requirement, but also have value on their own.</li>
<li>The ACP must have a separate address space from the Data-Plane. Reason: traceability, debug-ability, separation from Data-Plane, infrastructure security (filtering based on known address space).</li> <li>The ACP must have a separate address space from the Data-Plane. Reason: traceability, debug-ability, separation from Data-Plane, infrastructure security (filtering based on known address space).</li>
<li>The ACP must use autonomically managed address space. Reason: easy bootstrap and setup ("autonomic"); robustness (admin cannot break network easily). This document uses Unique Local Addresses (ULA) for this purpose, see <xref target="RFC4193" format="default"/>.</li> <li>The ACP must use autonomically managed address space. Reason: easy bootstrap and setup ("autonomic"); robustness (admin cannot break network easily). This document uses Unique Local Addresses (ULA) for this purpose, see <xref target="RFC4193" format="default"/>.</li>
<li>The ACP must be generic, that is it must be usable by all the functions and protocols of the ANI. Clients of the ACP must not be tied to a particular application or transport protocol.</li> <li>The ACP must be generic, that is it must be usable by all the functions and protocols of the ANI. Clients of the ACP must not be tied to a particular application or transport protocol.</li>
<li>The ACP must provide security: Messages coming through the ACP must be authenticated to be from a trusted node, and it is very strongly > recommended that they be encrypted.</li> <li>The ACP must provide security: Messages coming through the ACP must be authenticated to be from a trusted node, and it is very strongly &gt; recommended that they be encrypted.</li>
</ol> </ol>
<t>Explanation for ACP4: In a fully autonomic network (AN), newly written ASAs could potentially all communicate exclusively via GRASP with each other, and if that was assumed to be the only requirement against the ACP, it would not need to provide IPv6 layer connectivity between nodes, but only GRASP connectivity. Nevertheless, because ACP also intends to support non-AN networks, it is crucial to support IPv6 layer connectivity across the ACP to support any transport and application layer protocols.</t> <t>Explanation for ACP4: In a fully autonomic network (AN), newly written ASAs could potentially all communicate exclusively via GRASP with each other, and if that was assumed to be the only requirement against the ACP, it would not need to provide IPv6 layer connectivity between nodes, but only GRASP connectivity. Nevertheless, because ACP also intends to support non-AN networks, it is crucial to support IPv6 layer connectivity across the ACP to support any transport and application layer protocols.</t>
<t>The ACP operates hop-by-hop, because this interaction can be built on IPv6 link local addressing, which is autonomic, and has no dependency on configuration (requirement 1). It may be necessary to have ACP connectivity across non-ACP nodes, for example to link ACP nodes over the general Internet. This is possible, but introduces a dependency against stable/resilient routing over the non-ACP hops (see <xref target="remote-acp-neighbors" format="default"/>).</t> <t>The ACP operates hop-by-hop, because this interaction can be built on IPv6 link local addressing, which is autonomic, and has no dependency on configuration (requirement 1). It may be necessary to have ACP connectivity across non-ACP nodes, for example to link ACP nodes over the general Internet. This is possible, but introduces a dependency against stable/resilient routing over the non-ACP hops (see <xref target="remote-acp-neighbors" format="default"/>).</t>
</section> </section>
<!-- requirements --> <!-- requirements -->
<section anchor="overview" numbered="true" toc="default"> <section anchor="overview" numbered="true" toc="default">
<name>Overview (Informative)</name> <name>Overview (Informative)</name>
<t>When a node has an ACP certificate (see <xref target="acp-certificates" format="default"/>) and is enabled to bring up the ACP (see <xref target="node-enable" format="default"/>), it will create its ACP without any configuration as follows. For details, see <xref target="self-creation" format="default"/> and further sections: <t>When a node has an ACP certificate (see <xref target="acp-certificates" format="default"/>) and is enabled to bring up the ACP (see <xref target="node-enable" format="default"/>), it will create its ACP without any configuration as follows. For details, see <xref target="self-creation" format="default"/> and further sections:
</t> </t>
<ol type="1" spacing="compact"> <ol type="1" spacing="compact">
skipping to change at line 487 skipping to change at line 465
<t>Note: <t>Note:
</t> </t>
<ul spacing="compact"> <ul spacing="compact">
<li>None of the above operations (except the following explicit configured ones) are reflected in the configuration of the node.</li> <li>None of the above operations (except the following explicit configured ones) are reflected in the configuration of the node.</li>
<li>Non-ACP NMS ("Network Management Systems") or SDN controllers have to be explicitly configured for connection into the ACP.</li> <li>Non-ACP NMS ("Network Management Systems") or SDN controllers have to be explicitly configured for connection into the ACP.</li>
<li>Additional candidate peer adjacencies for ACP connections across non-ACP Layer-3 clouds requires explicit configuration. See <xref target="remote-acp-neighbors" format="default"/>.</li> <li>Additional candidate peer adjacencies for ACP connections across non-ACP Layer-3 clouds requires explicit configuration. See <xref target="remote-acp-neighbors" format="default"/>.</li>
</ul> </ul>
<t>The following figure illustrates the ACP.</t> <t>The following figure illustrates the ACP.</t>
<figure anchor="acp"> <figure anchor="acp">
<name>ACP VRF and secure channels</name> <name>ACP VRF and secure channels</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt="">
ACP node 1 ACP node 2 ACP node 1 ACP node 2
................... ................... ................... ...................
secure . . secure . . secure secure . . secure . . secure
channel: +-----------+ : channel : +-----------+ : channel channel: +-----------+ : channel : +-----------+ : channel
..--------| ACP VRF |---------------------| ACP VRF |---------.. ..--------| ACP VRF |---------------------| ACP VRF |---------..
: / \ / \ <--routing--&gt; / \ / \ : : / \ / \ <--routing--&gt; / \ / \ :
: \ / \ / \ / \ / : : \ / \ / \ / \ / :
..--------| Loopback |---------------------| Loopback |---------.. ..--------| Loopback |---------------------| Loopback |---------..
: | interface | : : | interface | : : | interface | : : | interface | :
: +-----------+ : : +-----------+ : : +-----------+ : : +-----------+ :
: : : : : : : :
: Data-Plane :...............: Data-Plane : : Data-Plane :...............: Data-Plane :
: : link : : : : link : :
:.................: :.................: :.................: :.................:
]]></artwork> </artwork>
</figure> </figure>
<t>The resulting overlay network is normally based exclusively on hop-by-hop tunnels. This is because addressing used on links is IPv6 link local addressing, which does not require any prior set-up. In this way the ACP can be built even if there is no configuration on the node, or if the Data-Plane has issues such as addressing or routing problems.</t> <t>The resulting overlay network is normally based exclusively on hop-by-hop tunnels. This is because addressing used on links is IPv6 link local addressing, which does not require any prior set-up. In this way the ACP can be built even if there is no configuration on the node, or if the Data-Plane has issues such as addressing or routing problems.</t>
</section> </section>
<!-- overview --> <!-- overview -->
<section anchor="self-creation" numbered="true" toc="default"> <section anchor="self-creation" numbered="true" toc="default">
<name>Self-Creation of an Autonomic Control Plane (ACP) (Normative)</name> <name>Self-Creation of an Autonomic Control Plane (ACP) (Normative)</name>
<t>This section specifies the components and steps to set up an ACP. The ACP is automatically "self-creating", which makes it "indestructible" against most changes to the Data-Plane, including misconfigurations of routing, addressing, NAT, firewall or any other traffic policy filters that inadvertently or otherwise unavoidably would also impact the management plane traffic, such as the actual operator CLI session or controller NETCONF session through which the configuration changes to the Data-Plane are executed.</t> <t>This section specifies the components and steps to set up an ACP. The ACP is automatically "self-creating", which makes it "indestructible" against most changes to the Data-Plane, including misconfigurations of routing, addressing, NAT, firewall or any other traffic policy filters that inadvertently or otherwise unavoidably would also impact the management plane traffic, such as the actual operator CLI session or controller NETCONF session through which the configuration changes to the Data-Plane are executed.</t>
<t>Physical misconfiguration of wiring between ACP nodes will also not break the ACP: As long as there is a transitive physical path between ACP nodes, the ACP should be able to recover given that it automatically operates across all interfaces of the ACP nodes and automatically determines paths between them.</t> <t>Physical misconfiguration of wiring between ACP nodes will also not break the ACP: As long as there is a transitive physical path between ACP nodes, the ACP should be able to recover given that it automatically operates across all interfaces of the ACP nodes and automatically determines paths between them.</t>
<t>Attacks against the network via incorrect routing or addressing information for the Data-Plane will not impact the ACP. Even impaired ACP nodes will have a significantly reduced attack surface against malicious misconfiguration because only very limited ACP or interface up/down configuration can affect the ACP, and pending on their specific designs these type of attacks could also be eliminated. See more in <xref target="enabling-acp" format="default"/> and <xref target="security" format="default"/>.</t> <t>Attacks against the network via incorrect routing or addressing information for the Data-Plane will not impact the ACP. Even impaired ACP nodes will have a significantly reduced attack surface against malicious misconfiguration because only very limited ACP or interface up/down configuration can affect the ACP, and pending on their specific designs these type of attacks could also be eliminated. See more in <xref target="enabling-acp" format="default"/> and <xref target="security" format="default"/>.</t>
<t>An ACP node can be a router, switch, controller, NMS host, or any other IPv6 capable node. Initially, it MUST have its ACP certificate, as well as an (empty) ACP Adjacency Table (described in <xref target="adj-table" format="default"/>). It then can start to discover ACP neighbors and build the ACP. This is described step by step in the following sections:</t> <t>An ACP node can be a router, switch, controller, NMS host, or any other IPv6 capable node. Initially, it MUST have its ACP certificate, as well as an (empty) ACP Adjacency Table (described in <xref target="adj-table" format="default"/>). It then can start to discover ACP neighbors and build the ACP. This is described step by step in the following sections:</t>
skipping to change at line 597 skipping to change at line 575
<t>For diagnostic and other operational purposes, it is beneficial to copy the device identifying fields of the node's IDevID certificate into the ACP certificate, such as the <xref target="X.520" format="default"/>, section 6.2.9 "serialNumber" attribute in the subject field distinguished name encoding. Note that this is not the certificate serial number. See also <xref target="I-D.ietf-anima-bootstrapping-keyinfra" format="default"/> section 2.3.1. This can be done for example if it would be acceptable for the device's "serialNumber" to be signaled via the Link Layer Discovery Protocol (LLDP, <xref target="LLDP" format="default"/>) because like LLDP signaled information, the ACP certificate information can be retrieved by neighboring nodes without further authentication and be used either for beneficial diagnostics or for malicious attacks. Retrieval of the ACP certificate is possible via a (failing) attempt to set up an ACP secure channel, and the "serialNumber" usually contains device type information that may help to faster determine working exploits/attacks against the device.</t> <t>For diagnostic and other operational purposes, it is beneficial to copy the device identifying fields of the node's IDevID certificate into the ACP certificate, such as the <xref target="X.520" format="default"/>, section 6.2.9 "serialNumber" attribute in the subject field distinguished name encoding. Note that this is not the certificate serial number. See also <xref target="I-D.ietf-anima-bootstrapping-keyinfra" format="default"/> section 2.3.1. This can be done for example if it would be acceptable for the device's "serialNumber" to be signaled via the Link Layer Discovery Protocol (LLDP, <xref target="LLDP" format="default"/>) because like LLDP signaled information, the ACP certificate information can be retrieved by neighboring nodes without further authentication and be used either for beneficial diagnostics or for malicious attacks. Retrieval of the ACP certificate is possible via a (failing) attempt to set up an ACP secure channel, and the "serialNumber" usually contains device type information that may help to faster determine working exploits/attacks against the device.</t>
<t>Note that there is no intention to constrain authorization within the ACP or autonomic networks using the ACP to just the ACP domain membership check as defined in this document. It can be extended or modified with additional requirements. Such future authorizations can use and require additional elements in certificates or policies or even additional certificates. See the additional check against the id-kp-cmcRA <xref target="RFC6402" format="default"/> extended key usage attribute (<xref target="domcert-maint" format="default"/>) and for possible future extensions, see <xref target="role-assignments" format="default"/>.</t> <t>Note that there is no intention to constrain authorization within the ACP or autonomic networks using the ACP to just the ACP domain membership check as defined in this document. It can be extended or modified with additional requirements. Such future authorizations can use and require additional elements in certificates or policies or even additional certificates. See the additional check against the id-kp-cmcRA <xref target="RFC6402" format="default"/> extended key usage attribute (<xref target="domcert-maint" format="default"/>) and for possible future extensions, see <xref target="role-assignments" format="default"/>.</t>
</section> </section>
<section anchor="domcert-acpinfo" numbered="true" toc="default"> <section anchor="domcert-acpinfo" numbered="true" toc="default">
<name>ACP Certificate AcpNodeName</name> <name>ACP Certificate AcpNodeName</name>
<?rfc needLines="20" ?> <?rfc needLines="20" ?>
<figure anchor="acp-dominfo-abnf"> <figure anchor="acp-dominfo-abnf">
<name>ACP Node Name ABNF</name> <name>ACP Node Name ABNF</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt="">
acp-node-name = local-part "@" acp-domain-name acp-node-name = local-part "@" acp-domain-name
local-part = [ acp-address ] [ "+" rsub extensions ] local-part = [ acp-address ] [ "+" rsub extensions ]
acp-address = 32HEXDIG | "0" ; HEXDIG as of RFC5234 section B.1 acp-address = 32HEXDIG | "0" ; HEXDIG as of RFC5234 section B.1
rsub = [ <subdomain> ] ; <subdomain> as of RFC1034, section 3.5 rsub = [ &lt;subdomain&gt; ] ; &lt;subdomain&gt; as of RFC1034, section 3.5
acp-domain-name = ; <domain> ; as of RFC 1034, section 3.5 acp-domain-name = ; &lt;domain&gt; ; as of RFC 1034, section 3.5
extensions = *( "+" extension ) extensions = *( "+" extension )
extension = 1*etext ; future standard definition. extension = 1*etext ; future standard definition.
etext = ALPHA / DIGIT / ; Printable US-ASCII etext = ALPHA / DIGIT / ; Printable US-ASCII
"!" / "#" / "$" / "%" / "&" / "'" / "!" / "#" / "$" / "%" / "&amp;" / "'" /
"*" / "-" / "/" / "=" / "?" / "^" / "*" / "-" / "/" / "=" / "?" / "^" /
"_" / "`" / "{" / "|" / "}" / "~" "_" / "`" / "{" / "|" / "}" / "~"
routing-subdomain = [ rsub "." ] acp-domain-name routing-subdomain = [ rsub "." ] acp-domain-name
Example: Example:
given an ACP address of fd89:b714:f3db:0:200:0:6400:0000 given an ACP address of fd89:b714:f3db:0:200:0:6400:0000
and an ACP domain-name of acp.example.com and an ACP domain-name of acp.example.com
and an rsub extenstion of area51.research and an rsub extenstion of area51.research
then this results in: then this results in:
acp-node-name = fd89b714f3db00000200000064000000 acp-node-name = fd89b714f3db00000200000064000000
+area51.research@acp.example.com +area51.research@acp.example.com
acp-domain-name = acp.example.com acp-domain-name = acp.example.com
routing-subdomain = area51.research.acp.example.com routing-subdomain = area51.research.acp.example.com
]]></artwork> </artwork>
</figure> </figure>
<t>acp-node-name in above <xref target="acp-dominfo-abnf" format="default"/> is the ABNF (<xref target="RFC5234" format="default"/>) definition of the ACP Node Name. An ACP certificate MUST carry this information. It MUST be encoded as a subjectAltName / otherName / AcpNodeName as described in <xref target="asn1" format="default"/>.</t> <t>acp-node-name in above <xref target="acp-dominfo-abnf" format="default"/> is the ABNF (<xref target="RFC5234" format="default"/>) definition of the ACP Node Name. An ACP certificate MUST carry this information. It MUST be encoded as a subjectAltName / otherName / AcpNodeName as described in <xref target="asn1" format="default"/>.</t>
<t>Nodes complying with this specification MUST be able to receive their ACP address through the domain certificate, in which case their own ACP certificate MUST have a 32HEXDIG acp-address field. Acp-address is case insensitive because ABNF HEXDIG is. It is recommended to encode acp-address with lower case letters. Nodes complying with this specification MUST also be able to authenticate nodes as ACP domain members or ACP secure channel peers when they have a 0-value acp-address field and as ACP domain members (but not as ACP secure channel peers) when the acp-address field is omitted from their AcpNodeName. See <xref target="certcheck" format="default"/>.</t> <t>Nodes complying with this specification MUST be able to receive their ACP address through the domain certificate, in which case their own ACP certificate MUST have a 32HEXDIG acp-address field. Acp-address is case insensitive because ABNF HEXDIG is. It is recommended to encode acp-address with lower case letters. Nodes complying with this specification MUST also be able to authenticate nodes as ACP domain members or ACP secure channel peers when they have a 0-value acp-address field and as ACP domain members (but not as ACP secure channel peers) when the acp-address field is omitted from their AcpNodeName. See <xref target="certcheck" format="default"/>.</t>
<t>acp-domain-name is used to indicate the ACP Domain across which ACP nodes authenticate and authorize each other, for example to build ACP secure channels to each other, see <xref target="certcheck" format="default"/>. acp-domain-name SHOULD be the FQDN of an Internet domain owned by the network administration of the ACP and ideally reserved to only be used for the ACP. In this specification it serves to be a name for the ACP that ideally is globally unique. When acp-domain-name is a globally unique name, collision of ACP addresses across different ACP domains can only happen due to ULA hash collisions (see <xref target="scheme" format="default"/>). Using different acp-domain-names, operators can distinguish multiple ACP even when using the same TA.</t> <t>acp-domain-name is used to indicate the ACP Domain across which ACP nodes authenticate and authorize each other, for example to build ACP secure channels to each other, see <xref target="certcheck" format="default"/>. acp-domain-name SHOULD be the FQDN of an Internet domain owned by the network administration of the ACP and ideally reserved to only be used for the ACP. In this specification it serves to be a name for the ACP that ideally is globally unique. When acp-domain-name is a globally unique name, collision of ACP addresses across different ACP domains can only happen due to ULA hash collisions (see <xref target="scheme" format="default"/>). Using different acp-domain-names, operators can distinguish multiple ACP even when using the same TA.</t>
<t>To keep the encoding simple, there is no consideration for internationalized acp-domain-names. The acp-node-name is not intended for end user consumption. There is no protection against an operator to pick any domain name for an ACP whether or not the operator can claim to own the domain name. Instead, the domain name only serves as a hash seed for the ULA and for diagnostics to the operator. Therefore, any operator owning only an internationalized domain name should be able to pick an equivalently unique 7-bit ASCII acp-domain-name string representing the internationalized domain name.</t> <t>To keep the encoding simple, there is no consideration for internationalized acp-domain-names. The acp-node-name is not intended for end user consumption. There is no protection against an operator to pick any domain name for an ACP whether or not the operator can claim to own the domain name. Instead, the domain name only serves as a hash seed for the ULA and for diagnostics to the operator. Therefore, any operator owning only an internationalized domain name should be able to pick an equivalently unique 7-bit ASCII acp-domain-name string representing the internationalized domain name.</t>
<t>"routing-subdomain" is a string that can be constructed from the acp-node-name, and it is used in the hash-creation of the ULA (see below). The presence of the "rsub" component allows a single ACP domain to employ multiple /48 ULA prefixes. See <xref target="domain-usage" format="default"/> for example use-cases.</t> <t>"routing-subdomain" is a string that can be constructed from the acp-node-name, and it is used in the hash-creation of the ULA (see below). The presence of the "rsub" component allows a single ACP domain to employ multiple /48 ULA prefixes. See <xref target="domain-usage" format="default"/> for example use-cases.</t>
<t>The optional "extensions" field is used for future standardized extensions to this specification. It MUST be ignored if present and not understood.</t> <t>The optional "extensions" field is used for future standardized extensions to this specification. It MUST be ignored if present and not understood.</t>
<t>The following points explain and justify the encoding choices described: <t>The following points explain and justify the encoding choices described:
</t> </t>
<ol type="1" spacing="compact"> <ol type="1" spacing="compact">
skipping to change at line 671 skipping to change at line 649
</li> </li>
</ol> </ol>
<t>See section 4.2.1.6 of <xref target="RFC5280" format="default"/> for details on the subjectAltName field.</t> <t>See section 4.2.1.6 of <xref target="RFC5280" format="default"/> for details on the subjectAltName field.</t>
<section anchor="asn1" numbered="true" toc="default"> <section anchor="asn1" numbered="true" toc="default">
<name>AcpNodeName ASN.1 Module</name> <name>AcpNodeName ASN.1 Module</name>
<t>The following ASN.1 module normatively specifies the AcpNodeName structure. <t>The following ASN.1 module normatively specifies the AcpNodeName structure.
This specification uses the ASN.1 definitions from <xref target="RFC5912" format="default"/> This specification uses the ASN.1 definitions from <xref target="RFC5912" format="default"/>
with the 2002 ASN.1 notation used in that document. <xref target="RFC5912" format="default"/> with the 2002 ASN.1 notation used in that document. <xref target="RFC5912" format="default"/>
updates normative documents using older ASN.1 notation.</t> updates normative documents using older ASN.1 notation.</t>
<figure> <figure>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt="">
ANIMA-ACP-2020 ANIMA-ACP-2020
{ iso(1) identified-organization(3) dod(6) { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-anima-acpnodename-2020(IANA1) } id-mod-anima-acpnodename-2020(IANA1) }
DEFINITIONS IMPLICIT TAGS ::= DEFINITIONS IMPLICIT TAGS ::=
BEGIN BEGIN
IMPORTS IMPORTS
OTHER-NAME OTHER-NAME
skipping to change at line 708 skipping to change at line 686
AcpNodeName IDENTIFIED BY id-on-AcpNodeName AcpNodeName IDENTIFIED BY id-on-AcpNodeName
} }
id-on-AcpNodeName OBJECT IDENTIFIER ::= { id-on IANA2 } id-on-AcpNodeName OBJECT IDENTIFIER ::= { id-on IANA2 }
AcpNodeName ::= IA5String (SIZE (1..MAX)) AcpNodeName ::= IA5String (SIZE (1..MAX))
-- AcpNodeName as specified in this document carries the -- AcpNodeName as specified in this document carries the
-- acp-node-name as specified in the ABNF in Section 6.1.2 -- acp-node-name as specified in the ABNF in Section 6.1.2
END END
]]></artwork> </artwork>
</figure> </figure>
</section> </section>
</section> </section>
<!-- domcert-acpinfo --> <!-- domcert-acpinfo -->
<section anchor="certcheck" numbered="true" toc="default"> <section anchor="certcheck" numbered="true" toc="default">
<name>ACP domain membership check</name> <name>ACP domain membership check</name>
<t>The following points constitute the ACP domain membership check of a candidate peer via its certificate: <t>The following points constitute the ACP domain membership check of a candidate peer via its certificate:
</t> </t>
<dl spacing="compact"> <dl spacing="compact">
<dt>1: </dt> <dt>1: </dt>
skipping to change at line 891 skipping to change at line 869
address (IPv6 address and/or TCP port), but this is easily automated on the address (IPv6 address and/or TCP port), but this is easily automated on the
EST server as long as the CA does not restrict registrars to request certificates EST server as long as the CA does not restrict registrars to request certificates
with the id-kp-cmcRA extended usage extension for themselves.</t> with the id-kp-cmcRA extended usage extension for themselves.</t>
<section anchor="domcert-grasp" numbered="true" toc="default"> <section anchor="domcert-grasp" numbered="true" toc="default">
<name>GRASP objective for EST server</name> <name>GRASP objective for EST server</name>
<t>ACP nodes that are EST servers MUST announce their service via GRASP in the ACP <t>ACP nodes that are EST servers MUST announce their service via GRASP in the ACP
through M_FLOOD messages. See <xref target="I-D.ietf-anima-grasp" format="default"/>, through M_FLOOD messages. See <xref target="I-D.ietf-anima-grasp" format="default"/>,
section 2.8.11 for the definition of this message type:</t> section 2.8.11 for the definition of this message type:</t>
<figure anchor="est-example"> <figure anchor="est-example">
<name>GRASP SRV.est example</name> <name>GRASP SRV.est example</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt="">
Example: Example:
[M_FLOOD, 12340815, h'fd89b714f3db0000200000064000001', 210000, [M_FLOOD, 12340815, h'fd89b714f3db0000200000064000001', 210000,
[["SRV.est", 4, 255 ], [["SRV.est", 4, 255 ],
[O_IPv6_LOCATOR, [O_IPv6_LOCATOR,
h'fd89b714f3db0000200000064000001', IPPROTO_TCP, 443]] h'fd89b714f3db0000200000064000001', IPPROTO_TCP, 443]]
] ]
]]></artwork> </artwork>
</figure> </figure>
<t> The formal definition of the objective in Concise data definition language (CDDL) <t> The formal definition of the objective in Concise data definition language (CDDL)
(see <xref target="RFC8610" format="default"/>) is as follows: </t> (see <xref target="RFC8610" format="default"/>) is as follows: </t>
<figure anchor="est-def"> <figure anchor="est-def">
<name>GRASP SRV.est definition</name> <name>GRASP SRV.est definition</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt="">
flood-message = [M_FLOOD, session-id, initiator, ttl, flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])]] +[objective, (locator-option / [])]]
; see example above and explanation ; see example above and explanation
; below for initiator and ttl ; below for initiator and ttl
objective = ["SRV.est", objective-flags, loop-count, objective = ["SRV.est", objective-flags, loop-count,
objective-value] objective-value]
objective-flags = sync-only ; as in GRASP spec objective-flags = sync-only ; as in GRASP spec
sync-only = 4 ; M_FLOOD only requires synchronization sync-only = 4 ; M_FLOOD only requires synchronization
loop-count = 255 ; recommended as there is no mechanism loop-count = 255 ; recommended as there is no mechanism
; to discover network diameter. ; to discover network diameter.
objective-value = any ; reserved for future extensions objective-value = any ; reserved for future extensions
]]></artwork> </artwork>
</figure> </figure>
<t>The objective name "SRV.est" indicates that the objective is an <t>The objective name "SRV.est" indicates that the objective is an
<xref target="RFC7030" format="default"/> compliant EST server because "est" is an <xref target="RFC7030" format="default"/> compliant EST server because "est" is an
<xref target="RFC6335" format="default"/> registered service name for <xref target="RFC7030" format="default"/>. <xref target="RFC6335" format="default"/> registered service name for <xref target="RFC7030" format="default"/>.
Objective-value MUST be ignored if present. Backward compatible extensions to Objective-value MUST be ignored if present. Backward compatible extensions to
<xref target="RFC7030" format="default"/> MAY be indicated through objective-value. <xref target="RFC7030" format="default"/> MAY be indicated through objective-value.
Non <xref target="RFC7030" format="default"/> compatible certificate renewal options MUST use a different objective-name. Non <xref target="RFC7030" format="default"/> compatible certificate renewal options MUST use a different objective-name.
Non-recognized objective-values (or parts thereof if it is a structure partially understood) MUST be ignored.</t> Non-recognized objective-values (or parts thereof if it is a structure partially understood) MUST be ignored.</t>
<t>The M_FLOOD message MUST be sent periodically. The default SHOULD be 60 seconds; <t>The M_FLOOD message MUST be sent periodically. The default SHOULD be 60 seconds;
the value SHOULD be operator configurable but SHOULD be the value SHOULD be operator configurable but SHOULD be
skipping to change at line 1182 skipping to change at line 1160
does not have a domain certificate. does not have a domain certificate.
Discovery of ACP neighbors happens only when the node does have the certificate. The node Discovery of ACP neighbors happens only when the node does have the certificate. The node
therefore never needs to discover both a bootstrap proxy and ACP neighbor at the same time.</t> therefore never needs to discover both a bootstrap proxy and ACP neighbor at the same time.</t>
<t>An ACP node announces itself to potential ACP peers by use of the "AN_ACP" objective. <t>An ACP node announces itself to potential ACP peers by use of the "AN_ACP" objective.
This is a synchronization objective intended to be flooded on a single link using the This is a synchronization objective intended to be flooded on a single link using the
GRASP Flood Synchronization (M_FLOOD) message. In accordance with the design of the Flood message, GRASP Flood Synchronization (M_FLOOD) message. In accordance with the design of the Flood message,
a locator consisting of a specific link-local IP address, IP protocol number and port number a locator consisting of a specific link-local IP address, IP protocol number and port number
will be distributed with the flooded objective. An example of the message is informally:</t> will be distributed with the flooded objective. An example of the message is informally:</t>
<figure anchor="an-acp-example"> <figure anchor="an-acp-example">
<name>GRASP AN_ACP example</name> <name>GRASP AN_ACP example</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt="">
[M_FLOOD, 12340815, h'fe80000000000000c0011001feef0000', 210000, [M_FLOOD, 12340815, h'fe80000000000000c0011001feef0000', 210000,
[["AN_ACP", 4, 1, "IKEv2" ], [["AN_ACP", 4, 1, "IKEv2" ],
[O_IPv6_LOCATOR, [O_IPv6_LOCATOR,
h'fe80000000000000c0011001feef0000', IPPROTO_UDP, 15000]] h'fe80000000000000c0011001feef0000', IPPROTO_UDP, 15000]]
[["AN_ACP", 4, 1, "DTLS" ], [["AN_ACP", 4, 1, "DTLS" ],
[O_IPv6_LOCATOR, [O_IPv6_LOCATOR,
h'fe80000000000000c0011001feef0000', IPPROTO_UDP, 17000]] h'fe80000000000000c0011001feef0000', IPPROTO_UDP, 17000]]
] ]
]]></artwork> </artwork>
</figure> </figure>
<t> The formal CDDL definition is: </t> <t> The formal CDDL definition is: </t>
<figure anchor="an-acp-def"> <figure anchor="an-acp-def">
<name>GRASP AN_ACP definition</name> <name>GRASP AN_ACP definition</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt="">
flood-message = [M_FLOOD, session-id, initiator, ttl, flood-message = [M_FLOOD, session-id, initiator, ttl,
+[objective, (locator-option / [])]] +[objective, (locator-option / [])]]
objective = ["AN_ACP", objective-flags, loop-count, objective = ["AN_ACP", objective-flags, loop-count,
objective-value] objective-value]
objective-flags = sync-only ; as in the GRASP specification objective-flags = sync-only ; as in the GRASP specification
sync-only = 4 ; M_FLOOD only requires synchronization sync-only = 4 ; M_FLOOD only requires synchronization
loop-count = 1 ; limit to link-local operation loop-count = 1 ; limit to link-local operation
objective-value = method-name / [ method, *extension ] objective-value = method-name / [ method, *extension ]
method = method-name / [ method-name, *method-param ] method = method-name / [ method-name, *method-param ]
method-name = "IKEv2" / "DTLS" / id method-name = "IKEv2" / "DTLS" / id
extension = any extension = any
method-param = any method-param = any
id = text .regexp "[A-Za-z@_$]([-.]*[A-Za-z0-9@_$])*" id = text .regexp "[A-Za-z@_$]([-.]*[A-Za-z0-9@_$])*"
]]></artwork> </artwork>
</figure> </figure>
<t>The objective-flags field is set to indicate synchronization.</t> <t>The objective-flags field is set to indicate synchronization.</t>
<t>The loop-count is fixed at 1 since this is a link-local operation.</t> <t>The loop-count is fixed at 1 since this is a link-local operation.</t>
<t>In the above example the RECOMMENDED period of sending of the <t>In the above example the RECOMMENDED period of sending of the
objective is 60 seconds. The indicated ttl of 210000 msec means objective is 60 seconds. The indicated ttl of 210000 msec means
that the objective would be cached by ACP nodes even when two that the objective would be cached by ACP nodes even when two
out of three messages are dropped in transit.</t> out of three messages are dropped in transit.</t>
<t>The session-id is a random number used for loop prevention (distinguishing a message from a prior instance of the same message). In DULL this field is irrelevant but has to be set according to the GRASP specification.</t> <t>The session-id is a random number used for loop prevention (distinguishing a message from a prior instance of the same message). In DULL this field is irrelevant but has to be set according to the GRASP specification.</t>
<t>The originator MUST be the IPv6 link local address of the originating ACP node on the sending interface.</t> <t>The originator MUST be the IPv6 link local address of the originating ACP node on the sending interface.</t>
<t>The method-name in the 'objective-value' parameter is a string indicating the protocol available at the specified or implied locator. It is a protocol supported by the node to negotiate a secure channel. IKEv2 as shown above is the protocol used to negotiate an IPsec secure channel.</t> <t>The method-name in the 'objective-value' parameter is a string indicating the protocol available at the specified or implied locator. It is a protocol supported by the node to negotiate a secure channel. IKEv2 as shown above is the protocol used to negotiate an IPsec secure channel.</t>
skipping to change at line 1281 skipping to change at line 1259
<t>In a simple example, ACP peer Node 1 attempts to initiate an IPsec via IKEv2 connection to peer Node 2. The IKEv2 authentication succeeds. Node 1 has the lower ACP address and becomes the Follower. Node 2 becomes the Decider. IKEv2 might not be the preferred ACP secure channel protocol for the Decider Node 2. Node 2 would therefore proceed to attempt secure channel setups with (in its view) more preferred protocol options (e.g., DTLS/UDP). If any such preferred ACP secure channel connection of the Decider succeeds, it would close the IPsec connection. If Node 2 has no preferred protocol option over IPsec, or no such connection attempt from Node 2 to Node 1 succeeds, Node 2 would keep the IPsec connection and use it.</t> <t>In a simple example, ACP peer Node 1 attempts to initiate an IPsec via IKEv2 connection to peer Node 2. The IKEv2 authentication succeeds. Node 1 has the lower ACP address and becomes the Follower. Node 2 becomes the Decider. IKEv2 might not be the preferred ACP secure channel protocol for the Decider Node 2. Node 2 would therefore proceed to attempt secure channel setups with (in its view) more preferred protocol options (e.g., DTLS/UDP). If any such preferred ACP secure channel connection of the Decider succeeds, it would close the IPsec connection. If Node 2 has no preferred protocol option over IPsec, or no such connection attempt from Node 2 to Node 1 succeeds, Node 2 would keep the IPsec connection and use it.</t>
<t>The Decider SHOULD NOT send actual payload packets across a secure channel until it has decided to use it. The Follower MAY delay linking the ACP secure channel into the ACP virtual interface until it sees the first payload packet from the Decider up to a maximum of 5 seconds to avoid unnecessarily linking a secure channel that will be terminated as undesired by the Decider shortly afterwards.</t> <t>The Decider SHOULD NOT send actual payload packets across a secure channel until it has decided to use it. The Follower MAY delay linking the ACP secure channel into the ACP virtual interface until it sees the first payload packet from the Decider up to a maximum of 5 seconds to avoid unnecessarily linking a secure channel that will be terminated as undesired by the Decider shortly afterwards.</t>
<?rfc needLines="48" ?> <?rfc needLines="48" ?>
<t>The following sequence of steps show this example in more detail. Each step is tagged with [&lt;step#&gt;{:&lt;connection&gt;}]. The connection is included to more easily distinguish which of the two competing connections the step belongs to, one initiated by Node 1, one initiated by Node 2. <t>The following sequence of steps show this example in more detail. Each step is tagged with [&lt;step#&gt;{:&lt;connection&gt;}]. The connection is included to more easily distinguish which of the two competing connections the step belongs to, one initiated by Node 1, one initiated by Node 2.
</t> </t>
<figure anchor="sequence-of-steps"> <figure anchor="sequence-of-steps">
<name>Secure Channel sequence of steps</name> <name>Secure Channel sequence of steps</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt="">
[1] Node 1 sends GRASP AN_ACP message to announce itself [1] Node 1 sends GRASP AN_ACP message to announce itself
[2] Node 2 sends GRASP AN_ACP message to announce itself [2] Node 2 sends GRASP AN_ACP message to announce itself
[3] Node 2 receives [1] from Node 1 [3] Node 2 receives [1] from Node 1
[4:C1] Because of [3], Node 2 starts as initiator on its [4:C1] Because of [3], Node 2 starts as initiator on its
preferred secure channel protocol towards Node 1. preferred secure channel protocol towards Node 1.
Connection C1. Connection C1.
skipping to change at line 1326 skipping to change at line 1304
to the same mutual peer as their C1, so this has no further to the same mutual peer as their C1, so this has no further
impact: the roles Decider and Follower where already assigned impact: the roles Decider and Follower where already assigned
between these two peers by [8:C1]. between these two peers by [8:C1].
[12:C2] Node 2 (the Decider) closes C1. Node 1 is fine with this, [12:C2] Node 2 (the Decider) closes C1. Node 1 is fine with this,
because of its role as the Follower (from [8:C1]). because of its role as the Follower (from [8:C1]).
[13] Node 2 (the Decider) and Node 1 (the Follower) start data [13] Node 2 (the Decider) and Node 1 (the Follower) start data
transfer across C2, which makes it become a secure channel transfer across C2, which makes it become a secure channel
for the ACP. for the ACP.
]]></artwork> </artwork>
</figure> </figure>
<t>All this negotiation is in the context of an "L2 interface". The Decider and Follower will build ACP connections to each other on every "L2 interface" that they both connect to. An autonomic node MUST NOT assume that neighbors with the same L2 or link-local IPv6 addresses on different L2 interfaces are the same node. This can only be determined after examining the certificate after a successful security association attempt.</t> <t>All this negotiation is in the context of an "L2 interface". The Decider and Follower will build ACP connections to each other on every "L2 interface" that they both connect to. An autonomic node MUST NOT assume that neighbors with the same L2 or link-local IPv6 addresses on different L2 interfaces are the same node. This can only be determined after examining the certificate after a successful security association attempt.</t>
<t>The Decider SHOULD NOT suppress attempting a particular ACP secure channel protocol connection on one L2 interface because this type of ACP secure channel connection has failed to the peer with the same ACP certificate on another L2 interface: Not only the supported ACP secure channel protocol options may be different on the same ACP peer across different L2 interfaces, but also error conditions may cause inconsistent failures across different L2 interfaces. Avoiding such connection attempt optimizations can therefore help to increase robustness in the case of errors.</t> <t>The Decider SHOULD NOT suppress attempting a particular ACP secure channel protocol connection on one L2 interface because this type of ACP secure channel connection has failed to the peer with the same ACP certificate on another L2 interface: Not only the supported ACP secure channel protocol options may be different on the same ACP peer across different L2 interfaces, but also error conditions may cause inconsistent failures across different L2 interfaces. Avoiding such connection attempt optimizations can therefore help to increase robustness in the case of errors.</t>
</section> </section>
<!-- channel-selection --> <!-- channel-selection -->
<section anchor="neighbor_verification" numbered="true" toc="default"> <section anchor="neighbor_verification" numbered="true" toc="default">
<name>Candidate ACP Neighbor verification</name> <name>Candidate ACP Neighbor verification</name>
skipping to change at line 1600 skipping to change at line 1578
<t>TCP and TLS connections for GRASP in the ACP use the IANA assigned TCP port for GRASP (7107). <t>TCP and TLS connections for GRASP in the ACP use the IANA assigned TCP port for GRASP (7107).
Effectively the transport stack is expected to be TLS for connections from/to the ACP Effectively the transport stack is expected to be TLS for connections from/to the ACP
address (e.g., global scope address(es)) and TCP for connections from/to link-local addresses address (e.g., global scope address(es)) and TCP for connections from/to link-local addresses
on the ACP virtual interfaces. The latter ones are only used for flooding of GRASP on the ACP virtual interfaces. The latter ones are only used for flooding of GRASP
messages.</t> messages.</t>
<!-- https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/344 --> <!-- https://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/344 -->
<?rfc needLines="48" ?> <?rfc needLines="48" ?>
<figure anchor="acp-grasp-picture"> <figure anchor="acp-grasp-picture">
<name>ACP as security and transport substrate for GRASP</name> <name>ACP as security and transport substrate for GRASP</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt="">
..............................ACP.............................. ..............................ACP..............................
. . . .
. /-GRASP-flooding-\ ACP GRASP instance . . /-GRASP-flooding-\ ACP GRASP instance .
. / \ A . / \ A
. GRASP GRASP GRASP C . GRASP GRASP GRASP C
. link-local unicast link-local P . link-local unicast link-local P
. multicast messages multicast . . multicast messages multicast .
. messages | messages . . messages | messages .
. | | | . . | | | .
............................................................... ...............................................................
skipping to change at line 1627 skipping to change at line 1605
. | TLS | . . | TLS | .
. ACP GRASP | ACP GRASP - ACP GRASP virtual . . ACP GRASP | ACP GRASP - ACP GRASP virtual .
. subnet1 | subnet2 virtual interfaces . . subnet1 | subnet2 virtual interfaces .
. TCP | TCP . . TCP | TCP .
. | | | . . | | | .
............................................................... ...............................................................
. | | | ^^^ Users of ACP (GRASP/ASA) . . | | | ^^^ Users of ACP (GRASP/ASA) .
. | | | ACP interfaces/addressing . . | | | ACP interfaces/addressing .
. | | | . . | | | .
. | | | A . | | | A
. | ACP-Loopback Interf.| <- ACP Loopback interface C . | ACP-Loopback Interf.| &lt;- ACP Loopback interface C
. | ACP-address | - address (global ULA) P . | ACP-address | - address (global ULA) P
. subnet1 | subnet2 <- ACP virtual interfaces . . subnet1 | subnet2 &lt;- ACP virtual interfaces .
. link-local | link-local - link-local addresses . . link-local | link-local - link-local addresses .
............................................................... ...............................................................
. | | | ACP VRF . . | | | ACP VRF .
. | RPL-routing | virtual routing and forwarding . . | RPL-routing | virtual routing and forwarding .
. | /IP-Forwarding\ | A . | /IP-Forwarding\ | A
. | / \ | C . | / \ | C
. ACP IPv6 packets ACP IPv6 packets P . ACP IPv6 packets ACP IPv6 packets P
. |/ \| . . |/ \| .
. IPsec/DTLS IPsec/DTLS - ACP-cert auth . . IPsec/DTLS IPsec/DTLS - ACP-cert auth .
............................................................... ...............................................................
| | Data-Plane | | Data-Plane
| | | |
| | - ACP secure channel | | - ACP secure channel
link-local link-local - encapsulation addresses link-local link-local - encapsulation addresses
subnet1 subnet2 - Data-Plane interfaces subnet1 subnet2 - Data-Plane interfaces
| | | |
ACP-Nbr1 ACP-Nbr2 ACP-Nbr1 ACP-Nbr2
]]></artwork> </artwork>
</figure> </figure>
<section anchor="GRASP-discussion" numbered="true" toc="default"> <section anchor="GRASP-discussion" numbered="true" toc="default">
<name>Discussion</name> <name>Discussion</name>
<t>TCP encapsulation for GRASP M_DISCOVERY and M_FLOOD link local messages is used because <t>TCP encapsulation for GRASP M_DISCOVERY and M_FLOOD link local messages is used because
these messages are flooded across potentially many hops to all ACP nodes and a single these messages are flooded across potentially many hops to all ACP nodes and a single
link with even temporary packet loss issues (e.g., WiFi/Powerline link) can reduce the link with even temporary packet loss issues (e.g., WiFi/Powerline link) can reduce the
probability for loss free transmission so much that applications would want to increase probability for loss free transmission so much that applications would want to increase
the frequency with which they send these messages. Such shorter periodic retransmission the frequency with which they send these messages. Such shorter periodic retransmission
of datagrams would result in more traffic and processing overhead in the ACP of datagrams would result in more traffic and processing overhead in the ACP
than the hop-by-hop reliable retransmission mechanism by TCP and duplicate elimination than the hop-by-hop reliable retransmission mechanism by TCP and duplicate elimination
skipping to change at line 1729 skipping to change at line 1707
<li>Autonomic functions do not require IPv4: Autonomic functions and autonomic service agents are new concepts. They can be exclusively built on IPv6 from day one. There is no need for backward compatibility.</li> <li>Autonomic functions do not require IPv4: Autonomic functions and autonomic service agents are new concepts. They can be exclusively built on IPv6 from day one. There is no need for backward compatibility.</li>
<li>OAM protocols do not require IPv4: The ACP may carry OAM protocols. All relevant protocols (SNMP, TFTP, SSH, SCP, RADIUS, Diameter, NETCONF ...) are available in IPv6. See also <xref target="RFC8368" format="default"/> for how ACP could be made to interoperate with IPv4 only OAM.</li> <li>OAM protocols do not require IPv4: The ACP may carry OAM protocols. All relevant protocols (SNMP, TFTP, SSH, SCP, RADIUS, Diameter, NETCONF ...) are available in IPv6. See also <xref target="RFC8368" format="default"/> for how ACP could be made to interoperate with IPv4 only OAM.</li>
</ul> </ul>
<t>Further explanation about the addressing and routing related reasons for the choice of the autonomous ACP addressing can be found in <xref target="ACP-loopback" format="default"/>.</t> <t>Further explanation about the addressing and routing related reasons for the choice of the autonomous ACP addressing can be found in <xref target="ACP-loopback" format="default"/>.</t>
</section> </section>
<section anchor="scheme" numbered="true" toc="default"> <section anchor="scheme" numbered="true" toc="default">
<name>The ACP Addressing Base Scheme</name> <name>The ACP Addressing Base Scheme</name>
<t>The Base ULA addressing scheme for ACP nodes has the following format:</t> <t>The Base ULA addressing scheme for ACP nodes has the following format:</t>
<figure anchor="base-addr-scheme"> <figure anchor="base-addr-scheme">
<name>ACP Addressing Base Scheme</name> <name>ACP Addressing Base Scheme</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt="">
8 40 2 78 8 40 2 78
+--+-------------------------+------+------------------------------+ +--+-------------------------+------+------------------------------+
|fd| hash(routing-subdomain) | Type | (sub-scheme) | |fd| hash(routing-subdomain) | Type | (sub-scheme) |
+--+-------------------------+------+------------------------------+ +--+-------------------------+------+------------------------------+
]]></artwork> </artwork>
</figure> </figure>
<t>The first 48-bits follow the ULA scheme, as defined in <xref target="RFC4193" format="default"/>, to which a type field is added: <t>The first 48-bits follow the ULA scheme, as defined in <xref target="RFC4193" format="default"/>, to which a type field is added:
</t> </t>
<ul spacing="compact"> <ul spacing="compact">
<li>"fd" identifies a locally defined ULA address.</li> <li>"fd" identifies a locally defined ULA address.</li>
<li>The 40-bits ULA "global ID" (term from <xref target="RFC4193" format="default"/>) for ACP addresses carried in the acp-node-name in the ACP certificates are the first 40-bits of the SHA256 hash of the routing subdomain from the same acp-node-name. In the example of <xref target="domcert-acpinfo" format="default"/>, the routing subdomain is "area51.research.acp.example.com" and the 40-bits ULA "global ID" 89b714f3db.</li> <li>The 40-bits ULA "global ID" (term from <xref target="RFC4193" format="default"/>) for ACP addresses carried in the acp-node-name in the ACP certificates are the first 40-bits of the SHA256 hash of the routing subdomain from the same acp-node-name. In the example of <xref target="domcert-acpinfo" format="default"/>, the routing subdomain is "area51.research.acp.example.com" and the 40-bits ULA "global ID" 89b714f3db.</li>
<li>When creating a new routing-subdomain for an existing autonomic network, it MUST be ensured, that rsub is selected so the resulting hash of the routing-subdomain does not collide with the hash of any pre-existing routing-subdomains of the autonomic network. This ensures that ACP addresses created by registrars for different routing subdomains do not collide with each other.</li> <li>When creating a new routing-subdomain for an existing autonomic network, it MUST be ensured, that rsub is selected so the resulting hash of the routing-subdomain does not collide with the hash of any pre-existing routing-subdomains of the autonomic network. This ensures that ACP addresses created by registrars for different routing subdomains do not collide with each other.</li>
<li>To allow for extensibility, the fact that the ULA "global ID" is a hash of the routing subdomain SHOULD NOT be assumed by any ACP node during normal operations. The hash function is only executed during the creation of the certificate. If BRSKI is used, then the BRSKI registrar will create the acp-node-name in response to the EST Certificate Signing Request (CSR) Attribute Request message by the pledge.</li> <li>To allow for extensibility, the fact that the ULA "global ID" is a hash of the routing subdomain SHOULD NOT be assumed by any ACP node during normal operations. The hash function is only executed during the creation of the certificate. If BRSKI is used, then the BRSKI registrar will create the acp-node-name in response to the EST Certificate Signing Request (CSR) Attribute Request message by the pledge.</li>
<li>Establishing connectivity between different ACP (different acp-domain-name) is outside the scope of this specification. <li>Establishing connectivity between different ACP (different acp-domain-name) is outside the scope of this specification.
If it is being done through future extensions, then the rsub of all routing-subdomains across those autonomic networks need to be selected so the resulting routing-subdomain hashes do not collide. For example, a large cooperation with its own private TA may want to create different autonomic networks that initially should not be able to connect but where the option to do so should be kept open. When taking this future possibility into account, it is easy to always select rsub so that no collisions happen.</li> If it is being done through future extensions, then the rsub of all routing-subdomains across those autonomic networks need to be selected so the resulting routing-subdomain hashes do not collide. For example, a large cooperation with its own private TA may want to create different autonomic networks that initially should not be able to connect but where the option to do so should be kept open. When taking this future possibility into account, it is easy to always select rsub so that no collisions happen.</li>
<li>Type: This field allows different address sub-schemes. This addresses the "upgradability" requirement. Assignment of types for this field will be maintained by IANA.</li> <li>Type: This field allows different address sub-schemes. This addresses the "upgradability" requirement. Assignment of types for this field will be maintained by IANA.</li>
</ul> </ul>
<t>The sub-scheme may imply a range or set of addresses assigned to the node, this is called the ACP address range/set and explained in each sub-scheme.</t> <t>The sub-scheme may imply a range or set of addresses assigned to the node, this is called the ACP address range/set and explained in each sub-scheme.</t>
<t>Please refer to <xref target="acp-registrars" format="default"/> and <xref target="address-spaces" format="default"/> for further explanations why the following Sub-Addressing schemes are used and why multiple are necessary.</t> <t>Please refer to <xref target="acp-registrars" format="default"/> and <xref target="address-spaces" format="default"/> for further explanations why the following Sub-Addressing schemes are used and why multiple are necessary.</t>
<t> <t>
The following summarizes the addressing Sub-Schemes: The following summarizes the addressing Sub-Schemes:
</t> </t>
<figure anchor="addr-scheme-summary"> <figure anchor="addr-scheme-summary">
<name>Addressing Sub-Schemes</name> <name>Addressing Sub-Schemes</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt="">
+------+-----------------+-----------+-------------------+ +------+-----------------+-----------+-------------------+
| Type | Name |F-bit| Z | V-bits | Prefix | | Type | Name |F-bit| Z | V-bits | Prefix |
+------+-----------------+-----+-----+----------+--------+ +------+-----------------+-----+-----+----------+--------+
| 0x00 | ACP-Zone | N/A | 0 | 1 bit | /127 | | 0x00 | ACP-Zone | N/A | 0 | 1 bit | /127 |
+------+-----------------+-----+-----+----------+--------+ +------+-----------------+-----+-----+----------+--------+
| 0x00 | ACP-Manual | N/A | 1 | N/A | /64 | | 0x00 | ACP-Manual | N/A | 1 | N/A | /64 |
+------+-----------------+-----+-----+----------+--------+ +------+-----------------+-----+-----+----------+--------+
| 0x01 | ACP-VLong-8 | 0 | N/A | 8 bits | /120 | | 0x01 | ACP-VLong-8 | 0 | N/A | 8 bits | /120 |
+------+-----------------+-----+-----+----------+--------+ +------+-----------------+-----+-----+----------+--------+
| 0x01 | ACP-VLong-16 | 1 | N/A | 16 bits | /112 | | 0x01 | ACP-VLong-16 | 1 | N/A | 16 bits | /112 |
+------+-----------------+-----+-----+----------+--------+ +------+-----------------+-----+-----+----------+--------+
| 0x10 | Reserved / For future definition/allocation | | 0x10 | Reserved / For future definition/allocation |
+------+-----------------+-----+-----+----------+--------+ +------+-----------------+-----+-----+----------+--------+
| 0x11 | Reserved / For future definition/allocation | | 0x11 | Reserved / For future definition/allocation |
+------+-----------------+-----+-----+----------+--------+ +------+-----------------+-----+-----+----------+--------+
]]></artwork> </artwork>
</figure> </figure>
<t>F-Bit and Z are two encoding fields explained below for <t>F-Bit and Z are two encoding fields explained below for
the Sub-Schemes that introduce/use them. V-bits is the number the Sub-Schemes that introduce/use them. V-bits is the number
of bits of addresses allocated to the ACP node. of bits of addresses allocated to the ACP node.
Prefix is the prefix the ACP node is announcing into the Prefix is the prefix the ACP node is announcing into the
RPL routing protocol.</t> RPL routing protocol.</t>
</section> </section>
<!-- base-scheme --> <!-- base-scheme -->
<section anchor="zone-scheme" numbered="true" toc="default"> <section anchor="zone-scheme" numbered="true" toc="default">
<name>ACP Zone Addressing Sub-Scheme (ACP-Zone)</name> <name>ACP Zone Addressing Sub-Scheme (ACP-Zone)</name>
<t>This sub-scheme is used when the Type field of the base scheme is 0x00 and the Z bit is 0x0.</t> <t>This sub-scheme is used when the Type field of the base scheme is 0x00 and the Z bit is 0x0.</t>
<figure anchor="addr-scheme"> <figure anchor="addr-scheme">
<name>ACP Zone Addressing Sub-Scheme</name> <name>ACP Zone Addressing Sub-Scheme</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt="">
64 64 64 64
+-----------------+---+---------++-----------------------------+---+ +-----------------+---+---------++-----------------------------+---+
| (base scheme) | Z | Zone-ID || Node-ID | | (base scheme) | Z | Zone-ID || Node-ID |
| | | || Registrar-ID | Node-Number| V | | | | || Registrar-ID | Node-Number| V |
+-----------------+---+---------++--------------+--------------+---+ +-----------------+---+---------++--------------+--------------+---+
50 1 13 48 15 1 50 1 13 48 15 1
]]></artwork> </artwork>
</figure> </figure>
<t>The fields are defined as follows:</t> <t>The fields are defined as follows:</t>
<ul spacing="compact"> <ul spacing="compact">
<li>Type: MUST be 0x0.</li> <li>Type: MUST be 0x0.</li>
<li>Z: MUST be 0x0.</li> <li>Z: MUST be 0x0.</li>
<li>Zone-ID: A value for a network zone.</li> <li>Zone-ID: A value for a network zone.</li>
<li>Node-ID: A unique value for each node.</li> <li>Node-ID: A unique value for each node.</li>
</ul> </ul>
<t>The 64-bit Node-ID must be unique across the ACP domain for each node. It is derived and composed as follows:</t> <t>The 64-bit Node-ID must be unique across the ACP domain for each node. It is derived and composed as follows:</t>
<ul spacing="compact"> <ul spacing="compact">
skipping to change at line 1823 skipping to change at line 1801
used in conjunction with operational practices for partial/incremental adoption used in conjunction with operational practices for partial/incremental adoption
of the ACP as described in <xref target="incremental-adoption" format="default"/>.</t> of the ACP as described in <xref target="incremental-adoption" format="default"/>.</t>
<t>Note: Zones and Zone-ID as defined here are not related to <xref target="RFC4007" format="default"/> zones or zone_id. ACP zone addresses are not scoped (reachable only from within an RFC4007 zone) but reachable across the whole ACP. An RFC4007 zone_id is a zone index that has only local significance on a node, whereas an ACP Zone-ID is an identifier for an ACP zone that is unique across that ACP.</t> <t>Note: Zones and Zone-ID as defined here are not related to <xref target="RFC4007" format="default"/> zones or zone_id. ACP zone addresses are not scoped (reachable only from within an RFC4007 zone) but reachable across the whole ACP. An RFC4007 zone_id is a zone index that has only local significance on a node, whereas an ACP Zone-ID is an identifier for an ACP zone that is unique across that ACP.</t>
</section> </section>
<!-- zone-scheme --> <!-- zone-scheme -->
<section anchor="manual-scheme" numbered="true" toc="default"> <section anchor="manual-scheme" numbered="true" toc="default">
<name>ACP Manual Addressing Sub-Scheme (ACP-Manual)</name> <name>ACP Manual Addressing Sub-Scheme (ACP-Manual)</name>
<t>This sub-scheme is used when the Type field of the base scheme is 0x00 and the Z bit is 0x1.</t> <t>This sub-scheme is used when the Type field of the base scheme is 0x00 and the Z bit is 0x1.</t>
<figure anchor="manual-scheme-pic"> <figure anchor="manual-scheme-pic">
<name>ACP Manual Addressing Sub-Scheme</name> <name>ACP Manual Addressing Sub-Scheme</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt="">
64 64 64 64
+---------------------+---+----------++-----------------------------+ +---------------------+---+----------++-----------------------------+
| (base scheme) | Z | Subnet-ID|| Interface Identifier | | (base scheme) | Z | Subnet-ID|| Interface Identifier |
+---------------------+---+----------++-----------------------------+ +---------------------+---+----------++-----------------------------+
50 1 13 50 1 13
]]></artwork> </artwork>
</figure> </figure>
<t>The fields are defined as follows: <t>The fields are defined as follows:
</t> </t>
<ul spacing="compact"> <ul spacing="compact">
<li>Type: MUST be 0x0.</li> <li>Type: MUST be 0x0.</li>
<li>Z: MUST be 0x1.</li> <li>Z: MUST be 0x1.</li>
<li>Subnet-ID: Configured subnet identifier.</li> <li>Subnet-ID: Configured subnet identifier.</li>
<li>Interface Identifier.</li> <li>Interface Identifier.</li>
</ul> </ul>
<t>This sub-scheme is meant for "manual" allocation to subnets where the other addressing schemes cannot be used. The primary use case is for assignment to ACP connect subnets (see <xref target="NMS" format="default"/>).</t> <t>This sub-scheme is meant for "manual" allocation to subnets where the other addressing schemes cannot be used. The primary use case is for assignment to ACP connect subnets (see <xref target="NMS" format="default"/>).</t>
skipping to change at line 1853 skipping to change at line 1831
<t>The Z bit field was added to distinguish Zone addressing and manual addressing sub-schemes without requiring one more bit in the base scheme and therefore allowing for the Vlong scheme (described below) to have one more bit available.</t> <t>The Z bit field was added to distinguish Zone addressing and manual addressing sub-schemes without requiring one more bit in the base scheme and therefore allowing for the Vlong scheme (described below) to have one more bit available.</t>
<t>Manual addressing sub-scheme addresses SHOULD NOT be used in ACP certificates. Any node capable to build ACP secure channels and permitted by Registrar policy to participate in building ACP secure channels SHOULD receive an ACP address (prefix) from one of the other ACP addressing sub-schemes. Nodes not capable (or permitted) to participate in ACP secure channels can connect to the ACP via ACP connect interfaces of ACP edge nodes (see <xref target="ACPconnect" format="default"/>), without setting up an ACP secure channel. Their ACP certificate MUST omit the acp-address field to indicate that their ACP certificate is only usable for non- ACP secure channel authentication, such as end-to-end transport connections across the ACP or Data-Plane.</t> <t>Manual addressing sub-scheme addresses SHOULD NOT be used in ACP certificates. Any node capable to build ACP secure channels and permitted by Registrar policy to participate in building ACP secure channels SHOULD receive an ACP address (prefix) from one of the other ACP addressing sub-schemes. Nodes not capable (or permitted) to participate in ACP secure channels can connect to the ACP via ACP connect interfaces of ACP edge nodes (see <xref target="ACPconnect" format="default"/>), without setting up an ACP secure channel. Their ACP certificate MUST omit the acp-address field to indicate that their ACP certificate is only usable for non- ACP secure channel authentication, such as end-to-end transport connections across the ACP or Data-Plane.</t>
<t>Address management of ACP connect subnets is done using traditional assignment methods and existing IPv6 protocols. See <xref target="ACautoconfig" format="default"/> for details. Therefore, the notion of V-bit many addresses assigned to the ACP nodes does not apply to this Sub-Scheme.</t> <t>Address management of ACP connect subnets is done using traditional assignment methods and existing IPv6 protocols. See <xref target="ACautoconfig" format="default"/> for details. Therefore, the notion of V-bit many addresses assigned to the ACP nodes does not apply to this Sub-Scheme.</t>
</section> </section>
<!-- manual --> <!-- manual -->
<section anchor="Vlong" numbered="true" toc="default"> <section anchor="Vlong" numbered="true" toc="default">
<name>ACP Vlong Addressing Sub-Scheme (ACP-VLong-8/ACP-VLong-16</name> <name>ACP Vlong Addressing Sub-Scheme (ACP-VLong-8/ACP-VLong-16</name>
<t>This sub-scheme is used when the Type field of the base scheme is 0x01.</t> <t>This sub-scheme is used when the Type field of the base scheme is 0x01.</t>
<figure anchor="v8-scheme"> <figure anchor="v8-scheme">
<name>ACP Vlong Addressing Sub-Scheme</name> <name>ACP Vlong Addressing Sub-Scheme</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt="">
50 78 50 78
+---------------------++-----------------------------+----------+ +---------------------++-----------------------------+----------+
| (base scheme) || Node-ID | | (base scheme) || Node-ID |
| || Registrar-ID |F| Node-Number| V | | || Registrar-ID |F| Node-Number| V |
+---------------------++--------------+--------------+----------+ +---------------------++--------------+--------------+----------+
50 46 1 23/15 8/16 50 46 1 23/15 8/16
]]></artwork> </artwork>
</figure> </figure>
<t> <t>
This addressing scheme foregoes the Zone-ID field to allow This addressing scheme foregoes the Zone-ID field to allow
for larger, flatter routed networks (e.g., as in IoT) with for larger, flatter routed networks (e.g., as in IoT) with
8421376 Node-Numbers (2^23+2^15). It also allows for up to 8421376 Node-Numbers (2^23+2^15). It also allows for up to
2^16 (i.e. 65536) different virtualized addresses within a 2^16 (i.e. 65536) different virtualized addresses within a
node, which could be used to address individual software node, which could be used to address individual software
components in an ACP node. components in an ACP node.
</t> </t>
<t> <t>
skipping to change at line 2542 skipping to change at line 2520
<!-- acp_general --> <!-- acp_general -->
</section> </section>
<!-- self-creation --> <!-- self-creation -->
<section anchor="acp-l2-switches" numbered="true" toc="default"> <section anchor="acp-l2-switches" numbered="true" toc="default">
<name>ACP support on L2 switches/ports (Normative)</name> <name>ACP support on L2 switches/ports (Normative)</name>
<section anchor="acp-l2-switches-why" numbered="true" toc="default"> <section anchor="acp-l2-switches-why" numbered="true" toc="default">
<name>Why (Benefits of ACP on L2 switches)</name> <name>Why (Benefits of ACP on L2 switches)</name>
<figure anchor="acp-example"> <figure anchor="acp-example">
<name>Topology with L2 ACP switches</name> <name>Topology with L2 ACP switches</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt="">
ANrtr1 ------ ANswitch1 --- ANswitch2 ------- ANrtr2 ANrtr1 ------ ANswitch1 --- ANswitch2 ------- ANrtr2
.../ \ \ ... .../ \ \ ...
ANrtrM ------ \ ------- ANrtrN ANrtrM ------ \ ------- ANrtrN
ANswitchM ... ANswitchM ...
]]></artwork> </artwork>
</figure> </figure>
<t>Consider a large L2 LAN with ANrtr1...ANrtrN connected via some topology of L2 switches. <t>Consider a large L2 LAN with ANrtr1...ANrtrN connected via some topology of L2 switches.
Examples include large enterprise campus networks with an L2 core, IoT networks or broadband Examples include large enterprise campus networks with an L2 core, IoT networks or broadband
aggregation networks which often have even a multi-level L2 switched topology.</t> aggregation networks which often have even a multi-level L2 switched topology.</t>
<t>If the discovery protocol used for the ACP is operating at the subnet level, every ACP router <t>If the discovery protocol used for the ACP is operating at the subnet level, every ACP router
will see all other ACP routers on the LAN as neighbors and a full mesh of ACP channels will be built. will see all other ACP routers on the LAN as neighbors and a full mesh of ACP channels will be built.
If some or all of the AN switches are autonomic with the same discovery protocol, then the If some or all of the AN switches are autonomic with the same discovery protocol, then the
full mesh would include those switches as well.</t> full mesh would include those switches as well.</t>
<t>A full mesh of ACP connections can create fundamental scale challenges. The number of <t>A full mesh of ACP connections can create fundamental scale challenges. The number of
security associations of the secure channel protocols will likely not scale arbitrarily, security associations of the secure channel protocols will likely not scale arbitrarily,
skipping to change at line 2648 skipping to change at line 2626
<name>Support for Non-ACP Components (Normative)</name> <name>Support for Non-ACP Components (Normative)</name>
<section anchor="ACPconnect" numbered="true" toc="default"> <section anchor="ACPconnect" numbered="true" toc="default">
<name>ACP Connect</name> <name>ACP Connect</name>
<section anchor="NMS" numbered="true" toc="default"> <section anchor="NMS" numbered="true" toc="default">
<name>Non-ACP Controller / NMS system</name> <name>Non-ACP Controller / NMS system</name>
<t>The Autonomic Control Plane can be used by management systems, such as controllers or network management system (NMS) hosts (henceforth called simply "NMS hosts"), to connect to devices (or other type of nodes) through it. For this, an NMS host needs to have access to the ACP. The ACP is a self-protecting overlay network, which allows by default access only to trusted, autonomic systems. Therefore, a traditional, non-ACP NMS system does not have access to the ACP by default, such as any other external node.</t> <t>The Autonomic Control Plane can be used by management systems, such as controllers or network management system (NMS) hosts (henceforth called simply "NMS hosts"), to connect to devices (or other type of nodes) through it. For this, an NMS host needs to have access to the ACP. The ACP is a self-protecting overlay network, which allows by default access only to trusted, autonomic systems. Therefore, a traditional, non-ACP NMS system does not have access to the ACP by default, such as any other external node.</t>
<t>If the NMS host is not autonomic, i.e., it does not support autonomic negotiation of the ACP, then it can be brought into the ACP by explicit configuration. To support connections to adjacent non-ACP nodes, an ACP node SHOULD support "ACP connect" (sometimes also called "autonomic connect"):</t> <t>If the NMS host is not autonomic, i.e., it does not support autonomic negotiation of the ACP, then it can be brought into the ACP by explicit configuration. To support connections to adjacent non-ACP nodes, an ACP node SHOULD support "ACP connect" (sometimes also called "autonomic connect"):</t>
<t>"ACP connect" is an interface level configured workaround for connection of trusted non-ACP nodes to the ACP. The ACP node on which ACP connect is configured is called an "ACP edge node". With ACP connect, the ACP is accessible from those non-ACP nodes (such as NOC systems) on such an interface without those non-ACP nodes having to support any ACP discovery or ACP channel setup. This is also called "native" access to the ACP because to those NOC systems the interface looks like a normal network interface without any ACP secure channel that is encapsulating the traffic.</t> <t>"ACP connect" is an interface level configured workaround for connection of trusted non-ACP nodes to the ACP. The ACP node on which ACP connect is configured is called an "ACP edge node". With ACP connect, the ACP is accessible from those non-ACP nodes (such as NOC systems) on such an interface without those non-ACP nodes having to support any ACP discovery or ACP channel setup. This is also called "native" access to the ACP because to those NOC systems the interface looks like a normal network interface without any ACP secure channel that is encapsulating the traffic.</t>
<figure anchor="acp-connect"> <figure anchor="acp-connect">
<name>ACP connect</name> <name>ACP connect</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt="">
Data-Plane "native" (no ACP) Data-Plane "native" (no ACP)
. .
+--------+ +----------------+ . +-------------+ +--------+ +----------------+ . +-------------+
| ACP | |ACP Edge Node | . | | | ACP | |ACP Edge Node | . | |
| Node | | | v | | | Node | | | v | |
| |-------|...[ACP VRF]....+----------------| |+ | |-------|...[ACP VRF]....+----------------| |+
| | ^ |. | | NOC Device || | | ^ |. | | NOC Device ||
| | . | .[Data-Plane]..+----------------| "NMS hosts" || | | . | .[Data-Plane]..+----------------| "NMS hosts" ||
| | . | [ ] | . ^ | || | | . | [ ] | . ^ | ||
+--------+ . +----------------+ . . +-------------+| +--------+ . +----------------+ . . +-------------+|
. . . +-------------+ . . . +-------------+
. . . . . .
Data-Plane "native" . ACP "native" (unencrypted) Data-Plane "native" . ACP "native" (unencrypted)
+ ACP auto-negotiated . "ACP connect subnet" + ACP auto-negotiated . "ACP connect subnet"
and encrypted . and encrypted .
ACP connect interface ACP connect interface
e.g., "VRF ACP native" (config) e.g., "VRF ACP native" (config)
]]></artwork> </artwork>
</figure> </figure>
<t>ACP connect has security consequences: All systems and processes connected via ACP connect have access to all ACP nodes on the entire ACP, without further authentication. Thus, the ACP connect interface and NOC systems connected to it needs to be physically controlled/secured. For this reason the mechanisms described here do explicitly not include options to allow for a non-ACP router to be connected across an ACP connect interface and addresses behind such a router routed inside the ACP.</t> <t>ACP connect has security consequences: All systems and processes connected via ACP connect have access to all ACP nodes on the entire ACP, without further authentication. Thus, the ACP connect interface and NOC systems connected to it needs to be physically controlled/secured. For this reason the mechanisms described here do explicitly not include options to allow for a non-ACP router to be connected across an ACP connect interface and addresses behind such a router routed inside the ACP.</t>
<t>Physical controlled/secured means that attackers can gain no access to the physical device hosting the ACP Edge Node, the physical interfaces and links providing the ACP connect link nor the physical devices hosting the NOC Device. In a simple case, ACP Edge node and NOC Device are co-located in an access controlled room, such as a NOC, to which attackers cannot gain physical access.</t> <t>Physical controlled/secured means that attackers can gain no access to the physical device hosting the ACP Edge Node, the physical interfaces and links providing the ACP connect link nor the physical devices hosting the NOC Device. In a simple case, ACP Edge node and NOC Device are co-located in an access controlled room, such as a NOC, to which attackers cannot gain physical access.</t>
<t>An ACP connect interface provides exclusively access to only the ACP. This is likely insufficient for many NMS hosts. Instead, they would require a second "Data-Plane" interface outside the ACP for connections between the NMS host and administrators, or Internet based services, or for direct access to the Data-Plane. The document <xref target="RFC8368" format="default">"Using Autonomic Control Plane for Stable Connectivity of Network OAM"</xref> explains in more detail how the ACP can be integrated in a mixed NOC environment.</t> <t>An ACP connect interface provides exclusively access to only the ACP. This is likely insufficient for many NMS hosts. Instead, they would require a second "Data-Plane" interface outside the ACP for connections between the NMS host and administrators, or Internet based services, or for direct access to the Data-Plane. The document <xref target="RFC8368" format="default">"Using Autonomic Control Plane for Stable Connectivity of Network OAM"</xref> explains in more detail how the ACP can be integrated in a mixed NOC environment.</t>
<t>An ACP connect interface SHOULD use an IPv6 address/prefix <t>An ACP connect interface SHOULD use an IPv6 address/prefix
from the ACP Manual Addressing Sub-Scheme (<xref target="manual-scheme" format="default"/>), letting the operator configure for example only the Subnet-ID and having the node automatically assign the remaining part of the prefix/address. It SHOULD NOT use a prefix that is also routed outside the ACP so that the addresses clearly indicate whether it is used inside the ACP or not.</t> from the ACP Manual Addressing Sub-Scheme (<xref target="manual-scheme" format="default"/>), letting the operator configure for example only the Subnet-ID and having the node automatically assign the remaining part of the prefix/address. It SHOULD NOT use a prefix that is also routed outside the ACP so that the addresses clearly indicate whether it is used inside the ACP or not.</t>
<t>The prefix of ACP connect subnets MUST be distributed by the ACP edge node into the ACP routing protocol RPL. The NMS hosts MUST connect to prefixes in the ACP routing table via its ACP connect interface. In the simple case where the ACP uses only one ULA prefix and all ACP connect subnets have prefixes covered by that ULA prefix, NMS hosts can rely on <xref target="RFC6724" format="default"/> to determine longest match prefix routes towards its different interfaces, ACP and Data-Plane. With RFC6724, The NMS host will select the ACP connect interface for all addresses in the ACP because any ACP destination address is longest matched by the address on the ACP connect interface. If the NMS hosts ACP connect interface uses another prefix or if the ACP uses multiple ULA prefixes, then the NMS hosts require (static) routes towards the ACP interface for these prefixes.</t> <t>The prefix of ACP connect subnets MUST be distributed by the ACP edge node into the ACP routing protocol RPL. The NMS hosts MUST connect to prefixes in the ACP routing table via its ACP connect interface. In the simple case where the ACP uses only one ULA prefix and all ACP connect subnets have prefixes covered by that ULA prefix, NMS hosts can rely on <xref target="RFC6724" format="default"/> to determine longest match prefix routes towards its different interfaces, ACP and Data-Plane. With RFC6724, The NMS host will select the ACP connect interface for all addresses in the ACP because any ACP destination address is longest matched by the address on the ACP connect interface. If the NMS hosts ACP connect interface uses another prefix or if the ACP uses multiple ULA prefixes, then the NMS hosts require (static) routes towards the ACP interface for these prefixes.</t>
<t> When an ACP Edge node receives a packet from an ACP connect interface, the ACP Edge node <t> When an ACP Edge node receives a packet from an ACP connect interface, the ACP Edge node
MUST only forward the packet into the ACP if the packet has an IPv6 source address from that interface (this is sometimes called "RPF filtering"). This filtering rule MAY be changed through administrative measures. The more any such administrative action enable reachability of non ACP nodes to the ACP, the more this may cause security issues.</t> MUST only forward the packet into the ACP if the packet has an IPv6 source address from that interface (this is sometimes called "RPF filtering"). This filtering rule MAY be changed through administrative measures. The more any such administrative action enable reachability of non ACP nodes to the ACP, the more this may cause security issues.</t>
<t>To limit the security impact of ACP connect, nodes supporting it SHOULD implement a security <t>To limit the security impact of ACP connect, nodes supporting it SHOULD implement a security
skipping to change at line 2731 skipping to change at line 2709
If ACP interfaces are configured with non ULA prefixes, then those prefixes cannot be aggregated without further configured policy on the ACP edge node. This explains the above recommendation to use ACP ULA prefix covered prefixes for ACP connect interfaces: They allow for a shorter list of prefixes to be signaled via RFC4191 to NMS hosts and software components.</t> If ACP interfaces are configured with non ULA prefixes, then those prefixes cannot be aggregated without further configured policy on the ACP edge node. This explains the above recommendation to use ACP ULA prefix covered prefixes for ACP connect interfaces: They allow for a shorter list of prefixes to be signaled via RFC4191 to NMS hosts and software components.</t>
<t>The ACP edge nodes that have a Vlong ACP address MAY allocate a subset of their /112 or /120 address prefix to ACP connect interface(s) to eliminate the need to non-autonomically configure/provision the address prefixes for such ACP connect interfaces.</t> <t>The ACP edge nodes that have a Vlong ACP address MAY allocate a subset of their /112 or /120 address prefix to ACP connect interface(s) to eliminate the need to non-autonomically configure/provision the address prefixes for such ACP connect interfaces.</t>
<!-- See <xref target="up4291"/> for considerations how this updates the IPv6 address architecture and ULA specification.</t> --> <!-- See <xref target="up4291"/> for considerations how this updates the IPv6 address architecture and ULA specification.</t> -->
</section> </section>
<!-- ACautoconfig --> <!-- ACautoconfig -->
<section anchor="SingleIF" numbered="true" toc="default"> <section anchor="SingleIF" numbered="true" toc="default">
<name>Combined ACP/Data-Plane Interface (VRF Select)</name> <name>Combined ACP/Data-Plane Interface (VRF Select)</name>
<figure anchor="vrf-select"> <figure anchor="vrf-select">
<name>VRF select</name> <name>VRF select</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt="">
Combined ACP and Data-Plane interface Combined ACP and Data-Plane interface
. .
+--------+ +--------------------+ . +--------------+ +--------+ +--------------------+ . +--------------+
| ACP | |ACP Edge No | . | NMS Host(s) | | ACP | |ACP Edge No | . | NMS Host(s) |
| Node | | | . | / Software | | Node | | | . | / Software |
| | | [ACP ]. | . | |+ | | | [ACP ]. | . | |+
| | | .[VRF ] .[VRF ] | v | "ACP address"|| | | | .[VRF ] .[VRF ] | v | "ACP address"||
| +-------+. .[Select].+--------+ "Date Plane || | +-------+. .[Select].+--------+ "Date Plane ||
| | ^ | .[Data ]. | | Address(es)"|| | | ^ | .[Data ]. | | Address(es)"||
| | . | [Plane] | | || | | . | [Plane] | | ||
| | . | [ ] | +--------------+| | | . | [ ] | +--------------+|
+--------+ . +--------------------+ +--------------+ +--------+ . +--------------------+ +--------------+
. .
Data-Plane "native" and + ACP auto-negotiated/encrypted Data-Plane "native" and + ACP auto-negotiated/encrypted
]]></artwork> </artwork>
</figure> </figure>
<t>Using two physical and/or virtual subnets (and therefore interfaces) into NMS Hosts (as per <xref target="NMS" format="default"/>) or Software (as per <xref target="software" format="default"/>) may be seen as additional complexity, for example with legacy NMS Hosts that support only one IP interface, or it may be insufficient to support <xref target="RFC4191" format="default"/> Type A or B host (see <xref target="ACautoconfig" format="default"/>).</t> <t>Using two physical and/or virtual subnets (and therefore interfaces) into NMS Hosts (as per <xref target="NMS" format="default"/>) or Software (as per <xref target="software" format="default"/>) may be seen as additional complexity, for example with legacy NMS Hosts that support only one IP interface, or it may be insufficient to support <xref target="RFC4191" format="default"/> Type A or B host (see <xref target="ACautoconfig" format="default"/>).</t>
<t>To provide a single subnet into both ACP and Data-Plane, the ACP Edge node needs to de-multiplex packets from NMS hosts into ACP VRF and Data-Plane. This is sometimes called "VRF select". If the ACP VRF has no overlapping IPv6 addresses with the Data-Plane (it should have no overlapping addresses), then this function can use the IPv6 Destination address. The problem is Source Address Selection on the NMS Host(s) according to RFC6724.</t> <t>To provide a single subnet into both ACP and Data-Plane, the ACP Edge node needs to de-multiplex packets from NMS hosts into ACP VRF and Data-Plane. This is sometimes called "VRF select". If the ACP VRF has no overlapping IPv6 addresses with the Data-Plane (it should have no overlapping addresses), then this function can use the IPv6 Destination address. The problem is Source Address Selection on the NMS Host(s) according to RFC6724.</t>
<t>Consider the simple case: The ACP uses only one ULA prefix, the ACP IPv6 prefix for the Combined ACP and Data-Plane interface is covered by that ULA prefix. The ACP edge node announces both the ACP IPv6 prefix and one (or more) prefixes for the Data-Plane. Without further policy configurations on the NMS Host(s), it may select its ACP address as a source address for Data-Plane ULA destinations because of Rule 8 of RFC6724. The ACP edge node can pass on the packet to the Data-Plane, but the ACP source address should not be used for Data-Plane traffic, and return traffic may fail.</t> <t>Consider the simple case: The ACP uses only one ULA prefix, the ACP IPv6 prefix for the Combined ACP and Data-Plane interface is covered by that ULA prefix. The ACP edge node announces both the ACP IPv6 prefix and one (or more) prefixes for the Data-Plane. Without further policy configurations on the NMS Host(s), it may select its ACP address as a source address for Data-Plane ULA destinations because of Rule 8 of RFC6724. The ACP edge node can pass on the packet to the Data-Plane, but the ACP source address should not be used for Data-Plane traffic, and return traffic may fail.</t>
<t>If the ACP carries multiple ULA prefixes or non-ULA ACP connect prefixes, then the correct source address selection becomes even more problematic.</t> <t>If the ACP carries multiple ULA prefixes or non-ULA ACP connect prefixes, then the correct source address selection becomes even more problematic.</t>
<t>With separate ACP connect and Data-Plane subnets and RFC4191 prefix announcements that are to be routed across the ACP connect interface, RFC6724 source address selection Rule 5 (use address of outgoing interface) will be used, so that above problems do not occur, even in more complex cases of multiple ULA and non-ULA prefixes in the ACP routing table.</t> <t>With separate ACP connect and Data-Plane subnets and RFC4191 prefix announcements that are to be routed across the ACP connect interface, RFC6724 source address selection Rule 5 (use address of outgoing interface) will be used, so that above problems do not occur, even in more complex cases of multiple ULA and non-ULA prefixes in the ACP routing table.</t>
<t>To achieve the same behavior with a Combined ACP and Data-Plane interface, the ACP Edge Node needs to behave as two separate routers on the interface: One link-local IPv6 address/router for its ACP reachability, and one link-local IPv6 address/router for its Data-Plane reachability. The Router Advertisements for both are as described above (<xref target="ACautoconfig" format="default"/>): For the ACP, the ACP prefix is announced together with RFC4191 option for the prefixes routed across the ACP and lifetime=0 to disqualify this next-hop as a default router. For the Data-Plane, the Data-Plane prefix(es) are announced together with whatever dafault router parameters are used for the Data-Plane.</t> <t>To achieve the same behavior with a Combined ACP and Data-Plane interface, the ACP Edge Node needs to behave as two separate routers on the interface: One link-local IPv6 address/router for its ACP reachability, and one link-local IPv6 address/router for its Data-Plane reachability. The Router Advertisements for both are as described above (<xref target="ACautoconfig" format="default"/>): For the ACP, the ACP prefix is announced together with RFC4191 option for the prefixes routed across the ACP and lifetime=0 to disqualify this next-hop as a default router. For the Data-Plane, the Data-Plane prefix(es) are announced together with whatever dafault router parameters are used for the Data-Plane.</t>
<t>In result, RFC6724 source address selection Rule 5.5 may result in the same correct source address selection behavior of NMS hosts without further configuration on it as the separate ACP connect and Data-Plane interfaces. As described in the text for Rule 5.5, this is only a MAY, because IPv6 hosts are not required to track next-hop information. If an NMS Host does not do this, then separate ACP connect and Data-Plane interfaces are the preferable method of attachment. Hosts implementing <xref target="RFC8028" format="default"/> should (instead of may) implement <xref target="RFC6724" format="default"/> Rule 5.5, so it is preferred for hosts to support <xref target="RFC8028" format="default"/>.</t> <t>In result, RFC6724 source address selection Rule 5.5 may result in the same correct source address selection behavior of NMS hosts without further configuration on it as the separate ACP connect and Data-Plane interfaces. As described in the text for Rule 5.5, this is only a MAY, because IPv6 hosts are not required to track next-hop information. If an NMS Host does not do this, then separate ACP connect and Data-Plane interfaces are the preferable method of attachment. Hosts implementing <xref target="RFC8028" format="default"/> should (instead of may) implement <xref target="RFC6724" format="default"/> Rule 5.5, so it is preferred for hosts to support <xref target="RFC8028" format="default"/>.</t>
<t>ACP edge nodes MAY support the Combined ACP and Data-Plane interface.</t> <t>ACP edge nodes MAY support the Combined ACP and Data-Plane interface.</t>
</section> </section>
skipping to change at line 2797 skipping to change at line 2775
<!-- ACP connect --> <!-- ACP connect -->
<section anchor="remote-acp-neighbors" numbered="true" toc="default"> <section anchor="remote-acp-neighbors" numbered="true" toc="default">
<name>Connecting ACP islands over Non-ACP L3 networks (Remote ACP neighbors)</name> <name>Connecting ACP islands over Non-ACP L3 networks (Remote ACP neighbors)</name>
<t>Not all nodes in a network may support the ACP. If non-ACP Layer-2 devices are between ACP nodes, the ACP will work across it since it is IP based. However, the autonomic discovery of ACP neighbors via DULL GRASP is only intended to work across L2 connections, so it is not sufficient to autonomically create ACP connections across non-ACP Layer-3 devices.</t> <t>Not all nodes in a network may support the ACP. If non-ACP Layer-2 devices are between ACP nodes, the ACP will work across it since it is IP based. However, the autonomic discovery of ACP neighbors via DULL GRASP is only intended to work across L2 connections, so it is not sufficient to autonomically create ACP connections across non-ACP Layer-3 devices.</t>
<section anchor="conf-remote" numbered="true" toc="default"> <section anchor="conf-remote" numbered="true" toc="default">
<name>Configured Remote ACP neighbor</name> <name>Configured Remote ACP neighbor</name>
<t>On the ACP node, remote ACP neighbors are configured explicitly. <t>On the ACP node, remote ACP neighbors are configured explicitly.
The parameters of such a "connection" are described in the following ABNF.</t> The parameters of such a "connection" are described in the following ABNF.</t>
<figure anchor="abnf"> <figure anchor="abnf">
<name>Parameters for remote ACP neighbors</name> <name>Parameters for remote ACP neighbors</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt="">
connection = [ method , local-addr, remote-addr, ?pmtu ] connection = [ method , local-addr, remote-addr, ?pmtu ]
method = [ "IKEv2", ?port ] method = [ "IKEv2", ?port ]
method =/ [ "DTLS", port ] method =/ [ "DTLS", port ]
local-addr = [ address , ?vrf ] local-addr = [ address , ?vrf ]
remote-addr = [ address ] remote-addr = [ address ]
address = ("any" | ipv4-address | ipv6-address ) address = ("any" | ipv4-address | ipv6-address )
vrf = tstr ; Name of a VRF on this node with local-address vrf = tstr ; Name of a VRF on this node with local-address
]]></artwork> </artwork>
</figure> </figure>
<t>Explicit configuration of a remote-peer according to this <t>Explicit configuration of a remote-peer according to this
ABNF provides all the information to build a secure channel without requiring a tunnel ABNF provides all the information to build a secure channel without requiring a tunnel
to that peer and running DULL GRASP inside of it.</t> to that peer and running DULL GRASP inside of it.</t>
<t>The configuration includes the parameters otherwise signaled <t>The configuration includes the parameters otherwise signaled
via DULL GRASP: local address, remote (peer) locator and via DULL GRASP: local address, remote (peer) locator and
method. The differences over DULL GRASP local neighbor method. The differences over DULL GRASP local neighbor
discovery and secure channel creation are as follows:</t> discovery and secure channel creation are as follows:</t>
<ul spacing="compact"> <ul spacing="compact">
<li>The local and remote address can be IPv4 or IPv6 and are typically global scope addresses.</li> <li>The local and remote address can be IPv4 or IPv6 and are typically global scope addresses.</li>
skipping to change at line 2919 skipping to change at line 2897
</ul> </ul>
<t>The simplest form of diagnostics answering questions such as the above <t>The simplest form of diagnostics answering questions such as the above
is to represent the relevant information sequentially in dependency order, is to represent the relevant information sequentially in dependency order,
so that the first non-expected/non-operational item is the most likely root so that the first non-expected/non-operational item is the most likely root
cause. Or just log/highlight that item. For example:</t> cause. Or just log/highlight that item. For example:</t>
<t>Q: Is ACP operational to accept neighbor connections: <t>Q: Is ACP operational to accept neighbor connections:
</t> </t>
<ul spacing="compact"> <ul spacing="compact">
<li>Check if any potentially necessary configuration to make ACP/ANI operational are correct (see <xref target="enabling-acp" format="default"/> for a discussion of such commands).</li> <li>Check if any potentially necessary configuration to make ACP/ANI operational are correct (see <xref target="enabling-acp" format="default"/> for a discussion of such commands).</li>
<li>Does the system time look reasonable, or could it be the default system time after clock chip battery failure (certificate checks depend on reasonable notion of time)?.</li> <li>Does the system time look reasonable, or could it be the default system time after clock chip battery failure (certificate checks depend on reasonable notion of time)?.</li>
<li>Does the node have keying material - domain certificate, TA certificates, ...></li> <li>Does the node have keying material - domain certificate, TA certificates, ...&gt;</li>
<li>If no keying material and ANI is supported/enabled, <li>If no keying material and ANI is supported/enabled,
check the state of BRSKI (not detailed in this example).</li> check the state of BRSKI (not detailed in this example).</li>
<li> <li>
<t>Check the validity of the domain certificate: <t>Check the validity of the domain certificate:
</t> </t>
<ul spacing="compact"> <ul spacing="compact">
<li>Does the certificate validate against the TA?</li> <li>Does the certificate validate against the TA?</li>
<li>Has it been revoked?</li> <li>Has it been revoked?</li>
<li>Was the last scheduled attempt to retrieve a CRL successful (e.g., do we know that our CRL information is up to date).</li> <li>Was the last scheduled attempt to retrieve a CRL successful (e.g., do we know that our CRL information is up to date).</li>
<li>Is the certificate valid: validity start time in the past, expiration time in the future?</li> <li>Is the certificate valid: validity start time in the past, expiration time in the future?</li>
skipping to change at line 3750 skipping to change at line 3728
<t>Improved several textual nits.</t> <t>Improved several textual nits.</t>
<t>Discuss/Comments from Erik Kline:</t> <t>Discuss/Comments from Erik Kline:</t>
<t>Editorial suggestions and nits. Thanks!.</t> <t>Editorial suggestions and nits. Thanks!.</t>
<t>6.1.3 Added text about how/why rsub is irrelevant for domain membership check.</t> <t>6.1.3 Added text about how/why rsub is irrelevant for domain membership check.</t>
<t>6.3 Added extension points to AN_ACP DULL GRASP objective because for example ACP domain certificate could be a nice optional additional parameter and prior syntax would have forced us to encode into separate objective unnecessarily.</t> <t>6.3 Added extension points to AN_ACP DULL GRASP objective because for example ACP domain certificate could be a nice optional additional parameter and prior syntax would have forced us to encode into separate objective unnecessarily.</t>
<t>6.7 Using RFC8415 terminology for exponential backoff parameters.</t> <t>6.7 Using RFC8415 terminology for exponential backoff parameters.</t>
<t>6.11.2 Amended ACP Sub-Addressing table with future code points, explanations and prefix announced into RPL.</t> <t>6.11.2 Amended ACP Sub-Addressing table with future code points, explanations and prefix announced into RPL.</t>
<t>6.12.1.11. Reworked text to better explain how black hole route works and added expanation for prefix for manual address scheme.</t> <t>6.12.1.11. Reworked text to better explain how black hole route works and added expanation for prefix for manual address scheme.</t>
<t>8.1.3. Reworked explanation of RIOs for ACP connect interfaces for Type C vs. Type A/B hosts.</t> <t>8.1.3. Reworked explanation of RIOs for ACP connect interfaces for Type C vs. Type A/B hosts.</t>
<t>8.1.4. Added explanation how this "VRF select" option is required for auto-attachment of Type A/B hosts to ACP and other networks.</t> <t>8.1.4. Added explanation how this "VRF select" option is required for auto-attachment of Type A/B hosts to ACP and other networks.</t>
<t></t> <t/>
<t>Discuss/Comments from Barry Leiba:</t> <t>Discuss/Comments from Barry Leiba:</t>
<t>Various editorial nits - thanks.</t> <t>Various editorial nits - thanks.</t>
<t>6.1 New section pulling in TLS requirements, no need anymore to duplicat for ACP GRASP, EST, BRSKI (ACP/ANI nodes) and (if desired) OCSP/CRLDP. Added rule to start use secure channel only after negotiation has finished. Added rules not to optimize negotiation across multiple L2 interfaces to the same peer.</t> <t>6.1 New section pulling in TLS requirements, no need anymore to duplicat for ACP GRASP, EST, BRSKI (ACP/ANI nodes) and (if desired) OCSP/CRLDP. Added rule to start use secure channel only after negotiation has finished. Added rules not to optimize negotiation across multiple L2 interfaces to the same peer.</t>
<t>6.6 Changed role names in secure channel negotiation process: Alice/Bob -> Decider/Follower. Explanation enhancements. Added definition for ACP nodes with "0" address.</t> <t>6.6 Changed role names in secure channel negotiation process: Alice/Bob -&gt; Decider/Follower. Explanation enhancements. Added definition for ACP nodes with "0" address.</t>
<t>6.8.3 Improved explanation how IKEv2 forces preference of IPsec over GRE due to ACP IPsec profiles being Tunneled vs. Transport.</t> <t>6.8.3 Improved explanation how IKEv2 forces preference of IPsec over GRE due to ACP IPsec profiles being Tunneled vs. Transport.</t>
<t>6.8.4 Limited mentioning of DTLS version requirements to this section.</t> <t>6.8.4 Limited mentioning of DTLS version requirements to this section.</t>
<t>6.9.2 Removed TLS requirements, they are now in 6.1.</t> <t>6.9.2 Removed TLS requirements, they are now in 6.1.</t>
<t>6.10.6 Removed explanation of IANA allocation requirement. Redundant - already in IANA section, and was seen as confusing.</t> <t>6.10.6 Removed explanation of IANA allocation requirement. Redundant - already in IANA section, and was seen as confusing.</t>
<t>8.1.1 Clarified that there can be security impacts when weakening directly connected address RPF filtering for ACP connect interfaces.</t> <t>8.1.1 Clarified that there can be security impacts when weakening directly connected address RPF filtering for ACP connect interfaces.</t>
<t></t> <t/>
<t>Discuss/Comments from Ben Kaduk:</t> <t>Discuss/Comments from Ben Kaduk:</t>
<t>Many good editorial improvements - thanks!.</t> <t>Many good editorial improvements - thanks!.</t>
<t>5. added explanation of what to do upon failed secure channel establishment.</t> <t>5. added explanation of what to do upon failed secure channel establishment.</t>
<t>6.1.1. refined/extended cert public cey crypto algo and better distinguished algo for the keys of the cert and the key of the signer.</t> <t>6.1.1. refined/extended cert public cey crypto algo and better distinguished algo for the keys of the cert and the key of the signer.</t>
<t>6.1.1. and following: explicitly defining "serialNumber" to be the X.520 subject name serialNumber, not the certificate serial Number.</t> <t>6.1.1. and following: explicitly defining "serialNumber" to be the X.520 subject name serialNumber, not the certificate serial Number.</t>
<t> 6.1.1. emhasize additional authorization step for EST servers (id-kp-cmcRA).</t> <t> 6.1.1. emhasize additional authorization step for EST servers (id-kp-cmcRA).</t>
<t>6.1.2 changed AcpNodeName ABNF to again use 32HEXDIG instead of self-defined variation, because authors overlooked that ABNF is case agnostic (which is fine). Added recommendation to encode as lower case. Added full ABNF encoding for extensions (any characters as in "atoms" except the new "+" separator).</t> <t>6.1.2 changed AcpNodeName ABNF to again use 32HEXDIG instead of self-defined variation, because authors overlooked that ABNF is case agnostic (which is fine). Added recommendation to encode as lower case. Added full ABNF encoding for extensions (any characters as in "atoms" except the new "+" separator).</t>
<t>6.1.5.3. New text to explain reason for use of HTTPS (instead of HTTP) for CRLDP and when and how to use HTTPS then.</t> <t>6.1.5.3. New text to explain reason for use of HTTPS (instead of HTTP) for CRLDP and when and how to use HTTPS then.</t>
<t>6.1.5.5. added text explaning why/how and when to maintain TA data upon failing cert renewal (one version with BRSKI, one version with other, ess secure bootstrap protocols).</t> <t>6.1.5.5. added text explaning why/how and when to maintain TA data upon failing cert renewal (one version with BRSKI, one version with other, ess secure bootstrap protocols).</t>
<t>6.3. new text and requirement about the signaling of transport ports in DULL GRASP - benefits (no well-known ports required), and problems (additional DoS attack vector, albeit not worse than pre-existing ones, depending on setup of L2 subnets.).</t> <t>6.3. new text and requirement about the signaling of transport ports in DULL GRASP - benefits (no well-known ports required), and problems (additional DoS attack vector, albeit not worse than pre-existing ones, depending on setup of L2 subnets.).</t>
<t>6.7.3.1.1. Specified AUTH_HMAC_SHA2_256_128 (as the ESP authentication algorithm).</t> <t>6.7.3.1.1. Specified AUTH_HMAC_SHA2_256_128 (as the ESP authentication algorithm).</t>
<t>6.8.2. Added recommendations for TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256 when supporting TLS 1.3.</t> <t>6.8.2. Added recommendations for TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256 when supporting TLS 1.3.</t>
<t>8.2.2. Added explanation about downgrade attack across configured ACP tunnels and what to do against it.</t> <t>8.2.2. Added explanation about downgrade attack across configured ACP tunnels and what to do against it.</t>
<t>9.3.5.2. Rewrote most of section as it originally was too centric on BRSKI. Should now well describe expectations against automated bootstrap. Introduces new requirement not to call node as in support of ANI if is ALSO has TOFU bootstrap.</t> <t>9.3.5.2. Rewrote most of section as it originally was too centric on BRSKI. Should now well describe expectations against automated bootstrap. Introduces new requirement not to call node as in support of ANI if is ALSO has TOFU bootstrap.</t>
<t>11. Expanded text about malicious EST servers. Added paragraph about ACP secure channel downgrade attacks. Added paragraphs about private PKI as a core to allow security against fake certificates, added paragraph about considerationsproblems when using public PI.</t> <t>11. Expanded text about malicious EST servers. Added paragraph about ACP secure channel downgrade attacks. Added paragraphs about private PKI as a core to allow security against fake certificates, added paragraph about considerationsproblems when using public PI.</t>
<t>A.10.9 New appendix suggesting how to discover ACP secure channel negotiation downgrade attacks.</t> <t>A.10.9 New appendix suggesting how to discover ACP secure channel negotiation downgrade attacks.</t>
<t></t> <t/>
<t>Discuss from Roman Danyliw:</t> <t>Discuss from Roman Danyliw:</t>
<t>6.1.5.1 - Added requirement to only announce SRV.est when a working CA connection.</t> <t>6.1.5.1 - Added requirement to only announce SRV.est when a working CA connection.</t>
<t>15 - Amended security considerations with text about registrar dependencies, security of IDevID/ACP-certificate, EST-Server and GRASP for EST server discovery.</t> <t>15 - Amended security considerations with text about registrar dependencies, security of IDevID/ACP-certificate, EST-Server and GRASP for EST server discovery.</t>
<t>Other:</t> <t>Other:</t>
<t>Conversion to XML v3. Solved empty () taxonomy xref problems. Various formatting fixes for v3.</t> <t>Conversion to XML v3. Solved empty () taxonomy xref problems. Various formatting fixes for v3.</t>
<t>Added contributors section.</t> <t>Added contributors section.</t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>draft-ietf-anima-autonomic-control-plane-28</name> <name>draft-ietf-anima-autonomic-control-plane-28</name>
<t>IESG review Roman Danyliw:</t> <t>IESG review Roman Danyliw:</t>
skipping to change at line 3953 skipping to change at line 3931
<t> Other:</t> <t> Other:</t>
<t>Forgot to update example of ACP domain information to use capitalized hex-digits as required by HEXDIG used.</t> <t>Forgot to update example of ACP domain information to use capitalized hex-digits as required by HEXDIG used.</t>
<t>Added reference to RFC8316 (AN use-cases) to beginning of section 3 (ACP use cases).</t> <t>Added reference to RFC8316 (AN use-cases) to beginning of section 3 (ACP use cases).</t>
<t>Small Enhanced IPsec parameters description / requirements fixes (from Michael Richardson).</t> <t>Small Enhanced IPsec parameters description / requirements fixes (from Michael Richardson).</t>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC1034" target="https://www.rfc-editor.org/info/rfc1034"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/>
<front>
<title>Domain names - concepts and facilities</title>
<seriesInfo name="DOI" value="10.17487/RFC1034"/>
<seriesInfo name="RFC" value="1034"/>
<seriesInfo name="STD" value="13"/>
<author initials="P.V." surname="Mockapetris" fullname="P.V. Mockapetris">
<organization/>
</author>
<date year="1987" month="November"/>
<abstract>
<t>This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="BCP" value="14"/>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<organization/>
</author>
<date year="1997" month="March"/>
<abstract>
<t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC3810" target="https://www.rfc-editor.org/info/rfc3810"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3810.xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4191.xml"/>
<title>Multicast Listener Discovery Version 2 (MLDv2) for IPv6</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4193.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC3810"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4291.xml"/>
<seriesInfo name="RFC" value="3810"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4301.xml"/>
<author initials="R." surname="Vida" fullname="R. Vida" role="editor">
<organization/>
</author>
<author initials="L." surname="Costa" fullname="L. Costa" role="editor">
<organization/>
</author>
<date year="2004" month="June"/>
<abstract>
<t>This document updates RFC 2710, and it specifies Version 2 of the ulticast Listener Discovery Protocol (MLDv2). MLD is used by an IPv6 router to discover the presence of multicast listeners on directly attached links, and to discover which multicast addresses are of interest to those neighboring nodes. MLDv2 is designed to be interoperable with MLDv1. MLDv2 adds the ability for a node to report interest in listening to packets with a particular multicast address only from specific source addresses or from all sources except for specific source addresses. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4191" target="https://www.rfc-editor.org/info/rfc4191">
<front>
<title>Default Router Preferences and More-Specific Routes</title>
<seriesInfo name="DOI" value="10.17487/RFC4191"/>
<seriesInfo name="RFC" value="4191"/>
<author initials="R." surname="Draves" fullname="R. Draves">
<organization/>
</author>
<author initials="D." surname="Thaler" fullname="D. Thaler">
<organization/>
</author>
<date year="2005" month="November"/>
<abstract>
<t>This document describes an optional extension to Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links. The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived from routing tables. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4193" target="https://www.rfc-editor.org/info/rfc4193">
<front>
<title>Unique Local IPv6 Unicast Addresses</title>
<seriesInfo name="DOI" value="10.17487/RFC4193"/>
<seriesInfo name="RFC" value="4193"/>
<author initials="R." surname="Hinden" fullname="R. Hinden">
<organization/>
</author>
<author initials="B." surname="Haberman" fullname="B. Haberman">
<organization/>
</author>
<date year="2005" month="October"/>
<abstract>
<t>This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4291" target="https://www.rfc-editor.org/info/rfc4291">
<front>
<title>IP Version 6 Addressing Architecture</title>
<seriesInfo name="DOI" value="10.17487/RFC4291"/>
<seriesInfo name="RFC" value="4291"/>
<author initials="R." surname="Hinden" fullname="R. Hinden">
<organization/>
</author>
<author initials="S." surname="Deering" fullname="S. Deering">
<organization/>
</author>
<date year="2006" month="February"/>
<abstract>
<t>This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses.</t>
<t>This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4301" target="https://www.rfc-editor.org/info/rfc4301">
<front>
<title>Security Architecture for the Internet Protocol</title>
<seriesInfo name="DOI" value="10.17487/RFC4301"/>
<seriesInfo name="RFC" value="4301"/>
<author initials="S." surname="Kent" fullname="S. Kent">
<organization/>
</author>
<author initials="K." surname="Seo" fullname="K. Seo">
<organization/>
</author>
<date year="2005" month="December"/>
<abstract>
<t>This document describes an updated version of the "Security Architecture for IP", which is designed to provide security services for traffic at the IP layer. This document obsoletes RFC 2401 (November 1998). [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4861" target="https://www.rfc-editor.org/info/rfc4861"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4861.xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4862.xml"/>
<title>Neighbor Discovery for IP version 6 (IPv6)</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC4861"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/>
<seriesInfo name="RFC" value="4861"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
<author initials="T." surname="Narten" fullname="T. Narten"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6550.xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6551.xml"/>
<author initials="E." surname="Nordmark" fullname="E. Nordmark"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6552.xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6553.xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7030.xml"/>
<author initials="W." surname="Simpson" fullname="W. Simpson"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7525.xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7676.xml"/>
<author initials="H." surname="Soliman" fullname="H. Soliman">
<organization/>
</author>
<date year="2007" month="September"/>
<abstract>
<t>This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4862" target="https://www.rfc-editor.org/info/rfc4862">
<front>
<title>IPv6 Stateless Address Autoconfiguration</title>
<seriesInfo name="DOI" value="10.17487/RFC4862"/>
<seriesInfo name="RFC" value="4862"/>
<author initials="S." surname="Thomson" fullname="S. Thomson">
<organization/>
</author>
<author initials="T." surname="Narten" fullname="T. Narten">
<organization/>
</author>
<author initials="T." surname="Jinmei" fullname="T. Jinmei">
<organization/>
</author>
<date year="2007" month="September"/>
<abstract>
<t>This document specifies the steps a host takes in deciding how to autoconfigure its interfaces in IP version 6. The autoconfiguration process includes generating a link-local address, generating global addresses via stateless address autoconfiguration, and the Duplicate Address Detection procedure to verify the uniqueness of the addresses on a link. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5234" target="https://www.rfc-editor.org/info/rfc5234">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<seriesInfo name="DOI" value="10.17487/RFC5234"/>
<seriesInfo name="RFC" value="5234"/>
<seriesInfo name="STD" value="68"/>
<author initials="D." surname="Crocker" fullname="D. Crocker" role="editor">
<organization/>
</author>
<author initials="P." surname="Overell" fullname="P. Overell">
<organization/>
</author>
<date year="2008" month="January"/>
<abstract>
<t>Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5246" target="https://www.rfc-editor.org/info/rfc5246">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<seriesInfo name="DOI" value="10.17487/RFC5246"/>
<seriesInfo name="RFC" value="5246"/>
<author initials="T." surname="Dierks" fullname="T. Dierks">
<organization/>
</author>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization/>
</author>
<date year="2008" month="August"/>
<abstract>
<t>This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5280">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<seriesInfo name="DOI" value="10.17487/RFC5280"/>
<seriesInfo name="RFC" value="5280"/>
<author initials="D." surname="Cooper" fullname="D. Cooper">
<organization/>
</author>
<author initials="S." surname="Santesson" fullname="S. Santesson">
<organization/>
</author>
<author initials="S." surname="Farrell" fullname="S. Farrell">
<organization/>
</author>
<author initials="S." surname="Boeyen" fullname="S. Boeyen">
<organization/>
</author>
<author initials="R." surname="Housley" fullname="R. Housley">
<organization/>
</author>
<author initials="W." surname="Polk" fullname="W. Polk">
<organization/>
</author>
<date year="2008" month="May"/>
<abstract>
<t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6347" target="https://www.rfc-editor.org/info/rfc6347">
<front>
<title>Datagram Transport Layer Security Version 1.2</title>
<seriesInfo name="DOI" value="10.17487/RFC6347"/>
<seriesInfo name="RFC" value="6347"/>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization/>
</author>
<author initials="N." surname="Modadugu" fullname="N. Modadugu">
<organization/>
</author>
<date year="2012" month="January"/>
<abstract>
<t>This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6550" target="https://www.rfc-editor.org/info/rfc6550">
<front>
<title>RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks</title>
<seriesInfo name="DOI" value="10.17487/RFC6550"/>
<seriesInfo name="RFC" value="6550"/>
<author initials="T." surname="Winter" fullname="T. Winter" role="editor">
<organization/>
</author>
<author initials="P." surname="Thubert" fullname="P. Thubert" role="editor">
<organization/>
</author>
<author initials="A." surname="Brandt" fullname="A. Brandt">
<organization/>
</author>
<author initials="J." surname="Hui" fullname="J. Hui">
<organization/>
</author>
<author initials="R." surname="Kelsey" fullname="R. Kelsey">
<organization/>
</author>
<author initials="P." surname="Levis" fullname="P. Levis">
<organization/>
</author>
<author initials="K." surname="Pister" fullname="K. Pister">
<organization/>
</author>
<author initials="R." surname="Struik" fullname="R. Struik">
<organization/>
</author>
<author initials="JP." surname="Vasseur" fullname="JP. Vasseur">
<organization/>
</author>
<author initials="R." surname="Alexander" fullname="R. Alexander">
<organization/>
</author>
<date year="2012" month="March"/>
<abstract>
<t>Low-Power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point as well as point-to-multipoint traffic from the central control point to the devices inside the LLN are supported. Support for point-to-point traffic is also available. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6551" target="https://www.rfc-editor.org/info/rfc6551">
<front>
<title>Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks</title>
<seriesInfo name="DOI" value="10.17487/RFC6551"/>
<seriesInfo name="RFC" value="6551"/>
<author initials="JP." surname="Vasseur" fullname="JP. Vasseur" role="editor">
<organization/>
</author>
<author initials="M." surname="Kim" fullname="M. Kim" role="editor">
<organization/>
</author>
<author initials="K." surname="Pister" fullname="K. Pister">
<organization/>
</author>
<author initials="N." surname="Dejean" fullname="N. Dejean">
<organization/>
</author>
<author initials="D." surname="Barthel" fullname="D. Barthel">
<organization/>
</author>
<date year="2012" month="March"/>
<abstract>
<t>Low-Power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad hoc networks that require the specification of new routing metrics and constraints. By contrast, with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing Protocol for Low-Power and Lossy Networks (RPL). [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6552" target="https://www.rfc-editor.org/info/rfc6552">
<front>
<title>Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)</title>
<seriesInfo name="DOI" value="10.17487/RFC6552"/>
<seriesInfo name="RFC" value="6552"/>
<author initials="P." surname="Thubert" fullname="P. Thubert" role="editor">
<organization/>
</author>
<date year="2012" month="March"/>
<abstract>
<t>The Routing Protocol for Low-Power and Lossy Networks (RPL) specification defines a generic Distance Vector protocol that is adapted to a variety of network types by the application of specific Objective Functions (OFs). An OF states the outcome of the process used by a RPL node to select and optimize routes within a RPL Instance based on the Information Objects available; an OF is not an algorithm.</t>
<t>This document specifies a basic Objective Function that relies only on the objects that are defined in the RPL and does not use any protocol extensions. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6553" target="https://www.rfc-editor.org/info/rfc6553">
<front>
<title>The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams</title>
<seriesInfo name="DOI" value="10.17487/RFC6553"/>
<seriesInfo name="RFC" value="6553"/>
<author initials="J." surname="Hui" fullname="J. Hui">
<organization/>
</author>
<author initials="JP." surname="Vasseur" fullname="JP. Vasseur">
<organization/>
</author>
<date year="2012" month="March"/>
<abstract>
<t>The Routing Protocol for Low-Power and Lossy Networks (RPL) includes routing information in data-plane datagrams to quickly identify inconsistencies in the routing topology. This document describes the RPL Option for use among RPL routers to include such routing information. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7030" target="https://www.rfc-editor.org/info/rfc7030">
<front>
<title>Enrollment over Secure Transport</title>
<seriesInfo name="DOI" value="10.17487/RFC7030"/>
<seriesInfo name="RFC" value="7030"/>
<author initials="M." surname="Pritikin" fullname="M. Pritikin" role="editor">
<organization/>
</author>
<author initials="P." surname="Yee" fullname="P. Yee" role="editor">
<organization/>
</author>
<author initials="D." surname="Harkins" fullname="D. Harkins" role="editor">
<organization/>
</author>
<date year="2013" month="October"/>
<abstract>
<t>This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7296" target="https://www.rfc-editor.org/info/rfc7296">
<front>
<title>Internet Key Exchange Protocol Version 2 (IKEv2)</title>
<seriesInfo name="DOI" value="10.17487/RFC7296"/>
<seriesInfo name="RFC" value="7296"/>
<seriesInfo name="STD" value="79"/>
<author initials="C." surname="Kaufman" fullname="C. Kaufman">
<organization/>
</author>
<author initials="P." surname="Hoffman" fullname="P. Hoffman">
<organization/>
</author>
<author initials="Y." surname="Nir" fullname="Y. Nir">
<organization/>
</author>
<author initials="P." surname="Eronen" fullname="P. Eronen">
<organization/>
</author>
<author initials="T." surname="Kivinen" fullname="T. Kivinen">
<organization/>
</author>
<date year="2014" month="October"/>
<abstract>
<t>This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7525" target="https://www.rfc-editor.org/info/rfc7525">
<front>
<title>Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)</title>
<seriesInfo name="DOI" value="10.17487/RFC7525"/>
<seriesInfo name="RFC" value="7525"/>
<seriesInfo name="BCP" value="195"/>
<author initials="Y." surname="Sheffer" fullname="Y. Sheffer">
<organization/>
</author>
<author initials="R." surname="Holz" fullname="R. Holz">
<organization/>
</author>
<author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre">
<organization/>
</author>
<date year="2015" month="May"/>
<abstract>
<t>Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The recommendations are applicable to the majority of use cases.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7676" target="https://www.rfc-editor.org/info/rfc7676">
<front>
<title>IPv6 Support for Generic Routing Encapsulation (GRE)</title>
<seriesInfo name="DOI" value="10.17487/RFC7676"/>
<seriesInfo name="RFC" value="7676"/>
<author initials="C." surname="Pignataro" fullname="C. Pignataro">
<organization/>
</author>
<author initials="R." surname="Bonica" fullname="R. Bonica">
<organization/>
</author>
<author initials="S." surname="Krishnan" fullname="S. Krishnan">
<organization/>
</author>
<date year="2015" month="October"/>
<abstract>
<t>Generic Routing Encapsulation (GRE) can be used to carry any network- layer payload protocol over any network-layer delivery protocol. Currently, GRE procedures are specified for IPv4, used as either the payload or delivery protocol. However, GRE procedures are not specified for IPv6.</t>
<t>This document specifies GRE procedures for IPv6, used as either the payload or delivery protocol.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="BCP" value="14"/>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization/>
</author>
<date year="2017" month="May"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8221" target="https://www.rfc-editor.org/info/rfc8221"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8221.xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8247.xml"/>
<title>Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)</title>
<seriesInfo name="DOI" value="10.17487/RFC8221"/>
<seriesInfo name="RFC" value="8221"/>
<author initials="P." surname="Wouters" fullname="P. Wouters">
<organization/>
</author>
<author initials="D." surname="Migault" fullname="D. Migault">
<organization/>
</author>
<author initials="J." surname="Mattsson" fullname="J. Mattsson">
<organization/>
</author>
<author initials="Y." surname="Nir" fullname="Y. Nir">
<organization/>
</author>
<author initials="T." surname="Kivinen" fullname="T. Kivinen">
<organization/>
</author>
<date year="2017" month="October"/>
<abstract>
<t>This document replaces RFC 7321, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)". The goal of this document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8247" target="https://www.rfc-editor.org/info/rfc8247">
<front>
<title>Algorithm Implementation Requirements and Usage Guidance for the Internet Key Exchange Protocol Version 2 (IKEv2)</title>
<seriesInfo name="DOI" value="10.17487/RFC8247"/>
<seriesInfo name="RFC" value="8247"/>
<author initials="Y." surname="Nir" fullname="Y. Nir">
<organization/>
</author>
<author initials="T." surname="Kivinen" fullname="T. Kivinen">
<organization/>
</author>
<author initials="P." surname="Wouters" fullname="P. Wouters">
<organization/>
</author>
<author initials="D." surname="Migault" fullname="D. Migault">
<organization/>
</author>
<date year="2017" month="September"/>
<abstract>
<t>The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE) protocol is used to negotiate the IPsec Security Association (IPsec SA) parameters, such as which algorithms should be used. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and usage guidance to ensure that there is at least one algorithm that all implementations support. This document updates RFC 7296 and obsoletes RFC 4307 in defining the current algorithm implementation requirements and usage guidance for IKEv2, and does minor cleaning up of the IKEv2 IANA registry. This document does not update the algorithms used for packet encryption using IPsec Encapsulating Security Payload (ESP).</t>
</abstract>
</front>
</reference>
<xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8422.xml"/> <xi:include href="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8422.xml"/>
<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8610.xml"/>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-anima-bootstrapping-keyinfra.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-anima-grasp.xml"/>
<seriesInfo name="RFC" value="8446"/>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization/>
</author>
<date year="2018" month="August"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc8610">
<front>
<title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</title>
<seriesInfo name="DOI" value="10.17487/RFC8610"/>
<seriesInfo name="RFC" value="8610"/>
<author initials="H." surname="Birkholz" fullname="H. Birkholz">
<organization/>
</author>
<author initials="C." surname="Vigano" fullname="C. Vigano">
<organization/>
</author>
<author initials="C." surname="Bormann" fullname="C. Bormann">
<organization/>
</author>
<date year="2019" month="June"/>
<abstract>
<t>This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.</t>
</abstract>
</front>
</reference>
<reference anchor="I-D.ietf-anima-bootstrapping-keyinfra" target="http://www.ietf.org/internet-drafts/draft-ietf-anima-bootstrapping-keyinfra-43.txt">
<front>
<title>Bootstrapping Remote Secure Key Infrastructures (BRSKI)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-bootstrapping-keyinfra-43"/>
<author initials="M" surname="Pritikin" fullname="Max Pritikin">
<organization/>
</author>
<author initials="M" surname="Richardson" fullname="Michael Richardson">
<organization/>
</author>
<author initials="T" surname="Eckert" fullname="Toerless Eckert">
<organization/>
</author>
<author initials="M" surname="Behringer" fullname="Michael Behringer">
<organization/>
</author>
<author initials="K" surname="Watsen" fullname="Kent Watsen">
<organization/>
</author>
<date month="August" day="7" year="2020"/>
<abstract>
<t>This document specifies automated bootstrapping of an Autonomic Control Plane. To do this a Secure Key Infrastructure is bootstrapped. This is done using manufacturer-installed X.509 certificates, in combination with a manufacturer's authorizing service, both online and offline. We call this process the Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/ disconnected networks. Support for deployment models with less stringent security requirements is included. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device. The established secure connection can be used to deploy a locally issued certificate to the device as well.</t>
</abstract>
</front>
</reference>
<reference anchor="I-D.ietf-anima-grasp" target="http://www.ietf.org/internet-drafts/draft-ietf-anima-grasp-15.txt">
<front>
<title>A Generic Autonomic Signaling Protocol (GRASP)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-grasp-15"/>
<author initials="C" surname="Bormann" fullname="Carsten Bormann">
<organization/>
</author>
<author initials="B" surname="Carpenter" fullname="Brian Carpenter">
<organization/>
</author>
<author initials="B" surname="Liu" fullname="Bing Liu">
<organization/>
</author>
<date month="July" day="13" year="2017"/>
<abstract>
<t>This document specifies the GeneRic Autonomic Signaling Protocol (GRASP), which enables autonomic nodes and autonomic service agents to dynamically discover peers, to synchronize state with each other, and to negotiate parameter settings with each other. GRASP depends on an external security environment that is described elsewhere. The technical objectives and parameters for specific application scenarios are to be described in separate documents. Appendices briefly discuss requirements for the protocol and existing protocols with comparable features.</t>
</abstract>
</front>
</reference>
<reference anchor="IKEV2IANA" target="https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml"> <reference anchor="IKEV2IANA" target="https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml">
<front> <front>
<title>Internet Key Exchange Version 2 (IKEv2) Parameters</title> <title>Internet Key Exchange Version 2 (IKEv2) Parameters</title>
<author fullname="IANA"> <author fullname="IANA">
<organization/> <organization/>
</author> </author>
<date/> <date/>
</front> </front>
</reference> </reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<!-- references whose text got removed over the versions of the doc: <!-- references whose text got removed over the versions of the doc:
<?rfc include='reference.RFC.4122'?> - No idea <?rfc include='reference.RFC.4122'?> - No idea
<?rfc include='reference.RFC.5082'?> - GTSM was considered for GRASP, text removed <?rfc include='reference.RFC.5082'?> - GTSM was considered for GRASP, text removed
<?rfc include="reference.I-D.carpenter-anima-ani-objectives"?> <?rfc include="reference.I-D.carpenter-anima-ani-objectives"?>
<?rfc include="reference.I-D.richardson-anima-6join-discovery.xml"?> <?rfc include="reference.I-D.richardson-anima-6join-discovery.xml"?>
--> -->
<reference anchor="I-D.ietf-anima-prefix-management" target="http://www.ietf.org/internet-drafts/draft-ietf-anima-prefix-management-07.txt"> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-anima-prefix-management.xml"/>
<front> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-acme-star.xml"/>
<title>Autonomic IPv6 Edge Prefix Management in Large-scale Networks</title> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-tls-dtls13.xml"/>
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-prefix-management-07"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1112.xml"/>
<author initials="S" surname="Jiang" fullname="Sheng Jiang"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1492.xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1654.xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1918.xml"/>
<author initials="Z" surname="Du" fullname="Zongpeng Du">
<organization/>
</author>
<author initials="B" surname="Carpenter" fullname="Brian Carpenter">
<organization/>
</author>
<author initials="Q" surname="Sun" fullname="Qiong Sun">
<organization/>
</author>
<date month="December" day="18" year="2017"/>
<abstract>
<t>This document defines two autonomic technical objectives for IPv6 prefix management at the edge of large-scale ISP networks, with an extension to support IPv4 prefixes. An important purpose of the document is to use it for validation of the design of various components of the autonomic networking infrastructure.</t>
</abstract>
</front>
</reference>
<reference anchor="I-D.ietf-acme-star" target="http://www.ietf.org/internet-drafts/draft-ietf-acme-star-11.txt">
<front>
<title>Support for Short-Term, Automatically-Renewed (STAR) Certificates in Automated Certificate Management Environment (ACME)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-acme-star-11"/>
<author initials="Y" surname="Sheffer" fullname="Yaron Sheffer">
<organization/>
</author>
<author initials="D" surname="Lopez" fullname="Diego Lopez">
<organization/>
</author>
<author initials="O" surname="Dios" fullname="Oscar de Dios">
<organization/>
</author>
<author initials="A" surname="Pastor" fullname="Antonio Pastor">
<organization/>
</author>
<author initials="T" surname="Fossati" fullname="Thomas Fossati">
<organization/>
</author>
<date month="October" day="24" year="2019"/>
<abstract>
<t>Public-key certificates need to be revoked when they are compromised, that is, when the associated private key is exposed to an unauthorized entity. However the revocation process is often unreliable. An alternative to revocation is issuing a sequence of certificates, each with a short validity period, and terminating this sequence upon compromise. This memo proposes an ACME extension to enable the issuance of short-term and automatically renewed (STAR) X.509 certificates. [RFC-Editor: please remove before publication] While the draft is being developed, the editor's version can be found at https://github.com/yaronf/I-D/tree/master/STAR.</t>
</abstract>
</front>
</reference>
<reference anchor="I-D.ietf-tls-dtls13" target="http://www.ietf.org/internet-drafts/draft-ietf-tls-dtls13-38.txt">
<front>
<title>The Datagram Transport Layer Security (DTLS) Protocol Version 1.3</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-tls-dtls13-38"/>
<author initials="E" surname="Rescorla" fullname="Eric Rescorla">
<organization/>
</author>
<author initials="H" surname="Tschofenig" fullname="Hannes Tschofenig">
<organization/>
</author>
<author initials="N" surname="Modadugu" fullname="Nagendra Modadugu">
<organization/>
</author>
<date month="May" day="29" year="2020"/>
<abstract>
<t>This document specifies Version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees with the exception of order protection/non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC1112" target="https://www.rfc-editor.org/info/rfc1112">
<front>
<title>Host extensions for IP multicasting</title>
<seriesInfo name="DOI" value="10.17487/RFC1112"/>
<seriesInfo name="RFC" value="1112"/>
<seriesInfo name="STD" value="5"/>
<author initials="S.E." surname="Deering" fullname="S.E. Deering">
<organization/>
</author>
<date year="1989" month="August"/>
<abstract>
<t>This memo specifies the extensions required of a host implementation of the Internet Protocol (IP) to support multicasting. Recommended procedure for IP multicasting in the Internet. This RFC obsoletes RFCs 998 and 1054. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC1492" target="https://www.rfc-editor.org/info/rfc1492">
<front>
<title>An Access Control Protocol, Sometimes Called TACACS</title>
<seriesInfo name="DOI" value="10.17487/RFC1492"/>
<seriesInfo name="RFC" value="1492"/>
<author initials="C." surname="Finseth" fullname="C. Finseth">
<organization/>
</author>
<date year="1993" month="July"/>
<abstract>
<t>This RFC documents the extended TACACS protocol use by the Cisco Systems terminal servers. This same protocol is used by the University of Minnesota's distributed authentication system. This memo provides information for the Internet community. It does not specify an Internet standard.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC1654" target="https://www.rfc-editor.org/info/rfc1654">
<front>
<title>A Border Gateway Protocol 4 (BGP-4)</title>
<seriesInfo name="DOI" value="10.17487/RFC1654"/>
<seriesInfo name="RFC" value="1654"/>
<author initials="Y." surname="Rekhter" fullname="Y. Rekhter" role="editor">
<organization/>
</author>
<author initials="T." surname="Li" fullname="T. Li" role="editor">
<organization/>
</author>
<date year="1994" month="July"/>
<abstract>
<t>This document defines an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC1918" target="https://www.rfc-editor.org/info/rfc1918">
<front>
<title>Address Allocation for Private Internets</title>
<seriesInfo name="DOI" value="10.17487/RFC1918"/>
<seriesInfo name="RFC" value="1918"/>
<seriesInfo name="BCP" value="5"/>
<author initials="Y." surname="Rekhter" fullname="Y. Rekhter">
<organization/>
</author>
<author initials="B." surname="Moskowitz" fullname="B. Moskowitz">
<organization/>
</author>
<author initials="D." surname="Karrenberg" fullname="D. Karrenberg">
<organization/>
</author>
<author initials="G. J." surname="de Groot" fullname="G. J. de Groot">
<organization/>
</author>
<author initials="E." surname="Lear" fullname="E. Lear">
<organization/>
</author>
<date year="1996" month="February"/>
<abstract>
<t>This document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC2315" target="https://www.rfc-editor.org/info/rfc2315"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2315.xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2409.xml"/>
<title>PKCS #7: Cryptographic Message Syntax Version 1.5</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2865.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC2315"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3164.xml"/>
<seriesInfo name="RFC" value="2315"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3315.xml"/>
<author initials="B." surname="Kaliski" fullname="B. Kaliski"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3411.xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3596.xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3920.xml"/>
<date year="1998" month="March"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3954.xml"/>
<abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4007.xml"/>
<t>This document describes a general syntax for data that may have cryptography applied to it, such as digital signatures and digital envelopes. This memo provides information for the Internet community. It does not specify an Internet standard of any kind.</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4210.xml"/>
</abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml"/>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4429.xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4541.xml"/>
<reference anchor="RFC2409" target="https://www.rfc-editor.org/info/rfc2409"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4604.xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4607.xml"/>
<title>The Internet Key Exchange (IKE)</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4610.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC2409"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4941.xml"/>
<seriesInfo name="RFC" value="2409"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4985.xml"/>
<author initials="D." surname="Harkins" fullname="D. Harkins"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5790.xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml"/>
<author initials="D." surname="Carrel" fullname="D. Carrel"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5912.xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6335.xml"/>
<date year="1998" month="November"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6402.xml"/>
<abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6407.xml"/>
<t>This memo describes a hybrid protocol. The purpose is to negotiate, and provide authenticated keying material for, security associations in a protected manner. [STANDARDS-TRACK]</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6554.xml"/>
</abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6724.xml"/>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6733.xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6762.xml"/>
<reference anchor="RFC2865" target="https://www.rfc-editor.org/info/rfc2865"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6763.xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6824.xml"/>
<title>Remote Authentication Dial In User Service (RADIUS)</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6830.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC2865"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7011.xml"/>
<seriesInfo name="RFC" value="2865"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7404.xml"/>
<author initials="C." surname="Rigney" fullname="C. Rigney"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7426.xml"/>
<organization/>
</author>
<author initials="S." surname="Willens" fullname="S. Willens">
<organization/>
</author>
<author initials="A." surname="Rubens" fullname="A. Rubens">
<organization/>
</author>
<author initials="W." surname="Simpson" fullname="W. Simpson">
<organization/>
</author>
<date year="2000" month="June"/>
<abstract>
<t>This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC3164" target="https://www.rfc-editor.org/info/rfc3164">
<front>
<title>The BSD Syslog Protocol</title>
<seriesInfo name="DOI" value="10.17487/RFC3164"/>
<seriesInfo name="RFC" value="3164"/>
<author initials="C." surname="Lonvick" fullname="C. Lonvick">
<organization/>
</author>
<date year="2001" month="August"/>
<abstract>
<t>This document describes the observed behavior of the syslog protocol. This memo provides information for the Internet community.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC3315" target="https://www.rfc-editor.org/info/rfc3315">
<front>
<title>Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title>
<seriesInfo name="DOI" value="10.17487/RFC3315"/>
<seriesInfo name="RFC" value="3315"/>
<author initials="R." surname="Droms" fullname="R. Droms" role="editor">
<organization/>
</author>
<author initials="J." surname="Bound" fullname="J. Bound">
<organization/>
</author>
<author initials="B." surname="Volz" fullname="B. Volz">
<organization/>
</author>
<author initials="T." surname="Lemon" fullname="T. Lemon">
<organization/>
</author>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization/>
</author>
<author initials="M." surname="Carney" fullname="M. Carney">
<organization/>
</author>
<date year="2003" month="July"/>
</front>
</reference>
<reference anchor="RFC3411" target="https://www.rfc-editor.org/info/rfc3411">
<front>
<title>An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks</title>
<seriesInfo name="DOI" value="10.17487/RFC3411"/>
<seriesInfo name="RFC" value="3411"/>
<seriesInfo name="STD" value="62"/>
<author initials="D." surname="Harrington" fullname="D. Harrington">
<organization/>
</author>
<author initials="R." surname="Presuhn" fullname="R. Presuhn">
<organization/>
</author>
<author initials="B." surname="Wijnen" fullname="B. Wijnen">
<organization/>
</author>
<date year="2002" month="December"/>
<abstract>
<t>This document describes an architecture for describing Simple Network Management Protocol (SNMP) Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data. This document obsoletes RFC 2571. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC3596" target="https://www.rfc-editor.org/info/rfc3596">
<front>
<title>DNS Extensions to Support IP Version 6</title>
<seriesInfo name="DOI" value="10.17487/RFC3596"/>
<seriesInfo name="RFC" value="3596"/>
<seriesInfo name="STD" value="88"/>
<author initials="S." surname="Thomson" fullname="S. Thomson">
<organization/>
</author>
<author initials="C." surname="Huitema" fullname="C. Huitema">
<organization/>
</author>
<author initials="V." surname="Ksinant" fullname="V. Ksinant">
<organization/>
</author>
<author initials="M." surname="Souissi" fullname="M. Souissi">
<organization/>
</author>
<date year="2003" month="October"/>
<abstract>
<t>This document defines the changes that need to be made to the Domain Name System (DNS) to support hosts running IP version 6 (IPv6). The changes include a resource record type to store an IPv6 address, a domain to support lookups based on an IPv6 address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC3920" target="https://www.rfc-editor.org/info/rfc3920">
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
<seriesInfo name="DOI" value="10.17487/RFC3920"/>
<seriesInfo name="RFC" value="3920"/>
<author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre" role="editor">
<organization/>
</author>
<date year="2004" month="October"/>
<abstract>
<t>This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC3954" target="https://www.rfc-editor.org/info/rfc3954">
<front>
<title>Cisco Systems NetFlow Services Export Version 9</title>
<seriesInfo name="DOI" value="10.17487/RFC3954"/>
<seriesInfo name="RFC" value="3954"/>
<author initials="B." surname="Claise" fullname="B. Claise" role="editor">
<organization/>
</author>
<date year="2004" month="October"/>
<abstract>
<t>This document specifies the data export format for version 9 of Cisco Systems' NetFlow services, for use by implementations on the network elements and/or matching collector programs. The version 9 export format uses templates to provide access to observations of IP packet flows in a flexible and extensible manner. A template defines a collection of fields, with corresponding descriptions of structure and semantics. This memo provides information for the Internet community.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4007" target="https://www.rfc-editor.org/info/rfc4007">
<front>
<title>IPv6 Scoped Address Architecture</title>
<seriesInfo name="DOI" value="10.17487/RFC4007"/>
<seriesInfo name="RFC" value="4007"/>
<author initials="S." surname="Deering" fullname="S. Deering">
<organization/>
</author>
<author initials="B." surname="Haberman" fullname="B. Haberman">
<organization/>
</author>
<author initials="T." surname="Jinmei" fullname="T. Jinmei">
<organization/>
</author>
<author initials="E." surname="Nordmark" fullname="E. Nordmark">
<organization/>
</author>
<author initials="B." surname="Zill" fullname="B. Zill">
<organization/>
</author>
<date year="2005" month="March"/>
<abstract>
<t>This document specifies the architectural characteristics, expected behavior, textual representation, and usage of IPv6 addresses of different scopes. According to a decision in the IPv6 working group, this document intentionally avoids the syntax and usage of unicast site-local addresses. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4210" target="https://www.rfc-editor.org/info/rfc4210">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)</title>
<seriesInfo name="DOI" value="10.17487/RFC4210"/>
<seriesInfo name="RFC" value="4210"/>
<author initials="C." surname="Adams" fullname="C. Adams">
<organization/>
</author>
<author initials="S." surname="Farrell" fullname="S. Farrell">
<organization/>
</author>
<author initials="T." surname="Kause" fullname="T. Kause">
<organization/>
</author>
<author initials="T." surname="Mononen" fullname="T. Mononen">
<organization/>
</author>
<date year="2005" month="September"/>
<abstract>
<t>This document describes the Internet X.509 Public Key Infrastructure (PKI) Certificate Management Protocol (CMP). Protocol messages are defined for X.509v3 certificate creation and management. CMP provides on-line interactions between PKI components, including an exchange between a Certification Authority (CA) and a client system. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4364" target="https://www.rfc-editor.org/info/rfc4364">
<front>
<title>BGP/MPLS IP Virtual Private Networks (VPNs)</title>
<seriesInfo name="DOI" value="10.17487/RFC4364"/>
<seriesInfo name="RFC" value="4364"/>
<author initials="E." surname="Rosen" fullname="E. Rosen">
<organization/>
</author>
<author initials="Y." surname="Rekhter" fullname="Y. Rekhter">
<organization/>
</author>
<date year="2006" month="February"/>
<abstract>
<t>This document describes a method by which a Service Provider may use an IP backbone to provide IP Virtual Private Networks (VPNs) for its customers. This method uses a "peer model", in which the customers' edge routers (CE routers) send their routes to the Service Provider's edge routers (PE routers); there is no "overlay" visible to the customer's routing algorithm, and CE routers at different sites do not peer with each other. Data packets are tunneled through the backbone, so that the core routers do not need to know the VPN routes. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4429" target="https://www.rfc-editor.org/info/rfc4429">
<front>
<title>Optimistic Duplicate Address Detection (DAD) for IPv6</title>
<seriesInfo name="DOI" value="10.17487/RFC4429"/>
<seriesInfo name="RFC" value="4429"/>
<author initials="N." surname="Moore" fullname="N. Moore">
<organization/>
</author>
<date year="2006" month="April"/>
<abstract>
<t>Optimistic Duplicate Address Detection is an interoperable modification of the existing IPv6 Neighbor Discovery (RFC 2461) and Stateless Address Autoconfiguration (RFC 2462) processes. The intention is to minimize address configuration delays in the successful case, to reduce disruption as far as possible in the failure case, and to remain interoperable with unmodified hosts and routers. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4541" target="https://www.rfc-editor.org/info/rfc4541">
<front>
<title>Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches</title>
<seriesInfo name="DOI" value="10.17487/RFC4541"/>
<seriesInfo name="RFC" value="4541"/>
<author initials="M." surname="Christensen" fullname="M. Christensen">
<organization/>
</author>
<author initials="K." surname="Kimball" fullname="K. Kimball">
<organization/>
</author>
<author initials="F." surname="Solensky" fullname="F. Solensky">
<organization/>
</author>
<date year="2006" month="May"/>
<abstract>
<t>This memo describes the recommendations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) snooping switches. These are based on best current practices for IGMPv2, with further considerations for IGMPv3- and MLDv2-snooping. Additional areas of relevance, such as link layer topology changes and Ethernet-specific encapsulation issues, are also considered. This memo provides information for the Internet community.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4604" target="https://www.rfc-editor.org/info/rfc4604">
<front>
<title>Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast</title>
<seriesInfo name="DOI" value="10.17487/RFC4604"/>
<seriesInfo name="RFC" value="4604"/>
<author initials="H." surname="Holbrook" fullname="H. Holbrook">
<organization/>
</author>
<author initials="B." surname="Cain" fullname="B. Cain">
<organization/>
</author>
<author initials="B." surname="Haberman" fullname="B. Haberman">
<organization/>
</author>
<date year="2006" month="August"/>
<abstract>
<t>The Internet Group Management Protocol Version 3 (IGMPv3) and the Multicast Listener Discovery Protocol Version 2 (MLDv2) are protocols that allow a host to inform its neighboring routers of its desire to receive IPv4 and IPv6 multicast transmissions, respectively. Source-specific multicast (SSM) is a form of multicast in which a receiver is required to specify both the network-layer address of the source and the multicast destination address in order to receive the multicast transmission. This document defines the notion of an "SSM-aware" router and host, and clarifies and (in some cases) modifies the behavior of IGMPv3 and MLDv2 on SSM-aware routers and hosts to accommodate source-specific multicast. This document updates the IGMPv3 and MLDv2 specifications. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4607" target="https://www.rfc-editor.org/info/rfc4607">
<front>
<title>Source-Specific Multicast for IP</title>
<seriesInfo name="DOI" value="10.17487/RFC4607"/>
<seriesInfo name="RFC" value="4607"/>
<author initials="H." surname="Holbrook" fullname="H. Holbrook">
<organization/>
</author>
<author initials="B." surname="Cain" fullname="B. Cain">
<organization/>
</author>
<date year="2006" month="August"/>
<abstract>
<t>IP version 4 (IPv4) addresses in the 232/8 (232.0.0.0 to 232.255.255.255) range are designated as source-specific multicast (SSM) destination addresses and are reserved for use by source-specific applications and protocols. For IP version 6 (IPv6), the address prefix FF3x::/32 is reserved for source-specific multicast use. This document defines an extension to the Internet network service that applies to datagrams sent to SSM addresses and defines the host and router requirements to support this extension. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4610" target="https://www.rfc-editor.org/info/rfc4610">
<front>
<title>Anycast-RP Using Protocol Independent Multicast (PIM)</title>
<seriesInfo name="DOI" value="10.17487/RFC4610"/>
<seriesInfo name="RFC" value="4610"/>
<author initials="D." surname="Farinacci" fullname="D. Farinacci">
<organization/>
</author>
<author initials="Y." surname="Cai" fullname="Y. Cai">
<organization/>
</author>
<date year="2006" month="August"/>
<abstract>
<t>This specification allows Anycast-RP (Rendezvous Point) to be used inside a domain that runs Protocol Independent Multicast (PIM) only. Other multicast protocols (such as Multicast Source Discovery Protocol (MSDP), which has been used traditionally to solve this problem) are not required to support Anycast-RP. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4941" target="https://www.rfc-editor.org/info/rfc4941">
<front>
<title>Privacy Extensions for Stateless Address Autoconfiguration in IPv6</title>
<seriesInfo name="DOI" value="10.17487/RFC4941"/>
<seriesInfo name="RFC" value="4941"/>
<author initials="T." surname="Narten" fullname="T. Narten">
<organization/>
</author>
<author initials="R." surname="Draves" fullname="R. Draves">
<organization/>
</author>
<author initials="S." surname="Krishnan" fullname="S. Krishnan">
<organization/>
</author>
<date year="2007" month="September"/>
<abstract>
<t>Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. Addresses are formed by combining network prefixes with an interface identifier. On an interface that contains an embedded IEEE Identifier, the interface identifier is typically derived from it. On other interface types, the interface identifier is generated through other means, for example, via random number generation. This document describes an extension to IPv6 stateless address autoconfiguration for interfaces whose interface identifier is derived from an IEEE identifier. Use of the extension causes nodes to generate global scope addresses from interface identifiers that change over time, even in cases where the interface contains an embedded IEEE identifier. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC4985" target="https://www.rfc-editor.org/info/rfc4985">
<front>
<title>Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name</title>
<seriesInfo name="DOI" value="10.17487/RFC4985"/>
<seriesInfo name="RFC" value="4985"/>
<author initials="S." surname="Santesson" fullname="S. Santesson">
<organization/>
</author>
<date year="2007" month="August"/>
<abstract>
<t>This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name extension that allows a certificate subject to be associated with the service name and domain name components of a DNS Service Resource Record. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5790" target="https://www.rfc-editor.org/info/rfc5790">
<front>
<title>Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Version 2 (MLDv2) Protocols</title>
<seriesInfo name="DOI" value="10.17487/RFC5790"/>
<seriesInfo name="RFC" value="5790"/>
<author initials="H." surname="Liu" fullname="H. Liu">
<organization/>
</author>
<author initials="W." surname="Cao" fullname="W. Cao">
<organization/>
</author>
<author initials="H." surname="Asaeda" fullname="H. Asaeda">
<organization/>
</author>
<date year="2010" month="February"/>
<abstract>
<t>This document describes lightweight IGMPv3 and MLDv2 protocols (LW- IGMPv3 and LW-MLDv2), which simplify the standard (full) versions of IGMPv3 and MLDv2. The interoperability with the full versions and the previous versions of IGMP and MLD is also taken into account. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5880" target="https://www.rfc-editor.org/info/rfc5880">
<front>
<title>Bidirectional Forwarding Detection (BFD)</title>
<seriesInfo name="DOI" value="10.17487/RFC5880"/>
<seriesInfo name="RFC" value="5880"/>
<author initials="D." surname="Katz" fullname="D. Katz">
<organization/>
</author>
<author initials="D." surname="Ward" fullname="D. Ward">
<organization/>
</author>
<date year="2010" month="June"/>
<abstract>
<t>This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5905" target="https://www.rfc-editor.org/info/rfc5905">
<front>
<title>Network Time Protocol Version 4: Protocol and Algorithms Specification</title>
<seriesInfo name="DOI" value="10.17487/RFC5905"/>
<seriesInfo name="RFC" value="5905"/>
<author initials="D." surname="Mills" fullname="D. Mills">
<organization/>
</author>
<author initials="J." surname="Martin" fullname="J. Martin" role="editor">
<organization/>
</author>
<author initials="J." surname="Burbank" fullname="J. Burbank">
<organization/>
</author>
<author initials="W." surname="Kasch" fullname="W. Kasch">
<organization/>
</author>
<date year="2010" month="June"/>
<abstract>
<t>The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5912" target="https://www.rfc-editor.org/info/rfc5912">
<front>
<title>New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)</title>
<seriesInfo name="DOI" value="10.17487/RFC5912"/>
<seriesInfo name="RFC" value="5912"/>
<author initials="P." surname="Hoffman" fullname="P. Hoffman">
<organization/>
</author>
<author initials="J." surname="Schaad" fullname="J. Schaad">
<organization/>
</author>
<date year="2010" month="June"/>
<abstract>
<t>The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6241">
<front>
<title>Network Configuration Protocol (NETCONF)</title>
<seriesInfo name="DOI" value="10.17487/RFC6241"/>
<seriesInfo name="RFC" value="6241"/>
<author initials="R." surname="Enns" fullname="R. Enns" role="editor">
<organization/>
</author>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor">
<organization/>
</author>
<author initials="J." surname="Schoenwaelder" fullname="J. Schoenwaelder" role="editor">
<organization/>
</author>
<author initials="A." surname="Bierman" fullname="A. Bierman" role="editor">
<organization/>
</author>
<date year="2011" month="June"/>
<abstract>
<t>The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6335" target="https://www.rfc-editor.org/info/rfc6335">
<front>
<title>Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry</title>
<seriesInfo name="DOI" value="10.17487/RFC6335"/>
<seriesInfo name="RFC" value="6335"/>
<seriesInfo name="BCP" value="165"/>
<author initials="M." surname="Cotton" fullname="M. Cotton">
<organization/>
</author>
<author initials="L." surname="Eggert" fullname="L. Eggert">
<organization/>
</author>
<author initials="J." surname="Touch" fullname="J. Touch">
<organization/>
</author>
<author initials="M." surname="Westerlund" fullname="M. Westerlund">
<organization/>
</author>
<author initials="S." surname="Cheshire" fullname="S. Cheshire">
<organization/>
</author>
<date year="2011" month="August"/>
<abstract>
<t>This document defines the procedures that the Internet Assigned Numbers Authority (IANA) uses when handling assignment and other requests related to the Service Name and Transport Protocol Port Number registry. It also discusses the rationale and principles behind these procedures and how they facilitate the long-term sustainability of the registry.</t>
<t>This document updates IANA's procedures by obsoleting the previous UDP and TCP port assignment procedures defined in Sections 8 and 9.1 of the IANA Allocation Guidelines, and it updates the IANA service name and port assignment procedures for UDP-Lite, the Datagram Congestion Control Protocol (DCCP), and the Stream Control Transmission Protocol (SCTP). It also updates the DNS SRV specification to clarify what a service name is and how it is registered. This memo documents an Internet Best Current Practice.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6402" target="https://www.rfc-editor.org/info/rfc6402">
<front>
<title>Certificate Management over CMS (CMC) Updates</title>
<seriesInfo name="DOI" value="10.17487/RFC6402"/>
<seriesInfo name="RFC" value="6402"/>
<author initials="J." surname="Schaad" fullname="J. Schaad">
<organization/>
</author>
<date year="2011" month="November"/>
<abstract>
<t>This document contains a set of updates to the base syntax for CMC, a Certificate Management protocol using the Cryptographic Message Syntax (CMS). This document updates RFC 5272, RFC 5273, and RFC 5274.</t>
<t>The new items in this document are: new controls for future work in doing server side key generation, definition of a Subject Information Access value to identify CMC servers, and the registration of a port number for TCP/IP for the CMC service to run on. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6407" target="https://www.rfc-editor.org/info/rfc6407">
<front>
<title>The Group Domain of Interpretation</title>
<seriesInfo name="DOI" value="10.17487/RFC6407"/>
<seriesInfo name="RFC" value="6407"/>
<author initials="B." surname="Weis" fullname="B. Weis">
<organization/>
</author>
<author initials="S." surname="Rowles" fullname="S. Rowles">
<organization/>
</author>
<author initials="T." surname="Hardjono" fullname="T. Hardjono">
<organization/>
</author>
<date year="2011" month="October"/>
<abstract>
<t>This document describes the Group Domain of Interpretation (GDOI) protocol specified in RFC 3547. The GDOI provides group key management to support secure group communications according to the architecture specified in RFC 4046. The GDOI manages group security associations, which are used by IPsec and potentially other data security protocols. This document replaces RFC 3547. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6554" target="https://www.rfc-editor.org/info/rfc6554">
<front>
<title>An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)</title>
<seriesInfo name="DOI" value="10.17487/RFC6554"/>
<seriesInfo name="RFC" value="6554"/>
<author initials="J." surname="Hui" fullname="J. Hui">
<organization/>
</author>
<author initials="JP." surname="Vasseur" fullname="JP. Vasseur">
<organization/>
</author>
<author initials="D." surname="Culler" fullname="D. Culler">
<organization/>
</author>
<author initials="V." surname="Manral" fullname="V. Manral">
<organization/>
</author>
<date year="2012" month="March"/>
<abstract>
<t>In Low-Power and Lossy Networks (LLNs), memory constraints on routers may limit them to maintaining, at most, a few routes. In some configurations, it is necessary to use these memory-constrained routers to deliver datagrams to nodes within the LLN. The Routing Protocol for Low-Power and Lossy Networks (RPL) can be used in some deployments to store most, if not all, routes on one (e.g., the Directed Acyclic Graph (DAG) root) or a few routers and forward the IPv6 datagram using a source routing technique to avoid large routing tables on memory-constrained routers. This document specifies a new IPv6 Routing header type for delivering datagrams within a RPL routing domain. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6724" target="https://www.rfc-editor.org/info/rfc6724">
<front>
<title>Default Address Selection for Internet Protocol Version 6 (IPv6)</title>
<seriesInfo name="DOI" value="10.17487/RFC6724"/>
<seriesInfo name="RFC" value="6724"/>
<author initials="D." surname="Thaler" fullname="D. Thaler" role="editor">
<organization/>
</author>
<author initials="R." surname="Draves" fullname="R. Draves">
<organization/>
</author>
<author initials="A." surname="Matsumoto" fullname="A. Matsumoto">
<organization/>
</author>
<author initials="T." surname="Chown" fullname="T. Chown">
<organization/>
</author>
<date year="2012" month="September"/>
<abstract>
<t>This document describes two algorithms, one for source address selection and one for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual-stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses -- depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice versa.</t>
<t>Default address selection as defined in this specification applies to all IPv6 nodes, including both hosts and routers. This document obsoletes RFC 3484. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6733" target="https://www.rfc-editor.org/info/rfc6733">
<front>
<title>Diameter Base Protocol</title>
<seriesInfo name="DOI" value="10.17487/RFC6733"/>
<seriesInfo name="RFC" value="6733"/>
<author initials="V." surname="Fajardo" fullname="V. Fajardo" role="editor">
<organization/>
</author>
<author initials="J." surname="Arkko" fullname="J. Arkko">
<organization/>
</author>
<author initials="J." surname="Loughney" fullname="J. Loughney">
<organization/>
</author>
<author initials="G." surname="Zorn" fullname="G. Zorn" role="editor">
<organization/>
</author>
<date year="2012" month="October"/>
<abstract>
<t>The Diameter base protocol is intended to provide an Authentication, Authorization, and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting, and security services used by all Diameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and RFC 5719, and it must be supported by all new Diameter implementations. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6762" target="https://www.rfc-editor.org/info/rfc6762">
<front>
<title>Multicast DNS</title>
<seriesInfo name="DOI" value="10.17487/RFC6762"/>
<seriesInfo name="RFC" value="6762"/>
<author initials="S." surname="Cheshire" fullname="S. Cheshire">
<organization/>
</author>
<author initials="M." surname="Krochmal" fullname="M. Krochmal">
<organization/>
</author>
<date year="2013" month="February"/>
<abstract>
<t>As networked devices become smaller, more portable, and more ubiquitous, the ability to operate with less configured infrastructure is increasingly important. In particular, the ability to look up DNS resource record data types (including, but not limited to, host names) in the absence of a conventional managed DNS server is useful.</t>
<t>Multicast DNS (mDNS) provides the ability to perform DNS-like operations on the local link in the absence of any conventional Unicast DNS server. In addition, Multicast DNS designates a portion of the DNS namespace to be free for local use, without the need to pay any annual fee, and without the need to set up delegations or otherwise configure a conventional DNS server to answer for those names.</t>
<t>The primary benefits of Multicast DNS names are that (i) they require little or no administration or configuration to set them up, (ii) they work when no infrastructure is present, and (iii) they work during infrastructure failures.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6763" target="https://www.rfc-editor.org/info/rfc6763">
<front>
<title>DNS-Based Service Discovery</title>
<seriesInfo name="DOI" value="10.17487/RFC6763"/>
<seriesInfo name="RFC" value="6763"/>
<author initials="S." surname="Cheshire" fullname="S. Cheshire">
<organization/>
</author>
<author initials="M." surname="Krochmal" fullname="M. Krochmal">
<organization/>
</author>
<date year="2013" month="February"/>
<abstract>
<t>This document specifies how DNS resource records are named and structured to facilitate service discovery. Given a type of service that a client is looking for, and a domain in which the client is looking for that service, this mechanism allows clients to discover a list of named instances of that desired service, using standard DNS queries. This mechanism is referred to as DNS-based Service Discovery, or DNS-SD.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6824" target="https://www.rfc-editor.org/info/rfc6824">
<front>
<title>TCP Extensions for Multipath Operation with Multiple Addresses</title>
<seriesInfo name="DOI" value="10.17487/RFC6824"/>
<seriesInfo name="RFC" value="6824"/>
<author initials="A." surname="Ford" fullname="A. Ford">
<organization/>
</author>
<author initials="C." surname="Raiciu" fullname="C. Raiciu">
<organization/>
</author>
<author initials="M." surname="Handley" fullname="M. Handley">
<organization/>
</author>
<author initials="O." surname="Bonaventure" fullname="O. Bonaventure">
<organization/>
</author>
<date year="2013" month="January"/>
<abstract>
<t>TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure.</t>
<t>Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e., reliable bytestream), and it provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. This document defines an Experimental Protocol for the Internet community.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6830" target="https://www.rfc-editor.org/info/rfc6830">
<front>
<title>The Locator/ID Separation Protocol (LISP)</title>
<seriesInfo name="DOI" value="10.17487/RFC6830"/>
<seriesInfo name="RFC" value="6830"/>
<author initials="D." surname="Farinacci" fullname="D. Farinacci">
<organization/>
</author>
<author initials="V." surname="Fuller" fullname="V. Fuller">
<organization/>
</author>
<author initials="D." surname="Meyer" fullname="D. Meyer">
<organization/>
</author>
<author initials="D." surname="Lewis" fullname="D. Lewis">
<organization/>
</author>
<date year="2013" month="January"/>
<abstract>
<t>This document describes a network-layer-based protocol that enables separation of IP addresses into two new numbering spaces: Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). No changes are required to either host protocol stacks or to the "core" of the Internet infrastructure. The Locator/ID Separation Protocol (LISP) can be incrementally deployed, without a "flag day", and offers Traffic Engineering, multihoming, and mobility benefits to early adopters, even when there are relatively few LISP-capable sites.</t>
<t>Design and development of LISP was largely motivated by the problem statement produced by the October 2006 IAB Routing and Addressing Workshop. This document defines an Experimental Protocol for the Internet community.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7011" target="https://www.rfc-editor.org/info/rfc7011">
<front>
<title>Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information</title>
<seriesInfo name="DOI" value="10.17487/RFC7011"/>
<seriesInfo name="RFC" value="7011"/>
<seriesInfo name="STD" value="77"/>
<author initials="B." surname="Claise" fullname="B. Claise" role="editor">
<organization/>
</author>
<author initials="B." surname="Trammell" fullname="B. Trammell" role="editor">
<organization/>
</author>
<author initials="P." surname="Aitken" fullname="P. Aitken">
<organization/>
</author>
<date year="2013" month="September"/>
<abstract>
<t>This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network. In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are required. This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document obsoletes RFC 5101.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7404" target="https://www.rfc-editor.org/info/rfc7404">
<front>
<title>Using Only Link-Local Addressing inside an IPv6 Network</title>
<seriesInfo name="DOI" value="10.17487/RFC7404"/>
<seriesInfo name="RFC" value="7404"/>
<author initials="M." surname="Behringer" fullname="M. Behringer">
<organization/>
</author>
<author initials="E." surname="Vyncke" fullname="E. Vyncke">
<organization/>
</author>
<date year="2014" month="November"/>
<abstract>
<t>In an IPv6 network, it is possible to use only link-local addresses on infrastructure links between routers. This document discusses the advantages and disadvantages of this approach to facilitate the decision process for a given network.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7426" target="https://www.rfc-editor.org/info/rfc7426">
<front>
<title>Software-Defined Networking (SDN): Layers and Architecture Terminology</title>
<seriesInfo name="DOI" value="10.17487/RFC7426"/>
<seriesInfo name="RFC" value="7426"/>
<author initials="E." surname="Haleplidis" fullname="E. Haleplidis" role="editor">
<organization/>
</author>
<author initials="K." surname="Pentikousis" fullname="K. Pentikousis" role="editor">
<organization/>
</author>
<author initials="S." surname="Denazis" fullname="S. Denazis">
<organization/>
</author>
<author initials="J." surname="Hadi Salim" fullname="J. Hadi Salim">
<organization/>
</author>
<author initials="D." surname="Meyer" fullname="D. Meyer">
<organization/>
</author>
<author initials="O." surname="Koufopavlou" fullname="O. Koufopavlou">
<organization/>
</author>
<date year="2015" month="January"/>
<abstract>
<t>Software-Defined Networking (SDN) refers to a new approach for network programmability, that is, the capacity to initialize, control, change, and manage network behavior dynamically via open interfaces. SDN emphasizes the role of software in running networks through the introduction of an abstraction for the data forwarding plane and, by doing so, separates it from the control plane. This separation allows faster innovation cycles at both planes as experience has already shown. However, there is increasing confusion as to what exactly SDN is, what the layer structure is in an SDN architecture, and how layers interface with each other. This document, a product of the IRTF Software-Defined Networking Research Group (SDNRG), addresses these questions and provides a concise reference for the SDN research community based on relevant peer-reviewed literature, the RFC series, and relevant documents by other standards organizations.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7435" target="https://www.rfc-editor.org/info/rfc7435" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7435.xml"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7435.xml"/>
<front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7575.xml"/>
<title>Opportunistic Security: Some Protection Most of the Time</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7576.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC7435"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7585.xml"/>
<seriesInfo name="RFC" value="7435"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7721.xml"/>
<author initials="V." surname="Dukhovni" fullname="V. Dukhovni"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7761.xml"/>
<organization/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/>
</author> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8028.xml"/>
<date year="2014" month="December"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
<abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8366.xml"/>
<t>This document defines the concept "Opportunistic Security" in the context of communications protocols. Protocol designs based on Opportunistic Security use encryption even when authentication is not available, and use authentication when possible, thereby removing barriers to the widespread use of encryption on the Internet.</t> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8316.xml"/>
</abstract> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8368.xml"/>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8398.xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>
<reference anchor="RFC7575" target="https://www.rfc-editor.org/info/rfc7575"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8572.xml"/>
<front> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-anima-reference-model.xml"/>
<title>Autonomic Networking: Definitions and Design Goals</title> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-eckert-anima-noc-autoconfig.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC7575"/>
<seriesInfo name="RFC" value="7575"/>
<author initials="M." surname="Behringer" fullname="M. Behringer">
<organization/>
</author>
<author initials="M." surname="Pritikin" fullname="M. Pritikin">
<organization/>
</author>
<author initials="S." surname="Bjarnason" fullname="S. Bjarnason">
<organization/>
</author>
<author initials="A." surname="Clemm" fullname="A. Clemm">
<organization/>
</author>
<author initials="B." surname="Carpenter" fullname="B. Carpenter">
<organization/>
</author>
<author initials="S." surname="Jiang" fullname="S. Jiang">
<organization/>
</author>
<author initials="L." surname="Ciavaglia" fullname="L. Ciavaglia">
<organization/>
</author>
<date year="2015" month="June"/>
<abstract>
<t>Autonomic systems were first described in 2001. The fundamental goal is self-management, including self-configuration, self-optimization, self-healing, and self-protection. This is achieved by an autonomic function having minimal dependencies on human administrators or centralized management systems. It usually implies distribution across network elements.</t>
<t>This document defines common language and outlines design goals (and what are not design goals) for autonomic functions. A high-level reference model illustrates how functional elements in an Autonomic Network interact. This document is a product of the IRTF's Network Management Research Group.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7576" target="https://www.rfc-editor.org/info/rfc7576">
<front>
<title>General Gap Analysis for Autonomic Networking</title>
<seriesInfo name="DOI" value="10.17487/RFC7576"/>
<seriesInfo name="RFC" value="7576"/>
<author initials="S." surname="Jiang" fullname="S. Jiang">
<organization/>
</author>
<author initials="B." surname="Carpenter" fullname="B. Carpenter">
<organization/>
</author>
<author initials="M." surname="Behringer" fullname="M. Behringer">
<organization/>
</author>
<date year="2015" month="June"/>
<abstract>
<t>This document provides a problem statement and general gap analysis for an IP-based Autonomic Network that is mainly based on distributed network devices. The document provides background by reviewing the current status of autonomic aspects of IP networks and the extent to which current network management depends on centralization and human administrators. Finally, the document outlines the general features that are missing from current network abilities and are needed in the ideal Autonomic Network concept.</t>
<t>This document is a product of the IRTF's Network Management Research Group.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7585" target="https://www.rfc-editor.org/info/rfc7585">
<front>
<title>Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Based on the Network Access Identifier (NAI)</title>
<seriesInfo name="DOI" value="10.17487/RFC7585"/>
<seriesInfo name="RFC" value="7585"/>
<author initials="S." surname="Winter" fullname="S. Winter">
<organization/>
</author>
<author initials="M." surname="McCauley" fullname="M. McCauley">
<organization/>
</author>
<date year="2015" month="October"/>
<abstract>
<t>This document specifies a means to find authoritative RADIUS servers for a given realm. It is used in conjunction with either RADIUS over Transport Layer Security (RADIUS/TLS) or RADIUS over Datagram Transport Layer Security (RADIUS/DTLS).</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7721" target="https://www.rfc-editor.org/info/rfc7721">
<front>
<title>Security and Privacy Considerations for IPv6 Address Generation Mechanisms</title>
<seriesInfo name="DOI" value="10.17487/RFC7721"/>
<seriesInfo name="RFC" value="7721"/>
<author initials="A." surname="Cooper" fullname="A. Cooper">
<organization/>
</author>
<author initials="F." surname="Gont" fullname="F. Gont">
<organization/>
</author>
<author initials="D." surname="Thaler" fullname="D. Thaler">
<organization/>
</author>
<date year="2016" month="March"/>
<abstract>
<t>This document discusses privacy and security considerations for several IPv6 address generation mechanisms, both standardized and non-standardized. It evaluates how different mechanisms mitigate different threats and the trade-offs that implementors, developers, and users face in choosing different addresses or address generation mechanisms.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7761" target="https://www.rfc-editor.org/info/rfc7761">
<front>
<title>Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)</title>
<seriesInfo name="DOI" value="10.17487/RFC7761"/>
<seriesInfo name="RFC" value="7761"/>
<seriesInfo name="STD" value="83"/>
<author initials="B." surname="Fenner" fullname="B. Fenner">
<organization/>
</author>
<author initials="M." surname="Handley" fullname="M. Handley">
<organization/>
</author>
<author initials="H." surname="Holbrook" fullname="H. Holbrook">
<organization/>
</author>
<author initials="I." surname="Kouvelas" fullname="I. Kouvelas">
<organization/>
</author>
<author initials="R." surname="Parekh" fullname="R. Parekh">
<organization/>
</author>
<author initials="Z." surname="Zhang" fullname="Z. Zhang">
<organization/>
</author>
<author initials="L." surname="Zheng" fullname="L. Zheng">
<organization/>
</author>
<date year="2016" month="March"/>
<abstract>
<t>This document specifies Protocol Independent Multicast - Sparse Mode (PIM-SM). PIM-SM is a multicast routing protocol that can use the underlying unicast routing information base or a separate multicast-capable routing information base. It builds unidirectional shared trees rooted at a Rendezvous Point (RP) per group, and it optionally creates shortest-path trees per source.</t>
<t>This document obsoletes RFC 4601 by replacing it, addresses the errata filed against it, removes the optional (*,*,RP), PIM Multicast Border Router features and authentication using IPsec that lack sufficient deployment experience (see Appendix A), and moves the PIM specification to Internet Standard.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7950">
<front>
<title>The YANG 1.1 Data Modeling Language</title>
<seriesInfo name="DOI" value="10.17487/RFC7950"/>
<seriesInfo name="RFC" value="7950"/>
<author initials="M." surname="Bjorklund" fullname="M. Bjorklund" role="editor">
<organization/>
</author>
<date year="2016" month="August"/>
<abstract>
<t>YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8028" target="https://www.rfc-editor.org/info/rfc8028">
<front>
<title>First-Hop Router Selection by Hosts in a Multi-Prefix Network</title>
<seriesInfo name="DOI" value="10.17487/RFC8028"/>
<seriesInfo name="RFC" value="8028"/>
<author initials="F." surname="Baker" fullname="F. Baker">
<organization/>
</author>
<author initials="B." surname="Carpenter" fullname="B. Carpenter">
<organization/>
</author>
<date year="2016" month="November"/>
<abstract>
<t>This document describes expected IPv6 host behavior in a scenario that has more than one prefix, each allocated by an upstream network that is assumed to implement BCP 38 ingress filtering, when the host has multiple routers to choose from. It also applies to other scenarios such as the usage of stateful firewalls that effectively act as address-based filters. Host behavior in choosing a first-hop router may interact with source address selection in a given implementation. However, the selection of the source address for a packet is done before the first-hop router for that packet is chosen. Given that the network or host is, or appears to be, multihomed with multiple provider-allocated addresses, that the host has elected to use a source address in a given prefix, and that some but not all neighboring routers are advertising that prefix in their Router Advertisement Prefix Information Options, this document specifies to which router a host should present its transmission. It updates RFC 4861.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="BCP" value="26"/>
<author initials="M." surname="Cotton" fullname="M. Cotton">
<organization/>
</author>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization/>
</author>
<author initials="T." surname="Narten" fullname="T. Narten">
<organization/>
</author>
<date year="2017" month="June"/>
<abstract>
<t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 5226.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8366" target="https://www.rfc-editor.org/info/rfc8366">
<front>
<title>A Voucher Artifact for Bootstrapping Protocols</title>
<seriesInfo name="DOI" value="10.17487/RFC8366"/>
<seriesInfo name="RFC" value="8366"/>
<author initials="K." surname="Watsen" fullname="K. Watsen">
<organization/>
</author>
<author initials="M." surname="Richardson" fullname="M. Richardson">
<organization/>
</author>
<author initials="M." surname="Pritikin" fullname="M. Pritikin">
<organization/>
</author>
<author initials="T." surname="Eckert" fullname="T. Eckert">
<organization/>
</author>
<date year="2018" month="May"/>
<abstract>
<t>This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher".</t>
<t>This document defines an artifact format as a YANG-defined JSON document that has been signed using a Cryptographic Message Syntax (CMS) structure. Other YANG-derived formats are possible. The voucher artifact is normally generated by the pledge's manufacturer (i.e., the Manufacturer Authorized Signing Authority (MASA).</t>
<t>This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8316" target="https://www.rfc-editor.org/info/rfc8316">
<front>
<title>Autonomic Networking Use Case for Distributed Detection of Service Level Agreement (SLA) Violations</title>
<seriesInfo name="DOI" value="10.17487/RFC8316"/>
<seriesInfo name="RFC" value="8316"/>
<author initials="J." surname="Nobre" fullname="J. Nobre">
<organization/>
</author>
<author initials="L." surname="Granville" fullname="L. Granville">
<organization/>
</author>
<author initials="A." surname="Clemm" fullname="A. Clemm">
<organization/>
</author>
<author initials="A." surname="Gonzalez Prieto" fullname="A. Gonzalez Prieto">
<organization/>
</author>
<date year="2018" month="February"/>
<abstract>
<t>This document describes an experimental use case that employs autonomic networking for the monitoring of Service Level Agreements (SLAs). The use case is for detecting violations of SLAs in a distributed fashion. It strives to optimize and dynamically adapt the autonomic deployment of active measurement probes in a way that maximizes the likelihood of detecting service-level violations with a given resource budget to perform active measurements. This optimization and adaptation should be done without any outside guidance or intervention.</t>
<t>This document is a product of the IRTF Network Management Research Group (NMRG). It is published for informational purposes.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8368" target="https://www.rfc-editor.org/info/rfc8368">
<front>
<title>Using an Autonomic Control Plane for Stable Connectivity of Network Operations, Administration, and Maintenance (OAM)</title>
<seriesInfo name="DOI" value="10.17487/RFC8368"/>
<seriesInfo name="RFC" value="8368"/>
<author initials="T." surname="Eckert" fullname="T. Eckert" role="editor">
<organization/>
</author>
<author initials="M." surname="Behringer" fullname="M. Behringer">
<organization/>
</author>
<date year="2018" month="May"/>
<abstract>
<t>Operations, Administration, and Maintenance (OAM), as per BCP 161, for data networks is often subject to the problem of circular dependencies when relying on connectivity provided by the network to be managed for the OAM purposes.</t>
<t>Provisioning while bringing up devices and networks tends to be more difficult to automate than service provisioning later on. Changes in core network functions impacting reachability cannot be automated because of ongoing connectivity requirements for the OAM equipment itself, and widely used OAM protocols are not secure enough to be carried across the network without security concerns.</t>
<t>This document describes how to integrate OAM processes with an autonomic control plane in order to provide stable and secure connectivity for those OAM processes. This connectivity is not subject to the aforementioned circular dependencies.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8398" target="https://www.rfc-editor.org/info/rfc8398">
<front>
<title>Internationalized Email Addresses in X.509 Certificates</title>
<seriesInfo name="DOI" value="10.17487/RFC8398"/>
<seriesInfo name="RFC" value="8398"/>
<author initials="A." surname="Melnikov" fullname="A. Melnikov" role="editor">
<organization/>
</author>
<author initials="W." surname="Chuang" fullname="W. Chuang" role="editor">
<organization/>
</author>
<date year="2018" month="May"/>
<abstract>
<t>This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name and Issuer Alternative Name extension that allows a certificate subject to be associated with an internationalized email address.</t>
<t>This document updates RFC 5280.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8402" target="https://www.rfc-editor.org/info/rfc8402">
<front>
<title>Segment Routing Architecture</title>
<seriesInfo name="DOI" value="10.17487/RFC8402"/>
<seriesInfo name="RFC" value="8402"/>
<author initials="C." surname="Filsfils" fullname="C. Filsfils" role="editor">
<organization/>
</author>
<author initials="S." surname="Previdi" fullname="S. Previdi" role="editor">
<organization/>
</author>
<author initials="L." surname="Ginsberg" fullname="L. Ginsberg">
<organization/>
</author>
<author initials="B." surname="Decraene" fullname="B. Decraene">
<organization/>
</author>
<author initials="S." surname="Litkowski" fullname="S. Litkowski">
<organization/>
</author>
<author initials="R." surname="Shakir" fullname="R. Shakir">
<organization/>
</author>
<date year="2018" month="July"/>
<abstract>
<t>Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.</t>
<t>SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.</t>
<t>SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8572" target="https://www.rfc-editor.org/info/rfc8572">
<front>
<title>Secure Zero Touch Provisioning (SZTP)</title>
<seriesInfo name="DOI" value="10.17487/RFC8572"/>
<seriesInfo name="RFC" value="8572"/>
<author initials="K." surname="Watsen" fullname="K. Watsen">
<organization/>
</author>
<author initials="I." surname="Farrer" fullname="I. Farrer">
<organization/>
</author>
<author initials="M." surname="Abrahamsson" fullname="M. Abrahamsson">
<organization/>
</author>
<date year="2019" month="April"/>
<abstract>
<t>This document presents a technique to securely provision a networking device when it is booting in a factory-default state. Variations in the solution enable it to be used on both public and private networks. The provisioning steps are able to update the boot image, commit an initial configuration, and execute arbitrary scripts to address auxiliary needs. The updated device is subsequently able to establish secure connections with other systems. For instance, a device may establish NETCONF (RFC 6241) and/or RESTCONF (RFC 8040) connections with deployment-specific network management systems.</t>
</abstract>
</front>
</reference>
<reference anchor="I-D.ietf-anima-reference-model" target="http://www.ietf.org/internet-drafts/draft-ietf-anima-reference-model-10.txt">
<front>
<title>A Reference Model for Autonomic Networking</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-reference-model-10"/>
<author initials="M" surname="Behringer" fullname="Michael Behringer">
<organization/>
</author>
<author initials="B" surname="Carpenter" fullname="Brian Carpenter">
<organization/>
</author>
<author initials="T" surname="Eckert" fullname="Toerless Eckert">
<organization/>
</author>
<author initials="L" surname="Ciavaglia" fullname="Laurent Ciavaglia">
<organization/>
</author>
<author initials="J" surname="Nobre" fullname="Jeferson Nobre">
<organization/>
</author>
<date month="November" day="22" year="2018"/>
<abstract>
<t>This document describes a reference model for Autonomic Networking for managed networks. It defines the behaviour of an autonomic node, how the various elements in an autonomic context work together, and how autonomic services can use the infrastructure.</t>
</abstract>
</front>
</reference>
<reference anchor="I-D.eckert-anima-noc-autoconfig" target="http://www.ietf.org/internet-drafts/draft-eckert-anima-noc-autoconfig-00.txt">
<front>
<title>Autoconfiguration of NOC services in ACP networks via GRASP</title>
<seriesInfo name="Internet-Draft" value="draft-eckert-anima-noc-autoconfig-00"/>
<author initials="T" surname="Eckert" fullname="Toerless Eckert">
<organization/>
</author>
<date month="July" day="2" year="2018"/>
<abstract>
<t>This document defines standards for the autoconfiguration of crucial NOC services on ACP nodes via GRASP. It enables secure remote access to zero-touch bootstrapped ANI devices via SSH/NETCONF with RADIUS/Diameter authentication and authorization and provides lifecycle autoconfiguration for other crucial services such as syslog, NTP (clock synchronization) and DNS for operational purposes.</t>
</abstract>
</front>
</reference>
<reference anchor="IEEE-1588-2008" target="http://standards.ieee.org/findstds/standard/1588-2008.html"> <reference anchor="IEEE-1588-2008" target="http://standards.ieee.org/findstds/standard/1588-2008.html">
<front> <front>
<title> <title>
IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems
</title> </title>
<author fullname="IEEE"> <author fullname="IEEE">
<organization>IEEE Standards Board</organization> <organization>IEEE Standards Board</organization>
</author> </author>
<date month="December" year="2008"/> <date month="December" year="2008"/>
</front> </front>
skipping to change at line 5887 skipping to change at line 4137
<front> <front>
<title>Information technology - Open Systems Interconnection - The Directory: Selected attribute types</title> <title>Information technology - Open Systems Interconnection - The Directory: Selected attribute types</title>
<seriesInfo name="ITU-T Recommendation X.520," value="ISO/IEC 9594-6"/> <seriesInfo name="ITU-T Recommendation X.520," value="ISO/IEC 9594-6"/>
<author> <author>
<organization>International Telecommunication Union</organization> <organization>International Telecommunication Union</organization>
</author> </author>
<date month="October" year="2016"/> <date month="October" year="2016"/>
</front> </front>
</reference> </reference>
<reference anchor="ACPDRAFT" target="https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-30.pdf"> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-anima-autonomic-control-plane.xml"/>
<front>
<title>An Autonomic Control Plane (ACP)</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-anima-autonomic-control-plane-30"/>
<author initials="T" surname="Eckert" fullname="Toerless Eckert">
<organization/>
</author>
<author initials="M" surname="Behringer" fullname="Michael Behringer">
<organization/>
</author>
<author initials="S" surname="Bjarnason" fullname="Steinthor Bjarnason">
<organization/>
</author>
</front>
<annotation>[RFC-Editor: Please remove this complete reference from the RFC] Refer to the IETF working group draft for the few sections removed from this document for various reasons. They capture the state of discussion about unresolved issues that may need to be revisited in future work.
</annotation>
</reference>
<reference anchor="FCC" target="https://docs.fcc.gov/public/attachments/DOC-367699A1.docx"> <reference anchor="FCC" target="https://docs.fcc.gov/public/attachments/DOC-367699A1.docx">
<front> <front>
<title>FCC STAFF REPORT ON NATIONWIDE T-MOBILE NETWORK OUTAGE ON JUNE 15, 2020 (PS Docket No. 20-183)</title> <title>FCC STAFF REPORT ON NATIONWIDE T-MOBILE NETWORK OUTAGE ON JUNE 15, 2020 (PS Docket No. 20-183)</title>
<author> <author>
<organization>FCC</organization> <organization>FCC</organization>
</author> </author>
<date year="2020" /> <date year="2020"/>
</front> </front>
<annotation>The FCC's Public Safety and Homeland Security Bureau issues a report on a nationwide T-Mobile outage that occurred on June 15, 2020. Action by: Public Safety and Homeland Security Bureau.</annotation> <annotation>The FCC's Public Safety and Homeland Security Bureau issues a report on a nationwide T-Mobile outage that occurred on June 15, 2020. Action by: Public Safety and Homeland Security Bureau.</annotation>
</reference> </reference>
<reference anchor="I-D.ietf-roll-applicability-template" target="http://www.ietf.org/internet-drafts/draft-ietf-roll-applicability-template-09.txt"> <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-roll-applicability-template.xml"/>
<front>
<title>ROLL Applicability Statement Template</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-roll-applicability-template-09"/>
<author initials="M" surname="Richardson" fullname="Michael Richardson">
<organization/>
</author>
<date month="May" day="3" year="2016"/>
<abstract>
<t>This document is a template applicability statement for the Routing over Low-power and Lossy Networks (ROLL) WG. This document is not for publication, but rather is to be used as a template.</t>
</abstract>
</front>
</reference>
</references> </references>
<section anchor="further" numbered="true" toc="default"> <section anchor="further" numbered="true" toc="default">
<name>Background and Futures (Informative)</name> <name>Background and Futures (Informative)</name>
<t>The following sections discuss additional background information about aspects of the normative parts of this document or associated mechanisms such as BRSKI (such as why specific choices were made by the ACP) and they provide discussion about possible future variations of the ACP.</t> <t>The following sections discuss additional background information about aspects of the normative parts of this document or associated mechanisms such as BRSKI (such as why specific choices were made by the ACP) and they provide discussion about possible future variations of the ACP.</t>
<section anchor="address-spaces" numbered="true" toc="default"> <section anchor="address-spaces" numbered="true" toc="default">
<name>ACP Address Space Schemes</name> <name>ACP Address Space Schemes</name>
<t>This document defines the Zone, Vlong and Manual sub <t>This document defines the Zone, Vlong and Manual sub
address schemes primarily to support address prefix assignment address schemes primarily to support address prefix assignment
via distributed, potentially uncoordinated ACP registrars as defined via distributed, potentially uncoordinated ACP registrars as defined
in <xref target="acp-registrars" format="default"/>. This in <xref target="acp-registrars" format="default"/>. This
skipping to change at line 6225 skipping to change at line 4447
<name>ACP APIs and operational models (YANG)</name> <name>ACP APIs and operational models (YANG)</name>
<t>Future work should define YANG (<xref target="RFC7950" format="default"/>) data model <t>Future work should define YANG (<xref target="RFC7950" format="default"/>) data model
and/or node internal APIs to monitor and manage the ACP.</t> and/or node internal APIs to monitor and manage the ACP.</t>
<t>Support for the ACP Adjacency Table (<xref target="adj-table" format="default"/>) and ACP GRASP need to <t>Support for the ACP Adjacency Table (<xref target="adj-table" format="default"/>) and ACP GRASP need to
be included into such model/API.</t> be included into such model/API.</t>
</section> </section>
<section anchor="future-rpl" numbered="true" toc="default"> <section anchor="future-rpl" numbered="true" toc="default">
<name>RPL enhancements</name> <name>RPL enhancements</name>
<figure anchor="dual-noc"> <figure anchor="dual-noc">
<name>Dual NOC</name> <name>Dual NOC</name>
<artwork name="" type="" align="left" alt=""><![CDATA[ <artwork name="" type="" align="left" alt="">
..... USA ...... ..... Europe ...... ..... USA ...... ..... Europe ......
NOC1 NOC2 NOC1 NOC2
| | | |
| metric 100 | | metric 100 |
ACP1 --------------------------- ACP2 . ACP1 --------------------------- ACP2 .
| | . WAN | | . WAN
| metric 10 metric 20 | . Core | metric 10 metric 20 | . Core
| | . | | .
ACP3 --------------------------- ACP4 . ACP3 --------------------------- ACP4 .
| metric 100 | | metric 100 |
| | . | | .
| | . Sites | | . Sites
ACP10 ACP11 . ACP10 ACP11 .
]]></artwork> </artwork>
</figure> </figure>
<t>The profile for RPL specified in this document builds only one spanning-tree path set to a root, typically a registrar in one NOC. In the presence of multiple NOCs, routing toward the non-root NOCs may be suboptimal. <xref target="dual-noc" format="default"/> shows an extreme example. Assuming that node ACP1 becomes the RPL root, traffic between ACP11 and NOC2 will pass through ACP4-ACP3-ACP1-ACP2 instead of ACP4-ACP2 because the RPL calculated DODAG/routes are shortest paths towards the RPL root.</t> <t>The profile for RPL specified in this document builds only one spanning-tree path set to a root, typically a registrar in one NOC. In the presence of multiple NOCs, routing toward the non-root NOCs may be suboptimal. <xref target="dual-noc" format="default"/> shows an extreme example. Assuming that node ACP1 becomes the RPL root, traffic between ACP11 and NOC2 will pass through ACP4-ACP3-ACP1-ACP2 instead of ACP4-ACP2 because the RPL calculated DODAG/routes are shortest paths towards the RPL root.</t>
<t>To overcome these limitations, extensions/modifications to the RPL profile can provide optimality for multiple NOCs. This requires utilizing Data-Plane artifact including IPinIP encap/decap on ACP routers and processing of IPv6 RPI headers. Alternatively, (Src,Dst) routing table entries could be used.</t> <t>To overcome these limitations, extensions/modifications to the RPL profile can provide optimality for multiple NOCs. This requires utilizing Data-Plane artifact including IPinIP encap/decap on ACP routers and processing of IPv6 RPI headers. Alternatively, (Src,Dst) routing table entries could be used.</t>
<t>Flooding of ACP GRASP messages can be further constrained and therefore optimized by flooding only via links that are part of the RPL DODAG.</t> <t>Flooding of ACP GRASP messages can be further constrained and therefore optimized by flooding only via links that are part of the RPL DODAG.</t>
</section> </section>
<section anchor="role-assignments" numbered="true" toc="default"> <section anchor="role-assignments" numbered="true" toc="default">
<name>Role assignments</name> <name>Role assignments</name>
<t>ACP connect is an explicit mechanism to "leak" ACP traffic explicitly (for example <t>ACP connect is an explicit mechanism to "leak" ACP traffic explicitly (for example
in a NOC). It is therefore also a possible security gap when it is easy to enable ACP in a NOC). It is therefore also a possible security gap when it is easy to enable ACP
connect on arbitrary compromised ACP nodes.</t> connect on arbitrary compromised ACP nodes.</t>
skipping to change at line 6485 skipping to change at line 4707
reducing the effective path segment capacity.</t> reducing the effective path segment capacity.</t>
<t>As explained elsewhere in this document already, considerations for <t>As explained elsewhere in this document already, considerations for
these type of attack are therefore outside the scope of the ACP but these type of attack are therefore outside the scope of the ACP but
fundametal to further design of the ASA infrastructure. Beyond fundametal to further design of the ASA infrastructure. Beyond
distinguishing whether a TCP proxy would be beneficial or malicious, distinguishing whether a TCP proxy would be beneficial or malicious,
the even more fundamental question is how to determine from a multitude the even more fundamental question is how to determine from a multitude
of service announcements which instance is the most trustworthy and of service announcements which instance is the most trustworthy and
functionally best. In the Internet/web, this question is NOT solved functionally best. In the Internet/web, this question is NOT solved
inside the network but through off-net human interaction ("trust me, inside the network but through off-net human interaction ("trust me,
the best search engine is www.&lt;insert-your-personal-recommendation>.com").</t> the best search engine is www.&lt;insert-your-personal-recommendation&gt;.com").</t>
</section> </section>
<section anchor="public-ca" numbered="true" toc="default"> <section anchor="public-ca" numbered="true" toc="default">
<name>Public CA considerations</name> <name>Public CA considerations</name>
<t>Public CAs are outside the scope of this document for the following reasons. This appendix describes the current state of understanding for those interested to consider utilizing public CA for the ACP in the future.</t> <t>Public CAs are outside the scope of this document for the following reasons. This appendix describes the current state of understanding for those interested to consider utilizing public CA for the ACP in the future.</t>
<t>If public CA where to be used to enroll ACP nodes and act as TA, this would require a model in which <t>If public CA where to be used to enroll ACP nodes and act as TA, this would require a model in which
the public CA would be able to assert the ownership of the information requested in the certificate, the public CA would be able to assert the ownership of the information requested in the certificate,
especially the AcpNodeName, for example mitigated by the domain registrar(s). especially the AcpNodeName, for example mitigated by the domain registrar(s).
 End of changes. 67 change blocks. 
1924 lines changed or deleted 146 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/