Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.

A Lower Effort Per-Hop Behavior (LE PHB)
draft-ietf-tsvwg-le-phb-08

Versions:

00
01
02
03
04
05
06
07
08
09
10
RFC 8622

The information below is for an old version of the document.

Document	Type	This is an older version of an Internet-Draft that was ultimately published as RFC 8622.
	Author	Roland Bless
	Last updated	2019-02-12 (Latest revision 2019-01-30)
	Replaces	draft-bless-tsvwg-le-phb
	RFC stream	Internet Engineering Task Force (IETF)
	Formats	txt htmlized pdf bibtex bibxml
	Reviews	GENART Last Call review by Brian Carpenter Ready SECDIR Last Call review by Kyle Rose Has nits TSVART Last Call review by Olivier Bonaventure Ready w/nits
	Additional resources	Mailing list discussion
Stream	WG state	Submitted to IESG for Publication
	Document shepherd	David L. Black
	Shepherd write-up	Show Last changed 2018-11-09
IESG	IESG state	Became RFC 8622 (Proposed Standard)
	Consensus boilerplate	Yes
	Telechat date	(None)
	Responsible AD	Spencer Dawkins
	Send notices to	"David Black" <david.black@dell.com>
IANA	IANA review state	IANA OK - Actions Needed

Email authors Email WG IPR References Referenced by Nits Search email archive

draft-ietf-tsvwg-le-phb-08

Internet Engineering Task Force R. Bless
Internet-Draft Karlsruhe Institute of Technology (KIT)
Obsoletes: 3662 (if approved) January 30, 2019
Updates: 4594,8325 (if approved)
Intended status: Standards Track
Expires: August 3, 2019

A Lower Effort Per-Hop Behavior (LE PHB)
draft-ietf-tsvwg-le-phb-08

Abstract

This document specifies properties and characteristics of a Lower
Effort (LE) per-hop behavior (PHB). The primary objective of this LE
PHB is to protect best-effort (BE) traffic (packets forwarded with
the default PHB) from LE traffic in congestion situations, i.e., when
resources become scarce, best-effort traffic has precedence over LE
traffic and may preempt it. Alternatively, packets forwarded by the
LE PHB can be associated with a scavenger service class, i.e., they
scavenge otherwise unused resources only. There are numerous uses
for this PHB, e.g., for background traffic of low precedence, such as
bulk data transfers with low priority in time, non time-critical
backups, larger software updates, web search engines while gathering
information from web servers and so on. This document recommends a
standard DSCP value for the LE PHB. This specification obsoletes RFC
3662 and updates the DSCP recommended in RFC 4594 and RFC 8325 to use
the DSCP assigned in this specification.

Status of This Memo

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 August 3, 2019.

Bless Expires August 3, 2019 [Page 1]
Internet-Draft Lower Effort PHB January 2019

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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3
4. PHB Description . . . . . . . . . . . . . . . . . . . . . . . 6
5. Traffic Conditioning Actions . . . . . . . . . . . . . . . . 6
6. Recommended DS Codepoint . . . . . . . . . . . . . . . . . . 7
7. Deployment Considerations . . . . . . . . . . . . . . . . . . 7
8. Remarking to other DSCPs/PHBs . . . . . . . . . . . . . . . . 8
9. Multicast Considerations . . . . . . . . . . . . . . . . . . 9
10. The Update to RFC 4594 . . . . . . . . . . . . . . . . . . . 10
11. The Update to RFC 8325 . . . . . . . . . . . . . . . . . . . 11
12. The Update to draft-ietf-tsvwg-rtcweb-qos . . . . . . . . . . 12
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
14. Security Considerations . . . . . . . . . . . . . . . . . . . 14
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
15.1. Normative References . . . . . . . . . . . . . . . . . . 14
15.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. History of the LE PHB . . . . . . . . . . . . . . . 17
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 17

Bless Expires August 3, 2019 [Page 2]
Internet-Draft Lower Effort PHB January 2019

Appendix C. Change History . . . . . . . . . . . . . . . . . . . 17
Appendix D. Note to RFC Editor . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20

1. Introduction

This document defines a Differentiated Services per-hop behavior
[RFC2474] called "Lower Effort" (LE), which is intended for traffic
of sufficiently low urgency that all other traffic takes precedence
over the LE traffic in consumption of network link bandwidth. Low
urgency traffic has a low priority for timely forwarding, which does
not necessarily imply that it is generally of minor importance. From
this viewpoint, it can be considered as a network equivalent to a
background priority for processes in an operating system. There may
or may not be memory (buffer) resources allocated for this type of
traffic.

Some networks carry packets that ought to consume network resources
only when no other traffic is demanding them. In this point of view,
packets forwarded by the LE PHB scavenge otherwise unused resources
only, which led to the name "scavenger service" in early Internet2
deployments (see Appendix A). Other commonly used names for LE PHB
type services are "Lower-than-best-effort" or "Less-than-best-
effort". Alternatively, the effect of this type of traffic on all
other network traffic is strictly limited ("no harm" property). This
is distinct from "best-effort" (BE) traffic since the network makes
no commitment to deliver LE packets. In contrast, BE traffic
receives an implied "good faith" commitment of at least some
available network resources. This document proposes a Lower Effort
Differentiated Services per-hop behavior (LE PHB) for handling this
"optional" traffic in a differentiated services node.

2. Requirements Language

The key words The payload type for the Security Association payload is
thirty-three (33).

3.3.1. Proposal Substructure

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Last Substruc | RESERVED | Proposal Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Proposal Num | Protocol ID | SPI Size |Num Transforms|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ SPI (variable) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <Transforms> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 7: Proposal Substructure

o Last Substruc (1 octet) - Specifies whether or not this is the
last Proposal Substructure in the SA. This field has a value of 0
if this was the last Proposal Substructure, and a value of 2 if
there are more Proposal Substructures. This syntax is inherited
from ISAKMP, but is unnecessary because the last Proposal could be
identified from the length of the SA. The value (2) corresponds
to a payload type of Proposal in IKEv1, and the first four octets
of the Proposal structure are designed to look somewhat like the
header of a payload.

o RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on
receipt.

o Proposal Length (2 octets, unsigned integer) - Length of this
proposal, including all transforms and attributes that follow.

o Proposal Num (1 octet) - When a proposal is made, the first
proposal in an SA payload MUST be 1, and subsequent proposals MUST
be one more than the previous proposal (indicating an OR of the
two proposals). When a proposal is accepted, the proposal number
in the SA payload MUST match the number on the proposal sent that
was accepted.

Kaufman, et al. Standards Track [Page 80]
RFC 7296 IKEv2bis October 2014

o Protocol ID (1 octet) - Specifies the IPsec protocol identifier
for the current negotiation. The values in the following table
are only current as of the publication date of RFC 4306. Other
values may have been added since then or will be added after the
publication of this document. Readers should refer to [IKEV2IANA]
for the latest values.

Protocol Protocol ID
-----------------------------------
IKE 1
AH 2
ESP 3

o SPI Size (1 octet) - For an initial IKE SA negotiation, this field
MUST be zero; the SPI is obtained from the outer header. During
subsequent negotiations, it is equal to the size, in octets, of
the SPI of the corresponding protocol (8 for IKE, 4 for ESP
and AH).

o Num Transforms (1 octet) - Specifies the number of transforms in
this proposal.

o SPI (variable) - The sending entity's SPI. Even if the SPI Size
is not a multiple of 4 octets, there is no padding applied to the
payload. When the SPI Size field is zero, this field is not
present in the Security Association payload.

o Transforms (variable) - One or more transform substructures.

3.3.2. Transform Substructure

Figure 8: Transform Substructure

o Last Substruc (1 octet) - Specifies whether or not this is the
last Transform Substructure in the Proposal. This field has a
value of 0 if this was the last Transform Substructure, and a

Kaufman, et al. Standards Track [Page 81]
RFC 7296 IKEv2bis October 2014

value of 3 if there are more Transform Substructures. This syntax
is inherited from ISAKMP, but is unnecessary because the last
transform could be identified from the length of the proposal.
The value (3) corresponds to a payload type of Transform in IKEv1,
and the first four octets of the Transform structure are designed
to look somewhat like the header of a payload.

o RESERVED - MUST be sent as zero; MUST be ignored on receipt.

o Transform Length - The length (in octets) of the Transform
Substructure including Header and Attributes.

o Transform Type (1 octet) - The type of transform being specified
in this transform. Different protocols support different
Transform Types. For some protocols, some of the transforms may
be optional. If a transform is optional and the initiator wishes
to propose that the transform be omitted, no transform of the
given type is included in the proposal. If the initiator wishes
to make use of the transform optional to the responder, it
includes a transform substructure with Transform ID = 0 as one of
the options.

o Transform ID (2 octets) - The specific instance of the Transform
Type being proposed.

The Transform Type values are listed below. The values in the
following table are only current as of the publication date of
RFC 4306. Other values may have been added since then or will be
added after the publication of this document. Readers should refer
to [IKEV2IANA] for the latest values.

Description Trans. Used In
Type
------------------------------------------------------------------
Encryption Algorithm (ENCR) 1 IKE and ESP
Pseudorandom Function (PRF) 2 IKE
Integrity Algorithm (INTEG) 3 IKE*, AH, optional in ESP
Diffie-Hellman Group (D-H) 4 IKE, optional in AH & ESP
Extended Sequence Numbers (ESN) 5 AH and ESP

(*) Negotiating an integrity algorithm is mandatory for the
Encrypted payload format specified in this document. For example,
[AEAD] specifies additional formats based on authenticated
encryption, in which a separate integrity algorithm is not
negotiated.

Kaufman, et al. Standards Track [Page 82]
RFC 7296 IKEv2bis October 2014

For Transform Type 1 (Encryption Algorithm), the Transform IDs are
listed below. The values in the following table are only current as
of the publication date of RFC 4306. Other values may have been
added since then or will be added after the publication of this
document. Readers should refer to [IKEV2IANA] for the latest values.

Name Number Defined In
---------------------------------------------------
ENCR_DES_IV64 1 (UNSPECIFIED)
ENCR_DES 2 [RFC2405], [DES]
ENCR_3DES 3 [RFC2451]
ENCR_RC5 4 [RFC2451]
ENCR_IDEA 5 [RFC2451], [IDEA]
ENCR_CAST 6 [RFC2451]
ENCR_BLOWFISH 7 [RFC2451]
ENCR_3IDEA 8 (UNSPECIFIED)
ENCR_DES_IV32 9 (UNSPECIFIED)
ENCR_NULL 11 [RFC2410]
ENCR_AES_CBC 12 [RFC3602]
ENCR_AES_CTR 13 [RFC3686]

For Transform Type 2 (Pseudorandom Function), the Transform IDs are
listed below. The values in the following table are only current as
of the publication date of RFC 4306. Other values may have been
added since then or will be added after the publication of this
document. Readers should refer to [IKEV2IANA] for the latest values.

Name Number Defined In
------------------------------------------------------------------
PRF_HMAC_MD5 1 [RFC2104], [MD5]
PRF_HMAC_SHA1 2 [RFC2104], [FIPS.180-4.2012]
PRF_HMAC_TIGER 3 (UNSPECIFIED)

For Transform Type 3 (Integrity Algorithm), defined Transform IDs are
listed below. The values in the following table are only current as
of the publication date of RFC 4306. Other values may have been
added since then or will be added after the publication of this
document. Readers should refer to [IKEV2IANA] for the latest values.

