draft-ietf-6man-segment-routing-header-15.txt   draft-ietf-6man-segment-routing-header-16.txt 
Network Working Group C. Filsfils, Ed. Network Working Group C. Filsfils, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track S. Previdi Intended status: Standards Track S. Previdi
Expires: April 25, 2019 Huawei Expires: August 8, 2019 Huawei
J. Leddy J. Leddy
Individual Individual
S. Matsushima S. Matsushima
Softbank Softbank
D. Voyer, Ed. D. Voyer, Ed.
Bell Canada Bell Canada
October 22, 2018 February 4, 2019
IPv6 Segment Routing Header (SRH) IPv6 Segment Routing Header (SRH)
draft-ietf-6man-segment-routing-header-15 draft-ietf-6man-segment-routing-header-16
Abstract Abstract
Segment Routing can be applied to the IPv6 data plane using a new Segment Routing can be applied to the IPv6 data plane using a new
type of Routing Extension Header. This document describes the type of Routing Extension Header. This document describes the
Segment Routing Extension Header and how it is used by Segment Segment Routing Extension Header and how it is used by Segment
Routing capable nodes. Routing capable nodes.
Requirements Language Requirements Language
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2019. This Internet-Draft will expire on August 8, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Segment Routing Extension Header . . . . . . . . . . . . . . 4 2. Segment Routing Extension Header . . . . . . . . . . . . . . 4
2.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Padding TLVs . . . . . . . . . . . . . . . . . . . . 6 2.1.1. Padding TLVs . . . . . . . . . . . . . . . . . . . . 6
2.1.2. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 7 2.1.2. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 8
3. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 10 3.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 10
3.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 11
3.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 11 3.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 11
4. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 11 4. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 11 4.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. Reduced SRH . . . . . . . . . . . . . . . . . . . . . 12 4.1.1. Reduced SRH . . . . . . . . . . . . . . . . . . . . . 12
4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 12
4.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 12 4.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 12
4.3.1. FIB Entry Is Locally Instantiated SRv6 END SID . . . 12 4.3.1. FIB Entry Is Locally Instantiated SRv6 END SID . . . 12
4.3.2. FIB Entry is a Local Interface . . . . . . . . . . . 14 4.3.2. FIB Entry is a Local Interface . . . . . . . . . . . 14
4.3.3. FIB Entry Is A Non-Local Route . . . . . . . . . . . 15 4.3.3. FIB Entry Is A Non-Local Route . . . . . . . . . . . 15
4.3.4. FIB Entry Is A No Match . . . . . . . . . . . . . . . 15 4.3.4. FIB Entry Is A No Match . . . . . . . . . . . . . . . 15
4.3.5. Load Balancing and ECMP . . . . . . . . . . . . . . . 15 5. Intra SR Domain Deployment Model . . . . . . . . . . . . . . 15
5. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Securing the SR Domain . . . . . . . . . . . . . . . . . 15
5.1. Abstract Representation of an SRH . . . . . . . . . . . . 15 5.2. SR Domain as a single system with delegation among
5.2. Example Topology . . . . . . . . . . . . . . . . . . . . 16 components . . . . . . . . . . . . . . . . . . . . . . . 16
5.3. Source SR Node . . . . . . . . . . . . . . . . . . . . . 17 5.3. MTU Considerations . . . . . . . . . . . . . . . . . . . 17
5.3.1. Intra SR Domain Packet . . . . . . . . . . . . . . . 17 5.4. AH ICV . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3.2. Transit Packet Through SR Domain . . . . . . . . . . 17 5.5. ESP ICV . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.4. Transit Node . . . . . . . . . . . . . . . . . . . . . . 18 5.6. ICMP Error Processing . . . . . . . . . . . . . . . . . . 17
5.5. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 18 5.7. Load Balancing and ECMP . . . . . . . . . . . . . . . . . 18
6. Deployment Models . . . . . . . . . . . . . . . . . . . . . . 18 5.8. Other Deployments . . . . . . . . . . . . . . . . . . . . 18
6.1. Nodes Within the SR domain . . . . . . . . . . . . . . . 18 6. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2. Nodes Outside the SR Domain . . . . . . . . . . . . . . . 18 6.1. Abstract Representation of an SRH . . . . . . . . . . . . 18
6.2.1. SR Source Nodes Not Directly Connected . . . . . . . 19 6.2. Example Topology . . . . . . . . . . . . . . . . . . . . 19
6.3. Source SR Node . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6.3.1. Intra SR Domain Packet . . . . . . . . . . . . . . . 20
7.1. Source Routing Attacks . . . . . . . . . . . . . . . . . 21 6.3.2. Inter SR Domain Packet - Transit . . . . . . . . . . 20
7.2. Service Theft . . . . . . . . . . . . . . . . . . . . . . 21 6.3.3. Inter SR Domain Packet - Internal to External . . . . 21
7.3. Topology Disclosure . . . . . . . . . . . . . . . . . . . 22 6.4. Transit Node . . . . . . . . . . . . . . . . . . . . . . 21
7.4. ICMP Generation . . . . . . . . . . . . . . . . . . . . . 22 6.5. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 6.6. Delegation of Function with HMAC Verification . . . . . . 21
8.1. Segment Routing Header Flags Register . . . . . . . . . . 23 6.6.1. SID List Verification . . . . . . . . . . . . . . . . 21
8.2. Segment Routing Header TLVs Register . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. Implementation Status . . . . . . . . . . . . . . . . . . . . 23 7.1. Source Routing Attacks . . . . . . . . . . . . . . . . . 23
9.1. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.2. Service Theft . . . . . . . . . . . . . . . . . . . . . . 23
9.2. Cisco Systems . . . . . . . . . . . . . . . . . . . . . . 24 7.3. Topology Disclosure . . . . . . . . . . . . . . . . . . . 23
9.3. FD.io . . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.4. ICMP Generation . . . . . . . . . . . . . . . . . . . . . 24
9.4. Barefoot . . . . . . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
9.5. Juniper . . . . . . . . . . . . . . . . . . . . . . . . . 24 8.1. Segment Routing Header Flags Register . . . . . . . . . . 24
9.6. Huawei . . . . . . . . . . . . . . . . . . . . . . . . . 25 8.2. Segment Routing Header TLVs Register . . . . . . . . . . 24
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 25
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 9.1. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 9.2. Cisco Systems . . . . . . . . . . . . . . . . . . . . . . 25
12.1. Normative References . . . . . . . . . . . . . . . . . . 25 9.3. FD.io . . . . . . . . . . . . . . . . . . . . . . . . . . 25
12.2. Informative References . . . . . . . . . . . . . . . . . 26 9.4. Barefoot . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 9.5. Juniper . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.6. Huawei . . . . . . . . . . . . . . . . . . . . . . . . . 26
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
Segment Routing can be applied to the IPv6 data plane using a new Segment Routing can be applied to the IPv6 data plane using a new
type of Routing Extension Header (SRH). This document describes the type of Routing Extension Header (SRH). This document describes the
Segment Routing Extension Header and how it is used by Segment Segment Routing Extension Header and how it is used by Segment
Routing capable nodes. Routing capable nodes.
The Segment Routing Architecture [RFC8402] describes Segment Routing The Segment Routing Architecture [RFC8402] describes Segment Routing
and its instantiation in two data planes MPLS and IPv6. and its instantiation in two data planes MPLS and IPv6.
skipping to change at page 8, line 36 skipping to change at page 8, line 41
o HMAC Key ID: A 4 octet opaque number which uniquely identifies the o HMAC Key ID: A 4 octet opaque number which uniquely identifies the
pre-shared key and algorithm used to generate the HMAC. If 0, the pre-shared key and algorithm used to generate the HMAC. If 0, the
HMAC is not included. HMAC is not included.
o HMAC: 32 octets of keyed HMAC, not present if Key ID is 0. o HMAC: 32 octets of keyed HMAC, not present if Key ID is 0.
The HMAC TLV is used to verify the source of a packet is permitted to The HMAC TLV is used to verify the source of a packet is permitted to
use the current segment in the destination address of the packet, and use the current segment in the destination address of the packet, and
ensure the segment list is not modified in transit. ensure the segment list is not modified in transit.
2.1.2.1. HMAC generation 2.1.2.1. HMAC Generation and Verification
Local policy determines when to check for an HMAC and potentially
provides an alternate composition of Text, and a requirement on where
the HMAC TLV must appear (e.g. first TLV). This local policy is
outside the scope of this document. It may be based on the active
segment at an SR Segment endpoint node, the result of an ACL that
considers incoming interface, HMAC Key ID, or other packet fields.
The HMAC field is the output of the HMAC computation as defined in The HMAC field is the output of the HMAC computation as defined in
[RFC2104], using: [RFC2104], using:
o key: the pre-shared key identified by HMAC Key ID o key: the pre-shared key identified by HMAC Key ID
o HMAC algorithm: identified by the HMAC Key ID o HMAC algorithm: identified by the HMAC Key ID
o Text: a concatenation of the following fields from the IPv6 header o Text: a concatenation of the following fields from the IPv6 header
and the SRH, as it would be received at the node verifying the and the SRH, as it would be received at the node verifying the
HMAC: HMAC:
* IPv6 header: source address (16 octets) * IPv6 header: source address (16 octets)
* IPv6 header: destination address (16 octets)
* SRH: Segments Left (1 octet)
* SRH: Last Entry (1 octet) * SRH: Last Entry (1 octet)
* SRH: Flags (1 octet) * SRH: Flags (1 octet)
* SRH: HMAC Key-id (4 octets) * SRH: HMAC Key-id (4 octets)
* SRH: all addresses in the Segment List (variable octets) * SRH: all addresses in the Segment List (variable octets)
The HMAC digest is truncated to 32 octets and placed in the HMAC The HMAC digest is truncated to 32 octets and placed in the HMAC
field of the HMAC TLV. field of the HMAC TLV.
For HMAC algorithms producing digests less than 32 octets, the digest For HMAC algorithms producing digests less than 32 octets, the digest
is placed in the lowest order octets of the HMAC field. Remaining is placed in the lowest order octets of the HMAC field. Remaining
octets MUST be set to zero. octets MUST be set to zero.
2.1.2.2. HMAC Verification
Local policy determines when to check for an HMAC and potentially a
requirement on where the HMAC TLV must appear (e.g. first TLV).
This local policy is outside the scope of this document. It may be
based on the active segment at an SR Segment endpoint node, the
result of an ACL that considers incoming interface, or other packet
fields.
If HMAC verification is successful, the packet is forwarded to the If HMAC verification is successful, the packet is forwarded to the
next segment. next segment.
If HMAC verification fails, an ICMP error message (parameter problem, If HMAC verification fails, an ICMP error message (parameter problem,
error code 0, pointing to the HMAC TLV) SHOULD be generated (but rate error code 0, pointing to the HMAC TLV) SHOULD be generated (but rate
limited) and SHOULD be logged. limited) and SHOULD be logged.
2.1.2.3. HMAC Pre-Shared Key Algorithm 2.1.2.2. HMAC Pre-Shared Key Algorithm
The HMAC Key ID field allows for the simultaneous existence of The HMAC Key ID field allows for the simultaneous existence of
several hash algorithms (SHA-256, SHA3-256 ... or future ones) as several hash algorithms (SHA-256, SHA3-256 ... or future ones) as
well as pre-shared keys. well as pre-shared keys.
The HMAC Key ID field is opaque, i.e., it has neither syntax nor The HMAC Key ID field is opaque, i.e., it has neither syntax nor
semantic except as an identifier of the right combination of pre- semantic except as an identifier of the right combination of pre-
shared key and hash algorithm, and except that a value of 0 means shared key and hash algorithm, and except that a value of 0 means
that there is no HMAC field. that there is no HMAC field.
skipping to change at page 13, line 14 skipping to change at page 13, line 14
If the FIB entry represents a locally instantiated SRv6 SID, process If the FIB entry represents a locally instantiated SRv6 SID, process
the next header of the IPv6 header as defined in section 4 of the next header of the IPv6 header as defined in section 4 of
[RFC8200] [RFC8200]
The following sections describe the actions to take while processing The following sections describe the actions to take while processing
next header fields. next header fields.
4.3.1.1. SRH Processing 4.3.1.1. SRH Processing
When an SRH is processed { S01. When an SRH is processed {
If Segments Left is equal to zero { S02. If Segments Left is equal to zero {
Proceed to process the next header in the packet, whose type S03. Proceed to process the next header in the packet,
is identified by the Next Header field in the Routing header. whose type is identified by the Next Header field in
} the Routing header.
Else { S04. }
If local policy requires TLV processing { S05. Else {
Perform TLV processing (see TLV Processing) S06. If local policy requires TLV processing {
} S07. Perform TLV processing (see TLV Processing)
max_last_entry = ( Hdr Ext Len / 2 ) - 1 S08. }
S09. max_last_entry = ( Hdr Ext Len / 2 ) - 1
If ((Last Entry > max_last_entry) or S10. If ((Last Entry > max_last_entry) or
(Segments Left is greater than (Last Entry+1)) { S11. (Segments Left is greater than (Last Entry+1)) {
Send an ICMP Parameter Problem, Code 0, message to the S12. Send an ICMP Parameter Problem, Code 0, message to
Source Address, pointing to the Segments Left field, and the Source Address, pointing to the Segments Left
discard the packet. field, and discard the packet.
} S13. }
Else { S14. Else {
Decrement Segments Left by 1. S15. Decrement Segments Left by 1.
Copy Segment List[Segments Left] from the SRH to the S16. Copy Segment List[Segments Left] from the SRH to the
destination address of the IPv6 header. destination address of the IPv6 header.
If the IPv6 Hop Limit is less than or equal to 1 { S17. If the IPv6 Hop Limit is less than or equal to 1 {
Send an ICMP Time Exceeded -- Hop Limit Exceeded in S18. Send an ICMP Time Exceeded -- Hop Limit Exceeded in
Transit message to the Source Address and discard Transit message to the Source Address and discard
the packet. the packet.
} S19. }
Else { S20. Else {
Decrement the Hop Limit by 1 S21. Decrement the Hop Limit by 1
Resubmit the packet to the IPv6 module for transmission S22. Resubmit the packet to the IPv6 module for transmission
to the new destination. to the new destination.
} S23. }
} S24. }
} S25. }
} S26. }
4.3.1.1.1. TLV Processing 4.3.1.1.1. TLV Processing
Local policy determines how TLV's are to be processed when the Active Local policy determines how TLV's are to be processed when the Active
Segment is a local END SID. The definition of local policy is Segment is a local END SID. The definition of local policy is
outside the scope of this document. outside the scope of this document.
For illustration purpose only, two example local policies that may be For illustration purpose only, two example local policies that may be
associated with an END SID are provided below. associated with an END SID are provided below.
skipping to change at page 14, line 29 skipping to change at page 14, line 29
For any packet received from interface I1 For any packet received from interface I1
If first TLV is HMAC { If first TLV is HMAC {
Process the HMAC TLV Process the HMAC TLV
} }
Else { Else {
Discard the packet Discard the packet
} }
4.3.1.2. Upper-layer Header or No Next Header 4.3.1.2. Upper-layer Header or No Next Header
Send an ICMP parameter problem message to the Source Address and When processing the Upper-layer header of a packet matching a FIB
discard the packet. Error code (TBD by IANA) "SR Upper-layer Header entry locally instantiated as an SRv6 END SID.
Error", pointer set to the offset of the upper-layer header.
IF (Upper-layer Header is IPv4 or IPv6) and local policy permits {
Perform IPv6 decapsulation
Resubmit the decapsulated packet to the IPv4 or IPv6 module
}
ELSE {
Send an ICMP parameter problem message to the Source Address and
discard the packet. Error code (TBD by IANA) "SR Upper-layer
Header Error", pointer set to the offset of the upper-layer
header.
}
A unique error code allows an SR Source node to recognize an error in A unique error code allows an SR Source node to recognize an error in
SID processing at an endpoint. SID processing at an endpoint.
4.3.2. FIB Entry is a Local Interface 4.3.2. FIB Entry is a Local Interface
If the FIB entry represents a local interface, not locally If the FIB entry represents a local interface, not locally
instantiated as an SRv6 SID, the SRH is processed as follows: instantiated as an SRv6 SID, the SRH is processed as follows:
If Segments Left is zero, the node must ignore the Routing header If Segments Left is zero, the node must ignore the Routing header
skipping to change at page 15, line 13 skipping to change at page 15, line 21
Source Address, pointing to the unrecognized Routing Type. Source Address, pointing to the unrecognized Routing Type.
4.3.3. FIB Entry Is A Non-Local Route 4.3.3. FIB Entry Is A Non-Local Route
Processing is not changed by this document. Processing is not changed by this document.
4.3.4. FIB Entry Is A No Match 4.3.4. FIB Entry Is A No Match
Processing is not changed by this document. Processing is not changed by this document.
4.3.5. Load Balancing and ECMP 5. Intra SR Domain Deployment Model
Within an SR domain, an SR source node encapsulates a packet in an The use of the SIDs exclusively within the SR Domain and solely for
outer IPv6 header for transport to an endpoint. The SR source node packets of the SR Domain is an important deployment model.
MUST impose a flow label computed based on the inner packet. The
computation of the flow label is as recommended in [RFC6438] for the This enables the SR Domain to act as a single routing system.
sending Tunnel End Point.
This section covers:
o securing the SR Domain from external attempt to use its SIDs
o SR Domain as a single system with delegation between components
o handling packets of the SR Domain
5.1. Securing the SR Domain
Nodes outside the SR Domain are not trusted: they cannot directly use
the SID's of the domain. This is enforced by two levels of access
control lists:
1. Any packet entering the SR Domain and destined to a SID within
the SR Domain is dropped. This may be realized with the
following logic, other methods with equivalent outcome are
considered compliant:
* allocate all the SID's from a block S/s
* configure each external interface of each edge node of the
domain with an inbound infrastructure access list (IACL) which
drops any incoming packet with a destination address in S/s
* Failure to implement this method of ingress filtering exposes
the SR Domain to source routing attacks as described and
referenced in [RFC5095]
2. The distributed protection in #1 is complemented with per node
protection, dropping packets to SIDs from source addresses
outside the SR Domain. This may be realized with the following
logic, other methods with equivalent outcome are considered
compliant:
* assign all interface addresses from prefix A/a
* at node k, all SIDs local to k are assigned from prefix Sk/sk
* configure each internal interface of each SR node k in the SR
Domain with an inbound IACL which drops any incoming packet
with a destination address in Sk/sk if the source address is
not in A/a.
5.2. SR Domain as a single system with delegation among components
All intra SR Domain packets are of the SR Domain. The IP v6 header
is originated by a node of the SR Domain, and is destined to a node
of the SR Domain.
All inter domain packets are encapsulated for the part of the packet
journey that is within the SR Domain. The outer IPv6 header is
originated by a node of the SR Domain, and is destined to a node of
the SR Domain.
As a consequence, any packet within the SR Domain is of the SR
Domain.
The SR Domain is a system in which the operator may want to
distribute or delegate different operations of the outer most header
to different nodes within the system.
An operator of an SR domain may choose to delegate SRH addition to a
host node within the SR domain, and validation of the contents of any
SRH to a more trusted router or switch attached to the host.
Consider a top of rack switch (T) connected to host (H) via interface
(I). H receives an SRH (SRH1) with a computed HMAC via some SDN
method outside the scope of this document. H classifies traffic it
sources and adds SRH1 to traffic requiring a specific SLA. T is
configured with an IACL on I requiring verification of the SRH for
any packet destined to the SID block of the SR Domain (S/s). T
checks and verifies that SRH1 is valid, contains an HMAC TLV and
verifies the HMAC.
5.3. MTU Considerations
Within the SR Domain, well known mitigation techniques are
RECOMMENDED, such as deploying a greater MTU value within the SR
Domain than at the ingress edges.
5.4. AH ICV
Within the domain, an SR source node which includes SRH and AH
extension headers can predict the content of the SRH and calculate
the ICV at the SR source node, ensuring it can be confirmed at the
destination.
5.5. ESP ICV
Within the domain, an SR source node may include SRH and ESP
extension headers. Only the data following the ESP header is
included in ICV computation. SRH precedes ESP.
5.6. ICMP Error Processing
ICMP error packets generated within the SR Domain are sent to source
nodes within the SR Domain. The invoking packet in the ICMP error
message may contain an SRH. Since the destination address of a
packet with an SRH changes as each segment is processed, it may not
be the destination used by the socket or application that generated
the invoking packet.
For the source of an invoking packet to process the ICMP error
message, the correct destination address must be determined. The
following logic is used to determine the destination address for use
by protocol error handlers.
o Walk all extension headers of the invoking IPv6 packet to the
routing extension header preceding the upper layer header.
* If routing header is type 4 (SRH)
+ Use the 0th segment in the segment list as the destination
address of the invoking packet.
ICMP errors are then processed by upper layer transports as defined
in [RFC4443].
For IP packets encapsulated in an outer IPv6 header, ICMP error
handling is as defined in [RFC2473].
5.7. Load Balancing and ECMP
For any inter domain packet, the SR Source node MUST impose a flow
label computed based on the inner packet. The computation of the
flow label is as recommended in [RFC6438] for the sending Tunnel End
Point.
At any transit node within an SR domain, the flow label MUST be used At any transit node within an SR domain, the flow label MUST be used
as defined in [RFC6438] to calculate the ECMP hash toward the as defined in [RFC6438] to calculate the ECMP hash toward the
destination address. If flow label is not used, the transit node may destination address. If flow label is not used, the transit node may
hash all packets between a pair of SR Edge nodes to the same link. hash all packets between a pair of SR Edge nodes to the same link.
At an SR segment endpoint node, the flow label MUST be used as At an SR segment endpoint node, the flow label MUST be used as
defined in [RFC6438] to calculate any ECMP hash used to forward the defined in [RFC6438] to calculate any ECMP hash used to forward the
processed packet to the next segment. processed packet to the next segment.
5. Illustrations 5.8. Other Deployments
Other deployment models and their implications on security, MTU,
HMAC, ICMP error processing and interaction with other extension
headers are outside the scope of this document.
6. Illustrations
This section provides illustrations of SRv6 packet processing at SR This section provides illustrations of SRv6 packet processing at SR
source, transit and SR segment endpoint nodes. source, transit and SR segment endpoint nodes.
5.1. Abstract Representation of an SRH 6.1. Abstract Representation of an SRH
For a node k, its IPv6 address is represented as Ak, its SRv6 SID is For a node k, its IPv6 address is represented as Ak, its SRv6 SID is
represented as Sk. represented as Sk.
IPv6 headers are represented as the tuple of (source, destination). IPv6 headers are represented as the tuple of (source, destination).
For example, a packet with source address A1 and destination address For example, a packet with source address A1 and destination address
A2 is represented as (A1,A2). The payload of the packet is omitted. A2 is represented as (A1,A2). The payload of the packet is omitted.
An SR Policy is a list of segments. A list of segments is An SR Policy is a list of segments. A list of segments is
represented as <S1,S2,S3> where S1 is the first SID to visit, S2 is represented as <S1,S2,S3> where S1 is the first SID to visit, S2 is
skipping to change at page 16, line 27 skipping to change at page 19, line 25
(S3,S2,S1; SL=2) represented fully as: (S3,S2,S1; SL=2) represented fully as:
Segments Left=2 Segments Left=2
Last Entry=2 Last Entry=2
Flags=0 Flags=0
Tag=0 Tag=0
Segment List[0]=S3 Segment List[0]=S3
Segment List[1]=S2 Segment List[1]=S2
Segment List[2]=S1 Segment List[2]=S1
5.2. Example Topology 6.2. Example Topology
The following topology is used in examples below: The following topology is used in examples below:
+ * * * * * * * * * * * * * * * * * * * * + + * * * * * * * * * * * * * * * * * * * * +
* [8] [9] * * [8] [9] *
| | | |
* | | * * | | *
[1]----[3]--------[5]----------------[6]---------[4]---[2] [1]----[3]--------[5]----------------[6]---------[4]---[2]
* | | * * | | *
skipping to change at page 17, line 4 skipping to change at page 19, line 50
+ * * * * * * * SR Domain * * * * * * * + + * * * * * * * SR Domain * * * * * * * +
Figure 3 Figure 3
o 3 and 4 are SR Domain edge routers o 3 and 4 are SR Domain edge routers
o 5, 6, and 7 are all SR Domain routers o 5, 6, and 7 are all SR Domain routers
o 8 and 9 are hosts within the SR Domain o 8 and 9 are hosts within the SR Domain
o 1 and 2 are hosts outside the SR Domain o 1 and 2 are hosts outside the SR Domain
o The SR domain is secured as per Section 5.1 and no external packet
can enter the domain with a destination address equal to a segment
of the domain.
5.3. Source SR Node 6.3. Source SR Node
5.3.1. Intra SR Domain Packet 6.3.1. Intra SR Domain Packet
When host 8 sends a packet to host 9 via an SR Policy <S7,A9> the When host 8 sends a packet to host 9 via an SR Policy <S7,A9> the
packet is packet is
P1: (A8,S7)(A9,S7; SL=1) P1: (A8,S7)(A9,S7; SL=1)
5.3.1.1. Reduced Variant 6.3.1.1. Reduced Variant
When host 8 sends a packet to host 9 via an SR Policy <S7,A9> and it When host 8 sends a packet to host 9 via an SR Policy <S7,A9> and it
wants to use a reduced SRH, the packet is wants to use a reduced SRH, the packet is
P2: (A8,S7)(A9; SL=1) P2: (A8,S7)(A9; SL=1)
5.3.2. Transit Packet Through SR Domain 6.3.2. Inter SR Domain Packet - Transit
When host 1 sends a packet to host 2, the packet is When host 1 sends a packet to host 2, the packet is
P3: (A1,A2) P3: (A1,A2)
The SR Domain ingress router 3 receives P3 and steers it to SR Domain The SR Domain ingress router 3 receives P3 and steers it to SR Domain
egress router 4 via an SR Policy <S7, S4>. Router 3 encapsulates the egress router 4 via an SR Policy <S7, S4>. Router 3 encapsulates the
received packet P3 in an outer header with an SRH. The packet is received packet P3 in an outer header with an SRH. The packet is
P4: (A3, S7)(S4, S7; SL=1)(A1, A2) P4: (A3, S7)(S4, S7; SL=1)(A1, A2)
If the SR Policy contains only one segment (the egress router 4), the If the SR Policy contains only one segment (the egress router 4), the
ingress Router 3 encapsulates P3 into an outer header (A3, S4). The ingress Router 3 encapsulates P3 into an outer header (A3, S4). The
packet is packet is
P5: (A3, S4)(A1, A2) P5: (A3, S4)(A1, A2)
5.3.2.1. Reduced Variant 6.3.2.1. Reduced Variant
The SR Domain ingress router 3 receives P3 and steers it to SR Domain The SR Domain ingress router 3 receives P3 and steers it to SR Domain
egress router 4 via an SR Policy <S7, S4>. If router 3 wants to use egress router 4 via an SR Policy <S7, S4>. If router 3 wants to use
a reduced SRH, Router 3 encapsulates the received packet P3 in an a reduced SRH, Router 3 encapsulates the received packet P3 in an
outer header with a reduced SRH. The packet is outer header with a reduced SRH. The packet is
P6: (A3, S7)(S4; SL=1)(A1, A2) P6: (A3, S7)(S4; SL=1)(A1, A2)
5.4. Transit Node 6.3.3. Inter SR Domain Packet - Internal to External
Nodes 5 acts as transit nodes for packet P1, and sends packet
P1: (A8,S7)(A9,S7;SL=1)
on the interface toward node 7.
5.5. SR Segment Endpoint Node
Node 7 receives packet P1 and, using the logic in section 4.3.1, When host 8 sends a packet to host 1, the packet is encapsulated for
sends packet the portion of its journey within the SR Domain. From 8 to 3 the
packet is
P7: (A8,A9)(A9,S7; SL=0) P7: (A8,S3)(A8,A1)
on the interface toward router 6. In the opposite direction, the packet generated from 1 to 8 is
6. Deployment Models P8: (A1,A8)
6.1. Nodes Within the SR domain At node 3 P8 is encapsulated for the portion of its journey within
the SR domain. Resulting in
SR Source Nodes within an SR Domain are trusted to generate IPv6 P9: (A3,S8)(A1,A8)
packets with SRH. SR segment endpoint nodes receiving packets on
interface that are part of the SR Domain may process any packet
destined to a local segment, containing an SRH.
A SR Source Node connected to the SR Domain via a secure tunnel, e.g. At node 9 the outer IPv6 header is removed by S6 processing then
IPSec tunnel mode [RFC4303] or Ethernet pseudowire [RFC4448], may be processed again when received by A8.
considered trusted and directly connected. Some types of tunnels may
result in additional processing overhead that should be considered in
a deployment.
6.2. Nodes Outside the SR Domain 6.4. Transit Node
Nodes outside the SR Domain cannot be trusted. SR Domain Ingress Nodes 5 acts as transit nodes for packet P1, and sends packet
routers SHOULD discard packets destined to SIDs within the SR Domain
(regardless of the presence of an SRH) to avoid attacks on the SR
Domain as described and referenced in [RFC5095]. As an additional
layer of protection, SR Segment Endpoint nodes SHOULD discard packets
destined to local SIDs from source addresses not part of the SR
Domain.
For example, using the example topology from section 5, all SIDs in P1: (A8,S7)(A9,S7;SL=1)
the SR Domain (SIDS S1-S9) are assigned within a single IPv6 prefix,
Prefix-S. All SIDs assigned to a node k are assigned within a single
IPv6 prefix Prefix-Sk, all addresses permitted to source packets
destined to SIDs in the SR Domain are assigned within a single IPv6
prefix Prefix-A.
An Infrastructure Access List (IACL), applied to the external on the interface toward node 7.
interfaces of SR Domain ingress nodes 3 and 4, that discards packets
destined to a SID covered by Prefix-S is used to discard packets
destined to SIDs within the SR Domain.
An IACL, applied to each interface of SR Segment Endpoint Nodes k, 6.5. SR Segment Endpoint Node
that discards packets destined to a SID covered by Prefix-Sk with a
source address not covered by Prefix-A.
Failure to implement a method of ingress filtering, as defined above, Node 7 receives packet P1 and, using the logic in Section 4.3.1,
exposes the SR domain to source routing attacks from nodes outside sends packet
the SR Domain, as described and referenced in [RFC5095].
6.2.1. SR Source Nodes Not Directly Connected P7: (A8,A9)(A9,S7; SL=0)
Nodes outside the SR Domain may request, by some trusted means on the interface toward router 6.
outside the scope of this document, a complete SRH including an HMAC
TLV which is computed correctly for the SRH.
SR Domain ingress routers permit traffic destined to select SIDs with 6.6. Delegation of Function with HMAC Verification
local policy requiring HMAC TLV processing for those select SIDs,
i.e. those SIDs provide a gateway to the SR Domain for a set of
segment lists.
If HMAC verification is successful, the packet is forwarded to the This section describes how a function may be delegated within the SR
next segment. Within the SR Domain no further HMAC check need be Domain to non SR source nodes. In the following sections consider a
performed. host 8 connected to a top of rack 5.
If HMAC verification fails, an ICMP error message (parameter problem, 6.6.1. SID List Verification
error code 0, pointing to the HMAC TLV) SHOULD be generated (but rate
limited) and SHOULD be logged.
For example, extending the topology defined in Figure 3, consider An operator may prefer to add the SRH at source 8, while 5 verifies
node 3 offering access to a premium SLA service to node 20. Node 20 the SID list is valid.
is a trusted SR Source not directly connected to the SR Domain.
+ * * * * * * * * * * * * * * * * * * * * + For illustration purpose, an SDN controller provides 8 an SRH
terminating at node 9, with segment list <S5,S7,S6,A9>, and HMAC TLV
computed for the SRH. The HMAC key is shared with 5, node 8 does not
know the key. Node 5 is configured with an IACL applied to the
interface connected to 8, requiring HMAC verification for any packet
destined to S/s.
* [8] [9] * Node 8 originates packets with the received SRH with HMAC TLV.
| |
* | | *
[20]--[11]--[3]--------[5]----------------[6]---------[4]---[2]
* | | *
| |
* | | *
+--------[7]-------+
* *
+ * * * * * * * SR Domain * * * * * * * + P15:(A8,S5)(A9,S6,S7,S5;SL=3;HMAC)
In order to access the SLA service, node 20 must be able to access Node 5 receives and verifies the HMAC for the SRH, then forwards the
segments within the SR Domain. To provide a secure entry point for packet to the next segment
the SLA service, SIDs with local policy requiring HMAC verification
at node k are defined as Hk and assigned from a prefix Prefix-H.
Prefix-H is disjoint with Prefix-S and Prefix-A defined earlier.
Prefix-H is not part of the IACLs applied at the external facing P16:(A8,S7)(A9,S6,S7,S5;SL=2;HMAC)
interfaces of node 3 and 4, allowing external nodes access to it.
SID H3 is a SID covered by Prefix-H at node 3. Node 6 receives
Node 20 requests the premium SLA service to node 2 and is provided a P17:(A8,S6)(A9,S6,S7,S5;SL=1;HMAC)
pre-computed SRH and HMAC with destination address H3.
Node 20 sends a packet with destination addresses set to H2, SRH and Node 9 receives
HMAC TLV are as provided for the premium SLA service.
Node 3 receives the packet and verifies the HMAC as defined in P18:(A8,A9)(A9,S6,S7,S5;SL=0;HMAC)
section 4.3, forwarding the packet to the next segment in the segment
list or dropping it based on the HMAC result.
This use of an HMAC is particularly valuable within an enterprise This use of an HMAC is particularly valuable within an enterprise
based SR Domain to authenticate a host which is using SRv6 segment based SR Domain [SRN].
routing as documented in [SRN]. In that example, the HMAC is used to
validate a source node is using a permitted segment list.
7. Security Considerations 7. Security Considerations
This section reviews security considerations related to the SRH, This section reviews security considerations related to the SRH,
given the SRH processing and deployment models discussed in this given the SRH processing and deployment models discussed in this
document. document.
As describe in Section 6, it is necessary to filter packets ingress As describe in Section 5, it is necessary to filter packets ingress
to the SR Domain destined to segments within the SR Domain. This to the SR Domain destined to segments within the SR Domain. This
ingress filtering is via an IACL at SR Domain ingress border nodes. ingress filtering is via an IACL at SR Domain ingress border nodes.
Additional protection is applied via an IACL at each SR Segment Additional protection is applied via an IACL at each SR Segment
Endpoint node, filtering packets not from within the SR Domain, Endpoint node, filtering packets not from within the SR Domain,
destined to SIDs in the SR Domain. ACLs are easily supported for destined to SIDs in the SR Domain. ACLs are easily supported for
small numbers of prefixes, making summarization important, and when small numbers of prefixes, making summarization important, and when
the prefixes requiring filtering is kept to a seldom changing set. the prefixes requiring filtering is kept to a seldom changing set.
Additionally, ingress filtering of IPv6 source addresses as Additionally, ingress filtering of IPv6 source addresses as
recommended in BCP38 SHOULD be used. recommended in BCP38 SHOULD be used.
SR Source Nodes not directly connected to the SR Domain may access
specific sets of segments within the SR Domain when secured with the
SRH HMAC TLV. The SRH HMAC TLV provides a means of verifying the
validity of ingress packets SRH, limiting access to the segments in
the SR Domain to only those source nodes with permission.
7.1. Source Routing Attacks 7.1. Source Routing Attacks
[RFC5095] deprecates the Type 0 Routing header due to a number of [RFC5095] deprecates the Type 0 Routing header due to a number of
significant attacks that are referenced in that document. Such significant attacks that are referenced in that document. Such
attacks include bypassing filtering devices, reaching otherwise attacks include bypassing filtering devices, reaching otherwise
unreachable Internet systems, network topology discovery, bandwidth unreachable Internet systems, network topology discovery, bandwidth
exhaustion, and defeating anycast. exhaustion, and defeating anycast.
Because this document specifies that the SRH is for use within an SR Because this document specifies that the SRH is for use within an SR
domain protected by ingress filtering via IACLs, and by domain protected by ingress filtering via IACLs; such attacks cannot
cryptographically authenticated SR source nodes not directly be mounted from outside an SR Domain. As specified in this document,
connected to the SR Domain; such attacks cannot be mounted from SR Domain ingress edge nodes drop packets entering the SR Domain
outside an SR Domain. As specified in this document, SR Domain destined to segments within the SR Domain.
ingress edge nodes drop packets entering the SR Domain destined to
segments within the SR Domain.
Aditionally, this document specifies the use of IACL on SR Segment Additionally, this document specifies the use of IACL on SR Segment
Endpoint nodes within the SR Domain to limit the source addresses Endpoint nodes within the SR Domain to limit the source addresses
permitted to send packets to a SID in the SR Domain. permitted to send packets to a SID in the SR Domain.
Such attacks may, however, be mounted from within the SR Domain, from Such attacks may, however, be mounted from within the SR Domain, from
nodes permitted to source traffic to SIDs in the domain. As such, nodes permitted to source traffic to SIDs in the domain. As such,
these attacks and other known attacks on an IP network (e.g. DOS/ these attacks and other known attacks on an IP network (e.g. DOS/
DDOS, topology discovery, man-in-the-middle, traffic interception/ DDOS, topology discovery, man-in-the-middle, traffic interception/
siphoning), can occur from compromised nodes within an SR Domain. siphoning), can occur from compromised nodes within an SR Domain.
7.2. Service Theft 7.2. Service Theft
Service theft is defined as the use of a service offered by the SR Service theft is defined as the use of a service offered by the SR
Domain by a node not authorized to use the service. Domain by a node not authorized to use the service.
Service theft is not a concern within the SR Domain as all SR Source Service theft is not a concern within the SR Domain as all SR Source
nodes and SR segment endpoint nodes within the domain are able to nodes and SR segment endpoint nodes within the domain are able to
utilizing the services of the Domain. If a node outside the SR utilize the services of the Domain. If a node outside the SR Domain
Domain learns of segments or a topological service within the SR learns of segments or a topological service within the SR domain,
domain, IACL filtering denies access to those segments. IACL filtering denies access to those segments.
Nodes outside the SR Domain, capable of intercepting packets from SR
Source nodes not directly connected to the SR Domain utilizing the
SRH HMAC, may steel the outer IP header SRH and HMAC TLV. If such an
attacker is capable of spoofing the source address of the original
sender it may use the IP header and HMAC to access services of the SR
Domain intended for the original SR Source node.
Frequent rekeying of the HMAC TLV helps mitigate against this attack
but cannot prevent it.
However, as described in Section 6.2.1, there exist use cases where
the risk of service threat is of minimum concern and the HMAC TLV is
used primarily to validate that the source is permitted to use the
segment list in the SRH.
7.3. Topology Disclosure 7.3. Topology Disclosure
The SRH may contains SIDs of some intermediate SR-nodes in the path The SRH may contains SIDs of some intermediate SR-nodes in the path
towards the destination, this reveals those addresses to attackers if towards the destination, this reveals those addresses to attackers if
they are able to intercept packets containing SRH. they are able to intercept packets containing SRH.
This is applicable within an SR Domain but the disclosure is less This is applicable within an SR Domain but the disclosure is less
relevant as an attacker has other means of learning topology. relevant as an attacker has other means of learning topology.
For an SR Source node not directly connected to the SR Domain this
disclosure is applicable. While the segments within the SR domain
disclosed in SRH are protected by ingress filtering, they may be
learned by an attacker external to the SR Domain.
As described in Section 6.2.1, there exist use cases where the risk
of topology disclosure is of minimum concern when the HMAC TLV is
used primarily to validate that the source is permitted to use the
segment list in the SRH.
7.4. ICMP Generation 7.4. ICMP Generation
The generation of ICMPv6 error messages may be used to attempt The generation of ICMPv6 error messages may be used to attempt
denial-of-service attacks by sending an error-causing destination denial-of-service attacks by sending an error-causing destination
address or SRH in back-to-back packets. An implementation that address or SRH in back-to-back packets. An implementation that
correctly follows Section 2.4 of [RFC4443] would be protected by the correctly follows Section 2.4 of [RFC4443] would be protected by the
ICMPv6 rate-limiting mechanism. ICMPv6 rate-limiting mechanism.
8. IANA Considerations 8. IANA Considerations
skipping to change at page 25, line 45 skipping to change at page 27, line 10
National Institute of Standards and Technology, "FIPS National Institute of Standards and Technology, "FIPS
180-4 Secure Hash Standard (SHS)", March 2012, 180-4 Secure Hash Standard (SHS)", March 2012,
<http://csrc.nist.gov/publications/fips/fips180-4/ <http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>. fips-180-4.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <https://www.rfc-editor.org/info/rfc2473>.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095, of Type 0 Routing Headers in IPv6", RFC 5095,
DOI 10.17487/RFC5095, December 2007, DOI 10.17487/RFC5095, December 2007,
<https://www.rfc-editor.org/info/rfc5095>. <https://www.rfc-editor.org/info/rfc5095>.
[RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
of Interpretation", RFC 6407, DOI 10.17487/RFC6407, of Interpretation", RFC 6407, DOI 10.17487/RFC6407,
October 2011, <https://www.rfc-editor.org/info/rfc6407>. October 2011, <https://www.rfc-editor.org/info/rfc6407>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
skipping to change at page 26, line 35 skipping to change at page 27, line 49
[I-D.filsfils-spring-srv6-interop] [I-D.filsfils-spring-srv6-interop]
Filsfils, C., Clad, F., Camarillo, P., Abdelsalam, A., Filsfils, C., Clad, F., Camarillo, P., Abdelsalam, A.,
Salsano, S., Bonaventure, O., Horn, J., and J. Liste, Salsano, S., Bonaventure, O., Horn, J., and J. Liste,
"SRv6 interoperability report", draft-filsfils-spring- "SRv6 interoperability report", draft-filsfils-spring-
srv6-interop-01 (work in progress), September 2018. srv6-interop-01 (work in progress), September 2018.
[I-D.filsfils-spring-srv6-network-programming] [I-D.filsfils-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Filsfils, C., Camarillo, P., Leddy, J.,
daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6 daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
Network Programming", draft-filsfils-spring-srv6-network- Network Programming", draft-filsfils-spring-srv6-network-
programming-05 (work in progress), July 2018. programming-06 (work in progress), October 2018.
[I-D.ietf-spring-segment-routing-mpls] [I-D.ietf-spring-segment-routing-mpls]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-14 data plane", draft-ietf-spring-segment-routing-mpls-18
(work in progress), June 2018. (work in progress), December 2018.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>. <https://www.rfc-editor.org/info/rfc2104>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>. <https://www.rfc-editor.org/info/rfc3032>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005, DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>. <https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89, Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>. <https://www.rfc-editor.org/info/rfc4443>.
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron,
"Encapsulation Methods for Transport of Ethernet over MPLS
Networks", RFC 4448, DOI 10.17487/RFC4448, April 2006,
<https://www.rfc-editor.org/info/rfc4448>.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
DOI 10.17487/RFC5308, October 2008, DOI 10.17487/RFC5308, October 2008,
<https://www.rfc-editor.org/info/rfc5308>. <https://www.rfc-editor.org/info/rfc5308>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>. <https://www.rfc-editor.org/info/rfc5340>.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation in for Equal Cost Multipath Routing and Link Aggregation in
 End of changes. 66 change blocks. 
254 lines changed or deleted 315 lines changed or added

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