draft-ietf-6man-segment-routing-header-08.txt   draft-ietf-6man-segment-routing-header-09.txt 
Network Working Group S. Previdi, Ed. Network Working Group S. Previdi, Ed.
Internet-Draft Individual Internet-Draft Individual
Intended status: Standards Track C. Filsfils Intended status: Standards Track C. Filsfils
Expires: July 24, 2018 K. Raza Expires: September 6, 2018 K. Raza
D. Dukes D. Dukes
Cisco Systems, Inc. Cisco Systems, Inc.
J. Leddy J. Leddy
B. Field B. Field
Comcast Comcast
D. Voyer D. Voyer
D. Bernier D. Bernier
Bell Canada Bell Canada
S. Matsushima S. Matsushima
Softbank Softbank
skipping to change at page 1, line 33 skipping to change at page 1, line 33
T. Kosugi T. Kosugi
NTT NTT
E. Vyncke E. Vyncke
Cisco Systems, Inc. Cisco Systems, Inc.
D. Lebrun D. Lebrun
Universite Catholique de Louvain Universite Catholique de Louvain
D. Steinberg D. Steinberg
Steinberg Consulting Steinberg Consulting
R. Raszuk R. Raszuk
Bloomberg Bloomberg
January 20, 2018 March 5, 2018
IPv6 Segment Routing Header (SRH) IPv6 Segment Routing Header (SRH)
draft-ietf-6man-segment-routing-header-08 draft-ietf-6man-segment-routing-header-09
Abstract Abstract
Segment Routing (SR) allows a node to steer a packet through a Segment Routing (SR) allows a node to steer a packet through a
controlled set of instructions, called segments, by prepending an SR controlled set of instructions, called segments, by prepending an SR
header to the packet. A segment can represent any instruction, header to the packet. A segment can represent any instruction,
topological or service-based. SR allows to enforce a flow through topological or service-based. SR allows to enforce a flow through
any path (topological, or application/service based) while any path (topological, or application/service based) while
maintaining per-flow state only at the ingress node to the SR domain. maintaining per-flow state only at the ingress node to the SR domain.
skipping to change at page 2, line 28 skipping to change at page 2, line 28
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 July 24, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
skipping to change at page 3, line 22 skipping to change at page 3, line 22
2.3.1. SR Domain in a Service Provider Network . . . . . . . 6 2.3.1. SR Domain in a Service Provider Network . . . . . . . 6
2.3.2. SR Domain in a Overlay Network . . . . . . . . . . . 7 2.3.2. SR Domain in a Overlay Network . . . . . . . . . . . 7
3. Segment Routing Extension Header (SRH) . . . . . . . . . . . 9 3. Segment Routing Extension Header (SRH) . . . . . . . . . . . 9
3.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1. SRH TLVs . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.1. Ingress Node TLV . . . . . . . . . . . . . . . . . . 11 3.1.1. Ingress Node TLV . . . . . . . . . . . . . . . . . . 11
3.1.2. Egress Node TLV . . . . . . . . . . . . . . . . . . . 12 3.1.2. Egress Node TLV . . . . . . . . . . . . . . . . . . . 12
3.1.3. Opaque Container TLV . . . . . . . . . . . . . . . . 13 3.1.3. Opaque Container TLV . . . . . . . . . . . . . . . . 13
3.1.4. Padding TLV . . . . . . . . . . . . . . . . . . . . . 14 3.1.4. Padding TLV . . . . . . . . . . . . . . . . . . . . . 14
3.1.5. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 14 3.1.5. HMAC TLV . . . . . . . . . . . . . . . . . . . . . . 14
3.1.6. NSH Carrier TLV . . . . . . . . . . . . . . . . . . . 15 3.1.6. NSH Carrier TLV . . . . . . . . . . . . . . . . . . . 15
3.2. SRH and RFC2460 behavior . . . . . . . . . . . . . . . . 16 3.2. SRH and RFC8200 behavior . . . . . . . . . . . . . . . . 16
4. SRH Functions . . . . . . . . . . . . . . . . . . . . . . . . 16 4. SRH Functions . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Endpoint Function (End) . . . . . . . . . . . . . . . . . 17 4.1. Endpoint Function (End) . . . . . . . . . . . . . . . . . 17
4.2. End.X: Endpoint with Layer-3 cross-connect . . . . . . . 18 4.2. End.X: Endpoint with Layer-3 cross-connect . . . . . . . 18
5. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5. SR Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 19 5.1. Source SR Node . . . . . . . . . . . . . . . . . . . . . 19
5.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 20 5.2. Transit Node . . . . . . . . . . . . . . . . . . . . . . 20
5.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 20 5.3. SR Segment Endpoint Node . . . . . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 21 6.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 21
6.1.1. Source routing threats . . . . . . . . . . . . . . . 21 6.1.1. Source routing threats . . . . . . . . . . . . . . . 21
skipping to change at page 4, line 42 skipping to change at page 4, line 42
derived from different components: IGP, BGP, Services, Contexts, derived from different components: IGP, BGP, Services, Contexts,
Locators, etc. The list of segment forming the path is called the Locators, etc. The list of segment forming the path is called the
Segment List and is encoded in the packet header. Segment List and is encoded in the packet header.
SR allows the use of strict and loose source based routing paradigms SR allows the use of strict and loose source based routing paradigms
without requiring any additional signaling protocols in the without requiring any additional signaling protocols in the
infrastructure hence delivering an excellent scalability property. infrastructure hence delivering an excellent scalability property.
The source based routing model described in The source based routing model described in
[I-D.ietf-spring-segment-routing] is inherited from the ones proposed [I-D.ietf-spring-segment-routing] is inherited from the ones proposed
by [RFC1940] and [RFC2460]. The source based routing model offers by [RFC1940] and [RFC8200]. The source based routing model offers
the support for explicit routing capability. the support for explicit routing capability.
2.1. Data Planes supporting Segment Routing 2.1. Data Planes supporting Segment Routing
Segment Routing (SR), can be instantiated over MPLS Segment Routing (SR), can be instantiated over MPLS
([I-D.ietf-spring-segment-routing-mpls]) and IPv6. This document ([I-D.ietf-spring-segment-routing-mpls]) and IPv6. This document
defines its instantiation over the IPv6 data-plane based on the use- defines its instantiation over the IPv6 data-plane based on the use-
cases defined in [I-D.ietf-spring-ipv6-use-cases]. cases defined in [I-D.ietf-spring-ipv6-use-cases].
This document defines a new type of Routing Header (originally This document defines a new type of Routing Header (originally
defined in [RFC2460]) called the Segment Routing Header (SRH) in defined in [RFC8200]) called the Segment Routing Header (SRH) in
order to convey the Segment List in the packet header as defined in order to convey the Segment List in the packet header as defined in
[I-D.ietf-spring-segment-routing]. Mechanisms through which segment [I-D.ietf-spring-segment-routing]. Mechanisms through which segment
are known and advertised are outside the scope of this document. are known and advertised are outside the scope of this document.
2.2. SRv6 Segment 2.2. SRv6 Segment
An SRv6 Segment is a 128-bit value. "SRv6 SID" or simply "SID" are An SRv6 Segment is a 128-bit value. "SRv6 SID" or simply "SID" are
often used as a shorter reference for "SRv6 Segment". often used as a shorter reference for "SRv6 Segment".
An SRv6-capable node N maintains a "My Local SID Table". This table An SRv6-capable node N maintains a "My Local SID Table". This table
skipping to change at page 6, line 22 skipping to change at page 6, line 22
segments belonging solely to the overlay routers (the SR domain). segments belonging solely to the overlay routers (the SR domain).
None of the segments in the SR-enabled packets exchanged by the None of the segments in the SR-enabled packets exchanged by the
overlay belong to the transit networks overlay belong to the transit networks
The source based routing model through its instantiation of the The source based routing model through its instantiation of the
Segment Routing Header (SRH) defined in this document equally applies Segment Routing Header (SRH) defined in this document equally applies
to all the above examples. to all the above examples.
It is assumed in this document that the SRH is added to the packet by It is assumed in this document that the SRH is added to the packet by
its source, consistently with the source routing model defined in its source, consistently with the source routing model defined in
[RFC2460]. For example: [RFC8200]. For example:
o At the node originating the packet (host, server). o At the node originating the packet (host, server).
o At the ingress node of an SR domain where the ingress node o At the ingress node of an SR domain where the ingress node
receives an IPv6 packet and encapsulates it into an outer IPv6 receives an IPv6 packet and encapsulates it into an outer IPv6
header followed by a Segment Routing header. header followed by a Segment Routing header.
2.3.1. SR Domain in a Service Provider Network 2.3.1. SR Domain in a Service Provider Network
The following figure illustrates an SR domain consisting of an The following figure illustrates an SR domain consisting of an
skipping to change at page 8, line 38 skipping to change at page 8, line 38
Each node may originate packets with an SRH which contains, in the Each node may originate packets with an SRH which contains, in the
segment list of the SRH or in the DA, segments identifying other segment list of the SRH or in the DA, segments identifying other
overlay nodes. This implies that packets with an SRH may traverse overlay nodes. This implies that packets with an SRH may traverse
operator's networks but, obviously, these SRHs cannot contain an operator's networks but, obviously, these SRHs cannot contain an
address/segment of the transit operators 1, 2 and 3. The SRH address/segment of the transit operators 1, 2 and 3. The SRH
originated by the overlay can only contain address/segment under the originated by the overlay can only contain address/segment under the
administration of the overlay (e.g. address/segments supported by A1, administration of the overlay (e.g. address/segments supported by A1,
A2, A3, B1, B2, B3, C1,C2 or C3). A2, A3, B1, B2, B3, C1,C2 or C3).
In this model, the operator network nodes are transit nodes and, In this model, the operator network nodes are transit nodes and,
according to [RFC2460], MUST NOT inspect the routing extension header according to [RFC8200], MUST NOT inspect the routing extension header
since they are not the DA of the packet. since they are not the DA of the packet.
It is a common practice in operators networks to filter out, at It is a common practice in operators networks to filter out, at
ingress, any packet whose DA is the address of an internal node and ingress, any packet whose DA is the address of an internal node and
it is also possible that an operator would filter out any packet it is also possible that an operator would filter out any packet
destined to an internal address and having an extension header in it. destined to an internal address and having an extension header in it.
This common practice does not impact the SR-enabled traffic between This common practice does not impact the SR-enabled traffic between
the overlay nodes as the intermediate transit networks never see a the overlay nodes as the intermediate transit networks never see a
destination address belonging to their infrastructure. These SR- destination address belonging to their infrastructure. These SR-
enabled overlay packets will thus never be filtered by the transit enabled overlay packets will thus never be filtered by the transit
operators. operators.
In all cases, transit packets (i.e.: packets whose DA is outside the In all cases, transit packets (i.e.: packets whose DA is outside the
domain of the operator's network) will be forwarded accordingly domain of the operator's network) will be forwarded accordingly
without introducing any security concern in the operator's network. without introducing any security concern in the operator's network.
This is similar to tunneled packets. This is similar to tunneled packets.
3. Segment Routing Extension Header (SRH) 3. Segment Routing Extension Header (SRH)
A new type of the Routing Header (originally defined in [RFC2460]) is A new type of the Routing Header (originally defined in [RFC8200]) is
defined: the Segment Routing Header (SRH) which has a new Routing defined: the Segment Routing Header (SRH) which has a new Routing
Type, (suggested value 4) to be assigned by IANA. 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 10, line 10 skipping to change at page 10, line 10
where: where:
o Next Header: 8-bit selector. Identifies the type of header o Next Header: 8-bit selector. Identifies the type of header
immediately following the SRH. immediately following the SRH.
o Hdr Ext Len: 8-bit unsigned integer, is the length of the SRH o Hdr Ext Len: 8-bit unsigned integer, is the length of the SRH
header in 8-octet units, not including the first 8 octets. header in 8-octet units, not including the first 8 octets.
o Routing Type: TBD, to be assigned by IANA (suggested value: 4). o Routing Type: TBD, to be assigned by IANA (suggested value: 4).
o Segments Left. Defined in [RFC2460], it contains the index, in o Segments Left. Defined in [RFC8200], it contains the index, in
the Segment List, of the next segment to inspect. Segments Left the Segment List, of the next segment to inspect. Segments Left
is decremented at each segment. is decremented at each segment.
o Last Entry: contains the index, in the Segment List, of the last o Last Entry: contains the index, in the Segment List, of the last
element of the Segment List. element of the Segment List.
o Flags: 8 bits of flags. Following flags are defined: o Flags: 8 bits of flags. Following flags are defined:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
skipping to change at page 16, line 24 skipping to change at page 16, line 24
o Type: to be assigned by IANA (suggested value 6). o Type: to be assigned by IANA (suggested value 6).
o Length: the total length of the TLV. o Length: the total length of the TLV.
o Flags: 8 bits. No flags are defined in this document. SHOULD be o Flags: 8 bits. No flags are defined in this document. SHOULD be
set to 0 on transmission and MUST be ignored on receipt. set to 0 on transmission and MUST be ignored on receipt.
o NSH Carried Object: the content of the TLV which consists of the o NSH Carried Object: the content of the TLV which consists of the
NSH data as defined in [I-D.ietf-sfc-nsh]. NSH data as defined in [I-D.ietf-sfc-nsh].
3.2. SRH and RFC2460 behavior 3.2. SRH and RFC8200 behavior
The SRH being a new type of the Routing Header, it also has the same The SRH being a new type of the Routing Header, it also has the same
properties: properties:
SHOULD only appear once in the packet. SHOULD only appear once in the packet.
Only the router whose address is in the DA field of the packet Only the router whose address is in the DA field of the packet
header MUST inspect the SRH. header MUST inspect the SRH.
Therefore, Segment Routing in IPv6 networks implies that the segment Therefore, Segment Routing in IPv6 networks implies that the segment
skipping to change at page 19, line 36 skipping to change at page 19, line 36
Local path computation. Local path computation.
Local configuration. Local configuration.
Interaction with a centralized controller delivering the path. Interaction with a centralized controller delivering the path.
Any other mechanism. Any other mechanism.
The following are the steps of the creation of the SRH: The following are the steps of the creation of the SRH:
Next Header and Hdr Ext Len fields are set according to [RFC2460]. Next Header and Hdr Ext Len fields are set according to [RFC8200].
Routing Type field is set as TBD (to be allocated by IANA, Routing Type field is set as TBD (to be allocated by IANA,
suggested value 4). suggested value 4).
The DA of the packet is set with the value of the first segment. The DA of the packet is set with the value of the first segment.
). ).
The first element of the segment list is the last segment (the The first element of the segment list is the last segment (the
final DA of the packet). The second element is the penultimate final DA of the packet). The second element is the penultimate
segment and so on. segment and so on.
skipping to change at page 20, line 18 skipping to change at page 20, line 18
The packet is sent out towards the packet's DA (the first The packet is sent out towards the packet's DA (the first
segment). segment).
HMAC TLV may be set according to Section 6. HMAC TLV may be set according to Section 6.
If the segment list contains a single segment and there is no need If the segment list contains a single segment and there is no need
for information in flag or TLV, then the SRH MAY be omitted. for information in flag or TLV, then the SRH MAY be omitted.
5.2. Transit Node 5.2. Transit Node
According to [RFC2460], the only node who is allowed to inspect the According to [RFC8200], the only node who is allowed to inspect the
Routing Extension Header (and therefore the SRH), is the node Routing Extension Header (and therefore the SRH), is the node
corresponding to the DA of the packet. Any other transit node MUST corresponding to the DA of the packet. Any other transit node MUST
NOT inspect the underneath routing header and MUST forward the packet NOT inspect the underneath routing header and MUST forward the packet
towards the DA and according to the IPv6 routing table. towards the DA and according to the IPv6 routing table.
In the example case described in Section 2.3.2, when SR capable nodes In the example case described in Section 2.3.2, when SR capable nodes
are connected through an overlay spanning multiple third-party are connected through an overlay spanning multiple third-party
infrastructure, it is safe to send SRH packets (i.e.: packet having a infrastructure, it is safe to send SRH packets (i.e.: packet having a
Segment Routing Header) between each other overlay/SR-capable nodes Segment Routing Header) between each other overlay/SR-capable nodes
as long as the segment list does not include any of the transit as long as the segment list does not include any of the transit
skipping to change at page 20, line 48 skipping to change at page 20, line 48
The segment endpoint node executes the function bound to the SID as The segment endpoint node executes the function bound to the SID as
per the matched MyLocalSID entry (Section 4). per the matched MyLocalSID entry (Section 4).
6. Security Considerations 6. Security Considerations
This section analyzes the security threat model, the security issues This section analyzes the security threat model, the security issues
and proposed solutions related to the new Segment Routing Header. and proposed solutions related to the new Segment Routing Header.
The Segment Routing Header (SRH) is simply another type of the The Segment Routing Header (SRH) is simply another type of the
routing header as described in RFC 2460 [RFC2460] and is: routing header as described in RFC 8200 [RFC8200] and is:
o Added by an SR edge router when entering the segment routing o Added by an SR edge router when entering the segment routing
domain or by the originating host itself. The source host can domain or by the originating host itself. The source host can
even be outside the SR domain; even be outside the SR domain;
o inspected and acted upon when reaching the destination address of o inspected and acted upon when reaching the destination address of
the IP header per RFC 2460 [RFC2460]. the IP header per RFC 8200 [RFC8200].
Per RFC2460 [RFC2460], routers on the path that simply forward an Per RFC8200 [RFC8200], routers on the path that simply forward an
IPv6 packet (i.e. the IPv6 destination address is none of theirs) IPv6 packet (i.e. the IPv6 destination address is none of theirs)
will never inspect and process the content of the SRH. Routers whose will never inspect and process the content of the SRH. Routers whose
one interface IPv6 address equals the destination address field of one interface IPv6 address equals the destination address field of
the IPv6 packet MUST parse the SRH and, if supported and if the local the IPv6 packet MUST parse the SRH and, if supported and if the local
configuration allows it, MUST act accordingly to the SRH content. configuration allows it, MUST act accordingly to the SRH content.
According to RFC2460 [RFC2460], the default behavior of a non SR- According to RFC8200 [RFC8200], the default behavior of a non SR-
capable router upon receipt of an IPv6 packet with SRH destined to an capable router upon receipt of an IPv6 packet with SRH destined to an
address of its, is to: address of its, is to:
o ignore the SRH completely if the Segment Left field is 0 and o ignore the SRH completely if the Segment Left field is 0 and
proceed to process the next header in the IPv6 packet; proceed to process the next header in the IPv6 packet;
o discard the IPv6 packet if Segment Left field is greater than 0, o discard the IPv6 packet if Segment Left field is greater than 0,
it MAY send a Parameter Problem ICMP message back to the Source it MAY send a Parameter Problem ICMP message back to the Source
Address. Address.
skipping to change at page 23, line 10 skipping to change at page 23, line 10
The SRH may also contains IPv6 addresses of some intermediate SR- The SRH may also contains IPv6 addresses of some intermediate SR-
nodes in the path towards the destination, this obviously reveals nodes in the path towards the destination, this obviously reveals
those addresses to the potentially hostile attackers if those those addresses to the potentially hostile attackers if those
attackers are able to intercept packets containing SRH. On the other attackers are able to intercept packets containing SRH. On the other
hand, if the attacker can do a traceroute whose probes will be hand, if the attacker can do a traceroute whose probes will be
forwarded along the SR path, then there is little learned by forwarded along the SR path, then there is little learned by
intercepting the SRH itself. intercepting the SRH itself.
6.1.5. ICMP Generation 6.1.5. ICMP Generation
Per section 4.4 of RFC2460 [RFC2460], when destination nodes (i.e. Per section 4.4 of RFC8200 [RFC8200], when destination nodes (i.e.
where the destination address is one of theirs) receive a Routing where the destination address is one of theirs) receive a Routing
Header with unsupported Routing Type, the required behavior is: Header with unsupported Routing Type, the required behavior is:
o If Segments Left is zero, the node must ignore the Routing header o If Segments Left is zero, the node must ignore the Routing header
and proceed to process the next header in the packet. and proceed to process the next header in the packet.
o If Segments Left is non-zero, the node must discard the packet and o If Segments Left is non-zero, the node must discard the packet and
send an ICMP Parameter Problem, Code 0, message to the packet's send an ICMP Parameter Problem, Code 0, message to the packet's
Source Address, pointing to the unrecognized Routing Type. Source Address, pointing to the unrecognized Routing Type.
This required behavior could be used by an attacker to force the This required behavior could be used by an attacker to force the
generation of ICMP message by any node. The attacker could send generation of ICMP message by any node. The attacker could send
packets with SRH (with Segment Left set to 0) destined to a node not packets with SRH (with Segment Left set to 0) destined to a node not
supporting SRH. Per RFC2460 [RFC2460], the destination node could supporting SRH. Per RFC8200 [RFC8200], the destination node could
generate an ICMP message, causing a local CPU utilization and if the generate an ICMP message, causing a local CPU utilization and if the
source of the offending packet with SRH was spoofed could lead to a source of the offending packet with SRH was spoofed could lead to a
reflection attack without any amplification. reflection attack without any amplification.
It must be noted that this is a required behavior for any unsupported It must be noted that this is a required behavior for any unsupported
Routing Type and not limited to SRH packets. So, it is not specific Routing Type and not limited to SRH packets. So, it is not specific
to SRH and the usual rate limiting for ICMP generation is required to SRH and the usual rate limiting for ICMP generation is required
anyway for any IPv6 implementation and has been implemented and anyway for any IPv6 implementation and has been implemented and
deployed for many years. deployed for many years.
skipping to change at page 29, line 36 skipping to change at page 29, line 36
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>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
[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>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
11.2. Informative References 11.2. Informative References
[I-D.bashandy-isis-srv6-extensions] [I-D.bashandy-isis-srv6-extensions]
Ginsberg, L., Bashandy, A., Filsfils, C., and B. Decraene, Ginsberg, L., Bashandy, A., Filsfils, C., and B. Decraene,
"IS-IS Extensions to Support Routing over IPv6 Dataplane", "IS-IS Extensions to Support Routing over IPv6 Dataplane",
draft-bashandy-isis-srv6-extensions-01 (work in progress), draft-bashandy-isis-srv6-extensions-01 (work in progress),
September 2017. September 2017.
[I-D.dawra-bgp-srv6-vpn] [I-D.dawra-bgp-srv6-vpn]
(Unknown), (., Dawra, G., Filsfils, C., Dukes, D., (Unknown), (., Dawra, G., Filsfils, C., Dukes, D.,
skipping to change at page 30, line 47 skipping to change at page 30, line 47
May 2017. May 2017.
[I-D.ietf-isis-segment-routing-extensions] [I-D.ietf-isis-segment-routing-extensions]
Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A.,
Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura, Gredler, H., Litkowski, S., Decraene, B., and J. Tantsura,
"IS-IS Extensions for Segment Routing", draft-ietf-isis- "IS-IS Extensions for Segment Routing", draft-ietf-isis-
segment-routing-extensions-15 (work in progress), December segment-routing-extensions-15 (work in progress), December
2017. 2017.
[I-D.ietf-ospf-ospfv3-segment-routing-extensions] [I-D.ietf-ospf-ospfv3-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Psenak, P., Filsfils, C., Previdi, S., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3 Shakir, R., Henderickx, W., and J. Tantsura, "OSPFv3
Extensions for Segment Routing", draft-ietf-ospf-ospfv3- Extensions for Segment Routing", draft-ietf-ospf-ospfv3-
segment-routing-extensions-10 (work in progress), segment-routing-extensions-11 (work in progress), January
September 2017. 2018.
[I-D.ietf-sfc-nsh] [I-D.ietf-sfc-nsh]
Quinn, P., Elzur, U., and C. Pignataro, "Network Service Quinn, P., Elzur, U., and C. Pignataro, "Network Service
Header (NSH)", draft-ietf-sfc-nsh-28 (work in progress), Header (NSH)", draft-ietf-sfc-nsh-28 (work in progress),
November 2017. November 2017.
[I-D.ietf-spring-ipv6-use-cases] [I-D.ietf-spring-ipv6-use-cases]
Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., and Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., and
M. Townsley, "IPv6 SPRING Use Cases", draft-ietf-spring- M. Townsley, "IPv6 SPRING Use Cases", draft-ietf-spring-
ipv6-use-cases-12 (work in progress), December 2017. ipv6-use-cases-12 (work in progress), December 2017.
[I-D.ietf-spring-resiliency-use-cases] [I-D.ietf-spring-resiliency-use-cases]
Filsfils, C., Previdi, S., Decraene, B., and R. Shakir, Filsfils, C., Previdi, S., Decraene, B., and R. Shakir,
"Resiliency use cases in SPRING networks", draft-ietf- "Resiliency use cases in SPRING networks", draft-ietf-
spring-resiliency-use-cases-12 (work in progress), spring-resiliency-use-cases-12 (work in progress),
December 2017. December 2017.
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-14 (work Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), December 2017. in progress), January 2018.
[I-D.ietf-spring-segment-routing-mpls] [I-D.ietf-spring-segment-routing-mpls]
Filsfils, C., Previdi, S., Bashandy, A., 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-11 data plane", draft-ietf-spring-segment-routing-mpls-12
(work in progress), October 2017. (work in progress), February 2018.
[I-D.previdi-idr-segment-routing-te-policy] [I-D.previdi-idr-segment-routing-te-policy]
Previdi, S., Filsfils, C., Mattes, P., Rosen, E., and S. Previdi, S., Filsfils, C., Mattes, P., Rosen, E., and S.
Lin, "Advertising Segment Routing Policies in BGP", draft- Lin, "Advertising Segment Routing Policies in BGP", draft-
previdi-idr-segment-routing-te-policy-07 (work in previdi-idr-segment-routing-te-policy-07 (work in
progress), June 2017. progress), June 2017.
[RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D. [RFC1940] Estrin, D., Li, T., Rekhter, Y., Varadhan, K., and D.
Zappala, "Source Demand Routing: Packet Format and Zappala, "Source Demand Routing: Packet Format and
Forwarding Specification (Version 1)", RFC 1940, Forwarding Specification (Version 1)", RFC 1940,
 End of changes. 27 change blocks. 
32 lines changed or deleted 33 lines changed or added

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