[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 ]
Tore Anderson
tore at fud.no
Fri Mar 28 12:49:04 CET 2014
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
- 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 ]