Would this proposal allow end users to request the transfer of a single IPv4 /32? Or is that prevented by RIPE requiring parties to a transfer to be LIRs? I am less worried about LIRs doing something stupid, but if it were allowed, I would guess that some end users would attempt to use /32 transfers the same way they use phone number portability. IMO it might be better to preserve some sort of minimum transfer size. Dropping it to a /24 (or farther) would make sense to me. Going all the way to /32 seems unnecessary and a bit risky, unless there are other good safeguards in place to ensure that any entities transferring a /32 are really in a position to route it themselves, and aren't just trying to impose the routing externality on the rest of the global table (and blaming someone else when their IPv4 /32 announcement isn't accepted everywhere). -Scott On Mon, Mar 24, 2014 at 7:12 AM, Elvis Velea <elvis@velea.eu> wrote:

Hi Rob,

I was just about to make the same comments :)

I support the proposal although I would have proposed a minimum /24 (as it is in the other regions).

However, leaving the decision in the hands of the operators sounds good as well.

cheers, elvis

On 24/03/14 16:05, Rob Evans wrote:

...

http://www.ripe.net/ripe/policies/proposals/2014-01

...

Overall I think this is a good thing, but I wonder if there is a reason for leaving 5.4 (minimum sub-allocation size) as-is?

If we open the door to transfer prefixes smaller than a /24, should sub-allocation of them be prevented?

The routing side of me, of course, might consider the alternative of clamping the transfers at /24 too, but perhaps that should just be left for consenting adults to negotiate between themselves.

Cheers, Rob

On Mar 24, 2014, at 2:29 PM, Gert Doering <gert@space.net> wrote:

Hi,

On Mon, Mar 24, 2014 at 11:24:31AM -0700, Scott Leibrand wrote:

...

Would this proposal allow end users to request the transfer of a single IPv4 /32?

Technically, yes, if a) we permit PI transfers (proposal in the works), and b) the RIPE NCC has given out a /32 PI.

End users reciving PA space have no transfer rights whatsoever, that space can only transfered by the PA holder (= the LIR).

I'm generally in support of this proposal as-is, at this time. Best, -M<

On 27.03.2014 07:52, Carsten Schiefner wrote:

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.

"... according to figures I have received from the RIPE NCC wrt. this." I should have added here. Best, -C.

On 27/03/14 10:34, Tore Anderson wrote:

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

+1 cheers, elvis -- <http://v4escrow.net> Elvis Daniel Velea Chief Business Analyst Email: elvis@V4Escrow.net <mailto:elvis@v4escrow.net> US Phone: +1 (702) 475 5914 EU Phone: +3 (161) 458 1914 Recognised IPv4 Broker/Facilitator in: This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited.

Hi, On Thu, Mar 27, 2014 at 10:07:53AM +0100, Carsten Schiefner wrote:

True - although it doesn't seem to be me moving it straight to the review phase, but the WG (Co-)Chair(s) - i.e. Gert and/or Sander.

Well, at the end of discussion phase, you, sander and me conspire to decide what to do next - "more discussion", "go forward as is" or "change text and go forward". You're the proposer, so you have a say in this ;-) Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

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

+1 If we're removing the min allocation size parameter it would be inconsistent to have a limitation on sub-allocation. I doubt there'd be many uses for a sub-allocation smaller than /24, but as Tore outline there doesn't seem much benefit of having this constraint. We should aim towards less arbitrary restrictions in policy. Rgds, James -----Original Message----- From: address-policy-wg-bounces@ripe.net [mailto:address-policy-wg-bounces@ripe.net] On Behalf Of Tore Anderson Sent: 27 March 2014 09:34 To: Carsten Schiefner; Rob Evans Cc: address-policy-wg@ripe.net Subject: Re: [address-policy-wg] 2014-01 New Policy Proposal (Abandoning the Minimum Allocation Size for IPv4) * 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

Dear all,

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

Well, technically speaking this is obviously feasible. However, as I pointed it out on the DSN WG mailing list, in case of transfers, where the "buyer" normally does not wish to have any further business relationship with the "seller" once the transfer is completed, this solution may be unattractive. The fact that the "seller" has to provide appropriate DNS services (i.e. in accordance with BCP20/RFC2317) to the "buyer" for an _indefinite_ period of time, is probably one more deterrent to transferring such a small amount of addresses. As the remark above was related to sub-allocations (not yet covered by the proposed policy), I feel the obligation to provide appropriate DNS service is less of a problem, as the sub-allocating LIR will have a tight relationship with the other LIR, since the former will remain responsible for the address space anyway.

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

