June 2014 - address-policy-wg

2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources)
by sandrabrown＠ipv4marketgroup.com 17 Sep '14

17 Sep '14

Tore, Thanks for your feedback. See below for comments. From: Tore Anderson <tore(a)fud.no> Subject: Re: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources) To: address-policy-wg(a)ripe.net Message-ID: <53A7ECB6.60108(a)fud.no> Content-Type: text/plain; charset=ISO-8859-1 I like it, overall. Clearly there are a few who are interested in engaging in inter-RIR transfers, and if we can facilitate for this without imposing any cost or burden on those who are not interested, I can see no reason to not do this. With regards to the proposals second argument against (regarding the re-introduction of "need" if another RIR insists), I do not consider that to be problematic at all, as it would be a burden that would be borne in its entirety by the entity voluntarily taking part in a transfer involving a "needy" RIR. I have some comments/suggested improvements though: 1) I concur with other posters that the use of ?LIR? should be avoided. However, I'd also like to add that suggested replacement ?organisation? could potentially also be problematic, as a resource holder could be a natural person rather than an organisation. It would be preferable to avoid getting in a situation where non-organsation resource holders would be prevented from engaging in inter-RIR transfers even though the resource-specific policy would allow for that. Therefore I would suggest using even more general language, such as ?resource holder?/?resource holder to be? or ?entity?. **** I think this is a very good point, thanks. Sandra 2) The proposal seeks to add the following paragraphs to ripe-606 section 5.5: ?When Internet number resources are transferred to another RIR, the RIPE NCC will work with the destination RIR to allow the transfer to the receiving LIR. When Internet number resources are transferred from another RIR, the RIPE NCC will work with its member LIR to fulfil any requirements of the sending RIR.? These additions seem completely redundant to me, as the new policy document says pretty much the same thing in sections 2.0 and 3.0. (Also, ?fulfill? is incorrectly spelled.) *** Thanks for pointing out this redundancy issue. *** Let me look into it with Marco and the Chairs, as to whether we *** would add the text or were making a statement of fact. *** Agree on spelling of fulfill. Thanks. Sandra 3) Also in ripe-606 section 5.5 the proposal seeks to add the following: ?If resources are transferred as legacy resources, the RIPE NCC will apply the legacy policy when accepting these resources.? This statement seems out of place to me: * ripe-606 does not apply to legacy resources, a fact which is implied by the new paragraph as well. The statement therefore voids itself. * Even if disregarding the above, ripe-606 only covers IPv4. Legacy resources also include ASNs. So if the resource is to be transferred is a legacy ASN, this transfer would be regulated by a piece of policy text located in the non-legacy IPv4 policy....which would to me be a completely nonsensical outcome. IMHO, the only sensible place to locate a statement that essentially says "legacy resources are governed by the legacy policy" is in, you guessed it, the legacy policy itself (ripe-605). We're in luck, because it already does just that. :-) *** I am not sure we will add that statement to the policy or if it is *** just a statement of fact: that legacy policy will apply, as you say. *** Let me check with Marco, as what you say makes total sense to *** me. Sandra So in summary, all of the additions 2014-05 seeks to do in ripe-605 seem redundant or out of place to me, accomplishing no actual policy change beyond adding bloat. Am I missing something? If not, I'd much rather prefer that ripe-605 is left alone by 2014-05. *** Yes the intention is not to add bloat but perhaps to re-confirm what *** is already there. Thanks a ton for your feedback, and of course for *** your support for the intent. *** Sandra Tore End of address-policy-wg Digest, Vol 34, Issue 15 *************************************************

3 2

About the /22 allocation limitation
by Dpto. Datos Television Costa Blanca 17 Jul '14

17 Jul '14

