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

Dear Tore,

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

Thank you for the detailed example. I now understand what you are saying.

The problem is that this does not work with allocations larger than
a /16. In this case the /16 is usually already delegated to the LIR.

An analogy with your example would be that 47.185.in-addr.arpa is already
delegated to you.

In this case the NCC could not insert the 0-127.43.47.185.in-addr.arpa
delegation in the 185.in-addr.arpa zone.

I see two solutions to this:

- the NCC "revokes" the /16 delegation and replaces it with 255 /24
delegations, and two /25 delegations
- you delegate 43.47.185.in-addr.arpa back to the NCC

Neither of them is appropriate in my view.

By the way, as I pointed it out on the DNS WG list, I think this
obligation to provide appropriate DNS services for an indefinite
time is not necessarily specific to address space smaller than a /24,
as any transfer smaller than a /16 out of an allocation of at least
a /16 has a somewhat similar problem.

Best regards,
Janos

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