< draft-bonica-v6-multihome-00.txt   draft-bonica-v6-multihome-01.txt >
INTAREA R. Bonica, Ed. INTAREA R. Bonica, Ed.
Internet-Draft Juniper Networks Internet-Draft Juniper Networks
Updates: 6296 (if approved) F. Baker Updates: 6296 (if approved) F. Baker
Intended status: Experimental Cisco Systems Intended status: Experimental Cisco Systems
Expires: April 6, 2012 M. Wasserman Expires: June 11, 2012 M. Wasserman
Painless Security Painless Security
October 4, 2011 G. Miller
Verizon
December 9, 2011
Multihoming with IPv6-to-IPv6 Network Prefix Translation (NPTv6) Multihoming with IPv6-to-IPv6 Network Prefix Translation (NPTv6)
draft-bonica-v6-multihome-00 draft-bonica-v6-multihome-01
Abstract Abstract
This memo describes an architecture for sites that are homed to This memo describes an architecture for sites that are homed to
multiple upstream providers. The architecture described herein uses multiple upstream providers. The architecture described herein uses
IPv6-to-IPv6 Network Prefix Translation (NPTv6) to achieve IPv6-to-IPv6 Network Prefix Translation (NPTv6) to achieve
redundancy, transport-layer survivability, load sharing and address redundancy, transport-layer survivability, load sharing and address
independence. independence.
This memo updates Section 2.4 of RFC 6296. This memo updates Section 2.4 of RFC 6296.
skipping to change at page 1, line 39 skipping to change at page 1, line 41
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 April 6, 2012. This Internet-Draft will expire on June 11, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. NPTv6 Deployment . . . . . . . . . . . . . . . . . . . . . . . 4 2. NPTv6 Deployment . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Topology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Addressing . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1. Upstream Provider Addressing . . . . . . . . . . . . . 5 2.2.1. Upstream Provider Addressing . . . . . . . . . . . . . 6
2.2.2. Site Addressing . . . . . . . . . . . . . . . . . . . 5 2.2.2. Site Addressing . . . . . . . . . . . . . . . . . . . 6
2.3. Address Translation . . . . . . . . . . . . . . . . . . . 6 2.3. Address Translation . . . . . . . . . . . . . . . . . . . 7
2.4. Domain Name System (DNS) . . . . . . . . . . . . . . . . . 7 2.4. Domain Name System (DNS) . . . . . . . . . . . . . . . . . 8
2.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.5. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.6. Failure Detection and Recovery . . . . . . . . . . . . . . 8 2.6. Failure Detection and Recovery . . . . . . . . . . . . . . 9
2.7. Load Balancing . . . . . . . . . . . . . . . . . . . . . . 9 2.7. Load Balancing . . . . . . . . . . . . . . . . . . . . . . 10
3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
[RFC3582] establishes the following goals for IPv6 site multihoming: [RFC3582] establishes the following goals for IPv6 site multihoming:
Redundancy - A site's ability to remain connected to the Redundancy - A site's ability to remain connected to the
Internet, even when connectivity through one or more of its Internet, even when connectivity through one or more of its
upstream providers fails. upstream providers fails.
Transport-Layer Survivability - A site's ability to maintain Transport-Layer Survivability - A site's ability to maintain
skipping to change at page 3, line 36 skipping to change at page 3, line 36
[RFC6296] explains how a site can achieve address independence using [RFC6296] explains how a site can achieve address independence using
IPv6-to-IPv6 Network Prefix Translation (NPTv6). In order to achieve IPv6-to-IPv6 Network Prefix Translation (NPTv6). In order to achieve
address independence, the site assigns an inside address to each of address independence, the site assigns an inside address to each of
its resources (e.g., hosts). Nodes outside of the site identify its resources (e.g., hosts). Nodes outside of the site identify
those same resources using a corresponding Provider Allocated (PA) those same resources using a corresponding Provider Allocated (PA)
address. address.
The site resolves this addressing dichotomy by deploying an NPTv6 The site resolves this addressing dichotomy by deploying an NPTv6
translator between itself and its upstream provider. The NPTv6 translator between itself and its upstream provider. The NPTv6
device maintains a static, one-to-one mapping between each inside translator maintains a static, one-to-one mapping between each inside
address and its corresponding PA address. That mapping persists address and its corresponding PA address. That mapping persists
across flows and over time. across flows and over time.
If the site disconnects from one upstream provider and connects to If the site disconnects from one upstream provider and connects to
another, it may lose its PA assignment. However, the site will not another, it may lose its PA assignment. However, the site will not
need to renumber its resources. It will only need to reconfigure the need to renumber its resources. It will only need to reconfigure the
mapping rules on its local NPTv6 device. mapping rules on its local NPTv6 translator.
Section 2.4 of [RFC6296] describes an NPTv6 architecture for sites Section 2.4 of [RFC6296] describes an NPTv6 architecture for sites
that are homed to multiple upstream providers. While that that are homed to multiple upstream providers. While that
architecture fulfils many of the goals identified by [RFC3582], it architecture fulfils many of the goals identified by [RFC3582], it
does not achieve transport-layer survivability. This memo describes does not achieve transport-layer survivability. Transport-layer
an alternative architecture for multihomed sites that require survivability is not achieved because in this architecture, a PA
transport-layer survivability. It updates Section 2.4 of [RFC6296]. address is useable only when the multi-homed site is directly
connected to the allocating provider.
This memo describes an alternative architecture for multihomed sites
that require transport-layer survivability. It updates Section 2.4
of [RFC6296]. In this architecture, PA addresses remain usable, even
when the multihomed site loses its direct connection to the
allocating provider.
The architecture described in this document can be deployed in sites
that are served by two or more upstream providers. For the purpose
of example, this document demonstrates how the architecture can be
deployed in a site that is served by two upstream providers.
1.1. Terminology
The following terms are used in this document:
inbound packet - A packet that is destined for the multi-homed
site
outbound packet - A packet that originates at the multi-homed site
and is destined for a point outside of the multi-homed site
NPTv6 inside interface - An interface that connects an NPTv6
translator to the site
NPTv6 outside interface- An interface that connects an NPTv6
translator to an upstream provider
2. NPTv6 Deployment 2. NPTv6 Deployment
This section demonstrates how NPTv6 can be deployed in order to This section demonstrates how NPTv6 can be deployed in order to
achieve the goals of [RFC3582]. achieve the goals of [RFC3582].
2.1. Topology 2.1. Topology
Upstream Upstream Upstream Upstream
Provider #1 Provider #2 Provider #1 Provider #2
skipping to change at page 6, line 4 skipping to change at page 6, line 48
CNB #1 and CNB #2 are both /60's, the SAB is a /59. CNB #1 and CNB #2 are both /60's, the SAB is a /59.
The site divides its SAB into smaller blocks, with each block being The site divides its SAB into smaller blocks, with each block being
exactly as large as one CNB. It also associates each of the exactly as large as one CNB. It also associates each of the
resulting sub-blocks with one of its CNBs. In this example, the site resulting sub-blocks with one of its CNBs. In this example, the site
divides the SAB into a lower half and an upper half. It associates divides the SAB into a lower half and an upper half. It associates
the lower half of the SAB with CNB #1 and the upper half of the SAB the lower half of the SAB with CNB #1 and the upper half of the SAB
with CNB #2. with CNB #2.
Finally, the site assigns one SAB address to each interface that is Finally, the site assigns one SAB address to each interface that is
connected to the Internal Network, including the inside interfaces connected to the Internal Network, including the inside interfaces of
interfaces of the two NPTv6 translators. The site also assigns a SAB the two NPTv6 translators. The site also assigns a SAB address to
address to the loopback interface of each NPTv6 translator. During the loopback interface of each NPTv6 translator. During periods of
periods of normal operation, interfaces that are assigned addresses normal operation, interfaces that are assigned addresses from the
from the lower half of the SAB receive traffic through Upstream lower half of the SAB receive traffic through Upstream Provider #1.
Provider #1. Likewise, interfaces that are assigned addresses from
the upper half of the SAB receive traffic through Upstream Provider Likewise, interfaces that are assigned addresses from the upper half
#2. of the SAB receive traffic through Upstream Provider #2.
Selected interfaces, because they receive a great deal of traffic, Selected interfaces, because they receive a great deal of traffic,
must receive traffic through both upstream providers simultaneously. must receive traffic through both upstream providers simultaneously.
Furthermore, those interfaces must control the portion of traffic Furthermore, those interfaces must control the portion of traffic
arriving through each upstream provider. The site assigns multiple arriving through each upstream provider. The site assigns multiple
addresses to those interfaces, some from the lower half and others addresses to those interfaces, some from the lower half and others
from the upper half of the SAB. For any interface, the ratio of from the upper half of the SAB. For any interface, the ratio of
upper half to lower half assignments roughly controls the portion of upper half to lower half assignments roughly controls the portion of
traffic arriving through each upstream provider. See Section 2.3 and traffic arriving through each upstream provider. See Section 2.3,
Section 2.5 for details. Section 2.5 and Section 2.7 for details.
2.3. Address Translation 2.3. Address Translation
Both NPTv6 translators are configured with the following rules: Both NPTv6 translators are configured with the following rules:
For outbound packets, if the first 60 bits of the source For outbound packets, if the first 60 bits of the source
address identify the lower half of the SAB, overwrite those 60 address identify the lower half of the SAB, overwrite those 60
bits with the 60 bits that identify CNB #1 bits with the 60 bits that identify CNB #1
For outbound packets, if the first 60 bits of the source For outbound packets, if the first 60 bits of the source
skipping to change at page 7, line 34 skipping to change at page 8, line 30
[RFC4271] to distribute customer and peer reachability information. [RFC4271] to distribute customer and peer reachability information.
PE #1 acquires a route to CNB #1 with NEXT-HOP equal to the outside PE #1 acquires a route to CNB #1 with NEXT-HOP equal to the outside
interface of NPTv6 #1. PE #1 can either learn this route from a interface of NPTv6 #1. PE #1 can either learn this route from a
single-hop eBGP session with NPTv6 #1, or acquire it through static single-hop eBGP session with NPTv6 #1, or acquire it through static
configuration. In either case, PE #1 overwrites the NEXT-HOP of this configuration. In either case, PE #1 overwrites the NEXT-HOP of this
route with its own loopback address and distributes the route route with its own loopback address and distributes the route
throughout Upstream Provider #1 using iBGP. The LOCAL PREF for this throughout Upstream Provider #1 using iBGP. The LOCAL PREF for this
route is set high, so that the route will be preferred to alternative route is set high, so that the route will be preferred to alternative
routes to CNB #1. Upstream Provider #1 does not distribute this routes to CNB #1. Upstream Provider #1 does not distribute this
route to CNB #1 outside of its own borders. route to CNB #1 outside of its own borders because it is part of the
larger aggregate PAB #1, which is itself advertised.
NPTv6 #1 acquires a default route with NEXT-HOP equal to the directly NPTv6 #1 acquires a default route with NEXT-HOP equal to the directly
connected interface on PE #1. NPTv6 #1 can either learn this route connected interface on PE #1. NPTv6 #1 can either learn this route
from a single-hop eBGP session with PE #1, or acquire it through from a single-hop eBGP session with PE #1, or acquire it through
static configuration. static configuration.
Similarly, Backup PE #1 acquires a route to CNB #1 with NEXT-HOP Similarly, Backup PE #1 acquires a route to CNB #1 with NEXT-HOP
equal to the outside interface of NPTv6 #2. Backup PE #1 can either equal to the outside interface of NPTv6 #2. Backup PE #1 can either
learn this route from a multi-hop eBGP session with NPTv6 #2, or learn this route from a multi-hop eBGP session with NPTv6 #2, or
acquire it through static configuration. In either case, Backup PE acquire it through static configuration. In either case, Backup PE
skipping to change at page 10, line 48 skipping to change at page 11, line 43
intrusion detection systems may be impacted. Also many users may intrusion detection systems may be impacted. Also many users may
confuse NPTv6 translation with a NAT. Two limitations of NAT are confuse NPTv6 translation with a NAT. Two limitations of NAT are
that a) it does not support incoming connections without special that a) it does not support incoming connections without special
configuration and b) it requires symmetric routing across the NAT configuration and b) it requires symmetric routing across the NAT
device. Many users understood these limitations to be security device. Many users understood these limitations to be security
features. Because NPTv6 has neither of these limitations, it also features. Because NPTv6 has neither of these limitations, it also
offers neither of these features. offers neither of these features.
6. Acknowledgements 6. Acknowledgements
Thanks to John Scudder and Yakov Rekhter for their helpful comments, Thanks to John Scudder, Yakov Rekhter and Warren Kumari for their
encouragement and support. Special thanks to Johann Jonsson, James helpful comments, encouragement and support. Special thanks to
Piper, Ravinder Wali, Ashte Collins, Inga Rollins and an anonymous Johann Jonsson, James Piper, Ravinder Wali, Ashte Collins, Inga
donor, without whom this memo would not have been written. Rollins and an anonymous donor, without whom this memo would not have
been written.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
skipping to change at page 11, line 49 skipping to change at page 12, line 47
[I-D.ietf-idr-best-external] [I-D.ietf-idr-best-external]
Marques, P., Fernando, R., Chen, E., Mohapatra, P., and H. Marques, P., Fernando, R., Chen, E., Mohapatra, P., and H.
Gredler, "Advertisement of the best external route in Gredler, "Advertisement of the best external route in
BGP", draft-ietf-idr-best-external-04 (work in progress), BGP", draft-ietf-idr-best-external-04 (work in progress),
April 2011. April 2011.
[I-D.ietf-lisp] [I-D.ietf-lisp]
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)", "Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-15 (work in progress), July 2011. draft-ietf-lisp-17 (work in progress), December 2011.
[I-D.rja-ilnp-intro] [I-D.rja-ilnp-intro]
Atkinson, R., "ILNP Concept of Operations", Atkinson, R., "ILNP Concept of Operations",
draft-rja-ilnp-intro-11 (work in progress), July 2011. draft-rja-ilnp-intro-11 (work in progress), July 2011.
Authors' Addresses Authors' Addresses
Ron Bonica (editor) Ron Bonica (editor)
Juniper Networks Juniper Networks
Sterling, Virginia 20164 Sterling, Virginia 20164
skipping to change at page 12, line 28 skipping to change at page 13, line 24
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
Margaret Wasserman Margaret Wasserman
Painless Security Painless Security
356 Abbott Street 356 Abbott Street
North Andover, MA 01845 North Andover, Massachusetts 01845
USA USA
Phone: +1 781 405 7464 Phone: +1 781 405 7464
Email: mrw@painless-security.com Email: mrw@painless-security.com
URI: http://www.painless-security.com URI: http://www.painless-security.com
Gregory J. Miller
Verizon
Ashburn, Virginia 20147
USA
Email: gregory.j.miller@verizon.com
 End of changes. 16 change blocks. 
43 lines changed or deleted 76 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/