Hi Everyone, First of all, my name is Daniel and Im the Network Administrator of the AS199952 Im new to the address policy wg and Im sure you can answer the question. The /22 allocation restriction to new LIRs are only for new LIRs or for all LIRs? We only got a /22 as new LIR, and we cant ask for more IPs, proving we need it or not. I know, this is a recursive discussion, but I wonder if old LIRs can ask for more IPs or they are restricted as new LIRs are. For all people who are going to say "Move to IPv6" I already did it. About 75% of my network is IPv6 ready. 100% of our backbone network is IPv6 but, as all of you can see, only 18% of the World ASes are IPv6 ( http://v6asns.ripe.net/v/6?s=_ALL;s=_RIR_APNIC;s=_RIR_AfriNIC;s=_RIR_ARIN;s… ) and IPv6 wont work for anybody if the rest of the world isnt IPv6 ready. To be honest, I think IPv6 will not be ready before lot of us (new lirs)run out of IPv4 address while old LIRs have thousands and thousands of unused IP address and they sell them for really expensive price. I saw one in the listing service asking for at least 2 digits per IP... 2 digits! for something they got for free in the past. Again, I know, IPv4 is exhausted but this cant be used for making lot and fast money from new LIRs that only have /22 allocation and need more. I wonder if a change proposal of the policy to allow to ask for more IPs, of course proving the use of the ones you already have, and only giving /24's would be accepted by the community or I will get flamed for making the proposal. Please, feel free to discuss about this if you are going to say something usefull. PS: Sorry about my english, if I didnt explained well about something, just tell me. I will not feel offended. Kind Regards, -- Daniel Baeza Centro de Observación de Red Dpto. Internet y Telefonía Television Costa Blanca S.L. Telf. 966190565 WEB: http://www.tvt.es Correo: datos(a)tvt-datos.es --AVISO LEGAL-- En cumplimiento de la Ley Orgánica 15/1999, de 13 de diciembre de protección de datos de carácter personal, se pone en conocimiento del destinatario del presente correo electrónico, que los datos incluidos en este mensaje, están dirigidos exclusivamente al citado destinatario cuyo nombre aparece en el encabezamiento, por lo que si usted no es la persona interesada rogamos nos comunique el error de envío y se abstenga de realizar copias del mensaje o de los datos contenidos en el mismo o remitirlo o entregarlo a otra persona, procediendo a borrarlo de inmediato. Asimismo le informamos que sus datos de correo han quedado incluidos en nuestra base de datos a fin de dirigirle, por este medio, comunicaciones comerciales, profesionales e informativas y que usted dispone de los derechos de acceso, rectificación, cancelación y especificación de los mismos, derechos que podrá hacer efectivos dirigiéndose a Televisión Costa Blanca, S.L., C/ San Policarpo 41 Bajo. C.P: 03181 Torrevieja (Alicante).

25 112

why-pi question still in request form after 2011-02 acceptance?
by Daniel Roesen 26 Jun '14

26 Jun '14

Hi, could someone explain the rationale that the "why-pi" question is still in the IPv6 PI request form? Given that since acceptance and implementation of 2011-02 there are no special requirements attached to IPv6 PI anymore (other than the bureaucracy), I see absolutely no point in having people explain "why PA address space cannot be used for this assignment". The obvious, totally acceptable yet completely superfluous answer would be "because PA is not provider independent". I'd suggest to simply remove this "why-pi" question from the request form and supporting notes. :-) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr(a)cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

3 2

Re: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources)
by Tore Anderson 23 Jun '14

23 Jun '14

* Marco Schmidt > We encourage you to review this proposal and send your comments to > <address-policy-wg(a)ripe.net> before 2 July 2014. I like it, overall. Clearly there are a few who are interested in engaging in inter-RIR transfers, and if we can facilitate for this without imposing any cost or burden on those who are not interested, I can see no reason to not do this. With regards to the proposals second argument against (regarding the re-introduction of "need" if another RIR insists), I do not consider that to be problematic at all, as it would be a burden that would be borne in its entirety by the entity voluntarily taking part in a transfer involving a "needy" RIR. I have some comments/suggested improvements though: 1) I concur with other posters that the use of «LIR» should be avoided. However, I'd also like to add that suggested replacement «organisation» could potentially also be problematic, as a resource holder could be a natural person rather than an organisation. It would be preferable to avoid getting in a situation where non-organsation resource holders would be prevented from engaging in inter-RIR transfers even though the resource-specific policy would allow for that. Therefore I would suggest using even more general language, such as «resource holder»/«resource holder to be» or «entity». 2) The proposal seeks to add the following paragraphs to ripe-606 section 5.5: «When Internet number resources are transferred to another RIR, the RIPE NCC will work with the destination RIR to allow the transfer to the receiving LIR. When Internet number resources are transferred from another RIR, the RIPE NCC will work with its member LIR to fulfil any requirements of the sending RIR.» These additions seem completely redundant to me, as the new policy document says pretty much the same thing in sections 2.0 and 3.0. (Also, «fulfill» is incorrectly spelled.) 3) Also in ripe-606 section 5.5 the proposal seeks to add the following: «If resources are transferred as legacy resources, the RIPE NCC will apply the legacy policy when accepting these resources.» This statement seems out of place to me: * ripe-606 does not apply to legacy resources, a fact which is implied by the new paragraph as well. The statement therefore voids itself. * Even if disregarding the above, ripe-606 only covers IPv4. Legacy resources also include ASNs. So if the resource is to be transferred is a legacy ASN, this transfer would be regulated by a piece of policy text located in the non-legacy IPv4 policy....which would to me be a completely nonsensical outcome. IMHO, the only sensible place to locate a statement that essentially says "legacy resources are governed by the legacy policy" is in, you guessed it, the legacy policy itself (ripe-605). We're in luck, because it already does just that. :-) So in summary, all of the additions 2014-05 seeks to do in ripe-605 seem redundant or out of place to me, accomplishing no actual policy change beyond adding bloat. Am I missing something? If not, I'd much rather prefer that ripe-605 is left alone by 2014-05. Tore

