<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-7">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 14/10/2019 15:24,
<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.1910141402420.26132@bigone.uneedus.com"><clip><br>
<br>
Even if ARIN is permitted to allow it, I do not think it to be a
good idea. Right now, without a policy change I can look at that
list and know that 100% of each Block of IPv6 addresses is managed
by the RIR listed. That allows for clean filter lists in IPv6 for
those that choose to filter out abuse routes from other RIR's.
Allowing transfers will eliminate that clean fixed line that
currently exists. Also, return and renumbering has always been
part of the policy since the beginning of IPv6 and should be
enforced.
<br>
</blockquote>
<p>That in my view is one of the main ans strongest reasons for not
allowing IPv6 transfers between RIRs. As there is not IPv6
shortage there is a plausible option which is renumbering and any
organizations in a M&A situation should include that as part
of the whole business or transaction.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:alpine.LRH.2.21.1910141402420.26132@bigone.uneedus.com">
<br>
Also as pointed out by others, if we want to allow interRIR
transfers, I think the global policy needs to be changed to allow
it. Otherwise without global consensus, I think IPv6 transfers
should NOT be permitted.
<br>
<br>
Albert Erdmann
<br>
Network Administrator
<br>
Paradise On Line Inc.
<br>
<br>
On Mon, 14 Oct 2019, Owen DeLong wrote:
<br>
<br>
<blockquote type="cite">You have the control relationship
backwards. IANA is a function performed by PTI under a contract
controlled by the NRO (Number Resource Organization). The NRO is
the five RIRs and they tell ICANN how to perform the IANA
function, not the other way around.
<br>
<br>
I¢m still on the fence about allowing this, but the argument
that it is not permitted by IANA/ICANN/PTI is completely hollow.
<br>
<br>
Owen
<br>
<br>
<br>
<blockquote type="cite">On Oct 14, 2019, at 13:00,
<a class="moz-txt-link-abbreviated" href="mailto:hostmaster@uneedus.com">hostmaster@uneedus.com</a> wrote:
<br>
<br>
The process of IPv6 is that IANA, which is a function of ICANN
provides blocks of IPv6 numbers to the RIR's for allocation
and assignment.
<br>
<br>
Due to the shortage of IPv4 numbers and 16 bit ASN numbers,
ICANN and IANA has permitted inter RIR transfers to happen
with these resources. However this consent has never extended
to IPv6 addresses.
<br>
<br>
I am unaware that IANA/ICANN has EVER voted to permit ARIN or
any other RIR to give control of portions of the blocks of
IPv6 numbers assigned to ARIN to a different RIR, which is
what an inter-RIR transfer of IPv6 resources is.
<br>
<br>
In the IPv6 space there are no legacy addresses. Every Block
of IPv6 space was assigned to a specific RIR. That includes
every address within that block. Transfers would require a
policy at IANA/ICANN to permit these actions. Does such
permission exist, and can anyone point me towards it?
<br>
<br>
In any case, even if it is possible, does not mean that it is
a good idea. I still maintain that every IPv6 registrant knew
the rules of the road when they received their block. Those
rules were that they were not transferable between RIR's. If
they later choose a different RIR, I say let them renumber.
<br>
<br>
Albert Erdmann
<br>
Network Administrator
<br>
Paradise On Line Inc.
<br>
<br>
<blockquote type="cite">On Mon, 14 Oct 2019, William Herrin
wrote:
<br>
<br>
On Mon, Oct 14, 2019 at 7:50 AM Fernando Frediani
<a class="moz-txt-link-rfc2396E" href="mailto:fhfrediani@gmail.com"><fhfrediani@gmail.com></a> wrote:
<br>
<blockquote type="cite">On 12/10/2019 13:58, William Herrin
wrote:
<br>
<blockquote type="cite">On Sat, Oct 12, 2019 at 6:29 AM
<a class="moz-txt-link-rfc2396E" href="mailto:hostmaster@uneedus.com"><hostmaster@uneedus.com></a> wrote:
<br>
<blockquote type="cite">
<blockquote type="cite">I agree. The only reason for
this transfer thing was the shortage of IPv4
<br>
addresses and 16 bit ASN numbers. There is no
shortage of IPv6 addresses
<br>
or 32 bit ASN.
<br>
</blockquote>
</blockquote>
<br>
<blockquote type="cite">Therefore, I agree that IPv6
transfers and 32 bit ASN transfers should not
<br>
be permitted, even for M&A.
<br>
</blockquote>
</blockquote>
<br>
<blockquote type="cite">I have almost exactly the opposite
opinion. No shortage means no cause to game the system.
No gaming of the system means the transfer is requested
for
<br>
</blockquote>
</blockquote>
reasonable, pragmatic causes. Like avoiding renumbering
pain. Why should this be prevented?
<br>
<blockquote type="cite">
<br>
Because this is not a strong enough reason to allow IPV6
and 32-bit ASN be moved from one region to another.
Although there are costs to do renumbering
<br>
</blockquote>
this is part of the business and anyone in such situation
must be prepared to do so.
<br>
Respectfully, I think you have it backwards. We shouldn't
need a reason to allow something, we should need a reason to
prevent it. Maybe not a great reason
<br>
(that probably sets the bar too high) but at least a
plausible reason.
<br>
<blockquote type="cite">The type of scenario that is being
proposed here is not something that happens so frequently,
in some cases may be very specific and is not very
<br>
</blockquote>
productive to change such an important thing like allowing
IPv6 and 32-bits ASN to be moved between regions with the
impacts it causes in the whole global
<br>
registering system just to accomplish the need of a few
which have workable plausible option available. Therefore
the need of a few cannot overcome the
<br>
interest of the whole system.
<br>
Like what? What malfunctions or functions inefficiently if
with the receiving registry's consent we allow a registrant
to move their IPv6 addresses and AS
<br>
numbers from ARIN to a different registry?
<br>
Regards,
<br>
Bill Herrin
<br>
--
<br>
William Herrin
<br>
<a class="moz-txt-link-abbreviated" href="mailto:bill@herrin.us">bill@herrin.us</a>
<br>
<a class="moz-txt-link-freetext" href="https://bill.herrin.us/">https://bill.herrin.us/</a>
<br>
</blockquote>
_______________________________________________
<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>
</blockquote>
<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>
</body>
</html>