draft-ietf-6man-segment-routing-header-21.txt   draft-ietf-6man-segment-routing-header-22.txt 
Network Working Group C. Filsfils, Ed. Network Working Group C. Filsfils, Ed.
Internet-Draft D. Dukes, Ed. Internet-Draft D. Dukes, Ed.
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: December 15, 2019 S. Previdi Expires: February 7, 2020 S. Previdi
Huawei Huawei
J. Leddy J. Leddy
Individual Individual
S. Matsushima S. Matsushima
Softbank Softbank
D. Voyer D. Voyer
Bell Canada Bell Canada
June 13, 2019 August 6, 2019
IPv6 Segment Routing Header (SRH) IPv6 Segment Routing Header (SRH)
draft-ietf-6man-segment-routing-header-21 draft-ietf-6man-segment-routing-header-22
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 called the Segment Routing Header.
Segment Routing Extension Header and how it is used by Segment This document describes the Segment Routing Header and how it is used
Routing capable nodes. by Segment Routing capable nodes.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 December 15, 2019. This Internet-Draft will expire on February 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Segment Routing Extension Header . . . . . . . . . . . . . . 4 2. Segment Routing Header . . . . . . . . . . . . . . . . . . . 4
2.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1. Padding TLVs . . . . . . . . . . . . . . . . . . . . 8 2.1.1. Padding TLVs . . . . . . . . . . . . . . . . . . . . 8
2.1.2. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 9 2.1.2. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 9
3. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 11 3. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 12 3.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 12
3.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 12 3.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 12
3.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 12 3.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 12
4. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 12 4. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 12 4.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 12
4.1.1. Reduced SRH . . . . . . . . . . . . . . . . . . . . . 13 4.1.1. Reduced SRH . . . . . . . . . . . . . . . . . . . . . 13
4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 13
4.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 13 4.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 14
4.3.1. FIB Entry Is Locally Instantiated SRv6 SID . . . . . 14 4.3.1. FIB Entry Is Locally Instantiated SRv6 SID . . . . . 14
4.3.2. FIB Entry is a Local Interface . . . . . . . . . . . 16 4.3.2. FIB Entry is a Local Interface . . . . . . . . . . . 16
4.3.3. FIB Entry Is A Non-Local Route . . . . . . . . . . . 17 4.3.3. FIB Entry Is A Non-Local Route . . . . . . . . . . . 17
4.3.4. FIB Entry Is A No Match . . . . . . . . . . . . . . . 17 4.3.4. FIB Entry Is A No Match . . . . . . . . . . . . . . . 17
5. Intra SR Domain Deployment Model . . . . . . . . . . . . . . 17 5. Intra SR Domain Deployment Model . . . . . . . . . . . . . . 17
5.1. Securing the SR Domain . . . . . . . . . . . . . . . . . 17 5.1. Securing the SR Domain . . . . . . . . . . . . . . . . . 17
5.2. SR Domain as a single system with delegation among 5.2. SR Domain as a single system with delegation among
components . . . . . . . . . . . . . . . . . . . . . . . 18 components . . . . . . . . . . . . . . . . . . . . . . . 18
5.3. MTU Considerations . . . . . . . . . . . . . . . . . . . 19 5.3. MTU Considerations . . . . . . . . . . . . . . . . . . . 19
5.4. ICMP Error Processing . . . . . . . . . . . . . . . . . . 19 5.4. ICMP Error Processing . . . . . . . . . . . . . . . . . . 19
5.5. Load Balancing and ECMP . . . . . . . . . . . . . . . . . 19 5.5. Load Balancing and ECMP . . . . . . . . . . . . . . . . . 19
5.6. Other Deployments . . . . . . . . . . . . . . . . . . . . 20 5.6. Other Deployments . . . . . . . . . . . . . . . . . . . . 20
6. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 20 6. Illustrations . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Abstract Representation of an SRH . . . . . . . . . . . . 20 6.1. Abstract Representation of an SRH . . . . . . . . . . . . 20
6.2. Example Topology . . . . . . . . . . . . . . . . . . . . 21 6.2. Example Topology . . . . . . . . . . . . . . . . . . . . 21
6.3. Source SR Node . . . . . . . . . . . . . . . . . . . . . 21 6.3. Source SR Node . . . . . . . . . . . . . . . . . . . . . 22
6.3.1. Intra SR Domain Packet . . . . . . . . . . . . . . . 22 6.3.1. Intra SR Domain Packet . . . . . . . . . . . . . . . 22
6.3.2. Inter SR Domain Packet - Transit . . . . . . . . . . 22 6.3.2. Inter SR Domain Packet - Transit . . . . . . . . . . 22
6.3.3. Inter SR Domain Packet - Internal to External . . . . 22 6.3.3. Inter SR Domain Packet - Internal to External . . . . 22
6.4. Transit Node . . . . . . . . . . . . . . . . . . . . . . 23 6.4. Transit Node . . . . . . . . . . . . . . . . . . . . . . 23
6.5. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 23 6.5. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 23
6.6. Delegation of Function with HMAC Verification . . . . . . 23 6.6. Delegation of Function with HMAC Verification . . . . . . 23
6.6.1. SID List Verification . . . . . . . . . . . . . . . . 23 6.6.1. SID List Verification . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7.1. Source Routing Attacks . . . . . . . . . . . . . . . . . 24 7.1. Source Routing Attacks . . . . . . . . . . . . . . . . . 24
skipping to change at page 3, line 31 skipping to change at page 3, line 31
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. Normative References . . . . . . . . . . . . . . . . . . 29 12.1. Normative References . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . 30 12.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
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 Header called the Segment Routing Header. This
Segment Routing Extension Header and how it is used by Segment document describes the Segment Routing Header and how it is used by
Routing capable nodes. Segment 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.
The encoding of IPv6 segments in the Segment Routing Extension Header The encoding of IPv6 segments in the Segment Routing Header is
is defined in this document. defined in this document.
Terminology used within this document is defined in detail in This document uses the terms Segment Routing, SR Domain, SRv6,
[RFC8402]. Specifically, these terms: Segment Routing, SR Domain, Segment ID (SID), SRv6 SID, Active Segment, and SR Policy as defined
SRv6, Segment ID (SID), SRv6 SID, Active Segment, and SR Policy. in [RFC8402].
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Segment Routing Extension Header 2. Segment Routing Header
Routing Headers are defined in [RFC8200]. The Segment Routing Header Routing Headers are defined in [RFC8200]. The Segment Routing Header
has a new Routing Type (suggested value 4) to be assigned by IANA. has a new Routing Type (suggested value 4) to be assigned by IANA.
The Segment Routing Header (SRH) is defined as follows: The Segment Routing Header (SRH) is defined as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 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 Header | Hdr Ext Len | Routing Type | Segments Left | | Next Header | Hdr Ext Len | Routing Type | Segments Left |
skipping to change at page 5, line 34 skipping to change at page 5, line 34
o Segment List[n]: 128 bit IPv6 addresses representing the nth o Segment List[n]: 128 bit IPv6 addresses representing the nth
segment in the Segment List. The Segment List is encoded starting segment in the Segment List. The Segment List is encoded starting
from the last segment of the SR Policy. I.e., the first element from the last segment of the SR Policy. I.e., the first element
of the segment list (Segment List [0]) contains the last segment of the segment list (Segment List [0]) contains the last segment
of the SR Policy, the second element contains the penultimate of the SR Policy, the second element contains the penultimate
segment of the SR Policy and so on. segment of the SR Policy and so on.
o Type Length Value (TLV) are described in Section 2.1. o Type Length Value (TLV) are described in Section 2.1.
In the SRH, the Next Header, Hdr Ext Len, and Routing Type fields are In the SRH, the Next Header, Hdr Ext Len, Routing Type, and Segments
defined in Section 4.4 of [RFC8200] as not mutable. The Segments Left fields are defined in Section 4.4 of [RFC8200]. Based on the
Left field is defined as mutable in Section 4.4 of [RFC8200]. constraints in that section Next Header, Header Ext Len, and Routing
Type are not mutable while Segments Left is mutable.
The mutability of the TLV value is defined by the most significant The mutability of the TLV value is defined by the most significant
bit in the type, as specified in Section 2.1. bit in the type, as specified in Section 2.1.
Section 4.3 defines the mutability of the remaining fields in the SRH Section 4.3 defines the mutability of the remaining fields in the SRH
(Flags, Tag, Segment List) in the context of the SID defined in this (Flags, Tag, Segment List) in the context of the SID defined in this
document. document.
New SIDs defined in the future MUST specify the mutability properties New SIDs defined in the future MUST specify the mutability properties
of the Flags, Tag, and Segment List and indicate how the HMAC TLV of the Flags, Tag, and Segment List and indicate how the HMAC TLV
skipping to change at page 6, line 22 skipping to change at page 6, line 25
A TLV provides meta-data for segment processing. The only TLVs A TLV provides meta-data for segment processing. The only TLVs
defined in this document are the HMAC (Section 2.1.2) and PAD defined in this document are the HMAC (Section 2.1.2) and PAD
(Section 2.1.1) TLVs. While processing the SID defined in (Section 2.1.1) TLVs. While processing the SID defined in
Section 4.3.1, all TLVs are ignored unless local configuration Section 4.3.1, all TLVs are ignored unless local configuration
indicates otherwise (Section 4.3.1.1.1). Thus, TLV and HMAC support indicates otherwise (Section 4.3.1.1.1). Thus, TLV and HMAC support
is optional for any implementation, however an implementation adding is optional for any implementation, however an implementation adding
or parsing TLVs MUST support PAD TLVs. Other documents may define or parsing TLVs MUST support PAD TLVs. Other documents may define
additional TLVs and processing rules for them. additional TLVs and processing rules for them.
TLVs are present when the Hdr Ext Len exceeds the Last Entry element TLVs are present when the Hdr Ext Len is greater than (Last
in the Segment List. Entry+1)*2.
While processing TLVs at a segment endpoint, TLVs MUST be fully While processing TLVs at a segment endpoint, TLVs MUST be fully
contained within the SRH as determined by the Hdr Ext Len. Detection contained within the SRH as determined by the Hdr Ext Len. Detection
of TLVs exceeding the boundary of the SRH Hdr Ext Len results in an of TLVs exceeding the boundary of the SRH Hdr Ext Len results in an
ICMP Parameter Problem, Code 0, message to the Source Address, ICMP Parameter Problem, Code 0, message to the Source Address,
pointing to the Hdr Ext Len field of the SRH, and the packet being pointing to the Hdr Ext Len field of the SRH, and the packet being
discarded. discarded.
An implementation MAY limit the number and/or length of TLVs it An implementation MAY limit the number and/or length of TLVs it
processes based on local configuration. It MAY: processes based on local configuration. It MAY:
skipping to change at page 8, line 10 skipping to change at page 8, line 10
HMAC TLV HMAC TLV
Additional TLVs may be defined in the future. Additional TLVs may be defined in the future.
2.1.1. Padding TLVs 2.1.1. Padding TLVs
There are two types of padding TLVs, pad1 and padN, the following There are two types of padding TLVs, pad1 and padN, the following
applies to both: applies to both:
Padding TLVs are used for meeting the alignment requirement of the
subsequent TLVs.
Padding TLVs are used to pad the SRH to a multiple of 8 octets. Padding TLVs are used to pad the SRH to a multiple of 8 octets.
Padding TLVs are used for alignment. Padding TLVs are used for alignment.
Padding TLVs are ignored by a node processing the SRH TLV. Padding TLVs are ignored by a node processing the SRH TLV.
Multiple Padding TLVs MAY be used in one SRH Multiple Padding TLVs MAY be used in one SRH
2.1.1.1. PAD1 2.1.1.1. PAD1
skipping to change at page 9, line 37 skipping to change at page 9, line 40
where: where:
o Type: to be assigned by IANA (suggested value 5). o Type: to be assigned by IANA (suggested value 5).
o Length: 38. o Length: 38.
o RESERVED: 2 octets. MUST be 0 on transmission and ignored on o RESERVED: 2 octets. MUST be 0 on transmission and ignored on
receipt. receipt.
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.
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.
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 and Verification 2.1.2.1. HMAC Generation and Verification
Local configuration determines when to check for an HMAC and Local configuration determines when to check for an HMAC and
potentially provides an alternate composition of Text, and a potentially indicates what the HMAC protects, and a requirement on
requirement on where the HMAC TLV must appear (e.g. first TLV), and where the HMAC TLV must appear (e.g. first TLV), and whether or not
whether or not to verify the destination address is equal to the to verify the destination address is equal to the current segment.
current segment. This local configuration is outside the scope of This local configuration is outside the scope of this document. It
this document. It may be based on the active segment at an SR may be based on the active segment at an SR Segment endpoint node,
Segment endpoint node, the result of an ACL that considers incoming the result of an ACL that considers incoming interface, HMAC Key ID,
interface, HMAC Key ID, or other packet fields. or other packet fields.
An implementation that supports the generation and verification of An implementation that supports the generation and verification of
the HMAC SHOULD support the following default behavior as defined in the HMAC SHOULD support the following default behavior as defined in
the remainder of this section. the remainder of this section.
The HMAC verification begins by checking the current segment is equal The HMAC verification begins by checking the current segment is equal
to the destination address of the IPv6 header, i.e. destination to the destination address of the IPv6 header, i.e. destination
address is equal to Segment List [Segments Left] and Segments Left is address is equal to Segment List [Segments Left] and Segments Left is
less than or equal to Last Segment+1. less than or equal to Last Segment+1.
skipping to change at page 11, line 31 skipping to change at page 11, line 38
the destination address with the Key ID allows for overlapping key the destination address with the Key ID allows for overlapping key
IDs amongst different HMAC verification nodes. The Text for the HMAC IDs amongst different HMAC verification nodes. The Text for the HMAC
computation is set to the IPv6 header fields and SRH fields as they computation is set to the IPv6 header fields and SRH fields as they
would appear at the verification node, not necessarily the same as would appear at the verification node, not necessarily the same as
the source node sending a packet with the HMAC TLV. the source node sending a packet with the HMAC TLV.
Pre-shared key roll-over is supported by having two key IDs in use Pre-shared key roll-over is supported by having two key IDs in use
while the HMAC TLV generating node and verifying node converge to a while the HMAC TLV generating node and verifying node converge to a
new key. new key.
SRH implementations can support multiple hash functions but MUST An implementation supporting HMAC can support multiple hash
implement SHA-2 [FIPS180-4] in its SHA-256 variant. functions. An implementation supporting HMAC MUST implement SHA-2
[FIPS180-4] in its SHA-256 variant.
The selection of pre-shared key and algorithm, and their distribution The selection of pre-shared key and algorithm, and their distribution
is outside the scope of this document, some options may include: is outside the scope of this document, some options may include:
o in the configuration of the HMAC generating or verifying nodes, o in the configuration of the HMAC generating or verifying nodes,
either by static configuration or any SDN oriented approach either by static configuration or any SDN oriented approach
o dynamically using a trusted key distribution protocol such as o dynamically using a trusted key distribution protocol such as
[RFC6407] [RFC6407]
skipping to change at page 19, line 7 skipping to change at page 19, line 7
any packet destined to the SID block of the SR Domain (S/s). T 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 checks and verifies that SRH1 is valid, contains an HMAC TLV and
verifies the HMAC. verifies the HMAC.
An operator of the SR Domain may choose to have all segments in the An operator of the SR Domain may choose to have all segments in the
SR Domain verify the HMAC. This mechanism would verify that the SRH SR Domain verify the HMAC. This mechanism would verify that the SRH
segment list is not modified while traversing the SR Domain. segment list is not modified while traversing the SR Domain.
5.3. MTU Considerations 5.3. MTU Considerations
Within the SR Domain, well known mitigation techniques are An SR Domain ingress edge node encapsulates packets traversing the SR
RECOMMENDED, such as deploying a greater MTU value within the SR Domain, and needs to consider the MTU of the SR Domain. Within the
Domain than at the ingress edges. 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. ICMP Error Processing 5.4. ICMP Error Processing
ICMP error packets generated within the SR Domain are sent to source ICMP error packets generated within the SR Domain are sent to source
nodes within the SR Domain. The invoking packet in the ICMP error nodes within the SR Domain. The invoking packet in the ICMP error
message may contain an SRH. Since the destination address of a message may contain an SRH. Since the destination address of a
packet with an SRH changes as each segment is processed, it may not packet with an SRH changes as each segment is processed, it may not
be the destination used by the socket or application that generated be the destination used by the socket or application that generated
the invoking packet. the invoking packet.
For the source of an invoking packet to process the ICMP error For the source of an invoking packet to process the ICMP error
message, the correct destination address must be determined. The message, the correct destination address must be determined. The
following logic is used to determine the destination address for use following logic is used to determine the destination address for use
by protocol error handlers. by protocol error handlers.
o Walk all extension headers of the invoking IPv6 packet to the o Walk all extension headers of the invoking IPv6 packet to the
routing extension header preceding the upper layer header. routing extension header preceding the upper layer header.
* If routing header is type 4 (SRH) * If routing header is type 4 (SRH)
+ Use the 0th segment in the segment list as the destination + Use the SID at Segment List[0] as the destination address of
address of the invoking packet. the invoking packet.
ICMP errors are then processed by upper layer transports as defined ICMP errors are then processed by upper layer transports as defined
in [RFC4443]. in [RFC4443].
For IP packets encapsulated in an outer IPv6 header, ICMP error For IP packets encapsulated in an outer IPv6 header, ICMP error
handling is as defined in [RFC2473]. handling is as defined in [RFC2473].
5.5. Load Balancing and ECMP 5.5. Load Balancing and ECMP
For any inter domain packet, the SR Source node MUST impose a flow For any inter domain packet, the SR Source node MUST impose a flow
 End of changes. 22 change blocks. 
42 lines changed or deleted 48 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/