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