[address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4)

Hi Janos,

> I think you refer to the following statement from the LIR handbook:
> "The RIPE NCC will directly reverse delegate to zones smaller than /24
> which are Provider Independent (PI) and do not originate from an LIR's PA
> allocation. If this applies or questions arise, please contact:
> ripe-dbm at ripe.net"

Yes, exactly.

Also see:
http://www.ripe.net/data-tools/dns/reverse-dns/how-to-set-up-reverse-delegation

> However, I think this is not an administrative question (i.e. the question
> is not whether the NCC allows it or not).
> 
> In case of PI, the "surrounding" address space is also managed by the
> RIPE NCC, so they do have the possibility to set up a scheme similar to
> the one specified in BCP20/RFC2317.
> 
> In case of a transfer out of an LIR allocation, the "surrounding" space
> is allocated to the "selling" LIR, so they are the ones who _can_ set up
> the reverse delegation.
> 
> Alternatively, the transfer policy could require that in such a case the
> "surrounding" /24 has to be delegated to the RIPE NCC, who will manage
> this address space in a neutral way for an indefinite period of time.
> This would, however, have an impact on RIPE NCC operations, and I do not
> think I would support such a proposal.

Maybe I am being dense, but I am really struggling to understand your
concern. After all the surrounding address space is already delegated to
the RIPE NCC's name servers, which then sub-delegate based on the domain
objects the resource holder inserts into the database. So I don't see
how this proposal would have an impact on RIPE NCC operations in this
regard (beyond the one-time job of permitting classless delegation for
PA space in the same way as for PI).

Let me try to explain my understanding of things by example...

185.47.43.0/24 is part of an ALLOCATED PA delegation from the RIPE NCC
to my LIR. When it comes to reverse DNS, the allocation chain goes like
this, starting from the root:

.                                NS  [a-m].root-servers.net.
in-addr.arpa.                    NS  [a-f].in-addr-servers.arpa.
185.in-addr.arpa.                NS  pri.authdns.ripe.net. (+slaves)
43.47.185.in-addr.arpa.          NS  ns-{foo,bar,baz}.linpro.net. (mine)

[The NS records for "40.47.185.in-addr.arpa." happens to be there
because I've inserted the corresponding object into the RIPE database
and it's based on those objects the RIPE NCC generates the
"185.in-addr.arpa" zone.]

Let's now assume that you and I agree that 185.47.43.128/25 should be
transferred to your LIR. I would then expect that the delegation chain
would part ways in the 185.in-addr.arpa sone, like so for my /25:

.                                NS  [a-m].root-servers.net.
in-addr.arpa.                    NS  [a-f].in-addr-servers.arpa.
185.in-addr.arpa.                NS  pri.authdns.ripe.net. (+slaves)
0-127.43.47.185.in-addr.arpa.    NS  ns-{foo,bar,baz}.linpro.net. (mine)

..and like so for your /25:

.                                NS  [a-m].root-servers.net.
in-addr.arpa.                    NS  [a-f].in-addr-servers.arpa.
185.in-addr.arpa.                NS  pri.authdns.ripe.net. (+slaves)
128-255.43.47.185.in-addr.arpa.  NS  ns*.iszt.hu (yours)

[As before, we would of course both need to insert appropriate domain
objects into the RIPE database for the final delegation to our own
authoritative name servers to show up in the 185.in-addr.arpa zone.]

Even though I would be the "selling" LIR here, I do not understand why I
would be required to play a part in delegating reverse DNS for the /25
you "bought" for an infinite period of time (or any period of time at
all for that matter). What am I missing here?

Tore