Name Number Defined In
----------------------------------------
NONE 0
AUTH_HMAC_MD5_96 1 [RFC2403]
AUTH_HMAC_SHA1_96 2 [RFC2404]
AUTH_DES_MAC 3 (UNSPECIFIED)
AUTH_KPDK_MD5 4 (UNSPECIFIED)
AUTH_AES_XCBC_96 5 [RFC3566]

Kaufman, et al. Standards Track [Page 83]
RFC 7296 IKEv2bis October 2014

For Transform Type 4 (Diffie-Hellman group), defined Transform IDs
are listed below. The values in the following table are only current
as of the publication date of RFC 4306. Other values may have been
added since then or will be added after the publication of this
document. Readers should refer to [IKEV2IANA] for the latest values.

Name Number Defined In
------------------------------------------
NONE 0
768-bit MODP Group 1 Appendix B
1024-bit MODP Group 2 Appendix B
1536-bit MODP Group 5 [ADDGROUP]
2048-bit MODP Group 14 [ADDGROUP]
3072-bit MODP Group 15 [ADDGROUP]
4096-bit MODP Group 16 [ADDGROUP]
6144-bit MODP Group 17 [ADDGROUP]
8192-bit MODP Group 18 [ADDGROUP]

Although ESP and AH do not directly include a Diffie-Hellman
exchange, a Diffie-Hellman group MAY be negotiated for the Child SA.
This allows the peers to employ Diffie-Hellman in the CREATE_CHILD_SA
exchange, providing perfect forward secrecy for the generated Child
SA keys.

Note that the MODP Diffie-Hellman groups listed above do not need any
special validity tests to be performed, but other types of groups
(elliptic curve groups, and MODP groups with small subgroups) need to
have some additional tests performed on them to use them securely.
See "Additional Diffie-Hellman Tests for IKEv2" ([RFC6989]) for more
information.

For Transform Type 5 (Extended Sequence Numbers), defined Transform
IDs are listed below. The values in the following table are only
current as of the publication date of RFC 4306. Other values may
have been added since then or will be added after the publication of
this document. Readers should refer to [IKEV2IANA] for the latest
values.

Name Number
--------------------------------------------
No Extended Sequence Numbers 0
Extended Sequence Numbers 1

Note that an initiator who supports ESNs will usually include two ESN
transforms, with values "0" and "1", in its proposals. A proposal
containing a single ESN transform with value "1" means that using
normal (non-extended) sequence numbers is not acceptable.

Kaufman, et al. Standards Track [Page 84]
RFC 7296 IKEv2bis October 2014

Numerous additional Transform Types have been defined since the
publication of RFC 4306. Please refer to the IANA "Internet Key
Exchange Version 2 (IKEv2) Parameters" registry for details.

3.3.3. Valid Transform Types by Protocol

The number and type of transforms that accompany an SA payload are
dependent on the protocol in the SA itself. An SA payload proposing
the establishment of an SA has the following mandatory and optional
Transform Types. A compliant implementation MUST understand all
mandatory and optional types for each protocol it supports (though it
need not accept proposals with unacceptable suites). A proposal MAY
omit the optional types if the only value for them it will accept is
NONE.

Protocol Mandatory Types Optional Types
---------------------------------------------------
IKE ENCR, PRF, INTEG*, D-H
ESP ENCR, ESN INTEG, D-H
AH INTEG, ESN D-H

3.3.4. Mandatory Transform IDs

The specification of suites that MUST and SHOULD be supported for
interoperability has been removed from this document because they are
likely to change more rapidly than this document evolves. At the
time of publication of this document, [RFC4307] specifies these
suites, but note that it might be updated in the future, and other
RFCs might specify different sets of suites.

An important lesson learned from IKEv1 is that no system should only
implement the mandatory algorithms and expect them to be the best
choice for all customers.

It is likely that IANA will add additional transforms in the future,
and some users may want to use private suites, especially for IKE
where implementations should be capable of supporting different
parameters, up to certain size limits. In support of this goal, all
implementations of IKEv2 SHOULD include a management facility that
allows specification (by a user or system administrator) of Diffie-
Hellman parameters (the generator, modulus, and exponent lengths and
values) for new Diffie-Hellman groups. Implementations SHOULD

Kaufman, et al. Standards Track [Page 85]
RFC 7296 IKEv2bis October 2014

provide a management interface through which these parameters and the
associated Transform IDs may be entered (by a user or system
administrator), to enable negotiating such groups.

All implementations of IKEv2 MUST include a management facility that
enables a user or system administrator to specify the suites that are
acceptable for use with IKE. Upon receipt of a payload with a set of
Transform IDs, the implementation MUST compare the transmitted
Transform IDs against those locally configured via the management
controls, to verify that the proposed suite is acceptable based on
local policy. The implementation MUST reject SA proposals that are
not authorized by these IKE suite controls. Note that cryptographic
suites that MUST be implemented need not be configured as acceptable
to local policy.

3.3.5. Transform Attributes

Each transform in a Security Association payload may include
attributes that modify or complete the specification of the
transform. The set of valid attributes depends on the transform.
Currently, only a single attribute type is defined: the Key Length
attribute is used by certain encryption transforms with variable-
length keys (see below for details).

The attributes are type/value pairs and are defined below.
Attributes can have a value with a fixed two-octet length or a
variable-length value. For the latter, the attribute is encoded as
type/length/value.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A| Attribute Type | AF=0 Attribute Length |
|F| | AF=1 Attribute Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AF=0 Attribute Value |
| AF=1 Not Transmitted |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 9: Data Attributes

o Attribute Format (AF) (1 bit) - Indicates whether the data
attribute follows the Type/Length/Value (TLV) format or a
shortened Type/Value (TV) format. If the AF bit is zero (0), then
the attribute uses TLV format; if the AF bit is one (1), the TV
format (with two-byte value) is used.

Kaufman, et al. Standards Track [Page 86]
RFC 7296 IKEv2bis October 2014

o Attribute Type (15 bits) - Unique identifier for each type of
attribute (see below).

o Attribute Value (variable length) - Value of the attribute
associated with the attribute type. If the AF bit is a zero (0),
this field has a variable length defined by the Attribute Length
field. If the AF bit is a one (1), the Attribute Value has a
length of 2 octets.

The only currently defined attribute type (Key Length) is fixed
length; the variable-length encoding specification is included only
for future extensions. Attributes described as fixed length MUST NOT
be encoded using the variable-length encoding unless that length
exceeds two bytes. Variable-length attributes MUST NOT be encoded as
fixed-length even if their value can fit into two octets. Note: This
is a change from IKEv1, where increased flexibility may have
simplified the composer of messages but certainly complicated the
parser.

The values in the following table are only current as of the
publication date of RFC 4306. Other values may have been added since
then or will be added after the publication of this document.
Readers should refer to [IKEV2IANA] for the latest values.

Attribute Type Value Attribute Format
------------------------------------------------------------
Key Length (in bits) 14 TV

Values 0-13 and 15-17 were used in a similar context in IKEv1, and
should not be assigned except to matching values.

The Key Length attribute specifies the key length in bits (MUST use
network byte order) for certain transforms as follows:

o The Key Length attribute MUST NOT be used with transforms that use
a fixed-length key. For example, this includes ENCR_DES,
ENCR_IDEA, and all the Type 2 (Pseudorandom Function) and Type 3
(Integrity Algorithm) transforms specified in this document. It
is recommended that future Type 2 or 3 transforms do not use this
attribute.

o Some transforms specify that the Key Length attribute MUST be
always included (omitting the attribute is not allowed, and
proposals not containing it MUST be rejected). For example, this
includes ENCR_AES_CBC and ENCR_AES_CTR.

Kaufman, et al. Standards Track [Page 87]
RFC 7296 IKEv2bis October 2014

"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 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.

3. Applicability

A Lower Effort PHB is applicable for many applications that otherwise
use best-effort delivery. More specifically, it is suitable for
traffic and services that can tolerate strongly varying throughput
for their data flows, especially periods of very low throughput or
even starvation (i.e., long interruptions due to significant or even
complete packet loss). Therefore, an application sending an LE

Bless Expires August 3, 2019 [Page 3]
Internet-Draft Lower Effort PHB January 2019

marked flow needs to be able to tolerate short or (even very) long
interruptions due to the presence of severe congestion conditions
during the transmission of the flow. Thus, there ought to be an
expectation that packets of the LE PHB could be excessively delayed
or dropped when any other traffic is present. The LE PHB is suitable
for sending traffic of low urgency across a Differentiated Services
(DS) domain or DS region.

Just like best-effort traffic, LE traffic SHOULD be congestion
controlled (i.e., use a congestion controlled transport or implement
an appropriate congestion control method [RFC2914] [RFC8085]). Since
LE traffic could be starved completely for a longer period of time,
transport protocols or applications (and their related congestion
control mechanisms) SHOULD be able to detect and react to such a
starvation situation. An appropriate reaction would be to resume the
transfer instead of aborting it, i.e., an LE optimized transport
ought to use appropriate retry and timeout limits in order to avoid
the loss of the connection due to the mentioned starvation periods.
While it is desirable to achieve a quick resumption of the transfer
as soon as resources become available again, it may be difficult to
achieve this in practice. Congestion control is not only useful to
let the flows within the LE behavior aggregate adapt to the available
bandwidth that may be highly fluctuating, but is also essential if LE
traffic is mapped to the default PHB in DS domains that do not
support LE. In this case, use of background transport protocols,
e.g., similar to LEDBAT [RFC6817], is expedient.

Use of the LE PHB might assist a network operator in moving certain
kinds of traffic or users to off-peak times. Alternatively, or in
addition, packets can be designated for the LE PHB when the goal is
to protect all other packet traffic from competition with the LE
aggregate while not completely banning LE traffic from the network.
An LE PHB SHOULD NOT be used for a customer's "normal Internet"
traffic nor should packets be "downgraded" to the LE PHB instead of
being dropped, particularly when the packets are unauthorized
traffic. The LE PHB is expected to have applicability in networks
that have at least some unused capacity at certain periods.

The LE PHB allows networks to protect themselves from selected types
of traffic as a complement to giving preferential treatment to other
selected traffic aggregates. LE ought not to be used for the general
case of downgraded traffic, but could be used by design, e.g., to
protect an internal network from untrusted external traffic sources.
In this case there is no way for attackers to preempt internal (non
LE) traffic by flooding. Another use case in this regard is
forwarding of multicast traffic from untrusted sources. Multicast
forwarding is currently enabled within domains only for specific
sources within a domain, but not for sources from anywhere in the

Bless Expires August 3, 2019 [Page 4]
Internet-Draft Lower Effort PHB January 2019

Internet. A main problem is that multicast routing creates traffic
sources at (mostly) unpredictable branching points within a domain,
potentially leading to congestion and packet loss. In the case of
multicast traffic packets from untrusted sources are forwarded as LE
traffic, they will not harm traffic from non-LE behavior aggregates.
A further related use case is mentioned in [RFC3754]: preliminary
forwarding of non-admitted multicast traffic.

There is no intrinsic reason to limit the applicability of the LE PHB
to any particular application or type of traffic. It is intended as
an additional traffic engineering tool for network administrators.
For instance, it can be used to fill protection capacity of
transmission links that is otherwise unused. Some network providers
keep link utilization below 50% to ensure that all traffic is
forwarded without loss after rerouting caused by a link failure (cf.
Section 6 of [RFC3439]). LE marked traffic can utilize the normally
unused capacity and will be preempted automatically in case of link
failure when 100% of the link capacity is required for all other
traffic. Ideally, applications mark their packets as LE traffic,
since they know the urgency of flows.

