Internet DRAFT - draft-troan-homenet-sadr
draft-troan-homenet-sadr
Homenet working Group O. Troan
Internet-Draft Cisco Systems
Intended status: Informational L. Colitti
Expires: March 08, 2014 Google
September 04, 2013
IPv6 Multihoming with Source Address Dependent Routing (SADR)
draft-troan-homenet-sadr-01
Abstract
A multihomed network using provider aggregatable addresses must send
the packet out the right path to avoid violating the provider's
ingress filtering. This memo suggests a mechanism called Source
Address Dependent Routing to solve that problem.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 08, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
Troan & Colitti Expires March 08, 2014 [Page 1]
Internet-Draft SADR September 2013
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
4. Using SADR for multihoming . . . . . . . . . . . . . . . . . . 3
5. A Conceptual Forwarding Algorithm . . . . . . . . . . . . . . 3
6. Routing considerations . . . . . . . . . . . . . . . . . . . . 4
6.1. Routing Protocol extensions . . . . . . . . . . . . . . . 5
6.2. Simplified SADR in home networks . . . . . . . . . . . . . 5
7. Interaction between routers and hosts . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . 6
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
11.1. Normative References . . . . . . . . . . . . . . . . . . 6
11.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
IPv6 is designed to support multiple addresses on an interface, and
the intention was to use this feature to support multihoming with
provider aggregatable addresses.
One difficulty of multihoming with provider-aggregatable space is
that providers typically employ BCP38 [RFC2827] filtering. If a
network sends traffic to its upstream provider using a source address
that was not assigned by that provider, the traffic will be dropped.
Thus, if a network is multihomed to multiple providers, it must
ensure that traffic is sent out the correct exit for the packet's
source address.
As long as upstream traffic is sent to the correct provider, hosts
inside the network are free to use source addresses assigned by any
of the network's upstream providers. In such a scenario, each host
has multiple addresses, one or more from each provider the network is
connected to. The network ensures that packets are sent to the
correct upstream by forwarding packets based on the destination
address and the source address. This we call source address
dependent routing (SADR). This memo shows how SADR can be used to
implement multihoming.
2. Conventions
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 RFC 2119 [RFC2119].
3. Terminology
Service Provider An entity that provides the network with
external connectivity, e.g. to the Internet.
Troan & Colitti Expires March 08, 2014 [Page 2]
Internet-Draft SADR September 2013
WAN Interface An interface connected to a Service
Providers. WAN interfaces may either be
physical links or virtual interfaces such as
tunnels. WAN interfaces are used to send
ingress traffic from the Internet to the End-
User, and egress traffic from the End-User
network to the Internet. Ingress traffic may
be received on any active interface at any
time. Egress traffic follows a set of rules
within the router in order to choose the
proper WAN interface.
Border Router A border router has one or more external
interfaces connecting it to one or more
Service Providers. The border router
receives one or more delegated prefixes, each
associated with one or more WAN interfaces.
External Route A route that is learned from a Service
Provider. Each External Route has an
Acceptable Source Prefix which determines
which source addresses may use that route.
Internal Router A router that is not a Border Router.
Internal Route A route to a destination inside the network.
4. Using SADR for multihoming
SADR is similar to policy based routing. This memo proposes a simple
extension to the destination based longest match algorithm to
constrain it to source address.
In order to support ingress filtering by upstream networks, the
network MUST treat external routes specially. Ingress filtering MAY
also be used internally, by installing (S,D) routes for locally
assigned prefixes, where the source prefix would be the aggregatable
prefix. If no ingress filtering is performed inside the network,
then normal non-source constrained forwarding is used.
5. A Conceptual Forwarding Algorithm
This section describes a conceptual forwarding algorithm. An
implementation might implement this differently, e.g. with multiple
tables, as long as the external behaviour is as described.
First a longest match lookup is done in the routing table for the
destination address, then for the resulting set a longest matching
lookup is done for the source address.
Troan & Colitti Expires March 08, 2014 [Page 3]
Internet-Draft SADR September 2013
In a destination based routing table, an entry in the routing table
can be shown as "D -> NH". That is, to get to a destination D, use
next-hop NH. For a source constrained routing table we propose the
following notation. (Source Network, Destination network) -> Next-
hop. (S, D) -> NH. A route that is not source constrained can be
represented as (*, D) -> NH.
For convenience this document shows the routing table as a single
destination based routing table, with source address constrained
paths. This does not preclude other implementations, as long as the
external behaviour is the same.
A router forwarding a packet does a longest match look-up on the
destination address. If this is a (*, D) entry, it forwards the
packet out the best next-hop as before (doing equal cost multi path
load balancing etc). If the look-up results in a (S, D) entry, the
look-up function does a longest match on the source address among the
set of (S, D) paths. If there is a match the packet is forwarded out
the given next-hop, if not an ICMP destination address unreachable
message, code 5 is returned [RFC4443]. A routing entry may have both
(S, D) paths and (*, D) paths. The longest match wins.
The following example show the routing table of a network connected
to two ISPs, ISP A and ISP B. Both ISPs offer default connectivity
and ISP B also offers a more specific route to a walled garden
service.
(2001:db8::/56, ::/0) -> ISP_A # Default route to ISP A
(2001:db9::/56, ::/0) -> ISP_B # Default route to ISP B
(*, 2001:db8::/64) -> R1 # Internal network, prefix from A
(*, 2001:db8:1::/64) -> R2 # Internal network, prefix from A
(*, 2001:db9::/64) -> R1 # Internal network, prefix from B
(*, 2001:db9:1::/64) -> R2 # Internal network, prefix from B
(*, fd00::/64) -> R3 # Internal network ULA
(2001:db9::/56, 2001:420::/32) -> ISP_B # Walled garden route from ISP B
Figure 1: Example Routing Table
A packet with the SA, DA of 2001:db8::1, 2001:dead:beef::1 would be
forwarded to ISP A, likewise a packet with SA, DA 2001:db9::1,
2001:dead:beef::1 would be forward to ISP B. An packet with SA,DA
2001:db8::1, 2001:db9::1 would be forwarded using normal destination
based routing. A packet to the walled garden SA,DA 2001:db9::1,
2001:420::1 would be sent to ISP B. A packet with SA,DA
2001:db8::1,2001:420::1 would be dropped with an ICMP unreachable
message being sent back.
6. Routing considerations
Now that we have described the function of the source constrained
routing table. How does the table get populated?
Troan & Colitti Expires March 08, 2014 [Page 4]
Internet-Draft SADR September 2013
6.1. Routing Protocol extensions
The generic answer is that the routing protocol used in the network
has to be extended to support (S, D) routes. Specifically, the
routing protocol should distribute, for each External Route, the
Acceptable Source Prefix(es) for that route. This may be done, for
example, using [I-D.baker-ipv6-ospf-dst-src-routing] or [I-D.baker-
ipv6-isis-dst-src-routing]. In the case of OSPFv3, for example,
external routes are advertised in an AS-External-prefix LSA,
[RFC5340]
6.2. Simplified SADR in home networks
In a home network using a dynamic prefix assignment mechanism such as
[I-D.arkko-homenet-prefix-assignment] it may be known that a
particular Border Router is announcing both an External Route and an
Aggregated Prefix (for example, if the same router ID is announcing
both). In this case, interior routers may assume that the Acceptable
Source Prefix of the External Route announced by that Border Router
is in fact the Aggregated Prefix announced by that Border Router.
An internal router when receiving a AS-External LSA route will
install that in the routing table as normal. When the internal
router receives a aggregated prefix as part of prefix assignment, the
router shall add source constrained entries to all the AS-External
routes received from the same border router (matching router-ID).
Routes that are not associated with a border router or are not AS-
External do not have source constrained paths.
The routing protocol requirements for simplified SADR in the home
network are:
1. Routing protocol must flood all information to all routers in the
home network. (Single area).
2. Prefix assignment and unicast routing must be done in the same
protocol.
3. A router must be uniquely identified (router-id) so that router
advertisements and prefix assignment can be tied together
7. Interaction between routers and hosts
Troan & Colitti Expires March 08, 2014 [Page 5]
Internet-Draft SADR September 2013
Generally, hosts need not be aware that SADR is in use in the
network. Hosts simply choose source addresses and the network will
deliver the traffic to the appropriate upstream. One exception is
when an Acceptable Source Prefix becomes invalid (e.g., if the Border
Router which announced it crashes, or its WAN link goes down). In
this case, current hosts will continue to use source addresses in
that Acceptable Source Prefix without knowing that all communication
outside the network is likely to fail. In this case, interior
routers can improve responsiveness by deprecating the addresses in
that Acceptable Source Prefix.
ICMP [RFC4443] includes a Destination unreachable code 5 - "Source
address failed ingress/egress policy". Hosts MUST adhered to this
message, and based on the unreachable message try another source
address.
8. IANA Considerations
This specification does not require any IANA actions.
9. Security Considerations
10. Acknowledgements
The authors would like to thank Jari Arkko and Andrew Yourtchenko for
their ideas and review.
11. References
11.1. Normative References
[I-D.arkko-homenet-prefix-assignment]
Arkko, J., Lindem, A., and B. Paterson, "Prefix Assignment
in a Home Network", draft-arkko-homenet-prefix-
assignment-03 (work in progress), October 2012.
[I-D.ietf-ospf-ospfv3-autoconfig]
Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration",
draft-ietf-ospf-ospfv3-autoconfig-00 (work in progress),
October 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
Troan & Colitti Expires March 08, 2014 [Page 6]
Internet-Draft SADR September 2013
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012.
11.2. Informative References
[I-D.baker-ipv6-isis-dst-src-routing]
Baker, F., "IPv6 Source/Destination Routing using IS-IS",
draft-baker-ipv6-isis-dst-src-routing-00 (work in
progress), February 2013.
[I-D.baker-ipv6-ospf-dst-src-routing]
Baker, F., "IPv6 Source/Destination Routing using OSPFv3",
draft-baker-ipv6-ospf-dst-src-routing-00 (work in
progress), February 2013.
[I-D.ietf-homenet-arch]
Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil,
"Home Networking Architecture for IPv6", draft-ietf-
homenet-arch-06 (work in progress), October 2012.
Authors' Addresses
Ole Troan
Cisco Systems
Philip Pedersens vei 1
Lysaker 1366
Norway
Email: ot@cisco.com
Lorenzo Colitti
Google
Roppongi Hills Mori Tower PO box 22
Minato, Tokyo 106-6126
Japan
Email: lorenzo@google.com
Troan & Colitti Expires March 08, 2014 [Page 7]
