Internet Engineering Task Force (IETF) O. Troan, Ed.
Request for Comments: 7157 Cisco
Category: Informational D. Miles
ISSN: 2070-1721 Google Fiber
S. Matsushima
Softbank Telecom
T. Okimoto
NTT West
D. Wing
Cisco
March 2014
IPv6 Multihoming without Network Address Translation
Abstract
Network Address and Port Translation (NAPT) works well for conserving
global addresses and addressing multihoming requirements because an
IPv4 NAPT router implements three functions: source address
selection, next-hop resolution, and (optionally) DNS resolution. For
IPv6 hosts, one approach could be the use of IPv6-to-IPv6 Network
Prefix Translation (NPTv6). However, NAT and NPTv6 should be
avoided, if at all possible, to permit transparent end-to-end
connectivity. In this document, we analyze the use cases of
multihoming. We also describe functional requirements and possible
solutions for multihoming without the use of NAT in IPv6 for hosts
and small IPv6 networks that would otherwise be unable to meet
minimum IPv6-allocation criteria. We conclude that DHCPv6-based
solutions are suitable to solve the multihoming issues described in
this document, but NPTv6 may be required as an intermediate solution.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7157.
Troan, et al. Informational [Page 1]RFC 7157 IPv6 Multihoming without NAT March 2014Copyright Notice
Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. IPv6 Multihomed Network Scenarios . . . . . . . . . . . . . . 6
3.1. Classification of Network Scenarios for Multihomed Host . 6
3.2. Multihomed Network Environment . . . . . . . . . . . . . 8
3.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 9
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. End-to-End Transparency . . . . . . . . . . . . . . . . . 11
4.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 11
5. Problem Analysis . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Source Address Selection . . . . . . . . . . . . . . . . 11
5.2. Next Hop Selection . . . . . . . . . . . . . . . . . . . 12
5.3. DNS Recursive Name Server Selection . . . . . . . . . . . 13
6. Implementation Approach . . . . . . . . . . . . . . . . . . . 13
6.1. Source Address Selection . . . . . . . . . . . . . . . . 14
6.2. Next Hop Selection . . . . . . . . . . . . . . . . . . . 14
6.3. DNS Recursive Name Server Selection . . . . . . . . . . . 15
6.4. Other Algorithms Available in RFCs . . . . . . . . . . . 16
7. Considerations for MHMP Deployment . . . . . . . . . . . . . 16
7.1. Non-MHMP Host Consideration . . . . . . . . . . . . . . . 16
datatracker.ietf.org