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

[Andrew Dul]

https://tools.ietf.org/html/rfc5533

As far as I know this concept wasn't really adopted or embraced by
network operators.

Andrew

On 7/16/2020 8:11 PM, 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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20200717/7acb6916/attachment.htm>