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, [email protected] 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 <[email protected]> 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 ([email protected]). >> Unsubscribe or manage your mailing list subscription at: >> https://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact [email protected] if you experience any issues. >> >> >> >> > > _______________________________________________ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues.
_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
