From ebais at a2b-internet.com Fri Nov 1 14:37:20 2013 From: ebais at a2b-internet.com (Erik Bais) Date: Fri, 1 Nov 2013 14:37:20 +0100 Subject: [address-policy-wg] 2013-05 Last Call for Comments (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: References: Message-ID: <01b901ced707$7d64e430$782eac90$@a2b-internet.com> Hi Marco, The URL link to the proposal in your email is pointing to policy 2013-04 which is already processed and archived. The correct url should be: https://www.ripe.net/ripe/policies/proposals/2013-05 Having said that, I want to express my support for Sascha's proposal. Regards, Erik Bais From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of mschmidt Sent: woensdag 30 oktober 2013 14:24 To: Address Policy Working Group; policy-announce at ripe.net Subject: [address-policy-wg] 2013-05 Last Call for Comments (No Restrictions on End User Assignments in Intra-RIR Transfers) Dear colleagues, The proposal described in 2013-05, No Restrictions on End User Assignments in Intra-RIR Transfers, 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 28 November and must be supported by an explanation. If no substantive objections are raised by the end of Last Call, the proposal will complete the PDP and will be evaluated by the co-Chairs of all RIPE Working Groups for consensus. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2013-05 Please e-mail any final comments about this proposal to address-policy-wg at ripe.net before 28 November 2013. Regards Marco Schmidt Policy Development Office RIPE NCC From elvis at velea.eu Fri Nov 1 15:42:50 2013 From: elvis at velea.eu (Elvis Daniel Velea) Date: Fri, 1 Nov 2013 22:42:50 +0800 Subject: [address-policy-wg] 2013-05 Last Call for Comments (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: <01b901ced707$7d64e430$782eac90$@a2b-internet.com> References: <01b901ced707$7d64e430$782eac90$@a2b-internet.com> Message-ID: <2672249943761741619@unknownmsgid> +1 I think I had already expressed my support for this proposal but I can't find that mail. cheers, elvis Excuse the briefness of this mail, it was sent from a mobile device. > On 01 Nov 2013, at 21:37, "Erik Bais" wrote: > > Hi Marco, > > The URL link to the proposal in your email is pointing to policy 2013-04 which is already processed and archived. > > The correct url should be: https://www.ripe.net/ripe/policies/proposals/2013-05 > > Having said that, I want to express my support for Sascha's proposal. > > Regards, > Erik Bais > > > From: address-policy-wg-bounces at ripe.net [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of mschmidt > Sent: woensdag 30 oktober 2013 14:24 > To: Address Policy Working Group; policy-announce at ripe.net > Subject: [address-policy-wg] 2013-05 Last Call for Comments (No Restrictions on End User Assignments in Intra-RIR Transfers) > > Dear colleagues, > > > The proposal described in 2013-05, No Restrictions on End User Assignments > in Intra-RIR Transfers, 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 28 November and must be supported by an > explanation. > > If no substantive objections are raised by the end of Last Call, the > proposal will complete the PDP and will be evaluated by the co-Chairs of > all RIPE Working Groups for consensus. > > You can find the full proposal at: > > https://www.ripe.net/ripe/policies/proposals/2013-05 > > Please e-mail any final comments about this proposal to address-policy-wg at ripe.net > before 28 November 2013. > > > Regards > > Marco Schmidt > Policy Development Office > RIPE NCC > > From gert at space.net Fri Nov 1 19:09:26 2013 From: gert at space.net (Gert Doering) Date: Fri, 1 Nov 2013 19:09:26 +0100 Subject: [address-policy-wg] 2013-05 Last Call for Comments (No Restrictions on End User Assignments in Intra-RIR Transfers) In-Reply-To: <01b901ced707$7d64e430$782eac90$@a2b-internet.com> References: <01b901ced707$7d64e430$782eac90$@a2b-internet.com> Message-ID: <20131101180926.GM50205@Space.Net> Hi, On Fri, Nov 01, 2013 at 02:37:20PM +0100, Erik Bais wrote: > Having said that, I want to express my support for Sascha's proposal. Thanks. Just for clarity (because I got another inquiry by personal mail) - in Last Call, no further statements of support are formally required, that is, if not a single mail is received in Last Call phase, this is still considered by the PDP as "support" (based on the support in the previous phases) - "silence is consent", in and *only in* the Last Call phase. OTOH, if someone has a valid concern, answering that is welcome, of course :-) 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From sylvain.vallerot at opdop.net Sun Nov 17 20:52:01 2013 From: sylvain.vallerot at opdop.net (Sylvain Vallerot) Date: Sun, 17 Nov 2013 20:52:01 +0100 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <526FC72E.7020802@fud.no> References: <1380206290.2739@mobil.space.net> <20131025180341.GA75737@Space.Net> <526FC72E.7020802@fud.no> Message-ID: <52891E61.8040709@opdop.net> On 29/10/2013 15:33, Tore Anderson wrote: > I think it would benefit the proposal's journey through the PDP if it > tried to do fewer things at once, perhaps by splitting it into multiple > proposals. Agreed. Despite i'm globally ok with the spirit the proposal but I think having a proposal that meets the "main goal" is not yet granted. A few things seem problematic to me Removing the color looks interesting, but to me question is, what does it bring apart from cosmetics ? From what I read in the proposal there sitll would be a difference between End User block and End Site bloc. Call it (sub)allocated or assign, it is the same difference. The majors points seems to be that nowadays PI blocks would (a) be bigger tomorrow and (b) able to be further sub-allocated / assigned to End Users / Sites. Yes this is the major point since it will give independance for a lot of companies. But this, only is costs from the sponsoring LIRs are not a barrier. However this should lead to an automatic shift to what used to be PI, since any End User could request a /32 that would be independant from the LIR there seems to be a risk regarding the aggregation goal (I refer to old-style routing aggregation). Next, growing automatic End-User minimum allocation to /32 is going to be a problem for routing LIRs structure and/or ressource management since they are supposed to have a IPv6 plan. This /32 frontier standard might become a problem for the smaller networks routability, leading everybody to rush to a /32 without having a need for it because of some operators taking /32 as a new filtering limit. I did not see any financial consideration here, so LIRs might will to apply financial pressure of their customers (and as Sponsoring LIRs) slow the implieds changes. So I think we lack an impact analysis here, and I wonder about the impact for LIRs, and impact for Ripe in terms if membership and workload evolutions. Sorry if some of these we already discussed, this is just for the requested feedback, I did'nt have the time to read all the 99 posts yet. Best regards, Sylvain From maildanrl at gmail.com Tue Nov 19 16:06:06 2013 From: maildanrl at gmail.com (Dan Luedtke) Date: Tue, 19 Nov 2013 16:06:06 +0100 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: References: <1380206290.2739@mobil.space.net> <20131025180341.GA75737@Space.Net> Message-ID: Tore Anderson wrote: > Being a data centre operator and LIR, I believe I cannot > currently make an IPv6 PA assignment to a customer of mine who wants to > run a cloud service where their customers can rent virtual servers in > turn. (A customer of theirs may in turn run some sort of web hotel for > another set of customers on those VMs, and so on and so on.) This is a typical situation the policies do not address well. Optional example: I have one IPv6 PI and I would love to become a RIPE member which I can not afford since I run a non-profit network targeted at network beginners. The policies gave me more than one headache and are the reason why I joined this wg in the first place. AFAIK the only way to go is by deciding which policy violation is less harmful. And that is bad. If an e.g. /56 would be treated like a single IPv4 address is today the solution would be "the loophole" (see quote above). As soon as I give /64 to a single VM to isolate it from other VMs and I am not the "owner" of the VM I will get into policy trouble because I just sub-allocated a portion of my PI space. Since I regularly deal with networking beginners and their VMs it would be fine to isolate them a bit more. Instead it looks like this: Multiple VMs share a link and a VM's interface gets as many addresses from that subnet as required, not more and not less, still seeing other VMs in the neighbor cache. On Tue, Oct 29, 2013 at 4:23 PM, Daniel Stolpe wrote: > > > On Sun, 27 Oct 2013, Roger J?rgensen wrote: > >> Erik Bais's mail touch what is probably the only real difference >> between PI and PA, and our core problem: >> >>> From Erik Bais's post on this thread: >> >> "Having garage-style 'hosters' do assignments, just because they can while >> using PI IPv6 space, is against the policy, however removing that >> distinction between PI and PA for v6 and allowing sub-assignments from PI >> space will basically open the door in the near future for cheap resources, >> without being an LIR. That will have an impact on the number of members >> the >> NCC will have once we are beyond the v4 era ... And less members will >> result >> in a high fee per member." >> >> >> Isn't this really about what is the difference between being a member and >> not? >> It would be nice to get ride of the PI and PA, and at the same time >> keeping the difference between member (LIR) and none member (no-LIR). > > > Well, there has to be some benefits for the members, hasn't it? At the same > time, what says RIPE has to have 10.000 members? Or 130 employees? And the > current policy looks very much like a membership boosting construction: just > sign up, pay the bill and get a /29 (compaired to ask a member to apply for > a /48 with very restricted use and make life really hard if you ever want > anything more). > > What makes us think that PA holders/members are always responsible while PI > holders/non-members are completely not trustworthy? > > I would prefer policies to apply for addresses (let's say, thou shalt not > assign less than a /xx to an yy) rather than the role play of today. > > > Best Regards, > > Daniel Stolpe > > _________________________________________________________________________________ > Daniel Stolpe Tel: 08 - 688 11 81 > stolpe at resilans.se > Resilans AB Fax: 08 - 55 00 21 63 > http://www.resilans.se/ > Box 13 054 > 556741-1193 > 103 02 Stockholm -- Dan Luedtke http://www.danrl.de From mschmidt at ripe.net Wed Nov 20 11:01:24 2013 From: mschmidt at ripe.net (Marco Schmidt) Date: Wed, 20 Nov 2013 11:01:24 +0100 Subject: [address-policy-wg] 2013-03: Review Phase - New Proposal Description and Impact Analysis Published Message-ID: Dear colleagues, Following feedback received from the community, the title and the introduction for the proposal 2013-03 (formerly titled "No Need - Post-Depletion Reality Adjustment and Cleanup") have been edited and published. The proposal is now entitled "Post Depletion Adjustment of Procedures to Match Policy Objectives, and Clean-up of Obsolete Policy Text". The impact analysis prepared by the RIPE NCC in relation to this proposal has also been published. The rest of the proposal document, including the new policy text, has not changed. The following changes have been made to the proposal: - New proposal title - Revised introductory text, explaining the purpose of the proposal - Adjusted Rationale a.7 in support of the proposal You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2013-03 The draft policy documents are available at: https://www.ripe.net/ripe/policies/proposals/2013-03/draft We encourage you to read the proposal and the impact analysis and send any comments to before 5 December 2013. Regards Marco Schmidt Policy Development Office RIPE NCC From gert at space.net Wed Nov 20 12:03:23 2013 From: gert at space.net (Gert Doering) Date: Wed, 20 Nov 2013 12:03:23 +0100 Subject: [address-policy-wg] 2013-03: Review Phase - New Proposal Description and Impact Analysis Published In-Reply-To: <1384942149.9327@mobil.space.net> References: <1384942149.9327@mobil.space.net> Message-ID: <20131120110323.GU81676@Space.Net> Dear AP WG, On Wed, Nov 20, 2013 at 11:01:24AM +0100, Marco Schmidt wrote: > [new version of 2013-03 published] > > The rest of the proposal document, including the new policy text, has not changed. > [..] > We encourage you to read the proposal and the impact analysis and send any > comments to before 5 December 2013. Based on the particular circumstances here, namely that the policy text is completely unchanged from the previous version, the WG chairs have decided that we do NOT require everybody to state their support or opposition to the proposal again. So: if you supported this proposal before, and still support it, we'll take your statements given in the previous review period into account here. Similarily, if you opposed it, and still oppose it, no need to re-state that, as we'll also take this into account. OTOH, what we would really like to hear is "I did not like the previous version of the proposal due to the negative signals it sends out to the world, but with the new supporting notes it's good now, so support!" - or possibly "I was fine with the old text, but the new notes are all wrong now, so I can no longer support it" (that would be bad news). thanks :-) 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From gert at space.net Wed Nov 20 15:16:05 2013 From: gert at space.net (Gert Doering) Date: Wed, 20 Nov 2013 15:16:05 +0100 Subject: [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space) In-Reply-To: <526FC72E.7020802@fud.no> References: <1380206290.2739@mobil.space.net> <20131025180341.GA75737@Space.Net> <526FC72E.7020802@fud.no> Message-ID: <20131120141605.GZ81676@Space.Net> Hi, the discussion phase for this is coming to an end, and what I've heard so far is mostly "great idea, way too complex approach to solving it". Anyway, to answer some of these... On Tue, Oct 29, 2013 at 03:33:18PM +0100, Tore Anderson wrote: > > The proposal aims to unify IPv6 PA and IPv6 PI space into one kind of > > address space, "IPv6 addresses". This is the goal. > > A goal which I support. However, the proposal does go a bit further than > just this. For example, it: I think these are really unavoidable consequences if you - unify PA and PI - keep the "there is LIR" and "there is users of sponsored LIRs" model > - unifies [PA] allocations and [PA] assignments > - unifies the LIR and End User roles > - allows an infinitely deep hierarchy of LIR+EU organisations > - in doing so, significantly changes the structure of the Internet > Registry System This is basically a consequence of the policy we currently *have* - PA space can be sub-allocated, even though this is slightly hidden in the policy... http://www.ripe.net/ripe/docs/ripe-589#lir-to-isp ("status: ALLOCATED-BY-LIR"). While the database does not have a status: value for "ALLLOCATED-BY-CUSTOMER-OF-LIR", there is nothing in the policy text that wouldn't allow multiple layers of "subordinate ISPs" for PA space - as long as "all /48 assignments" are properly documented... So - if you unify PI and PA, and continue to permit sub-allocations, this is where you end... (and it seems to match "reality" somewhat better than "there are LIRs and there are end-users, and no other categories in between"). > - dramatically increases the maximum undocumented delegation size from 1 > /29 per LIR to $NUMSITES * /29. There's that, yes. If we accept the prerequisites above, this is a certain risk, which is why we tried countering this with "large blocks are somewhat more expensive". > [.. reasons why this proposal exists ..] > Is this concern really specific to PI? I'd say this is more a > problematic property of IPv6 *assignments* - regardless of them being PI > or PA. Being a data centre operator and LIR, I believe I cannot > currently make an IPv6 PA assignment to a customer of mine who wants to > run a cloud service where their customers can rent virtual servers in > turn. (A customer of theirs may in turn run some sort of web hotel for > another set of customers on those VMs, and so on and so on.) You can :-) - ripe-589, 5.3. Well, you wouldn't "assign" the addresses to your customers, but "sub-allocate", and he would then assign individual /56s or whatever to the final end customers. But the addressing hierarchy is possible. [..] > Of course, this wouldn't by itself yield PI/PA unification. However I > think that too may be accomplished in a less intrusive way than 2013-06 > currently proposes: Delete section 7, and add a new section to the > appendix or even just the supporting notes saying that it should be > possible to obtain become an LIR and hold PA space without being a > direct member of the RIPE NCC, and that this should cost about the same > as holding PI does today, and that all pre-existing PI holders and their > blocks/inet6nums should be automatically converted to this new arrangement. Sounds easy, but I'm not sure this would actually solve all the questions that arise, like - why should anyone become a RIPE member if they can have their address space for 50 EUR/year insteaad? - under which conditions can an entity get two "LIR blocks", then? - which size of address block would a "non RIPE member" LIR receive? ... so in the end, the answers would likely be similarily lengthy than what was provided here. But anyway, just trying to shine some light on why I think the complexity is not exactly avoidable - but I get the message "this is too much too digest, and the problem it is solving does not seem to be that big after all". Gert Doering -- ripe policy victim -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From nick at inex.ie Thu Nov 21 22:35:15 2013 From: nick at inex.ie (Nick Hilliard) Date: Thu, 21 Nov 2013 21:35:15 +0000 Subject: [address-policy-wg] Announcing address resources Message-ID: <528E7C93.909@inex.ie> Apropos of, oh I don't know, the weather or the phase of the moon or something, could someone point me to the RIPE policy which says that if you're assigned address resources from the RIPE NCC, that they cannot be announced from outside the RIPE NCC service region? [This is a genuine request, btw. I've been flicking down through RIPE policies for an hour or two today and can't find the reference.] Nick From ebais at a2b-internet.com Thu Nov 21 23:51:18 2013 From: ebais at a2b-internet.com (Erik Bais) Date: Thu, 21 Nov 2013 23:51:18 +0100 Subject: [address-policy-wg] Announcing address resources In-Reply-To: <528E7C93.909@inex.ie> References: <528E7C93.909@inex.ie> Message-ID: <81D895E9-6C1A-4340-968C-E1F8C6FD43B7@a2b-internet.com> Hi Nick, Policy https://www.ripe.net/ripe/docs/ripe-592 states .... 1.1 Scope This document describes the policies for the responsible management of globally unique IPv4 Internet address space in the RIPE NCC service region. But that is as close I could find it ... The policy is valid for allocation and assignment IN the RIPE service region ... Not outside .. Can you use the IP addresses within the region but for customers originating outside the region: yes. Can you use the IP adresses outside the region but for EU region customers: that is a bit grey I think, but I'm going for yes. The issue is that you should have a RIPE region based entity to qualify to request resources. Also if you want to obtain for instance with an EU entity at ARIN, to host US based customers, it isn't possible. they require you to have an ARIN region based entity as well. Although RIPE is generally easier in that respect (policy interpertation) You should be able to route your resources at multiple locations, as long as they are not single homed in the incorrect service region (imho) ... But there might be a clearer definition required if desired... What is your interpertation of it ? Erik Bais Verstuurd vanaf mijn iPad Op 21 nov. 2013 om 22:35 heeft Nick Hilliard het volgende geschreven: > Apropos of, oh I don't know, the weather or the phase of the moon or > something, could someone point me to the RIPE policy which says that if > you're assigned address resources from the RIPE NCC, that they cannot be > announced from outside the RIPE NCC service region? > > [This is a genuine request, btw. I've been flicking down through RIPE > policies for an hour or two today and can't find the reference.] > > Nick > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Fri Nov 22 00:02:06 2013 From: nick at inex.ie (Nick Hilliard) Date: Thu, 21 Nov 2013 23:02:06 +0000 Subject: [address-policy-wg] Announcing address resources In-Reply-To: <81D895E9-6C1A-4340-968C-E1F8C6FD43B7@a2b-internet.com> References: <528E7C93.909@inex.ie> <81D895E9-6C1A-4340-968C-E1F8C6FD43B7@a2b-internet.com> Message-ID: <528E90EE.70001@inex.ie> On 21/11/2013 22:51, Erik Bais wrote: > But there might be a clearer definition required if desired... > What is your interpertation of it ? I saw that while trawling earlier today; at best it's ambiguous. As it's stated, I don't see anything in there which could stop anyone announcing ripe-ncc-assigned address space outside the ripe service region. Nick From rhe at nosc.ja.net Fri Nov 22 00:17:15 2013 From: rhe at nosc.ja.net (Rob Evans) Date: Thu, 21 Nov 2013 23:17:15 +0000 Subject: [address-policy-wg] Announcing address resources In-Reply-To: <528E90EE.70001@inex.ie> References: <528E7C93.909@inex.ie> <81D895E9-6C1A-4340-968C-E1F8C6FD43B7@a2b-internet.com> <528E90EE.70001@inex.ie> Message-ID: <528E947B.9030808@nosc.ja.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I saw that while trawling earlier today; at best it's ambiguous. > As it's stated, I don't see anything in there which could stop > anyone announcing ripe-ncc-assigned address space outside the ripe > service region. For what it is worth, which isn't much, I had a draft email sitting about most of this afternoon asking the same question of someone that appeared to be quoting such a policy. I couldn't find it either. Cheers, Rob -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKOlHsACgkQF83fs8P8zalWuwCfS8HwSzmOH0L2U1cHwybuGC3X X8gAnRciTT9+fvghug1rqwFN7agciYkv =tU1S -----END PGP SIGNATURE----- From randy at psg.com Fri Nov 22 01:41:43 2013 From: randy at psg.com (Randy Bush) Date: Fri, 22 Nov 2013 09:41:43 +0900 Subject: [address-policy-wg] Announcing address resources In-Reply-To: <528E7C93.909@inex.ie> References: <528E7C93.909@inex.ie> Message-ID: > Apropos of, oh I don't know, the weather or the phase of the moon or > something, could someone point me to the RIPE policy which says that if > you're assigned address resources from the RIPE NCC, that they cannot be > announced from outside the RIPE NCC service region? null set. what a ridiculous idea. only arin would think of such undeployable st00pidity randy From jcurran at arin.net Fri Nov 22 02:03:00 2013 From: jcurran at arin.net (John Curran) Date: Fri, 22 Nov 2013 01:03:00 +0000 Subject: [address-policy-wg] Announcing address resources In-Reply-To: References: <528E7C93.909@inex.ie> Message-ID: <9D844710-2476-4A7E-A507-DB209B68547A@arin.net> On Nov 21, 2013, at 9:41 PM, Randy Bush wrote: >> Apropos of, oh I don't know, the weather or the phase of the moon or >> something, could someone point me to the RIPE policy which says that if >> you're assigned address resources from the RIPE NCC, that they cannot be >> announced from outside the RIPE NCC service region? > > null set. what a ridiculous idea. only arin would think of such > undeployable st00pidity Randy - While the thought is appreciated, there is no such policy in the ARIN region. Since we do have a service region, we require requesters to be operating in the ARINregion and to announce the least-specific in the region, but nothing precludes announcement of same or more specifics from outside the region. Thanks! /John John Curran President and CEO ARIN From randy at psg.com Fri Nov 22 02:08:25 2013 From: randy at psg.com (Randy Bush) Date: Fri, 22 Nov 2013 10:08:25 +0900 Subject: [address-policy-wg] Announcing address resources In-Reply-To: <9D844710-2476-4A7E-A507-DB209B68547A@arin.net> References: <528E7C93.909@inex.ie> <9D844710-2476-4A7E-A507-DB209B68547A@arin.net> Message-ID: > Since we do have a service region, we require requesters to be operating in > the ARINregion and to announce the least-specific in the region, but nothing > precludes announcement of same or more specifics from outside the > region. i thought rirs did not regulate routing. silly me. glad you think you can better design my network than i. foad. randy From jcurran at arin.net Fri Nov 22 02:19:27 2013 From: jcurran at arin.net (John Curran) Date: Fri, 22 Nov 2013 01:19:27 +0000 Subject: [address-policy-wg] Announcing address resources In-Reply-To: References: <528E7C93.909@inex.ie> <9D844710-2476-4A7E-A507-DB209B68547A@arin.net> Message-ID: <8E0CC324-F1DE-4803-88FB-53F2052310BD@arin.net> On Nov 21, 2013, at 10:08 PM, Randy Bush wrote: >> Since we do have a service region, we require requesters to be operating in >> the ARINregion and to announce the least-specific in the region, but nothing >> precludes announcement of same or more specifics from outside the >> region. > > i thought rirs did not regulate routing. silly me. glad you think you > can better design my network than i. foad. If you're requested addresses for use in the region, then have usage of them in the region. If not, don't ask for them. It's not regulating the applicants routing at all, it's simply integrity to request application they just submitted. Thanks! /John John Curran President and CEO ARIN From elvis at v4escrow.net Fri Nov 22 02:46:06 2013 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Fri, 22 Nov 2013 02:46:06 +0100 Subject: [address-policy-wg] Announcing address resources In-Reply-To: <9D844710-2476-4A7E-A507-DB209B68547A@arin.net> References: <528E7C93.909@inex.ie> <9D844710-2476-4A7E-A507-DB209B68547A@arin.net> Message-ID: <528EB75E.9000303@v4escrow.net> Hello John, On 22/11/13 02:03, John Curran wrote: [...] > Since we do have a service region, we require requesters to be operating in > the ARINregion and to announce the least-specific in the region, but nothing > precludes announcement of same or more specifics from outside the region. > the link you have provided is from a presentation made at ARIN31. It's a presentation showing ARIN's current practices. Regarding the 'least-specific announcement', I see there are some questions already in the presentation, have these questions been answered by any updates of the policy (or procedure) since then? If not, as Nick's initial question was regarding RIPE policies, can you please point us to the ARIN policy or procedure document saying that less specifics *must* be announced from the ARIN region? Kind regards, Elvis -- V4Escrow, LLC -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: elvis.jpg Type: image/jpeg Size: 79970 bytes Desc: not available URL: From jcurran at arin.net Fri Nov 22 03:08:07 2013 From: jcurran at arin.net (John Curran) Date: Fri, 22 Nov 2013 02:08:07 +0000 Subject: [address-policy-wg] Announcing address resources In-Reply-To: <528EB75E.9000303@v4escrow.net> References: <528E7C93.909@inex.ie> <9D844710-2476-4A7E-A507-DB209B68547A@arin.net> <528EB75E.9000303@v4escrow.net> Message-ID: On Nov 21, 2013, at 10:46 PM, Elvis Daniel Velea > wrote: On 22/11/13 02:03, John Curran wrote: [...] Since we do have a service region, we require requesters to be operating in the ARINregion and to announce the least-specific in the region, but nothing precludes announcement of same or more specifics from outside the region. the link you have provided is from a presentation made at ARIN31. It's a presentation showing ARIN's current practices. Regarding the 'least-specific announcement', I see there are some questions already in the presentation, have these questions been answered by any updates of the policy (or procedure) since then? If not, as Nick's initial question was regarding RIPE policies, can you please point us to the ARIN policy or procedure document saying that less specifics *must* be announced from the ARIN region? The presentation resulted in discussion of changing current ARIN practices and/or codifying them into policy, and this led to Draft Policy ARIN-2013-6 "Allocation of IPv4 and IPv6 Address Space to Out-of-region Requestors" , which was discussed at length and then abandoned. We continue to operate as I explained above, and I felt was important to note that here since there easily could have been some confusion about ARIN's practices given the list comments and recent policy discussions. Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From randy at psg.com Fri Nov 22 04:09:30 2013 From: randy at psg.com (Randy Bush) Date: Fri, 22 Nov 2013 12:09:30 +0900 Subject: [address-policy-wg] Announcing address resources In-Reply-To: References: <528E7C93.909@inex.ie> <9D844710-2476-4A7E-A507-DB209B68547A@arin.net> <528EB75E.9000303@v4escrow.net> Message-ID: > Since we do have a service region, we require requesters to be > operating in the ARIN region. understandable, though not clearly more than maintaining geo monopoly, of little real benefit to the internet. > and to announce the least-specific in the region and what is the utility of telling me which part of the prefix to announce were? as i said, you are telling me what my routing policy should be. foad. randy From jcurran at arin.net Fri Nov 22 04:22:36 2013 From: jcurran at arin.net (John Curran) Date: Fri, 22 Nov 2013 03:22:36 +0000 Subject: [address-policy-wg] Announcing address resources In-Reply-To: References: <528E7C93.909@inex.ie> <9D844710-2476-4A7E-A507-DB209B68547A@arin.net> <528EB75E.9000303@v4escrow.net> Message-ID: On Nov 22, 2013, at 12:09 AM, Randy Bush wrote: >> and to announce the least-specific in the region > > and what is the utility of telling me which part of the prefix to > announce were? No idea (feel free to go read the archives of the discussion if you're curious), and in any case unrelated to the question asked about being able to route the address space outside the region, which is "yes" in ARIN's case. Thanks! /John From drc at virtualized.org Fri Nov 22 12:33:21 2013 From: drc at virtualized.org (David Conrad) Date: Fri, 22 Nov 2013 08:33:21 -0300 Subject: [address-policy-wg] Announcing address resources In-Reply-To: References: <528E7C93.909@inex.ie> Message-ID: <10E15312-478F-499B-91BA-3F1A060481F2@virtualized.org> On Nov 21, 2013, at 9:41 PM, Randy Bush wrote: >> could someone point me to the RIPE policy which says that if >> you're assigned address resources from the RIPE NCC, that they cannot be >> announced from outside the RIPE NCC service region? > null set. +1 > what a ridiculous idea. only arin would think of such undeployable st00pidity Actually, in practice, I believe both AfriNIC and LACNIC (and not ARIN) require requesters to assert, at least during request time, they will be using the address space allocated from the respective RIR free pools in-region. This has proven to be a bit problematic as this practice appears to be encouraging folks who cannot get address space in their region because their RIR has run out of address space to obtain address space from the ARIN region, thereby increasing the consumption rate from ARIN (not to mention potentially providing folks in AfriNIC/LACNIC with a false sense of IPv4 sufficiency that may decrease pressure for IPv6 deployment in those regions). Regards, -drc -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 495 bytes Desc: Message signed with OpenPGP using GPGMail URL: From randy at psg.com Fri Nov 22 14:27:24 2013 From: randy at psg.com (Randy Bush) Date: Fri, 22 Nov 2013 22:27:24 +0900 Subject: [address-policy-wg] Announcing address resources In-Reply-To: <10E15312-478F-499B-91BA-3F1A060481F2@virtualized.org> References: <528E7C93.909@inex.ie> <10E15312-478F-499B-91BA-3F1A060481F2@virtualized.org> Message-ID: > Actually, in practice, I believe both AfriNIC and LACNIC (and not > ARIN) require requesters to assert, at least during request time, they > will be using the address space allocated from the respective RIR free > pools in-region. if you believe in the regional monopoly koolaid, then one can make a case for getting space from a region in which one operates. and i can even see an expectation that it will be used in that region, though not solely in that region. and not with an anyone saying what routing announcements one can make where. [ i do not want to get into silly corner case examples ] randy From nigel at titley.com Fri Nov 22 17:33:32 2013 From: nigel at titley.com (Nigel Titley) Date: Fri, 22 Nov 2013 16:33:32 +0000 Subject: [address-policy-wg] Announcing address resources In-Reply-To: References: <528E7C93.909@inex.ie> <10E15312-478F-499B-91BA-3F1A060481F2@virtualized.org> Message-ID: <528F875C.7080209@titley.com> On 22/11/2013 13:27, Randy Bush wrote: >> Actually, in practice, I believe both AfriNIC and LACNIC (and not >> ARIN) require requesters to assert, at least during request time, they >> will be using the address space allocated from the respective RIR free >> pools in-region. > if you believe in the regional monopoly koolaid, then one can make a > case for getting space from a region in which one operates. and i can > even see an expectation that it will be used in that region, though not > solely in that region. and not with an anyone saying what routing > announcements one can make where. > I am reasonably certain that to answer Nick's original question: there is an assumption that RIPE NCC members will be operating in the RIPE NCC service region but that there are no strictures on where they announce prefixes or what size, colour or creed such prefixes should be. From a purely pragmatic point of view this would be a nightmare to police and I can do without any further nightmares. Nigel From ripe.address-policy-wg at ml.karotte.org Mon Nov 25 09:48:24 2013 From: ripe.address-policy-wg at ml.karotte.org (Sebastian Wiesinger) Date: Mon, 25 Nov 2013 09:48:24 +0100 Subject: [address-policy-wg] Announcing address resources In-Reply-To: <528E7C93.909@inex.ie> References: <528E7C93.909@inex.ie> Message-ID: <20131125084824.GA25194@danton.fire-world.de> * Nick Hilliard [2013-11-21 22:36]: > Apropos of, oh I don't know, the weather or the phase of the moon or > something, could someone point me to the RIPE policy which says that if > you're assigned address resources from the RIPE NCC, that they cannot be > announced from outside the RIPE NCC service region? Hi, the way I understood it is that the LIR company has to be in the RIPE region but where you announce your prefixes is your decision. I requested an AS&PA explicitly for announcement in asia without any problems. Regards Sebastian -- GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE) 'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE. -- Terry Pratchett, The Fifth Elephant From raimis at litnet.lt Fri Nov 29 04:57:33 2013 From: raimis at litnet.lt (Raimundas Tuminauskas) Date: Fri, 29 Nov 2013 05:57:33 +0200 Subject: [address-policy-wg] ripe-589 question Message-ID: <20131129055733.18765g0w8kjb0hog@pastas.litnet.lt> Dear all, We've ran into internal conflict assigning IPv6 address space. Anyone caring to provide independent view on this would be much appreciated. Problem: LITNET (org: ORG-LA11-RIPE) has been comprised of two ASNs 2847 and 5479. Current IPv6 allocation is /29 (inet6num: 2001:778::/29). Current policy is to assign /32 per AS. Proposed new policy is to assign /30 per AS. Arguments for new policy: - RIPE-589 3.4 (Aggregation) and 3.8 (Conflict of goals) Arguments for current policy: - Two routes will be announced anyway. Different AS_PATH and routing policies, no aggregation. - /32 is 1200+ /64s per head of population of the country. Should be enough for any local AS for foreseeable future. Revise assignment planning if not. - The same address space allocation will be preserved for future AS if any current end-user (university) would require independent routing policies. - We will not get any wider allocation. Next address range (if it will happen) will be far off from 2001:778 I'm not in favor of wasting a long-term resource like IPv6 and rather deviate from the policy, but maybe I'm missing a point here somewhere ? TIA sincerely, Raimundas Tuminauskas KTU ITD / LITNET NOC Studentu 48a, Kaunas 51367, Lithuania phone: +370 37300033 fax: +370 37300643 email: raimis at litnet.lt From sander at steffann.nl Fri Nov 29 07:32:40 2013 From: sander at steffann.nl (Sander Steffann) Date: Fri, 29 Nov 2013 07:32:40 +0100 Subject: [address-policy-wg] ripe-589 question In-Reply-To: <20131129055733.18765g0w8kjb0hog@pastas.litnet.lt> References: <20131129055733.18765g0w8kjb0hog@pastas.litnet.lt> Message-ID: Hi, > We've ran into internal conflict assigning IPv6 address space. Anyone caring to provide independent view on this would be much appreciated. > > Problem: > LITNET (org: ORG-LA11-RIPE) has been comprised of two ASNs 2847 and 5479. > Current IPv6 allocation is /29 (inet6num: 2001:778::/29). > Current policy is to assign /32 per AS. > Proposed new policy is to assign /30 per AS. > > Arguments for new policy: > - RIPE-589 3.4 (Aggregation) and 3.8 (Conflict of goals) > > Arguments for current policy: > - Two routes will be announced anyway. Different AS_PATH and routing policies, no aggregation. > - /32 is 1200+ /64s per head of population of the country. Should be enough for any local AS for foreseeable future. Revise assignment planning if not. I wouldn't count separate /64s as that will give you a distorted number. Count using the assignment size you are using, which I assume is a /48 per customer/university/research-institution/etc. That gives you a maximum of 65536 per /32. In a country with a population of 3 million that is probably enough to number all your customers :-) > - The same address space allocation will be preserved for future AS if any current end-user (university) would require independent routing policies. > - We will not get any wider allocation. Next address range (if it will happen) will be far off from 2001:778 So why don't you announce 2001:778::/32 from one AS and 2001:77c::/32 from the other? If you need more space in one AS then you can grow to a /31 or /30, and if you don't need to grow them then you might, if at some point in the future you need a separate routing policy, announce the remaining space from a separate AS. > I'm not in favor of wasting a long-term resource like IPv6 and rather deviate from the policy, but maybe I'm missing a point here somewhere ? Well, you can get the /29, and nobody else is going to get it, so you might as well make the best use of it. I just asked the NCC to expand my /32 to a /29. I use the first /32 for a LISP-based ISP setup, and I'm going to use one or more separate /32s for training purposes for ISPs. The nice thing about IPv6 is that we can always get enough space for what we need (within limits of course ;-) Cheers, Sander