Example uses for the LE PHB:

o For traffic caused by world-wide web search engines while they
gather information from web servers.

o For software updates or dissemination of new releases of operating
systems.

o For reporting errors or telemetry data from operating systems or
applications.

o For backup traffic or non-time critical synchronization or
mirroring traffic.

o For content distribution transfers between caches.

o For preloading or prefetching objects from web sites.

o For network news and other "bulk mail" of the Internet.

o For "downgraded" traffic from some other PHB when this does not
violate the operational objectives of the other PHB.

o For multicast traffic from untrusted (e.g., non-local) sources.

Bless Expires August 3, 2019 [Page 5]
Internet-Draft Lower Effort PHB January 2019

4. PHB Description

The LE PHB is defined in relation to the default PHB (best-effort).
A packet forwarded with the LE PHB SHOULD have lower precedence than
packets forwarded with the default PHB, i.e., in the case of
congestion, LE marked traffic SHOULD be dropped prior to dropping any
default PHB traffic. Ideally, LE packets would be forwarded only
when no packet with any other PHB is awaiting transmission. This
means that in case of link resource contention LE traffic can be
starved completely, which may not be always desired by the network
operator's policy. The used scheduler to implement the LE PHB may
reflect this policy accordingly.

A straightforward implementation could be a simple priority scheduler
serving the default PHB queue with higher priority than the lower-
effort PHB queue. Alternative implementations may use scheduling
algorithms that assign a very small weight to the LE class. This,
however, could sometimes cause better service for LE packets compared
to BE packets in cases when the BE share is fully utilized and the LE
share not.

If a dedicated LE queue is not available, an active queue management
mechanism within a common BE/LE queue could also be used. This could
drop all arriving LE packets as soon as certain queue length or
sojourn time thresholds are exceeded.

Since congestion control is also useful within the LE traffic class,
Explicit Congestion Notification [RFC3168] SHOULD be used for LE
packets, too.

5. Traffic Conditioning Actions

If possible, packets SHOULD be pre-marked in DS-aware end systems by
applications due to their specific knowledge about the particular
precedence of packets. There is no incentive for DS domains to
distrust this initial marking, because letting LE traffic enter a DS
domain causes no harm. Thus, any policing such as limiting the rate
of LE traffic is not necessary at the DS boundary.

As for most other PHBs an initial classification and marking can be
also performed at the first DS boundary node according to the DS
domain's own policies (e.g., as protection measure against untrusted
sources). However, non-LE traffic (e.g., BE traffic) SHOULD NOT be
remarked to LE on a regular basis without consent or knowledge of the
user. See also remarks with respect to downgrading in Section 3 and
Section 8.

Bless Expires August 3, 2019 [Page 6]
Internet-Draft Lower Effort PHB January 2019

6. Recommended DS Codepoint

The RECOMMENDED codepoint for the LE PHB is '000001'.

Earlier specifications [RFC4594] recommended to use CS1 as codepoint
(as mentioned in [RFC3662]). This is problematic since it may cause
a priority inversion in Diffserv domains that treat CS1 as originally
proposed in [RFC2474], resulting in forwarding LE packets with higher
precedence than BE packets. Existing implementations SHOULD
transition to use the unambiguous LE codepoint '000001' whenever
possible.

This particular codepoint was chosen due to measurements on the
currently observable DSCP remarking behavior in the Internet
[ietf99-secchi]. Since some network domains set the former IP
precedence bits to zero, it is possible that some other standardized
DSCPs get mapped to the LE PHB DSCP if it were taken from the DSCP
standards action pool 1 (xxxxx0).

7. Deployment Considerations

In order to enable LE support, DS nodes typically only need

o A BA classifier (Behavior Aggregate classifier, see [RFC2475])
that classifies packets according to the LE DSCP

o A dedicated LE queue

o A suitable scheduling discipline, e.g., simple priority queueing

Alternatively, implementations could use active queue management
mechanisms instead of a dedicated LE queue, e.g., dropping all
arriving LE packets when certain queue length or sojourn time
thresholds are exceeded.

Internet-wide deployment of the LE PHB is eased by the following
properties:

o No harm to other traffic: since the LE PHB has the lowest
forwarding priority it does not consume resources from other PHBs.
Deployment across different provider domains with LE support
causes no trust issues or attack vectors to existing (non LE)
traffic. Thus, providers can trust LE markings from end-systems,
i.e., there is no need to police or remark incoming LE traffic.

o No PHB parameters or configuration of traffic profiles: the LE PHB
itself possesses no parameters that need to be set or configured.

Bless Expires August 3, 2019 [Page 7]
Internet-Draft Lower Effort PHB January 2019

Similarly, since LE traffic requires no admission or policing, it
is not necessary to configure traffic profiles.

o No traffic conditioning mechanisms: the LE PHB requires no traffic
meters, droppers, or shapers. See also Section 5 for further
discussion.

Operators of DS domains that cannot or do not want to implement the
LE PHB (e.g., because there is no separate LE queue available in the
corresponding nodes) SHOULD NOT drop packets marked with the LE DSCP.
They SHOULD map packets with this DSCP to the default PHB and SHOULD
preserve the LE DSCP marking. DS domains operators that do not
implement the LE PHB should be aware that they violate the "no harm"
property of LE. See also Section 8 for further discussion of
forwarding LE traffic with the default PHB instead.

8. Remarking to other DSCPs/PHBs

"DSCP bleaching", i.e., setting the DSCP to '000000&o Some transforms allow variable-length keys, but also specify a
default key length if the attribute is not included. For example,
these transforms include ENCR_RC5 and ENCR_BLOWFISH.

Implementation note: To further interoperability and to support
upgrading endpoints independently, implementers of this protocol
SHOULD accept values that they deem to supply greater security. For
instance, if a peer is configured to accept a variable-length cipher
with a key length of X bits and is offered that cipher with a larger
key length, the implementation SHOULD accept the offer if it supports
use of the longer key.

Support for this capability allows a responder to express a concept
of "at least" a certain level of security -- "a key length of _at
least_ X bits for cipher Y". However, as the attribute is always
returned unchanged (see the next section), an initiator willing to
accept multiple key lengths has to include multiple transforms with
the same Transform Type, each with a different Key Length attribute.

3.3.6. Attribute Negotiation

During Security Association negotiation initiators present offers to
responders. Responders MUST select a single complete set of
parameters from the offers (or reject all offers if none are
acceptable). If there are multiple proposals, the responder MUST
choose a single proposal. If the selected proposal has multiple
transforms with the same type, the responder MUST choose a single
one. Any attributes of a selected transform MUST be returned
unmodified. The initiator of an exchange MUST check that the
accepted offer is consistent with one of its proposals, and if not
MUST terminate the exchange.

If the responder receives a proposal that contains a Transform Type
it does not understand, or a proposal that is missing a mandatory
Transform Type, it MUST consider this proposal unacceptable; however,
other proposals in the same SA payload are processed as usual.
Similarly, if the responder receives a transform that it does not
understand, or one that contains a Transform Attribute it does not
understand, it MUST consider this transform unacceptable; other
transforms with the same Transform Type are processed as usual. This
allows new Transform Types and Transform Attributes to be defined in
the future.

Negotiating Diffie-Hellman groups presents some special challenges.
SA offers include proposed attributes and a Diffie-Hellman public
number (KE) in the same message. If in the initial exchange the
initiator offers to use one of several Diffie-Hellman groups, it
SHOULD pick the one the responder is most likely to accept and

Kaufman, et al. Standards Track [Page 88]
RFC 7296 IKEv2bis October 2014

include a KE corresponding to that group. If the responder selects a
proposal using a different Diffie-Hellman group (other than NONE),
the responder will indicate the correct group in the response and the
initiator SHOULD pick an element of that group for its KE value when
retrying the first message. It SHOULD, however, continue to propose
its full supported set of groups in order to prevent a
man-in-the-middle downgrade attack. If one of the proposals offered
is for the Diffie-Hellman group of NONE, and the responder selects
that Diffie-Hellman group, then it MUST ignore the initiator's KE
payload and omit the KE payload from the response.

3.4. Key Exchange Payload

The Key Exchange payload, denoted KE in this document, is used to
exchange Diffie-Hellman public numbers as part of a Diffie-Hellman
key exchange. The Key Exchange payload consists of the IKE generic
payload header followed by the Diffie-Hellman public value itself.

Figure 10: Key Exchange Payload Format

A Key Exchange payload is constructed by copying one's Diffie-Hellman
public value into the "Key Exchange Data" portion of the payload.
The length of the Diffie-Hellman public value for MODP groups MUST be
equal to the length of the prime modulus over which the
exponentiation was performed, prepending zero bits to the value if
necessary.

The Diffie-Hellman Group Num identifies the Diffie-Hellman group in
which the Key Exchange Data was computed (see Section 3.3.2). This
Diffie-Hellman Group Num MUST match a Diffie-Hellman group specified
in a proposal in the SA payload that is sent in the same message, and
SHOULD match the Diffie-Hellman group in the first group in the first
proposal, if such exists. If none of the proposals in that SA
payload specifies a Diffie-Hellman group, the KE payload MUST NOT be

Kaufman, et al. Standards Track [Page 89]
RFC 7296 IKEv2bis October 2014

present. If the selected proposal uses a different Diffie-Hellman
group (other than NONE), the message MUST be rejected with a Notify
payload of type INVALID_KE_PAYLOAD. See also Sections 1.2 and 2.7.

The payload type for the Key Exchange payload is thirty-four (34).

3.5. Identification Payloads

The Identification payloads, denoted IDi and IDr in this document,
allow peers to assert an identity to one another. This identity may
be used for policy lookup, but does not necessarily have to match
anything in the CERT payload; both fields may be used by an
implementation to perform access control decisions. When using the
ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2
does not require this address to match the address in the IP header
of IKEv2 packets, or anything in the TSi/TSr payloads. The contents
of IDi/IDr are used purely to fetch the policy and authentication
data related to the other party.

NOTE: In IKEv1, two ID payloads were used in each direction to hold
Traffic Selector (TS) information for data passing over the SA. In
IKEv2, this information is carried in TS payloads (see Section 3.13).

The Peer Authorization Database (PAD) as described in RFC 4301
[IPSECARCH] describes the use of the ID payload in IKEv2 and provides
a formal model for the binding of identity to policy in addition to
providing services that deal more specifically with the details of
policy enforcement. The PAD is intended to provide a link between
the SPD and the IKE Security Association management. See
Section 4.4.3 of RFC 4301 for more details.

The Identification payload consists of the IKE generic payload header
followed by identification fields as follows:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID Type | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Identification Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 11: Identification Payload Format

Kaufman, et al. Standards Track [Page 90]
RFC 7296 IKEv2bis October 2014

o ID Type (1 octet) - Specifies the type of Identification being
used.

o RESERVED - MUST be sent as zero; MUST be ignored on receipt.

o Identification Data (variable length) - Value, as indicated by the
Identification Type. The length of the Identification Data is
computed from the size in the ID payload header.

The payload types for the Identification payload are thirty-five (35)
for IDi and thirty-six (36) for IDr.

The following table lists the assigned semantics for the
Identification Type field. The values in the following table are
only current as of the publication date of RFC 4306. Other values
may have been added since then or will be added after the publication
of this document. Readers should refer to [IKEV2IANA] for the latest
values.

ID Type Value
-------------------------------------------------------------------
ID_IPV4_ADDR 1
A single four (4) octet IPv4 address.

