<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>