sub-/24 "delegation" [2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4)]
Dear DNS WG, people on this list might be interested in one aspect of the proposed policy <http://www.ripe.net/ripe/policies/proposals/2014-01>, <http://www.ripe.net/ripe/mail/archives/address-policy-wg/2014-March/008638.html>, when it comes to (sub-)allocations smaller than /24. Note that BCP10/RFC 2317 is not necessarily the or the only solution to the problem. Also, in the interest of keeping the policy discussion focused, we might want to strictly focus on the reverse mapping on this list and make sure some "sense of the room" as well as all other aspects get discussed on address-policy. -Peter (DNS WG co-chair) ----- Forwarded message from Tore Anderson <tore@fud.no> ----- From: Tore Anderson <tore@fud.no> To: Carsten Schiefner <ripe-wgs.cs@schiefner.de>, Rob Evans <rhe@nosc.ja.net> Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) Date: Thu, 27 Mar 2014 09:34:20 +0100 In-Reply-To: <5333CABF.1070609@schiefner.de> * Carsten Schiefner
No, not really. I feel this being only loosely coupled at best. My proposal enables the transfer of allocations of *all* sizes and the conversion of PI assignments of *all* sizes into allocations.
Whether sub-allocations can be made from *all* these (new) allocations or "just" from those being at least a /24 appears as a separate question to me. Even more so, as the the sub-allocation mechanism has been applied or used very rarely only so far.
And having the "one thing at a time" principle in mind: if this impossibility is of concern to the community, then this should maybe be handled by a separate policy (modification) proposal.
Hi Carsten, I'm just of the opinion that removing one without the other leaves the policy in a counter-intuitive state. To me it would appear appropriate for a proposal titled «Abandoning the Minimum Allocation Size for IPv4» to remove all flavours of the minimum allocation size, including the one specific for sub-allocations. Besides, one of the two stated reasons for having the minimum sub-allocation size («[/24] is the smallest prefix length that can be reverse delegated») is quite simply false, given RFC 2317, and if we also accept the rationale for 2014-01, then we've essentially rejected the other reason too («allows for a reasonable number of small assignments to be made»). So I'd ask you to consider removing that paragraph as well before going to review phase. Note that since we're still in the discussion phase, doing so doesn't have to slow down the progress of the proposal, you can go straight to review with updated proposal (modifications at a later stage are much more cumbersome). Just my €.02...your proposal, your call. ;) Tore ----- End forwarded message -----
Dear all,
people on this list might be interested in one aspect of the proposed policy <http://www.ripe.net/ripe/policies/proposals/2014-01>, <http://www.ripe.net/ripe/mail/archives/address-policy-wg/2014-March/008638.html>, when it comes to (sub-)allocations smaller than /24. Note that BCP10/RFC 2317 is not necessarily the or the only solution to the problem.
_Technically_ speaking, in my opinion BCP20/RFC2317 is an acceptable solution. It is a trade off: it increases the number of DNS queries, but it gives a large freedom and independence in managing the reverse address space. As I see it, in fact we are talking about three different cases: 1. allocations made by the NCC (5.1) 2. transfers (5.5) 3. possibly sub-allocations (5.4, still under consideration by Carsten, the author of the proposal) In accordance with BCP20, the "maintainer" of the /24 has to set up and _continue_to_provide_ DNS service in accordance with the RFC for an indefinite period of time to the "user" of the smaller address block. In case 1 above, the NCC can do it without any problems. In case 3, the sub-allocating LIR has strong ties to the other LIR, as it is responsible for the address space anyway. However, in case 2, i.e. in case of transfers, I see a possible problem, as otherwise a business relationship does not necessarily exist between the "seller" and the "buyer" of the address space, once the transfer is approved by the NCC and registered in the database. I think it would be a good idea to include this obligation to provide appropriate DNS services for an indefinite time (possibly for a fee) in the transfer contract itself. Anyway, if someone is asking for a fee for such a service, this will most probably be a further very good deterrent to asking for the transfer of such a small address space. :) Anyway, 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
Also, in the interest of keeping the policy discussion focused, we might want to strictly focus on the reverse mapping on this list and make sure some "sense of the room" as well as all other aspects get discussed on address-policy.
-Peter (DNS WG co-chair)
----- Forwarded message from Tore Anderson <tore@fud.no> -----
From: Tore Anderson <tore@fud.no> To: Carsten Schiefner <ripe-wgs.cs@schiefner.de>, Rob Evans <rhe@nosc.ja.net> Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) Date: Thu, 27 Mar 2014 09:34:20 +0100 In-Reply-To: <5333CABF.1070609@schiefner.de>
* Carsten Schiefner
No, not really. I feel this being only loosely coupled at best. My proposal enables the transfer of allocations of *all* sizes and the conversion of PI assignments of *all* sizes into allocations.
Whether sub-allocations can be made from *all* these (new) allocations or "just" from those being at least a /24 appears as a separate question to me. Even more so, as the the sub-allocation mechanism has been applied or used very rarely only so far.
And having the "one thing at a time" principle in mind: if this impossibility is of concern to the community, then this should maybe be handled by a separate policy (modification) proposal.
Hi Carsten,
I'm just of the opinion that removing one without the other leaves the policy in a counter-intuitive state. To me it would appear appropriate for a proposal titled «Abandoning the Minimum Allocation Size for IPv4» to remove all flavours of the minimum allocation size, including the one specific for sub-allocations.
Besides, one of the two stated reasons for having the minimum sub-allocation size («[/24] is the smallest prefix length that can be reverse delegated») is quite simply false, given RFC 2317, and if we also accept the rationale for 2014-01, then we've essentially rejected the other reason too («allows for a reasonable number of small assignments to be made»).
So I'd ask you to consider removing that paragraph as well before going to review phase. Note that since we're still in the discussion phase, doing so doesn't have to slow down the progress of the proposal, you can go straight to review with updated proposal (modifications at a later stage are much more cumbersome).
Just my €.02...your proposal, your call. ;)
Tore
----- End forwarded message -----
On 03/27/2014 02:58 AM, Janos Zsako wrote:
Dear all,
people on this list might be interested in one aspect of the proposed policy <http://www.ripe.net/ripe/policies/proposals/2014-01>, <http://www.ripe.net/ripe/mail/archives/address-policy-wg/2014-March/008638.html>,
when it comes to (sub-)allocations smaller than /24. Note that BCP10/RFC 2317 is not necessarily the or the only solution to the problem.
_Technically_ speaking, in my opinion BCP20/RFC2317 is an acceptable solution. It is a trade off: it increases the number of DNS queries,
It doesn't have to increase the number of DNS queries if the parent slaves the child's zone(s). The parent will have the answer for the first query that arrives from a given resolver, and the child will receive subsequent queries directly. Also see https://dougbarton.us/DNS/2317.html for more thoughts. :) hth, Doug
On Mar 27, 2014, at 12:39 PM, Doug Barton <dougb@dougbarton.us> wrote:
On 03/27/2014 02:58 AM, Janos Zsako wrote:
Dear all,
people on this list might be interested in one aspect of the proposed policy <http://www.ripe.net/ripe/policies/proposals/2014-01>, <http://www.ripe.net/ripe/mail/archives/address-policy-wg/2014-March/008638.html>,
when it comes to (sub-)allocations smaller than /24. Note that BCP10/RFC 2317 is not necessarily the or the only solution to the problem.
_Technically_ speaking, in my opinion BCP20/RFC2317 is an acceptable solution. It is a trade off: it increases the number of DNS queries,
It doesn't have to increase the number of DNS queries if the parent slaves the child's zone(s). The parent will have the answer for the first query that arrives from a given resolver, and the child will receive subsequent queries directly. Also see https://dougbarton.us/DNS/2317.html for more thoughts. :)
OOC, was any thought given to this approach? http://tools.ietf.org/html/draft-gersch-dnsop-revdns-cidr-01 IIRC, there is a treatise in that draft that relates its proposal to RFC 2317. Eric
Dear Eric,
OOC, was any thought given to this approach? http://tools.ietf.org/html/draft-gersch-dnsop-revdns-cidr-01
I may be wrong, but my understanding is that this I-D focuses on storing and retrieving information associated with a given (known) IP address range. Such information could be related to BGP routing, IRT and abuse, secure mail servers, etc. The problem I see here if you want to use this naming convention for "traditional" reverse queries is that you have to _know_ the address block you are trying to find information about, before starting the query. In case of a "traditional" reverse query for 192.168.1.1 for example, in order to use the above approach one would have to first query the RIR database (or perhaps some other place?) to find out the assignment the given IP address belongs to (e.g. 192.168.1.0/25) and _then_ we could query something like 1.0.m.1.168.192.in-addr.arpa. Did I misunderstand the I-D? Best regards, Janos
IIRC, there is a treatise in that draft that relates its proposal to RFC 2317.
Eric
participants (4)
-
Doug Barton -
Janos Zsako -
Osterweil, Eric -
Peter Koch