ID_FQDN 2
A fully-qualified domain name string. An example of an ID_FQDN
is "example.com". The string MUST NOT contain any terminators
(e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII;
for an "internationalized domain name", the syntax is as defined
in [IDNA], for example "xn--tmonesimerkki-bfbb.example.net".

ID_RFC822_ADDR 3
A fully-qualified RFC 822 email address string. An example of a
ID_RFC822_ADDR is "jsmith@example.com". The string MUST NOT
contain any terminators. Because of [EAI], implementations would
be wise to treat this field as UTF-8 encoded text, not as
pure ASCII.

ID_IPV6_ADDR 5
A single sixteen (16) octet IPv6 address.

ID_DER_ASN1_DN 9
The binary Distinguished Encoding Rules (DER) encoding of an
ASN.1 X.500 Distinguished Name [PKIX].

ID_DER_ASN1_GN 10
The binary DER encoding of an ASN.1 X.509 GeneralName [PKIX].

Kaufman, et al. Standards Track [Page 91]
RFC 7296 IKEv2bis October 2014

ID_KEY_ID 11
An opaque octet stream that may be used to pass vendor-
specific information necessary to do certain proprietary
types of identification.

Two implementations will interoperate only if each can generate a
type of ID acceptable to the other. To assure maximum
interoperability, implementations MUST be configurable to send at
least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and
MUST be configurable to accept all of these four types.
Implementations SHOULD be capable of generating and accepting all of
these types. IPv6-capable implementations MUST additionally be
configurable to accept ID_IPV6_ADDR. IPv6-only implementations MAY
be configurable to send only ID_IPV6_ADDR instead of ID_IPV4_ADDR for
IP addresses.

EAP [EAP] does not mandate the use of any particular type of
identifier, but often EAP is used with Network Access Identifiers
(NAIs) defined in [NAI]. Although NAIs look a bit like email
addresses (e.g., "joe@example.com"), the syntax is not exactly the
same as the syntax of email address in [MAILFORMAT]. For those NAIs
that include the realm component, the ID_RFC822_ADDR identification
type SHOULD be used. Responder implementations should not attempt to
verify that the contents actually conform to the exact syntax given
in [MAILFORMAT], but instead should accept any reasonable-looking
NAI. For NAIs that do not include the realm component, the ID_KEY_ID
identification type SHOULD be used.

See "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and
PKIX" ([RFC4945]) for more information about matching Identification
payloads and the contents of the PKIX Certificates.

3.6. Certificate Payload

The Certificate payload, denoted CERT in this document, provides a
means to transport certificates or other authentication-related
information via IKE. Certificate payloads SHOULD be included in an
exchange if certificates are available to the sender. The Hash and
URL formats of the Certificate payloads should be used in case the
peer has indicated an ability to retrieve this information from
elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload. Note
that the term "Certificate payload" is somewhat misleading, because
not all authentication mechanisms use certificates and data other
than certificates may be passed in this payload.

Kaufman, et al. Standards Track [Page 92]
RFC 7296 IKEv2bis October 2014#x27; (default PHB) is
NOT RECOMMENDED for this PHB. This may cause effects that are in
contrast to the original intent in protecting BE traffic from LE
traffic (no harm property). In the case that a DS domain does not
support the LE PHB, its nodes SHOULD treat LE marked packets with the
default PHB instead (by mapping the LE DSCP to the default PHB), but
they SHOULD do so without remarking to DSCP '000000'. The reason for
this is that later traversed DS domains may then have still the
possibility to treat such packets according to the LE PHB.

Operators of DS domains that forward LE traffic within the BE
aggregate need to be aware of the implications, i.e., induced
congestion situations and quality-of-service degradation of the
original BE traffic. In this case, the LE property of not harming
other traffic is no longer fulfilled. To limit the impact in such
cases, traffic policing of the LE aggregate MAY be used.

In case LE marked packets are effectively carried within the default
PHB (i.e., forwarded as best-effort traffic) they get a better
forwarding treatment than expected. For some applications and
services, it is favorable if the transmission is finished earlier
than expected. However, in some cases it may be against the original
intention of the LE PHB user to strictly send the traffic only if
otherwise unused resources are available. In case LE traffic is
mapped to the default PHB, LE traffic may compete with BE traffic for
the same resources and thus adversely affect the original BE
aggregate. Applications that want to ensure the lower precedence
compared to BE traffic even in such cases SHOULD use additionally a
corresponding Lower-than-Best-Effort transport protocol [RFC6297],
e.g., LEDBAT [RFC6817].

Bless Expires August 3, 2019 [Page 8]
Internet-Draft Lower Effort PHB January 2019

A DS domain that still uses DSCP CS1 for marking LE traffic
(including Low Priority-Data as defined in [RFC4594] or the old
definition in [RFC3662]) SHOULD remark traffic to the LE DSCP
'000001' at the egress to the next DS domain. This increases the
probability that the DSCP is preserved end-to-end, whereas a CS1
marked packet may be remarked by the default DSCP if the next domain
is applying Diffserv-intercon [RFC8100].

9. Multicast Considerations

Basically the multicast considerations in [RFC3754] apply. However,
using the Lower Effort PHB for multicast requires to pay special
attention to the way how packets get replicated inside routers. Due
to multicast packet replication, resource contention may actually
occur even before a packet is forwarded to its output port and in the
worst case, these forwarding resources are missing for higher
prioritized multicast or even unicast packets.

Several forwarding error correction coding schemes such as fountain
codes (e.g., [RFC5053]) allow reliable data delivery even in
environments with a potential high amount of packet loss in
transmission. When used for example over satellite links or other
broadcast media, this means that receivers that lose 80% of packets
in transmission simply need 5 times as long to receive the complete
data than those receivers experiencing no loss (without any receiver
feedback required).

Superficially viewed, it may sound very attractive to use IP
multicast with the LE PHB to build this type of opportunistic
reliable distribution in IP networks, but it can only be usefully
deployed with routers that do not experience forwarding/replication
resource starvation when a large amount of packets (virtually) need
to be replicated to links where the LE queue is full.

Thus, packet replication of LE marked packets should consider the
situation at the respective output links: it is a waste of internal
forwarding resources if a packet is replicated to output links that
have no resources left for LE forwarding. In those cases a packet
would have been replicated just to be dropped immediately after
finding a filled LE queue at the respective output port. Such
behavior could be avoided for example by using a conditional internal
packet replication: a packet would then only be replicated in case
the output link is not fully used. This conditional replication,
however, is probably not widely implemented.

While the resource contention problem caused by multicast packet
replication is also true for other Diffserv PHBs, LE forwarding is
special, because often it is assumed that LE packets get only

Bless Expires August 3, 2019 [Page 9]
Internet-Draft Lower Effort PHB January 2019

forwarded in case of available resources at the output ports. The
previously mentioned redundancy data traffic could nicely use the
varying available residual bandwidth being utilized the by LE PHB,
but only if the previously specific requirements in the internal
implementation of the network devices are considered.

10. The Update to RFC 4594

[RFC4594] recommended to use CS1 as codepoint in section 4.10,
whereas CS1 was defined in [RFC2474] to have a higher precedence than
CS0, i.e., the default PHB. Consequently, Diffserv domains
implementing CS1 according to [RFC2474] will cause a priority
inversion for LE packets that contradicts with the original purpose
of LE. Therefore, every occurrence of the CS1 DSCP is replaced by
the LE DSCP.

Changes:

o This update to RFC 4594 removes the following entry from figure 3:

|---------------+---------+-------------+--------------------------|
| Low-Priority | CS1 | 001000 | Any flow that has no BW |
| Data | | | assurance |
------------------------------------------------------------------

and replaces this by the following entry:

|---------------+---------+-------------+--------------------------|
| Low-Priority | LE | 000001 | Any flow that has no BW |
| Data | | | assurance |
------------------------------------------------------------------

o This update to RFC 4594 extends the Notes text below figure 3 that
currently states "Notes for Figure 3: Default Forwarding (DF) and
Class Selector 0 (CS0) provide equivalent behavior and use the
same DS codepoint, '000000'." to state "Notes for Figure 3:
Default Forwarding (DF) and Class Selector 0 (CS0) provide
equivalent behavior and use the same DS codepoint, '000000'. The
prior recommendation to use the CS1 DSCP for Low-Priority Data has
been replaced by the current recommendation to use the LE DSCP,
'000001'."

o This update to RFC 4594 removes the following entry from figure 4:

|---------------+------+-------------------+---------+--------+----|
| Low-Priority | CS1 | Not applicable | RFC3662 | Rate | Yes|
| Data | | | | | |
------------------------------------------------------------------

Bless Expires August 3, 2019 [Page 10]
Internet-Draft Lower Effort PHB January 2019

and replaces this by the following entry:

|---------------+------+-------------------+---------+--------+----|
| Low-Priority | LE | Not applicable | RFCXXXX | Rate | Yes|
| Data | | | | | |
------------------------------------------------------------------

o Section 2.3 of [RFC4594] specifies: "In network segments that use
IP precedence marking, only one of the two service classes can be
supported, High-Throughput Data or Low-Priority Data. We
RECOMMEND that the DSCP value(s) of the unsupported service class
be changed to 000xx1 on ingress and changed back to original
value(s) on egress of the network segment that uses precedence
marking. For example, if Low-Priority Data is mapped to Standard
service class, then 000001 DSCP marking MAY be used to distinguish
it from Standard marked packets on egress." This document removes
this recommendation, because by using the herein defined LE DSCP
such remarking is not necessary. So even if Low-Priority Data is
unsupported (i.e., mapped to the default PHB) the LE DSCP should
be kept across the domain as RECOMMENDED in Section 8. That
removed text is replaced by: "In network segments that use IP
Precedence marking, the Low-Priority Data service class receives
the same Diffserv QoS as the Standard service class when the LE
DSCP is used for Low-Priority Data traffic. This is acceptable
behavior for the Low-Priority Data service class, although it is
not the preferred behavior."

o This document removes the following line of RFC 4594,
Section 4.10: "The RECOMMENDED DSCP marking is CS1 (Class Selector
1)." and replaces this with the following text: "The RECOMMENDED
DSCP marking is LE (Lower Effort), which replaces the prior
recommendation for CS1 (Class Selector 1) marking."

11. The Update to RFC 8325

Section 4.2.10 of RFC 8325 [RFC8325] specifies "[RFC3662] and
[RFC4594] both recommend Low-Priority Data be marked CS1 DSCP."
which is updated to "[RFC3662] recommends that Low-Priority Data be
marked CS1 DSCP. [RFC4594] as updated by [RFCXXXX] recommends Low-
Priority Data be marked LE DSCP."

This document removes the following paragraph of RFC 8325,
Section 4.2.10 because this document makes the anticipated change:
"Note: This marking recommendation may change in the future, as [LE-
PHB] defines a Lower Effort (LE) PHB for Low-Priority Data traffic
and recommends an additional DSCP for this traffic."

Bless Expires August 3, 2019 [Page 11]
Internet-Draft Lower Effort PHB January 2019

Section 4.2.10 of RFC 8325 [RFC8325] specifies "therefore, it is
RECOMMENDED to map Low-Priority Data traffic marked CS1 DSCP to UP 1"
which is updated to "therefore, it is RECOMMENDED to map Low-Priority
Data traffic marked with LE DSCP or legacy CS1 DSCP to UP 1"

This update to RFC 8325 replaces the following entry from figure 1:

+---------------+------+----------+-------------+--------------------+
| Low-Priority | CS1 | RFC 3662 | 1 | AC_BK (Background) |
| Data | | | | |
+--------------------------------------------------------------------+