1 0

Going to last call: 2014-01 (Abandoning the Minimum Allocation Size for IPv4)
by Sander Steffann 17 Jun '14

17 Jun '14

Dear working group, The working group chairs have decided to send policy proposal 2014-01, Abandoning the Minimum Allocation Size for IPv4, to Last Call. During the discussion phase there was already general support for this policy proposal. Some people asked for the minimum size of sub-allocations too be included in this policy proposal as well. This was done in version 2 of the proposal text. After going to the review phase the feedback was all positive, with 8 people explicitly stating their support: - Tore Anderson - Jan Ingvoldstad - Piotr Strzyzewski - Sascha Luck - Jens Ott - George Giannousopoulos - Andreas Larsen - Sebastian Wiesinger The announcement of the start of the review phase was sent out on the 15th of May, and all messages indicating support came in immediately after. Since then the mailing list has been quiet about 2014-01, which we see as a sign of consensus. The formal Last Call announcement will be sent to the appropriate lists by our incredibly helpful PDO, Marco Schmidt. Cheers, Gert and Sander Your APWG chairs

5 4

2014-01 Last Call for Comments (Abandoning the Minimum Allocation Size for IPv4)
by Marco Schmidt 16 Jun '14

16 Jun '14

Dear colleagues, The proposal described in 2014-01, "Abandoning the Minimum Allocation Size for IPv4", is now in its Concluding Phase. The Address Policy Working Group co-Chairs have declared that consensus for the proposal has been reached and it will now move to Last Call. As per the RIPE Policy Development Process (PDP), the purpose of these coming four weeks of Last Call is to give the community the opportunity to present well-justified objections in case anyone missed the previous two phases and want to oppose the proposal. Any objection must be made by 15 July 2014 and must be supported by an explanation. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2014-01 Please e-mail any final comments about this proposal to address-policy-wg(a)ripe.net before 15 July 2014. Regards Marco Schmidt Policy Development Officer RIPE NCC

1 0

Re: [address-policy-wg] address-policy-wg Digest, Vol 34, Issue 10
by Lu 10 Jun '14

10 Jun '14

