draft-ietf-idr-flow-spec-07.txt   draft-ietf-idr-flow-spec-08.txt 
IDR Working Group P. Marques IDR Working Group P. Marques
Internet-Draft N. Sheth Internet-Draft N. Sheth
Intended status: Standards Track R. Raszuk Intended status: Standards Track R. Raszuk
Expires: October 3, 2009 B. Greene Expires: October 23, 2009 B. Greene
Juniper Networks Juniper Networks
J. Mauch J. Mauch
NTT/Verio NTT/Verio
D. McPherson D. McPherson
Arbor Networks Arbor Networks
April 1, 2009 April 21, 2009
Dissemination of flow specification rules Dissemination of flow specification rules
draft-ietf-idr-flow-spec-07 draft-ietf-idr-flow-spec-08
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 3, 2009. This Internet-Draft will expire on October 23, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 10 skipping to change at page 3, line 10
The information is carried via the Border Gateway Protocol (BGP), The information is carried via the Border Gateway Protocol (BGP),
thereby reusing protocol algorithms, operational experience and thereby reusing protocol algorithms, operational experience and
administrative processes such as inter-provider peering agreements. administrative processes such as inter-provider peering agreements.
Table of Contents Table of Contents
1. Definitions of Terms Used in this Memo . . . . . . . . . . . . 4 1. Definitions of Terms Used in this Memo . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Flow specifications . . . . . . . . . . . . . . . . . . . . . 6 3. Flow specifications . . . . . . . . . . . . . . . . . . . . . 6
4. Dissemination of Information . . . . . . . . . . . . . . . . . 6 4. Dissemination of Information . . . . . . . . . . . . . . . . . 7
5. Traffic filtering . . . . . . . . . . . . . . . . . . . . . . 12 5. Traffic filtering . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Order of traffic filtering rules . . . . . . . . . . . . . 13 5.1. Order of traffic filtering rules . . . . . . . . . . . . . 14
6. Validation procedure . . . . . . . . . . . . . . . . . . . . . 14 6. Validation procedure . . . . . . . . . . . . . . . . . . . . . 15
7. Traffic Filtering Actions . . . . . . . . . . . . . . . . . . 16 7. Traffic Filtering Actions . . . . . . . . . . . . . . . . . . 16
8. Traffic filtering in RFC2547bis networks . . . . . . . . . . . 17 8. Traffic filtering in RFC2547bis networks . . . . . . . . . . . 18
9. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10. Security considerations . . . . . . . . . . . . . . . . . . . 18 10. Security considerations . . . . . . . . . . . . . . . . . . . 19
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
13. Normative References . . . . . . . . . . . . . . . . . . . . . 21 13. Normative References . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Definitions of Terms Used in this Memo 1. Definitions of Terms Used in this Memo
NLRI - Network Layer Reachability Information NLRI - Network Layer Reachability Information
RIB - Routing Information Base RIB - Routing Information Base
Loc-RIB - Local RIB Loc-RIB - Local RIB
AS - Autonomous System Number AS - Autonomous System Number
VRF - Virtual Routing and Forwarding instance VRF - Virtual Routing and Forwarding instance
PE - Provider Edge router PE - Provider Edge router
2. Introduction 2. Introduction
Modern IP routers contain both the capability to forward traffic Modern IP routers contain both the capability to forward traffic
according to aggregate IP prefixes as well as to classify, shape, according to aggregate IP prefixes as well as to classify, shape,
limit filter or redirect packets based on administratively defined rate limit, filter or redirect packets based on administratively
policies. defined policies.
While forwarding information is, typically, dynamically signaled While forwarding information is, typically, dynamically signaled
across the network via routing protocols, there is no agreed upon across the network via routing protocols, there is no agreed upon
mechanism to dynamically signal flows across autonomous-systems. mechanism to dynamically signal flow information across autonomous-
systems.
For several applications, it may be necessary to exchange control For several applications, it may be necessary to exchange control
information pertaining to aggregated traffic flow definitions which information pertaining to aggregated traffic flow definitions which
cannot be expressed using destination address prefixes only. cannot be expressed using destination address prefixes only.
An aggregated traffic flow is considered to be an n-tuple consisting An aggregated traffic flow is considered to be an n-tuple consisting
of several matching criteria such as source and destination address of several matching criteria such as source and destination address
prefixes, IP protocol and transport protocol port numbers. prefixes, IP protocol and transport protocol port numbers.
The intention of this document is to define a general procedure to The intention of this document is to define a general procedure to
skipping to change at page 5, line 9 skipping to change at page 5, line 9
By expanding routing information with flow specifications, the By expanding routing information with flow specifications, the
routing system can take advantage of the ACL/firewall capabilities in routing system can take advantage of the ACL/firewall capabilities in
the router's forwarding path. Flow specifications can be seen as the router's forwarding path. Flow specifications can be seen as
more specific routing entries to an unicast prefix and are expected more specific routing entries to an unicast prefix and are expected
to depend upon the existing unicast data information. to depend upon the existing unicast data information.
A flow specification received from a external autonomous-system will A flow specification received from a 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 which result in different safely install more specific flow rules which may result in different
forwarding behavior, as requested by this system. forwarding behavior, as requested by this system.
The choice of BGP as the carrier of this control information is also The key technology components required to address the class of
justifiable by the fact that the key issues in terms of complexity problems targeted by this document are:
are problems which are common to unicast route distribution and have
already been solved in the current environment.
From an algorithmic perspective, the main problem that presents 1. Efficient point to multi-point distribution of control plane
itself is the loop-free distribution of <key, attribute> pairs from information.
one originator to N ingresses. The key, in this particular instance,
being a flow specification. 2. Inter-domain capabilities and routing policy support.
3. Tight integration with unicast routing, for verification
purposes.
Items 1 and 2 have already been addressed using BGP for other types
of control plane information. Close integration with BGP also makes
it feasible to specific a mechanism to automatically verify flow
information against unicast routing. These factors are behind the
choice of BGP as the carrier of flow specification information.
As with previous extensions to the BGP protocol, this specification
makes it possible to add additional information to Internet routers.
These 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 given unit of time. The authors believe that, as with
previous extensions, service providers will be careful to keep
information levels bellow the maximum capacity of their devices.
It is also expected that in many initial deployments flow
specification information will replace existing host length route
advertisements rather than add additional information.
Experience with previous BGP extensions has also shown that the
maximum capacity of BGP speakers has been gradually increased
according to expected loads. Taking into account Internet unicast
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
reflector or confederation design) and existing external reflector or confederation design) and existing external
relationships (e.g.: inter-domain BGP sessions to a customer relationships (e.g.: inter-domain BGP sessions to a customer
network). network).
While it is certainly possible to address this problem using other While it is certainly possible to address this problem using other
mechanisms, the authors believe that this solution offers the mechanisms, the authors believe that this solution offers the
substantial advantage of being an incremental addition to deployed substantial advantage of being an incremental addition to already
mechanisms. deployed mechanisms.
At the current deployments the information distributed by the flow- In current deployments, the information distributed by the flow-spec
spec extension is originated both manually as well as automatically extension is originated both manually as well as automatically. The
by systems which are able to detect malicious flows. When automated latter by systems which are able to detect malicious flows. When
systems are used care should be taken to their correctness and rate automated systems are used care should be taken to ensure their
of advertisement of flow routes. correctness as well as to limit the advertisement rate of flow
routes.
This specification defines required protocol extensions to address This specification defines required protocol extensions to address
most common applications of IPv4 unicast and VPNv4 unicast filtering. most common applications of IPv4 unicast and VPNv4 unicast filtering.
The same mechanism can be reused and new match criteria added to The same mechanism can be reused and new match criteria added to
address similar filtering needs for other BGP address families (for address similar filtering needs for other BGP address families (for
example IPv6 unicast). Authors believe that those would be best to example IPv6 unicast). Authors believe that those would be best to
be addressed in a separate document. be addressed in a separate document.
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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Flow specifications 3. Flow specifications
A flow specification is an n-tuple consisting on 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 8, line 14 skipping to change at page 8, line 37
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| e | a | len | 0 |lt |gt |eq | | e | a | len | 0 |lt |gt |eq |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Numeric operator Numeric operator
* End of List bit. Set in the last {op, value} pair in the list. * End of List bit. Set in the last {op, value} pair in the list.
* And bit. If unset the previous term is logically ORed with the * AND bit. If unset the previous term is logically ORed with the
current one. If set the operation is a logical AND. It should current one. If set the operation is a logical AND. It should
be unset in the first operator byte of a sequence. The AND be unset in the first operator byte of a sequence. The AND
operator has higher priority than OR for the purposes of operator has higher priority than OR for the purposes of
evaluating logical expressions. evaluating logical expressions.
* The length of value field for this operand is given as (1 << * The length of value field for this operand is given as (1 <<
len). len).
* Lt - less than comparison between data and value. * Lt - less than comparison between data and value.
skipping to change at page 8, line 43 skipping to change at page 9, line 19
Encoding: <type (1 octet), [op, value]+> Encoding: <type (1 octet), [op, value]+>
Defines a list of {operation, value} pairs that matches source Defines a list of {operation, value} pairs that matches source
OR destination TCP/UDP ports. This list is encoded using the OR destination TCP/UDP ports. This list is encoded using the
numeric operand format defined above. Values are encoded as 1 numeric operand format defined above. Values are encoded as 1
or 2 byte quantities. or 2 byte quantities.
Port, source port and destination port components evaluate to Port, source port and destination port components evaluate to
FALSE if the IP protocol field of the packet has a value other FALSE if the IP protocol field of the packet has a value other
than TCP or UDP, if the packet is framented and this is not the than TCP or UDP, if the packet is fragmented and this is not
first fragment or if the system in unable to locate the the first fragment or if the system in unable to locate the
transport header. Different implementations may or may not be transport header. Different implementations may or may not be
able to decode the transport header in the presence of IP able to decode the transport header in the presence of IP
options or ESP NULL [RFC4303] encryption. options or ESP NULL [RFC4303] encryption.
Type 5 - Destination port Type 5 - Destination port
Encoding: <type (1 octet), [op, value]+> Encoding: <type (1 octet), [op, value]+>
Defines a list of {operation, value} pairs used to match the Defines a list of {operation, value} pairs used to match the
destination port of a TCP or UDP packet. Values are encoded as destination port of a TCP or UDP packet. Values are encoded as
1 or 2 byte quantities. 1 or 2 byte quantities.
Type 6 - Source port Type 6 - Source port
Encoding: <type (1 octet), [op, value]+> Encoding: <type (1 octet), [op, value]+>
Defines a list of {operation, value} pairs used to match the Defines a list of {operation, value} pairs used to match the
source port of a TCP or UDP packet. Values are encoded as 1 or source port of a TCP or UDP packet. Values are encoded as 1 or
skipping to change at page 10, line 10 skipping to change at page 10, line 34
packets that are not TCP packets. packets that are not TCP packets.
This type uses the bitmask operand format, which differs from This type uses the bitmask operand format, which differs from
the numeric operator format in the lower nibble. the numeric operator format in the lower nibble.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| e | a | len | 0 | 0 |not| m | | e | a | len | 0 | 0 |not| m |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
* Most significant nibble: (End of List bit, And bit and Length * Most significant nibble: (End of List bit, AND bit and Length
field), as defined for in the numeric operator format. field), as defined for in the numeric operator format.
* Not bit. If set, logical negation of operation. * NOT bit. If set, logical negation of operation.
* Match bit. If set this is a bitwise match operation defined as * Match bit. If set this is a bitwise match operation defined as
"(data & value) == value"; if unset (data & value) evaluates to "(data & value) == value"; if unset (data & value) evaluates to
true if any of the bits in the value mask are set in the data. true if any of the bits in the value mask are set in the data.
Type 10 - Packet length Type 10 - Packet length
Encoding: <type (1 octet), [op, value]+> Encoding: <type (1 octet), [op, value]+>
Match on the total IP packet length (excluding L2 but including Match on the total IP packet length (excluding L2 but including
skipping to change at page 13, line 5 skipping to change at page 13, line 32
Several techniques are currently used to control traffic filtering of Several techniques are currently used to control traffic filtering of
DoS attacks. Among those, one of the most common is to inject DoS attacks. Among those, one of the most common is to inject
unicast route advertisements corresponding to a destination prefix unicast route advertisements corresponding to a destination prefix
being attacked. One variant of this technique marks such route being attacked. One variant of this technique marks such route
advertisements with a community that gets translated into a discard advertisements with a community that gets translated into a discard
next-hop by the receiving router. Other variants, attract traffic to next-hop by the receiving router. Other variants, attract traffic to
a particular node that serves as a deterministic drop point. a particular node that serves as a deterministic drop point.
Using unicast routing advertisements to distribute traffic filtering Using unicast routing advertisements to distribute traffic filtering
information has the advantage of using the existing infrastructure information has the advantage of using the existing infrastructure
and inter-as communication channels. This can allow, for instance, and inter-as communication channels. This can allow, for instance, a
for a service provider to accept filtering requests from customers service provider to accept filtering requests from customers for
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 convey information about traffic filtering rules for traffic that
should be discarded. should be discarded.
skipping to change at page 13, line 43 skipping to change at page 14, line 23
5.1. Order of traffic filtering rules 5.1. Order 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 at particular traffic flow. Thus it is necessary to define the order at
which rules get matched and applied to a particular traffic flow. 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 specifications rules and must be constant arrival order of the flow specifications rules and must be constant
in the network. 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 the 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) the rule that doesn't contain that (and thus will match before) 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.
For IP prefix values (IP destination and source prefix) precedence is For IP prefix values (IP destination and source prefix) precedence is
given to lowest IP value of the common prefix length; if the common given to lowest IP value of the common prefix length; if the common
prefix is equal then the most specific prefix has precedence. prefix is equal then the most specific prefix has 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 the memcmp() function as defined by the ISO C string using the the memcmp() function as defined by the ISO C
standard. For strings of different lenghts, the common prefix is standard. For strings of different lengths, the common prefix is
compared. If equal the longest string is considered to have higher compared. If equal the longest string is considered to have higher
precedence than the shorter one. precedence than the shorter one.
Pseudocode: Pseudocode:
flow_rule_cmp (a, b) flow_rule_cmp (a, b)
{ {
comp1 = next_component(a); comp1 = next_component(a);
comp2 = next_component(b); comp2 = next_component(b);
while (comp1 || comp2) { while (comp1 || comp2) {
// component_type returns infinity on end-of-list // component_type returns infinity on end-of-list
if (component_type(comp1) < compnent_type(comp2)) { if (component_type(comp1) < compnent_type(comp2)) {
return A_HAS_PRECEDENCE; return A_HAS_PRECEDENCE;
} }
if (component_type(comp1) > compnent_type(comp2)) { if (component_type(comp1) > component_type(comp2)) {
return B_HAS_PRECEDENCE; return B_HAS_PRECEDENCE;
} }
if (component_type(comp1) == IP_DESTINATION || IP_SOURCE) { if (component_type(comp1) == IP_DESTINATION || IP_SOURCE) {
common = MIN(prefix_length(comp1), prefix_length(comp2)); common = MIN(prefix_length(comp1), prefix_length(comp2));
cmp = prefix_compare(comp1, comp2, common); cmp = prefix_compare(comp1, comp2, common);
// not equal, lowest value has precedence // not equal, lowest value has precedence
// equal, longest match has precedence // equal, longest match has precedence
} else { } else {
common = MIN(component_length(comp1), component_length(comp2)); common = MIN(component_length(comp1), component_length(comp2));
skipping to change at page 18, line 11 skipping to change at page 18, line 49
In circumstances where a security threat does get propagated inside In circumstances where a security threat does get propagated inside
the VPN customer network, there may not be readily available the VPN customer network, there may not be readily available
mechanisms to provide mitigation via traffic filter. mechanisms to provide mitigation via traffic filter.
This document proposes an additional BGP NLRI type (afi=1, safi=134) This document proposes an additional BGP NLRI type (afi=1, safi=134)
value, which can be used to propagate traffic filtering information value, which can be used to propagate traffic filtering information
in a BGP/MPLS VPN environment. in a BGP/MPLS VPN 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 encoded defined in this document. The NLRI length following the encoding defined in this document. The NLRI length
field shall includes the both 8 bytes of the Route Distinguisher as field shall include both the 8 bytes of the Route Distinguisher as
well as the subsequent flow specification. well as the subsequent flow specification.
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
skipping to change at page 19, line 11 skipping to change at page 19, line 49
As long as traffic filtering rules are restricted to match the As long as traffic filtering rules are restricted to match the
corresponding unicast routing paths for the relevant prefixes, the corresponding unicast routing paths for the relevant prefixes, the
security characteristics of this proposal are equivalent to the security characteristics of this proposal are equivalent to the
existing security properties of BGP unicast routing. existing security properties of BGP unicast routing.
Where it not the case, this would open the door to further denial of Where it not the case, this would open the door to further denial of
service attacks. service attacks.
Enabling firewall like capabilities in routers without centralized Enabling firewall like capabilities in routers without centralized
management could make certain failures harder to diagnose. For management could make certain failures harder to diagnose. For
example, with the extensions it is possible to allow TCP packets to example, it is possible to allow TCP packets to pass between a pair
pass between a pair of addresses but not ICMP packets. It would also of addresses but not ICMP packets. It is also possible to permit
be possible to permit packets smaller than 900 or greater than 1000 packets smaller than 900 or greater than 1000 bytes to pass between a
bytes to pass between a pair of addresses, but not packets whose pair of addresses, but not packets whose length is in the range 900-
length is in the range 900-1000. The Internet has become 1000. Such behavior may be confusing and these capabilities should
sufficiently aware of firewalls that such behavior is less likely to be used with care whether manually configured or coordinated through
be confusing than it was a few years ago and there are no new the protocol extensions described in this document.
capabilities introduced by these extensions, just an increased
likelihood that such capabilities will be used.
11. IANA Considerations 11. IANA Considerations
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. Types must be assigned are identified by a an 8-bit component type. Types must be assigned
and interpreted uniquely. The current specification defines types 1 and interpreted uniquely. The current specification defines types 1
though 12, with the value 0 being reserved. though 12, with the value 0 being reserved.
For the purpose of this work IANA has allocated values for two SAFIs: For the purpose of this work IANA has allocated values for two SAFIs:
SAFI 133 for IPv4 and SAFI 134 for VPNv4 dissemination of flow SAFI 133 for IPv4 and SAFI 134 for VPNv4 dissemination of flow
 End of changes. 26 change blocks. 
55 lines changed or deleted 80 lines changed or added

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