by the following entries:

+---------------+------+----------+-------------+--------------------+
| Low-Priority | LE | RFCXXXX | 1 | AC_BK (Background) |
| Data | | | | |
+--------------------------------------------------------------------+
| Low-Priority | CS1 | RFC 3662 | 1 | AC_BK (Background) |
| Data (legacy) | | | | |
+--------------------------------------------------------------------+

12. The Update to draft-ietf-tsvwg-rtcweb-qos

Section 5 of [I-D.ietf-tsvwg-rtcweb-qos] describes the Recommended
DSCP Values for WebRTC Applications

This update to [I-D.ietf-tsvwg-rtcweb-qos] replaces all occurrences
of CS1 with LE in Table 1:

+------------------------+-------+------+-------------+-------------+
| Flow Type | Very | Low | Medium | High |
| | Low | | | |
+------------------------+-------+------+-------------+-------------+
| Audio | LE | DF | EF (46) | EF (46) |
| | (1) | (0) | | |
| | | | | |
| Interactive Video with | LE | DF | AF42, AF43 | AF41, AF42 |
| or without Audio | (1) | (0) | (36, 38) | (34, 36) |
| | | | | |
| Non-Interactive Video | LE | DF | AF32, AF33 | AF31, AF32 |
| with or without Audio | (1) | (0) | (28, 30) | (26, 28) |
| | | | | |
| Data | LE | DF | AF11 | AF21 |
| | (1) | (0) | | |
+------------------------+-------+------+-------------+-------------+

and updates the following paragraph:

Bless Expires August 3, 2019 [Page 12]
Internet-Draft Lower Effort PHB January 2019

"The above table assumes that packets marked with CS1 are treated as
"less than best effort", such as the LE behavior described in
[RFC3662]. However, the treatment of CS1 is implementation
dependent. If an implementation treats CS1 as other than "less than
best effort", then the actual priority (or, more precisely, the per-
hop-behavior) of the packets may be changed from what is intended.
It is common for CS1 to be treated the same as DF, so applications
and browsers using CS1 cannot assume that CS1 will be treated
differently than DF [RFC7657]. However, it is also possible per
[RFC2474] for CS1 traffic to be given better treatment than DF, thus
caution should be exercised when electing to use CS1. This is one of
the cases where marking packets using these recommendations can make
things worse."

as follows:

"The above table assumes that packets marked with LE are treated as
lower effort (i.e., "less than best effort"), such as the LE behavior
described in [RFCXXXX]. However, the treatment of LE is
implementation dependent. If an implementation treats LE as other
than "less than best effort", then the actual priority (or, more
precisely, the per- hop-behavior) of the packets may be changed from
what is intended. It is common for LE to be treated the same as DF,
so applications and browsers using LE cannot assume that LE will be
treated differently than DF [RFC7657]. During development of this
document, the CS1 DSCP was recommended for "very low" application
priority traffic; implementations that followed that recommendation
SHOULD be updated to use the LE DSCP instead of the CS1 DSCP."

13. IANA Considerations

This document assigns the Differentiated Services Field Codepoint
(DSCP) '000001' from the Differentiated Services Field Codepoints
(DSCP) registry (https://www.iana.org/assignments/dscp-registry/dscp-
registry.xhtml) (Pool 3, Codepoint Space xxxx01, Standards Action) to
the LE PHB. This document suggests to use a DSCP from Pool 3 in
order to avoid problems for other PHB marked flows to become
accidentally remarked as LE PHB, e.g., due to partial DSCP bleaching.
See [RFC8436] for re-classifying Pool 3 for Standards Action.

IANA is requested to update the registry as follows:

o Name: LE

o Value (Binary): 000001

o Value (Decimal): 1

Bless Expires August 3, 2019 [Page 13]
Internet-Draft Lower Effort PHB January 2019

o Reference: [RFC number of this memo]

14. Security Considerations

There are no specific security exposures for this PHB. Since it
defines a new class of low forwarding priority, remarking other
traffic as LE traffic may lead to quality-of-service degradation of
such traffic. Thus, any attacker that is able to modify the DSCP of
a packet to LE may carry out a downgrade attack. See the general
security considerations in [RFC2474] and [RFC2475].

With respect to privacy, an attacker could use the information from
the DSCP to infer that the transferred (probably even encrypted)
content is considered of low priority or low urgency by a user, in
case the DSCP was set on the user's request. However, this disclosed
information is only useful if some form of identification happened at
the same time, see [RFC6973] for further details on general privacy
threats.

15. References

15.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
DOI 10.17487/RFC2474, December 1998,
<http://www.rfc-editor.org/info/rfc2474>.

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<http://www.rfc-editor.org/info/rfc2475>.

15.2. Informative References

[carlberg-lbe-2001]
Carlberg, K., Gevros, P., and J. Crowcroft, "Lower than
best effort: a design and implementation", SIGCOMM
Computer Communications Review Volume 31, Issue 2
supplement, April 2001,
<https://doi.org/10.1145/844193.844208>.

Bless Expires August 3, 2019 [Page 14]
Internet-Draft Lower Effort PHB January 2019

[chown-lbe-2003]
Chown, T., Ferrari, T., Leinen, S., Sabatino, R., Simar,
N., and S. Venaas, "Less than Best Effort: Application
Scenarios and Experimental Results", In Proceedings of the
Second International Workshop on Quality of Service in
Multiservice IP Networks (QoS-IP 2003), Lecture Notes in
Computer Science, vol 2601. Springer, Berlin,
Heidelberg Pages 131-144, February 2003,
<https://doi.org/10.1007/3-540-36480-3_10>.

[draft-bless-diffserv-lbe-phb-00]
Bless, R. and K. Wehrle, "A Lower Than Best-Effort Per-Hop
Behavior", draft-bless-diffserv-lbe-phb-00 (work in
progress), September 1999, <https://tools.ietf.org/html/
draft-bless-diffserv-lbe-phb-00&

The Certificate payload is defined as follows:

Figure 12: Certificate Payload Format

o Certificate Encoding (1 octet) - This field indicates the type of
certificate or certificate-related information contained in the
Certificate Data field. The values in the following table are
only current as of the publication date of RFC 4306. Other values
may have been added since then or will be added after the
publication of this document. Readers should refer to [IKEV2IANA]
for the latest values.

Certificate Encoding Value
----------------------------------------------------
PKCS #7 wrapped X.509 certificate 1 UNSPECIFIED
PGP Certificate 2 UNSPECIFIED
DNS Signed Key 3 UNSPECIFIED
X.509 Certificate - Signature 4
Kerberos Token 6 UNSPECIFIED
Certificate Revocation List (CRL) 7
Authority Revocation List (ARL) 8 UNSPECIFIED
SPKI Certificate 9 UNSPECIFIED
X.509 Certificate - Attribute 10 UNSPECIFIED
Deprecated (was Raw RSA Key) 11 DEPRECATED
Hash and URL of X.509 certificate 12
Hash and URL of X.509 bundle 13

o Certificate Data (variable length) - Actual encoding of
certificate data. The type of certificate is indicated by the
Certificate Encoding field.

The payload type for the Certificate payload is thirty-seven (37).

Kaufman, et al. Standards Track [Page 93]
RFC 7296 IKEv2bis October 2014

Specific syntax for some of the certificate type codes above is not
defined in this document. The types whose syntax is defined in this
document are:

o "X.509 Certificate - Signature" contains a DER-encoded X.509
certificate whose public key is used to validate the sender's AUTH
payload. Note that with this encoding, if a chain of certificates
needs to be sent, multiple CERT payloads are used, only the first
of which holds the public key used to validate the sender's AUTH
payload.

o "Certificate Revocation List" contains a DER-encoded X.509
certificate revocation list.

o Hash and URL encodings allow IKE messages to remain short by
replacing long data structures with a 20-octet SHA-1 hash (see
[FIPS.180-4.2012]) of the replaced value followed by a variable-
length URL that resolves to the DER-encoded data structure itself.
This improves efficiency when the endpoints have certificate data
cached and makes IKE less subject to DoS attacks that become
easier to mount when IKE messages are large enough to require IP
fragmentation [DOSUDPPROT].

The "Hash and URL of a bundle" type uses the following ASN.1
definition for the X.509 bundle:

CertBundle
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-cert-bundle(34) }

DEFINITIONS EXPLICIT TAGS ::=
BEGIN

IMPORTS
Certificate, CertificateList
FROM PKIX1Explicit88
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7)
id-mod(0) id-pkix1-explicit(18) } ;

CertificateOrCRL ::= CHOICE {
cert [0] Certificate,
crl [1] CertificateList }

CertificateBundle ::= SEQUENCE OF CertificateOrCRL

END

Kaufman, et al. Standards Track [Page 94]
RFC 7296 IKEv2bis October 2014

Implementations MUST be capable of being configured to send and
accept up to four X.509 certificates in support of authentication,
and also MUST be capable of being configured to send and accept the
two Hash and URL formats (with HTTP URLs). If multiple certificates
are sent, the first certificate MUST contain the public key
associated with the private key used to sign the AUTH payload. The
other certificates may be sent in any order.

Implementations MUST support the "http:" scheme for hash-and-URL
lookup. The behavior of other URL schemes [URLS] is not currently
specified, and such schemes SHOULD NOT be used in the absence of a
document specifying them.

3.7. Certificate Request Payload

The Certificate Request payload, denoted CERTREQ in this document,
provides a means to request preferred certificates via IKE and can
appear in the IKE_INIT_SA response and/or the IKE_AUTH request.
Certificate Request payloads MAY be included in an exchange when the
sender needs to get the certificate of the receiver.

The Certificate Request payload is defined as follows:

Figure 13: Certificate Request Payload Format

o Certificate Encoding (1 octet) - Contains an encoding of the type
or format of certificate requested. Values are listed in
Section 3.6.

o Certification Authority (variable length) - Contains an encoding
of an acceptable certification authority for the type of
certificate requested.

The payload type for the Certificate Request payload is
thirty-eight (38).

Kaufman, et al. Standards Track [Page 95]
RFC 7296 IKEv2bis October 2014

The Certificate Encoding field has the same values as those defined
in Section 3.6. The Certification Authority field contains an
indicator of trusted authorities for this certificate type. The
Certification Authority value is a concatenated list of SHA-1 hashes
of the public keys of trusted Certification Authorities (CAs). Each
is encoded as the SHA-1 hash of the Subject Public Key Info element
(see Section 4.1.2.7 of [PKIX]) from each Trust Anchor certificate.
The 20-octet hashes are concatenated and included with no other
formatting.

The contents of the Certification Authority field are defined only
for X.509 certificates, which are types 4, 12, and 13. Other values
SHOULD NOT be used until Standards-Track specifications that specify
their use are published.

Note that the term "Certificate Request" is somewhat misleading, in
that values other than certificates are defined in a "Certificate"
payload and requests for those values can be present in a Certificate
Request payload. The syntax of the Certificate Request payload in
such cases is not defined in this document.

The Certificate Request payload is processed by inspecting the
Cert Encoding field to determine whether the processor has any
certificates of this type. If so, the Certification Authority field
is inspected to determine if the processor has any certificates that
can be validated up to one of the specified certification
authorities. This can be a chain of certificates.

If an end-entity certificate exists that satisfies the criteria
specified in the CERTREQ, a certificate or certificate chain SHOULD
be sent back to the certificate requestor if the recipient of the
CERTREQ:

o is configured to use certificate authentication,

