< draft-baker-ipv6-isis-dst-src-routing-01.txt   draft-baker-ipv6-isis-dst-src-routing-02.txt >
Network Working Group F.J. Baker Network Working Group F.J. Baker
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track August 28, 2013 Intended status: Standards Track D. Lamparter
Expires: March 01, 2014 Expires: April 23, 2015 NetDEF
October 20, 2014
IPv6 Source/Destination Routing using IS-IS IPv6 Source/Destination Routing using IS-IS
draft-baker-ipv6-isis-dst-src-routing-01 draft-baker-ipv6-isis-dst-src-routing-02
Abstract Abstract
This note describes the changes necessary for IS-IS to route IPv6 This note describes the changes necessary for IS-IS to route IPv6
traffic from a specified prefix to a specified prefix. traffic from a specified prefix to a specified prefix.
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.
skipping to change at page 1, line 31 skipping to change at page 1, line 32
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 March 01, 2014. This Internet-Draft will expire on April 23, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. Theory of Routing . . . . . . . . . . . . . . . . . . . . . . 2 2. Theory of Routing . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Dealing with ambiguity . . . . . . . . . . . . . . . . . 3 2.2. Dealing with ambiguity . . . . . . . . . . . . . . . . . 4
2.3. Interactions with other constraints . . . . . . . . . . . 4 2.3. Interactions with other constraints . . . . . . . . . . . 4
2.4. Multi-topology Routing . . . . . . . . . . . . . . . . . 5
3. Extensions necessary for IPv6 Source/Destination Routing in 3. Extensions necessary for IPv6 Source/Destination Routing in
IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Source Prefix sub-TLV . . . . . . . . . . . . . . . . . . 5 3.1. Source Prefix sub-TLV . . . . . . . . . . . . . . . . . . 5
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 6 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
This specification builds on IS-IS for IPv6 [RFC5308] and its This specification builds on IS-IS for IPv6 [RFC5308] and the
extensible TLV. This note defines the sub-TLV for an IPv6 [RFC2460] critical extension TLV in [critical-subtlvs]. This note defines the
Source Prefix, to define routes from a source prefix to a destination sub-TLV for an IPv6 [RFC2460] Source Prefix, to define routes from a
prefix. source prefix to a destination prefix.
This implies not simply routing "to a destination", but routing "to This implements the Destination/Source Routing mechanism described in
that destination AND from a specified source". It may be combined [dst-src-routing]. This implies not simply routing "to a
with other qualifying attributes, such as "traffic going to that destination", but routing "to that destination AND from a specified
destination AND using a specified flow label AND from a specified source". It may be combined with other qualifying attributes, such
source prefix". The obvious application is egress routing, as as "traffic going to that destination AND using a specified flow
required for a multihomed entity with a provider-allocated prefix label AND from a specified source prefix". The obvious application
from each of several upstream networks. Traffic within the network is egress routing, as required for a multihomed entity with a
could be source/destination routed as well, or could be implicitly or provider-allocated prefix from each of several upstream networks.
explicitly routed from "any prefix", ::/0. Other use cases are Traffic within the network could be source/destination routed as
described in [I-D.baker-rtgwg-src-dst-routing-use-cases]. If a FIB well, or could be implicitly or explicitly routed from "any prefix",
contains a route to a given destination from one or more prefixes not ::/0. Other use cases are described in
including ::/0, and a given packet destined there that has a source [I-D.baker-rtgwg-src-dst-routing-use-cases]. If a FIB contains a
address that is in none of them, the packet in effect has no route, route to a given destination from one or more prefixes not including
just as if the destination itself were not in the route table. ::/0, and a given packet destined there that has a source address
that is in none of them, the packet in effect has no route, just as
if the destination itself were not in the route table.
1.1. Requirements Language 1.1. Requirements Language
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].
2. Theory of Routing 2. Theory of Routing
Both IS-IS and OSPF perform their calculations by building a lattice Both IS-IS and OSPF perform their calculations by building a lattice
of routers and links from the router performing the calculation to of routers and links from the router performing the calculation to
each router, and then use routes (sequences in the lattice) to get to each router, and then use routes (sequences in the lattice) to get to
destinations that those routes advertise connectivity to. Following destinations that those routes advertise connectivity to. Following
the SPF algorithm, calculation starts by selecting a starting point the SPF algorithm, calculation starts by selecting a starting point
(typically the router doing the calculation), and successively adding (typically the router doing the calculation), and successively adding
{link, router} pairs until one has calculated a route to every router {link, router} pairs until one has calculated a route to every router
in the network. As each router is added, including the original in the network. As each router is added, including the original
router, destinations that it is directly connected to are turned into 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 routes in the route table: "to get to 2001:db8::/32, route traffic to
skipping to change at page 3, line 28 skipping to change at page 3, line 34
In this context, the route is qualified by a source prefix; It is In this context, the route is qualified by a source prefix; It is
installed into the FIB with the destination prefix, and the FIB installed into the FIB with the destination prefix, and the FIB
applies the route if and only if the IPv6 source address also matches applies the route if and only if the IPv6 source address also matches
the advertised prefix. Of course, there may be multiple LSPs in the the advertised prefix. Of course, there may be multiple LSPs in the
RIB with the same destination and differing source prefixes; these RIB with the same destination and differing source prefixes; these
may also have the same or differing next hop lists. The intended may also have the same or differing next hop lists. The intended
forwarding action is to forward matching traffic to one of the next forwarding action is to forward matching traffic to one of the next
hop routers associated with this destination and source prefix, or to hop routers associated with this destination and source prefix, or to
discard non-matching traffic as "destination unreachable". discard non-matching traffic as "destination unreachable".
LSAs that lack a source prefix sub-TLV match any source address TLVs that lack a source prefix sub-TLV match any source address
(i.e., the source prefix TLV defaults to ::/0), by definition. (i.e., the source prefix TLV defaults to ::/0), by definition.
When resolving Destination/Source Reachabilities, the SPF calculation
results used MUST reflect a calculation performed including only
routers that advertise support for the critical Source Prefix TLV
defined in section 3. The mechanism for signaling this is described
in [critical-subtlvs]. Routers that support this extension MUST
advertise support as described there.
2.1. Notation 2.1. Notation
For the purposes of this document, a route from the prefix A to the For the purposes of this document, a route from the prefix A to the
prefix B (in other words, whose source prefix is A and whose prefix B (in other words, whose source prefix is A and whose
destination prefix is B) is expressed as A->B. A packet with the destination prefix is B) is expressed as A->B. A packet with the
source address A and the destination address B is similarly described source address A and the destination address B is similarly described
as A->B. as A->B.
2.2. Dealing with ambiguity 2.2. Dealing with ambiguity
skipping to change at page 4, line 39 skipping to change at page 5, line 4
The FIB algorithm, in this example, must therefore match the second The FIB algorithm, in this example, must therefore match the second
route, even though it is not the longest destination match, because route, even though it is not the longest destination match, because
it also matches the source address. it also matches the source address.
2.3. Interactions with other constraints 2.3. Interactions with other constraints
In the event that there are other constraints on routing, such as In the event that there are other constraints on routing, such as
proposed in [I-D.baker-ipv6-isis-dst-flowlabel-routing], the effect proposed in [I-D.baker-ipv6-isis-dst-flowlabel-routing], the effect
is a logical AND. The FIB lookup must yield the route with the is a logical AND. The FIB lookup must yield the route with the
longest matching destination prefix that also matches each of the longest matching destination prefix that also matches each of the
constraints. constraints. The general mechanics for this are described in
[extra-qualifiers].
2.4. Multi-topology Routing
While not mandatory, IS-IS is often implemented as Multi Topology
Routing [RFC5120] with IPv4 or other protocols in the same or
different topologies. The TLV structure in [critical-subtlvs] is
topology-agnostic in that it always includes the topology ID, which
may be zero to indicate the default topology.
The mechanism in this document and its Sub-TLV are applicable to any
topology that carries routing information used for IPv6 Unicast
routing. Destination/Source reachability information SHOULD NOT be
placed differently from "plain" destination reachabilities.
A system MUST NOT originate Destination/Source Reachabilities in a
topology that is exclusively configured for multicast RPF operation.
If a topology is shared between unicast lookups and multicast reverse
path lookups, reachabilities with a source prefix other than ::/0
MUST be ignored for multicast reverse path lookups.
The statements in the previous two paragraphs currently result in
applicability of Destination/Source routes as:
MT-ID designated usage applicability
0 default topology yes
1 IPv4 management no
2 IPv6 default yes
3 IPv4 multicast no
4 IPv6 multicast no
5 IPv6 management yes
Applicability of Destination/Source IPv6 Reachabilities
3. Extensions necessary for IPv6 Source/Destination Routing in IS-IS 3. Extensions necessary for IPv6 Source/Destination Routing in IS-IS
Section 2 of [RFC5308] defines the "IPv6 Reachability TLV", and Section 2 of [RFC5308] defines the "IPv6 Reachability TLV", and
carries in it destination prefix advertisements. It has the carries in it destination prefix advertisements. It has the
capability of extension, using sub-TLVs. capability of extension, using sub-TLVs.
We define the Source Prefix Sub-TLV as in Section 3.1. As noted in We define the Source Prefix Sub-TLV as in Section 3.1. As noted in
Section 2, any IPv6 Reachability TLV that does not specify a source Section 2, any IPv6 Reachability TLV that does not specify a source
prefix is understood to as specifying ::/0 as the source prefix. prefix is understood to as specifying ::/0 (any IPv6 address) as the
source prefix.
3.1. Source Prefix sub-TLV 3.1. Source Prefix sub-TLV
The following Sub-TLV is defined for the critical part of TLV TBD2
defined in [critical-subtlvs]:
0 1 2 3 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 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 |Prefix Length | Prefix | Type | Length |Prefix Length | Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Prefix Sub-TLV Source Prefix Sub-TLV
Source Prefix Type: assigned by IANA Source Prefix Type: assigned by IANA
TLV Length: Length of the sub-TLV in octets TLV Length: Length of the sub-TLV in octets
Prefix Length: Length of the prefix in bits Prefix Length: Length of the prefix in bits
Prefix: (source prefix length+7)/8 octets of prefix Prefix: (source prefix length+7)/8 octets of prefix
4. IANA Considerations 4. IANA Considerations
The source prefix type mentioned in Section 3 must be defined. The "Sub-TLVs for TLVs TBD1 (critical) and TBD2 (critical)" registry
defined in [critical-subtlvs] is extended by the following element:
Source Prefix Type: assigned by IANA
Description: IPv6 Source Prefix
Applicable to TLV TBD1 (IPv4): No
Applicable to TLV TBD2 (IPv6): Yes
5. Security Considerations 5. Security Considerations
While source/destination routing could be used as part of a security There are no security considerations specific to this document.
solution, it is not really intended for the purpose. The approach However, the considerations from [dst-src-routing] and
limits routing, in the sense that it routes traffic to an appropriate [critical-subtlvs] are particularly relevant to this document.
egress, or gives a way to prevent communication between systems not
included in a source/destination route, and in that sense could be
considered similar to an access list that is managed by and scales
with routing.
6. Acknowledgements 6. Acknowledgements
7. References 7. References
7.1. Normative References 7.1. Normative References
[ISO.10589.1992] [IS-IS] ISO/IEC, "Intermediate System to Intermediate System
International Organization for Standardization, Intra-Domain Routing Exchange Protocol for use in
"Intermediate system to intermediate system intra-domain- Conjunction with the Protocol for Providing the
routing routine information exchange protocol for use in Connectionless-mode Network Service (ISO 8473)", ISO/IEC
conjunction with the protocol for providing the 10589:2002, Second Edition, 2002.
connectionless-mode Network Service (ISO 8473)", ISO
Standard 10589, 1992.
[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, March 1997.
[RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version
6 (IPv6) Specification", RFC 2460, December 1998. 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120, February 2008.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October
2008. 2008.
[critical-subtlvs]
Lamparter, D., "IS-IS Reachability with critical Sub-
TLVs", draft-lamparter-isis-reachability-critical-
subtlvs-00 (work in progress), October 2014.
[dst-src-routing]
Lamparter, D., "Destination/Source Routing", draft-
lamparter-rtgwg-dst-src-routing-00 (work in progress),
October 2014.
[extra-qualifiers]
Lamparter, D., "Considerations and Registry for extending
IP route lookup", draft-lamparter-rtgwg-routing-
discriminators-00 (work in progress), October 2014.
7.2. Informative References 7.2. Informative References
[I-D.baker-ipv6-isis-dst-flowlabel-routing] [I-D.baker-ipv6-isis-dst-flowlabel-routing]
Baker, F., "Using IS-IS with Role-Based Access Control", Baker, F., "Using IS-IS with Token-based Access Control",
draft-baker-ipv6-isis-dst-flowlabel-routing-00 (work in draft-baker-ipv6-isis-dst-flowlabel-routing-01 (work in
progress), February 2013. progress), August 2013.
[I-D.baker-rtgwg-src-dst-routing-use-cases] [I-D.baker-rtgwg-src-dst-routing-use-cases]
Baker, F., "Requirements and Use Cases for Source/ Baker, F., "Requirements and Use Cases for Source/
Destination Routing", draft-baker-rtgwg-src-dst-routing- Destination Routing", draft-baker-rtgwg-src-dst-routing-
use-cases-00 (work in progress), August 2013. use-cases-00 (work in progress), August 2013.
Appendix A. Change Log Appendix A. Change Log
Initial Version: February 2013 Initial Version: February 2013
updated Version: August 2013 updated Version: August 2013
Author's Address Added MTR: August 2014
Split into 4 drafts: October 2014
Authors' Addresses
Fred Baker Fred Baker
Cisco Systems Cisco Systems
Santa Barbara, California 93117 Santa Barbara, California 93117
USA USA
Email: fred@cisco.com Email: fred@cisco.com
David Lamparter
NetDEF
Leipzig 04103
Germany
Email: david@opensourcerouting.org
 End of changes. 27 change blocks. 
58 lines changed or deleted 130 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/