Thanks Albert for such a comprehensive explanation and for going over
something that certainly most people understand well so didactically and
covering that "objection" completely.
I support that this fracturing of the reverse DNS is something
unnecessary and at the cost of not having to renumber. The correct path
in my view is the company request space in another RIR where it is
moving to and renumber with time and plan. Keep it Simpler.
Fernando
On 16/07/2019 00:17, hostmas...@uneedus.com wrote:
I will take a stab at what this means.
I am choosing the block containing my IPv6 addresses as an example. If
you go to the ARIN whois site and look up network NET6-2600, you will
see that this network range is 2600:: to
260f:ffff:ffff:ffff:ffff:ffff:ffff:ffff. This network is otherwise
stated as 2600::/12., and shows that it is assigned to ARIN by IANA.
IANA always assigns blocks of IPv6 addresses to RIR's in /12 blocks.
A link to this is https://whois.arin.net/rest/net/NET6-2600-1
This means the ENTIRE BLOCK has been assigned to ARIN, and therefore
ARIN controls the reverse DNS of this entire block.
ARIN allocates portions of this block to LIR's or ISP's and provides a
pointer to the DNS servers designated by the entities that have been
allocated the IPv6 blocks contained within the larger /12 block.
If RIR transfers were permitted, ARIN would have to give control of
the transfered addresses within this block to the RIR(s) involved and
would no longer control the entire block. PKI also follows from top to
bottom and may not work properly if portions of the block are assigned
to different RIR(s).
More generically, I would call this "ARIN giving up control of
portions of the Reverse DNS zones to another RIR." It breaks the
block apart, thus the poster's term "fracturing".
I believe that ARIN should maintain control of 100% of each IPv6 block
that it receives from IANA. I can understand the term "fracturing"
being used to describe what would happen to IPv6 blocks received from
IANA, if ARIN gave up control of specific addresses contained within
that block to another RIR. If someone wants to receive IPv6 addresses
from another RIR, I believe that they need to renumber into a block
belonging to that RIR.
Generally ARIN (and other RIR's) use what is called "sparse
allocation" when allocating IPv6 blocks. This means that addresses
before and after each allocation are left vacant, so that a specific
allocation can be made larger without having to allocate more than one
block of addresses, controlling the growth of the routing tables.
Instead, the existing block is made larger. For example a /35 might
be expanded to a /32, and this was done when the policy was changed to
allocate ISP's a /32 by default, and this way the addresses continue
to remain in a single block of a larger size.
Albert Erdmann
Network Administrator
Paradise On Line Inc.
On Tue, 16 Jul 2019, Job Snijders wrote:
Dear Fernando,
On Mon, Jul 15, 2019 at 08:13:12PM -0300, Fernando Frediani wrote:
I will comment only in one of the points, the other I believe are
really well explained by others and it doesn't seem good to 'rain on
the wet floor'.
I'm sorry but I don't think we can skip over some of these "objections"
without further substantiation on what the terminology actually means.
The term "fracturing the Reverse DNS zone" was coined just a few hours
ago and I don't think most people have any idea what it means. At least
I don't! :-)
I googled the term "fractured DNS", and from what I understand it is a
term used in context of alternative DNS roots (DNS roots other than
the ICANN/IANA root most of us use). I fail to see what "fractured DNS"
might mean in our current context of inter-RIR IPv6 transfers.
Kind regards,
Job
_______________________________________________
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.
_______________________________________________
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.