o is allowed to send a CERT payload,

o has matching CA trust policy governing the current negotiation,
and

o has at least one time-wise and usage-appropriate end-entity
certificate chaining to a CA provided in the CERTREQ.

Certificate revocation checking must be considered during the
chaining process used to select a certificate. Note that even if two
peers are configured to use two different CAs, cross-certification
relationships should be supported by appropriate selection logic.

Kaufman, et al. Standards Track [Page 96]
RFC 7296 IKEv2bis October 2014

The intent is not to prevent communication through the strict
adherence of selection of a certificate based on CERTREQ, when an
alternate certificate could be selected by the sender that would
still enable the recipient to successfully validate and trust it
through trust conveyed by cross-certification, CRLs, or other
out-of-band configured means. Thus, the processing of a CERTREQ
should be seen as a suggestion for a certificate to select, not a
mandated one. If no certificates exist, then the CERTREQ is ignored.
This is not an error condition of the protocol. There may be cases
where there is a preferred CA sent in the CERTREQ, but an alternate
might be acceptable (perhaps after prompting a human operator).

The HTTP_CERT_LOOKUP_SUPPORTED notification MAY be included in any
message that can include a CERTREQ payload and indicates that the
sender is capable of looking up certificates based on an HTTP-based
URL (and hence presumably would prefer to receive certificate
specifications in that format).

3.8. Authentication Payload

The Authentication payload, denoted AUTH in this document, contains
data used for authentication purposes. The syntax of the
Authentication Data varies according to the Auth Method as specified
below.

The Authentication payload is defined as follows:

Figure 14: Authentication Payload Format

o Auth Method (1 octet) - Specifies the method of authentication
used. The types of signatures are listed here. The values in the
following table are only current as of the publication date of
RFC 4306. Other values may have been added since then or will be
added after the publication of this document. Readers should
refer to [IKEV2IANA] for the latest values.

Kaufman, et al. Standards Track [Page 97]
RFC 7296 IKEv2bis October 2014

Mechanism Value
-----------------------------------------------------------------
RSA Digital Signature 1
Computed as specified in Section 2.15 using an RSA private key
with RSASSA-PKCS1-v1_5 signature scheme specified in [PKCS1]
(implementers should note that IKEv1 used a different method for
RSA signatures). To promote interoperability, implementations
that support this type SHOULD support signatures that use SHA-1
as the hash function and SHOULD use SHA-1 as the default hash
function when generating signatures. Implementations can use the
certificates received from a given peer as a hint for selecting a
mutually understood hash function for the AUTH payload signature.
Note, however, that the hash algorithm used in the AUTH payload
signature doesn't have to be the same as any hash algorithm(s)
used in the certificate(s).

Shared Key Message Integrity Code 2
Computed as specified in Section 2.15 using the shared key
associated with the identity in the ID payload and the
negotiated PRF.

DSS Digital Signature 3
Computed as specified in Section 2.15 using a DSS private key
(see [DSS]) over a SHA-1 hash.

o RESERVED - MUST be sent as zero; MUST be ignored on receipt.

o Authentication Data (variable length) - see Section 2.15.

The payload type for the Authentication payload is thirty-nine (39).

3.9. Nonce Payload

The Nonce payload, denoted as Ni and Nr in this document for the
initiator's and responder's nonce, respectively, contains random data
used to guarantee liveness during an exchange and protect against
replay attacks.

Kaufman, et al. Standards Track [Page 98]
RFC 7296 IKEv2bis October 2014

The Nonce payload is defined as follows:

Figure 15: Nonce Payload Format

o Nonce Data (variable length) - Contains the random data generated
by the transmitting entity.

The payload type for the Nonce payload is forty (40).

The size of the Nonce Data MUST be between 16 and 256 octets,
inclusive. Nonce values MUST NOT be reused.

3.10. Notify Payload

The Notify payload, denoted N in this document, is used to transmit
informational data, such as error conditions and state transitions,
to an IKE peer. A Notify payload may appear in a response message
(usually specifying why a request was rejected), in an INFORMATIONAL
exchange (to report an error not in an IKE request), or in any other
message to indicate sender capabilities or to modify the meaning of
the request.

Kaufman, et al. Standards Track [Page 99]
RFC 7296 IKEv2bis October 2014

gt;.

[I-D.ietf-tsvwg-rtcweb-qos]
Jones, P., Dhesikan, S., Jennings, C., and D. Druta, "DSCP
Packet Markings for WebRTC QoS", draft-ietf-tsvwg-rtcweb-
qos-18 (work in progress), August 2016.

[ietf99-secchi]
Secchi, R., Venne, A., and A. Custura, "Measurements
concerning the DSCP for a LE PHB", Presentation held at
99th IETF Meeting, TSVWG, Prague , July 2017,
<https://datatracker.ietf.org/meeting/99/materials/slides-
99-tsvwg-sessb-31measurements-concerning-the-dscp-for-a-
le-phb-00>.

