[arin-ppml] Draft Policy ARIN-2020-5: Clarify and Update Requirements for Allocations to Downstream Customers

[Owen DeLong]

This is all beautiful in theory.

There are a lot of applications with crufty code out there that do not handle this situation well at all.

There’s also the issue of what happens when the upstream router goes away, but the link state doesn’t change.

There are other issues.

Bottom line, it’s theoretically possible, but current implementations lead to very bad user experiences.

There are some efforts underway (HOMENET and V6OPS working groups) to potentially improve the situation.

Owen


> On Jul 16, 2020, at 20:11 , hostmaster at uneedus.com wrote:
> 
> Has there actually been any effort toward another routing method in IPv6 other than BGP?
> 
> In theory, IPv6 should not require BGP for multihoming, unlike IPv4. According to the current IPv6 standards, one should be able to have more than one router from more than one provider on a LAN.  Each of these routers could assign a SLAAC/DHCP6 address/network to every host, providing each host with more than one route to the internet, using the IPv6 block of each upstream.  Thus, if this could properly work, IPv6 should be able to provide multihoming to each host with an address on the provider blocks, without the need of the customer site to use BGP or any other routing protocol.
> 
> The problem is that the IPv6 stack in these hosts receiving advertisements from more than one router generally cannot deal with more than one default route, forcing all traffic from that host onto only one of the available networks.  This is not an easy fix, since it would require a change in the network stack of each host, rather than each network.
> 
> I have more than one IPv6 upstream, with a /48 from each from their PA space.  In order to get this to work, I have to play games with the routing table with a cron script that checks for upstream connectivity and changes the routing tables accordingly. Other scripts for inbound connections alter the inbound DNS entries that are always advertised with a low TTL. It would be nice if ITEF could work out a true solution to this, as it would eliminate the need for most to have PI IPv6 space.
> 
> Any news on if there has ever been any progress in this regard?  By splitting the upstream between more than one IPv6 provider, this would seem to to be a cleaner solution than BGP and IPv4.  I would rather have an RFC sanctioned solution to this problem.
> 
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
> 
> 
> On Thu, 16 Jul 2020, Owen DeLong wrote:
> 
>> In general, I agree with your point. Perhaps “Customer must originate prefix(es) and announce them via a border routing protocol (e.g. BGP-4) to each of their
>> upstreams."
>> In specific, I think it’s extremely unlikely that there will be any significant advances or changes in IPv4 routing protocols as the IETF has pretty thoroughly
>> expressed adesire to stop working on IPv4 except in furtherance of transition to IPv6.
>> Owen
>> 
>>      On Jul 16, 2020, at 11:06 , John Santos <john at egh.com> wrote:
>> On 7/16/2020 11:39 AM, Kat Hunter wrote:
>> [...]
>>      4.2.3.6 Original Text:
>>      Under normal circumstances an ISP is required to determine the prefix size of their reassignment to a downstream customer according to the
>>      guidelines set forth in RFC 2050. Specifically, a downstream customer justifies their reassignment by demonstrating they have an immediate
>>      requirement for 25% of the IP addresses being assigned, and that they have a plan to utilize 50% of their assignment within one year of its receipt.
>>      This policy allows a downstream customer’s multihoming requirement to serve as justification for a /24 reassignment from their upstream ISP,
>>      regardless of host requirements. Downstream customers must provide contact information for all of their upstream providers to the ISP from whom they
>>      are requesting a /24. The ISP will then verify the customer’s multihoming requirement and may assign the customer a /24, based on this policy.
>>      Customers may receive a /24 from only one of their upstream providers under this policy without providing additional justification. ISPs may
>>      demonstrate they have made an assignment to a downstream customer under this policy by supplying ARIN with the information they collected from the
>>      customer, as described above, or by identifying the AS number of the customer. This information may be requested by ARIN staff when reviewing an
>>      ISP’s utilization during their request for additional IP addresses space.
>> New version of proposed 4.2.3.6 replacement:
>> 
>>      4.3.2.6 New Text, replacing old:
>>      If a downstream customer has a requirement to multihome, that requirement alone will serve as justification for a /24 allocation. Downstream
>>      customers must provide contact information for all of their upstream providers to the ISP from whom they are requesting a /24, and utilize BGP as
>>      the routing protocol between the customer and the ISP. Customers may receive a /24 from only one of their upstream providers under this policy
>>      without providing additional justification. ISPs may demonstrate they have made an assignment to a downstream customer under this policy by
>>      supplying ARIN with the information they collected from the customer, as described above, or by identifying the AS number of the customer.
>> -Kat Hunter
>> [...]
>> Older version of proposed 4.2.3.6:
>> 
>>            4.2.3.6. Reassignments to Multihomed Downstream Customers
>> 
>>            If a downstream customer has a requirement to multihome, that
>>            requirement alone will serve as justification for a /24 allocation.
>>            Downstream customers must provide contact information for all of their
>>            upstream providers to the ISP from whom they are requesting a /24, and
>>            utilize BGP as the routing protocol between the customer and the ISP.
>>            Customers may receive a /24 from only one of their upstream providers
>>            under this policy without providing additional justification. ISPs may
>>            demonstrate they have made an assignment to a downstream customer under
>>            this policy by supplying ARIN with the information they collected from
>>            the customer, as described above, or by identifying the AS number of the
>>            customer.
>> 
>>            Timetable for implementation: Immediate
>> I haven't digested this proposal sufficiently to have an opinion one way or the other, but I do have a general and a specific question.  Doesn't ARIN attempt to
>> avoid mandating particular network technologies in policy, so as not to impede technological advances?
>> I am particularly referring to BGP in both versions of the proposed new policy.  Would it be better to develop wording that would suggest BGP until something
>> better comes along, by not specifically refer to it in the policy text?  Or is BGP considered to be as good as it's ever going to get, at least for IPv4
>> routing?
>> -- 
>> John Santos
>> Evans Griffiths & Hart, Inc.
>> 781-861-0670 ext 539
>> _______________________________________________
>> 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.