Indeed, the two stated reasons for needing a minimum sub-allocation size are not convincing at all. At the same time, I agree with Carsten that this issue is orthogonal to the minimum allocation problem: we could simply drop the minimum sub-allocation size requirement without affecting the minimum allocation size in any way. Also, dropping the minimum allocation size requirement does not necessarily imply that we have to ignore the minimum sub-allocation size. BTW: dropping the minimum allocation size for NCC allocations is in a way already approved in case of free address pool exhaustion (see last paragraph of 5.1: "In case an allocation of a single /22 as per clause 1 can no longer be made, multiple allocations up to an equivalent of a /22 in address space will be made to fulfill a request.").

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

I think this is a sensible approach. As far as the 2014-01 policy is concerned, as I pointed out above, its first part (5.1) is already approved: if we remove that sentence, this has an influence only on the transfers (part 2 of the proposal, 5.5 of ripe-606). I think the main argument against allowing transfers smaller than /22 is most probably the fear from fragmentation and routing table explosion. This does not affect certification significantly (not more than it affects routing), as the number of Subscribers will not increase (the receiving party - or "buyer" as I called them above - has to be an LIR already), just the number of allocations signed. The main argument in favour of dropping this barrier in my view is that probably such transfers will happen anyway and it would be good to be able to keep the registry records accurate. Therefore, I support this proposal (with or without involving the minimum sub-allocation size as well). Best regards, Janos

Just my €.02...your proposal, your call. ;)

Tore

Dear Tore,

...

Well, technically speaking this is obviously feasible. However, as I pointed it out on the DSN WG mailing list, in case of transfers, where the "buyer" normally does not wish to have any further business relationship with the "seller" once the transfer is completed, this solution may be unattractive. The fact that the "seller" has to provide appropriate DNS services (i.e. in accordance with BCP20/RFC2317) to the "buyer" for an _indefinite_ period of time, is probably one more deterrent to transferring such a small amount of addresses.

I think it would be reasonable to expect that if 2014-01 passes, the NCC will respond by allowing direct classless delegation of PA blocks, just like is already done for PI. If so, what you're describing here shouldn't be a problem.

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@ripe.net" 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. Best regards, Janos

Tore

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

Hi,

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.

I think the first one is appropriate. If the NCC doesn't allocate the whole /16 to one organisation they cannot create a reverse delegation for it to that single organisation. They can't delegate reverse DNS to an organisation that doesn't hold that address space... So the technically correct solution is to do what you suggest first. It isn't pretty, and it would make address holders think twice before carving out a small portion of their address space to sell, but that might be a good thing :) I'll leave that for the the WG to discuss :) Cheers, Sander

Dear Sander,

...

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.

Euhm, no... For example: if an LIR has a /21 and permanently transfers a /25 to another organisation then the resulting situation would be: - The LIR now has multiple smaller allocations: a /22, /23, /24 and /25. So the reverse delegation would be for 7x /24 and the /25 would be delegated according to BCP20/RFC2317 - The other organisation would have a /25 and get BCP20/RFC2317stuff too

Once a /25 is transferred the original allocation changes and the NCC cannot delegate the reverse for the whole /24 that contains the /25 to the LIR. It's not the LIR's address space anymore.

You are right. Basically what you are saying, the NCC would not approve the transfer as long as the above is not solved. I am wondering whether this is (or should be) enforced in case of transfers out of a /16 allocation. Best regards, Janos

Cheers, Sander

Dear all,

...

I am wondering whether this is (or should be) enforced in case of transfers out of a /16 allocation.

Why not? It is an issue for any delegation that is not on a multiple of 8 bits (/8, /16 and /24). We currently already have reverse tree delegations of multiple /24s for those that have an allocation from a /17 to a /25. That isn't new. The only new part would be to re-organise some parts of the tree before transferring the corresponding address space.

Just out of curiosity I checked the transfers that resulted in the split of a /16. It seems it is already part of the procedures to revoke the reverse delegation upon transfer. Out of 19 such transfers only 3, mostly older ones, did still have the delegation. Best regards, Janos

Cheers, Sander