[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, DOI 10.17487/RFC2914, September 2000,
<https://www.rfc-editor.org/info/rfc2914>.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, DOI 10.17487/RFC3168, September 2001,
<http://www.rfc-editor.org/info/rfc3168>.

[RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural
Guidelines and Philosophy", RFC 3439,
DOI 10.17487/RFC3439, December 2002,
<https://www.rfc-editor.org/info/rfc3439>.

[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
Per-Domain Behavior (PDB) for Differentiated Services",
RFC 3662, DOI 10.17487/RFC3662, December 2003,
<http://www.rfc-editor.org/info/rfc3662>.

Bless Expires August 3, 2019 [Page 15]
Internet-Draft Lower Effort PHB January 2019

[RFC3754] Bless, R. and K. Wehrle, "IP Multicast in Differentiated
Services (DS) Networks", RFC 3754, DOI 10.17487/RFC3754,
April 2004, <http://www.rfc-editor.org/info/rfc3754>.

[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594,
DOI 10.17487/RFC4594, August 2006,
<http://www.rfc-editor.org/info/rfc4594>.

[RFC5053] Luby, M., Shokrollahi, A., Watson, M., and T. Stockhammer,
"Raptor Forward Error Correction Scheme for Object
Delivery", RFC 5053, DOI 10.17487/RFC5053, October 2007,
<https://www.rfc-editor.org/info/rfc5053>.

[RFC6297] Welzl, M. and D. Ros, "A Survey of Lower-than-Best-Effort
Transport Protocols", RFC 6297, DOI 10.17487/RFC6297, June
2011, <http://www.rfc-editor.org/info/rfc6297>.

[RFC6817] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind,
"Low Extra Delay Background Transport (LEDBAT)", RFC 6817,
DOI 10.17487/RFC6817, December 2012,
<http://www.rfc-editor.org/info/rfc6817>.

[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.

[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.

[RFC8100] Geib, R., Ed. and D. Black, "Diffserv-Interconnection
Classes and Practice", RFC 8100, DOI 10.17487/RFC8100,
March 2017, <http://www.rfc-editor.org/info/rfc8100>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8325] Szigeti, T., Henry, J., and F. Baker, "Mapping Diffserv to
IEEE 802.11", RFC 8325, DOI 10.17487/RFC8325, February
2018, <https://www.rfc-editor.org/info/rfc8325>.

Bless Expires August 3, 2019 [Page 16]
Internet-Draft Lower Effort PHB January 2019

[RFC8436] Fairhurst, G., "Update to IANA Registration Procedures for
Pool 3 Values in the Differentiated Services Field
Codepoints (DSCP) Registry", RFC 8436,
DOI 10.17487/RFC8436, August 2018,
<https://www.rfc-editor.org/info/rfc8436>.

Appendix A. History of the LE PHB

A first version of this PHB was suggested by Roland Bless and Klaus
Wehrle in September 1999 [draft-bless-diffserv-lbe-phb-00], named "A
Lower Than Best-Effort Per-Hop Behavior". After some discussion in
the Diffserv Working Group Brian Carpenter and Kathie Nichols
proposed a "bulk handling" per-domain behavior and believed a PHB was
not necessary. Eventually, "Lower Effort" was specified as per-
domain behavior and finally became [RFC3662]. More detailed
information about its history can be found in Section 10 of
[RFC3662].

There are several other names in use for this type of PHB or
associated service classes. Well-known is the QBone Scavenger
Service (QBSS) that was proposed in March 2001 within the Internet2
QoS Working Group. Alternative names are "Lower-than-best-effort"
[carlberg-lbe-2001] or "Less-than-best-effort" [chown-lbe-2003].

The Notify payload is defined as follows:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | SPI Size | Notify Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Security Parameter Index (SPI) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Notification Data ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 16: Notify Payload Format

o Protocol ID (1 octet) - If this notification concerns an existing
SA whose SPI is given in the SPI field, this field indicates the
type of that SA. For notifications concerning Child SAs, this
field MUST contain either (2) to indicate AH or (3) to indicate
ESP. Of the notifications defined in this document, the SPI is
included only with INVALID_SELECTORS, REKEY_SA, and
CHILD_SA_NOT_FOUND. If the SPI field is empty, this field MUST be
sent as zero and MUST be ignored on receipt.

o SPI Size (1 octet) - Length in octets of the SPI as defined by the
IPsec protocol ID or zero if no SPI is applicable. For a
notification concerning the IKE SA, the SPI Size MUST be zero and
the field must be empty.

o Notify Message Type (2 octets) - Specifies the type of
notification message.

o SPI (variable length) - Security Parameter Index.

o Notification Data (variable length) - Status or error data
transmitted in addition to the Notify Message Type. Values for
this field are type specific (see below).

The payload type for the Notify payload is forty-one (41).

Kaufman, et al. Standards Track [Page 100]
RFC 7296 IKEv2bis October 2014

3.10.1. Notify Message Types

Notification information can be error messages specifying why an SA
could not be established. It can also be status data that a process
managing an SA database wishes to communicate with a peer process.

The table below lists the notification messages and their
corresponding values. The number of different error statuses was
greatly reduced from IKEv1 both for simplification and to avoid
giving configuration information to probers.

Types in the range 0 - 16383 are intended for reporting errors. An
implementation receiving a Notify payload with one of these types
that it does not recognize in a response MUST assume that the
corresponding request has failed entirely. Unrecognized error types
in a request and status types in a request or response MUST be
ignored, and they should be logged.

Notify payloads with status types MAY be added to any message and
MUST be ignored if not recognized. They are intended to indicate
capabilities, and as part of SA negotiation, are used to negotiate
non-cryptographic parameters.

More information on error handling can be found in Section 2.21.

The values in the following table are only current as of the
publication date of RFC 4306, plus two error types added in this
document. Other values may have been added since then or will be
added after the publication of this document. Readers should refer
to [IKEV2IANA] for the latest values.

NOTIFY messages: error types Value
-------------------------------------------------------------------
UNSUPPORTED_CRITICAL_PAYLOAD 1
See Section 2.5.

INVALID_IKE_SPI 4
See Section 2.21.

INVALID_MAJOR_VERSION 5
See Section 2.5.

INVALID_SYNTAX 7
Indicates the IKE message that was received was invalid because
some type, length, or value was out of range or because the
request was rejected for policy reasons. To avoid a DoS
attack using forged messages, this status may only be
returned for and in an encrypted packet if the Message ID and

Kaufman, et al. Standards Track [Page 101]
RFC 7296 IKEv2bis October 2014

cryptographic checksum were valid. To avoid leaking information
to someone probing a node, this status MUST be sent in response
to any error not covered by one of the other status types.
To aid debugging, more detailed error information should be
written to a console or log.

INVALID_MESSAGE_ID 9
See Section 2.3.

INVALID_SPI 11
See Section 1.5.

NO_PROPOSAL_CHOSEN 14
None of the proposed crypto suites was acceptable. This can be
sent in any case where the offered proposals (including but not
limited to SA payload values, USE_TRANSPORT_MODE notify,
IPCOMP_SUPPORTED notify) are not acceptable for the responder.
This can also be used as "generic" Child SA error when Child SA
cannot be created for some other reason. See also Section 2.7.

INVALID_KE_PAYLOAD 17
See Sections 1.2 and 1.3.

AUTHENTICATION_FAILED 24
Sent in the response to an IKE_AUTH message when, for some
reason, the authentication failed. There is no associated
data. See also Section 2.21.2.

SINGLE_PAIR_REQUIRED 34
See Section 2.9.

NO_ADDITIONAL_SAS 35
See Section 1.3.

INTERNAL_ADDRESS_FAILURE 36
See Section 3.15.4.

FAILED_CP_REQUIRED 37
See Section 2.19.

TS_UNACCEPTABLE 38
See Section 2.9.

Kaufman, et al. Standards Track [Page 102]
RFC 7296 IKEv2bis October 2014

INVALID_SELECTORS 39
MAY be sent in an IKE INFORMATIONAL exchange when a node receives
an ESP or AH packet whose selectors do not match those of the SA
on which it was delivered (and that caused the packet to be
dropped). The Notification Data contains the start of the
offending packet (as in ICMP messages) and the SPI field of the
notification is set to match the SPI of the Child SA.

TEMPORARY_FAILURE 43
See Section 2.25.

CHILD_SA_NOT_FOUND 44
See Section 2.25.

NOTIFY messages: status types Value
-------------------------------------------------------------------
INITIAL_CONTACT 16384
See Section 2.4.

SET_WINDOW_SIZE 16385
See Section 2.3.

ADDITIONAL_TS_POSSIBLE 16386
See Section 2.9.

IPCOMP_SUPPORTED 16387
See Section 2.22.

NAT_DETECTION_SOURCE_IP 16388
See Section 2.23.

NAT_DETECTION_DESTINATION_IP 16389
See Section 2.23.

COOKIE 16390
See Section 2.6.

USE_TRANSPORT_MODE 16391
See Section 1.3.1.

HTTP_CERT_LOOKUP_SUPPORTED 16392
See Section 3.6.

REKEY_SA 16393
See Section 1.3.3.

Kaufman, et al. Standards Track [Page 103]
RFC 7296 IKEv2bis October 2014

ESP_TFC_PADDING_NOT_SUPPORTED 16394
See Section 1.3.1.

NON_FIRST_FRAGMENTS_ALSO 16395
See Section 1.3.1.

3.11. Delete Payload

The Delete payload, denoted D in this document, contains a
protocol-specific Security Association identifier that the sender has
removed from its Security Association database and is, therefore, no
longer valid. Figure 17 shows the format of the Delete payload. It
is possible to send multiple SPIs in a Delete payload; however, each
SPI MUST be for the same protocol. Mixing of protocol identifiers
MUST NOT be performed in the Delete payload. It is permitted,
however, to include multiple Delete payloads in a single
INFORMATIONAL exchange where each Delete payload lists SPIs for a
different protocol.

Deletion of the IKE SA is indicated by a protocol ID of 1 (IKE) but
no SPIs. Deletion of a Child SA, such as ESP or AH, will contain the
IPsec protocol ID of that protocol (2 for AH, 3 for ESP), and the SPI
is the SPI the sending endpoint would expect in inbound ESP or AH
packets.

The Delete payload is defined as follows:

Figure 17: Delete Payload Format

o Protocol ID (1 octet) - Must be 1 for an IKE SA, 2 for AH, or 3
for ESP.

o SPI Size (1 octet) - Length in octets of the SPI as defined by the
protocol ID. It MUST be zero for IKE (SPI is in message header)
or four for AH and ESP.

Kaufman, et al. Standards Track [Page 104]
RFC 7296 IKEv2bis October 2014

o Num of SPIs (2 octets, unsigned integer) - The number of SPIs
contained in the Delete payload. The size of each SPI is defined
by the SPI Size field.

o Security Parameter Index(es) (variable length) - Identifies the
specific Security Association(s) to delete. The length of this
field is determined by the SPI Size and Num of SPIs fields.

The payload type for the Delete payload is forty-two (42).

3.12. Vendor ID Payload

The Vendor ID payload, denoted V in this document, contains a vendor-
defined constant. The constant is used by vendors to identify and
recognize remote instances of their implementations. This mechanism
allows a vendor to experiment with new features while maintaining
backward compatibility.

A Vendor ID payload MAY announce that the sender is capable of
accepting certain extensions to the protocol, or it MAY simply
identify the implementation as an aid in debugging. A Vendor ID
payload MUST NOT change the interpretation of any information defined
in this specification (i.e., the critical bit MUST be set to 0).
Multiple Vendor ID payloads MAY be sent. An implementation is not
required to send any Vendor ID payload at all.

A Vendor ID payload may be sent as part of any message. Reception of
a familiar Vendor ID payload allows an implementation to make use of
private use numbers described throughout this document, such as
private payloads, private exchanges, private notifications, etc.
Unfamiliar Vendor IDs MUST be ignored.

Writers of documents who wish to extend this protocol MUST define a
Vendor ID payload to announce the ability to implement the extension
in the document. It is expected that documents that gain acceptance
and are standardized will be given "magic numbers" out of the Future
Use range by IANA, and the requirement to use a Vendor ID will go
away.

Kaufman, et al. Standards Track [Page 105]
RFC 7296 IKEv2bis October 2014

The Vendor ID payload fields are defined as follows:

Figure 18: Vendor ID Payload Format

o Vendor ID (variable length) - It is the responsibility of the
person choosing the Vendor ID to assure its uniqueness in spite of
the absence of any central registry for IDs. Good practice is to
include a company name, a person name, or some such information.
If you want to show off, you might include the latitude and
longitude and time where you were when you chose the ID and some
random input. A message digest of a long unique string is
preferable to the long unique string itself.

The payload type for the Vendor ID payload is forty-three (43).

3.13. Traffic Selector Payload

The Traffic Selector payload, denoted TS in this document, allows
peers to identify packet flows for processing by IPsec security
services. The Traffic Selector payload consists of the IKE generic
payload header followed by individual Traffic Selectors as follows:

Figure 19: Traffic Selectors Payload Format

o Number of TSs (1 octet) - Number of Traffic Selectors being
provided.

Kaufman, et al. Standards Track [Page 106]
RFC 7296 IKEv2bis October 2014

o RESERVED - This field MUST be sent as zero and MUST be ignored on
receipt.

o Traffic Selectors (variable length) - One or more individual
Traffic Selectors.

The length of the Traffic Selector payload includes the TS header and
all the Traffic Selectors.

The payload type for the Traffic Selector payload is forty-four (44)
for addresses at the initiator's end of the SA and forty-five (45)
for addresses at the responder's end.

There is no requirement that TSi and TSr contain the same number of
individual Traffic Selectors. Thus, they are interpreted as follows:
a packet matches a given TSi/TSr if it matches at least one of the
individual selectors in TSi, and at least one of the individual
selectors in TSr.

For instance, the following Traffic Selectors:

TSi = ((17, 100, 198.51.100.66-198.51.100.66),
(17, 200, 198.51.100.66-198.51.100.66))
TSr = ((17, 300, 0.0.0.0-255.255.255.255),
(17, 400, 0.0.0.0-255.255.255.255))

would match UDP packets from 198.51.100.66 to anywhere, with any of
the four combinations of source/destination ports (100,300),
(100,400), (200,300), and (200, 400).

Thus, some types of policies may require several Child SA pairs. For
instance, a policy matching only source/destination ports (100,300)
and (200,400), but not the other two combinations, cannot be
negotiated as a single Child SA pair.

Kaufman, et al. Standards Track [Page 107]
RFC 7296 IKEv2bis October 2014

3.13.1. Traffic Selector

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TS Type |IP Protocol ID*| Selector Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Start Port* | End Port* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Starting Address* ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Ending Address* ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 20: Traffic Selector

*Note: All fields other than TS Type and Selector Length depend on
the TS Type. The fields shown are for TS Types 7 and 8, the only two
values currently defined.

o TS Type (one octet) - Specifies the type of Traffic Selector.

o IP protocol ID (1 octet) - Value specifying an associated IP
protocol ID (such as UDP, TCP, and ICMP). A value of zero means
that the protocol ID is not relevant to this Traffic Selector --
the SA can carry all protocols.

o Selector Length (2 octets, unsigned integer) - Specifies the
length of this Traffic Selector substructure including the header.

o Start Port (2 octets, unsigned integer) - Value specifying the
smallest port number allowed by this Traffic Selector. For
protocols for which port is undefined (including protocol 0), or
if all ports are allowed, this field MUST be zero. ICMP and
ICMPv6 Type and Code values, as well as Mobile IP version 6
(MIPv6) mobility header (MH) Type values, are represented in this
field as specified in Section 4.4.1.1 of [IPSECARCH]. ICMP Type
and Code values are treated as a single 16-bit integer port
number, with Type in the most significant eight bits and Code in
the least significant eight bits. MIPv6 MH Type values are
treated as a single 16-bit integer port number, with Type in the
most significant eight bits and the least significant eight bits
set to zero.

Kaufman, et al. Standards Track [Page 108]
RFC 7296 IKEv2bis October 2014

o End Port (2 octets, unsigned integer) - Value specifying the
largest port number allowed by this Traffic Selector. For
protocols for which port is undefined (including protocol 0), or
if all ports are allowed, this field MUST be 65535. ICMP and
ICMPv6 Type and Code values, as well as MIPv6 MH Type values, are
represented in this field as specified in Section 4.4.1.1 of
[IPSECARCH]. ICMP Type and Code values are treated as a single
16-bit integer port number, with Type in the most significant
eight bits and Code in the least significant eight bits. MIPv6 MH
Type values are treated as a single 16-bit integer port number,
with Type in the most significant eight bits and the least
significant eight bits set to zero.

o Starting Address - The smallest address included in this Traffic
Selector (length determined by TS Type).

o Ending Address - The largest address included in this Traffic
Selector (length determined by TS Type).

Systems that are complying with [IPSECARCH] that wish to indicate
"ANY" ports MUST set the start port to 0 and the end port to 65535;
note that according to [IPSECARCH], "ANY" includes "OPAQUE". Systems
working with [IPSECARCH] that wish to indicate "OPAQUE" ports, but
not "ANY" ports, MUST set the start port to 65535 and the end port
to 0.

The Traffic Selector types 7 and 8 can also refer to ICMP or ICMPv6
type and code fields, as well as MH Type fields for the IPv6 mobility
header [MIPV6]. Note, however, that neither ICMP nor MIPv6 packets
have separate source and destination fields. The method for
specifying the Traffic Selectors for ICMP and MIPv6 is shown by
example in Section 4.4.1.3 of [IPSECARCH].

Kaufman, et al. Standards Track [Page 109]
RFC 7296 IKEv2bis October 2014

The following table lists values for the Traffic Selector Type field
and the corresponding Address Selector Data. The values in the
following table are only current as of the publication date of
RFC 4306. Other values may have been added since then or will be
added after the publication of this document. Readers should refer
to [IKEV2IANA] for the latest values.

TS Type Value
-------------------------------------------------------------------
TS_IPV4_ADDR_RANGE 7

A range of IPv4 addresses, represented by two four-octet
values. The first value is the beginning IPv4 address
(inclusive) and the second value is the ending IPv4 address
(inclusive). All addresses falling between the two specified
addresses are considered to be within the list.

TS_IPV6_ADDR_RANGE 8

A range of IPv6 addresses, represented by two sixteen-octet
values. The first value is the beginning IPv6 address
(inclusive) and the second value is the ending IPv6 address
(inclusive). All addresses falling between the two specified
addresses are considered to be within the list.

3.14. Encrypted Payload

The Encrypted payload, denoted SK {...} in this document, contains
other payloads in encrypted form. The Encrypted payload, if present
in a message, MUST be the last payload in the message. Often, it is
the only payload in the message. This payload is also called the
"Encrypted and Authenticated" payload.

The algorithms for encryption and integrity protection are negotiated
during IKE SA setup, and the keys are computed as specified in
Sections 2.14 and 2.18.

This document specifies the cryptographic processing of Encrypted
payloads using a block cipher in CBC mode and an integrity check
algorithm that computes a fixed-length checksum over a variable size
message. The design is modeled after the ESP algorithms described in
RFCs 2104 [HMAC], 4303 [ESP], and 2451 [ESPCBC]. This document
completely specifies the cryptographic processing of IKE data, but
those documents should be consulted for design rationale. Future
documents may specify the processing of Encrypted payloads for other
types of transforms, such as counter mode encryption and
authenticated encryption algorithms. Peers MUST NOT negotiate
transforms for which no such specification exists.

Kaufman, et al. Standards Track [Page 110]
RFC 7296 IKEv2bis October 2014

When an authenticated encryption algorithm is used to protect the IKE
SA, the construction of the Encrypted payload is different than what
is described here. See [AEAD] for more information on authenticated
encryption algorithms and their use in IKEv2.

The payload type for an Encrypted payload is forty-six (46). The
Encrypted payload consists of the IKE generic payload header followed
by individual fields as follows:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initialization Vector |
| (length is block size for encryption algorithm) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Encrypted IKE Payloads ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Padding (0-255 octets) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| | Pad Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Integrity Checksum Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 21: Encrypted Payload Format

o Next Payload - The payload type of the first embedded payload.
Note that this is an exception in the standard header format,
since the Encrypted payload is the last payload in the message and
therefore the Next Payload field would normally be zero. But
because the content of this payload is embedded payloads and there
was no natural place to put the type of the first one, that type
is placed here.

o Payload Length - Includes the lengths of the header,
initialization vector (IV), Encrypted IKE payloads, Padding, Pad
Length, and Integrity Checksum Data.

o Initialization Vector - For CBC mode ciphers, the length of the
initialization vector (IV) is equal to the block length of the
underlying encryption algorithm. Senders MUST select a new
unpredictable IV for every message; recipients MUST accept any
value. The reader is encouraged to consult [MODES] for advice on
IV generation. In particular, using the final ciphertext block of

Kaufman, et al. Standards Track [Page 111]
RFC 7296 IKEv2bis October 2014

the previous message is not considered unpredictable. For modes
other than CBC, the IV format and processing is specified in the
document specifying the encryption algorithm and mode.

o IKE payloads are as specified earlier in this section. This field
is encrypted with the negotiated cipher.

o Padding MAY contain any value chosen by the sender, and MUST have
a length that makes the combination of the payloads, the Padding,
and the Pad Length to be a multiple of the encryption block size.
This field is encrypted with the negotiated cipher.

o Pad Length is the length of the Padding field. The sender SHOULD
set the Pad Length to the minimum value that makes the combination
of the payloads, the Padding, and the Pad Length a multiple of the
block size, but the recipient MUST accept any length that results
in proper alignment. This field is encrypted with the negotiated
cipher.

o Integrity Checksum Data is the cryptographic checksum of the
entire message starting with the Fixed IKE header through the Pad
Length. The checksum MUST be computed over the encrypted message.
Its length is determined by the integrity algorithm negotiated.

3.15. Configuration Payload

The Configuration payload, denoted CP in this document, is used to
exchange configuration information between IKE peers. The exchange
is for an IRAC to request an internal IP address from an IRAS and to
exchange other information of the sort that one would acquire with
Dynamic Host Configuration Protocol (DHCP) if the IRAC were directly
connected to a LAN.

The Configuration payload is defined as follows:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload |C| RESERVED | Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CFG Type | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Configuration Attributes ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 22: Configuration Payload Format

Kaufman, et al. Standards Track [Page 112]
RFC 7296 IKEv2bis October 2014

The payload type for the Configuration payload is forty-seven (47).

o CFG Type (1 octet) - The type of exchange represented by the
Configuration Attributes. The values in the following table are
only current as of the publication date of RFC 4306. Other values
may have been added since then or will be added after the
publication of this document. Readers should refer to [IKEV2IANA]
for the latest values.

CFG Type Value
--------------------------
CFG_REQUEST 1
CFG_REPLY 2
CFG_SET 3
CFG_ACK 4

o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on
receipt.

o Configuration Attributes (variable length) - These are type length
value (TLV) structures specific to the Configuration payload and
are defined below. There may be zero or more Configuration
Attributes in this payload.

3.15.1. Configuration Attributes

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| Attribute Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Value ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 23: Configuration Attribute Format

o Reserved (1 bit) - This bit MUST be set to zero and MUST be
ignored on receipt.

o Attribute Type (15 bits) - A unique identifier for each of the
Configuration Attribute Types.

o Length (2 octets, unsigned integer) - Length in octets of value.

o Value (0 or more octets) - The variable-length value of this
Configuration Attribute. The following lists the attribute types.

Kaufman, et al. Standards Track [Page 113]
RFC 7296 IKEv2bis October 2014

The values in the following table are only current as of the
publication date of RFC 4306 (except INTERNAL_ADDRESS_EXPIRY and
INTERNAL_IP6_NBNS, which were removed by RFC 5996). Other values may
have been added since then or will be added after the publication of
this document. Readers should refer to [IKEV2IANA] for the latest
values.

Attribute Type Value Multi-Valued Length
------------------------------------------------------------
INTERNAL_IP4_ADDRESS 1 YES* 0 or 4 octets
INTERNAL_IP4_NETMASK 2 NO 0 or 4 octets
INTERNAL_IP4_DNS 3 YES 0 or 4 octets
INTERNAL_IP4_NBNS 4 YES 0 or 4 octets
INTERNAL_IP4_DHCP 6 YES 0 or 4 octets
APPLICATION_VERSION 7 NO 0 or more
INTERNAL_IP6_ADDRESS 8 YES* 0 or 17 octets
INTERNAL_IP6_DNS 10 YES 0 or 16 octets
INTERNAL_IP6_DHCP 12 YES 0 or 16 octets
INTERNAL_IP4_SUBNET 13 YES 0 or 8 octets
SUPPORTED_ATTRIBUTES 14 NO Multiple of 2
INTERNAL_IP6_SUBNET 15 YES 17 octets

* These attributes may be multi-valued on return only if
multiple values were requested.

o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the
internal network, sometimes called a red node address or private
address, and it MAY be a private address on the Internet. In a
request message, the address specified is a requested address (or
a zero-length address if no specific address is requested). If a
specific address is requested, it likely indicates that a previous
connection existed with this address and the requestor would like
to reuse that address. With IPv6, a requestor MAY supply the low-
order address octets it wants to use. Multiple internal addresses
MAY be requested by requesting multiple internal address
attributes. The responder MAY only send up to the number of
addresses requested. The INTERNAL_IP6_ADDRESS is made up of two
fields: the first is a 16-octet IPv6 address, and the second is a
one-octet prefix-length as defined in [ADDRIPV6]. The requested
address is valid as long as this IKE SA (or its rekeyed
successors) requesting the address is valid. This is described in
more detail in Section 3.15.3.

o INTERNAL_IP4_NETMASK - The internal networkAppendix B. Acknowledgments

Since text is borrowed from earlier Internet-Drafts and RFCs the co-
authors of previous specifications are acknowledged here: Kathie
Nichols and Klaus Wehrle. David Black, Toerless Eckert, Gorry
Fairhurst, Ruediger Geib, and Spencer Dawkins provided helpful
comments and (also text) suggestions.

Appendix C. Change History

This section briefly lists changes between Internet-Draft versions
for convenience.

Changes in Version 08:

o revised two sentences as suggested by Spencer Dawkins

Changes in Version 07:

o revised some text for clarification according to comments from
Spencer Dawkins

Changes in Version 06:

Bless Expires August 3, 2019 [Page 17]
Internet-Draft Lower Effort PHB January 2019

o added Multicast Considerations section with input from Toerless
Eckert

o incorporated suggestions by David Black with respect to better
reflect legacy CS1 handling

Changes in Version 05:

o added scavenger service class into abstract

o added some more history

o added reference for "Myth of Over-Provisioning" in RFC3439 and
references to presentations w.r.t. codepoint choices

o added text to update draft-ietf-tsvwg-rtcweb-qos

o revised text on congestion control in case of remarking to BE

o added reference to DSCP measurement talk @IETF99

o small typo fixes

Changes in Version 04:

o Several editorial changes according to review from Gorry Fairhurst

o Changed the section structure a bit (moved subsections 1.1 and 1.2
into own sections 3 and 7 respectively)

o updated section 2 on requirements language

o added updates to RFC 8325

o tried to be more explicit what changes are required to RFCs 4594
and 8325

Changes in Version 03:

o Changed recommended codepoint to 000001

o Added text to explain the reasons for the DSCP choice

o Removed LE-min,LE-strict discussion

o Added one more potential use case: reporting errors or telemetry
data from OSs

Bless Expires August 3, 2019 [Page 18]
Internet-Draft Lower Effort PHB January 2019

o Added privacy considerations to the security section (not worth an
own section I think)

o Changed IANA considerations section

Changes in Version 02:

o Applied many editorial suggestions from David Black

o Added Multicast traffic use case

o Clarified what is required for deployment in section 1.2
(Deployment Considerations)

o Added text about implementations using AQMs and ECN usage

o Updated IANA section according to David Black's suggestions

o Revised text in the security section

o Changed copyright Notice to pre5378Trust200902

Changes in Version 01:

o Now obsoletes RFC 3662.

o Tried to be more precise in section 1.1 (Applicability) according
to R. Geib's suggestions, so rephrased several paragraphs. Added
text about congestion control

o Change section 2 (PHB Description) according to R. Geib's
suggestions.

o Added RFC 2119 language to several sentences.

o Detailed the description of remarking implications and
recommendations in Section 8.

o Added Section 10 to explicitly list changes with respect to RFC
4594, because this document will update it.

Appendix D. Note to RFC Editor

This section lists actions for the RFC editor during final
formatting.

o Please replace the occurrences of RFCXXXX in Section 10 and
Section 11 with the assigned RFC number for this document.

Bless Expires August 3, 2019 [Page 19]
Internet-Draft Lower Effort PHB January 2019

o Delete Appendix C.

o Delete this section.

Author's Address

Roland Bless
Karlsruhe Institute of Technology (KIT)
Kaiserstr. 12
Karlsruhe 76131
Germany

Phone: +49 721 608 46413
Email: roland.bless@kit.edu

Bless Expires August 3, 2019 [Page 20]

A Lower Effort Per-Hop Behavior (LE PHB) draft-ietf-tsvwg-le-phb-08

A Lower Effort Per-Hop Behavior (LE PHB)
draft-ietf-tsvwg-le-phb-08