[arin-ppml] Draft Policy ARIN-2019-4: Allow Inter-regional IPv6 Resource Transfers
hostmaster at uneedus.com
hostmaster at uneedus.com
Wed Apr 3 23:16:54 EDT 2019
My multihoming solution was homegrown, and not a vendor solution. I agree
that despite RFC 7084 being issued in November, 2013 there does not yet
appear to be a standardized way to multihome more than one provider
connection without either using PI space and BGP, or a form of NAT for
IPv6 multihoming (Shim 6) on standard ISP connections. No one to my
knowledge has ever actually put this RFC into action. The key part of
that RFC is router notifications of zero preferred lifetime when a link
fails. This signals the attached hosts to change their default gateway.
I have low margins in my smallish business, and the additional costs of PI
space and BGP based ISP connections are not worth incurring just to avoid
a 1 minute latency issue that might happen less than a couple of times in
a month on average. Others with a bigger budget might make a different
choice. Happy eyeballs is another reason not to incur costs, since a
failover to IPv4 will happen in less than that minute, and of course since
IPv4 sits behind a NAT, that fallover problem has been solved by almost
every major vendor without the use of BGP.
I suspect the true reason for the IETF's failure on their renumbering test
was the lack of implementation of things like RFC 7084. Had there been
vendor support for this, the renumbering test would have gone more
smoothly.
My opinion is that IPv6 needs to avoid all the hacks that we have done in
IPv4 and remain pure. IPv6 brings back true end to end connections
without all the hacks needed in an IPv4 enviroment, and should make things
simpler with a smaller routing table. For that reason, I am opposed to
IPv6 transfers. If transfers should be permitted, these transfers should
be limited to PI space and it should not be permitted in PA space since
that leads us down the road to much fragmented routing tables.
Albert Erdmann
Network Administrator
Paradise On Line Inc.
On Wed, 3 Apr 2019, JORDI PALET MARTINEZ via ARIN-PPML wrote:
> Sorry the late answer been extremely busy for a few days and had big email backlog.
>
> El 27/3/19 23:12, "arin-ppml-bounces at arin.net en nombre de hostmaster at uneedus.com" <arin-ppml-bounces at arin.net en nombre de hostmaster at uneedus.com> escribió:
>
> On Tue, 26 Mar 2019, JORDI PALET MARTINEZ via ARIN-PPML wrote:
>
> >
> > El 26/3/19 23:23, "arin-ppml-bounces at arin.net en nombre de hostmaster at uneedus.com" <arin-ppml-bounces at arin.net en nombre de hostmaster at uneedus.com> escribiÓ:
> >
> > I am opposed.
> >
> > IPv6 policies have been designed from the beginning to limit the growth of
> > the global routing tables. Policies such as sparse assignment help with
> > this goal, as well as the development of means to renumber with relative
> > ease, compared to IPv4. This is because more than one upstream can be
> > advertised at the same time and in the same network. A RFC compliant host
> > will by default assign addresses in each subnet that it hears router
> > advertisements and spread its outgoing traffic between the available
> > upstream routers. Unlike IPv4, we are nowhere near exhaust, and there is
> >
> > Have you really tried that ? Thinks aren't so easy as it may seem.
>
> Yes, I have done this for the last 6 years. It works 100% on inbound
> traffic. I agree there is a big issue with MS boxes choosing just a
> single outbound IPv6 route and never failing over, except to IPv4 because
> of happy eyeballs in the browser.
>
> Working only for inbound traffic is not a solution.
>
> >
> > no need to get into the legacy transfer issue with IPv6. I would perfer
> > to allow each IPv6 block assigned to a RIR to remain 100% under the
> > control of that RIR. If transfers are possible, this fact alone can be
> > used to defeat the trust anchor.
> >
> > It is unclear to me what the trust anchor problem actually is, and why it
> > needs to lead to the explosion of the IPv6 DFZ because of transfers. If
> >
> > This policy will not increase the DFZ. The same number of routes you
> > have in one region will just move to another one, same or different
> > upstreams.
> >
>
> IPv6 was designed from the beginning to allow more than one router on a
> lan. Therefore each router can be associated with a different ISP. Hosts
> will assign an address on each network that sends a router advertisement.
> Since I am using only the ISP default route on each /64 ISP provided
> network, you are correct, the number of routes in the DFZ do not change.
>
> This is also the way you can easily (compared to IPv4) migrate to a new
> address block, by marking the old one as depreciated. At that point, old
> connections are continued, but all new ones happen on the new address
> block.
>
> You mean renumbering. We had a big IETF effort to try that. Is not that easy. It means somebody need to change, for example, DNS. This means that you can't have multihoming with automatic failover, load sharing/balancing, etc., not that easy.
>
> > there is an issue of ARIN policy regarding trust anchors compared to other
> > RIR's, this policy should instead be addressed instead of allowing
> > transfers as a work around to a bad ARIN policy.
> >
> > Ideally, IPv6 blocks should be obtained from the upstream ISP/LIR and they
> > should be routed to the default route, with only one route per ISP/LIR.
> >
> > Ideally yes, one router per ISP/LIR, but not all follow that because
> > "traffic engineering".
>
> True, but usually all customers in a given area use that same set of
> routes, and this does not require any route involvement at the ISP.
>
> >
> > If I understand correctly, you're saying that we must not have IPv6 PI?
> >
>
> No, I am not saying that at all. I am pointing out that in IPv6 that
> multihome and failover should work over standard ISP connections, without
> any involvement with the upstream ISP. This also allows failover without
> having to obtain IPv6 PI space, using only the upstream provided IPv6
> addresses. If you have a site that needs more bandwidth than a standard
> connection can provide, you can choose to use two or more different
> providers to provide the required bandwidth and also obtain failover
> without any additional costs. Each host will obtain an IPv6 address from
> every available router. In the case of MS windows, it will only use one of
> the provided IPv6 /64's for outbound connections, but which one is chosen
> is quite random and tends to be close to evenly split between each of them
> in a group of MS windows machines. I wish that MS would read the RFCs and
> split their outbound bandwidth use between all available connections like
> Linux does.
>
> > Since the "normal" site assignment is a /48, unlike IPv4, there is no
> > shortage of address space for any use without involvement of ARIN or other
> > RIR. If one needs to be multihomed, each host can have an address from
> > each available upstream, providing availability to each host from more
> > than one network.
> >
> > Have you tried that? Hosts don't multihome today with IPv6 with multiple
> > prefixes from different upstreams. You really need IPv6 PI.
> >
>
> I have, and have been doing it for the last 6 years. It does require DNS
> tricks. I have a script running that removes the AAAA record for any
> upstream that is not available, and replaces it when it returns. Of course
> that record uses a TTL of 60. It simply pings each circuit's gateway
> address to determine the up/down status of that connection once a minute,
> and adds/removes the DNS records for the IP address for that connection
> assigned to each host on the network that has either failed or returned.
> While not instant or perfect, the script is cheap and requires no
> additional hardware or costs.
>
> Not instant means is not usable. If it means having a low TTL is bad for being able to cache the RR, etc.
>
> I can't agree this is the way at all.
>
> > Albert Erdmann
> > Network Administrator
> > Paradise On Line Inc.
> >
> > On Tue, 26 Mar 2019, ARIN wrote:
> >
> > > On 21 March 2019, the ARIN Advisory Council (AC) accepted "ARIN-prop-263:
> > > Allow Inter-regional IPv6 Resource Transfers" as a Draft Policy.
> > >
> > > The Draft Policy text is below and can be found at:
> > > https://www.arin.net/participate/policy/drafts/2019_4/
> > >
> > > You are encouraged to discuss all Draft Policies on PPML. The AC will
> > > evaluate the discussion in order to assess the conformance of this draft
> > > policy with ARIN's Principles of Internet number resource policy as stated in
> > > the Policy Development Process (PDP). Specifically, these principles are:
> > >
> > > * Enabling Fair and Impartial Number Resource Administration
> > > * Technically Sound
> > > * Supported by the Community
> > >
> > > The PDP can be found at:
> > > https://www.arin.net/participate/policy/pdp/
> > >
> > > Draft Policies and Proposals under discussion can be found at:
> > > https://www.arin.net/participate/policy/drafts/
> > >
> > > Regards,
> > >
> > > Sean Hopkins
> > > Policy Analyst
> > > American Registry for Internet Numbers (ARIN)
> > >
> > >
> > >
> > > Draft Policy ARIN-2019-4: Allow Inter-regional IPv6 Resource Transfers
> > >
> > > Problem Statement:
> > >
> > > There is an operational need to allow RIR transfers of IPv6 resources between
> > > RIRs with an equivalent transfer policy. ARINâ•˙s RPKI Trust Anchor (TA) is
> > > measurably less widely deployed than TAs from other RIRs. As a consequence,
> > > RPKI ROAs published through ARIN offer less value. Operators seeking to
> > > extract the most value from their investment in IPv6 would benefit from the
> > > ability to transfer IPv6 resources to RIRs with more widely deployed RPKI
> > > Trust Anchors.
> > >
> > > Policy Statement:
> > >
> > > Change the first sentence in section 8.4 from:
> > >
> > > ╲Inter-regional transfers of IPv4 number resources and ASNs may take place
> > > only via RIRs who agree to the transfer and share reciprocal, compatible
> > > needs-based policies.╡
> > >
> > > To:
> > >
> > > ╲Inter-regional transfers of Internet number resources may take place only
> > > via RIRs who agree to the transfer and share reciprocal, compatible
> > > needs-based policies.╡
> > >
> > > Comments:
> > >
> > > Timetable for implementation: Immediate
> > > _______________________________________________
> > > ARIN-PPML
> > > You are receiving this message because you are subscribed to
> > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > > Unsubscribe or manage your mailing list subscription at:
> > > https://lists.arin.net/mailman/listinfo/arin-ppml
> > > Please contact info at arin.net if you experience any issues.
> > >_______________________________________________
> > ARIN-PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > https://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >
> >
> >
> >
> > **********************************************
> > IPv4 is over
> > Are you ready for the new Internet ?
> > http://www.theipv6company.com
> > The IPv6 Company
> >
> > This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
> >
> >
> >
> > _______________________________________________
> > ARIN-PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > https://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
> >_______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
>
>
>
> _______________________________________________
> ARIN-PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> https://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
More information about the ARIN-PPML
mailing list