Hi, Jordi,
I do not agree with your points, and strongly oppose IPv6 transfers for
ARIN. Just because two RIR's have developed a policy to allow this is NOT
a good reason for ARIN to jump unto that bandwagon.
There are clear costs to allowing IPv6 transfers at ARIN. They include
development costs in changing the IT systems at ARIN, the costs of the
operation of that portion of the reverse DNS on behalf of people who are
NOT providing any revenue to ARIN as well as staff training.
Unlike with IPv4, there are NO legacy holders or others that are receiving
IPv6 DNS services from ARIN without payment of fees. Keeping each ARIN
/12 completely under the control of ARIN is best, and reduces the overall
cost of operation by not having to manage or train staff on transfers.
We would have no way to predict or limit the number of reverse queries of
portions of the ARIN reverse that are transfered to other RIR's.
Operations involving massive amounts of traffic might choose to move
to another RIR, leaving ARIN to have to increase circuit capacity or
otherwise manage that traffic for free. By not allowing transfers of IPv6
resources, all traffic is 100% paid for by ARIN fees.
I also see this as forum shopping. However if forum shopping is allowed,
it will be the RIR with the best policies and lowest costs who will win
that battle. If that battle has to happen, I would like ARIN to be the
winner, by having policies that keep costs low, and fixing any issues with
the reverse PKI systems that have been identified.
There is also the idea of "KISS". By keeping it simple, we know all
traffic in the ARIN /12's are managed by ARIN, and we do not have to deal
with many of the "hacks" that have affected IPv4.
While CIDR, NAT, RIR and Directed Transfers have gone a long way to extend
the life of IPv4, IPv6 does not have the shortage of address space to
require the use of any of these things. IPv6 has the promise of bringing
back the original end to end of each host on the original ARPAnet. Also,
when numbers are transfered, would the RIR have to transfer the reserve
space provided by sparse allocation to the receiving RIR? If not, this
will cause fragmented routes when the holders of the transfered space have
to expand.
As for future ideas, I would like to see a renumbering requirement into a
larger single block when a member expands their IPv6 space beyond the
reserved space, so that each member holds but a single block of IPv6.
I believe that all costs of an RIR change should be borne by the party
wishing to transfer. The proposal would require ARIN to develop processes
paid for by all solely for the benefit of those few that want to avold
renumbering and pass these costs to all members. I think this is wrong.
If it is thought that transfers are a good idea, maybe some kind of yearly
fee for reverse DNS needs to be assessed to compensate ARIN for its
efforts.
Also, I honestly doubt that these players that claim to want to move their
home office without renumbering are actually doing so because of the
downtime associated with a true hot cut. I think that in most cases,
although they are keeping their original IPv6 numbers and moving them
between RIPE and APNIC, I strongly suspect that individual hosts being
moved are being renumbered to different /64's within their block when they
move from LAN to LAN to avoid downtime. If they can do this, they
certainly can instead renumber to a new block at ARIN or whatever RIR they
are desiring to move to. Of course, there is nothing to prevent those
desiring to move RIR's from maintaining numbers in more than one RIR while
the movement of hosts takes place.
Does anyone have any stats as to what percentage of the total members of
RIPE or APNIC have in fact moved their IPv6 from one RIR to the other? I
strongly suspect it is less than one percent. If so, that is grossly
unfair for such a small number of those transfering their numbers to
be able to spread that transfer cost across the entire membership of
those two RIR's. While APNIC and RIPE might agree to this pass on of
costs to its members, I do not think that ARIN should do the same.
Albert Erdmann
Network Administrator
Paradise On Line Inc.
On Wed, 17 Jul 2019, JORDI PALET MARTINEZ via ARIN-PPML wrote:
Hi Jimmy,
The cost of doing all that has been done already for IPv4 and by other RIRs.
It is one-time development cost anyway (to adapt the changes to IPv6), so not a
giant effort. And by the way, it has been done already to allow that working
among RIPE and APNIC, and I believe there is plenty of cooperation among RIRs
in order to share developments, engineering, knowledge and so on.
Furthermore, there is not such human resources cost as all those proceses, as
every policy implementation in any RIR, become automated.
Regarding the cost of a member "leaving" ARIN membership, it is comparable to
the reverse case, when a RIPE or APNIC member moves to ARIN. This is something that we
need to live with, but is part of the set of services that the RIRs offer, to a global
community, not just to a specific region.
Consequently, I don't think this is a valid argument to object to this proposal.
Regards,
Jordi
@jordipalet
El 17/7/19 22:17, "ARIN-PPML en nombre de Jimmy Hess" <arin-ppml-boun...@arin.net
en nombre de mysi...@gmail.com> escribió:
On Mon, Jul 15, 2019 at 11:37 PM Job Snijders <j...@ntt.net> wrote:
> Even if inter-RIR transfers were permitted, ARIN would still
> operationally be responsible for all delegations under the
> "0.6.2.ip6.arpa." zone. So, no issue there.
[snip]
No.... that is exactly one potential issue. An entity wishing to move
their networks around ought to bear costs of their moves; the RIR
such as ARIN should not be subsidizing an entity's choice to move
out of region and continue to keep everything nice and convenient for
that resource holder by incurring extra costs against the fees paid by
other still-in-region members to help facilitate the operations of some
small number of 'wanting to move out' resource holders; This
is not in the interests of the regional community whom its ARIN's
mission to serve to be in a position of continuing to provide
a Reverse DNS service to the entity that moved out after they
are no longer an ARIN customer, And "fragmenting" in this
manner is exactly what this forces upon ARIN.
The kind of Reverse DNS Zone that is simplest for RIRs to have
software, systems, and process to manage -- is one where all the
NS delegations are predictable and match up exactly with database
entries created by customers linked to a direct allocation or assignment.
And the requirement to maintain additional, extra nameserver delegations
for "transferred blocks" means designing, developing, or maintaining,
systems, algorithms, and management processes which involve
more ARIN staff time being used to operate, and a
greater minimum complexity than the simplest form
(which would meet the simpler requirements of each delegation
maintained by an ARIN customer).
Aside from the administrative burden that ARIN now would have to
maintain an entirely additional set of delegations and database entries
which are for out-of-region usage on transferred out V6 space, and
have processes and people to update these entries from time to time:
when the end user's downstream nameserver addresses change.
To keep such a transfer in effect and reverse DNS working properly:
ARIN (and therefore other ARIN members) would effectively have to
also bear an ongoing cost on behalf of the foreign registrant in perpetuity
without compensation for the services, because that organization will
be cancelling their relationship with ARIN and/or no longer be paying
any maintenance fee for that block of addresses.
Meanwhile.... ARIN continues to have to maintain DNS servers with
computational and bandwidth resources allocated
to answering queries that come for the reverse DNS range of THAT block
transferred out and maintaining a set of nameserver delegations in the
reverse DNS zone for the "transferred out" address block in order to do so.
And the VOLUME (total number of reverse DNS queries per day) per
block varies with the usage of that block, size, etc,
so it is non-predictable.
ARIN likely needs that entity as a customer while delegating reverse
DNS to them,
in order to be be able to charge maintenance fees to compensate ARIN for
costs of providing the service of answering the reverse DNS
Nameserver queries.
--
-JH
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.
**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company
This electronic message contains information which may be privileged or
confidential. The information is intended to be for the exclusive use of the
individual(s) named above and further non-explicilty authorized disclosure,
copying, distribution or use of the contents of this information, even if
partially, including attached files, is strictly prohibited and will be
considered a criminal offense. If you are not the intended recipient be aware
that any disclosure, copying, distribution or use of the contents of this
information, even if partially, including attached files, is strictly
prohibited, will be considered a criminal offense, so you must reply to the
original sender to inform about this communication and delete it.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.
_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.
