< draft-ietf-rtgwg-enterprise-pa-multihoming-10.txt   draft-ietf-rtgwg-enterprise-pa-multihoming-11.txt >
skipping to change at page 1, line 13 skipping to change at page 1, line 13
Routing Working Group F. Baker Routing Working Group F. Baker
Internet-Draft Internet-Draft
Intended status: Informational C. Bowers Intended status: Informational C. Bowers
Expires: January 4, 2020 Juniper Networks Expires: January 4, 2020 Juniper Networks
J. Linkova J. Linkova
Google Google
July 3, 2019 July 3, 2019
Enterprise Multihoming using Provider-Assigned IPv6 Addresses without Enterprise Multihoming using Provider-Assigned IPv6 Addresses without
Network Prefix Translation: Requirements and Solutions Network Prefix Translation: Requirements and Solutions
draft-ietf-rtgwg-enterprise-pa-multihoming-10 draft-ietf-rtgwg-enterprise-pa-multihoming-11
Abstract Abstract
Connecting an enterprise site to multiple ISPs over IPv6 using Connecting an enterprise site to multiple ISPs over IPv6 using
provider-assigned addresses is difficult without the use of some form provider-assigned addresses is difficult without the use of some form
of Network Address Translation (NAT). Much has been written on this of Network Address Translation (NAT). Much has been written on this
topic over the last 10 to 15 years, but it still remains a problem topic over the last 10 to 15 years, but it still remains a problem
without a clearly defined or widely implemented solution. Any without a clearly defined or widely implemented solution. Any
multihoming solution without NAT requires hosts at the site to have multihoming solution without NAT requires hosts at the site to have
addresses from each ISP and to select the egress ISP by selecting a addresses from each ISP and to select the egress ISP by selecting a
skipping to change at page 6, line 18 skipping to change at page 6, line 18
of traffic with external destinations. of traffic with external destinations.
This document is organized as follows. Section 4 looks in more This document is organized as follows. Section 4 looks in more
detail at the enterprise networking environments in which this detail at the enterprise networking environments in which this
solution is expected to operate. The discussion of Section 4 uses solution is expected to operate. The discussion of Section 4 uses
the concepts of source-prefix-scoped routing advertisements and the concepts of source-prefix-scoped routing advertisements and
forwarding tables and provides a description of how source-prefix- forwarding tables and provides a description of how source-prefix-
scoped routing advertisements are used to generate source-prefix- scoped routing advertisements are used to generate source-prefix-
scoped forwarding tables. Instead, this detailed description is scoped forwarding tables. Instead, this detailed description is
provided in Section 5. Section 6 discusses existing and proposed provided in Section 5. Section 6 discusses existing and proposed
mechanisms for hosts to select the default source address applied to mechanisms for hosts to select the default source address to be used
packets. It also discusses the requirements for routing that are by applications. It also discusses the requirements for routing that
needed to support these enterprise network scenarios and the are needed to support these enterprise network scenarios and the
mechanisms by which hosts are expected to select source addresses for mechanisms by which hosts are expected to update default source
new connetions dynamically based on network state. Section 7 addresses based on network state. Section 7 discusses deployment
discusses deployment considerations, while Section 8 discusses other considerations, while Section 8 discusses other solutions.
solutions.
2. Requirements Language 2. 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", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Terminology 3. Terminology
 End of changes. 2 change blocks. 
8 lines changed or deleted 7 lines changed or added

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