- address-policy-wg - mailman.ripe.net

Guidance Requested: Reassigning Referenced ASNs
by Andrea Cima 01 Jul '13

01 Jul '13

[Apologies for duplicates] Dear colleagues, At the Address Policy WG session during RIPE 66, the RIPE NCC requested guidance from the RIPE community on reassigning referenced 16-bit ASNs. Together with the Address Policy WG Chairs, we have decided to seek additional input from the WG mailing list. Background: the RIPE NCC has around 1,400 returned 16-bit ASNs that are currently referenced in route objects, and "import" and "export" lines in aut-num objects. Problem: there is a need for 16-bit ASNs by operators. However, because these ASNs are referenced, they are not being reassigned. At RIPE 66, the RIPE NCC suggested the following potential solutions: A. Not reassign referenced AS numbers B. Reassign AS numbers even if referenced C. Clean up the RIPE Database from references and then reassign the AS numbers C.1. "Silent" update; or C.2. Informing the object holder of the update Please find the RIPE Meeting slides at the following url: https://ripe66.ripe.net/presentations/176-Address_Policy_WG_RIPE_66.pdf This email has been sent to both the Address Policy WG and RIPE Database WG mailing lists, due to the impact the proposals would have on the RIPE Database. However, we would ask to keep the discussion on the Address Policy WG mailing list to facilitate participation and the channeling of feedback. Thank you in advance for your input and best regards, Andrea Cima RIPE NCC

12 21

Re: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs
by Andreas Schachtner 27 Jun '13

27 Jun '13

Sanity checking upon submitting to the DB could prevent this. My 2c, Andreas Schachtner Send via mobile device. Please excuse brevity, typos and the funny spelling checker in particular. Gert Doering <gert(a)space.net> schrieb: >Hi, > >On Wed, Jun 26, 2013 at 06:40:21PM +0200, Opteamax GmbH - RIPE-Team wrote: >> Actually I don't really understand the problem. If the ASN is >> back in the pool, this reads for me "it shall no longer appear in >> the routing table". This includes for me that any object referencing >> this ASN is illegal by definition. So these illegal objects may not >> exist and *must* be removed asap from the DB. After removing all >> illegal objects, they should stay in some "grace-period" - let's >> say 3 month - and then there should be no problem reallocating the >> asn. > >The database currently has no mechanics to prevent someone from entering >an import/export line that says: > > aut-num: AS100000 > remarks: have fun with Jens > export: to AS5539 announce AS48200 > >which is exactly that sort of reference that would currently keep the >NCC from reallocating AS48200 (assuming that one were free). > >Auto-cleaning the route: objects still referencing AS48200 is fairly >easy, but auto-cleaning export/import policies and AS-SET objects is >harder, especially as people might have the aut-num: object in question >on file, just change stuff locally, and then re-send it when they have >changes, overriding the cleaned-up object in the database... > >Gert Doering > -- NetMaster >-- >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 (89) 32356-444 USt-IdNr.: DE813185279

4 6

Guidance Requested: Changing the Status of PI Address Space
by Sonderegger Olaf ABRAXAS INFORMATIK AG 27 Jun '13

27 Jun '13

Hi all My question is: Why RIPE NCC should go one step back instead one step forward? I remember an idea to remove status "Provider Aggregatable" (PA) and "Provider Independent" (PI) for IPv6 addresses [see Ref 1 / Ref 2]. If we go ahead with this idea and open it for any kind of IP address, than final result is the same as current guidance request. Ref 1: http://ripe62.ripe.net/presentations/148-wg.pdf<http://ripe62.ripe.net/presentations/148-wg.pdf%20/> Ref 2: http://ripe63.ripe.net/presentations/143-wg3.pdf I think, I could accept request as our first step in direction of removing status "Provider Aggregatable" (PA) and "Provider Independent" (PI). Best regards, Olaf Sonderegger

4 4

Re: [address-policy-wg] [db-wg] Guidance Requested: Reassigning Referenced ASNs
by Michele Neylon :: Blacknight 26 Jun '13

26 Jun '13

