Network Working Group M.G.D.Sumanta
Internet-Draft IMTEC
Intended status: Informational September 14 , 2016
Expires: March 14, 2017
IPv6 Multihoming with transparent End-to-End connectivity
draft-sumanta-ipv6-multihoming-solution-01
Abstract
IPv6 Multihoming design help host(s) in a site to switch dynamically
between multiple attached global internet without impacting
transport and application layer protocol whenever failure occur.
Basic issue on this design when ipv-to-ipv6 Network prefix
translations not being used are:-
1. Source addresses selection, 2. Next hop selection and
3. DNS resolution.
Even though Ipv6-to-Ipv6 Network prefix translation (NPTv6) solve
above mention problems, NPTv6 not ideal as it's not achieve
End-to-End transparency of connectivity .Alternatively by using
policy at End host to select source address and next hop also
solve above mention issues.
This document proposes solution which defines how automatically a
policy can be enforced on host by first hop router using router
advertisement. That's reduced administrative effort of updating policy
on all hosts in site. This document not obsolete any of the previous
work, only propose how policy on End-host can be enforce from router
by mapping destination prefix with DNS via Router Advertisement.
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, 2017.
M.G.D.Sumanta Expires March 14,2017 [Page 1]
Internet-Draft IMTEC September 14, 2016
Copyright Notice
Copyright (c) 2015 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
1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement ............... . . . . . . . . . . . . . . 5
3.1. Wrong Source address selection. ......................... 5
3.2. Wrong Next hop selection. . . . . . . . . . . . ...... . 5
3.3. Private and Public RDNSS co-existence. . . . . . . . . .. 5
4. Router Advertisement message on details . . . . . . . . . .. 5
4.1. Router Advertising message. . . . . . . . . . . . . . . . 5
4.2. Recursive DNS Server option.. . . . . . . . . . . . . . . 6
4.3 DNS Search list option. ................................ 6
4.4 Router information option. .............................. 6
5. Solution . . . . . . . . . . . . . . . . . . . . . . ........ 7
5.1. Next Hop selection . . . . . . . . . . . . . . . ..... 7
5.2. Source Address Selection . . . . . . . . . . . . . . . . 8
5.3. Private and Public RDNS co-existence . . . . . . . . . .. 9
5.4. DNS search-list extension ............................. 9
6. Security Considerations . . . . . . . . . . . . . . . . . . .. 9
7. IANA Considerations ......................................... 10
8. Acknowledgements ............................................ 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . .. 10
9.2. Informative References . . . . . . . . . . . . . . . . .. 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . .. 11
M.G.D.Sumanta Expires March 14,2017 [Page 2]
Internet-Draft IMTEC September 14, 2016
1. Introduction
Multi Homing has been architect to exchange IP packet uninterruptedly
from local host to remote host or vice versa even when underlying
connectivity change dynamically. It is being designed to support
changing path without knocking session of the application.
+------+
|remote|
| host |
| R |
+------+
|
+ - - - - - - - - - - - +
| Internet Connectivity |
+ - - - - - - - - - - - +
/ \
+---------+ +---------+
| ISP A | | ISP B |
+---------+ +---------+
| Path A | Path B
+ - - - - - - - - - - - - - - - - - - - - +
| multi- | | |
homed +------+ +------+
| site | site-| | site-| |
| exit | | exit |
| |router| |router| |
| A | | B |
| +------+ +------+ |
| |
| local site connectivity |
|
| +-----------+ |
|multi-homed|
| | host | |
+-----------+
+ - - - - - - - - - - - - - - - - - - - - +
Fig 1 : Complete figure of ipv6 multiHoming.
M.G.D.Sumanta Expires March 14,2017 [Page 3]
Internet-Draft IMTEC September 14, 2016
Network Address and port Translation (NAPT) one of the solution which
being used in Ipv4 Multihoming scenario also can be used in Ipv6.
Ipv6-to-Ipv6 network prefix translation (NPTV6) RFC 6296 [RFC6296] work
on basic principle, End host address being mapped with a global address
and confined End host address visibility from outside network. Invisible
nature of Network address translation prevent End-to-end transparency.
Unlike Ipv6, in Ipv4 where global address are scarce resource,
Network Address Translation could be ideal solution.
That unlikely the case in IPv6, which have enough address to uniquely
address every conceivable host on internet without using network address
Port Translation (NAPT) [ RFC3022]
Adequate number of Ipv6 global unique address and support for multiple
addresses in node make easy to implement end host with multiple unique
address from different service provider its being connected. This
ensure end-to-end transparent connection. However there are
several issue in this kind of implementation or design,
Issues can be broadly categories in to :
A. Wrong Source address selection.
B. Wrong Next hop selection.
C. Private and public RDNSS co-existence.
On way to get ride off above mention issues from multi address assigned
end host implementation would be using policy on end host to select
Source address and Next hop.
On complex uses case, end host policy definition will be so complex that
it's difficult to achieve complete error free. Complexity arise
due to multiple next hop, source address and DNS presence and any wrong
combination will raise reachability issue or ingress filtering on
service provider ingress end. It get further complicated on deployment
where local destination reachable via a particular site and remote
destination reachable via multiple sites. Further, manual policy
configuration on end host subjected to changeable whenever service
provider's or local site's DNS, default gate way router and numerous
destination changes.
RFC 7157 [RFC 7157] also talk about same issue described here.
RFC 7157 described how police implementation in end host solve issue.
This document further narrate how the policy can be created
automatically by router using router advertisement. This document
also describe how public private name space information being feed to
host , so that host can select right next hop and source address to
resolve domain name on mix environment of public and private RDNSS.
RFC 6724 [RFC6724] laid down guideline for Address selection rule.That's
work fine when multiple interface are from different address space like
unicast , multicast ,Ipv4 and IPv6 or from different scope within IPv6
like link-local , global etc. However, when multiple address from same
scope present above mention issue persist. Multihomed host which is
connected to multiple internet providers have multiple global scope
address configured from connected provider dependent address space.
1.1. Reserved Words
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 [RFC2119].
M.G.D.Sumanta Expires March 14,2017 [Page 4]
Internet-Draft IMTEC September 14, 2016
2. Terminology
NPTv6 IPv6-to-IPv6 Network Prefix Translation as described in
[RFC6296].
NAPT Network Address Port Translation as described in
RFC 3022 [RFC3022]. In other contexts, NAPT is often pronounced
"NAT" or written as "NAT".
MHMP Multihomed with multi-prefix. A host implementation that
supports the mechanisms described in this document;
selection, and DNS selection policy.
namely, source address selection policy, next hop
3. Problem Statement
+------+ ___________
| | / \
+---| rtr1 |=====/ network \
| | | \ 1 ISP A /
+------+ | +------+ \___________/
| | |
|host |-----+
| | |
+------+ | +------+ ___________
| | | / \
+---| rtr2 |=====/ network \
| | \ 2 ISP B /
+------+ \___________/
Fig 2: Ipv6 Multi homing Part figure.
3.1 Wrong Source address selection.
When multiple address assigned on End host,End host may
select different Source address the the right source address need to
reach via a service provider. Wrong source address selection does not
alarming without service provider have ingress filter applied as packet
with any global address perfect to travel global scope. However,
uncertainty on service provider ingress filter presence impose packet's
source address should be particular service provider dependent address.
Otherwise, will be filter out on service provider network by ingress
rule. Having different service provider dependent source address compare
to service provider packet being forwarded consider as wrong source
address selection.
3.2 Wrong Next hop selection.
End host for all off-link prefix, consider default router address as
M.G.D.Sumanta Expires March 14,2017 [Page 5]
Internet-Draft IMTEC September 14, 2016
next hop. Default routers are being advertise using dynamic router
advertisement process. Selection of default router is either by
round robin or by preference setting. RFC 4861 [RFC4861] and
RFC 4191 [RFC4191] describe in details. Further, end host could be
router capable and have routing table entry corresponding to different
destination. However, practice of having routing info limited on End
host, due to memory and computation requirement. Nondeterministic nature
of default router selection may lead to scenario where host chose a
next hop which does not have reachability to reach particular
destination. Or Host select a next hop to reach DNS for domain name
esolve can not forward to selected DNS. Further, Ingres filtering, state
full farewells and unicast revers path filtering (uRPF) RFC3704[RFC3704]
also disrupt traffic on wrong next hop selection. Similarly packet when
need o be routed through a particular local site,next hop selection play
a pivotal role for successful packet delivery.
3.3 Private and Public RDNSS co-existence.
In an implementation End host could only send default queries to the
RDNSS present in Internet and queries related to the private namespace
to the RDNSS of the private network. This can be configured by setting
the RDNSS of the private network to know about listed domains and
networks, but not to be a default RDNSS. Typical issue with this
implementation , end host does not has clue which DNS to reach for
which destination URL ,wrong estination choice will lead to unsuccessful
attempts on address resolve process .Even if selection of DNS problem
being bell out, further packet forwarding should be with same source
address and next hop. Otherwise packet will not get fate to reach
final destination.Such way, presence of private and public RDNSS
co-existence provoke more complex issue egards o sourc address and
next hop selection.
4. Router Advertisement message on details
4.1 Router Advertising message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O| Reserved | Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options...
+-+-+-+-+-+-+-+-+-+-+-+-
M.G.D.Sumanta Expires March 14,2017 [Page 6]
Internet-Draft IMTEC September 14, 2016
4.2 Recursive DNS Server option.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Addresses of IPv6 Recursive DNS Servers :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3 DNS Search list option.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Domain Names of DNS Search List :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.4 Router information option.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Prefix Length |Resvd|Prf|Resvd|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix (Variable Length) |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M.G.D.Sumanta Expires March 14,2017 [Page 7]
Internet-Draft IMTEC September 14, 2016
5. Solution
100::/
+------+ ___________
fe80::11 | | / \ DNS 101::1
+---| rtr1 |=====/ network \
| | | \ 1 ISP A /
+------+ | +------+ \___________/
| | |
|host |-----+
| | | 200::/
+------+ | +------+ ___________
| | | / \
+---| rtr2 |=====/ network \ DNS 202::1
fe80::12 | | \ 2 ISP B /
+------+ \___________/
Fig 3: Ipv6 Multi homing Part figure.
5.1 Next Hop selection
Network designer or Administrator should provision router to aware
of DNS address and service provider prefix which end host will use as
DNS address to resolve destination URL and provided prefix to build up
its interface address respectively. Administrator should provision
correct mapping of this information, so that when end host select
service provider prefix corresponding address as source address and
pair DNS address , packet forward successfully. Also, particular router
is the prefer router to reach destination for both DNS traffic and
data traffic using corresponding service provider dependent source
address. This should be ensure for error free traveling to destination
with correct mapping of source address and next hop. Further Router
will send router advertisement with router information list carrying
DNS server prefix with prf value as high. By receiving such router
advertisement, host select advertising router link-local address as
next hop or default gate way router to reach prefix mention on router
information list. Hence, to reach particular DNS host will chose
advertising router as next hop. Further all traffic destined for same
destination should use same Next hop as its being used to reach DNS
while discovering domain to address mapping. In some case host may
know destination ipv6 address and do not go through DNS resolve process.
In that circumstances, if destination belongs to particular
service provider dependent prefix or prefix being advertise through
Router advertisement on its router information list setting,
advertising router Link-local address being used as next hop address.
In other all case Next hop being selected current rule
of random selection.
M.G.D.Sumanta Expires March 14,2017 [Page 8]
Internet-Draft IMTEC September 14, 2016
Example :
In above [Fig 3], consider ISP A DNS server address 101::1 and
ISP B DNS server address 202::1. When rtr1 send RA message
along with all info it's propagate to host, Recursive DNS option,
DNS search list option; it's also should add Router
information option , for prefix 101::1/128. By receiving such RA,
host will set highest default router as rtr1 link-local address
for 101:: 1/128 prefix. Similarly, rtr2's link-local will be
considered as highest default router for prefix 202:: 1/128.Now
there is no difficulty to select correct next hop. If host want
to resolve via ISP A, it will choose rtr1 and when
via ISP B it will choose rtr2.
5.2 Source Address Selection
Similar to Next hop rule , Network designer or
Administrator should provision router to aware of service provider
prefix and DNS address which end host will adopt to build up its
interface address and to use as DNS to resolve destination URL
respectively. Router should hold correct mapping of this information,
so that if end host wanted to reach any destination including mapping
DNS using provision prefix corresponding source address, particular
router should be the next hop. This should be ensure. Router send
router advertisement with router information list carrying DNS server
prefix with prf value as high. By receiving such router
advertisement, hos ensure while advertising router being chosen as
Next hop address, advertise prefix corresponding address also being
chosen as source address. Even for the traffic which not going
through DNS resolve, also should chose source address based on Next
hop its select. That ensure right choice of source address in all
implementations and use cases.
Example :
In above figure [Fig 3] rtr1 send RA with prefix 100::/64 to configure
ISP dependent address. Rtr1 Link-local address is fe80::11 Similarly
rtr2 send RA with prefix 200::/64 to configure ISP dependent address.
Rtr2 Link-local address is fe80::12 Let consider 400::/64 is the
destination traffic need to be destine. As this is being off-link
prefix, traffic is being send base on default router and next hop
will be selected as either rtr1 or rtr2 link-local address. Proposed
enhancement will select source as 100::xxxx address when rtr1 is
being selected as next hop or will select 200::xxx
address when rtr2 is being selected as next hop.
M.G.D.Sumanta Expires March 14,2017 [Page 9]
Internet-Draft IMTEC September 14, 2016
5.3 Private and Public RDNS co-existence
When a local site have private DNS , router should advertise
local DNS prefix mapping to DNS search list containing entire
private domain name. Also, when site local have local destination
without subject to DNS resolve, those local destination also should
be advertise on router advertisement in router information list
setting prf bit high. In other word, administrator should
ensure all destination prefixes are being advertise on router
information list for which particular router must be consider as
Next hop. As RFC 4191 [RFC4191] already laid guideline,how host
should behave and which default router would be selected
based on router information list prefix and prf bit value further
not being described here. Using same guideline and with care full
declaration of router information list would help to nail down all
issues related to Next Hop and Source address selection on Private
and Public RDNS co-existence network.
5.4 DNS search-list extension
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | RDNS | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: Domain Names of DNS Search List :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RDNS Flag - This Flag indicate - Map domain suffix received on this
RA to RDNS option received in same RA.
6. Security Considerations
Major part of end host police enforcement depends on Router
advertisement and router information list its carry. Its
necessary router advertisement should be from a trusted router.
In a LAN to verify router advertisement from trusted source
there are already well define solution which carve out Rouge RA
problem, secure neighbor discovery etc. Also, creation of router
M.G.D.Sumanta Expires March 14,2017 [Page 10]
Internet-Draft IMTEC September 14, 2016
list depends on router aware ness of information which could be
potential thread of misinform. Careful approach of configuration
only by authorized network user or Authorized dynamic update process
should be in place to adhere those information for further use.
7. IANA Considerations
This document has no action for IANA
8. Acknowledgements
This document is influence by RFC 7157 which have details
explanation on Ipv6 multihoming problem and why End-to-End-Ipv6
translation not being a expectable solution. Also, this document
use some of the ASCII diagram from RFC 7157 in modified form.
Also acknowledge Brian E Carpenter for his feedback. this version
of draft mainly address his comment.
9. Reference
9.1 Normative Reference
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 7157] O. Troan,D. Miles ,S. Matsushima , T. Okimoto , D. Wing ,
"IPv6 Multihoming without Network Address Translation" ,
RFC 7157 , March 2014
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, June 2011.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for
Multihomed Networks", BCP 84, RFC 3704, March 2004.
9.2 Informative References
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January
2001.
M.G.D.Sumanta Expires March 14,2017 [Page 11]
Internet-Draft IMTEC September 14, 2016
Static Route Option for Dynamic Host Configuration
Protocol (DHCP) version 4", RFC 3442, December 2002.
10. Author's Address
Sumanta Das Gajendra Mahapatra
Dell international services India private limited
Chennai , INDIA
Email : sumanta.dgmp@gmail.com
M.G.D.Sumanta Expires March 14,2017 [Page 12]
Internet-Draft IMTEC September 14, 2016