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.