+1 seems sane On 25 Jun 2013, at 16:51, Randy Bush <randy(a)psg.com> wrote: > inform owner of dangling reference. wait a week. inform again. > wait a month. inform again. wait a week. remove dangling reference. > wait a month to see if anything has broken enough to get the attention > of folk who do not respond to email. reassign AS number. > > randy > Mr Michele Neylon Blacknight Solutions ♞ Hosting & Domains ICANN Accredited Registrar http://www.blacknight.co http://blog.blacknight.com/ Intl. +353 (0) 59 9183072 US: 213-233-1612 Locall: 1850 929 929 Direct Dial: +353 (0)59 9183090 Facebook: http://fb.me/blacknight Twitter: http://twitter.com/mneylon ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,Ireland Company No.: 370845

1 0

Cosmetic Surgery Project: Extended Review Period until 9 July on revised RIPE Policy document for IPv6 database objects
by Emilio Madaio 26 Jun '13

26 Jun '13

Dear colleagues, As part of the Cosmetic Surgery Project, the RIPE NCC is moving forward with a review of the policy document ripe-513, "Value of the "status:" and "assignment-size:" attributes in INET6NUM objects for sub-assigned PA space". A draft of the policy document is online and ready for community review at: https://www.ripe.net/ripe/readability/improving-the-readability-of-ripe-doc… The Address Policy Working Group Co-Chairs decided to extend the review period until 9 July 2013 to allow the community more time to give their feedback. Please send your feedback on this draft document to the Address Policy Working Group at <address-policy-wg at ripe.net>. Kind regards, Emilio Madaio Policy Development Officer RIPE NCC

4 4

2013-02 Proposal Accepted (Removal of requirement for certification of reallocated IPv4 addresses)
by Emilio Madaio 21 Jun '13

21 Jun '13

Dear Colleagues, Consensus has been reached, and the proposal for a change to RIPE Document ripe-582, "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", has been accepted by the RIPE community. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2013-02 The updated RIPE Policy document is ripe-592 and is available at: https://www.ripe.net/ripe/docs/ripe-592 Thank you for your input. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

Resource Certification for non-RIPE NCC Members
by Erik Bais 20 Jun '13

20 Jun '13

Dear community members of the AP WG and the NCC Services WG, As you may have seen, Ive created a policy proposal to ask the RIPE NCC to allow Resource Certification for non-RIPE NCC member resource holders. (IXP / Legacy space and PI space holders) Currently we are in the phase: Discussion Open for discussion And I would like to invite you to the service wg mail list for your support for this policy and a discussion on wording of the policy. For those that are not subscribed to the NCC Services mail-list -=> http://www.ripe.net/mailman/listinfo/ncc-services-wg/ During the creation of the policy I made a small error in the intention to limit the policy to entities in the RIPE NCC service region and the policy currently states: The Internet resources reside within the RIPE NCC service region Ill update this in the review phase. Im not sure yet if we need to skip that part entirely or change it to the actual intention. Your input and stated support on the NCC Services WG mail list would be highly appreciated. Kind regards, Erik Bais Link to the policy proposal: https://www.ripe.net/ripe/policies/proposals/2013-04

10 13

the interpretation of "transfer" - somewhat related to 2012-07
by Wilfried Woeber 12 Jun '13

12 Jun '13

Quoting Andrea's comment of today regarding "authoritative" RIR: <quote> Legacy resources issued to organisations within the RIPE region have been transferred to the RIPE region during the ERX project. Legacy resources that have not been transferred at that time, have been issued and registered to organisations in other RIR regions. RIPE policy has no authority over legacy resources registered in other RIR regions. For this reason, in order to transfer those resources to the RIPE registry (and register them with a RIPE NCC LIR), there needs to be a transfer policy that would allow transfers between the RIPE NCC and the RIR that has the authority over those resources. </quote> First of all, I appreciate the NCC's cautious approach to moving things around without a clear consensus and guidance on preocedures! Two comments for discussion or clarification: ° until now I always read policies or policy proposals regarding a "transfer" of addresses from userA to userB. With either both of them sharing the same assignment to an authoritative RIR (intra-region xfr) or relating to different authoritative RIRs (inter-region xfr). The comment as quoted above indicates a different, or rather an additional interpretation and applicability: the transfer of address *registration* data pertaining to some (the very same!) userX from one authoritative RIR to a different one. I am not sure that the community did or does have that interpetation in mind? ° the "good old ERX" project, back then, was based on simple clerical inputs, a procedural agreement amongst the RIRs, and with no formal policy background, IIRC. Thus I do not really understand, why we would need a formal "policy" regarding inter-regeion transfers, as long as the registration subject remains the same. I may have missed some things, of course. Wilfried.