+1 This transmission is intended solely for the addressee(s) shown above. It may contain information that is privileged, confidential or otherwise protected from disclosure. Any review, dissemination or use of this transmission or its contents by persons other than the intended addressee(s) is strictly prohibited. If you have received this transmission in error, please notify this office immediately and e-mail the original at the sender's address above by replying to this message and including the text of the transmission received. > On 2014年6月10日, at 下午12:00, address-policy-wg-request(a)ripe.net wrote: > > Send address-policy-wg mailing list submissions to > address-policy-wg(a)ripe.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://www.ripe.net/mailman/listinfo/address-policy-wg > or, via email, send a message with subject or body 'help' to > address-policy-wg-request(a)ripe.net > > You can reach the person managing the list at > address-policy-wg-owner(a)ripe.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of address-policy-wg digest..." > > > Today's Topics: > > 1. Re: Re-issue of reclaimed 16bit ASNs and modifications to > references in routing policy to these resources (Nick Hilliard) > 2. Re: Re-issue of reclaimed 16bit ASNs and modifications to > references in routing policy to these resources (Dimitri I Sidelnikov) > 3. Re: Re-issue of reclaimed 16bit ASNs and modifications to > references in routing policy to these resources > (Jens Ott - Opteamax GmbH) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 09 Jun 2014 15:40:52 +0100 > From: Nick Hilliard <nick(a)inex.ie> > Subject: Re: [address-policy-wg] Re-issue of reclaimed 16bit ASNs and > modifications to references in routing policy to these resources > To: Hank Nussbacher <hank(a)efes.iucc.ac.il>, Jo?o Damas > <joao(a)bondis.org>, routing-wg(a)ripe.net, address-policy-wg(a)ripe.net > Message-ID: <5395C774.2040403(a)inex.ie> > Content-Type: text/plain; charset=ISO-8859-1 > >> On 09/06/2014 14:53, Hank Nussbacher wrote: >> On a related matter, is it possible currently to setup my aut-num that if >> anyone adds my autnum to their import/export/as-set objects I would receive >> a notification about it? Currently the "notify" field only informs me of >> changes to the specific aut-num, not people who reference my aut-num w/o my >> permission? > > +1 > > I'd also like to see when someone includes my autnums or as-sets in their > as-sets. This has clobbered me in the past with highly unwelcome changes > to production traffic flows. > > Nick > > > > > ------------------------------ > > Message: 2 > Date: Mon, 09 Jun 2014 21:05:39 +0400 > From: Dimitri I Sidelnikov <sid(a)free.net> > Subject: Re: [address-policy-wg] Re-issue of reclaimed 16bit ASNs and > modifications to references in routing policy to these resources > To: routing-wg(a)ripe.net, address-policy-wg(a)ripe.net > Message-ID: <5395E963.5030005(a)free.net> > Content-Type: text/plain; charset=UTF-8 > > I support it. > > 09.06.2014 16:49, Jo?o Damas ?????: >> Dear all, >> at the recent RIPE 68 meeting there was a discussion about issues concerning the re-issue of recovered 16-bit ASNs by the RIPE NCC and possible modifications to the content of routing-related attributes in RIPE Database objects, namely the routing policy attributes of autnum and as-set objects. >> >> The observed consensus during the meeting was that: >> >> - the RIPE NCC should not to remove references to recovered ASNs from import and export lines, and neither from as-set objects; routing policies are the realm of the object owner and are not related to allocation data. >> - the RIPE NCC will inform the maintainer of the object containing the obsolete reference about this reference. The RIPE NCC will also offer support to the maintainer to delete the reference; >> - the RIPE NCC will start re-assigning referenced AS numbers once the unreferenced pool of 16-bit AS numbers has been exhausted. >> >> We would like to close the issue and be able to provide clear guidance to the RIPE NCC so we would like to get confirmation for this outcome also from the working group mailing lists. This is not a policy issue: the re-allocation of recovered ASNs was dealt with by the APWG, the current issue is related to alterations to RIPE Database objects that reference the resources subject to re-allocation. >> We propose a 15 day comment period, ending June 24th 2014. >> >> Sander Steffann, Gert D?ring, Rob Evans, Jo?o Damas > > -- > > Kind regards, > --- > D.Sidelnikov > > > > > ------------------------------ > > Message: 3 > Date: Mon, 09 Jun 2014 16:20:54 +0200 > From: Jens Ott - Opteamax GmbH <jo(a)opteamax.de> > Subject: Re: [address-policy-wg] Re-issue of reclaimed 16bit ASNs and > modifications to references in routing policy to these resources > To: Hank Nussbacher <hank(a)efes.iucc.ac.il>, Jo?o Damas > <joao(a)bondis.org>, routing-wg(a)ripe.net, address-policy-wg(a)ripe.net > Message-ID: <3c678c23-376e-4fa7-a0fc-50f3181a4ba9(a)email.android.com> > Content-Type: text/plain; charset=UTF-8 > > > >> On 9. Juni 2014 15:53:15 MESZ, Hank Nussbacher <hank(a)efes.iucc.ac.il> wrote: >> At 14:49 09/06/2014 +0200, Jo?o Damas wrote: >>> Dear all, >>> at the recent RIPE 68 meeting there was a discussion about issues >>> concerning the re-issue of recovered 16-bit ASNs by the RIPE NCC and >>> possible modifications to the content of routing-related attributes in >> >>> RIPE Database objects, namely the routing policy attributes of autnum >> and >>> as-set objects. >>> >>> The observed consensus during the meeting was that: >>> >>> - the RIPE NCC should not to remove references to recovered ASNs from >>> import and export lines, and neither from as-set objects; routing >> policies >>> are the realm of the object owner and are not related to allocation >> data. >> >> On a related matter, is it possible currently to setup my aut-num that >> if >> anyone adds my autnum to their import/export/as-set objects I would >> receive >> a notification about it? Currently the "notify" field only informs me >> of >> changes to the specific aut-num, not people who reference my aut-num >> w/o my >> permission? >> >> If this is not feasible with the system today, would it be possible to >> add >> this feature? I'll explain the rationale: we have recently discovered >> that >> hostile aut-num's that intend to perform a BGP hijack, will add the >> victims >> aut-num to their routing policy or to their unsuspecting upstream. >> This >> policy is then picked up as legitimate and propogated. By having a >> "notify-on-policy" email address field, I would be able to quickly see >> who >> is planning on hijacking my IP ranges. >> >> Comments? >> > > I fully support your point. I also observed what you told here. Therefore we enhanced our Prefixlist-Generator doing counter-checks if an import statement also have a corresponding export - statement. Result is, that the prefixlist generation takes about 10 times longer, our caching database grew by factor eight (as we now also need to cache autnum objects of child- and grandchild-objects) ... > > So a "notify-on-policy" - how you called it - would be very appreciated! > > BR Jens >> Thanks, >> Hank >> >> >> >> >> >> !DSPAM:637,5395bdec188062364380171! > > -- > Jens Ott > Opteamax GmbH > Simrockstr. 4G > 53619 Rheinbreitbach > Tel. +49 2224 969500 > Email: jo(a)opteamax.de > > > > End of address-policy-wg Digest, Vol 34, Issue 10 > *************************************************

