| Internet-Draft | APN6 Encapsulation | April 2022 |
| Li, et al. | Expires 10 October 2022 | [Page] |
Application-aware IPv6 Networking (APN6) makes use of IPv6 encapsulation to convey the APN Attribute along with data packets and make the network aware of data flow requirements at different granularity levels. The APN attribute can be encapsulated in the APN header. This document defines the encapsulation of the APN header in the IPv6 data plane.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 10 October 2022.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Application-aware Networking (APN) is introduced in [I-D.li-apn-framework] and [I-D.li-apn-problem-statement-usecases]. APN conveys an attribute along with data packets into the network and make the network aware of data flow requirements at different granularity levels. Such an attribute is acquired, constructed as a structured value, and then encapsulated in the packets. Such a structured value is treated as an opaque object in the network, to which the network operator applies policies in various nodes/service functions along the path, providing corresponding services.¶
[I-D.li-apn-header] defines the application-aware networking (APN) header which can be used in different data planes to carry the APN attribute. This document defines the encapsulation of the APN header in the IPv6 data plane.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
APN: Application-aware Networking¶
APN6: Application-aware IPv6 Networking, i.e., the data plane of APN is IPv6¶
APN Attribute: Application-aware information. It is added at the edge devices of an APN domain along with any tunnel encapsulation.¶
APN ID: Application-aware Networking ID¶
APN Para: Application-aware Networking Parameters¶
To support Application-aware IPv6 networking, one IPv6 Header option RFC 8200 [RFC8200], the APN option, is defined.¶
The APN option has the following format:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Opt Type = TBD1| Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. APN Header (Variable) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. The APN Option
¶
where:¶
o Opt Type: Type value is TBD1, an 8-bit unsigned integer. Identifier of the type of this APN Option.¶
o Opt Data Len: An 8-bit unsigned integer. Length of the Option Data field of this option, that is, length of the APN header.¶
o APN Header: Option-Type-specific data. It carries the APN header. Variable-length field as specified in [I-D.li-apn-header].¶
The APN IPv6 Header option can be placed in two locations in an IPv6 packet header RFC 8200 [RFC8200] depend upon the scenario and implementation requirements. These are defined in the subsections below.¶
The APN option can be carried in the IPv6 Hop-by-Hop Options Header. By using the HBH Options Header, the information carried can be read by every node along the path.¶
The APN option can be carried in the IPv6 Destination Options Header. By using the DOH Options Header, the information carried can be read by the destination node but would not normally be seen by other nodes along the path.¶
[RFC8754] defines the segment routing header (SRH) and the SRH TLV. The SRH TLV provides meta-data for segment processing. The APN header can be placed in the SRH as the value of one type of SRH TLV following the Segment List. By using the SRH, the information carried can be read by the specified segment destinations along the SRv6 path.¶
The APN TLV is OPTIONAL and has the following format:¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TBD2 | Length |D| RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. APN Header (Variable) .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. The APN SRH TLV
¶
where:¶
o Type: TBD2 (suggested value 5).¶
o Length: The length of the variable length data in bytes.¶
o D: 1 bit. When it is set, it indicates the Destination Address verification is disabled due to use of a reduced segment list.¶
o RESERVED: 15 bits. MUST be 0 on transmission and ignored on receipt.¶
o APN Header: It carries the APN header as specified in [I-D.li-apn-header]. A variable-length field.¶
IANA is requested to assign two code points as below.¶
IANA is requested to assign an IPv6 Header Option as follows:¶
Hex Binary Value
Value act chg rest Description Reference
----- --- --- ----- ---------------------------- ---------------
TBD1 00 0 xxxxx Application-aware Networking [this document]
¶
RFC Editor / IANA Note: To be removed when RFC is published. xxxxx is the binary for the bottom 5 bits of TBD1.¶
IANA is requested to assign an SRH TLV Type from the range of type values for TLVs that do not change en route (2-127) as follows:¶
Value Description Reference
----- ---------------------------- -----------------
TBD2 Application-aware Networking [this document]
¶
The Security Considerations are described in [I-D.li-apn-problem-statement-usecases].¶