draft-ietf-idr-flow-spec-v6-05.txt   draft-ietf-idr-flow-spec-v6-06.txt 
IDR Working Group R. Raszuk, Ed. IDR Working Group R. Raszuk
Internet-Draft NTT MCL Inc. Internet-Draft Mirantis Inc.
Updates: RFC5575 (if approved) B. Pithawala Updates: RFC5575 (if approved) B. Pithawala
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: September 21, 2014 D. McPherson Expires: May 14, 2015 D. McPherson
Verisign, Inc. Verisign, Inc.
A. Karch A. Karch
Cisco Systems Cisco Systems
March 20, 2014 November 10, 2014
Dissemination of Flow Specification Rules for IPv6 Dissemination of Flow Specification Rules for IPv6
draft-ietf-idr-flow-spec-v6-05 draft-ietf-idr-flow-spec-v6-06
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 42
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 September 21, 2014. This Internet-Draft will expire on May 14, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 3, line 49 skipping to change at page 3, line 49
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 offset (1 octet), prefix length Encoding: <type (1 octet), prefix length (1 octet), prefix offset
(1 octet), prefix> (1 octet), prefix>
Defines the destination prefix to match. Prefix offset has been Defines the destination prefix to match. Prefix offset has been
defined to allow for flexible matching on part of the IPv6 address defined to allow for flexible matching on part of the IPv6 address
where we want to skip (don't care) of N first bits of the address. where we want to skip (don't care) of N first bits of the address.
This can be especially useful where part of the IPv6 address This can be especially useful where part of the IPv6 address
consists of an embedded IPv4 address and matching needs to happen consists of an embedded IPv4 address and matching needs to happen
only on the embedded IPv4 address. The encoded prefix contains only on the embedded IPv4 address. The encoded prefix contains
enough octets for the bits used in matching (length minus offset enough octets for the bits used in matching (length minus offset
bits). bits).
Type 2 - Source IPv6 Prefix Type 2 - Source IPv6 Prefix
Encoding: <type (1 octet), prefix offset (1 octet), prefix length Encoding: <type (1 octet), prefix length (1 octet), prefix offset
(1 octet), prefix> (1 octet), prefix>
Defines the source prefix to match. Prefix offset has been Defines the source prefix to match. Prefix offset has been
defined to allow for flexible matching on part of the IPv6 address defined to allow for flexible matching on part of the IPv6 address
where we want to skip (don't care) of N first bits of the address. where we want to skip (don't care) of N first bits of the address.
This can be especially useful where part of the IPv6 address This can be especially useful where part of the IPv6 address
consists of an embedded IPv4 address and matching needs to happen consists of an embedded IPv4 address and matching needs to happen
only on the embedded IPv4 address. The encoded prefix contains only on the embedded IPv4 address. The encoded prefix contains
enough octets for the bits used in matching (length minus offset enough octets for the bits used in matching (length minus offset
bits). bits).
skipping to change at page 5, line 24 skipping to change at page 5, line 24
+ 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, value]+>
Contains a set of {operator, value} pairs that are used to match Contains a set of {operator, value} pairs that are used to match
the 20-bit Flow Label field [RFC2460]. The operator byte is the 20-bit Flow Label field [RFC2460]. The operator byte is
encoded as specified in the component type 3 of [RFC5575]. encoded as specified in the component type 3 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/80-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 |
+---------------------------+-------------+-------------------------+ +---------------------------+-------------+-------------------------+
| 0x01 40 68 12 34 56 78 9A | 02 00 08 c0 | 04 03 89 45 8b 91 1f 90 | | 0x01 68 50 12 34 56 78 9A | 02 00 08 c0 | 04 03 89 45 8b 91 1f 90 |
+---------------------------+-------------+-------------------------+ +---------------------------+-------------+-------------------------+
3.1. Order of Traffic Filtering Rules 3.1. Order of Traffic Filtering Rules
The orignal definition for the order of traffic filtering rules can The orignal definition for the order of traffic filtering rules can
be reused with new consideration for the IPv6 prefix offset. As long be reused with new consideration for the IPv6 prefix offset. As long
as the offsets are equal, the comparison is the same, retaining as the offsets are equal, the comparison is the same, retaining
longest-prefix-match semantics. If the offsets are not equal, the longest-prefix-match semantics. If the offsets are not equal, the
lowest offset has precedence, as this flow matches the most lowest offset has precedence, as this flow matches the most
significant bit. significant bit.
skipping to change at page 9, line 4 skipping to change at page 9, line 4
[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, November 2009.
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, December
2007. 2007.
Authors' Addresses Authors' Addresses
Robert Raszuk (editor) Robert Raszuk
NTT MCL Inc. Mirantis Inc.
101 S Ellsworth Avenue Suite 350 615 National Ave. #100
San Mateo, CA 94401 Mt View, CA 94043
US USA
Email: robert@raszuk.net Email: robert@raszuk.net
Burjiz Pithawala Burjiz Pithawala
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
US US
Email: bpithaw@cisco.com Email: bpithaw@cisco.com
 End of changes. 11 change blocks. 
16 lines changed or deleted 17 lines changed or added

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