draft-ietf-idr-rfc5575bis-04.txt | draft-ietf-idr-rfc5575bis-05.txt | |||
---|---|---|---|---|
IDR Working Group S. Hares | IDR Working Group S. Hares | |||
Internet-Draft Huawei | Internet-Draft Huawei | |||
Obsoletes: 5575,7674 (if approved) C. Loibl | Obsoletes: 5575,7674 (if approved) C. Loibl | |||
Intended status: Standards Track Next Layer Communications | Intended status: Standards Track Next Layer Communications | |||
Expires: January 3, 2018 R. Raszuk | Expires: April 22, 2018 R. Raszuk | |||
Bloomberg LP | Bloomberg LP | |||
D. McPherson | D. McPherson | |||
Verisign | Verisign | |||
M. Bacher | M. Bacher | |||
T-Mobile Austria | T-Mobile Austria | |||
July 2, 2017 | October 19, 2017 | |||
Dissemination of Flow Specification Rules | Dissemination of Flow Specification Rules | |||
draft-ietf-idr-rfc5575bis-04 | draft-ietf-idr-rfc5575bis-05 | |||
Abstract | Abstract | |||
This document updates RFC5575 which defines a Border Gateway Protocol | This document updates [RFC5575] which defines a Border Gateway | |||
Network Layer Reachability Information (BGP NLRI) encoding format | Protocol Network Layer Reachability Information (BGP NLRI) encoding | |||
that can be used to distribute traffic flow specifications. This | format that can be used to distribute traffic Flow Specifications. | |||
allows the routing system to propagate information regarding more | This allows the routing system to propagate information regarding | |||
specific components of the traffic aggregate defined by an IP | more specific components of the traffic aggregate defined by an IP | |||
destination prefix. This draft specifies IPv4 traffic flow | destination prefix. | |||
specifications via a BGP NLRI which carries traffic flow | ||||
specification filter, and an Extended community value which encodes | ||||
actions a routing system can take if the packet matches the traffic | ||||
flow filters. The flow filters and the actions are processed in a | ||||
fixed order. Other drafts specify IPv6, MPLS addresses, L2VPN | ||||
addresses, and NV03 encapsulation of IP addresses. | ||||
This document updates RFC5575 to correct unclear specifications in | It specifies IPv4 traffic Flow Specifications via a BGP NLRI which | |||
carries traffic Flow Specification filter, and an Extended community | ||||
value which encodes actions a routing system can take if the packet | ||||
matches the traffic flow filters. The flow filters and the actions | ||||
are processed in a fixed order. Other drafts specify IPv6, MPLS | ||||
addresses, L2VPN addresses, and NV03 encapsulation of IP addresses. | ||||
This document updates [RFC5575] to correct unclear specifications in | ||||
the flow filters and to provide rules for actions which interfere | the flow filters and to provide rules for actions which interfere | |||
(e.g. redirection of traffic and flow filtering). | (e.g. redirection of traffic and flow filtering). | |||
Applications which use the bgp flow specification are: 1) application | Applications which use the bgp Flow Specification are: 1) application | |||
which automate of inter-domain coordination of traffic filtering, | which automate inter-domain coordination of traffic filtering, such | |||
such as what is required in order to mitigate (distributed) denial- | as what is required in order to mitigate (distributed) denial-of- | |||
of-service attacks; 2) application which control traffic filtering in | service attacks; 2) applications which control traffic filtering in | |||
the context of a BGP/MPLS VPN service, and 3) applications with | the context of a BGP/MPLS VPN service, and 3) applications with | |||
centralized control of traffic in a SDN or NFV context. Some of | centralized control of traffic in a SDN or NFV context. Some | |||
deployments of these three applications can be handled by the strict | deployments of these three applications can be handled by the strict | |||
ordering of the BGP NLRI traffic flow filters, and the strict actions | ordering of the BGP NLRI traffic flow filters, and the strict actions | |||
encoded in the Extended Community Flow Specification actions. | encoded in the extended community Flow Specification actions. | |||
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 http://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 January 3, 2018. | This Internet-Draft will expire on April 22, 2018. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2017 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 | |||
(http://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 | |||
skipping to change at page 3, line 13 ¶ | skipping to change at page 3, line 13 ¶ | |||
4.2.8. Type 8 - ICMP code . . . . . . . . . . . . . . . . . 11 | 4.2.8. Type 8 - ICMP code . . . . . . . . . . . . . . . . . 11 | |||
4.2.9. Type 9 - TCP flags . . . . . . . . . . . . . . . . . 11 | 4.2.9. Type 9 - TCP flags . . . . . . . . . . . . . . . . . 11 | |||
4.2.10. Type 10 - Packet length . . . . . . . . . . . . . . . 12 | 4.2.10. Type 10 - Packet length . . . . . . . . . . . . . . . 12 | |||
4.2.11. Type 11 - DSCP (Diffserv Code Point) . . . . . . . . 12 | 4.2.11. Type 11 - DSCP (Diffserv Code Point) . . . . . . . . 12 | |||
4.2.12. Type 12 - Fragment . . . . . . . . . . . . . . . . . 12 | 4.2.12. Type 12 - Fragment . . . . . . . . . . . . . . . . . 12 | |||
4.3. Examples of Encodings . . . . . . . . . . . . . . . . . . 12 | 4.3. Examples of Encodings . . . . . . . . . . . . . . . . . . 12 | |||
5. Traffic Filtering . . . . . . . . . . . . . . . . . . . . . . 13 | 5. Traffic Filtering . . . . . . . . . . . . . . . . . . . . . . 13 | |||
5.1. Ordering of Traffic Filtering Rules . . . . . . . . . . . 14 | 5.1. Ordering of Traffic Filtering Rules . . . . . . . . . . . 14 | |||
6. Validation Procedure . . . . . . . . . . . . . . . . . . . . 16 | 6. Validation Procedure . . . . . . . . . . . . . . . . . . . . 16 | |||
7. Traffic Filtering Actions . . . . . . . . . . . . . . . . . . 17 | 7. Traffic Filtering Actions . . . . . . . . . . . . . . . . . . 17 | |||
7.1. Traffic Rate in Bytes (traffic-rate-bytes) sub-type 0x06 18 | 7.1. Traffic Rate in Bytes (traffic-rate-bytes) sub-type 0x06 19 | |||
7.2. Traffic Rate in Packets (traffic-rate-packets) sub-type | 7.2. Traffic Rate in Packets (traffic-rate-packets) sub-type | |||
TBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 | TBD . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
7.3. Traffic-action (traffic-action) sub-type 0x07 . . . . . . 19 | 7.3. Traffic-action (traffic-action) sub-type 0x07 . . . . . . 19 | |||
7.4. RT Redirect (rt-redirect) sub-type 0x08 . . . . . . . . . 20 | 7.4. RT Redirect (rt-redirect) sub-type 0x08 . . . . . . . . . 20 | |||
7.5. Traffic Marking (traffic-marking) sub-type 0x09 . . . . . 20 | 7.5. Traffic Marking (traffic-marking) sub-type 0x09 . . . . . 20 | |||
7.6. Rules on Traffic Action Interference . . . . . . . . . . 20 | 7.6. Rules on Traffic Action Interference . . . . . . . . . . 21 | |||
7.6.1. Examples . . . . . . . . . . . . . . . . . . . . . . 21 | 7.6.1. Examples . . . . . . . . . . . . . . . . . . . . . . 21 | |||
8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks . 21 | 8. Dissemination of Traffic Filtering in BGP/MPLS VPN Networks . 22 | |||
8.1. Validation Procedures for BGP/MPLS VPNs . . . . . . . . . 22 | 8.1. Validation Procedures for BGP/MPLS VPNs . . . . . . . . . 23 | |||
8.2. Traffic Actions Rules . . . . . . . . . . . . . . . . . . 22 | 8.2. Traffic Actions Rules . . . . . . . . . . . . . . . . . . 23 | |||
9. Limitations of Previous Traffic Filtering Efforts . . . . . . 22 | 9. Limitations of Previous Traffic Filtering Efforts . . . . . . 23 | |||
9.1. Limitations in Previous DDoS Traffic Filtering Efforts . 22 | 9.1. Limitations in Previous DDoS Traffic Filtering Efforts . 23 | |||
9.2. Limitations in Previous BGP/MPLS Traffic Filtering . . . 23 | 9.2. Limitations in Previous BGP/MPLS Traffic Filtering . . . 24 | |||
10. Traffic Monitoring . . . . . . . . . . . . . . . . . . . . . 24 | 10. Traffic Monitoring . . . . . . . . . . . . . . . . . . . . . 24 | |||
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 | 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 | |||
11.1. AFI/SAFI Definitions . . . . . . . . . . . . . . . . . . 24 | 11.1. AFI/SAFI Definitions . . . . . . . . . . . . . . . . . . 24 | |||
11.2. Flow Component Definitions . . . . . . . . . . . . . . . 24 | 11.2. Flow Component Definitions . . . . . . . . . . . . . . . 25 | |||
11.3. Extended Community Flow Specification Actions . . . . . 25 | 11.3. Extended Community Flow Specification Actions . . . . . 26 | |||
12. Security Considerations . . . . . . . . . . . . . . . . . . . 28 | 12. Security Considerations . . . . . . . . . . . . . . . . . . . 28 | |||
13. Original authors . . . . . . . . . . . . . . . . . . . . . . 28 | 13. Original authors . . . . . . . . . . . . . . . . . . . . . . 29 | |||
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 | 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 | |||
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 | 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
15.1. Normative References . . . . . . . . . . . . . . . . . . 29 | 15.1. Normative References . . . . . . . . . . . . . . . . . . 29 | |||
15.2. Informative References . . . . . . . . . . . . . . . . . 31 | 15.2. Informative References . . . . . . . . . . . . . . . . . 31 | |||
Appendix A. Comparison with RFC 5575 . . . . . . . . . . . . . . 31 | 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 31 | |||
Appendix A. Comparison with RFC 5575 . . . . . . . . . . . . . . 32 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
1. Introduction | 1. Introduction | |||
Modern IP routers contain both the capability to forward traffic | Modern IP routers contain both the capability to forward traffic | |||
according to IP prefixes as well as to classify, shape, rate limit, | according to IP prefixes as well as to classify, shape, rate limit, | |||
filter, or redirect packets based on administratively defined | filter, or redirect packets based on administratively defined | |||
policies. | policies. | |||
These traffic policy mechanisms allow the router to define match | These traffic policy mechanisms allow the router to define match | |||
rules that operate on multiple fields of the packet header. Actions | rules that operate on multiple fields of the packet header. Actions | |||
such as the ones described above can be associated with each rule. | such as the ones described above can be associated with each rule. | |||
The n-tuple consisting of the matching criteria defines an aggregate | The n-tuple consisting of the matching criteria defines an aggregate | |||
traffic flow specification. The matching criteria can include | traffic Flow Specification. The matching criteria can include | |||
elements such as source and destination address prefixes, IP | elements such as source and destination address prefixes, IP | |||
protocol, and transport protocol port numbers. | protocol, and transport protocol port numbers. | |||
This document defines a general procedure to encode flow | This document defines a general procedure to encode flow | |||
specification rules for aggregated traffic flows so that they can be | specification rules for aggregated traffic flows so that they can be | |||
distributed as a BGP [RFC5575] NLRI. Additionally, we define the | distributed as a BGP [RFC4271] NLRI. Additionally, we define the | |||
required mechanisms to utilize this definition to the problem of | required mechanisms to utilize this definition to the problem of | |||
immediate concern to the authors: intra- and inter-provider | immediate concern to the authors: intra- and inter-provider | |||
distribution of traffic filtering rules to filter (distributed) | distribution of traffic filtering rules to filter (distributed) | |||
denial-of-service (DoS) attacks. | denial-of-service (DoS) attacks. | |||
By expanding routing information with flow specifications, the | By expanding routing information with Flow Specifications, the | |||
routing system can take advantage of the ACL (Access Control List) or | routing system can take advantage of the ACL (Access Control List) or | |||
firewall capabilities in the router's forwarding path. Flow | firewall capabilities in the router's forwarding path. Flow | |||
specifications can be seen as more specific routing entries to a | specifications can be seen as more specific routing entries to a | |||
unicast prefix and are expected to depend upon the existing unicast | unicast prefix and are expected to depend upon the existing unicast | |||
data information. | data information. | |||
A flow specification received from an external autonomous system will | A Flow Specification received from an external autonomous system will | |||
need to be validated against unicast routing before being accepted. | need to be validated against unicast routing before being accepted. | |||
If the aggregate traffic flow defined by the unicast destination | If the aggregate traffic flow defined by the unicast destination | |||
prefix is forwarded to a given BGP peer, then the local system can | prefix is forwarded to a given BGP peer, then the local system can | |||
safely install more specific flow rules that may result in different | safely install more specific flow rules that may result in different | |||
forwarding behavior, as requested by this system. | forwarding behavior, as requested by this system. | |||
The key technology components required to address the class of | The key technology components required to address the class of | |||
problems targeted by this document are: | problems targeted by this document are: | |||
1. Efficient point-to-multipoint distribution of control plane | 1. Efficient point-to-multipoint distribution of control plane | |||
skipping to change at page 4, line 47 ¶ | skipping to change at page 4, line 47 ¶ | |||
2. Inter-domain capabilities and routing policy support. | 2. Inter-domain capabilities and routing policy support. | |||
3. Tight integration with unicast routing, for verification | 3. Tight integration with unicast routing, for verification | |||
purposes. | purposes. | |||
Items 1 and 2 have already been addressed using BGP for other types | Items 1 and 2 have already been addressed using BGP for other types | |||
of control plane information. Close integration with BGP also makes | of control plane information. Close integration with BGP also makes | |||
it feasible to specify a mechanism to automatically verify flow | it feasible to specify a mechanism to automatically verify flow | |||
information against unicast routing. These factors are behind the | information against unicast routing. These factors are behind the | |||
choice of BGP as the carrier of flow specification information. | choice of BGP as the carrier of Flow Specification information. | |||
As with previous extensions to BGP, this specification makes it | As with previous extensions to BGP, this specification makes it | |||
possible to add additional information to Internet routers. These | possible to add additional information to Internet routers. These | |||
are limited in terms of the maximum number of data elements they can | are limited in terms of the maximum number of data elements they can | |||
hold as well as the number of events they are able to process in a | hold as well as the number of events they are able to process in a | |||
given unit of time. The authors believe that, as with previous | given unit of time. The authors believe that, as with previous | |||
extensions, service providers will be careful to keep information | extensions, service providers will be careful to keep information | |||
levels below the maximum capacity of their devices. | levels below the maximum capacity of their devices. | |||
In many deployments of BGP Flow Specification, the flow specification | In many deployments of BGP Flow Specification, the Flow Specification | |||
information has replace existing host length route advertisements. | information has replace existing host length route advertisements. | |||
Experience with previous BGP extensions has also shown that the | Experience with previous BGP extensions has also shown that the | |||
maximum capacity of BGP speakers has been gradually increased | maximum capacity of BGP speakers has been gradually increased | |||
according to expected loads. Taking into account Internet unicast | according to expected loads. Taking into account Internet unicast | |||
routing as well as additional applications as they gain popularity. | routing as well as additional applications as they gain popularity. | |||
From an operational perspective, the utilization of BGP as the | From an operational perspective, the utilization of BGP as the | |||
carrier for this information allows a network service provider to | carrier for this information allows a network service provider to | |||
reuse both internal route distribution infrastructure (e.g., route | reuse both internal route distribution infrastructure (e.g., route | |||
skipping to change at page 6, line 13 ¶ | skipping to change at page 6, line 13 ¶ | |||
VRF - Virtual Routing and Forwarding instance. | VRF - Virtual Routing and Forwarding instance. | |||
PE - Provider Edge router | PE - Provider Edge router | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119] | document are to be interpreted as described in [RFC2119] | |||
3. Flow Specifications | 3. Flow Specifications | |||
A flow specification is an n-tuple consisting of several matching | A Flow Specification is an n-tuple consisting of several matching | |||
criteria that can be applied to IP traffic. A given IP packet is | criteria that can be applied to IP traffic. A given IP packet is | |||
said to match the defined flow if it matches all the specified | said to match the defined flow if it matches all the specified | |||
criteria. | criteria. | |||
A given flow may be associated with a set of attributes, depending on | A given flow may be associated with a set of attributes, depending on | |||
the particular application; such attributes may or may not include | the particular application; such attributes may or may not include | |||
reachability information (i.e., NEXT_HOP). Well-known or AS-specific | reachability information (i.e., NEXT_HOP). Well-known or AS-specific | |||
community attributes can be used to encode a set of predetermined | community attributes can be used to encode a set of predetermined | |||
actions. | actions. | |||
skipping to change at page 6, line 41 ¶ | skipping to change at page 6, line 41 ¶ | |||
databases. Entries that are placed in the Loc-RIB are then | databases. Entries that are placed in the Loc-RIB are then | |||
associated with a given set of semantics, which is application | associated with a given set of semantics, which is application | |||
dependent. This is consistent with existing BGP applications. For | dependent. This is consistent with existing BGP applications. For | |||
instance, IP unicast routing (AFI=1, SAFI=1) and IP multicast | instance, IP unicast routing (AFI=1, SAFI=1) and IP multicast | |||
reverse-path information (AFI=1, SAFI=2) are handled by BGP without | reverse-path information (AFI=1, SAFI=2) are handled by BGP without | |||
any particular semantics being associated with them until installed | any particular semantics being associated with them until installed | |||
in the Loc-RIB. | in the Loc-RIB. | |||
Standard BGP policy mechanisms, such as UPDATE filtering by NLRI | Standard BGP policy mechanisms, such as UPDATE filtering by NLRI | |||
prefix as well as community matching and manipulation, MUST apply to | prefix as well as community matching and manipulation, MUST apply to | |||
the Flow specification defined NLRI-type, especially in an inter- | the Flow Specification defined NLRI-type, especially in an inter- | |||
domain environment. Network operators can also control propagation | domain environment. Network operators can also control propagation | |||
of such routing updates by enabling or disabling the exchange of a | of such routing updates by enabling or disabling the exchange of a | |||
particular (AFI, SAFI) pair on a given BGP peering session. | particular (AFI, SAFI) pair on a given BGP peering session. | |||
4. Dissemination of IPv4 FLow Specification Information | 4. Dissemination of IPv4 FLow Specification Information | |||
We define a "Flow Specification" NLRI type (Figure 1) that may | We define a "Flow Specification" NLRI type (Figure 1) that may | |||
include several components such as destination prefix, source prefix, | include several components such as destination prefix, source prefix, | |||
protocol, ports, and others (see Section 4.2 below). This NLRI is | protocol, ports, and others (see Section 4.2 below). This NLRI is | |||
treated as an opaque bit string prefix by BGP. Each bit string | treated as an opaque bit string prefix by BGP. Each bit string | |||
skipping to change at page 7, line 25 ¶ | skipping to change at page 7, line 25 ¶ | |||
value. The NLRI length is expressed in octets. | value. The NLRI length is expressed in octets. | |||
+------------------------------+ | +------------------------------+ | |||
| length (0xnn or 0xfn nn) | | | length (0xnn or 0xfn nn) | | |||
+------------------------------+ | +------------------------------+ | |||
| NLRI value (variable) | | | NLRI value (variable) | | |||
+------------------------------+ | +------------------------------+ | |||
Figure 1: Flow-spec NLRI for IPv4 | Figure 1: Flow-spec NLRI for IPv4 | |||
Implementations wishing to exchange flow specification rules MUST use | Implementations wishing to exchange Flow Specification rules MUST use | |||
BGP's Capability Advertisement facility to exchange the Multiprotocol | BGP's Capability Advertisement facility to exchange the Multiprotocol | |||
Extension Capability Code (Code 1) as defined in [RFC4760]. The | Extension Capability Code (Code 1) as defined in [RFC4760]. The | |||
(AFI, SAFI) pair carried in the Multiprotocol Extension Capability | (AFI, SAFI) pair carried in the Multiprotocol Extension Capability | |||
MUST be the same as the one used to identify a particular application | MUST be the same as the one used to identify a particular application | |||
that uses this NLRI-type. | that uses this NLRI-type. | |||
4.1. Length Encoding | 4.1. Length Encoding | |||
o If the NLRI length value is smaller than 240 (0xf0 hex), the | o If the NLRI length value is smaller than 240 (0xf0 hex), the | |||
length field can be encoded as a single octet. | length field can be encoded as a single octet. | |||
skipping to change at page 7, line 47 ¶ | skipping to change at page 7, line 47 ¶ | |||
o Otherwise, it is encoded as an extended-length 2-octet value in | o Otherwise, it is encoded as an extended-length 2-octet value in | |||
which the most significant nibble of the first byte is all ones. | which the most significant nibble of the first byte is all ones. | |||
In figure 1 above, values less-than 240 are encoded using two hex | In figure 1 above, values less-than 240 are encoded using two hex | |||
digits (0xnn). Values above 239 are encoded using 3 hex digits | digits (0xnn). Values above 239 are encoded using 3 hex digits | |||
(0xfnnn). The highest value that can be represented with this | (0xfnnn). The highest value that can be represented with this | |||
encoding is 4095. The value 241 is encoded as 0xf0f1. | encoding is 4095. The value 241 is encoded as 0xf0f1. | |||
4.2. NLRI Value Encoding | 4.2. NLRI Value Encoding | |||
The Flow specification NLRI-type consists of several optional | The Flow Specification NLRI-type consists of several optional | |||
subcomponents. A specific packet is considered to match the flow | subcomponents. A specific packet is considered to match the flow | |||
specification when it matches the intersection (AND) of all the | specification when it matches the intersection (AND) of all the | |||
components present in the specification. | components present in the specification. | |||
The encoding of each of the NLRI components begins with a type field | The encoding of each of the NLRI components begins with a type field | |||
(1 octet) followed by a variable length parameter. Section 4.2.1 to | (1 octet) followed by a variable length parameter. Section 4.2.1 to | |||
Section 4.2.12 define component types and parameter encodings for the | Section 4.2.12 define component types and parameter encodings for the | |||
IPv4 IP layer and transport layer headers. IPv6 NLRI component types | IPv4 IP layer and transport layer headers. IPv6 NLRI component types | |||
are described in [I-D.ietf-idr-flow-spec-v6]. | are described in [I-D.ietf-idr-flow-spec-v6]. | |||
Flow specification components must follow strict type ordering by | Flow Specification components must follow strict type ordering by | |||
increasing numerical order. A given component type may or may not be | increasing numerical order. A given component type may or may not be | |||
present in the specification, but if present, it MUST precede any | present in the specification, but if present, it MUST precede any | |||
component of higher numeric type value. | component of higher numeric type value. | |||
All combinations of component types within a single NLRI are allowed, | All combinations of component types within a single NLRI are allowed, | |||
even if the combination makes no sense from a semantical perspective. | even if the combination makes no sense from a semantical perspective. | |||
If a given component type within a prefix in unknown, the prefix in | If a given component type within a prefix in unknown, the prefix in | |||
question cannot be used for traffic filtering purposes by the | question cannot be used for traffic filtering purposes by the | |||
receiver. Since a flow specification has the semantics of a logical | receiver. Since a Flow Specification has the semantics of a logical | |||
AND of all components, if a component is FALSE, by definition it | AND of all components, if a component is FALSE, by definition it | |||
cannot be applied. However, for the purposes of BGP route | cannot be applied. However, for the purposes of BGP route | |||
propagation, this prefix should still be transmitted since BGP route | propagation, this prefix should still be transmitted since BGP route | |||
distribution is independent on NLRI semantics. | distribution is independent on NLRI semantics. | |||
The <type, value> encoding is chosen in order to allow for future | The <type, value> encoding is chosen in order to allow for future | |||
extensibility. | extensibility. | |||
4.2.1. Type 1 - Destination Prefix | 4.2.1. Type 1 - Destination Prefix | |||
skipping to change at page 9, line 31 ¶ | skipping to change at page 9, line 31 ¶ | |||
len - length of the value field for this operand encodes 1 (00) - | len - length of the value field for this operand encodes 1 (00) - | |||
4 (11) bytes. Type 3 flow component values are always encoded as | 4 (11) bytes. Type 3 flow component values are always encoded as | |||
single byte (len = 00). | single byte (len = 00). | |||
lt - less than comparison between data and value. | lt - less than comparison between data and value. | |||
gt - greater than comparison between data and value. | gt - greater than comparison between data and value. | |||
eq - equality between data and value. | eq - equality between data and value. | |||
The bits lt, gt, and eq can be combined to produce "less or equal", | The bits lt, gt, and eq can be combined to produce common relational | |||
"greater or equal", and inequality values. | operators such as "less or equal", "greater or equal", and "not equal | |||
to". | ||||
+----+----+----+----------------------------------+ | +----+----+----+----------------------------------+ | |||
| lt | gt | eq | Resulting operation | | | lt | gt | eq | Resulting operation | | |||
+----+----+----+----------------------------------+ | +----+----+----+----------------------------------+ | |||
| 0 | 0 | 0 | true (independent of the value) | | | 0 | 0 | 0 | true (independent of the value) | | |||
| 0 | 0 | 1 | == (equal) | | | 0 | 0 | 1 | == (equal) | | |||
| 0 | 1 | 0 | > (greater than) | | | 0 | 1 | 0 | > (greater than) | | |||
| 0 | 1 | 1 | >= (greater than or equal) | | | 0 | 1 | 1 | >= (greater than or equal) | | |||
| 1 | 0 | 0 | < (less than) | | | 1 | 0 | 0 | < (less than) | | |||
| 1 | 0 | 1 | <= (less than or equal) | | | 1 | 0 | 1 | <= (less than or equal) | | |||
skipping to change at page 12, line 48 ¶ | skipping to change at page 12, line 48 ¶ | |||
Bit 7 - Don't fragment (DF) | Bit 7 - Don't fragment (DF) | |||
Bit 6 - Is a fragment (IsF) | Bit 6 - Is a fragment (IsF) | |||
Bit 5 - First fragment (FF) | Bit 5 - First fragment (FF) | |||
Bit 4 - Last fragment (LF) | Bit 4 - Last fragment (LF) | |||
4.3. Examples of Encodings | 4.3. Examples of Encodings | |||
An example of a flow specification encoding for: "all packets to | An example of a Flow Specification encoding for: "all packets to | |||
10.0.1/24 and TCP port 25". | 10.0.1/24 and TCP port 25". | |||
+------------------+----------+----------+ | +------------------+----------+----------+ | |||
| destination | proto | port | | | destination | proto | port | | |||
+------------------+----------+----------+ | +------------------+----------+----------+ | |||
| 0x01 18 0a 00 01 | 03 81 06 | 04 81 19 | | | 0x01 18 0a 00 01 | 03 81 06 | 04 81 19 | | |||
+------------------+----------+----------+ | +------------------+----------+----------+ | |||
Decode for protocol: | Decode for protocol: | |||
+-------+----------+------------------------------+ | +-------+----------+------------------------------+ | |||
| Value | | | | | Value | | | | |||
+-------+----------+------------------------------+ | +-------+----------+------------------------------+ | |||
| 0x03 | type | | | | 0x03 | type | | | |||
| 0x81 | operator | end-of-list, value size=1, = | | | 0x81 | operator | end-of-list, value size=1, = | | |||
| 0x06 | value | | | | 0x06 | value | | | |||
+-------+----------+------------------------------+ | +-------+----------+------------------------------+ | |||
An example of a flow specification encoding for: "all packets to | An example of a Flow Specification encoding for: "all packets to | |||
10.1.1/24 from 192/8 and port {range [137, 139] or 8080}". | 10.1.1/24 from 192/8 and port {range [137, 139] or 8080}". | |||
+------------------+----------+-------------------------+ | +------------------+----------+-------------------------+ | |||
| destination | source | port | | | destination | source | port | | |||
+------------------+----------+-------------------------+ | +------------------+----------+-------------------------+ | |||
| 0x01 18 0a 01 01 | 02 08 c0 | 04 03 89 45 8b 91 1f 90 | | | 0x01 18 0a 01 01 | 02 08 c0 | 04 03 89 45 8b 91 1f 90 | | |||
+------------------+----------+-------------------------+ | +------------------+----------+-------------------------+ | |||
Decode for port: | Decode for port: | |||
skipping to change at page 14, line 12 ¶ | skipping to change at page 14, line 12 ¶ | |||
mechanism to be designed for the three new applications of traffic | mechanism to be designed for the three new applications of traffic | |||
filtering (prevention of traffic-based, denial-of-service (DOS) | filtering (prevention of traffic-based, denial-of-service (DOS) | |||
attacks, traffic filtering in the context of BGP/MPLS VPN service, | attacks, traffic filtering in the context of BGP/MPLS VPN service, | |||
and centralized traffic control for SDN/NFV networks) requires | and centralized traffic control for SDN/NFV networks) requires | |||
coordination among service providers and/or coordination among the AS | coordination among service providers and/or coordination among the AS | |||
within a service provider. Section 8 has details on the limitation | within a service provider. Section 8 has details on the limitation | |||
of previous mechanisms and why BGP Flow Specification version 1 | of previous mechanisms and why BGP Flow Specification version 1 | |||
provides a solution for to prevent DOS and aid BGP/MPLS VPN filtering | provides a solution for to prevent DOS and aid BGP/MPLS VPN filtering | |||
rules. | rules. | |||
This flow specification NLRI defined above to convey information | This Flow Specification NLRI defined above to convey information | |||
about traffic filtering rules for traffic that should be discarded or | about traffic filtering rules for traffic that should be discarded or | |||
handled in manner specified by a set of pre-defined actions (which | handled in manner specified by a set of pre-defined actions (which | |||
are defined in BGP Extended Communities). This mechanism is | are defined in BGP Extended Communities). This mechanism is | |||
primarily designed to allow an upstream autonomous system to perform | primarily designed to allow an upstream autonomous system to perform | |||
inbound filtering in their ingress routers of traffic that a given | inbound filtering in their ingress routers of traffic that a given | |||
downstream AS wishes to drop. | downstream AS wishes to drop. | |||
In order to achieve this goal, this draft specifies two application | In order to achieve this goal, this draft specifies two application | |||
specific NLRI identifiers that provide traffic filters, and a set of | specific NLRI identifiers that provide traffic filters, and a set of | |||
actions encoding in BGP Extended Communities. The two application | actions encoding in BGP Extended Communities. The two application | |||
specific NLRI identifiers are: | specific NLRI identifiers are: | |||
o IPv4 flow specification identifier (AFI=1, SAFI=133) along with | o IPv4 Flow Specification identifier (AFI=1, SAFI=133) along with | |||
specific semantic rules for IPv4 routes, and | specific semantic rules for IPv4 routes, and | |||
o BGP NLRI type (AFI=1, SAFI=134) value, which can be used to | o BGP NLRI type (AFI=1, SAFI=134) value, which can be used to | |||
propagate traffic filtering information in a BGP/MPLS VPN | propagate traffic filtering information in a BGP/MPLS VPN | |||
environment. | environment. | |||
Distribution of the IPv4 Flow specification is described in section | Distribution of the IPv4 Flow Specification is described in section | |||
6, and distibution of BGP/MPLS traffic flow specification is | 6, and distibution of BGP/MPLS traffic Flow Specification is | |||
described in section 8. The traffic filtering actions are described | described in section 8. The traffic filtering actions are described | |||
in section 7. | in section 7. | |||
5.1. Ordering of Traffic Filtering Rules | 5.1. Ordering of Traffic Filtering Rules | |||
With traffic filtering rules, more than one rule may match a | With traffic filtering rules, more than one rule may match a | |||
particular traffic flow. Thus, it is necessary to define the order | particular traffic flow. Thus, it is necessary to define the order | |||
at which rules get matched and applied to a particular traffic flow. | at which rules get matched and applied to a particular traffic flow. | |||
This ordering function must be such that it must not depend on the | This ordering function must be such that it must not depend on the | |||
arrival order of the flow specification's rules and must be | arrival order of the Flow Specification's rules and must be | |||
consistent in the network. | consistent in the network. | |||
The relative order of two flow specification rules is determined by | The relative order of two Flow Specification rules is determined by | |||
comparing their respective components. The algorithm starts by | comparing their respective components. The algorithm starts by | |||
comparing the left-most components of the rules. If the types | comparing the left-most components of the rules. If the types | |||
differ, the rule with lowest numeric type value has higher precedence | differ, the rule with lowest numeric type value has higher precedence | |||
(and thus will match before) than the rule that doesn't contain that | (and thus will match before) than the rule that doesn't contain that | |||
component type. If the component types are the same, then a type- | component type. If the component types are the same, then a type- | |||
specific comparison is performed. | specific comparison is performed (see below) if the types are equal | |||
the algorithm continues with the next component. | ||||
For IP prefix values (IP destination and source prefix) precedence is | For IP prefix values (IP destination or source prefix): If the | |||
given to the lowest IP value of the common prefix length; if the | prefixes overlap, the one with the longer prefix-length has higher | |||
common prefix is equal, then the most specific prefix has precedence. | precedence. If they do not overlap the one with the lowest IP value | |||
has higher precedence. | ||||
For all other component types, unless otherwise specified, the | For all other component types, unless otherwise specified, the | |||
comparison is performed by comparing the component data as a binary | comparison is performed by comparing the component data as a binary | |||
string using the memcmp() function as defined by the ISO C standard. | string using the memcmp() function as defined by the ISO C standard. | |||
For strings of different lengths, the common prefix is compared. If | For strings with equal lengths the lowest string (memcmp) has higher | |||
equal, the longest string is considered to have higher precedence | precedence. For strings of different lengths, the common prefix is | |||
than the shorter one. | compared. If the common prefix is not equal the string with the | |||
lowest prefix has higher precedence. If the common prefix is equal, | ||||
the longest string is considered to have higher precedence than the | ||||
shorter one. | ||||
Pseudocode: | The code below shows a python3 implementation of the comparison | |||
algorithm described above. The full python3 implementation including | ||||
unittests can be optained at https://github.com/stoffi92/flowspec-cmp | ||||
[1]. | ||||
flow_rule_cmp (a, b) | import itertools | |||
{ | import ipaddress | |||
comp1 = next_component(a); | ||||
comp2 = next_component(b); | ||||
while (comp1 || comp2) { | ||||
// component_type returns infinity on end-of-list | ||||
if (component_type(comp1) < component_type(comp2)) { | ||||
return A_HAS_PRECEDENCE; | ||||
} | ||||
if (component_type(comp1) > component_type(comp2)) { | ||||
return B_HAS_PRECEDENCE; | ||||
} | ||||
if (component_type(comp1) == IP_DESTINATION || IP_SOURCE) { | def flow_rule_cmp(a, b): | |||
common = MIN(prefix_length(comp1), prefix_length(comp2)); | for comp_a, comp_b in itertools.zip_longest(a.components, | |||
cmp = prefix_compare(comp1, comp2, common); | b.components): | |||
// not equal, lowest value has precedence | # If a component type does not exist in one rule | |||
// equal, longest match has precedence | # this rule has lower precedence | |||
} else { | if not comp_a: | |||
common = | return B_HAS_PRECEDENCE | |||
MIN(component_length(comp1), component_length(comp2)); | if not comp_b: | |||
cmp = memcmp(data(comp1), data(comp2), common); | return A_HAS_PRECEDENCE | |||
// not equal, lowest value has precedence | # higher precedence for lower component type | |||
// equal, longest string has precedence | if comp_a.component_type < comp_b.component_type: | |||
} | return A_HAS_PRECEDENCE | |||
} | if comp_a.component_type > comp_b.component_type: | |||
return EQUAL; | return B_HAS_PRECEDENCE | |||
} | # component types are equal -> type specific comparison | |||
if comp_a.component_type in (IP_DESTINATION, IP_SOURCE): | ||||
# assuming comp_a.value, comp_b.value of type ipaddress | ||||
if comp_a.value.overlaps(comp_b.value): | ||||
# longest prefixlen has precedence | ||||
if comp_a.value.prefixlen > comp_b.value.prefixlen: | ||||
return A_HAS_PRECEDENCE | ||||
if comp_a.value.prefixlen < comp_b.value.prefixlen: | ||||
return B_HAS_PRECEDENCE | ||||
# components equal -> continue with next component | ||||
elif comp_a.value > comp_b.value: | ||||
return B_HAS_PRECEDENCE | ||||
elif comp_a.value < comp_b.value: | ||||
return A_HAS_PRECEDENCE | ||||
else: | ||||
# assuming comp_a.value, comp_b.value of type bytearray | ||||
if len(comp_a.value) == len(comp_b.value): | ||||
if comp_a.value > comp_b.value: | ||||
return B_HAS_PRECEDENCE | ||||
if comp_a.value < comp_b.value: | ||||
return A_HAS_PRECEDENCE | ||||
# components equal -> continue with next component | ||||
else: | ||||
common = min(len(comp_a.value), len(comp_b.value)) | ||||
if comp_a.value[:common] > comp_b.value[:common]: | ||||
return B_HAS_PRECEDENCE | ||||
elif comp_a.value[:common] < comp_b.value[:common]: | ||||
return A_HAS_PRECEDENCE | ||||
# the first common bytes match | ||||
elif len(comp_a.value) > len(comp_b.value): | ||||
return A_HAS_PRECEDENCE | ||||
else: | ||||
return B_HAS_PRECEDENCE | ||||
return EQUAL | ||||
6. Validation Procedure | 6. Validation Procedure | |||
Flow specifications received from a BGP peer that are accepted in the | Flow Specifications received from a BGP peer that are accepted in the | |||
respective Adj-RIB-In are used as input to the route selection | respective Adj-RIB-In are used as input to the route selection | |||
process. Although the forwarding attributes of two routes for the | process. Although the forwarding attributes of two routes for the | |||
same flow specification prefix may be the same, BGP is still required | same Flow Specification prefix may be the same, BGP is still required | |||
to perform its path selection algorithm in order to select the | to perform its path selection algorithm in order to select the | |||
correct set of attributes to advertise. | correct set of attributes to advertise. | |||
The first step of the BGP Route Selection procedure (Section 9.1.2 of | The first step of the BGP Route Selection procedure (Section 9.1.2 of | |||
[RFC4271] is to exclude from the selection procedure routes that are | [RFC4271] is to exclude from the selection procedure routes that are | |||
considered non-feasible. In the context of IP routing information, | considered non-feasible. In the context of IP routing information, | |||
this step is used to validate that the NEXT_HOP attribute of a given | this step is used to validate that the NEXT_HOP attribute of a given | |||
route is resolvable. | route is resolvable. | |||
The concept can be extended, in the case of flow specification NLRI, | The concept can be extended, in the case of Flow Specification NLRI, | |||
to allow other validation procedures. | to allow other validation procedures. | |||
A flow specification NLRI must be validated such that it is | A Flow Specification NLRI must be validated such that it is | |||
considered feasible if and only if: | considered feasible if and only if: | |||
a) The originator of the flow specification matches the originator | a) The originator of the Flow Specification matches the originator | |||
of the best-match unicast route for the destination prefix | of the best-match unicast route for the destination prefix | |||
embedded in the flow specification. | embedded in the Flow Specification. | |||
b) There are no more specific unicast routes, when compared with | b) There are no more specific unicast routes, when compared with | |||
the flow destination prefix, that has been received from a | the flow destination prefix, that has been received from a | |||
different neighboring AS than the best-match unicast route, which | different neighboring AS than the best-match unicast route, which | |||
has been determined in step a). | has been determined in step a). | |||
By originator of a BGP route, we mean either the BGP originator path | By originator of a BGP route, we mean either the BGP originator path | |||
attribute, as used by route reflection, or the transport address of | attribute, as used by route reflection, or the transport address of | |||
the BGP peer, if this path attribute is not present. | the BGP peer, if this path attribute is not present. | |||
BGP implementations MUST also enforce that the AS_PATH attribute of a | BGP implementations MUST also enforce that the AS_PATH attribute of a | |||
route received via the External Border Gateway Protocol (eBGP) | route received via the External Border Gateway Protocol (eBGP) | |||
contains the neighboring AS in the left-most position of the AS_PATH | contains the neighboring AS in the left-most position of the AS_PATH | |||
attribute. While this rule is optional in the BGP specification, it | attribute. While this rule is optional in the BGP specification, it | |||
becomes necessary to enforce it for security reasons. | becomes necessary to enforce it for security reasons. | |||
The best-match unicast route may change over the time independently | The best-match unicast route may change over the time independently | |||
of the flow specification NLRI. Therefore, a revalidation of the | of the Flow Specification NLRI. Therefore, a revalidation of the | |||
flow specification NLRI MUST be performed whenever unicast routes | Flow Specification NLRI MUST be performed whenever unicast routes | |||
change. Revalidation is defined as retesting that clause a and | change. Revalidation is defined as retesting that clause a and | |||
clause b above are true. | clause b above are true. | |||
Explanation: | Explanation: | |||
The underlying concept is that the neighboring AS that advertises the | The underlying concept is that the neighboring AS that advertises the | |||
best unicast route for a destination is allowed to advertise flow- | best unicast route for a destination is allowed to advertise flow- | |||
spec information that conveys a more or equally specific destination | spec information that conveys a more or equally specific destination | |||
prefix. Thus, as long as there are no more specific unicast routes, | prefix. Thus, as long as there are no more specific unicast routes, | |||
received from a different neighboring AS, which would be affected by | received from a different neighboring AS, which would be affected by | |||
that filtering rule. | that filtering rule. | |||
The neighboring AS is the immediate destination of the traffic | The neighboring AS is the immediate destination of the traffic | |||
described by the flow specification. If it requests these flows to | described by the Flow Specification. If it requests these flows to | |||
be dropped, that request can be honored without concern that it | be dropped, that request can be honored without concern that it | |||
represents a denial of service in itself. Supposedly, the traffic is | represents a denial of service in itself. Supposedly, the traffic is | |||
being dropped by the downstream autonomous system, and there is no | being dropped by the downstream autonomous system, and there is no | |||
added value in carrying the traffic to it. | added value in carrying the traffic to it. | |||
7. Traffic Filtering Actions | 7. Traffic Filtering Actions | |||
This specification defines a minimum set of filtering actions that it | This specification defines a minimum set of filtering actions that it | |||
standardizes as BGP extended community values [RFC4360]. This is not | standardizes as BGP extended community values [RFC4360]. This is not | |||
meant to be an inclusive list of all the possible actions, but only a | meant to be an inclusive list of all the possible actions, but only a | |||
skipping to change at page 17, line 38 ¶ | skipping to change at page 18, line 18 ¶ | |||
Implementations SHOULD provide mechanisms that map an arbitrary BGP | Implementations SHOULD provide mechanisms that map an arbitrary BGP | |||
community value (normal or extended) to filtering actions that | community value (normal or extended) to filtering actions that | |||
require different mappings in different systems in the network. For | require different mappings in different systems in the network. For | |||
instance, providing packets with a worse-than-best-effort, per-hop | instance, providing packets with a worse-than-best-effort, per-hop | |||
behavior is a functionality that is likely to be implemented | behavior is a functionality that is likely to be implemented | |||
differently in different systems and for which no standard behavior | differently in different systems and for which no standard behavior | |||
is currently known. Rather than attempting to define it here, this | is currently known. Rather than attempting to define it here, this | |||
can be accomplished by mapping a user-defined community value to | can be accomplished by mapping a user-defined community value to | |||
platform-/network-specific behavior via user configuration. | platform-/network-specific behavior via user configuration. | |||
The default action for a traffic filtering flow specification is to | The default action for a traffic filtering Flow Specification is to | |||
accept IP traffic that matches that particular rule. | accept IP traffic that matches that particular rule. | |||
This document defines the following extended communities values shown | This document defines the following extended communities values shown | |||
in Table 2 in the form 0x8xnn where nn indicates the sub-type. | in Table 2 in the form 0x8xnn where nn indicates the sub-type. | |||
Encodings for these extended communities are described below. | Encodings for these extended communities are described below. | |||
+-----------+----------------------+--------------------------------+ | +-----------+----------------------+--------------------------------+ | |||
| community | action | encoding | | | community | action | encoding | | |||
+-----------+----------------------+--------------------------------+ | +-----------+----------------------+--------------------------------+ | |||
| 0x8006 | traffic-rate-bytes | 2-byte ASN, 4-byte float | | | 0x8006 | traffic-rate-bytes | 2-byte ASN, 4-byte float | | |||
skipping to change at page 19, line 41 ¶ | skipping to change at page 20, line 11 ¶ | |||
+---+---+---+---+---+---+---+---+ | +---+---+---+---+---+---+---+---+ | |||
where S and T are defined as: | where S and T are defined as: | |||
o T: Terminal Action (bit 47): When this bit is set, the traffic | o T: Terminal Action (bit 47): When this bit is set, the traffic | |||
filtering engine will apply any subsequent filtering rules (as | filtering engine will apply any subsequent filtering rules (as | |||
defined by the ordering procedure). If not set, the evaluation of | defined by the ordering procedure). If not set, the evaluation of | |||
the traffic filter stops when this rule is applied. | the traffic filter stops when this rule is applied. | |||
o S: Sample (bit 46): Enables traffic sampling and logging for this | o S: Sample (bit 46): Enables traffic sampling and logging for this | |||
flow specification. | Flow Specification. | |||
o reserved: should always be set to 0 by the originator and not be | o reserved: should always be set to 0 by the originator and not be | |||
evaluated by the receiving BGP speaker. | evaluated by the receiving BGP speaker. | |||
The use of the Terminal Action (bit 47) may result in more than one | The use of the Terminal Action (bit 47) may result in more than one | |||
filter-rule matching a particular flow. All the flow actions from | filter-rule matching a particular flow. All the flow actions from | |||
these rules shall be collected and applied. If interfering actions | these rules shall be collected and applied. If interfering actions | |||
have been collected only the first occurence SHALL be applied. | have been collected only the first occurence SHALL be applied. | |||
However, if a single rule contains interfering actions this rule | However, if a single rule contains interfering actions this rule | |||
SHALL still be handled as described in Section 7.6. | SHALL still be handled as described in Section 7.6. | |||
skipping to change at page 20, line 44 ¶ | skipping to change at page 21, line 13 ¶ | |||
This extended community is encoded as a sequence of 5 zero bytes | This extended community is encoded as a sequence of 5 zero bytes | |||
followed by the DSCP value encoded in the 6 least significant bits of | followed by the DSCP value encoded in the 6 least significant bits of | |||
6th byte. | 6th byte. | |||
Interferes with: No other BGP Flow Specification traffic action in | Interferes with: No other BGP Flow Specification traffic action in | |||
this document. | this document. | |||
7.6. Rules on Traffic Action Interference | 7.6. Rules on Traffic Action Interference | |||
Traffic actions may interfere with each other. If interfering | Traffic actions may interfere with each other. If interfering | |||
traffic actions are present for a single flow specification NLRI the | traffic actions are present for a single Flow Specification NLRI the | |||
entire flow specification (irrespective if there are any other non | entire Flow Specification (irrespective if there are any other non | |||
conflicting actions associated with the same flow specification) | conflicting actions associated with the same Flow Specification) | |||
SHALL be treated as BGP WITHDRAW. | SHALL be treated as BGP WITHDRAW. | |||
This document defines 7 traffic actions which are interfering in the | This document defines 7 traffic actions which are interfering in the | |||
following way: | following way: | |||
1. Redirect-action-communities (0x8008, 0x8108, 0x8208): | 1. Redirect-action-communities (0x8008, 0x8108, 0x8208): | |||
The three redirect-communities are mutually exclusive. Only a | The three redirect-communities are mutually exclusive. Only a | |||
single redirect community may be associated with a flow | single redirect community may be associated with a Flow | |||
specification otherwise they are interfering. | Specification otherwise they are interfering. | |||
2. All traffic-action communities (including redirect-actions): | 2. All traffic-action communities (including redirect-actions): | |||
Multiple occurences of the same (sub-type and type) traffic- | Multiple occurences of the same (sub-type and type) traffic- | |||
action associated with a flow specification are always | action associated with a Flow Specification are always | |||
interfering. | interfering. | |||
When a traffic action is defined in a standards document the handling | When a traffic action is defined in a standards document the handling | |||
of interaction with other/same traffic actions MUST be defined as | of interaction with other/same traffic actions MUST be defined as | |||
well. Invalid interactions between actions SHOULD NOT trigger a BGP | well. Invalid interactions between actions SHOULD NOT trigger a BGP | |||
NOTIFICATION. All error handling for error conditions based on | NOTIFICATION. All error handling for error conditions based on | |||
[RFC7606]. | [RFC7606]. | |||
7.6.1. Examples | 7.6.1. Examples | |||
skipping to change at page 22, line 6 ¶ | skipping to change at page 22, line 25 ¶ | |||
filtering requirements than Internet service providers. But also | filtering requirements than Internet service providers. But also | |||
Internet service providers may use those VPNs for scenarios like | Internet service providers may use those VPNs for scenarios like | |||
having the Internet routing table in a VRF, resulting in the same | having the Internet routing table in a VRF, resulting in the same | |||
traffic filtering requirements as defined for the global routing | traffic filtering requirements as defined for the global routing | |||
table environment within this document. This document proposes an | table environment within this document. This document proposes an | |||
additional BGP NLRI type (AFI=1, SAFI=134) value, which can be used | additional BGP NLRI type (AFI=1, SAFI=134) value, which can be used | |||
to propagate traffic filtering information in a BGP/MPLS VPN | to propagate traffic filtering information in a BGP/MPLS VPN | |||
environment. | environment. | |||
The NLRI format for this address family consists of a fixed-length | The NLRI format for this address family consists of a fixed-length | |||
Route Distinguisher field (8 bytes) followed by a flow specification, | Route Distinguisher field (8 bytes) followed by a Flow Specification, | |||
following the encoding defined above in Section 4.2 of this document. | following the encoding defined above in Section 4.2 of this document. | |||
The NLRI length field shall include both the 8 bytes of the Route | The NLRI length field shall include both the 8 bytes of the Route | |||
Distinguisher as well as the subsequent flow specification. | Distinguisher as well as the subsequent Flow Specification. | |||
+------------------------------+ | +------------------------------+ | |||
| length (0xnn or 0xfn nn) | | | length (0xnn or 0xfn nn) | | |||
+------------------------------+ | +------------------------------+ | |||
| Route Distinguisher (8 bytes)| | | Route Distinguisher (8 bytes)| | |||
+------------------------------+ | +------------------------------+ | |||
| NLRI value (variable) | | | NLRI value (variable) | | |||
+------------------------------+ | +------------------------------+ | |||
Flow-spec NLRI for MPLS | Flow-spec NLRI for MPLS | |||
Propagation of this NLRI is controlled by matching Route Target | Propagation of this NLRI is controlled by matching Route Target | |||
extended communities associated with the BGP path advertisement with | extended communities associated with the BGP path advertisement with | |||
the VRF import policy, using the same mechanism as described in "BGP/ | the VRF import policy, using the same mechanism as described in "BGP/ | |||
MPLS IP VPNs" [RFC4364]. | MPLS IP VPNs" [RFC4364]. | |||
Flow specification rules received via this NLRI apply only to traffic | Flow Specification rules received via this NLRI apply only to traffic | |||
that belongs to the VRF(s) in which it is imported. By default, | that belongs to the VRF(s) in which it is imported. By default, | |||
traffic received from a remote PE is switched via an MPLS forwarding | traffic received from a remote PE is switched via an MPLS forwarding | |||
decision and is not subject to filtering. | decision and is not subject to filtering. | |||
Contrary to the behavior specified for the non-VPN NLRI, flow rules | Contrary to the behavior specified for the non-VPN NLRI, flow rules | |||
are accepted by default, when received from remote PE routers. | are accepted by default, when received from remote PE routers. | |||
8.1. Validation Procedures for BGP/MPLS VPNs | 8.1. Validation Procedures for BGP/MPLS VPNs | |||
The validation procedures are the same as for IPv4. | The validation procedures are the same as for IPv4. | |||
skipping to change at page 23, line 28 ¶ | skipping to change at page 23, line 48 ¶ | |||
and inter-AS communication channels. This can allow, for instance, a | and inter-AS communication channels. This can allow, for instance, a | |||
service provider to accept filtering requests from customers for | service provider to accept filtering requests from customers for | |||
address space they own. | address space they own. | |||
There are several drawbacks, however. An issue that is immediately | There are several drawbacks, however. An issue that is immediately | |||
apparent is the granularity of filtering control: only destination | apparent is the granularity of filtering control: only destination | |||
prefixes may be specified. Another area of concern is the fact that | prefixes may be specified. Another area of concern is the fact that | |||
filtering information is intermingled with routing information. | filtering information is intermingled with routing information. | |||
The mechanism defined in this document is designed to address these | The mechanism defined in this document is designed to address these | |||
limitations. We use the flow specification NLRI defined above to | limitations. We use the Flow Specification NLRI defined above to | |||
convey information about traffic filtering rules for traffic that is | convey information about traffic filtering rules for traffic that is | |||
subject to modified forwarding behavior (actions). The actions are | subject to modified forwarding behavior (actions). The actions are | |||
defined as extended communities and include (but are not limited to) | defined as extended communities and include (but are not limited to) | |||
rate-limiting (including discard), traffic redirection, packet | rate-limiting (including discard), traffic redirection, packet | |||
rewriting. | rewriting. | |||
9.2. Limitations in Previous BGP/MPLS Traffic Filtering | 9.2. Limitations in Previous BGP/MPLS Traffic Filtering | |||
Provider-based Layer 3 VPN networks, such as the ones using a BGP/ | Provider-based Layer 3 VPN networks, such as the ones using a BGP/ | |||
MPLS IP VPN [RFC4364] control plane, may have different traffic | MPLS IP VPN [RFC4364] control plane, may have different traffic | |||
skipping to change at page 24, line 35 ¶ | skipping to change at page 25, line 8 ¶ | |||
11.1. AFI/SAFI Definitions | 11.1. AFI/SAFI Definitions | |||
IANA maintains a registry entitled "SAFI Values". For the purpose of | IANA maintains a registry entitled "SAFI Values". For the purpose of | |||
this work, IANA updated the registry and allocated two additional | this work, IANA updated the registry and allocated two additional | |||
SAFIs: | SAFIs: | |||
+-------+------------------------------------------+----------------+ | +-------+------------------------------------------+----------------+ | |||
| Value | Name | Reference | | | Value | Name | Reference | | |||
+-------+------------------------------------------+----------------+ | +-------+------------------------------------------+----------------+ | |||
| 133 | IPv4 dissemination of flow specification | [this | | | 133 | IPv4 dissemination of Flow Specification | [this | | |||
| | rules | document] | | | | rules | document] | | |||
| 134 | VPNv4 dissemination of flow | [this | | | 134 | VPNv4 dissemination of Flow | [this | | |||
| | specification rules | document] | | | | Specification rules | document] | | |||
+-------+------------------------------------------+----------------+ | +-------+------------------------------------------+----------------+ | |||
Table 3: Registry: SAFI Values | Table 3: Registry: SAFI Values | |||
11.2. Flow Component Definitions | 11.2. Flow Component Definitions | |||
A flow specification consists of a sequence of flow components, which | A Flow Specification consists of a sequence of flow components, which | |||
are identified by a an 8-bit component type. IANA has created and | are identified by a an 8-bit component type. IANA has created and | |||
maintains a registry entitled "Flow Spec Component Types". This | maintains a registry entitled "Flow Spec Component Types". This | |||
document defines the following Component Type Codes: | document defines the following Component Type Codes: | |||
+-------+--------------------+-----------------+ | +-------+--------------------+-----------------+ | |||
| Value | Name | Reference | | | Value | Name | Reference | | |||
+-------+--------------------+-----------------+ | +-------+--------------------+-----------------+ | |||
| 1 | Destination Prefix | [this document] | | | 1 | Destination Prefix | [this document] | | |||
| 2 | Source Prefix | [this document] | | | 2 | Source Prefix | [this document] | | |||
| 3 | IP Protocol | [this document] | | | 3 | IP Protocol | [this document] | | |||
skipping to change at page 29, line 5 ¶ | skipping to change at page 29, line 32 ¶ | |||
1000. Such behavior may be confusing and these capabilities should | 1000. Such behavior may be confusing and these capabilities should | |||
be used with care whether manually configured or coordinated through | be used with care whether manually configured or coordinated through | |||
the protocol extensions described in this document. | the protocol extensions described in this document. | |||
13. Original authors | 13. Original authors | |||
Barry Greene, MuPedro Marques, Jared Mauch, Danny McPherson, and | Barry Greene, MuPedro Marques, Jared Mauch, Danny McPherson, and | |||
Nischal Sheth were authors on [RFC5575], and therefore are | Nischal Sheth were authors on [RFC5575], and therefore are | |||
contributing authors on this document. | contributing authors on this document. | |||
Note: Any original author of [RFC5575] who wants to work on this | ||||
draft can be added as a co-author. | ||||
14. Acknowledgements | 14. Acknowledgements | |||
The authors would like to thank Yakov Rekhter, Dennis Ferguson, Chris | The authors would like to thank Yakov Rekhter, Dennis Ferguson, Chris | |||
Morrow, Charlie Kaufman, and David Smith for their comments for the | Morrow, Charlie Kaufman, and David Smith for their comments for the | |||
comments on the original [RFC5575]. Chaitanya Kodeboyina helped | comments on the original [RFC5575]. Chaitanya Kodeboyina helped | |||
design the flow validation procedure; and Steven Lin and Jim Washburn | design the flow validation procedure; and Steven Lin and Jim Washburn | |||
ironed out all the details necessary to produce a working | ironed out all the details necessary to produce a working | |||
implementation in the original [RFC5575]. | implementation in the original [RFC5575]. | |||
Additional acknowledgements for this document will be included here. | Additional the authors would like to thank Alexander Mayrhofer, | |||
The current authors would like to thank Alexander Mayrhofer and | Nicolas Fevrier and Job Snijders for their comments and review. | |||
Nicolas Fevrier for their comments and review. | ||||
15. References | 15. References | |||
15.1. Normative References | 15.1. Normative References | |||
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, | [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, | |||
RFC 793, DOI 10.17487/RFC0793, September 1981, | RFC 793, DOI 10.17487/RFC0793, September 1981, | |||
<http://www.rfc-editor.org/info/rfc793>. | <https://www.rfc-editor.org/info/rfc793>. | |||
[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, | |||
<http://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, | [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, | |||
"Definition of the Differentiated Services Field (DS | "Definition of the Differentiated Services Field (DS | |||
Field) in the IPv4 and IPv6 Headers", RFC 2474, | Field) in the IPv4 and IPv6 Headers", RFC 2474, | |||
DOI 10.17487/RFC2474, December 1998, | DOI 10.17487/RFC2474, December 1998, | |||
<http://www.rfc-editor.org/info/rfc2474>. | <https://www.rfc-editor.org/info/rfc2474>. | |||
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A | [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A | |||
Border Gateway Protocol 4 (BGP-4)", RFC 4271, | Border Gateway Protocol 4 (BGP-4)", RFC 4271, | |||
DOI 10.17487/RFC4271, January 2006, | DOI 10.17487/RFC4271, January 2006, | |||
<http://www.rfc-editor.org/info/rfc4271>. | <https://www.rfc-editor.org/info/rfc4271>. | |||
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended | [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended | |||
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, | Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, | |||
February 2006, <http://www.rfc-editor.org/info/rfc4360>. | February 2006, <https://www.rfc-editor.org/info/rfc4360>. | |||
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private | [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private | |||
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February | Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February | |||
2006, <http://www.rfc-editor.org/info/rfc4364>. | 2006, <https://www.rfc-editor.org/info/rfc4364>. | |||
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, | [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, | |||
"Multiprotocol Extensions for BGP-4", RFC 4760, | "Multiprotocol Extensions for BGP-4", RFC 4760, | |||
DOI 10.17487/RFC4760, January 2007, | DOI 10.17487/RFC4760, January 2007, | |||
<http://www.rfc-editor.org/info/rfc4760>. | <https://www.rfc-editor.org/info/rfc4760>. | |||
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private | [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private | |||
LAN Service (VPLS) Using BGP for Auto-Discovery and | LAN Service (VPLS) Using BGP for Auto-Discovery and | |||
Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, | Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, | |||
<http://www.rfc-editor.org/info/rfc4761>. | <https://www.rfc-editor.org/info/rfc4761>. | |||
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private | [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private | |||
LAN Service (VPLS) Using Label Distribution Protocol (LDP) | LAN Service (VPLS) Using Label Distribution Protocol (LDP) | |||
Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, | Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, | |||
<http://www.rfc-editor.org/info/rfc4762>. | <https://www.rfc-editor.org/info/rfc4762>. | |||
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
IANA Considerations Section in RFCs", RFC 5226, | IANA Considerations Section in RFCs", RFC 5226, | |||
DOI 10.17487/RFC5226, May 2008, | DOI 10.17487/RFC5226, May 2008, | |||
<http://www.rfc-editor.org/info/rfc5226>. | <https://www.rfc-editor.org/info/rfc5226>. | |||
[RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., | [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., | |||
and D. McPherson, "Dissemination of Flow Specification | and D. McPherson, "Dissemination of Flow Specification | |||
Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, | Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, | |||
<http://www.rfc-editor.org/info/rfc5575>. | <https://www.rfc-editor.org/info/rfc5575>. | |||
[RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS | [RFC5668] Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS | |||
Specific BGP Extended Community", RFC 5668, | Specific BGP Extended Community", RFC 5668, | |||
DOI 10.17487/RFC5668, October 2009, | DOI 10.17487/RFC5668, October 2009, | |||
<http://www.rfc-editor.org/info/rfc5668>. | <https://www.rfc-editor.org/info/rfc5668>. | |||
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., | [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., | |||
and A. Bierman, Ed., "Network Configuration Protocol | and A. Bierman, Ed., "Network Configuration Protocol | |||
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, | (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, | |||
<http://www.rfc-editor.org/info/rfc6241>. | <https://www.rfc-editor.org/info/rfc6241>. | |||
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route | [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route | |||
Origin Authorizations (ROAs)", RFC 6482, | Origin Authorizations (ROAs)", RFC 6482, | |||
DOI 10.17487/RFC6482, February 2012, | DOI 10.17487/RFC6482, February 2012, | |||
<http://www.rfc-editor.org/info/rfc6482>. | <https://www.rfc-editor.org/info/rfc6482>. | |||
[RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP | [RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP | |||
Extended Communities", RFC 7153, DOI 10.17487/RFC7153, | Extended Communities", RFC 7153, DOI 10.17487/RFC7153, | |||
March 2014, <http://www.rfc-editor.org/info/rfc7153>. | March 2014, <https://www.rfc-editor.org/info/rfc7153>. | |||
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. | [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. | |||
Patel, "Revised Error Handling for BGP UPDATE Messages", | Patel, "Revised Error Handling for BGP UPDATE Messages", | |||
RFC 7606, DOI 10.17487/RFC7606, August 2015, | RFC 7606, DOI 10.17487/RFC7606, August 2015, | |||
<http://www.rfc-editor.org/info/rfc7606>. | <https://www.rfc-editor.org/info/rfc7606>. | |||
[RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect | [RFC7674] Haas, J., Ed., "Clarification of the Flowspec Redirect | |||
Extended Community", RFC 7674, DOI 10.17487/RFC7674, | Extended Community", RFC 7674, DOI 10.17487/RFC7674, | |||
October 2015, <http://www.rfc-editor.org/info/rfc7674>. | October 2015, <https://www.rfc-editor.org/info/rfc7674>. | |||
15.2. Informative References | 15.2. Informative References | |||
[I-D.ietf-idr-flow-spec-v6] | [I-D.ietf-idr-flow-spec-v6] | |||
McPherson, D., Raszuk, R., Pithawala, B., | McPherson, D., Raszuk, R., Pithawala, B., | |||
akarch@cisco.com, a., and S. Hares, "Dissemination of Flow | akarch@cisco.com, a., and S. Hares, "Dissemination of Flow | |||
Specification Rules for IPv6", draft-ietf-idr-flow-spec- | Specification Rules for IPv6", draft-ietf-idr-flow-spec- | |||
v6-08 (work in progress), March 2017. | v6-08 (work in progress), March 2017. | |||
[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, | |||
<http://www.rfc-editor.org/info/rfc4303>. | <https://www.rfc-editor.org/info/rfc4303>. | |||
15.3. URIs | ||||
[1] https://github.com/stoffi92/flowspec-cmp | ||||
Appendix A. Comparison with RFC 5575 | Appendix A. Comparison with RFC 5575 | |||
This document includes numerous editorial changes to [RFC5575]. It | This document includes numerous editorial changes to [RFC5575]. It | |||
is recommended to read the entire document. The authors, however | is recommended to read the entire document. The authors, however | |||
want to point out the following technical changes to [RFC5575]: | want to point out the following technical changes to [RFC5575]: | |||
Section 4.2.3 defines a numeric operator and comparison bit | Section 4.2.3 defines a numeric operator and comparison bit | |||
combinations. In [RFC5575] the meaning of those bit combination | combinations. In [RFC5575] the meaning of those bit combination | |||
was not explicitly defined and left open to the reader. | was not explicitly defined and left open to the reader. | |||
skipping to change at page 31, line 48 ¶ | skipping to change at page 32, line 32 ¶ | |||
transitivity of the other action communities at all. | transitivity of the other action communities at all. | |||
Section 7.2 introduces a new traffic filtering action (traffic- | Section 7.2 introduces a new traffic filtering action (traffic- | |||
rate-packets). This action did not exist in [RFC5575]. | rate-packets). This action did not exist in [RFC5575]. | |||
Section 7.4 contains the same redirect actions already defined in | Section 7.4 contains the same redirect actions already defined in | |||
[RFC5575] however, these actions have been renamed to "rt- | [RFC5575] however, these actions have been renamed to "rt- | |||
redirect" to make it clearer that the redirection is based on | redirect" to make it clearer that the redirection is based on | |||
route-target. | route-target. | |||
Section 7.6 introduces rules how updates of flow specifications | Section 7.6 introduces rules how updates of Flow Specifications | |||
shall be handled in case they contain interfering actions. | shall be handled in case they contain interfering actions. | |||
Section 7.3 also cross-references this section. [RFC5575] did not | Section 7.3 also cross-references this section. [RFC5575] did not | |||
define this. | define this. | |||
Authors' Addresses | Authors' Addresses | |||
Susan Hares | Susan Hares | |||
Huawei | Huawei | |||
7453 Hickory Hill | 7453 Hickory Hill | |||
Saline, MI 48176 | Saline, MI 48176 | |||
End of changes. 84 change blocks. | ||||
144 lines changed or deleted | 179 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/ |