One document matched: draft-baker-ipv6-isis-dst-flowlabel-routing-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section,
otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a
string such as <29> printed in the blank line at the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents, but idnits insists on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="4"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others prefer
numbers. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc rfcprocack="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="std" docName="draft-baker-ipv6-isis-dst-flowlabel-routing-00"
ipr="trust200902">
<front>
<title abbrev="RBAC in Routing">Using IS-IS with Role-Based Access
Control</title>
<author fullname="Fred Baker" initials="F.J." surname="Baker">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city>Santa Barbara</city>
<code>93117</code>
<region>California</region>
<country>USA</country>
</postal>
<email>fred@cisco.com</email>
</address>
</author>
<date year="2013" />
<area>Internet Engineering Task Force</area>
<workgroup></workgroup>
<abstract>
<t>This note describes the changes necessary for IS-IS to route classes
of IPv6 traffic that are defined by an IPv6 Flow Label and a destination
prefix. This implies not routing "to a destination", but "traffic
matching a classification tuple". The obvious application is data center
inter-tenant routing using a form of role-based access control. If the
sender doesn't know the value to insert in the flow label (the
receiver's tenant ID), he in effect has no route to that
destination.</t>
</abstract>
<!--
<note title="Foreword">
</note>
-->
<!--
<?rfc needLines="10" ?>
<texttable anchor="table_example" title="A Very Simple Table">
<preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
<ttcol align="center">ttcol #1</ttcol>
<ttcol align="center">ttcol #2</ttcol>
<c>c #1</c> <c>c #2</c>
<c>c #3</c> <c>c #4</c>
<c>c #5</c> <c>c #6</c>
<postamble>which is a very simple example.</postamble>
</texttable>
-->
</front>
<middle>
<!--
<t>There are multiple list styles: "symbols", "letters", "numbers",
"hanging", "format", etc.</t>
<t>
<list style="symbols">
<t>First bullet</t>
<t>Second bullet</t>
</list>
</t>
-->
<!--
<figure anchor="reference" title="Figure">
<artwork align="center">
<![CDATA[
ASCII artwork goes here...
]]>
</artwork>
</figure>
-->
<section title="Introduction">
<t>This specification builds on the extensible TLV defined in <xref
target="RFC5308"></xref>. It adds to the existing Reachability TLV the
(obviously optional) sub-TLV for an IPv6 Flow Label, to define routes
defined by a destination prefix plus a flow label. <xref
target="RFC5308"></xref> also provides an "address TLV", which enables a
router to identify the prefixes in use on its interfaces. The Address
TLV is not extensible; it does not permit sub-TLVs. Hence, classes of
traffic defined by the destination address plus a flow label MUST be
advertised using the Reachability TLV.</t>
<t>Advertised IS-IS TLVs that specify only a destination prefix may be
understood as identifying a destination prefix used with "any" flow
label, which is a very useful class of traffic to compactly
represent.</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</section>
</section>
<section anchor="extensions" title="Theory of Routing">
<t>Both IS-IS and OSPF perform their calculations by building a lattice
of routers and routes from the router performing the calculation to each
router, and then use those routes to get to destinations that those
routes advertise connectivity to. Following the SPF algorithm,
calculation starts by selecting a starting point (typically the router
doing the calculation), and successively adding {link, router) pairs
until one has calculated a route to every router in the network. As each
router is added, including the original router, destinations that it is
directly connected to are turned into routes in the route table: "to get
to 2001:db8::/32, route traffic to {interface, list of next hop
routers}". For immediate neighbors to the originating router, of course,
there is no next hop router; traffic is handled locally.</t>
<t><xref target="ISO.10589.1992">IS-IS</xref> represents those
destinations as a type-length-value field that identifies an address.
For CLNS, it was designed for the ISO NSAP; by various extensions, it
also handles IPv4 and IPv6 prefixes and their counterparts for other
protocols. Adding a new class of traffic to route is as simple as adding
a new tuple type and the supporting method routines for that class of
traffic.</t>
<section title="Dealing with ambiguity">
<t>In any routing protocol, there is the possibility of ambiguity. An
area border router might, for example, summarize the routes to other
areas into a small set of relatively short prefixes, which have more
specific routes within the area. Traditionally, we have dealt with
that using a "longest match first" rule. If the same datagram matches
more than one destination prefix advertised within the area, we follow
the route to the longest matching prefix.</t>
<t>When routing a class of traffic, we follow an analogous "most
specific match" rule; we follow the route for the most specific
matching tuple. In cases of simple overlap, such as routing to
2001:db8::/32 or 2001:db8:1::/48, that is exactly analogous; we choose
one of the two routes.</t>
<t>It is possible, however, to construct an ambiguous case in which
neither class subsumes the other. For example, presume that <list
style="symbols">
<t>A is a prefix,</t>
<t>B is a more-specific prefix within A, and</t>
<t>C is a specific flow label value</t>
</list></t>
<t>The two classes "routes to A using flow label C" and "routes to B
using any flow label" are ambiguous: a datagram to B using the flow
label C matches both classes, and it is not clear in the data plane
what decision to make. Solving this requires the addition of a third
route in the FIB corresponding to the class for routes to B using flow
label C, which is more-specific than either of the first two, and can
be given routing guidance based on metrics or other policy in the
usual way.</t>
</section>
</section>
<section anchor="IS-IS-extensions-ipv6"
title="Extensions necessary for IS-IS/IPv6">
<t>Section 2 of <xref target="RFC5308"></xref> defines the "IPv6
Reachability TLV", and carries in it destination prefix advertisements.
It has the capability of extension, using sub-TLVs. The extension needed
is to add a sub-TLV for each additional item in the tuple. We interpret
the lack of a given sub-TLV as "any"; by definition, S=0 implies any
source address, any DSCP, and any flow label. If S=1, there will be one
or more additional sub-TLVs following the sub-TLV format specified
there.</t>
<section anchor="label-security" title="On Flow labels and Security">
<t>According to section 6 of <xref target="RFC2460"></xref>, a Flow
Label is a 20 bit number which <list style="empty">
<t>"may be used by a source to label sequences of packets for
which it requests special handling by the IPv6 routers".</t>
</list></t>
<t>The possible use case mentioned in an appendix is egress routing.
Other RFCs suggest other possible use cases.</t>
<t>In this model, the flow label is used to prove that the datagram's
sender has specific knowledge of its intended receiver. No proof is
requested; this is left for higher layer exchanges such as IPSec or
TLS. However, if the information is distributed privately, such as
through DHCP/DHCPv6, the network can presume that a system that marks
traffic with the right flow label has a good chance of being
authorized to communicate with its peer.</t>
<t>The key consideration, in this context, is that the flow label is a
20 bit number. As such, an advertised route requiring a given flow
label value is calling for an exact match of all 20 bits of the label
value.</t>
</section>
<section anchor="IS-IS-label" title="Flow Label sub-TLV">
<?rfc needLines="8"?>
<figure title="Flow Label Sub-TLV">
<artwork align="center"><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | MBZ | 20 bit Flow Label
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t><list style="hanging">
<t hangText="Flow Label Type:">assigned by IANA</t>
<t hangText="TLV Length:">Length of the sub-TLV in octets</t>
<t hangText="Flow Label:">20 bits of Flow Label value</t>
<t hangText="MBZ:">unused, MUST be zero when generated, ignored on
receipt.</t>
</list></t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This section will request an identifying value for the TLV defined.
This is deferred to the -01 version of the draft.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>To be considered.</t>
</section>
<section anchor="Privacy" title="Privacy Considerations">
<t>To be considered.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t></t>
</section>
<section anchor="log" title="Change Log">
<t><list style="hanging">
<t hangText="Initial Version:">February 2013</t>
</list></t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<references title="Normative References">
<?rfc include="reference.ISO.10589.1992" ?>
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.2460" ?>
<?rfc include="reference.RFC.5308" ?>
</references>
<references title="Informative References">
<reference anchor="PATRICIA">
<front>
<title>Practical Algorithm to Retrieve Information Coded in
Alphanumeric</title>
<author fullname="D.R. Morrison" initials="D.R." surname="Morrison">
<organization>Association for Computing Machinery</organization>
</author>
<date month="October" year="1968" />
</front>
<seriesInfo name="Journal of the ACM" value="15(4) pp514-534" />
<format target="http://www.csse.monash.edu.au/~lloyd/tildeAlgDS/Tree/PATRICIA/"
type="HTML" />
</reference>
</references>
<section anchor="rbac"
title="Use case: Data Center Role-based Access Control">
<t>Consider a data center in which IPv6 is deployed throughout using
internet routing technologies instead of tunnels, and the Flow Label is
used to identify tenants, as discussed in <xref
target="label-security"></xref>. Hosts are required, by configuration if
necessary, to know their own tenant number and the numbers of any
tenants they are authorized to communicate with. When they originate a
datagram, they send it to their peer's destination address and label it
with their peer's tenant id. They, or their router on their behalf,
advertise their own addresses as traffic classes <list style="empty">
<t>{destination prefix, Tenant Flow Label }</t>
</list></t>
<t>The net effect is that traffic is routed among tenants that are
authorized to communicate, but not among tenants that are not authorized
to communicate - there is no route. This is done without tunnels, access
lists, or other data plane overhead; the overhead is in the control
plane, equipping authorized parties to communicate.</t>
</section>
<section title="FIB Design">
<t>While the design of the Forwarding Information Base is not a matter
for standardization, as it only has to work correctly, not interoperate
with something else, the design of a FIB for this type of lookup may
differ from approaches used in destination routing. We describe two
possible approaches from the perspective of a proof of concept. These
are a staged lookup and a single FIB.</t>
<section title="Staged Lookup">
<t>A FIB can be designed as a staged lookup. Given that it is unlikely
that any given destination would support very many tenants, a simple
list or small hash may be sufficient; one looks up the destination,
and having found it, validates the flow label used. In such a design,
it is necessary to have the option of "any" flow label in addition to
the set of specified flow labels, as it is legal and correct to
advertise routes that do not have flow labels.</t>
</section>
<section title="PATRICIA">
<t>One approach is a <xref target="PATRICIA"></xref> Tree. This is a
relative of a Trie, but unlike a Trie, need not use every bit in
classification, and does not need the bits used to be contiguous. It
depends on treating the bit string as a set of slices of some size,
potentially of different sizes. Slice width is an implementation
detail; since the algorithm is most easily described using a slice of
a single bit, that will be presumed in this description.</t>
<section title="Virtual Bit String">
<t>It is quite possible to view the fields in a datagram header
incorporated into the classification tuple as a virtual bit string
such as is shown in <xref target="conceptual"></xref>. This bit
string has various regions within it. Some vary and are therefore
useful in a radix tree lookup. Some may be essentially constant -
all global IPv6 addresses at this writing are within 2000::/3, for
example, so while it must be tested to assure a match, incorporating
it into the radix tree may not be very helpful in classification.
Others are ignored; if the destination is a remote /64, we really
don't care what the EID is. In addition, due to variation in prefix
length and other details, the widths of those fields vary among
themselves. The algorithm the FIB implements, therefore, must
efficiently deal with the fact of a discontiguous lookup key.</t>
<figure anchor="conceptual"
title="Treating a traffic class as a virtual bit string">
<artwork align="center"><![CDATA[
+---------------------+----------------------+-----+-----------+
|Destination Prefix |Source Prefix |DSCP | Flow Label|
+------+------+-------+------+-------+-------+-----+-----------+
Common|Varying|Ignored|Common|Varying|Ignored|Varying or ignored
]]></artwork>
</figure>
</section>
<section title="Tree Construction">
<t>The tree is constructed by recursive slice-wise decomposition. At
each stage, the input is a set of classes to be classified. At each
stage, the result is the addition of a lookup node in the tree that
identifies the location of its slice in the virtual bit string
(which might be a bit number), the width of the slice to be
inspected, and an enumerated set of results. Each result is a
similar set of classes, and is analyzed in a similar manner.</t>
<t>The analysis is performed by enumerating which bits that have not
already been considered are best suited to classification. For a
slice of N bits, one wants to select a slide that most evenly
divides the set of classes into 2^N subsets. If one or more bits in
the slice is ignored in some of the classes, those classes must be
included in every subset, as the actual classification of them will
depend on other bits.</t>
<figure anchor="patricia-tree" title="Example PATRICIA Tree">
<artwork align="center"><![CDATA[
Input:{2001:db8::/32, ::/0, *, *}
{2001:db8:1::/48, ::/0, AF41, *}
{2001:db8:1::/48, ::/0, AF42, *}
{2001:db8:1::/48, ::/0, AF43, *}
Common parts: Destination prefix 2001:dba, source prefix, and label
Varying parts: DSCP and the third set of sixteen bits in the
destination prefix
One possible decomposition:
(1) slice = DSCP
enumerated cases:
(a) { {2001:db8::/32, ::/0, *, *}, {2001:db8:1::/48, ::/0, AF41, *} }
(b) { {2001:db8::/32, ::/0, *, *}, {2001:db8:1::/48, ::/0, AF42, *} }
(c) { {2001:db8::/32, ::/0, *, *}, {2001:db8:1::/48, ::/0, AF43, *} }
(2) slice = third sixteen bit field in destination
This divides each enumerated case into those containing 0001 and
"everything else", which would imply 2001:db8::/32
(1) DSCP
--------------------------
(1a) (1b) (1c)
/ \ / \ / \
/32 /48 /32 /48 /32 /48
]]></artwork>
</figure>
</section>
<section title="Tree Lookup">
<t>To look something up in a PATRICIA Tree, one starts at the root
of the tree and performs the indicated comparisons recursively
walking down the tree until one reaches a terminal node. When the
enumerated subset is empty or contains only a single class,
classification stops. Either classification has failed (there was no
matching class, or one has presumably found the indicated class. At
that point, every bit in the virtual bit string must be compared to
the classifier; classification is accepted on a perfect match.</t>
<t>In the example in <xref target="patricia-tree"></xref>, if a
packet {2001:db8:1:2:3:4:5:6, 2001:db8:2:3:4:5:6:7, AF41, 0}
arrives, we start at the root. Since it is an AF41 packet, we deduce
that case (1a) applies, and since the destination has 0001 in the
third sixteen bit field of the destination address, we are comparing
to {2001:db8:1::/48, ::/0, AF41, *}. Since the destination address
is within 2001:db8:1::/48, classification as that succeeds.</t>
</section>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 21:06:13 |