[address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4)
- Previous message (by thread): [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4)
- Next message (by thread): [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Janos Zsako
zsako at iszt.hu
Fri Mar 28 14:59:51 CET 2014
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 > >
- Previous message (by thread): [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4)
- Next message (by thread): [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]