< draft-ietf-idr-flow-spec-v6-06.txt   draft-ietf-idr-flow-spec-v6-07.txt >
IDR Working Group R. Raszuk IDR Working Group D. McPherson
Internet-Draft Mirantis Inc. Internet-Draft Verisign, Inc.
Updates: RFC5575 (if approved) B. Pithawala Intended status: Standards Track R. Raszuk, Ed.
Intended status: Standards Track Cisco Systems Expires: September 20, 2016 Bloomberg LP
Expires: May 14, 2015 D. McPherson B. Pithawala
Verisign, Inc. Individual
A. Karch A. Karch
Cisco Systems Cisco Systems
November 10, 2014 S. Hares, Ed.
Huawei
March 19, 2016
Dissemination of Flow Specification Rules for IPv6 Dissemination of Flow Specification Rules for IPv6
draft-ietf-idr-flow-spec-v6-06 draft-ietf-idr-flow-spec-v6-07.txt
Abstract Abstract
Dissemination of Flow Specification Rules [RFC5575] provides a Dissemination of Flow Specification Rules [RFC5575] provides a
protocol extension for propagation of traffic flow information for protocol extension for propagation of traffic flow information for
the purpose of rate limiting or filtering. The [RFC5575] specifies the purpose of rate limiting or filtering. The [RFC5575] specifies
those extensions for IPv4 protocol data packets. those extensions for IPv4 protocol data packets.
This specification extends the current [RFC5575] and defines changes This specification extends the current [RFC5575] and defines changes
to the original document in order to make it also usable and to the original document in order to make it also usable and
skipping to change at page 1, line 42 skipping to change at page 1, line 44
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 http://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 May 14, 2015. This Internet-Draft will expire on September 20, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2016 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. IPv6 Flow Specification encoding in BGP . . . . . . . . . . . 2 2. IPv6 Flow Specification encoding in BGP . . . . . . . . . . . 3
3. IPv6 Flow Specification types changes . . . . . . . . . . . . 3 3. IPv6 Flow Specification types changes . . . . . . . . . . . . 3
3.1. Order of Traffic Filtering Rules . . . . . . . . . . . . 5 3.1. Order of Traffic Filtering Rules . . . . . . . . . . . . 5
4. IPv6 Flow Specification Traffic Filtering Action changes . . 6 4. IPv6 Flow Specification Traffic Filtering Action changes . . 6
5. Security considerations . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The growing amount of IPv6 traffic in private and public networks The growing amount of IPv6 traffic in private and public networks
requires the extension of tools used in the IPv4 only networks to be requires the extension of tools used in the IPv4 only networks to be
also capable of supporting IPv6 data packets. also capable of supporting IPv6 data packets.
In this document authors analyze the differences of IPv6 [RFC2460] In this document authors analyze the differences of IPv6 [RFC2460]
flows description from those of traditional IPv4 packets and propose flows description from those of traditional IPv4 packets and propose
subset of new encoding formats to enable Dissemination of Flow subset of new encoding formats to enable Dissemination of Flow
skipping to change at page 3, line 45 skipping to change at page 3, line 51
Flow specification received over AFI/SAFI=2/133 will be validated Flow specification received over AFI/SAFI=2/133 will be validated
against routing reachability received over AFI/SAFI=2/1 against routing reachability received over AFI/SAFI=2/1
Flow specification received over AFI/SAFI=2/134 will be validated Flow specification received over AFI/SAFI=2/134 will be validated
against routing reachability received over AFI/SAFI=2/128 against routing reachability received over AFI/SAFI=2/128
3. IPv6 Flow Specification types changes 3. IPv6 Flow Specification types changes
The following component types are redefined or added for the purpose The following component types are redefined or added for the purpose
of accommodating new IPv6 header encoding. Unless otherwise stated of accommodating new IPv6 header encoding. Unless otherwise stated
all other types as defined in RFC5575 apply to IPv6 packets as is. all other types as defined in [RFC5575] apply to IPv6 packets as is.
Type 1 - Destination IPv6 Prefix Type 1 - Destination IPv6 Prefix
Encoding: <type (1 octet), prefix length (1 octet), prefix offset Encoding: <type (1 octet), prefix length (1 octet), prefix
(1 octet), prefix> offset (1 octet), prefix>
Defines the destination prefix to match. Prefix offset has been
defined to allow for flexible matching on part of the IPv6 address Function: Defines the destination prefix to match. Prefix
where we want to skip (don't care) of N first bits of the address. offset has been defined to allow for flexible matching on part
This can be especially useful where part of the IPv6 address of the IPv6 address where we want to skip (don't care) of N
consists of an embedded IPv4 address and matching needs to happen first bits of the address. This can be especially useful where
only on the embedded IPv4 address. The encoded prefix contains part of the IPv6 address consists of an embedded IPv4 address
enough octets for the bits used in matching (length minus offset and matching needs to happen only on the embedded IPv4 address.
bits). The encoded prefix contains enough octets for the bits used in
matching (length minus offset bits).
Type 2 - Source IPv6 Prefix Type 2 - Source IPv6 Prefix
Encoding: <type (1 octet), prefix length (1 octet), prefix offset Encoding: <type (1 octet), prefix length (1 octet), prefix
(1 octet), prefix> offset (1 octet), prefix>
Defines the source prefix to match. Prefix offset has been Function: Defines the source prefix to match. Prefix offset
defined to allow for flexible matching on part of the IPv6 address has been defined to allow for flexible matching on part of the
where we want to skip (don't care) of N first bits of the address. IPv6 address where we want to skip (don't care) of N first bits
This can be especially useful where part of the IPv6 address of the address. This can be especially useful where part of
consists of an embedded IPv4 address and matching needs to happen the IPv6 address consists of an embedded IPv4 address and
only on the embedded IPv4 address. The encoded prefix contains matching needs to happen only on the embedded IPv4 address.
enough octets for the bits used in matching (length minus offset The encoded prefix contains enough octets for the bits used in
bits). matching (length minus offset bits)
Type 3 - Next Header Type 3 - Next Header
Encoding: <type (1 octet), [op, value]+> Encoding: <type (1 octet), [op, value]+>
Contains a set of {operator, value} pairs that are used to match Function: Contains a set of {operator, value} pairs that are
the last Next Header value octet in IPv6 packets. The operator used to match the last Next Header value octet in IPv6 packets.
byte is encoded as specified in component type 3 of [RFC5575]. The operator byte is encoded as specified in component type 3
of [RFC5575].
While IPv6 allows for more then one Next Header field in the Note: While IPv6 allows for more then one Next Header field in
packet the main goal of Type 3 flow specification component is to the packet the main goal of Type 3 flow specification component
match on the subsequent IP protocol value. Therefor the is to match on the subsequent IP protocol value. Therefor the
definition is limited to match only on last Next Header field in definition is limited to match only on last Next Header field
the packet. in the packet.
Type 12 - Fragment Type 12 - Fragment
Encoding: <type (1 octet), [op, bitmask]+> Encoding: <type (1 octet), [op, bitmask]+>
Uses bitmask operand format defined above. Bit-7 is not used
and MUST be 0 to provide backwards-compatibility with the
definition in [RFC5575]
Uses bitmask operand format defined above. Bit-7 is not used and Bitmast operand format:
MUST be 0 to provide backwards-compatibility with the definition
in RFC5575.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| Reserved |LF |FF |IsF| 0 | | Reserved |LF |FF |IsF| 0 |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
Bitmask values: Bitmask values:
+ 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)
Type 13 - Flow Label - New type Type 13 - Flow Label (New type)
Encoding: <type (1 octet), [op, value]+> Encoding: <type (1 octet), [op, bitmask]+>
Contains a set of {operator, value} pairs that are used to match Function: Contains a set of {operator, value} pairs that are
the 20-bit Flow Label field [RFC2460]. The operator byte is used to match the 20-bit Flow Label field [RFC2460]. The
encoded as specified in the component type 3 of [RFC5575]. Values operator byte is encoded as specified in the component type 3
are encoded as 1-, 2-, or 4- byte quantities. of [RFC5575]. Values are encoded as 1-, 2-, or 4- byte
quantities.
The following example demonstrates the new prefix encoding for: "all The following example demonstrates the new prefix encoding for: "all
packets to ::1234:5678:9A00:0/64-104 from 192::/8 and port {range packets to ::1234:5678:9A00:0/64-104 from 192::/8 and port {range
[137, 139] or 8080}". In the destination prefix, "80-" represents [137, 139] or 8080}". In the destination prefix, "80-" represents
the prefix offset of 80 bits. In this exmaple, the 0 offset is the prefix offset of 80 bits. In this exmaple, the 0 offset is
omitted from the printed source prefix. omitted from the printed source prefix.
+---------------------------+-------------+-------------------------+ +---------------------------+-------------+-------------------------+
| destination | source | port | | destination | source | port |
+---------------------------+-------------+-------------------------+ +---------------------------+-------------+-------------------------+
skipping to change at page 6, line 38 skipping to change at page 6, line 44
// equal, longest string has precedence // equal, longest string has precedence
} }
} }
return EQUAL; return EQUAL;
} }
4. IPv6 Flow Specification Traffic Filtering Action changes 4. IPv6 Flow Specification Traffic Filtering Action changes
One of the traffic filtering actions which can be expressed by BGP One of the traffic filtering actions which can be expressed by BGP
extended community is defined in [RFC5575] as traffic-marking. This extended community is defined in [RFC5575] as traffic-marking.
extended community type is of value: 0x8009.
For the purpose of making it compatible with IPv6 header action
expressed by presence of this extended community has been modified to
read:
Traffic Marking: The traffic marking extended community instructs a
system to modify first 6 bits of Traffic Class field as (recommended
by [RFC2474]) of a transiting IPv6 packet to the corresponding value.
This extended community is encoded as a sequence of 42 zero bits
followed by the 6 bits overwriting DSCP portion of Traffic Class
value.
Another traffic filtering action defined in [RFC5575] as a BGP Another traffic filtering action defined in [RFC5575] as a BGP
extended community is redirect. To allow an IPv6 address specific extended community is redirect. To allow an IPv6 address specific
route-target, a new traffic action IPv6 address specific extended route-target, a new traffic action IPv6 address specific extended
community is provided. The extended community type has the value community is provided.
0x800b.
Redirect-IPv6: The redirect IPv6 address specific extended community Therefore, for the purpose of making it compatible with IPv6 header
allows the traffic to be redirected to a VRF routing instance that action expressed by presence of the extended community the following
lists the specified IPv6 address specific route-target in its import text in [RFC5575] has been modified to read:
policy. If several local instances match this criteria, the choice
between them is a local matter (for example, the instance with the
lowest Route Distinguisher value can be elected). This extended
community uses the same encoding as the IPv6 address specific Route
Target extended community [RFC5701].
5. Security considerations Traffic Marking (0x8009): The traffic marking extended community
instructs a system to modify first 6 bits of Traffic Class field
as (recommended by [RFC2474]) of a transiting IPv6 packet to the
corresponding value. This extended community is encoded as a
sequence of 42 zero bits followed by the 6 bits overwriting DSCP
portion of Traffic Class value.
Redirect-IPv6 (0x800B): redirect IPv6 address specific extended
community allows the traffic to be redirected to a VRF routing
instance that lists the specified IPv6 address specific route-
target in its import policy. If several local instances match
this criteria, the choice between them is a local matter (for
example, the instance with the lowest Route Distinguisher value
can be elected). This extended community uses the same encoding
as the IPv6 address specific Route Target extended community
[RFC5701].
5. Security Considerations
No new security issues are introduced to the BGP protocol by this No new security issues are introduced to the BGP protocol by this
specification. specification over the security concerins in [RFC5575]
6. IANA Considerations 6. IANA Considerations
This section complies with [RFC7153]
IANA is requested to rename currently defined SAFI 133 and SAFI 134 IANA is requested to rename currently defined SAFI 133 and SAFI 134
per [RFC5575] to read: per [RFC5575] to read:
133 Dissemination of flow specification rules 133 Dissemination of flow specification rules
134 L3VPN dissemination of flow specification rules 134 L3VPN dissemination of flow specification rules
IANA is requested to create and maintain a new registry entitled: IANA is requested to create and maintain a new registry entitled:
"Flow Spec IPv6 Component Types". The following component types have "Flow Spec IPv6 Component Types". The initial values are:
been registered:
Type 1 - Destination IPv6 Prefix Type Description RFC
Type 2 - Source IPv6 Prefix --------------------------------- ---------
Type 3 - Next Header Type 1 - Destination IPv6 Prefix [this draft]
Type 4 - Port Type 2 - Source IPv6 Prefix [this draft]
Type 5 - Destination port Type 3 - Next Header [this draft]
Type 6 - Source port Type 4 - Port [this draft]
Type 7 - ICMP type Type 5 - Destination port [this draft]
Type 8 - ICMP code Type 6 - Source port [this draft]
Type 9 - TCP flags Type 7 - ICMP type [this draft]
Type 10 - Packet length Type 8 - ICMP code [this draft]
Type 11 - DSCP Type 9 - TCP flags [this draft]
Type 12 - Fragment Type 10 - Packet length [this draft]
Type 13 - Flow Label Type 11 - DSCP [this draft]
Type 12 - Fragment [this draft]
Type 13 - Flow Label [this draft]
7. Acknowledgements
7. Acknowledgments
Authors would like to thank Pedro Marques, Hannes Gredler and Bruno Authors would like to thank Pedro Marques, Hannes Gredler and Bruno
Rijsman, Brian Carpenter, and Thomas Mangin for their valuable input. Rijsman, Brian Carpenter, and Thomas Mangin for their valuable input.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-6man-flow-3697bis]
Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", draft-ietf-6man-flow-
3697bis-07 (work in progress), July 2011.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[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, December Field) in the IPv4 and IPv6 Headers", RFC 2474,
1998. DOI 10.17487/RFC2474, December 1998,
<http://www.rfc-editor.org/info/rfc2474>.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Protocol 4 (BGP-4)", RFC 4271, January 2006. Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<http://www.rfc-editor.org/info/rfc4271>.
[RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement
with BGP-4", RFC 5492, February 2009. with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February
2009, <http://www.rfc-editor.org/info/rfc5492>.
[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, August 2009. Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009,
<http://www.rfc-editor.org/info/rfc5575>.
[RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community [RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community
Attribute", RFC 5701, November 2009. Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009,
<http://www.rfc-editor.org/info/rfc5701>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011,
<http://www.rfc-editor.org/info/rfc6437>.
[RFC7153] Rosen, E. and Y. Rekhter, "IANA Registries for BGP
Extended Communities", RFC 7153, DOI 10.17487/RFC7153,
March 2014, <http://www.rfc-editor.org/info/rfc7153>.
8.2. Informative References 8.2. Informative References
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095, December of Type 0 Routing Headers in IPv6", RFC 5095,
2007. DOI 10.17487/RFC5095, December 2007,
<http://www.rfc-editor.org/info/rfc5095>.
Authors' Addresses Authors' Addresses
Robert Raszuk
Mirantis Inc.
615 National Ave. #100
Mt View, CA 94043
USA
Email: robert@raszuk.net Danny McPherson
Verisign, Inc.
Burjiz Pithawala Email: dmcpherson@verisign.com
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
US
Email: bpithaw@cisco.com Robert Raszuk (editor)
Bloomberg LP
731 Lexington Ave
New York City, NY 10022
USA
Danny McPherson Email: robert@raszuk.net
Verisign, Inc.
Email: dmcpherson@verisign.com Burjiz Pithawala
Individual
Email: burjizp@gmail.com
Andy Karch Andy Karch
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
US USA
Email: akarch@cisco.com Email: akarch@cisco.com
Susan Hares (editor)
Huawei
7453 Hickory Hill
Saline, MI 48176
USA
Email: shares@ndzh.com
 End of changes. 54 change blocks. 
139 lines changed or deleted 158 lines changed or added

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