1 0

Re: [address-policy-wg] address-policy-wg Digest, Vol 22, Issue 5
by ACCESS 11 Jun '13

11 Jun '13

Вторник, 11 июня 2013, 12:00 +02:00 от address-policy-wg-request(a)ripe.net: > 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: Resource Certification for non-RIPE NCC Members (Peter Koch) > 2. Policy Proposal 2012-10 "Extension of IPv6 /32 to /29 on a > per-allocation vs per-LIR basis" implemented (Kjell Leknes) > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 10 Jun 2013 17:20:30 +0200 > From: Peter Koch < pk(a)DENIC.DE > > Subject: Re: [address-policy-wg] Resource Certification for non-RIPE > NCC Members > To: ncc-services-wg(a)ripe.net, address-policy-wg(a)ripe.net > Message-ID: < 20130610152030.GK14598(a)x28.adm.denic.de > > Content-Type: text/plain; charset=us-ascii > > On Fri, Jun 07, 2013 at 03:32:31PM +0200, Wilfried Woeber wrote: > > > Whether we need a formal "policy" or just an agreement (amongst the members > > of the NCC) to a Service Description and a review of the CPS as maintained > > by the NCC is a sideline issue, imho. > > > > For now using the framework of the PDP maybe useful and appropriate. > > I respectfully suggest it is not. The current modus operandi for RPKI > in the NCC service region is not only not based on a policy created > by the PDP, it exists despite a policy proposal for that very subject > having failed. Whether or not that creates a schism might be interesting > to discuss, but is not relevant for the case at hand. What counts here is > that the absence of policy is not an 'omission' or accident. > > So far I have seen support for 2013-04 based on symmetry or equality of > PA, PI and other (former) special cases. While this might have merit > operationally, it cannot support a parallel policy just because there's > nothing to draw the parallel to. This point of order has not been addressed > so far (and there are multiple solutions to this situation). > > Therefore I formally object to 2013-04 being elevated into the next PDP phase. > > -Peter > > ------------------------------ > > Message: 2 > Date: Tue, 11 Jun 2013 08:43:29 +0200 > From: Kjell Leknes < kjell(a)ripe.net > > Subject: [address-policy-wg] Policy Proposal 2012-10 "Extension of > IPv6 /32 to /29 on a per-allocation vs per-LIR basis" implemented > To: "address-policy-wg(a)ripe.net" < address-policy-wg(a)ripe.net >, > "policy-announce(a)ripe.net" < policy-announce(a)ripe.net > > Message-ID: < 11E136AE-2A9A-4798-9F2E-D57CF49672D8(a)ripe.net > > Content-Type: text/plain; charset="us-ascii" > > [Apologies for duplicate emails] > > Dear colleagues, > > We are pleased to announce that RIPE Policy Proposal 2012-10, "Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis", has been implemented. > > The full policy proposal can be found at: > http://www.ripe.net/ripe/policies/proposals/2012-10 [Open URL] > > The updated RIPE Document 589, "IPv6 Address Allocation and Assignment Policy", can be found at: > http://www.ripe.net/ripe/docs/ripe-589 [Open URL] > > You can request this extension by submitting the IPv6 Additional Allocation Request Form through the LIR Portal, or by emailing it to hostmaster(a)ripe.net > > If you have any questions, please contact ncc(a)ripe.net > > Regards, > > Kjell Leknes > Registration Services > RIPE NCC >

1 0

Policy Proposal 2012-10 "Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis" implemented
by Kjell Leknes 11 Jun '13

11 Jun '13

[Apologies for duplicate emails] Dear colleagues, We are pleased to announce that RIPE Policy Proposal 2012-10, "Extension of IPv6 /32 to /29 on a per-allocation vs per-LIR basis", has been implemented. The full policy proposal can be found at: http://www.ripe.net/ripe/policies/proposals/2012-10 [Open URL] The updated RIPE Document 589, "IPv6 Address Allocation and Assignment Policy", can be found at: http://www.ripe.net/ripe/docs/ripe-589 [Open URL] You can request this extension by submitting the IPv6 Additional Allocation Request Form through the LIR Portal, or by emailing it to hostmaster(a)ripe.net If you have any questions, please contact ncc(a)ripe.net Regards, Kjell Leknes Registration Services RIPE NCC

1 0