3 2

Re-issue of reclaimed 16bit ASNs and modifications to references in routing policy to these resources
by João Damas 09 Jun '14

09 Jun '14

Dear all, at the recent RIPE 68 meeting there was a discussion about issues concerning the re-issue of recovered 16-bit ASNs by the RIPE NCC and possible modifications to the content of routing-related attributes in RIPE Database objects, namely the routing policy attributes of autnum and as-set objects. The observed consensus during the meeting was that: - the RIPE NCC should not to remove references to recovered ASNs from import and export lines, and neither from as-set objects; routing policies are the realm of the object owner and are not related to allocation data. - the RIPE NCC will inform the maintainer of the object containing the obsolete reference about this reference. The RIPE NCC will also offer support to the maintainer to delete the reference; - the RIPE NCC will start re-assigning referenced AS numbers once the unreferenced pool of 16-bit AS numbers has been exhausted. We would like to close the issue and be able to provide clear guidance to the RIPE NCC so we would like to get confirmation for this outcome also from the working group mailing lists. This is not a policy issue: the re-allocation of recovered ASNs was dealt with by the APWG, the current issue is related to alterations to RIPE Database objects that reference the resources subject to re-allocation. We propose a 15 day comment period, ending June 24th 2014. Sander Steffann, Gert Döring, Rob Evans, João Damas

7 7

Re: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources)
by Jan Ingvoldstad 07 Jun '14

07 Jun '14

On Tue, Jun 3, 2014 at 3:13 PM, Marco Schmidt <mschmidt(a)ripe.net> wrote: > https://www.ripe.net/ripe/policies/proposals/2014-05 I like this proposed policy, it is very reasonable, and seems to have addressed the overlying concerns with inter-RIR transfers. I have a comment regarding the second argument against the policy, "*The proposal will re-introduce operational needs justification, if any RIR insists on this, in order to effect certain transfers*." I don't think this is an argument against the policy itself, but it is a concern that RIPE NCC needs to address when guiding LIRs in the transfer process. In other words: yes, operational needs justification under any other RIR's "jurisdiction" is a concern, but it is not within RIPE's powers to do anything about it, other than help RIPE's LIRs make the best of it when transferring resources. -- Jan

6 9

Re: [address-policy-wg] 2014-05 New Policy Proposal (Policy for Inter-RIR Transfers of Internet Resources)
by Nigel Titley 07 Jun '14

07 Jun '14

On 03/06/14 14:13, Marco Schmidt wrote: > Dear colleagues, > > > A new RIPE Policy Proposal has been made and is now available for > discussion. > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2014-05 > > > We encourage you to review this proposal and send your comments to > <address-policy-wg(a)ripe.net> before 2 July 2014. > > Speaking as myself and myself only. Much as I disliked the woolly language of its predecessor I think this version is crisp and clean. Once the already mentioned nits about LIR/Member/Organisation/Stonecutter are sorted out, and with a possible fix to 2014-01, as mentioned by Carsten, I think this would be a good addition to RIPE region policy. Nigel

1 0