<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix"><a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/rfc5533">https://tools.ietf.org/html/rfc5533</a></div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">As far as I know this concept wasn't
really adopted or embraced by network operators.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Andrew<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 7/16/2020 8:11 PM,
<a class="moz-txt-link-abbreviated" href="mailto:hostmaster@uneedus.com">hostmaster@uneedus.com</a> wrote:<br>
</div>
<blockquote type="cite"
cite="mid:alpine.LRH.2.21.2007162243110.8599@bigone.uneedus.com">Has
there actually been any effort toward another routing method in
IPv6 other than BGP?
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
Albert Erdmann
<br>
Network Administrator
<br>
Paradise On Line Inc.
<br>
<br>
<br>
On Thu, 16 Jul 2020, Owen DeLong wrote:
<br>
<br>
<blockquote type="cite">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
<br>
upstreams."
<br>
<br>
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
<br>
expressed adesire to stop working on IPv4 except in furtherance
of transition to IPv6.
<br>
<br>
Owen
<br>
<br>
<br>
On Jul 16, 2020, at 11:06 , John Santos
<a class="moz-txt-link-rfc2396E" href="mailto:john@egh.com"><john@egh.com></a> wrote:
<br>
<br>
On 7/16/2020 11:39 AM, Kat Hunter wrote:
<br>
[...]
<br>
4.2.3.6 Original Text:
<br>
Under normal circumstances an ISP is required to determine
the prefix size of their reassignment to a downstream customer
according to the
<br>
guidelines set forth in RFC 2050. Specifically, a
downstream customer justifies their reassignment by
demonstrating they have an immediate
<br>
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.
<br>
This policy allows a downstream customer’s multihoming
requirement to serve as justification for a /24 reassignment
from their upstream ISP,
<br>
regardless of host requirements. Downstream customers must
provide contact information for all of their upstream providers
to the ISP from whom they
<br>
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.
<br>
Customers may receive a /24 from only one of their
upstream providers under this policy without providing
additional justification. ISPs may
<br>
demonstrate they have made an assignment to a downstream
customer under this policy by supplying ARIN with the
information they collected from the
<br>
customer, as described above, or by identifying the AS
number of the customer. This information may be requested by
ARIN staff when reviewing an
<br>
ISP’s utilization during their request for additional IP
addresses space.
<br>
<br>
New version of proposed 4.2.3.6 replacement:
<br>
<br>
4.3.2.6 New Text, replacing old:
<br>
If a downstream customer has a requirement to multihome,
that requirement alone will serve as justification for a /24
allocation. Downstream
<br>
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
<br>
the routing protocol between the customer and the ISP.
Customers may receive a /24 from only one of their upstream
providers under this policy
<br>
without providing additional justification. ISPs may
demonstrate they have made an assignment to a downstream
customer under this policy by
<br>
supplying ARIN with the information they collected from
the customer, as described above, or by identifying the AS
number of the customer.
<br>
<br>
-Kat Hunter
<br>
[...]
<br>
<br>
Older version of proposed 4.2.3.6:
<br>
<br>
4.2.3.6. Reassignments to Multihomed Downstream
Customers
<br>
<br>
If a downstream customer has a requirement to
multihome, that
<br>
requirement alone will serve as justification for a
/24 allocation.
<br>
Downstream customers must provide contact
information for all of their
<br>
upstream providers to the ISP from whom they are
requesting a /24, and
<br>
utilize BGP as the routing protocol between the
customer and the ISP.
<br>
Customers may receive a /24 from only one of their
upstream providers
<br>
under this policy without providing additional
justification. ISPs may
<br>
demonstrate they have made an assignment to a
downstream customer under
<br>
this policy by supplying ARIN with the information
they collected from
<br>
the customer, as described above, or by identifying
the AS number of the
<br>
customer.
<br>
<br>
Timetable for implementation: Immediate
<br>
<br>
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
<br>
avoid mandating particular network technologies in policy, so as
not to impede technological advances?
<br>
<br>
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
<br>
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
<br>
routing?
<br>
<br>
<br>
-- <br>
John Santos
<br>
Evans Griffiths & Hart, Inc.
<br>
781-861-0670 ext 539
<br>
_______________________________________________
<br>
ARIN-PPML
<br>
You are receiving this message because you are subscribed to
<br>
the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
<br>
Unsubscribe or manage your mailing list subscription at:
<br>
<a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
<br>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.
<br>
<br>
<br>
<br>
<br>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="https://lists.arin.net/mailman/listinfo/arin-ppml">https://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>