From ncc at ripe.net Fri Sep 1 12:36:55 2006 From: ncc at ripe.net (Paul Rendek) Date: Fri, 01 Sep 2006 12:36:55 +0200 Subject: [address-policy-wg] Urgent: NRO NC Nominations Message-ID: <44F80D47.8050309@ripe.net> [Apologies for duplicate e-mails.] Dear Colleagues, During the process of collecting nominations for the available seat on the Number Resource Organization (NRO) Number Council (NC), we experienced problems with incoming e-mail to nominations at ripe.net. Unfortunately, this may have resulted in the loss of some nominations and supporting e-mails. If you have sent a nomination or a supporting e-mail to nominations at ripe.net, please check to see if it is listed at: http://www.ripe.net/info/resource-admin/nro2006/confirmed-nominations.html ============================================================================================================================ * If you do not see your nomination or supporting e-mail on the web page mentioned above, please re-send it as soon a possible to: nominations at ripe.net * ============================================================================================================================ For more information about the NRO NC election process, please see: http://www.ripe.net/info/resource-admin/nro2006/ We apologise for any inconvenience caused. Kind regards, Paul Rendek Head of Member Services & Communications RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From filiz at ripe.net Tue Sep 12 10:15:14 2006 From: filiz at ripe.net (Filiz Yilmaz) Date: Tue, 12 Sep 2006 10:15:14 +0200 Subject: [address-policy-wg] 2006-06 New Policy Proposal (IPv4 Maximum Allocation Period) Message-ID: <20060912081514.C11822F5A0@herring.ripe.net> PDP Number: 2006-06 IPv4 Maximum Allocation Period Dear Colleagues, A new RIPE Policy Proposal has been made and is now available for discussion. This proposal is to have the RIPE NCC allocate address space to Local Internet Registries (LIRs) based on their one-year needs. In other words, it suggests setting a maximum allocation period of 12 months. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-06.html We encourage you to review this proposal and send your comments to before 10 October 2006. Regards Filiz Yilmaz RIPE NCC Policy Development Officer From filiz at ripe.net Tue Sep 12 10:18:04 2006 From: filiz at ripe.net (Filiz Yilmaz) Date: Tue, 12 Sep 2006 10:18:04 +0200 Subject: [address-policy-wg] 2006-07 New Policy Proposal (Minimum IPv4 Assignment Window) Message-ID: <20060912081804.19FAF2F592@herring.ripe.net> PDP Number: 2006-07 Minimum IPv4 Assignment Window Dear Colleagues, A new RIPE Policy has been made and is now available for discussion. This proposal suggests the minimum Assignment Window (AW) available to LIRs should be raised from zero (0) to /21 (2048 IPv4 addresses). Because the sub-allocation policy references the AW policy, the sub-allocation policy also needs to be updated. This proposal suggests that the maximum sub-allocation should be kept at /20 (4096 IPv4 addresses). You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-07.html We encourage you to review this proposal and send your comments to before 10 October 2006. Regards Filiz Yilmaz RIPE NCC Policy Development Officer From filiz at ripe.net Tue Sep 12 10:48:53 2006 From: filiz at ripe.net (Filiz Yilmaz) Date: Tue, 12 Sep 2006 10:48:53 +0200 Subject: [address-policy-wg] 2006-07 New Policy Proposal (Minimum IPv4 Assignment Window) In-Reply-To: <20060912081804.19FAF2F592@herring.ripe.net> References: <20060912081804.19FAF2F592@herring.ripe.net> Message-ID: <45067475.7060805@ripe.net> Dear Colleagues, Filiz Yilmaz wrote: > PDP Number: 2006-07 > Minimum IPv4 Assignment Window > > Dear Colleagues, > > A new RIPE Policy has been made and is now available for > discussion. > This should read "A new RIPE Policy Proposal has been made and is now available for discussion". Apologies for duplicates and any confusion. Kind regards, Filiz Yilmaz RIPE NCC Policy Development Officer > This proposal suggests the minimum Assignment Window (AW) available > to LIRs should be raised from zero (0) to /21 (2048 IPv4 addresses). > Because the sub-allocation policy references the AW policy, the > sub-allocation policy also needs to be updated. This proposal > suggests that the maximum sub-allocation should be kept at /20 (4096 > IPv4 addresses). > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2006-07.html > > We encourage you to review this proposal and send your comments to > before 10 October 2006. > > Regards > > Filiz Yilmaz > RIPE NCC > Policy Development Officer > From jeroen at unfix.org Tue Sep 12 11:15:51 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Tue, 12 Sep 2006 11:15:51 +0200 Subject: [address-policy-wg] Re:2006-06 New Policy Proposal (IPv4 Maximum Allocation Period)] In-Reply-To: <20060912090412.GA10737@ripe.net> References: <20060912090412.GA10737@ripe.net> Message-ID: <45067AC7.7090408@unfix.org> Filiz Yilmaz wrote: > PDP Number: 2006-06 IPv4 Maximum Allocation Period The subject of this proposal sounds a *lot* like: "The maximum period that an IPv4 prefix will be allocated to the LIR" while instead is meant (what I read from the rest of the text and taunted some others with who also read it differently ;) : "The maximum period over which we will ask the LIR to foresee the future developments and requests that it will make" Thus the subject is sort of misleading, maybe a better naming would be: "2006-06 Maximum Period used in Determination of New IPv4 Allocations" but I'll leave the exact wording to be filled in by the rest of the APWG members. One extra note, in case RIPE at a certain point accepts one of the "IPv6 PI" proposals, then the above might be applicable to those too. For the rest, the proposal sounds good to me, especially in light of making policies more equal globally. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From ncc at ripe.net Tue Sep 12 17:17:57 2006 From: ncc at ripe.net (Axel Pawlik) Date: Tue, 12 Sep 2006 17:17:57 +0200 Subject: [address-policy-wg] ICANN Ratifies Global Policy for Allocation of IPv6 Address Space Message-ID: <4506CFA5.7080604@ripe.net> [Apologies for duplicate e-mails.] Dear Colleagues, Please find below an announcement on behalf of the Number Resource Organization (NRO): -------------------------------------------------------------------------------------------------------------------------------------------- On 7 September 2006, the ICANN Board ratified the Global Policy for Allocation of IPv6 Address Space. This policy provides for the allocation of IPv6 address space from ICANN to the Regional Internet Registries (RIRs). On 13 July 2006, the Secretary of the Address Supporting Organization (ASO) Address Council (AC) forwarded to ICANN the proposed global policy for allocation of IPv6 address space. This proposed global policy had been submitted to the ASO AC by the Executive Council of the Number Resource Organization on 6 June 2006, and adopted by the ASO AC on 12 July 2006. Each RIR community individually discussed the policy and approved its adoption via their own policy development processes. The Global Addressing Policy document is available from the ASO website at: http://aso.icann.org/docs/aso-global-ipv6.pdf The ICANN announcement is available from the ICANN website at: http://www.icann.org/announcements/announcement-11sep06.htm nro-announce mailing list information: nro-announce at nro.net https://www.nro.net/nro-lists/listinfo/nro-announce ------------------------------------------------------------------------------------------------------------------------------------------- Regards, Axel Pawlik Managing Director RIPE NCC From gert at space.net Fri Sep 15 18:04:43 2006 From: gert at space.net (Gert Doering) Date: Fri, 15 Sep 2006 18:04:43 +0200 Subject: [address-policy-wg] DRAFT agenda for RIPE 53 address policy WG meeting Message-ID: <20060915160443.GA39272@Space.Net> Hi APWG folks, here's a first draft of an agenda for the RIPE53 address policy meeting in Amsterdam in two weeks. The meeting is scheduled for Thursday afternoon, October 5, 2006, 14:00-15:30 local time. The overall RIPE meeting outline is available at http://www.ripe.net/ripe/meetings/ripe-53/meeting-plan.html The list of plenary presentations scheduled may become available at http://www.ripe.net/ripe/meetings/ripe-53/presentations/ (empty right now) Please send me your comments pretty quickly, as we need to hand in the agenda for printing fairly soon. Gert Doering -- APWG Co-Chair --------------------------- snip ------------------------- A. Administrative Matters - Welcome - Select a scribe - Distribute participants list - Finalise agenda - Approve minutes from RIPE 52: http://www.ripe.net/ripe/wg/address-policy/r52-minutes.html - point people to mailing list B. finding of a new APWG Chair / new Co-Chair(s) - Hans-Petter Holen is proposing to step down as WG chair (and become a co-chair) due to high work load / little spare time - Andrea Borgato seems to have fallen off the net --> volunteers welcome! C. ongoing/current address policy proposals in the RIPE region * 2005-02 - IP Assignments for anycasting DNS * 2005-08 - amend IPv6 assignment and utilization requirement * 2005-12 - 4-byte AS number policy * 2006-01 - Provider Independent (PI) IPv6 assigmnets for end users * 2006-02 - IPv6 Address Allocation and Assignment Policy * 2006-04 - Contact e-mail Address Requirements * 2006-05 - (IPv4) PI Assignment Size * 2006-06 - IPv4 Maximum Allocation Period (misleading title) * 2006-07 - Minimum IPv4 Assignment Window the idea is to have a presentation by Filiz Yilmaz from the RIPE NCC (thanks!) in the plenary session on Wednesday, and discussions about individual proposals in the working group session on Thursday. For the most recent policy proposals, I think it would be a good idea to have a very brief presentation from the proposer, explaining the rationale behind the proposal. D. Update on global IANA/ICANN policies * IPv6 ICANN->RIR distribution policy update E. ongoing policy work in other regions * presentation in the plenary * plus discussion time in the WG slot Z. AOB -- Total number of prefixes smaller than registry allocations: 88685 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From gert at space.net Fri Sep 15 21:01:26 2006 From: gert at space.net (Gert Doering) Date: Fri, 15 Sep 2006 21:01:26 +0200 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <44F401BE.9030600@baycix.de> References: <20060829082515.EA0922F592@herring.ripe.net> <44F401BE.9030600@baycix.de> Message-ID: <20060915190126.GF20002@Space.Net> Hi, On Tue, Aug 29, 2006 at 10:58:38AM +0200, Sascha Lenz wrote: > . o O(and i really wonder why there's still no rant about global routing > table size increase by allowing routing issues to be PI-assignment > relevant..) Because it doesn't make a difference. It just means "people will no longer lie to the RIPE hostmasters". What I am really worried about is people getting "lots and lots" of PI, and using multiple routing table slots, instead of getting a reasonable chunk of addresses (however named), and announcing only *one* route. (I'm not talking about TE - this is a can of worms in itself - but about "poor address planning" or "using PI as a substitute for becoming a LIR") Gert Doering -- APWG Co-Chair -- Total number of prefixes smaller than registry allocations: 94488 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From nick at inex.ie Fri Sep 15 23:26:29 2006 From: nick at inex.ie (Nick Hilliard) Date: Fri, 15 Sep 2006 22:26:29 +0100 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <20060915190126.GF20002@Space.Net> References: <20060829082515.EA0922F592@herring.ripe.net> <44F401BE.9030600@baycix.de> <20060915190126.GF20002@Space.Net> Message-ID: <1158355589.98123.20.camel@crumpet.netability.ie> On Fri, 2006-09-15 at 21:01 +0200, Gert Doering wrote: > What I am really worried about is people getting "lots and lots" of PI, > and using multiple routing table slots, instead of getting a reasonable > chunk of addresses (however named), and announcing only *one* route. This is a critical concern. As it stands, 2006-05 will do little but encourage rampant use of PI space by removing the psychological barrier of lying to RIPE. This is a bad thing: routing tables have once again grown to the extent that they have burst commonly used equipment - the current problem is with dual-stacked SUP720 pfc3a/b modules which now do not have enough tcam to deal with > 192K ipv4 prefixes in their default configuration (although this can be manually tweaked at the inconvenience of a reboot). But we all know this already. I've previously expressed opinions on address-policy-wg about the necessity of charging for PI space, both as a means for discouraging its assignment and for providing a legitimate means to reclaim dead IP space. I have to be honest here and say that this issue needs to be addressed rather more urgently than the proposals in 2006-05. We can continue to lie to RIPE on PI application forms, and they will continue to pretend to believe us so long as the figures add up correctly. But in the interim, PI address space is being lost from the global v4 address pool like a bad memory leak which everyone knows about but no-one wants to fix. Nick From andy at nosignal.org Sat Sep 16 19:47:48 2006 From: andy at nosignal.org (Andy Davidson) Date: Sat, 16 Sep 2006 18:47:48 +0100 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <20060915190126.GF20002@Space.Net> References: <20060829082515.EA0922F592@herring.ripe.net> <44F401BE.9030600@baycix.de> <20060915190126.GF20002@Space.Net> Message-ID: On 15 Sep 2006, at 20:01, Gert Doering wrote: > On Tue, Aug 29, 2006 at 10:58:38AM +0200, Sascha Lenz wrote: >> . o O(and i really wonder why there's still no rant about global >> routing >> table size increase by allowing routing issues to be PI-assignment >> relevant..) > Because it doesn't make a difference. > It just means "people will no longer lie to the RIPE hostmasters". > What I am really worried about is people getting "lots and lots" of > PI, > and using multiple routing table slots, instead of getting a > reasonable > chunk of addresses (however named), and announcing only *one* route. There is a real risk that networks due to router resource constraints, who already filter on shorter-than-/24 prefixes will have to cope with any routing table growth by filtering on /23, /22, etc. If we accept argument that we should, as a community, advocate no smaller PI assignments smaller than a /24 because of table filtration, what happens when the table grows to the size that operators start to filter on longer masks ? Andy From gert at space.net Mon Sep 18 17:52:51 2006 From: gert at space.net (Gert Doering) Date: Mon, 18 Sep 2006 17:52:51 +0200 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: References: <20060829082515.EA0922F592@herring.ripe.net> <44F401BE.9030600@baycix.de> <20060915190126.GF20002@Space.Net> Message-ID: <20060918155251.GZ20002@Space.Net> Hi, On Sat, Sep 16, 2006 at 06:47:48PM +0100, Andy Davidson wrote: > If we accept argument that we should, as a community, advocate no > smaller PI assignments smaller than a /24 because of table > filtration, what happens when the table grows to the size that > operators start to filter on longer masks ? In that case, PI receipients holding a /24 suddenly are without connectivity to these networks - and will start yelling at RIPE. Which is basically the point while RIPE (and the RIPE NCC) has previously always refused to make any statements regarding the routeability of a given network size. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 94488 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From gert at space.net Mon Sep 18 17:58:22 2006 From: gert at space.net (Gert Doering) Date: Mon, 18 Sep 2006 17:58:22 +0200 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <44F41A4A.6050907@nethinks.com> References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> Message-ID: <20060918155822.GA20002@Space.Net> Hi, On Tue, Aug 29, 2006 at 12:43:22PM +0200, Garry Glendown wrote: > What's the point in making end users (as in Companies, etc.) register as > an LIR just because they want (or need) a network of their own? Discouragement. There are some end users where "everyone agrees" that PI space is a "must", and then there are some where renumbering really would be quick and mostly painless. I strongly think that the latter kind should not be able to get PI space easily, for a one-time-fee, and burden the *recurring cost* for their convenience on everybody else. If we make PI cost a "reasonable" price (like "extra-small LIR") per year, this will not hinder networks that "must have" PI very much - and those that find PI a nice and cheap convenience might reconsider. [..] > If the amount of prefixes were a reason, shouldn't ISPs be (en)forced to > aggregate their announcements? If someone has a good idea how to tackle that, I'd like to hear about it. Really. (But this is only remotely relevant to the ongoing discussion) [..] > Rather, in order to discourage PI usage by endusers who don't actually > need a PI network from a technical standpoint, why not charge an > appropriate amount for assigning PI networks? That's the idea. > Please correct me if I got > this wrong, but at the moment, PI networks count towards the LIR's > rating. Which means "the LIR pays", which hopefully translates into "the PI holder pays". The problem with the current scheme is that it's a one-time fee, payable only in the year of PI assignment (!), and after that, the PI is free. > Which can end up - in a way - to be unfair, as PI networks are > requested for end customer, which may at some point in the future switch > providers. The points are still counted, even though the provider does > not have any revenue to count against it. No. The LIR is charged only in the year of PI assignment. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 94488 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From mike at linx.net Mon Sep 18 18:20:28 2006 From: mike at linx.net (Mike Hughes) Date: Mon, 18 Sep 2006 17:20:28 +0100 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <20060918155822.GA20002@Space.Net> References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> Message-ID: <1784A354CCBFF95A58C0945F@Rangitoto.linx.net> --On 18 September 2006 17:58 +0200 Gert Doering wrote: > The problem with the current scheme is that it's a one-time fee, payable > only in the year of PI assignment (!), and after that, the PI is free. This is important given that there *is* an ongoing cost of PI space (e.g. operating the databases which say who's been allocated what), and this is set to increase if anything, with the plans to digitally sign allocations/assignments in order to increase the security of the routing system (e.g. sBGP). I find myself more in favour of having to "lease" number resources, as long as the cost is reasonable (and we can see to that because of the "bottom-up" process that exists), rather than "buy" them. This will, if anything, help with resource reclamation and re-cycling in the longer term. Regards, Mike -- Mike Hughes Chief Technical Officer London Internet Exchange mike at linx.net http://www.linx.net/ From jeroen at unfix.org Mon Sep 18 18:33:54 2006 From: jeroen at unfix.org (Jeroen Massar) Date: Mon, 18 Sep 2006 18:33:54 +0200 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <1784A354CCBFF95A58C0945F@Rangitoto.linx.net> References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <1784A354CCBFF95A58C0945F@Rangitoto.linx.net> Message-ID: <450ECA72.6030809@spaghetti.zurich.ibm.com> Mike Hughes wrote: > --On 18 September 2006 17:58 +0200 Gert Doering wrote: > >> The problem with the current scheme is that it's a one-time fee, payable >> only in the year of PI assignment (!), and after that, the PI is free. > > This is important given that there *is* an ongoing cost of PI space (e.g. > operating the databases which say who's been allocated what), and this is > set to increase if anything, with the plans to digitally sign > allocations/assignments in order to increase the security of the routing > system (e.g. sBGP). > > I find myself more in favour of having to "lease" number resources, as long > as the cost is reasonable (and we can see to that because of the > "bottom-up" process that exists), rather than "buy" them. > > This will, if anything, help with resource reclamation and re-cycling in > the longer term. Leasing sounds good in my book too, especially with schemes like sBGP this will also become easier, as the certificate used for announcing the prefix will have an expiration date, the date of the renewal. Folks who didn't pay their fees automatically loose their ability to announce their prefix. As such sBGP (or a similar method) will introduce quite a new internet era: high security routes, unless an ISP gets compromised, and also the ability to make prefixes illegal very easily. With such a scheme an organization will lease a prefix for X amount of years, they can then in advance of the end date already opt for a refresh of the prefix. Of course, where possible the RIR should make it possible for the leaser to get the same prefix over and over, avoiding the needs to renumber. When the leaser doesn't extend the prefix lease on time the lease expires and the prefix is returned to the free pool. Greets, Jeroen (who indeed would like to see a scheme like sBGP deployed :) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From oliver at bartels.de Mon Sep 18 18:44:37 2006 From: oliver at bartels.de (Oliver Bartels) Date: Mon, 18 Sep 2006 18:44:37 +0200 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <20060918155822.GA20002@Space.Net> Message-ID: <200609181642.k8IGgw9P011043@alpha.bartels.de> Hi Gert, On Mon, 18 Sep 2006 17:58:22 +0200, Gert Doering wrote: >I strongly think that the latter kind should not be able to get PI space >easily, for a one-time-fee, and burden the *recurring cost* for their >convenience on everybody else. Your approach sounds like "Planwirtschaft" and generating jobs for buerocrates ("right-to-use PI certification agency auditing office supervisor" ;-/ How about taking the potential money received for PI to finance a better BGP / routing technology or at least memory for poor ISP's ? If we would handle other network technological issues like the "PI is impossible - large tables are impossible" one, we probably would have a "right-to-use-a-9600-baud-modem certification agency" instead of DSL, just because someone would argument that it is impossible to have more than 10 high speed channels on a standard 1000 phone lines copper cable ... Do you remember the old "private modems are bad and will destroy the phone network" arguments from former Bundespost ? The PI routing issue is a technical challenge which cries for an technical solution (yes, large distributed databases do exist) and not for an additional administration. Best Regards Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From oliver at bartels.de Mon Sep 18 18:52:37 2006 From: oliver at bartels.de (Oliver Bartels) Date: Mon, 18 Sep 2006 18:52:37 +0200 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <450ECA72.6030809@spaghetti.zurich.ibm.com> Message-ID: <200609181650.k8IGow9P012059@alpha.bartels.de> Hi Jeroen, On Mon, 18 Sep 2006 18:33:54 +0200, Jeroen Massar wrote: > (who indeed would like to see a scheme like sBGP deployed :) The sBGP will consume _significantly_ more resources in the network for even a small amount of sBGP prefixes than PI will consume ever. Crypto Algos require a lot of computational power on conventional CPU's, the very huge majority of backbone routers has no special crypto hardware on board. _If_ sBGB should be implemented, I do sugest to make the BGP PI-friendly (e.g. separation of prefix and AS attributes) in the same step, as sBGB will require an router hardware and software update anyway. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From gert at space.net Mon Sep 18 21:55:56 2006 From: gert at space.net (Gert Doering) Date: Mon, 18 Sep 2006 21:55:56 +0200 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <200609181650.k8IGow9P012059@alpha.bartels.de> References: <450ECA72.6030809@spaghetti.zurich.ibm.com> <200609181650.k8IGow9P012059@alpha.bartels.de> Message-ID: <20060918195555.GB20002@Space.Net> Hi, On Mon, Sep 18, 2006 at 06:52:37PM +0200, Oliver Bartels wrote: > On Mon, 18 Sep 2006 18:33:54 +0200, Jeroen Massar wrote: > > (who indeed would like to see a scheme like sBGP deployed :) > > The sBGP will consume _significantly_ more resources in the > network for even a small amount of sBGP prefixes than PI will > consume ever. There is no need to run the sBGP crypto on all routers on all prefixes in realtime. Especially not on "session startup" time - assuming that a significant set of your neighbour routers have been doing sBGP verification on a largish subset of the routes in their tables, doing the verification as a low-prio thing (and dropping BGP prefixes that fail verification) should suffice. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 94488 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From gert at space.net Mon Sep 18 21:59:35 2006 From: gert at space.net (Gert Doering) Date: Mon, 18 Sep 2006 21:59:35 +0200 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <200609181642.k8IGgw9P011043@alpha.bartels.de> References: <20060918155822.GA20002@Space.Net> <200609181642.k8IGgw9P011043@alpha.bartels.de> Message-ID: <20060918195934.GC20002@Space.Net> Hi, On Mon, Sep 18, 2006 at 06:44:37PM +0200, Oliver Bartels wrote: > The PI routing issue is a technical challenge which > cries for an technical solution (yes, large distributed databases > do exist) and not for an additional administration. Of course I hope for a technical solution that will solve everything. Until then, I do my best to make sure the network will continue running - and part of that effort is to make sure that costs are at least partially paid by those that have the benefits. If you look at the statistics, you see a significant upturn in PI usage over the last years, and we *do* seem to have exponential growth there. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 94488 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From nick at inex.ie Mon Sep 18 23:07:36 2006 From: nick at inex.ie (Nick Hilliard) Date: Mon, 18 Sep 2006 22:07:36 +0100 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <200609181642.k8IGgw9P011043@alpha.bartels.de> References: <200609181642.k8IGgw9P011043@alpha.bartels.de> Message-ID: <1158613656.72512.74.camel@crumpet.netability.ie> > How about taking the potential money received for PI to finance > a better BGP / routing technology or at least memory for poor > ISP's ? Can we please kill this "let's get RIPE/NCC to charge more money for X so that we can give it to Y" idea for once and for all? The RIPE NCC is not a taxation agency. Let's not waste time proposing to turn it into one. > Do you remember the old "private modems are bad and will > destroy the phone network" arguments from former Bundespost ? Yes, we all remember that. Just as we remember the times when - due to routing table growth - a whole pile of different types of equipment were rendered defunct due to their inability to deal with a full routing table, whether through RIB or FIB memory deficiency. At each stage, this cost ISPs a lot of money to rectify. The Bundespost argument (repeated by pretty much all telcos worldwide, as far as I can tell) was to a large extent FUD based on presumption and fear of the unknown. Routing table growth is a well defined phenomenon which costs real money to deal with. [Incidentally, we also remember the NFSnet $15 domain tax and the way that it was declared illegal.] > The PI routing issue is a technical challenge which > cries for an technical solution (yes, large distributed databases > do exist) and not for an additional administration. The "PI routing issue" does not exist, at least in the terms that you're using here. What exists is a large growth in routing table size, due to - inter-alia - PI announcements, PA subnet announcements and the fast organic growth of full PA netblocks. Also, large distributed databases are of no real relevance to switching IP packets at 10G speeds. However, this is not particularly relevant to proposal 2006-05. The proposal may - slightly - increase the rate of uptake of PI assignments in the RIPE catchment area, and this may proportionally increase the number of prefixes in the routing tables. But the only thing that's stopping people from registering /24's at the moment where they really need less than this amount of space, is their inclination not to lie to RIPE. Removing this (almost) requirement to lie to get a /24 is not going to open up the flood gates and cause the internet to collapse. Nick From nick at inex.ie Mon Sep 18 23:37:02 2006 From: nick at inex.ie (Nick Hilliard) Date: Mon, 18 Sep 2006 22:37:02 +0100 Subject: [address-policy-wg] 2006-05 / PI Assignment Size - brief address wastage analysis Message-ID: <1158615422.72512.92.camel@crumpet.netability.ie> As of yesterday, there were ~18000 ASSIGNED PI netblocks in the RIPE DB, comprising a mixture of recently assigned PI blocks, and a bunch of older network blocks from the days when RIPE used to allocate /16's without too much justification. Of these 18000 blocks, about: 850 are < /24 10285 are /24 (2.5% of ASSIGNED PI space in RIPE) 2650 are /23 1650 are /22 2550 are > /22 (94.3% of ASSIGNED PI space in RIPE) >From a cursory glance, it would appear that a bunch of these assignments are misregistered or are subregistrations of other old ASSIGNED PI blocks. Particularly notable are the NRENs and the older ISPs, which would have been allocated large blocks a long time ago. These blocks are now classified as ASSIGNED PI instead of ASSIGNED PA. Much of this IP address space is aggregated in the routing tables and does not present much cause for worry from that perspective. Given that there are only ~850 assignments < /24, it would seem reasonable to assume that 2006-05 will cause only a very marginal increase in the amount of address space used for PI announcements. Therefore there seems little reason to reject the proposal because of address space wastage. Yes, a small amount of address space will be wasted, but in the grand scheme of things, very little. Nick From oliver at bartels.de Tue Sep 19 05:20:21 2006 From: oliver at bartels.de (Oliver Bartels) Date: Tue, 19 Sep 2006 05:20:21 +0200 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <1158613656.72512.74.camel@crumpet.netability.ie> Message-ID: <200609190318.k8J3Ig9P020225@alpha.bartels.de> Hi Nick, On Mon, 18 Sep 2006 22:07:36 +0100, Nick Hilliard wrote: >> How about taking the potential money received for PI to finance >> a better BGP / routing technology or at least memory for poor >> ISP's ? > >Can we please kill this "let's get RIPE/NCC to charge more money for X >so that we can give it to Y" idea for once and for all? Fully agree. I just used this argument to demonstrate the effect of "let us charge money and build administrations". >The Bundespost argument (repeated by pretty much all telcos worldwide, >as far as I can tell) was to a large extent FUD based on presumption and >fear of the unknown. Routing table growth is a well defined phenomenon >which costs real money to deal with. In the 9600 baud modem age it was also possible to use a 2 MBit/s line as the international uplink of a national ISP. Today we have to invest into fibre links which cost real money to deal with. We should think of restricting high bandwidth applications by RIPE to certain adresses and create a high speed permit agency ;-/ >The "PI routing issue" does not exist, at least in the terms that you're >using here. What exists is a large growth in routing table size, due to >- inter-alia - PI announcements, PA subnet announcements and the fast >organic growth of full PA netblocks. And most of the table growth is due de-aggregation of large prefixes into bundles of subnets in non-RIPE regions. The policy of the RIPE NCC will change _nothing_ with this, as an ISP you will have to face the fact that routers will need more resources in the future. >Also, large distributed databases are of no real relevance to switching >IP packets at 10G speeds. There are technical solutions for technical challenges ... A distributed database with 180k prefixes is not really large using todays hardware. In my opinion the "memory problem" just exists because of the sell-next-level-due-to-hardware-limits policy of some router vendors. Interesting: Take the 256 MByte roughly required on some systems for a two upstreams full table, subtract 1/4 for the OS and divide the difference by 180k, this yields about 1100 bytes per prefix. Yes, 1100 byte. You may probably store the whole written history of all PI end site companies within this space. Just for your information: - One of the backbone routers with full-mesh and full-table this email is passed over just takes 30 MBytes (!) for the whole 180k prefix RIB. And it works as expected. Just to show that things can be made better. >However, this is not particularly relevant to proposal 2006-05. The >proposal may - slightly - increase the rate of uptake of PI assignments >in the RIPE catchment area, and this may proportionally increase the >number of prefixes in the routing tables. But the only thing that's >stopping people from registering /24's at the moment where they really >need less than this amount of space, is their inclination not to lie to >RIPE. Removing this (almost) requirement to lie to get a /24 is not >going to open up the flood gates and cause the internet to collapse. Agree. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From oliver at bartels.de Tue Sep 19 05:39:06 2006 From: oliver at bartels.de (Oliver Bartels) Date: Tue, 19 Sep 2006 05:39:06 +0200 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <20060918195934.GC20002@Space.Net> Message-ID: <200609190337.k8J3bM9P021850@alpha.bartels.de> Hi Gert, On Mon, 18 Sep 2006 21:59:35 +0200, Gert Doering wrote: >Of course I hope for a technical solution that will solve everything. > >Until then, I do my best to make sure the network will continue >running - and part of that effort is to make sure that costs are >at least partially paid by those that have the benefits. This is a nice try, however I doubt you will be able to charge those who de-aggregate prefixes and thus cause the vast majority of the table growth. At the end of the day a lot of these de-aggregation results from "security concerns" since 9-11. You may try to charge Mr. Bin Laden, however there are other ones in the queue, too. To keep your network running, you may either: 1. invest or 2. filter those redundant de-agregated announcements (e.g. don't take a /24 with the same AS-path as the /16 it is contained in) However, I know the second (filter) approach _will_ cause your company which pays your salary loosing business, as your company is an transit ISP and thus your customers router will prefer the more specific of your competitor supplying the full table. This should answer the question: # If we accept argument that we should, as a community, advocate no # smaller PI assignments smaller than a /24 because of table # filtration, what happens when the table grows to the size that # operators start to filter on longer masks ? This won't happen, as doing so will cause loss of business for those transit networks which do so. Sadly enough, you should also face that there is nothing, really nothing, that the RIPE can do to stop the table growth influenced by other regions in this world. If the buzzword "security" comes up with large US telcos, this is the end of all discussions in these days. The only thing restrictive policies limited to the RIPE region, as the PI /24 issue and the v6 200 customer rules cause is: - Local ISP's homed in the RIPE region only will be less competitive compared to international ISP's. - People will ly to the hostmasters :-( We should not make policies which cause said disadvantages without having any significant advantage. Best Regards Oliver Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From randy at psg.com Tue Sep 19 05:45:12 2006 From: randy at psg.com (Randy Bush) Date: Mon, 18 Sep 2006 17:45:12 -1000 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <200609190337.k8J3bM9P021850@alpha.bartels.de> References: <200609190337.k8J3bM9P021850@alpha.bartels.de> Message-ID: <450F67C8.4050201@psg.com> > This is a nice try, however I doubt you will be able to charge those > who de-aggregate prefixes and thus cause the vast majority of > the table growth. filters From president at ukraine.su Tue Sep 19 17:34:58 2006 From: president at ukraine.su (Max Tulyev) Date: Tue, 19 Sep 2006 15:34:58 +0000 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <20060918155822.GA20002@Space.Net> References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> Message-ID: <45100E22.4010507@ukraine.su> Gert Doering wrote: > If we make PI cost a "reasonable" price (like "extra-small LIR") per > year, this will not hinder networks that "must have" PI very much - and > those that find PI a nice and cheap convenience might reconsider. In this case, at first you are going to kill a small and extra-small business (I believe, it is *only* real target for those who speaks againist PI - to simplify competition for themselves) as well as non-commertial and educational requesters. Second, "PI vs LIR" deal. If one real wants own IP/AS, and ready to pay for it, this one WILL add a prefix to the global routing table, either he become a LIR or only get PI. BUT. If costs are equal, EVERY manager (who make final decision for what to pay) will take MORE "something" (IP addresses in this case) for same (or near) price. And no technician can argue with that. So instead of PI /24 they really need, they get a LIR with at least /21 they really don't need in any case. And we loose in conservation of address space in 8 times (not winning in aggregation any percent)!!! -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From president at ukraine.su Tue Sep 19 17:41:06 2006 From: president at ukraine.su (Max Tulyev) Date: Tue, 19 Sep 2006 15:41:06 +0000 Subject: [address-policy-wg] PI vs PA in routing table Message-ID: <45100F92.7080200@ukraine.su> Hello! Is there a graphs shows how much prefixes in global route table are PA and how much - PI (maybe in percents)? And also this one year-by-year (monthly?)? Maybe there is no real "route table PI pollution" trouble in the real world? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From president at ukraine.su Tue Sep 19 17:47:51 2006 From: president at ukraine.su (Max Tulyev) Date: Tue, 19 Sep 2006 15:47:51 +0000 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <200609190337.k8J3bM9P021850@alpha.bartels.de> References: <200609190337.k8J3bM9P021850@alpha.bartels.de> Message-ID: <45101127.8040500@ukraine.su> Oliver Bartels wrote: > 2. filter those redundant de-agregated announcements > (e.g. don't take a /24 with the same AS-path as the /16 > it is contained in) > > However, I know the second (filter) approach _will_ cause your > company which pays your salary loosing business, It is a good idea to set up the default route to one of upstreams when you set up filtering. This saves routers' memory, but leaves your connectivity fine. You can even accept 0.0.0.0/0 from several upstreams with different localprefs to keep channels back-up working. P.S. I don't believe backbone carriers who don't have upstreams at all need to conserve some extra kilobytes of memory ;) -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From gert at space.net Tue Sep 19 14:05:23 2006 From: gert at space.net (Gert Doering) Date: Tue, 19 Sep 2006 14:05:23 +0200 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <45100E22.4010507@ukraine.su> References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> Message-ID: <20060919120523.GP20002@Space.Net> Hi, On Tue, Sep 19, 2006 at 03:34:58PM +0000, Max Tulyev wrote: > In this case, at first you are going to kill a small and extra-small > business (I believe, it is *only* real target for those who speaks > againist PI - to simplify competition for themselves) as well as > non-commertial and educational requesters. While this is a nice argument, I don't really see why I am supposed to sponsor these entities. If they think they need to put a burden on global routing, they can pay for it - and if they think that's too expensive, they can use PA space, and renumber every now and then. Nobody is aiming to exclude people from participating in the Internet, but PI isn't the *only* way. > Second, "PI vs LIR" deal. If one real wants own IP/AS, and ready to pay > for it, this one WILL add a prefix to the global routing table, either > he become a LIR or only get PI. BUT. If costs are equal, EVERY manager > (who make final decision for what to pay) will take MORE "something" (IP > addresses in this case) for same (or near) price. And no technician can > argue with that. So instead of PI /24 they really need, they get a LIR > with at least /21 they really don't need in any case. And we loose in > conservation of address space in 8 times (not winning in aggregation any > percent)!!! Actually, I see this as a win - as soon as the /24 is full, we have a second entry in the routing table (for the next PI), while with a /21, the single routing table entry will last a lot longer. This is what is happening right now - people get multiple PI assignments, instead of a single larger block. (Besides this, nobody said that the price would have to be the *same* - I specifically mentioned the "extra small" LIR category) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 94488 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From gert at space.net Tue Sep 19 14:07:19 2006 From: gert at space.net (Gert Doering) Date: Tue, 19 Sep 2006 14:07:19 +0200 Subject: [address-policy-wg] PI vs PA in routing table In-Reply-To: <45100F92.7080200@ukraine.su> References: <45100F92.7080200@ukraine.su> Message-ID: <20060919120719.GQ20002@Space.Net> Hi, On Tue, Sep 19, 2006 at 03:41:06PM +0000, Max Tulyev wrote: > Maybe there is no real "route table PI pollution" trouble in the real world? Currently, there are much more PA entries than PI - but the problem that I see is that the PI growth rate is much higher than PA, and as such, "unlimited PI" might rise to be a problem. Nobody is proposing to disallow PI. Just balance "cost" vs. "convenience" a little bit better. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 94488 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From dmitry at volia.net Tue Sep 19 14:09:43 2006 From: dmitry at volia.net (Dmitry Kiselev) Date: Tue, 19 Sep 2006 15:09:43 +0300 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <45100E22.4010507@ukraine.su> References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> Message-ID: <20060919120943.GN56407@f17.dmitry.net> Hello! On Tue, Sep 19, 2006 at 03:34:58PM +0000, Max Tulyev wrote: > > If we make PI cost a "reasonable" price (like "extra-small LIR") per > > year, this will not hinder networks that "must have" PI very much - and > > those that find PI a nice and cheap convenience might reconsider. > > In this case, at first you are going to kill a small and extra-small > business (I believe, it is *only* real target for those who speaks > againist PI - to simplify competition for themselves) as well as > non-commertial and educational requesters. > > Second, "PI vs LIR" deal. If one real wants own IP/AS, and ready to pay > for it, this one WILL add a prefix to the global routing table, either > he become a LIR or only get PI. BUT. If costs are equal, EVERY manager > (who make final decision for what to pay) will take MORE "something" (IP > addresses in this case) for same (or near) price. And no technician can > argue with that. So instead of PI /24 they really need, they get a LIR > with at least /21 they really don't need in any case. And we loose in > conservation of address space in 8 times (not winning in aggregation any > percent)!!! Max, how say that fees will be equal? As for me, PI/24+ASN should have yearly fee acceptable for most small companies. If they really need it, they will pay for it. Once payments stoped - resources returned and ready to reassignment. -- Dmitry Kiselev From president at ukraine.su Tue Sep 19 18:09:38 2006 From: president at ukraine.su (Max Tulyev) Date: Tue, 19 Sep 2006 16:09:38 +0000 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <20060919120943.GN56407@f17.dmitry.net> References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> Message-ID: <45101642.5010003@ukraine.su> Dmitry Kiselev wrote: > Max, how say that fees will be equal? As for me, PI/24+ASN should have > yearly fee acceptable for most small companies. If they really need it, > they will pay for it. Once payments stoped - resources returned and > ready to reassignment. Seems to be very reasonable. For example, as it was a long before. But there should be a schema how I can pass mntner to client, and therefore "block" (or remove) objects in case of payment stops. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From president at ukraine.su Tue Sep 19 18:13:31 2006 From: president at ukraine.su (Max Tulyev) Date: Tue, 19 Sep 2006 16:13:31 +0000 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <20060919120523.GP20002@Space.Net> References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120523.GP20002@Space.Net> Message-ID: <4510172B.5000405@ukraine.su> Gert Doering wrote: > (Besides this, nobody said that the price would have to be the *same* - I > specifically mentioned the "extra small" LIR category) Yep, it is certainly minimum /21 PA I said ;) -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From oliver at bartels.de Tue Sep 19 15:16:44 2006 From: oliver at bartels.de (Oliver Bartels) Date: Tue, 19 Sep 2006 15:16:44 +0200 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <45101127.8040500@ukraine.su> Message-ID: <200609191315.k8JDF19P026100@alpha.bartels.de> Hi Max, ( and Randy, too, as it hits the same topic ) On Tue, 19 Sep 2006 15:47:51 +0000, Max Tulyev wrote: >It is a good idea to set up the default route to one of upstreams when >you set up filtering. This saves routers' memory, but leaves your >connectivity fine. You can even accept 0.0.0.0/0 from several upstreams >with different localprefs to keep channels back-up working. This doesn't help the transit provider who is selling upstream to BGP clients. Your default route and Randy's reduced table compete against the full unfiltered table of the other upstream. The more specific prefix _always_ wins. >P.S. I don't believe backbone carriers who don't have upstreams at all >need to conserve some extra kilobytes of memory ;) Ack. In this case there are simply some anti-competitive arguments hidden as resource conservation arguments. Best Regards Oliver Bartels Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany oliver at bartels.de + http://www.bartels.de + Tel. +49-8122-9729-0 From Michael.Dillon at btradianz.com Tue Sep 19 15:17:13 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 19 Sep 2006 14:17:13 +0100 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <20060919120523.GP20002@Space.Net> Message-ID: > Nobody is aiming to exclude people from participating in the Internet, > but PI isn't the *only* way. IP addresses (PA and PI) are not just used for the Internet. Many IP address blocks are only used on IP internetworks that are not part of the public Internet. Some of these internetworks allow limited traffic exchange with the public Internet through NAT gateways. Others allow no traffic interchange at all and enforce this with firewalls in case participants fail to maintain the air gap between their Internet connections and the other internetwork. Most of these IP address blocks, PI and PA, are not used by a military organization. They tend to be used by business federations and by companies providing a business service to customers over a non-public internetwork. RFC 2050 paragraph 3(a) specifically allows for IP address allocations/assignments to these non-Internet uses. When RIPE is making policy about IP address use, we should be careful to not be Internet-centric because that could be interpreted as anti-competition. Companies can justify PI assignments or PA allocations/assignments independently of whether they intend to connect to the public Internet. As far as participating in the Internet, not all organizations necessarily want 100% global connectivity. In particular, organizations in countries with a non-colonial language may only want connectivity to a few countries which they consider to be their "community" or their "market". For the record, colonial languages are those like English, French, Spanish, and Russian which are widely used outside of their area of origin due to a previous history as the language of empire. You can understand that a business who markets services in Hungarian might only want connectivity to Hungary, Rumania, Austria, Slovakia, and Ukraine where there is a population of Hungarian native speakers. They might do this by buying connectivity to multiple local ISPs in this region and asking those ISPs to not forward their announced route(s). That is a valid use of a PI assignment for multihoming that does not result in the use of a slot in the global routing table. --Michael Dillon P.S. my choice of Hungarian was entirely random. The same thing applies for languages like Catalan, Italian, Albanian, German, etc. From gert at space.net Tue Sep 19 15:53:14 2006 From: gert at space.net (Gert Doering) Date: Tue, 19 Sep 2006 15:53:14 +0200 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: References: <20060919120523.GP20002@Space.Net> Message-ID: <20060919135314.GV20002@Space.Net> Hi, On Tue, Sep 19, 2006 at 02:17:13PM +0100, Michael.Dillon at btradianz.com wrote: > Hungarian might only want connectivity to Hungary, Rumania, > Austria, Slovakia, and Ukraine where there is a population > of Hungarian native speakers. They might do this by buying > connectivity to multiple local ISPs in this region and asking > those ISPs to not forward their announced route(s). While this sounds like a theoretical possiblity, I haven't seen any real-world example yet (and I'm from a region with "non-colonial" language)... I do see the use of PI for "private interconnections", though - and some thought needs to go into "how to handle those", yes. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 94488 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From hank at efes.iucc.ac.il Tue Sep 19 16:51:15 2006 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 19 Sep 2006 17:51:15 +0300 (IDT) Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <45101642.5010003@ukraine.su> References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> <45101642.5010003@ukraine.su> Message-ID: On Tue, 19 Sep 2006, Max Tulyev wrote: > Dmitry Kiselev wrote: >> Max, how say that fees will be equal? As for me, PI/24+ASN should have >> yearly fee acceptable for most small companies. If they really need it, >> they will pay for it. Once payments stoped - resources returned and >> ready to reassignment. > > Seems to be very reasonable. For example, as it was a long before. Once payment stops resources are not returned (as far as my example shows below). See: http://www.ripe.net/ripe/maillists/archives/ncc-services-wg/2004/msg00100.html for an example I've been tracking for 5 years now (company bankrupt). ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt shows the following still: il.doarnet DoarNet Ltd. 19981211 212.77.128/19 ALLOCATED PA So in theory your idea sounds nice. In practice it doesn't work. Regards, -Hank Nussbacher http://www.interall.co.il From david.conrad at icann.org Tue Sep 19 17:56:20 2006 From: david.conrad at icann.org (David Conrad) Date: Tue, 19 Sep 2006 08:56:20 -0700 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <45100E22.4010507@ukraine.su> References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> Message-ID: > (I believe, it is *only* real target for those who speaks > againist PI - to simplify competition for themselves) Um. No. It is also people who have experienced the "joys" of watching routers falls over (and the subsequent cascading failures) because of too much routing information and who wish to avoid similar happy experiences in the future. Simply, PI to network topological leaves doesn't scale. Rgds, -drc "Those who cannot remember the past are condemned to repeat it." -- George Santayana From president at ukraine.su Tue Sep 19 20:30:33 2006 From: president at ukraine.su (Max Tulyev) Date: Tue, 19 Sep 2006 22:30:33 +0400 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> <45101642.5010003@ukraine.su> Message-ID: <45103749.9020407@ukraine.su> Hi Hank! This story is about PA/LIR, where (again, in the theory) all is quite simply. No money -> closing contarct (as in terms of it) -> getting back IPs. But. If there is PI space (and ASes not associated with LIR company) - there is also third party: end-user. He shouldn't have any troubles if LIR goes out of business or became unlucky in it. I have a large experience in providing PI/AS (even own a LIR with primary service is PI assignment i ex-USSR). My opinion is: 1. PI is a GOOD thing. 1a. It stimulates small and medium business, providing Internet in regions with a lack of money. Yes, EUR2000 really can be a yearly turnover of small Internet company here. 1b. It conserves IP space (people do request as many space as they really need, not /21 "because it is given at LIR startup") 2. PI and AS SHOULD be billed in the regular basis (yearly, quarterly or so). This pervents dead IP space beeing locked. 3. There shoud be an mechanism (NOT mntner as it is now) to suspend and remove address space if there is no payments. Again, _not_ LIR's mntner in object. 4. There should be clear and simply mechanism ("what-to-do, step-by-step") how PI end-user can change LIR if something goes wrong (LIR is out of business, and even LIR goes mad). 4a. This mechanism should be quite easy and clear so anyone can get rid in it in ten minutes, therefore there should be something to stop user switching between LIRs looking where is cheaper (and in practice, killing the market by some inadequate players will do demping). 5. Of course, RIPE (LIR?) should check actuality of contact information of that kind of objects. Or if not really check - have an ability to suspend objects if this information is invalid (i.e. RIPE can't contact user with that information). Yes, I think there should be "suspended" objects: not visible in the database (or visible with some flag, but not routeable - without route objects or so). These objects can be returned to life in some cases (user at least payed a bill, provided actual contacts or so) or wiped in some other cases. Maybe, we should learn things from domain name registering systems. If it is interesting, I can do something like presentation or policy draft? So it is a good topic to talk at the RIPE meeting anyway ;) Hank Nussbacher wrote: > On Tue, 19 Sep 2006, Max Tulyev wrote: > >> Dmitry Kiselev wrote: >>> Max, how say that fees will be equal? As for me, PI/24+ASN should have >>> yearly fee acceptable for most small companies. If they really need it, >>> they will pay for it. Once payments stoped - resources returned and >>> ready to reassignment. >> >> Seems to be very reasonable. For example, as it was a long before. > > Once payment stops resources are not returned (as far as my example > shows below). See: > http://www.ripe.net/ripe/maillists/archives/ncc-services-wg/2004/msg00100.html > > for an example I've been tracking for 5 years now (company bankrupt). > > ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt > shows the following still: > il.doarnet > DoarNet Ltd. > > 19981211 212.77.128/19 ALLOCATED PA > > So in theory your idea sounds nice. In practice it doesn't work. > > Regards, > -Hank Nussbacher > http://www.interall.co.il > -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From president at ukraine.su Tue Sep 19 20:37:18 2006 From: president at ukraine.su (Max Tulyev) Date: Tue, 19 Sep 2006 22:37:18 +0400 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> Message-ID: <451038DE.5030900@ukraine.su> David Conrad wrote: > Simply, PI to network topological leaves doesn't scale. I think it is not an argument for PI. You also can't scale PA when it ends. You only can allocate new one. It is an argument for thinking before doing. Best way is to set up period of requesting, i.e. one company can do same kind of requests for example once in two years. It makes a company think twice about scaling ("do we requesting enough space for our grow?") and about conserving ("we have to pay more for more space"). -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From david.conrad at icann.org Tue Sep 19 22:16:04 2006 From: david.conrad at icann.org (David Conrad) Date: Tue, 19 Sep 2006 13:16:04 -0700 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <451038DE.5030900@ukraine.su> References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <451038DE.5030900@ukraine.su> Message-ID: Max, On Sep 19, 2006, at 11:37 AM, Max Tulyev wrote: > David Conrad wrote: >> Simply, PI to network topological leaves doesn't scale. > I think it is not an argument for PI. Right. It is an argument against PI. > You also can't scale PA when it > ends. You only can allocate new one. The difference, of course, is that PA (by definition) can be aggregated into a single announcement, thereby reducing the amount of information sloshing around the routing system. It is true that if an ISP runs out of PA prefixes to assign to their customers that they'll need to get another one and that additional prefix will need to be PI, but that is a single prefix that aggregates all the customers numbered out of that prefix. This is Routing Scalability 101. > It is an argument for thinking before doing. Best way is to set up > period of requesting, i.e. one company can do same kind of requests > for > example once in two years. It makes a company think twice about > scaling > ("do we requesting enough space for our grow?") and about conserving Even if you can have a crystal ball that predicts your future addressing requirements for arbitrary amounts of time into the future, this still has a 1:1 ratio of end user organization to routing prefix and every flap of that prefix has to get propagated globally. This simply doesn't scale. Rgds, -drc From nick at inex.ie Tue Sep 19 23:22:21 2006 From: nick at inex.ie (Nick Hilliard) Date: Tue, 19 Sep 2006 22:22:21 +0100 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <451038DE.5030900@ukraine.su> Message-ID: <45105F8D.9080605@inex.ie> > Even if you can have a crystal ball that predicts your future addressing > requirements for arbitrary amounts of time into the future, this still > has a 1:1 ratio of end user organization to routing prefix and every > flap of that prefix has to get propagated globally. Then we're stuck with a situation where on the one hand, RIPE membership is pressing for the continuation of a non-scalable addressing policy out of commercial necessity, but on the other, there are no real policy disincentives to discourage end-users from this harmful practice. This is quite an absurd situation, really. This policy inconsistency needs to be fixed urgently. And the most appropriate way of doing it is to apply both an initial and recurring charge to PI assignments. This is a reasonable system which will deal with not only the financial reality that IRRs cost money to run, but will also act as a much-needed disincentive to applying for PI space. Nick From president at ukraine.su Wed Sep 20 13:40:26 2006 From: president at ukraine.su (Max Tulyev) Date: Wed, 20 Sep 2006 11:40:26 +0000 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <451038DE.5030900@ukraine.su> Message-ID: <451128AA.6090300@ukraine.su> David Conrad wrote: >> You also can't scale PA when it >> ends. You only can allocate new one. > > The difference, of course, is that PA (by definition) can be aggregated > into a single announcement, thereby reducing the amount of information > sloshing around the routing system. It is true that if an ISP runs out > of PA prefixes to assign to their customers that they'll need to get > another one and that additional prefix will need to be PI, but that is a > single prefix that aggregates all the customers numbered out of that > prefix. This is Routing Scalability 101. Please, see the difference of just customers (who don't know anything about PI vs PA at all, using their ADSL connection and be happy) and those who need own routing policy and own IP space. You can't aggregate second one into single prefix by definition. Again, I don't even think about "portable IPs to any customer" at this stage of Internet evolution. May be a bit later? But not now. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From dmitry at volia.net Wed Sep 20 10:51:59 2006 From: dmitry at volia.net (Dmitry Kiselev) Date: Wed, 20 Sep 2006 11:51:59 +0300 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <45103749.9020407@ukraine.su> References: <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> <45101642.5010003@ukraine.su> <45103749.9020407@ukraine.su> Message-ID: <20060920085159.GO56407@f17.dmitry.net> Hi, Max! On Tue, Sep 19, 2006 at 10:30:33PM +0400, Max Tulyev wrote: > This story is about PA/LIR, where (again, in the theory) all is quite > simply. No money -> closing contarct (as in terms of it) -> getting back > IPs. > > But. If there is PI space (and ASes not associated with LIR company) - > there is also third party: end-user. He shouldn't have any troubles > if LIR goes out of business or became unlucky in it. > > I have a large experience in providing PI/AS (even own a LIR with > primary service is PI assignment i ex-USSR). > > My opinion is: > > 1. PI is a GOOD thing. > 1a. It stimulates small and medium business, providing Internet in > regions with a lack of money. Yes, EUR2000 really can be a yearly > turnover of small Internet company here. > 1b. It conserves IP space (people do request as many space as they > really need, not /21 "because it is given at LIR startup") > 2. PI and AS SHOULD be billed in the regular basis (yearly, quarterly or > so). This pervents dead IP space beeing locked. > 3. There shoud be an mechanism (NOT mntner as it is now) to suspend and > remove address space if there is no payments. Again, _not_ LIR's mntner > in object. > 4. There should be clear and simply mechanism ("what-to-do, > step-by-step") how PI end-user can change LIR if something goes wrong > (LIR is out of business, and even LIR goes mad). > 4a. This mechanism should be quite easy and clear so anyone can get rid > in it in ten minutes, therefore there should be something to stop user > switching between LIRs looking where is cheaper (and in practice, > killing the market by some inadequate players will do demping). > 5. Of course, RIPE (LIR?) should check actuality of contact information > of that kind of objects. Or if not really check - have an ability to > suspend objects if this information is invalid (i.e. RIPE can't contact > user with that information). > > Yes, I think there should be "suspended" objects: not visible in the > database (or visible with some flag, but not routeable - without route > objects or so). These objects can be returned to life in some cases > (user at least payed a bill, provided actual contacts or so) or wiped in > some other cases. > > Maybe, we should learn things from domain name registering systems. > > If it is interesting, I can do something like presentation or policy > draft? So it is a good topic to talk at the RIPE meeting anyway ;) According to current IPv4 Address Policy PI address space should be ASSIGNED to END USERS ONLY. ISP usually provide service for some (or many) organizations, i.e. contact info for some ranges may be very different. Although ISP is close to its customers they are different companies - end-users in Policy terms. ISP with PI can't create separate DB records and it is violate section 4.0 of Policy. It is violate item 5 from Your opinion quoted above too. ;) Since PA have no such disadvantages and have a good scale capability it should be used by ISPs. PI is still good for small/medium *enterprises* which large enough to do multihoming. > > On Tue, 19 Sep 2006, Max Tulyev wrote: > > > >> Dmitry Kiselev wrote: > >>> Max, how say that fees will be equal? As for me, PI/24+ASN should have > >>> yearly fee acceptable for most small companies. If they really need it, > >>> they will pay for it. Once payments stoped - resources returned and > >>> ready to reassignment. > >> > >> Seems to be very reasonable. For example, as it was a long before. > > > > Once payment stops resources are not returned (as far as my example > > shows below). See: > > http://www.ripe.net/ripe/maillists/archives/ncc-services-wg/2004/msg00100.html > > > > for an example I've been tracking for 5 years now (company bankrupt). > > > > ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt > > shows the following still: > > il.doarnet > > DoarNet Ltd. > > > > 19981211 212.77.128/19 ALLOCATED PA > > > > So in theory your idea sounds nice. In practice it doesn't work. > > -- > WBR, > Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) -- Dmitry Kiselev From Michael.Dillon at btradianz.com Wed Sep 20 11:17:32 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 20 Sep 2006 10:17:32 +0100 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: Message-ID: > Simply, PI to network topological leaves doesn't scale. On the contrary, PI *DOES* scale and it has scaled because there is no direct one-to-one connection between issuing a PI assignment and consuming a global routing table slot. Far more worrisome is the practice of issuing multiple non-aggregatable blocks to a single AS and the tendency of some ASes to use multiple global routing table slots for traffic engineering. Those things have greater impact on global routing table size than the number of new PI blocks. In addition, there is no consensus that the global routing table is becoming too big for providers to cope. If there was an imminent problem, then network operators would be meeting in public forums to define the scope of the problem and to agree on actions to mitigate the problem. If that were happening then RIPE could leverage the existence of this consortium of network operators to incorporate global routing table issues into its policies. But since this hypothetical consortium does not currently exist, RIPE can find nobody to take responsibility for global routing table impact and therefore cannot include global routing table size in its policies. --Michael Dillon From gert at space.net Wed Sep 20 12:13:41 2006 From: gert at space.net (Gert Doering) Date: Wed, 20 Sep 2006 12:13:41 +0200 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: References: Message-ID: <20060920101341.GF20002@Space.Net> Hi, On Wed, Sep 20, 2006 at 10:17:32AM +0100, Michael.Dillon at btradianz.com wrote: > But since this hypothetical consortium does not currently exist, > RIPE can find nobody to take responsibility for global routing > table impact and therefore cannot include global routing table > size in its policies. Invalid conclusion. *We* are RIPE. *You* are part of RIPE. So of course the RIPE policies can consider routing table impact. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 94488 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From Michael.Dillon at btradianz.com Wed Sep 20 12:51:45 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 20 Sep 2006 11:51:45 +0100 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <20060920101341.GF20002@Space.Net> Message-ID: > Invalid conclusion. *We* are RIPE. *You* are part of RIPE. > > So of course the RIPE policies can consider routing table impact. RIPE represents network operators from one of the 5 regions of the world which share the global routing table. How can RIPE reasonably deal with such a global issue unilaterally? Currently, the interdomain routing system requires a flat non-hierarchical architecture for the global routing table. Unless RIPE introduces some sort of routing model which involves a European routing table that carries more detail than the global routing table, then RIPE should not accept any responsibility at all for the use of global routing table slots. The decisions about the use of routing table slots are not made within RIPE. They are private decisions of private organizations outside of the RIPE terms of reference. --Michael Dillon From nick at inex.ie Wed Sep 20 13:11:36 2006 From: nick at inex.ie (Nick Hilliard) Date: Wed, 20 Sep 2006 12:11:36 +0100 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: References: Message-ID: <1158750696.12375.42.camel@pancake.netability.ie> On Wed, 2006-09-20 at 11:51 +0100, Michael.Dillon at btradianz.com wrote: > RIPE represents network operators from one of the 5 > regions of the world which share the global routing table. > How can RIPE reasonably deal with such a global issue > unilaterally? RIPE is not an island and no matter how much we'd like to pretend otherwise, RIPE addressing policies cannot be meaningfully divorced from the population of routing table slots. You're free to agree or disagree with this, but the bottom line is that if RIPE changes its policies on PI assignment, this is likely to impact the number of announced PI prefixes, regardless of whether the announcements are accepted or not. Also, RIPE is not dealing with this unilaterally. It's dealing with the issue in its own area, which is what it's mandated to do by its members and charged to do by ICANN. If it makes policies in one particular area, these policies are not directly relevant in other parts of the world, unless other RIR areas in the world decide that they want to adopt similar policies. Nick -- Network Ability Ltd. | Head of Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick at inex.ie From abramov at demos.net Wed Sep 20 14:21:27 2006 From: abramov at demos.net (Gennady Abramov) Date: Wed, 20 Sep 2006 16:21:27 +0400 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <20060920085159.GO56407@f17.dmitry.net> References: <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> <45101642.5010003@ukraine.su> <45103749.9020407@ukraine.su> <20060920085159.GO56407@f17.dmitry.net> Message-ID: <20060920122127.GD1581@demos.net> On Wed, Sep 20, 2006 at 11:51:59AM +0300, Dmitry Kiselev wrote: > > This story is about PA/LIR, where (again, in the theory) all is quite > > simply. No money -> closing contarct (as in terms of it) -> getting back > > IPs. > > According to current IPv4 Address Policy PI address space should be > ASSIGNED to END USERS ONLY. ISP usually provide service for some > (or many) organizations, i.e. contact info for some ranges may be > very different. Although ISP is close to its customers they are > different companies - end-users in Policy terms. ISP with PI can't > create separate DB records and it is violate section 4.0 of Policy. > It is violate item 5 from Your opinion quoted above too. ;) > > Since PA have no such disadvantages and have a good scale capability > it should be used by ISPs. PI is still good for small/medium > *enterprises* which large enough to do multihoming. And, don't forget that you even can do multihoming without PI address space, by multihoming of PA assigment (if LIR permitted it). The only advantage of PI's is that customer doesn't needs to be renumbered if he leaves his primary ISP. > > > > > On Tue, 19 Sep 2006, Max Tulyev wrote: > > > > > >> Dmitry Kiselev wrote: > > >>> Max, how say that fees will be equal? As for me, PI/24+ASN should have > > >>> yearly fee acceptable for most small companies. If they really need it, > > >>> they will pay for it. Once payments stoped - resources returned and > > >>> ready to reassignment. > > >> > > >> Seems to be very reasonable. For example, as it was a long before. > > > > > > Once payment stops resources are not returned (as far as my example > > > shows below). See: > > > http://www.ripe.net/ripe/maillists/archives/ncc-services-wg/2004/msg00100.html > > > > > > for an example I've been tracking for 5 years now (company bankrupt). > > > > > > ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt > > > shows the following still: > > > il.doarnet > > > DoarNet Ltd. > > > > > > 19981211 212.77.128/19 ALLOCATED PA > > > > > > So in theory your idea sounds nice. In practice it doesn't work. > > > > -- > > WBR, > > Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) > > -- > Dmitry Kiselev -- Regards, Gennady Abramov, CCNP, AGV77-RIPE Demos-Internet NOC Phone: +7 (495) 737-0436 http://www.demos.ru/address From nick at inex.ie Wed Sep 20 15:54:09 2006 From: nick at inex.ie (Nick Hilliard) Date: Wed, 20 Sep 2006 14:54:09 +0100 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <20060920122127.GD1581@demos.net> References: <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> <45101642.5010003@ukraine.su> <45103749.9020407@ukraine.su> <20060920085159.GO56407@f17.dmitry.net> <20060920122127.GD1581@demos.net> Message-ID: <1158760449.12375.86.camel@pancake.netability.ie> > And, don't forget that you even can do multihoming without PI address > space, by multihoming of PA assigment (if LIR permitted it). It's nothing to do with your LIR. You can only do this if your secondary upstream agrees to it. Your LIR can shout and jump up and down and tell you not to do this, but they can't stop their competitor from leaking a prefix which they really shouldn't. Fortunately, most ISPs won't do this sort of thing. Nick From dmitry at volia.net Wed Sep 20 15:56:19 2006 From: dmitry at volia.net (Dmitry Kiselev) Date: Wed, 20 Sep 2006 16:56:19 +0300 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <20060920122127.GD1581@demos.net> References: <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> <45101642.5010003@ukraine.su> <45103749.9020407@ukraine.su> <20060920085159.GO56407@f17.dmitry.net> <20060920122127.GD1581@demos.net> Message-ID: <20060920135619.GP56407@f17.dmitry.net> Hi! On Wed, Sep 20, 2006 at 04:21:27PM +0400, Gennady Abramov wrote: > > > This story is about PA/LIR, where (again, in the theory) all is quite > > > simply. No money -> closing contarct (as in terms of it) -> getting back > > > IPs. > > > > According to current IPv4 Address Policy PI address space should be > > ASSIGNED to END USERS ONLY. ISP usually provide service for some > > (or many) organizations, i.e. contact info for some ranges may be > > very different. Although ISP is close to its customers they are > > different companies - end-users in Policy terms. ISP with PI can't > > create separate DB records and it is violate section 4.0 of Policy. > > It is violate item 5 from Your opinion quoted above too. ;) > > > > Since PA have no such disadvantages and have a good scale capability > > it should be used by ISPs. PI is still good for small/medium > > *enterprises* which large enough to do multihoming. > And, don't forget that you even can do multihoming without PI address > space, by multihoming of PA assigment (if LIR permitted it). > The only advantage of PI's is that customer doesn't needs to be > renumbered if he leaves his primary ISP. ...and does not pay any money! ;) It is major argument for most of PI holders. > > > >>> Max, how say that fees will be equal? As for me, PI/24+ASN should have > > > >>> yearly fee acceptable for most small companies. If they really need it, > > > >>> they will pay for it. Once payments stoped - resources returned and > > > >>> ready to reassignment. > > > >> > > > >> Seems to be very reasonable. For example, as it was a long before. > > > > > > > > Once payment stops resources are not returned (as far as my example > > > > shows below). See: > > > > http://www.ripe.net/ripe/maillists/archives/ncc-services-wg/2004/msg00100.html > > > > > > > > for an example I've been tracking for 5 years now (company bankrupt). > > > > > > > > ftp://ftp.ripe.net/pub/stats/ripencc/membership/alloclist.txt > > > > shows the following still: > > > > il.doarnet > > > > DoarNet Ltd. > > > > > > > > 19981211 212.77.128/19 ALLOCATED PA > > > > > > > > So in theory your idea sounds nice. In practice it doesn't work. -- Dmitry Kiselev From president at ukraine.su Wed Sep 20 20:03:09 2006 From: president at ukraine.su (Max Tulyev) Date: Wed, 20 Sep 2006 18:03:09 +0000 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <20060920122127.GD1581@demos.net> References: <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> <45101642.5010003@ukraine.su> <45103749.9020407@ukraine.su> <20060920085159.GO56407@f17.dmitry.net> <20060920122127.GD1581@demos.net> Message-ID: <4511825D.6080102@ukraine.su> Gennady Abramov wrote: > And, don't forget that you even can do multihoming without PI address > space, by multihoming of PA assigment (if LIR permitted it). Multihoming, but not backups. Because of some traffic will flow through [aggregated] LIR route if even link with LIR will be damaged. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From president at ukraine.su Wed Sep 20 20:10:47 2006 From: president at ukraine.su (Max Tulyev) Date: Wed, 20 Sep 2006 18:10:47 +0000 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <20060920135619.GP56407@f17.dmitry.net> References: <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> <45101642.5010003@ukraine.su> <45103749.9020407@ukraine.su> <20060920085159.GO56407@f17.dmitry.net> <20060920122127.GD1581@demos.net> <20060920135619.GP56407@f17.dmitry.net> Message-ID: <45118427.5090300@ukraine.su> Dmitry Kiselev wrote: > ...and does not pay any money! ;) It is major argument for most of > PI holders. You know, nothing is strengthen user's confidence as well as prepayment ;) -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From president at ukraine.su Wed Sep 20 20:32:33 2006 From: president at ukraine.su (Max Tulyev) Date: Wed, 20 Sep 2006 18:32:33 +0000 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <20060920143125.GF1581@demos.net> References: <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> <45101642.5010003@ukraine.su> <45103749.9020407@ukraine.su> <20060920085159.GO56407@f17.dmitry.net> <20060920122127.GD1581@demos.net> <4511825D.6080102@ukraine.su> <20060920143125.GF1581@demos.net> Message-ID: <45118941.4010401@ukraine.su> Gennady Abramov wrote: > On Wed, Sep 20, 2006 at 06:03:09PM +0000, Max Tulyev wrote: >> Gennady Abramov wrote: >>> And, don't forget that you even can do multihoming without PI address >>> space, by multihoming of PA assigment (if LIR permitted it). >> Multihoming, but not backups. Because of some traffic will flow through >> [aggregated] LIR route if even link with LIR will be damaged. > It is very some traffic. > Some traffic flows on default gateway, even if you have BGP full view on > the router... :) > Normally, longest prefix has highest priority. If your > multihomed prefix doesn't exist in some part of Internet, you may have > troubles with connectivity with this part of Internet, don't looking PA > or PI addresses you uses. > In the case of PA specific, traffic from this part of Internet will flow > to aggregated route, and, if specific route would be found on next hops, > will go to specific route from this next hops. > In the case of PI, traffic will flow to default or will be dropped. > Anyway, if your prefix doesn't routed anywhere, it isn't normal > situation, don't depend of addresses u use. Good only in the theory ;) IRL some "wise" admins filters out more specific if there is less specific (? - as I can understand this). This means some part of Internet will be not accessible if there is no link between you and your LIR. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From Michael.Dillon at btradianz.com Wed Sep 20 17:25:47 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 20 Sep 2006 16:25:47 +0100 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <1158760449.12375.86.camel@pancake.netability.ie> Message-ID: > It's nothing to do with your LIR. You can only do this if your > secondary upstream agrees to it. Your LIR can shout and jump up and > down and tell you not to do this, but they can't stop their competitor > from leaking a prefix which they really shouldn't. > > Fortunately, most ISPs won't do this sort of thing. Which is unfortunate. Because if scaling of the global routing table is really as big of an issue as some people claim, then the above scenario defines a BEST PRACTICE for multihoming without global impact. But, as I said in my last message, without a globally agreed definition of the problem and a globally agreed way forward to solving it, any action that RIPE takes to limit growth of the global routing table is just penalizing European businesses for no net benefit. PI assignments are a good thing because they help get organizations online. When an organization needs this kind of address range, RIPE should be ready to give it to them. In the end, all assignments and allocations are subject to technical justifications based on RFC 2050. --Michael Dillon P.S. I happen to believe that there are issues with scaling the global routing table but I believe that it is better to solve those issues directly, and not indirectly through RIR policies. A direct solution can only come from a direct discussion, not random complaints in various RIR address policy forums. From nick at inex.ie Wed Sep 20 18:44:15 2006 From: nick at inex.ie (Nick Hilliard) Date: Wed, 20 Sep 2006 17:44:15 +0100 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: References: Message-ID: <1158770655.57847.58.camel@crumpet.netability.ie> > Which is unfortunate. Because if scaling of the global routing > table is really as big of an issue as some people claim, It's just an issue which crops up again and again, and costs money to solve each time. I've got a bunch of dual stacked sup720 pfc3b's. These no longer take a full v4 routing table in their default configuration, and shortly, I expect them not to be able to take a full v4 routing table using any soft configuration, except by filtering out routes. Yes, I can upgrade them. But it's an issue. It means downtime and lots of ???. > then > the above scenario defines a BEST PRACTICE for multihoming > without global impact. Let's be fair here - it's half-baked multihoming. If your connection to your LIR network goes down, you're going to be left with patchy connectivity at best. Half baked != best practice. > But, as I said in my last message, without a globally > agreed definition of the problem and a globally agreed > way forward to solving it, any action that RIPE takes to > limit growth of the global routing table is just penalizing > European businesses for no net benefit. But, but, but, but.... in this proposal, RIPE is not taking action to limit the growth of the global routing table. Under the terms of 2006-05, the intent is to make RIPE PI assignments more useful in the Internet, which makes PI a more attractive option, which helps European businesses. > PI assignments are a good thing because they help get > organizations online. When an organization needs this kind > of address range, RIPE should be ready to give it to them. > In the end, all assignments and allocations are subject to > technical justifications based on RFC 2050. Exactly - this is what this proposal is about. Separate to this proposal are the following items of note: 1. 2006-05 affects address assignment policy, and address assignment policy indirectly affects routing table growth, 2. we have no garbage collection mechanism for stale PI assignments, 3. readily available PI is good for business, 4. lots of people believe - with good reason - that readily available PI is bad news from a network scalability point of view, and therefore: 5. one of the reasons that people might be unhappy about this proposal is because it may increase the amount of PI space assigned by RIPE. Nick From david.conrad at icann.org Wed Sep 20 19:43:53 2006 From: david.conrad at icann.org (David Conrad) Date: Wed, 20 Sep 2006 10:43:53 -0700 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: References: Message-ID: Michael, On Sep 20, 2006, at 2:17 AM, Michael.Dillon at btradianz.com wrote: >> Simply, PI to network topological leaves doesn't scale. > > On the contrary, PI *DOES* scale and it has scaled because > there is no direct one-to-one connection between issuing a > PI assignment and consuming a global routing table slot. Yes, pedantically, if you don't insert a prefix into the routing system, it scales quite well. I'm not sure this distinction has much value though. > Those things have greater impact > on global routing table size than the number of new PI > blocks. More specific announcement for TE may have a greater impact _today_ but given the pattern of liberalization of PI policies in all the RIRs, it isn't clear to me this will be the case in the future. What's worse is that more specifics can be filtered while still potentially providing routability (albeit perhaps sub-optimally) through the supernet. If you apply filters that affect PI prefixes, those prefixes are simply gone. Rgds, -drc From david.conrad at icann.org Wed Sep 20 19:45:18 2006 From: david.conrad at icann.org (David Conrad) Date: Wed, 20 Sep 2006 10:45:18 -0700 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <451128AA.6090300@ukraine.su> References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <451038DE.5030900@ukraine.su> <451128AA.6090300@ukraine.su> Message-ID: <6D03E145-6B3F-4B76-8C00-FC9BD070CFDB@icann.org> Max, On Sep 20, 2006, at 4:40 AM, Max Tulyev wrote: > Again, I don't even think about "portable IPs to any customer" at this > stage of Internet evolution. May be a bit later? But not now. So what is the criteria between customers who should get PI and who shouldn't? Thanks, -drc From andy at nosignal.org Thu Sep 21 03:00:20 2006 From: andy at nosignal.org (Andy Davidson) Date: Thu, 21 Sep 2006 02:00:20 +0100 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <45103749.9020407@ukraine.su> References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> <45101642.5010003@ukraine.su> <45103749.9020407@ukraine.su> Message-ID: <4511E424.5060808@nosignal.org> Max Tulyev wrote: >This story is about PA/LIR, where (again, in the theory) all is quite >simply. No money -> closing contarct (as in terms of it) -> getting back >IPs. > > You're opening up a huge can of worms here. 'Getting back IPs' means contacting peers and upstreams and telling these parties to stop accepting the announcement from the non-paying company. If the company is still paying bills to their upstreams, do you think upstreams will take kindly to this action ? The RIPE NCC deleting the inetnum object doesn't mean the addresses stop routing ... RIPE NCC possibly have no contract with the companies that would need to stop accepting the prefixes from the debting party. -a From heldal at eml.cc Thu Sep 21 04:17:48 2006 From: heldal at eml.cc (Per Heldal) Date: Thu, 21 Sep 2006 04:17:48 +0200 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <4511E424.5060808@nosignal.org> References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> <45101642.5010003@ukraine.su> <45103749.9020407@ukraine.su> <4511E424.5060808@nosignal.org> Message-ID: <1158805068.15386.26.camel@localhost.localdomain> On Thu, 2006-09-21 at 02:00 +0100, Andy Davidson wrote: > Max Tulyev wrote: > > >This story is about PA/LIR, where (again, in the theory) all is quite > >simply. No money -> closing contarct (as in terms of it) -> getting back > >IPs. > > > > > > You're opening up a huge can of worms here. 'Getting back IPs' means > contacting peers and upstreams and telling these parties to stop > accepting the announcement from the non-paying company. If the company > is still paying bills to their upstreams, do you think upstreams will > take kindly to this action ? What the immediate upstream may think would be irrelevant. *If* there is *ever* consensus within the RIPE community to have the NCC reclaim blocks, there would have to be mechanisms in place to enforce the decision. That would most probably involve a quarantine period for reclaimed prefixes during which transit providers in the region would be asked to black-hole the space. > > The RIPE NCC deleting the inetnum object doesn't mean the addresses stop > routing ... It only takes a handful of large transit providers to black-hole a prefix to render that address-block useless. > > RIPE NCC possibly have no contract with the companies that would need to > stop accepting the prefixes from the debting party. > There are more than enough transit-providers on contract. The immediate upstream of the reclaimed block alone makes no difference. The question isn't if it can be done or not, but whether the RIPE community as a whole really wants such a scheme to be implemented. -- Per Heldal - http://heldal.eml.cc/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From abramov at demos.net Wed Sep 20 16:18:00 2006 From: abramov at demos.net (Gennady Abramov) Date: Wed, 20 Sep 2006 18:18:00 +0400 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <1158760449.12375.86.camel@pancake.netability.ie> References: <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> <45101642.5010003@ukraine.su> <45103749.9020407@ukraine.su> <20060920085159.GO56407@f17.dmitry.net> <20060920122127.GD1581@demos.net> <1158760449.12375.86.camel@pancake.netability.ie> Message-ID: <20060920141800.GE1581@demos.net> On Wed, Sep 20, 2006 at 02:54:09PM +0100, Nick Hilliard wrote: > > And, don't forget that you even can do multihoming without PI address > > space, by multihoming of PA assigment (if LIR permitted it). > > It's nothing to do with your LIR. You can only do this if your > secondary upstream agrees to it. Your LIR can shout and jump up and > down and tell you not to do this, but they can't stop their competitor > from leaking a prefix which they really shouldn't. Mm... In most cases, LIR protects (Or at least, should protect, I think) PA assigments by his own mntner. Secondary upstream can't create route object on this specific PA assigment from first LIR without agreement, and this prefix wouldn't be routed in Internet normally. > > Fortunately, most ISPs won't do this sort of thing. > > Nick -- Regards, Gennady Abramov, CCNP, AGV77-RIPE Demos-Internet NOC Phone: +7 (495) 737-0436 http://www.demos.ru/address From abramov at demos.net Wed Sep 20 16:31:25 2006 From: abramov at demos.net (Gennady Abramov) Date: Wed, 20 Sep 2006 18:31:25 +0400 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <4511825D.6080102@ukraine.su> References: <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> <45101642.5010003@ukraine.su> <45103749.9020407@ukraine.su> <20060920085159.GO56407@f17.dmitry.net> <20060920122127.GD1581@demos.net> <4511825D.6080102@ukraine.su> Message-ID: <20060920143125.GF1581@demos.net> On Wed, Sep 20, 2006 at 06:03:09PM +0000, Max Tulyev wrote: > Gennady Abramov wrote: > > And, don't forget that you even can do multihoming without PI address > > space, by multihoming of PA assigment (if LIR permitted it). > > Multihoming, but not backups. Because of some traffic will flow through > [aggregated] LIR route if even link with LIR will be damaged. It is very some traffic. Some traffic flows on default gateway, even if you have BGP full view on the router... :) Normally, longest prefix has highest priority. If your multihomed prefix doesn't exist in some part of Internet, you may have troubles with connectivity with this part of Internet, don't looking PA or PI addresses you uses. In the case of PA specific, traffic from this part of Internet will flow to aggregated route, and, if specific route would be found on next hops, will go to specific route from this next hops. In the case of PI, traffic will flow to default or will be dropped. Anyway, if your prefix doesn't routed anywhere, it isn't normal situation, don't depend of addresses u use. -- Regards, Gennady Abramov, CCNP, AGV77-RIPE Demos-Internet NOC Phone: +7 (495) 737-0436 http://www.demos.ru/address From nick at inex.ie Thu Sep 21 10:21:04 2006 From: nick at inex.ie (Nick Hilliard) Date: Thu, 21 Sep 2006 09:21:04 +0100 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <4511E424.5060808@nosignal.org> References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> <45101642.5010003@ukraine.su> <45103749.9020407@ukraine.su> <4511E424.5060808@nosignal.org> Message-ID: <45124B70.9050102@inex.ie> > You're opening up a huge can of worms here. Aye, surely. 10 years ago, a survey was done on the 192/8 swamp, and it was estimated that even at that stage, 60% of the registrations were uncontactable. I can't see how thing would have got better in the interim, but does this mean that we officially declare this space lost? Whatever about reclaiming blocks previously assigned, what about blocks assigned in the future? Are we also going to commit right now to losing these blocks if they are unused, or are we going to attempt to fix the issue? I mean, there's a massive problem here. Losing IP space to posterity just because we can't be bothered to put policies in place to deal with the issue is frankly rather unwise. > 'Getting back IPs' means > contacting peers and upstreams and telling these parties to stop > accepting the announcement from the non-paying company. If the company > is still paying bills to their upstreams, do you think upstreams will > take kindly to this action ? > The RIPE NCC deleting the inetnum object doesn't mean the addresses stop > routing ... The RIPE NCC is not the routing police; it's a registration clearing-house. LIR's pay money to guarantee that the address space blocks they are allocated are globally unique. It's up to carriers to ensure that their customers' announcements are legitimate. Anyway, this is getting seriously off topic for 2006-05. Nick From president at ukraine.su Thu Sep 21 19:22:15 2006 From: president at ukraine.su (Max Tulyev) Date: Thu, 21 Sep 2006 17:22:15 +0000 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <6D03E145-6B3F-4B76-8C00-FC9BD070CFDB@icann.org> References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <451038DE.5030900@ukraine.su> <451128AA.6090300@ukraine.su> <6D03E145-6B3F-4B76-8C00-FC9BD070CFDB@icann.org> Message-ID: <4512CA47.5080501@ukraine.su> David Conrad wrote: > Max, > > On Sep 20, 2006, at 4:40 AM, Max Tulyev wrote: >> Again, I don't even think about "portable IPs to any customer" at this >> stage of Internet evolution. May be a bit later? But not now. > > So what is the criteria between customers who should get PI and who > shouldn't? Multihoming. In some other rare cases - really large problems with renumbering (hosting provider with 10000 domains). -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From leo at ripe.net Thu Sep 21 15:28:19 2006 From: leo at ripe.net (leo vegoda) Date: Thu, 21 Sep 2006 15:28:19 +0200 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <1158805068.15386.26.camel@localhost.localdomain> References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> <45101642.5010003@ukraine.su> <45103749.9020407@ukraine.su> <4511E424.5060808@nosignal.org> <1158805068.15386.26.camel@localhost.localdomain> Message-ID: <0D5DE326-C143-49E3-82F6-A275EFCED257@ripe.net> Hi Per, On 21 Sep 2006, at 4:17GMT+02:00, Per Heldal wrote: [...] > What the immediate upstream may think would be irrelevant. *If* > there is > *ever* consensus within the RIPE community to have the NCC reclaim > blocks, there would have to be mechanisms in place to enforce the > decision. That would most probably involve a quarantine period for > reclaimed prefixes during which transit providers in the region > would be > asked to black-hole the space. We always 'quarantine' address space when it is returned to us. Allocations from about 65 LIRs have been returned so far this year. Regards, -- leo vegoda Registration Services Manager RIPE NCC From president at ukraine.su Thu Sep 21 19:27:06 2006 From: president at ukraine.su (Max Tulyev) Date: Thu, 21 Sep 2006 17:27:06 +0000 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <4511E424.5060808@nosignal.org> References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> <45101642.5010003@ukraine.su> <45103749.9020407@ukraine.su> <4511E424.5060808@nosignal.org> Message-ID: <4512CB6A.7000805@ukraine.su> Andy Davidson wrote: > You're opening up a huge can of worms here. > 'Getting back IPs' means > contacting peers and upstreams and telling these parties to stop > accepting the announcement from the non-paying company. If the company > is still paying bills to their upstreams, do you think upstreams will > take kindly to this action ? > The RIPE NCC deleting the inetnum object doesn't mean the addresses stop > routing ... It means. Just because of this space will not be routed in the world. RR DB is a good thing! ;) -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From president at ukraine.su Thu Sep 21 19:33:48 2006 From: president at ukraine.su (Max Tulyev) Date: Thu, 21 Sep 2006 17:33:48 +0000 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <1158805068.15386.26.camel@localhost.localdomain> References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> <45101642.5010003@ukraine.su> <45103749.9020407@ukraine.su> <4511E424.5060808@nosignal.org> <1158805068.15386.26.camel@localhost.localdomain> Message-ID: <4512CCFC.9010001@ukraine.su> Per Heldal wrote: > What the immediate upstream may think would be irrelevant. *If* there is > *ever* consensus within the RIPE community to have the NCC reclaim > blocks, there would have to be mechanisms in place to enforce the > decision. That would most probably involve a quarantine period for > reclaimed prefixes during which transit providers in the region would be > asked to black-hole the space. No, not black-hole! Just don't accept! Because of there will be another period of "de-black-holing" ;) and so on... > It only takes a handful of large transit providers to black-hole a > prefix to render that address-block useless. Again, if there is no inetnum/as/roure objects, "large transit providers" just drop this because of RR DB filters. This also true for those who "transmit pirate signal into the Matrix" ;) using fake IPs and ASes. > > The question isn't if it can be done or not, but whether the RIPE > community as a whole really wants such a scheme to be implemented. > I think it must be done. Not only because of this case, but also for blocking unauthorized announces. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From president at ukraine.su Thu Sep 21 19:41:14 2006 From: president at ukraine.su (Max Tulyev) Date: Thu, 21 Sep 2006 17:41:14 +0000 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <0D5DE326-C143-49E3-82F6-A275EFCED257@ripe.net> References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> <45101642.5010003@ukraine.su> <45103749.9020407@ukraine.su> <4511E424.5060808@nosignal.org> <1158805068.15386.26.camel@localhost.localdomain> <0D5DE326-C143-49E3-82F6-A275EFCED257@ripe.net> Message-ID: <4512CEBA.2080009@ukraine.su> leo vegoda wrote: > We always 'quarantine' address space when it is returned to us. > Allocations from about 65 LIRs have been returned so far this year. And what will be if some totally mad person will announce that space and will say "It's mine, not your!!!"? Can RIPE use some (which?) force in this case? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From leo at ripe.net Thu Sep 21 15:50:06 2006 From: leo at ripe.net (leo vegoda) Date: Thu, 21 Sep 2006 15:50:06 +0200 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <4512CEBA.2080009@ukraine.su> References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> <45101642.5010003@ukraine.su> <45103749.9020407@ukraine.su> <4511E424.5060808@nosignal.org> <1158805068.15386.26.camel@localhost.localdomain> <0D5DE326-C143-49E3-82F6-A275EFCED257@ripe.net> <4512CEBA.2080009@ukraine.su> Message-ID: <0F398136-D540-4002-BD51-0A4A23C3966A@ripe.net> Hi Max, On 21 Sep 2006, at 7:41GMT+02:00, Max Tulyev wrote: >> >> We always 'quarantine' address space when it is returned to us. >> Allocations from about 65 LIRs have been returned so far this year. > > And what will be if some totally mad person will announce that > space and > will say "It's mine, not your!!!"? Can RIPE use some (which?) force in > this case? The RIPE NCC has no authority over routing decisions taken by network operators. Regards, -- leo vegoda Registration Services Manager RIPE NCC From dmitry at volia.net Thu Sep 21 15:52:13 2006 From: dmitry at volia.net (Dmitry Kiselev) Date: Thu, 21 Sep 2006 16:52:13 +0300 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <4512CEBA.2080009@ukraine.su> References: <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> <45101642.5010003@ukraine.su> <45103749.9020407@ukraine.su> <4511E424.5060808@nosignal.org> <1158805068.15386.26.camel@localhost.localdomain> <0D5DE326-C143-49E3-82F6-A275EFCED257@ripe.net> <4512CEBA.2080009@ukraine.su> Message-ID: <20060921135213.GV56407@f17.dmitry.net> Hi! On Thu, Sep 21, 2006 at 05:41:14PM +0000, Max Tulyev wrote: > > We always 'quarantine' address space when it is returned to us. > > Allocations from about 65 LIRs have been returned so far this year. > > And what will be if some totally mad person will announce that space and > will say "It's mine, not your!!!"? Can RIPE use some (which?) force in > this case? Yeah... RIPE has SWAT for such cases... :) :D Joke. IMHO, RIPE can only inform community about collision and point to legal network owner. -- Dmitry Kiselev From ncc at ripe.net Thu Sep 21 15:59:41 2006 From: ncc at ripe.net (Paul Rendek) Date: Thu, 21 Sep 2006 15:59:41 +0200 Subject: [address-policy-wg] RIPE NCC NRO Number Council Candidates Announced Message-ID: <45129ACD.80209@ripe.net> [Apologies for duplicate e-mails] Dear Colleagues, The following candidates have accepted their nomination for the vacant seat on the Number Resource Organization (NRO) Number Council (NC) from the RIPE NCC service region: * Sabine Jaume Rajaonia * Dave Wilson The term of Sabine Jaume, who was elected in January 2004, expires in December 2006. The representative appointed by the Internet community for the NRO NC seat will serve a three-year term, beginning 1 January 2007. Candidate profiles and information on how to submit an Expression of Support can be found at: http://www.ripe.net/info/resource-admin/nro2006/confirmed-nominations.html Voting will take place during the RIPE NCC Services Working Group session of the RIPE 53 Meeting in Amsterdam. This session takes place at 16:00 - 17:00 on Thursday 5 October, 2006. Note: this is a change from the previously published date. The successful candidate will be announced during this meeting. For more information about the NRO NC, nominations and the election process, see: http://www.ripe.net/info/resource-admin/nro2006/ Regards, Paul Rendek Head of Member Services & Communications RIPE NCC From fw at deneb.enyo.de Thu Sep 21 22:53:29 2006 From: fw at deneb.enyo.de (Florian Weimer) Date: Thu, 21 Sep 2006 22:53:29 +0200 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <45100E22.4010507@ukraine.su> (Max Tulyev's message of "Tue, 19 Sep 2006 15:34:58 +0000") References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> Message-ID: <87psdpx7p2.fsf@mid.deneb.enyo.de> * Max Tulyev: > Second, "PI vs LIR" deal. If one real wants own IP/AS, and ready to pay > for it, this one WILL add a prefix to the global routing table, either > he become a LIR or only get PI. BUT. If costs are equal, EVERY manager > (who make final decision for what to pay) will take MORE "something" (IP > addresses in this case) for same (or near) price. Reality check, please. Market prices for PI space (excluding router setup etc.) are quite close to LIR setup fees. From marcus.gerdon at mainz-kom.de Thu Sep 21 23:15:34 2006 From: marcus.gerdon at mainz-kom.de (Marcus Gerdon) Date: Thu, 21 Sep 2006 23:15:34 +0200 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI AssignmentSize) References: <1158770655.57847.58.camel@crumpet.netability.ie> Message-ID: <010001c6ddc3$13f9ff70$ef47ea0a@avalon> > > Which is unfortunate. Because if scaling of the global routing > > table is really as big of an issue as some people claim, > > It's just an issue which crops up again and again, and costs money to > solve each time. I've got a bunch of dual stacked sup720 pfc3b's. > These no longer take a full v4 routing table in their default > configuration, and shortly, I expect them not to be able to take a full > v4 routing table using any soft configuration, except by filtering out > routes. > > Yes, I can upgrade them. But it's an issue. It means downtime and lots > of ???. > > > And, don't forget that you even can do multihoming without PI address > > space, by multihoming of PA assigment (if LIR permitted it). > Some traffic flows on default gateway, even if you have BGP full view on > the router... :) > Normally, longest prefix has highest priority. If your > multihomed prefix doesn't exist in some part of Internet, you may have > troubles with connectivity with this part of Internet, don't looking PA > or PI addresses you uses. Sorry to say, but you're running an ISP on 6500's and propose a problem with upgrading PFC-3B to PFC-3BXL at about 6.000 - 9.000 $ per engine ? Besides that, you bought a 256k prefixes engine about 2 years ago (i think it was released about sometime 2004) ? There's not only an issue of routing / routing table scalibity but also an issue of network scalability. The latter is in the sole responsibility of the ISP / LIR. Instead of table size/memory issues due to table growth we could also discuss about CPU utilization issues due to BGP updates. Did you check the CPU load of your sup720 loaded with a bunch of session ? The current number of constant updates triggers about 10-20% (at least) load on 3BXL engines when connected with decix peers and an upstream for example. Maybe we should propose serious actions to be taken against flapping systems, software- and standard-pc - based (zebra, quagga, etc.) networks, too ... /-( And in my opinion include bgp links across links of 2-4 mbit/s of bandwidth to the list above - usually those are encountered to satisfy the 2-upstreams-rule. As long as I see ASN >= 64512, prefixes down to /30, /16's with sub-advertisements of 200 /24's with the same as path, packets with source addresses out of RFC 1918 ranges even via large multinational ASN sessions, I believe there're more important general operating problems than a bunch of PI prefixes. IMHO the massive de-aggrations hurt much more (and yes, we're doing some of that ourselves). There're a lot of operational problems currently existing so why bother about a few more PI prefixes and introduce additional administrative and operational overhead ? Most time I spend with PI-related problems are advertisements < /24 sent by customers (and therefore dropped) filing a complaint later, LIR not responding to db object transfer request, inaccurate or outdated db information etc. But these won't solve by further constraining PI assignments. Remember, a PI request has to be filed with RIPE by a LIR. You can refuse the customers wishes - but that customer will find some LIR that will do just to take over the customer from you. Those arguments lead to the same discussion fought out in the IPv6 PI discussion: if the internet's end users (customers) are denied their requests by policies and their wishes are ignored, those areas will starve in the long run. regards, Marcus ------------------------------------------ Tropolys Rhein-Main GmbH Versatel Group Network Engineering and Administration ------------------------------------------ ASN 8881 / 15837 MG3031-RIPE ------------------------------------------ From president at ukraine.su Thu Sep 21 22:28:19 2006 From: president at ukraine.su (Max Tulyev) Date: Fri, 22 Sep 2006 00:28:19 +0400 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <87psdpx7p2.fsf@mid.deneb.enyo.de> References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <87psdpx7p2.fsf@mid.deneb.enyo.de> Message-ID: <4512F5E3.6000406@ukraine.su> Florian Weimer wrote: > Reality check, please. Market prices for PI space (excluding router > setup etc.) are quite close to LIR setup fees. > Where??? Near me it is ~$300 for /24, ~$500 for /23, ~$700 for /22. AS included ;) It's not only my price, it is market there... -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From abramov at demos.net Thu Sep 21 15:57:38 2006 From: abramov at demos.net (Gennady Abramov) Date: Thu, 21 Sep 2006 17:57:38 +0400 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <4511E424.5060808@nosignal.org> References: <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> <45101642.5010003@ukraine.su> <45103749.9020407@ukraine.su> <4511E424.5060808@nosignal.org> Message-ID: <20060921135738.GB1821@demos.net> On Thu, Sep 21, 2006 at 02:00:20AM +0100, Andy Davidson wrote: > You're opening up a huge can of worms here. 'Getting back IPs' means > contacting peers and upstreams and telling these parties to stop > accepting the announcement from the non-paying company. If the company > is still paying bills to their upstreams, do you think upstreams will > take kindly to this action ? > > The RIPE NCC deleting the inetnum object doesn't mean the addresses stop > routing ... > > RIPE NCC possibly have no contract with the companies that would need to > stop accepting the prefixes from the debting party. The deletion of "route:" object means troubles with routing of the prefix. Of course, it is possible to route prefix without corresponding "route:", but it isn't very easy. And, of course, forget of any routing policy with this prefix, you may just to place this prefix to the Internet somehow. Of course, if you can (Talk with your upstreams to configure "hand-made" filters, or get an upstream who will accept "any" from you and have such peers and upstreams, etc). -- ? ?????????, ??????? ????????, CCNP ????? ???????? ?????????? (NOC) ??? "?????-????????" ???.: (495) 737-0436 http://www.demos.ru/address From Joao_Damas at isc.org Fri Sep 22 10:19:39 2006 From: Joao_Damas at isc.org (Joao Damas) Date: Fri, 22 Sep 2006 10:19:39 +0200 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <0F398136-D540-4002-BD51-0A4A23C3966A@ripe.net> References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> <45101642.5010003@ukraine.su> <45103749.9020407@ukraine.su> <4511E424.5060808@nosignal.org> <1158805068.15386.26.camel@localhost.localdomain> <0D5DE326-C143-49E3-82F6-A275EFCED257@ripe.net> <4512CEBA.2080009@ukraine.su> <0F398136-D540-4002-BD51-0A4A23C3966A@ripe.net> Message-ID: On 21 Sep, 2006, at 15:50, leo vegoda wrote: > Hi Max, > > On 21 Sep 2006, at 7:41GMT+02:00, Max Tulyev wrote: >>> >>> We always 'quarantine' address space when it is returned to us. >>> Allocations from about 65 LIRs have been returned so far this year. >> >> And what will be if some totally mad person will announce that >> space and >> will say "It's mine, not your!!!"? Can RIPE use some (which?) >> force in >> this case? > > The RIPE NCC has no authority over routing decisions taken by > network operators. > Though hopefully it will have public records for ISPs to see who has been assigned the IP block through the established process, right? Joao From leo at ripe.net Fri Sep 22 10:27:18 2006 From: leo at ripe.net (leo vegoda) Date: Fri, 22 Sep 2006 10:27:18 +0200 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> <45101642.5010003@ukraine.su> <45103749.9020407@ukraine.su> <4511E424.5060808@nosignal.org> <1158805068.15386.26.camel@localhost.localdomain> <0D5DE326-C143-49E3-82F6-A275EFCED257@ripe.net> <4512CEBA.2080009@ukraine.su> <0F398136-D540-4002-BD51-0A4A23C3966A@ripe.net> Message-ID: <429A7CF3-FFD1-4D5F-91B0-79D4E7EB9908@ripe.net> Hi Joao, On 22 Sep 2006, at 10:19GMT+02:00, Joao Damas wrote: [...] >>>> We always 'quarantine' address space when it is returned to us. >>>> Allocations from about 65 LIRs have been returned so far this year. >>> >>> And what will be if some totally mad person will announce that >>> space and >>> will say "It's mine, not your!!!"? Can RIPE use some (which?) >>> force in >>> this case? >> >> The RIPE NCC has no authority over routing decisions taken by >> network operators. > > Though hopefully it will have public records for ISPs to see who > has been assigned the IP block through the established process, right? If a network is announcing address space that has been returned to us there will not be a registration for the specific prefix being announced, just a registration for the allocation from which it is 'taken'. Regards, -- leo vegoda Registration Services Manager RIPE NCC From Woeber at CC.UniVie.ac.at Fri Sep 22 10:38:43 2006 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 22 Sep 2006 08:38:43 +0000 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <429A7CF3-FFD1-4D5F-91B0-79D4E7EB9908@ripe.net> References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> <45101642.5010003@ukraine.su> <45103749.9020407@ukraine.su> <4511E424.5060808@nosignal.org> <1158805068.15386.26.camel@localhost.localdomain> <0D5DE326-C143-49E3-82F6-A275EFCED257@ripe.net> <4512CEBA.2080009@ukraine.su> <0F398136-D540-4002-BD51-0A4A23C3966A@ripe.net> <429A7CF3-FFD1-4D5F-91B0-79D4E7EB9908@ripe.net> Message-ID: <4513A113.9050804@CC.UniVie.ac.at> But this is nothing special imho, the very same statement holds true for any space that as yet hadn't been "in use" at all. Bottom line: if there isn't a record to properly docment assignment to an end site, then the use or routing of that address space is at least vey, very, questionable(1). But if you don't double-check - you'll never know ;-) Wilfried. (1) announcement of a full PA allocation as one route, covering as yet unassigned space, is an exception to this rule. leo vegoda wrote: > Hi Joao, > > On 22 Sep 2006, at 10:19GMT+02:00, Joao Damas wrote: > > [...] > >>>>> We always 'quarantine' address space when it is returned to us. >>>>> Allocations from about 65 LIRs have been returned so far this year. >>>> >>>> >>>> And what will be if some totally mad person will announce that >>>> space and >>>> will say "It's mine, not your!!!"? Can RIPE use some (which?) force in >>>> this case? >>> >>> >>> The RIPE NCC has no authority over routing decisions taken by >>> network operators. >> >> >> Though hopefully it will have public records for ISPs to see who has >> been assigned the IP block through the established process, right? > > > If a network is announcing address space that has been returned to us > there will not be a registration for the specific prefix being > announced, just a registration for the allocation from which it is > 'taken'. > > Regards, > From randy at psg.com Fri Sep 22 10:27:37 2006 From: randy at psg.com (Randy Bush) Date: Thu, 21 Sep 2006 22:27:37 -1000 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> <45101642.5010003@ukraine.su> <45103749.9020407@ukraine.su> <4511E424.5060808@nosignal.org> <1158805068.15386.26.camel@localhost.localdomain> <0D5DE326-C143-49E3-82F6-A275EFCED257@ripe.net> <4512CEBA.2080009@ukraine.su> <0F398136-D540-4002-BD51-0A4A23C3966A@ripe.net> Message-ID: <17683.40569.987510.900871@roam.psg.com> > Though hopefully it will have public records for ISPs to see who has > been assigned the IP block through the established process, right? if we are lucky, this time next year, you will be able to verify an X.509 certificate chain with rfc 3779 resource extensions, and have significant confidence in rights to address and asn resources. randy From heldal at eml.cc Fri Sep 22 12:47:56 2006 From: heldal at eml.cc (Per Heldal) Date: Fri, 22 Sep 2006 12:47:56 +0200 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <20060829082515.EA0922F592@herring.ripe.net> References: <20060829082515.EA0922F592@herring.ripe.net> Message-ID: <1158922076.15386.82.camel@localhost.localdomain> On Tue, 2006-08-29 at 10:25 +0200, Filiz Yilmaz wrote: > PDP Number: 2006-05 > PI Assignment Size > > > Dear Colleagues, > > A new RIPE Policy has been proposed and is now available for > discussion. > > This proposal suggests to have the minimum assignment size for PI > assignments to be a /24 when routing is a major issue for a > multihoming End User. When should RIRs allocate v4 PI-blocks so small they won't be globally accepted? Such would in reality become small "private" blocks. For v6 the discussion is still open wrt the allocation of private (unannuced) addresses, but for v4 we should stick to rfc1918 and ask those who don't qualify for an allocation big enough to pursue de-aggregated PA-space which at least will be routed through its wider aggregate. The wording in the policy should instead reflect the need for consistence between the minimum size of allocated blocks and common filtering recommendations for the related IANA container-block (/8). //per -- Per Heldal - http://heldal.eml.cc/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From Woeber at CC.UniVie.ac.at Fri Sep 22 13:12:08 2006 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 22 Sep 2006 11:12:08 +0000 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <1158922076.15386.82.camel@localhost.localdomain> References: <20060829082515.EA0922F592@herring.ripe.net> <1158922076.15386.82.camel@localhost.localdomain> Message-ID: <4513C508.4020408@CC.UniVie.ac.at> Per Heldal wrote: > On Tue, 2006-08-29 at 10:25 +0200, Filiz Yilmaz wrote: > >>PDP Number: 2006-05 >>PI Assignment Size >> >> >>Dear Colleagues, >> >>A new RIPE Policy has been proposed and is now available for >>discussion. >> >>This proposal suggests to have the minimum assignment size for PI >>assignments to be a /24 when routing is a major issue for a >>multihoming End User. I still think that proposal is a completely inappropriate approach to take volatile(1) routing configuration criteria as (major) input for manufacturing address assignment policies. (1) volatile in the sense that a) (change in) filtering behaviour of ISPs is not consistent, nor under the control of the body having to agree on addressing policy, and b) as has been pointed out already, this behaviour might change "any time", rendering the policy broken again. > When should RIRs allocate v4 PI-blocks so small they won't be globally > accepted? Such would in reality become small "private" blocks. For v6 > the discussion is still open wrt the allocation of private (unannuced) > addresses, but for v4 we should stick to rfc1918 and ask those who don't > qualify for an allocation big enough to pursue de-aggregated PA-space > which at least will be routed through its wider aggregate. > > The wording in the policy should instead reflect the need for > consistence between the minimum size of allocated blocks and common > filtering recommendations for the related IANA container-block (/8). > > > //per Another aspect of this proposal is that it would brake the equal opportunity approch opposite PA-Space - unless we raise the minimum block size for PA- assignments to /24 or whatever, too. Wilfried. From president at ukraine.su Mon Sep 25 17:30:29 2006 From: president at ukraine.su (Max Tulyev) Date: Mon, 25 Sep 2006 15:30:29 +0000 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <17683.40569.987510.900871@roam.psg.com> References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> <45101642.5010003@ukraine.su> <45103749.9020407@ukraine.su> <4511E424.5060808@nosignal.org> <1158805068.15386.26.camel@localhost.localdomain> <0D5DE326-C143-49E3-82F6-A275EFCED257@ripe.net> <4512CEBA.2080009@ukraine.su> <0F398136-D540-4002-BD51-0A4A23C3966A@ripe.net> <17683.40569.987510.900871@roam.psg.com> Message-ID: <4517F615.1050502@ukraine.su> Randy Bush wrote: >> Though hopefully it will have public records for ISPs to see who has >> been assigned the IP block through the established process, right? > > if we are lucky, this time next year, you will be able to verify an X.509 > certificate chain with rfc 3779 resource extensions, and have significant > confidence in rights to address and asn resources. As I can understand, I can verify origin of prefix, prefix itself, but it can't authorize is that certain as-path legitimate or not. Like I can figure it out from routing registry DB. Isn't it? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From filiz at ripe.net Mon Sep 25 14:55:25 2006 From: filiz at ripe.net (Filiz Yilmaz) Date: Mon, 25 Sep 2006 14:55:25 +0200 Subject: [address-policy-wg] 2005-02 Proposal Accepted (IP Assignments for Anycasting DNS) Message-ID: <20060925125525.2BB692F583@herring.ripe.net> PDP Number: 2005-02 IP Assignments for Anycasting DNS Dear Colleagues, Consensus has been reached, and the proposal described in 2005-02 has been accepted by the RIPE community. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-2.html Two policy documents were affected by this proposal and now are updated and published: IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region, ripe-387 http://www.ripe.net/ripe/docs/ipv4-policies.html and IPv6 Address Allocation and Assignment Policy, ripe-388 http://www.ripe.net/ripe/docs/ipv6policy.html Thank you for your input. We also noticed an error in the previous IPv4 policy document, ripe-368. In 2004, utilisation requirements to receive a first allocation were dropped and the document was updated accordingly. However, a reference to this changed policy was overlooked in this previous update: 5.4 Sub-allocations: ... Downstream network operators efficiently using a /22 sub-allocation qualify to receive a /20 PA allocation from the RIPE NCC if they decide to become an LIR themselves. ... We also removed this out of date reference from the document in ripe-387. We apologise for any confusion. Kind regards, Filiz Yilmaz RIPE NCC Policy Development Officer From filiz at ripe.net Mon Sep 25 15:02:18 2006 From: filiz at ripe.net (Filiz Yilmaz) Date: Mon, 25 Sep 2006 15:02:18 +0200 Subject: [address-policy-wg] 2005-12 Proposal Accepted (4-Byte AS Number Policy) Message-ID: <20060925130218.C53EC2F5BD@herring.ripe.net> PDP Number: 2005-12 4-Byte AS Number Policy Dear Colleagues, Consensus has been reached, and the proposal described in 2005-12 has been accepted by the RIPE community. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-12.html One policy document was affected by this proposal and now is updated and published: Autonomous System (AS) Number Assignment Policies and Procedures, ripe-389 http://www.ripe.net/ripe/docs/asn-assignment.html Thank you for your input. Kind regards, Filiz Yilmaz RIPE NCC Policy Development Officer From randy at psg.com Mon Sep 25 18:43:40 2006 From: randy at psg.com (Randy Bush) Date: Mon, 25 Sep 2006 06:43:40 -1000 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> <45101642.5010003@ukraine.su> <45103749.9020407@ukraine.su> <4511E424.5060808@nosignal.org> <1158805068.15386.26.camel@localhost.localdomain> <0D5DE326-C143-49E3-82F6-A275EFCED257@ripe.net> <4512CEBA.2080009@ukraine.su> <0F398136-D540-4002-BD51-0A4A23C3966A@ripe.net> <17683.40569.987510.900871@roam.psg.com> <4517F615.1050502@ukraine.su> Message-ID: <17688.1852.763030.432390@roam.psg.com> >> if we are lucky, this time next year, you will be able to verify an X.509 >> certificate chain with rfc 3779 resource extensions, and have significant >> confidence in rights to address and asn resources. > > As I can understand, I can verify origin of prefix, prefix itself, but > it can't authorize is that certain as-path legitimate or not. Like I can > figure it out from routing registry DB. Isn't it? the current work will provide a formally verifiable demonstration of ownership of address space. to achieve your goal _formally_ will require something like sbgp. the irr is an informal way to kinda achieve what you want. and we use it today. one first useful step for an isp is to use the x.509 data to verify ownership assertions in the irr when building filter lists, for example. randy From president at ukraine.su Mon Sep 25 22:57:13 2006 From: president at ukraine.su (Max Tulyev) Date: Mon, 25 Sep 2006 20:57:13 +0000 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <17688.1852.763030.432390@roam.psg.com> References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> <45101642.5010003@ukraine.su> <45103749.9020407@ukraine.su> <4511E424.5060808@nosignal.org> <1158805068.15386.26.camel@localhost.localdomain> <0D5DE326-C143-49E3-82F6-A275EFCED257@ripe.net> <4512CEBA.2080009@ukraine.su> <0F398136-D540-4002-BD51-0A4A23C3966A@ripe.net> <17683.40569.987510.900871@roam.psg.com> <4517F615.1050502@ukraine.su> <17688.1852.763030.432390@roam.psg.com> Message-ID: <451842A9.7070907@ukraine.su> Randy Bush wrote: >>> if we are lucky, this time next year, you will be able to verify an X.509 >>> certificate chain with rfc 3779 resource extensions, and have significant >>> confidence in rights to address and asn resources. >> As I can understand, I can verify origin of prefix, prefix itself, but >> it can't authorize is that certain as-path legitimate or not. Like I can >> figure it out from routing registry DB. Isn't it? > > the current work will provide a formally verifiable demonstration of > ownership of address space. > > to achieve your goal _formally_ will require something like sbgp. > > the irr is an informal way to kinda achieve what you want. and we > use it today. > > one first useful step for an isp is to use the x.509 data to verify > ownership assertions in the irr when building filter lists, for > example. I just think (if I correct understood that, sorry but this RFC is not easy reading) small enhancement of this will give us the large improvement: we can do filtering of unauthorized announcements (announcements of right prefix originated with right AS but from wrong place)! -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From randy at psg.com Mon Sep 25 18:57:35 2006 From: randy at psg.com (Randy Bush) Date: Mon, 25 Sep 2006 06:57:35 -1000 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> <44F41A4A.6050907@nethinks.com> <20060918155822.GA20002@Space.Net> <45100E22.4010507@ukraine.su> <20060919120943.GN56407@f17.dmitry.net> <45101642.5010003@ukraine.su> <45103749.9020407@ukraine.su> <4511E424.5060808@nosignal.org> <1158805068.15386.26.camel@localhost.localdomain> <0D5DE326-C143-49E3-82F6-A275EFCED257@ripe.net> <4512CEBA.2080009@ukraine.su> <0F398136-D540-4002-BD51-0A4A23C3966A@ripe.net> <17683.40569.987510.900871@roam.psg.com> <4517F615.1050502@ukraine.su> <17688.1852.763030.432390@roam.psg.com> <451842A9.7070907@ukraine.su> Message-ID: <17688.2687.846237.426426@roam.psg.com> > I just think (if I correct understood that, sorry but this RFC is not easy > reading) small enhancement of this will give us the large improvement: we > can do filtering of unauthorized announcements (announcements of right > prefix originated with right AS but from wrong place)! will need one more thing to verify origin, what is called a Routing Origination Authority, which looks a lot like a cert and is stored in the infrastructure, but which binds a cert of address ownership to the as number which is authorized to announce it. this would be verifiably signed by the formal owner of the address space. randy From randy at psg.com Mon Sep 25 20:40:18 2006 From: randy at psg.com (Randy Bush) Date: Mon, 25 Sep 2006 08:40:18 -1000 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <20060925183648.GA15120@vacation.karoshi.com.> References: <45103749.9020407@ukraine.su> <4511E424.5060808@nosignal.org> <1158805068.15386.26.camel@localhost.localdomain> <0D5DE326-C143-49E3-82F6-A275EFCED257@ripe.net> <4512CEBA.2080009@ukraine.su> <0F398136-D540-4002-BD51-0A4A23C3966A@ripe.net> <17683.40569.987510.900871@roam.psg.com> <4517F615.1050502@ukraine.su> <17688.1852.763030.432390@roam.psg.com> <20060925183648.GA15120@vacation.karoshi.com.> Message-ID: <45182292.6000906@psg.com> > wow... address ownership. thats kind of a new concept. > last i checked, most RIRs deal with the concept of address > stewardship. does that mean i can assert ownership of > integers and the RIR system will back me up? thanks for very educational contribution. randy From randy at psg.com Mon Sep 25 21:37:51 2006 From: randy at psg.com (Randy Bush) Date: Mon, 25 Sep 2006 09:37:51 -1000 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <20060925193114.GA15550@vacation.karoshi.com.> References: <1158805068.15386.26.camel@localhost.localdomain> <0D5DE326-C143-49E3-82F6-A275EFCED257@ripe.net> <4512CEBA.2080009@ukraine.su> <0F398136-D540-4002-BD51-0A4A23C3966A@ripe.net> <17683.40569.987510.900871@roam.psg.com> <4517F615.1050502@ukraine.su> <17688.1852.763030.432390@roam.psg.com> <20060925183648.GA15120@vacation.karoshi.com.> <45182292.6000906@psg.com> <20060925193114.GA15550@vacation.karoshi.com.> Message-ID: <4518300F.5000102@psg.com> > your welcome. and unless you have verifiable information > to the contrary, i (for one) would appreciate it if > you would be more precise regarding address allocation/delegation > and stewardship. To my understanding, addresses are NOT > property and can not be owned. > I will be pleased to be reliably informed otherwise. Please > educate me here. sorry, bill. i stick to engineering and leave layers 9-42 to experts such as yourself. but good red herring (sorry for idiom. red herrings are a bad smell dragged across a trail to keep others from being able to follow it). randy From bmanning at vacation.karoshi.com Mon Sep 25 20:36:48 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 25 Sep 2006 18:36:48 +0000 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <17688.1852.763030.432390@roam.psg.com> References: <45103749.9020407@ukraine.su> <4511E424.5060808@nosignal.org> <1158805068.15386.26.camel@localhost.localdomain> <0D5DE326-C143-49E3-82F6-A275EFCED257@ripe.net> <4512CEBA.2080009@ukraine.su> <0F398136-D540-4002-BD51-0A4A23C3966A@ripe.net> <17683.40569.987510.900871@roam.psg.com> <4517F615.1050502@ukraine.su> <17688.1852.763030.432390@roam.psg.com> Message-ID: <20060925183648.GA15120@vacation.karoshi.com.> On Mon, Sep 25, 2006 at 06:43:40AM -1000, Randy Bush wrote: > >> if we are lucky, this time next year, you will be able to verify an X.509 > >> certificate chain with rfc 3779 resource extensions, and have significant > >> confidence in rights to address and asn resources. > > > > As I can understand, I can verify origin of prefix, prefix itself, but > > it can't authorize is that certain as-path legitimate or not. Like I can > > figure it out from routing registry DB. Isn't it? > > the current work will provide a formally verifiable demonstration of > ownership of address space. wow... address ownership. thats kind of a new concept. last i checked, most RIRs deal with the concept of address stewardship. does that mean i can assert ownership of integers and the RIR system will back me up? > one first useful step for an isp is to use the x.509 data to verify > ownership assertions in the irr when building filter lists, for > example. > randy --bill From bmanning at vacation.karoshi.com Mon Sep 25 21:31:14 2006 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 25 Sep 2006 19:31:14 +0000 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <45182292.6000906@psg.com> References: <1158805068.15386.26.camel@localhost.localdomain> <0D5DE326-C143-49E3-82F6-A275EFCED257@ripe.net> <4512CEBA.2080009@ukraine.su> <0F398136-D540-4002-BD51-0A4A23C3966A@ripe.net> <17683.40569.987510.900871@roam.psg.com> <4517F615.1050502@ukraine.su> <17688.1852.763030.432390@roam.psg.com> <20060925183648.GA15120@vacation.karoshi.com.> <45182292.6000906@psg.com> Message-ID: <20060925193114.GA15550@vacation.karoshi.com.> On Mon, Sep 25, 2006 at 08:40:18AM -1000, Randy Bush wrote: > > wow... address ownership. thats kind of a new concept. > > last i checked, most RIRs deal with the concept of address > > stewardship. does that mean i can assert ownership of > > integers and the RIR system will back me up? > > thanks for very educational contribution. > > randy your welcome. and unless you have verifiable information to the contrary, i (for one) would appreciate it if you would be more precise regarding address allocation/delegation and stewardship. To my understanding, addresses are NOT property and can not be owned. I will be pleased to be reliably informed otherwise. Please educate me here. --bill From rogerj at jorgensen.no Tue Sep 26 10:06:26 2006 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Tue, 26 Sep 2006 10:06:26 +0200 (CEST) Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI AssignmentSize) In-Reply-To: <17688.2687.846237.426426@roam.psg.com> References: <20060829082515.EA0922F592@herring.ripe.net><1156842147.20677.43.camel@localhost.locald omain><20060829093925.GT56407@f17.dmitry.net><44F41A4A.6050907@nethinks.com ><20060918155822.GA20002@Space.Net><45100E22.4010507@ukraine.su><2006091912 0943.GN56407@f17.dmitry.net><45101642.5010003@ukraine.su><45103749.9020407@ukraine.su><4511E424.506 0808@nosignal.org><1158805068.15386.26.camel@localhost.localdomain><0D5DE32 6-C143-49E3-82F6-A275EFCED257@ripe.net><4512CEBA.2080009@ukraine.su><0F3981 36-D540-4002-BD51-0A4A23C3966A@ripe.net><17683.40569.987510.900871@roam.psg.com><4517F615.1050502@ukrain e.su><17688.1852.763030.432390@roam.psg.com><451842A9.7070907@ukraine.su> <17688.2687.846237.426426@roam.psg.com> Message-ID: On Mon, 25 Sep 2006, Randy Bush wrote: > will need one more thing to verify origin, what is called a Routing > Origination Authority, which looks a lot like a cert and is stored > in the infrastructure, but which binds a cert of address ownership > to the as number which is authorized to announce it. this would be > verifiably signed by the formal owner of the address space. Hope you don't mean ownership as in really own it forever, but more like right to use it if you've payed your fee etc ? -- ------------------------------ Roger Jorgensen | roger at jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- From gert at space.net Tue Sep 26 10:18:27 2006 From: gert at space.net (Gert Doering) Date: Tue, 26 Sep 2006 10:18:27 +0200 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI AssignmentSize) In-Reply-To: References: <17688.2687.846237.426426@roam.psg.com> Message-ID: <20060926081827.GH20002@Space.Net> Hi, On Tue, Sep 26, 2006 at 10:06:26AM +0200, Roger Jorgensen wrote: > Hope you don't mean ownership as in really own it forever, but more like > right to use it if you've payed your fee etc ? Exactly. Certificates have a lifetime, if you don't pay your fee, the cert will not be renewed. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 98999 SpaceNet AG Mail: netmaster at Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 From hank at efes.iucc.ac.il Tue Sep 26 10:28:37 2006 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 26 Sep 2006 11:28:37 +0300 (IDT) Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI AssignmentSize) In-Reply-To: References: <20060829082515.EA0922F592@herring.ripe.net><1156842147.20677.43.camel@localhost.locald omain><20060829093925.GT56407@f17.dmitry.net><44F41A4A.6050907@nethinks.com ><20060918155822.GA20002@Space.Net><45100E22.4010507@ukraine.su><2006091912 0943.GN56407@f17.dmitry.net><45101642.5010003@ukraine.su><45103749.9020407@ukraine.su><4511E424.506 0808@nosignal.org><1158805068.15386.26.camel@localhost.localdomain><0D5DE32 6-C143-49E3-82F6-A275EFCED257@ripe.net><4512CEBA.2080009@ukraine.su><0F3981 36-D540-4002-BD51-0A4A23C3966A@ripe.net><17683.40569.987510.900871@roam.psg.com><4517F615.1050502@ukrain e.su><17688.1852.763030.432390@roam.psg.com><451842A9.7070907@ukraine.su> <17688.2687.846237.426426@roam.psg.com> Message-ID: On Tue, 26 Sep 2006, Roger Jorgensen wrote: Why not just replace the word "owner" with "leaser"? I always assumed that I was leasing IP address space from the RIRs and not owning it. -Hank > On Mon, 25 Sep 2006, Randy Bush wrote: > >> will need one more thing to verify origin, what is called a Routing >> Origination Authority, which looks a lot like a cert and is stored >> in the infrastructure, but which binds a cert of address ownership >> to the as number which is authorized to announce it. this would be >> verifiably signed by the formal owner of the address space. > > Hope you don't mean ownership as in really own it forever, but more like > right to use it if you've payed your fee etc ? > > > -- > > > ------------------------------ > Roger Jorgensen | > roger at jorgensen.no | - IPv6 is The Key! > ------------------------------------------------------- > > > +++++++++++++++++++++++++++++++++++++++++++ > This Mail Was Scanned By Mail-seCure System > at the Tel-Aviv University CC. > From leo at ripe.net Tue Sep 26 10:59:57 2006 From: leo at ripe.net (leo vegoda) Date: Tue, 26 Sep 2006 10:59:57 +0200 Subject: [address-policy-wg] 2005-02 implementation: IP assignments for anycasting DNS Message-ID: <271D7BC3-CF74-4877-A993-5918714DD514@ripe.net> Dear Colleagues, We are pleased to announce that we will be able to accept e-mailed requests for assignments for anycasting DNS servers from 2 October 2006. The request form and supporting notes will be available from the RIPE Document Store at: http://www.ripe.net/ripe/docs/internet-registries.html We will make a separate announcement when it is possible to make requests via the LIR Portal. Assignments for anycasting DNS will come from reserved blocks: * IPv4 Anycast Assignments (/24) from 194.0.0.0/18 * IPv6 Anycast Assignments (/48) from 2001:0678::/29 You may want to update your filters. Regards, -- leo vegoda Registration Services Manager RIPE NCC From filiz at ripe.net Tue Sep 26 15:10:33 2006 From: filiz at ripe.net (Filiz Yilmaz) Date: Tue, 26 Sep 2006 15:10:33 +0200 Subject: [address-policy-wg] 2006-04 Draft Document will be produced (Contact e-mail Address Requirements) Message-ID: <20060926131033.E112D2F583@herring.ripe.net> PDP Number: 2006-04 Contact e-mail Address Requirements Dear Colleagues, The discussion period for the proposal 2006-04, Contact e-mail Address Requirements has ended. This proposal suggests that working and up-to-date contact e-mail addresses should be maintained at all times for address space that is registered in the RIPE Database. A draft document will now be prepared for review. We will publish the document in about four weeks. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-04.html Regards, Filiz Yilmaz RIPE NCC Policy Development Officer From jorgen at hovland.cx Tue Sep 26 15:36:35 2006 From: jorgen at hovland.cx (=?UTF-8?Q?J=C3=B8rgen_Hovland?=) Date: Tue, 26 Sep 2006 15:36:35 +0200 Subject: [address-policy-wg] 2006-04 Draft Document will be produced (Contact e-mail Address Requirements) In-Reply-To: <20060926131033.E112D2F583@herring.ripe.net> Message-ID: <007401c6e170$c971c120$4e27b3d5@tungemaskin> I find it ridiculous that the author of this proposal himself is not providing a real contact e-mail address in the proposal. If it was up to me, I would have rejected the policy proposal just because of that. Author: Jeffrey L. Scribner jscribner at localhost ASI Enterprises, Inc. j -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Filiz Yilmaz Sent: 26. september 2006 15:11 To: policy-announce at ripe.net Cc: Jeffrey L. Scribner; Hans Petter Holen; address-policy-wg at ripe.net Subject: [address-policy-wg] 2006-04 Draft Document will be produced (Contact e-mail Address Requirements) PDP Number: 2006-04 Contact e-mail Address Requirements Dear Colleagues, The discussion period for the proposal 2006-04, Contact e-mail Address Requirements has ended. This proposal suggests that working and up-to-date contact e-mail addresses should be maintained at all times for address space that is registered in the RIPE Database. A draft document will now be prepared for review. We will publish the document in about four weeks. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-04.html Regards, Filiz Yilmaz RIPE NCC Policy Development Officer From slz at baycix.de Tue Sep 26 15:46:41 2006 From: slz at baycix.de (Sascha Lenz) Date: Tue, 26 Sep 2006 15:46:41 +0200 Subject: [address-policy-wg] 2006-04 Draft Document will be produced (Contact e-mail Address Requirements) In-Reply-To: <007401c6e170$c971c120$4e27b3d5@tungemaskin> References: <007401c6e170$c971c120$4e27b3d5@tungemaskin> Message-ID: <45192F41.2000301@baycix.de> Hi, J?rgen Hovland wrote: > I find it ridiculous that the author of this proposal himself is not providing a real contact e-mail address in the proposal. > > If it was up to me, I would have rejected the policy proposal just because of that. > > Author: Jeffrey L. Scribner > jscribner at localhost > ASI Enterprises, Inc. [...] as you might have noticed by browsing through other RIPE Websites, this is just due to the very useful Anti-Spam-E-Mail-Address-obsfucator of the Webserver, nothing else. I'm sure the real E-Mail address is in the original proposal text :-) -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From Woeber at CC.UniVie.ac.at Tue Sep 26 16:10:10 2006 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 26 Sep 2006 14:10:10 +0000 Subject: [address-policy-wg] 2006-04 Draft Document will be produced (Contact e-mail Address Requirements) In-Reply-To: <007401c6e170$c971c120$4e27b3d5@tungemaskin> References: <007401c6e170$c971c120$4e27b3d5@tungemaskin> Message-ID: <451934C2.8070405@CC.UniVie.ac.at> J?rgen Hovland wrote: > I find it ridiculous that the author of this proposal himself is not providing a real contact e-mail address in the proposal. Following up... I was fooled by that a while ago, too :-) Just click on the mail address and - assuming you've got a compatible MUA - the compose window comes up with the correct mail address filled in. Wilfried. From Michael.Dillon at btradianz.com Tue Sep 26 16:16:40 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 26 Sep 2006 15:16:40 +0100 Subject: [address-policy-wg] 2006-04 Draft Document will be produced (Contact e-mail Address Requirements) In-Reply-To: <20060926131033.E112D2F583@herring.ripe.net> Message-ID: > http://www.ripe.net/ripe/policies/proposals/2006-04.html This policy is directed at ISPs and at their customers. >Registration data (range, contact information, status etc.) >must be correct at all times (i.e. they have to be maintained). >Every organisation controlling an IP address should provide >at least one working contact e-mail address where notifications >of abuse emanating from that IP address can be sent. A company in the SPAM business could be in full compliance with this policy if they operate an auto-responder like RIPE's hostmaster mailbox, which replies to every email saying "Thank you for your concern. We will deal with the matter promptly". The net benefit to the Internet community would be zero. >All persons and organisations assigned an IP address should >act to prevent abusive messages originating from that IP address. I don't believe that RIPE has any authority over what ISP customers do with their Internet connection. If a customer has a contract with and ISP for the purposes of originating abusive messages, then what authority does RIPE have to forbid this? On the other hand, if this is something which should be forbidden, who is the proper authority to take action? My answers are "None" and "National governments". A few days ago, whilst riding the tube to work, I was looking over someone's shoulder reading the newspaper. It was one of the cheap tabloids, possible the Sun. There was an advert for a company that offered to send abusive phone messages to someone else for a fee. It was an 0900 number which you dialled, then selected from a menu of message types, and then gave the number to be called. The choices were "Stop seeing my boyfriend", "Stop seeing my girlfriend", "Last notice to pay parking fine", "Mortgage reposession of home", etc. Clearly, there is at least one UK business that has a contract with a UK phone company for the purpose of originating abusive messages. Apparently, the regulator does not prohibit this, although maybe they simply don't know about it yet. In any case, the problem of sending abusive messages clearly does exist outside the Internet therefore it is NOT an Internet problem. If abusive messages are considered bad by society, then society should pass a law in the usual way rather than foisting unenforceable rules on the RIPE community. --Michael Dillon P.S. I am opposed to sending abusive messages and I would like to see them disappear from the Internet. But I also do not believe that any technical measures targetted at abusive messages will ever work since the perpetrators just discover new ways to avoid those measures. I really don't want to give the perpetrators an incentive to corrupt RIPE or the RIPE NCC which is what I believe will happen if RIPE gets in their way. From Michael.Dillon at btradianz.com Tue Sep 26 16:18:59 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 26 Sep 2006 15:18:59 +0100 Subject: [address-policy-wg] 2006-04 Draft Document will be produced (Contact e-mail Address Requirements) In-Reply-To: <45192F41.2000301@baycix.de> Message-ID: > > jscribner at localhost > > ASI Enterprises, Inc. > I'm sure the real E-Mail address is in the original proposal text :-) Just click on that funny email address in your web browser and the real email address automagically appears in your email client. --Michael Dillon From jorgen at hovland.cx Tue Sep 26 16:28:14 2006 From: jorgen at hovland.cx (=?UTF-8?Q?J=C3=B8rgen_Hovland?=) Date: Tue, 26 Sep 2006 16:28:14 +0200 Subject: [address-policy-wg] 2006-04 Draft Document will be produced (Contact e-mail Address Requirements) In-Reply-To: Message-ID: <008401c6e178$00df30f0$4e27b3d5@tungemaskin> Then I guess nobody will object when I put the following in my RIPE handle in order to be compliant with the new policy: e-mail: U2FsdGVkX19DjGgCGGBqHru1mllYpl+qhZZZycdQg9F42g== remarks: please decode my email address with base64 remarks: then decrypt it with AES-256-OFB using key jorgen remarks: then read from right to left remarks: In the subject you must put the name of the current day Or perhaps I should just use some javascript code instead? Or Haskell.. j -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Michael.Dillon at btradianz.com Sent: 26. september 2006 16:19 To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2006-04 Draft Document will be produced (Contact e-mail Address Requirements) > > jscribner at localhost > > ASI Enterprises, Inc. > I'm sure the real E-Mail address is in the original proposal text :-) Just click on that funny email address in your web browser and the real email address automagically appears in your email client. --Michael Dillon From Woeber at CC.UniVie.ac.at Tue Sep 26 18:19:54 2006 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 26 Sep 2006 16:19:54 +0000 Subject: [address-policy-wg] 2006-04 Draft Document will be produced (Contact e-mail Address Requirements) In-Reply-To: <008401c6e178$00df30f0$4e27b3d5@tungemaskin> References: <008401c6e178$00df30f0$4e27b3d5@tungemaskin> Message-ID: <4519532A.2040305@CC.UniVie.ac.at> >From a technical & security point of view I like your proposal :-) But... J?rgen Hovland wrote: > Then I guess nobody will object when I put the following in my RIPE handle in order to be compliant with the new policy: > > e-mail: U2FsdGVkX19DjGgCGGBqHru1mllYpl+qhZZZycdQg9F42g== > remarks: please decode my email address with base64 > remarks: then decrypt it with AES-256-OFB using key jorgen > remarks: then read from right to left > remarks: In the subject you must put the name of the current day > > Or perhaps I should just use some javascript code instead? Or Haskell.. > > > j ... quoting from $ whois -v person e-mail The e-mail address of a person, role, organisation or irt team. This attribute is filtered from the default whois output when at least one of the objects returned by the query contains an abuse-mailbox attribute. An e-mail address as defined in RFC 2822. I wonder if you approach is coverd by RFC 2822 :-) Wilfried. From leo at ripe.net Tue Sep 26 10:59:57 2006 From: leo at ripe.net (leo vegoda) Date: Tue, 26 Sep 2006 10:59:57 +0200 Subject: [address-policy-wg] [ncc-announce] 2005-02 implementation: IP assignments for anycasting DNS Message-ID: <271D7BC3-CF74-4877-A993-5918714DD514@ripe.net> Dear Colleagues, We are pleased to announce that we will be able to accept e-mailed requests for assignments for anycasting DNS servers from 2 October 2006. The request form and supporting notes will be available from the RIPE Document Store at: http://www.ripe.net/ripe/docs/internet-registries.html We will make a separate announcement when it is possible to make requests via the LIR Portal. Assignments for anycasting DNS will come from reserved blocks: * IPv4 Anycast Assignments (/24) from 194.0.0.0/18 * IPv6 Anycast Assignments (/48) from 2001:0678::/29 You may want to update your filters. Regards, -- leo vegoda Registration Services Manager RIPE NCC From denis at ripe.net Tue Sep 26 18:45:29 2006 From: denis at ripe.net (Denis Walker) Date: Tue, 26 Sep 2006 18:45:29 +0200 Subject: [address-policy-wg] 2006-04 Draft Document will be produced (Contact e-mail Address Requirements) In-Reply-To: <4519532A.2040305@CC.UniVie.ac.at> References: <008401c6e178$00df30f0$4e27b3d5@tungemaskin> <4519532A.2040305@CC.UniVie.ac.at> Message-ID: <45195929.6040605@ripe.net> Wilfried Woeber, UniVie/ACOnet wrote: > From a technical & security point of view I like your proposal :-) > But... > > J?rgen Hovland wrote: > > >> Then I guess nobody will object when I put the following in my RIPE handle in order to be compliant with the new policy: >> >> e-mail: U2FsdGVkX19DjGgCGGBqHru1mllYpl+qhZZZycdQg9F42g== >> remarks: please decode my email address with base64 >> remarks: then decrypt it with AES-256-OFB using key jorgen >> remarks: then read from right to left >> remarks: In the subject you must put the name of the current day >> >> Or perhaps I should just use some javascript code instead? Or Haskell.. >> >> >> j >> > > ... quoting from $ whois -v person > > e-mail > > The e-mail address of a person, role, organisation or irt team. > This attribute is filtered from the default whois output when at > least one of the objects returned by the query contains an > abuse-mailbox attribute. > > An e-mail address as defined in RFC 2822. > > > I wonder if you approach is coverd by RFC 2822 :-) > sorry guys....you will not get past the parser with this one :) cheers denis > Wilfried. > > From dogwallah at gmail.com Tue Sep 26 19:02:22 2006 From: dogwallah at gmail.com (McTim) Date: Tue, 26 Sep 2006 20:02:22 +0300 Subject: [address-policy-wg] 2006-04 Draft Document will be produced (Contact e-mail Address Requirements) In-Reply-To: References: <20060926131033.E112D2F583@herring.ripe.net> Message-ID: Hello Michael, On 9/26/06, Michael.Dillon at btradianz.com wrote: > > http://www.ripe.net/ripe/policies/proposals/2006-04.html > > This policy is directed at ISPs and at their customers. What makes you think this? > > >Registration data (range, contact information, status etc.) > >must be correct at all times (i.e. they have to be maintained). > >Every organisation controlling an IP address should provide > >at least one working contact e-mail address where notifications > >of abuse emanating from that IP address can be sent. > > A company in the SPAM business could be in full compliance > with this policy if they operate an auto-responder like > RIPE's hostmaster mailbox, which replies to every email > saying "Thank you for your concern. We will deal with > the matter promptly". The net benefit to the Internet > community would be zero. > yes, but it's not supposed to stop SPAM, just correct an old oversight, that of an email address not being a required contact detail. > >All persons and organisations assigned an IP address should > >act to prevent abusive messages originating from that IP address. > > I don't believe that RIPE has any authority over what > ISP customers do with their Internet connection. If > a customer has a contract with and ISP for the purposes > of originating abusive messages, then what authority > does RIPE have to forbid this? On the other hand, if this > is something which should be forbidden, who is the proper > authority to take action? My answers are "None" and > "National governments". > Would it be acceptable to you if it said: |All persons and organisations assigned an IP address should act to prevent abusive messages originating from that IP address without their knowledge" or smt similarly toothless?? -- Cheers, McTim $ whois -h whois.afrinic.net mctim From denis at ripe.net Tue Sep 26 19:36:16 2006 From: denis at ripe.net (Denis Walker) Date: Tue, 26 Sep 2006 19:36:16 +0200 Subject: [address-policy-wg] 2006-04 Draft Document will be produced (Contact e-mail Address Requirements) In-Reply-To: References: <20060926131033.E112D2F583@herring.ripe.net> Message-ID: <45196510.1010108@ripe.net> Hi It seems to me that this policy is about having a rule that says "everyone responsible for address space should provide contact details and keep them up to date". Having such a rule is a good starting point. But who is going to enforce it and how? Our support team already get many complaints about invalid contact details. If we have a policy that says people should keep them up to date, we may just get more complaints. People will tell us we have a policy about it so what are we going to do about it? let me give you a quote from our standard reply about invalid contact data: "There may be options we could pursue to check the validity of the contact data in the objects in the RIPE Database. Where we have a direct relationship with the owners of these objects we could request that they update this information. But we do not have a mandate from the RIPE community to allocate any resources to this activity. If you feel this should have a higher priority then you may raise the issue on the Database Working Group or Antispam Working Group or Address Policy Working Group mailing lists." So a question that needs answering is do you want to allocate resources to finding ways to check the validity of email addresses in the RIPE Databse and what realistic penalty can be applied to unreachable people? regards Denis Walker Software Engineering Department RIPE NCC McTim wrote: > Hello Michael, > > On 9/26/06, Michael.Dillon at btradianz.com > wrote: >> > http://www.ripe.net/ripe/policies/proposals/2006-04.html >> >> This policy is directed at ISPs and at their customers. > > What makes you think this? > >> >> >Registration data (range, contact information, status etc.) >> >must be correct at all times (i.e. they have to be maintained). >> >Every organisation controlling an IP address should provide >> >at least one working contact e-mail address where notifications >> >of abuse emanating from that IP address can be sent. >> >> A company in the SPAM business could be in full compliance >> with this policy if they operate an auto-responder like >> RIPE's hostmaster mailbox, which replies to every email >> saying "Thank you for your concern. We will deal with >> the matter promptly". The net benefit to the Internet >> community would be zero. >> > > yes, but it's not supposed to stop SPAM, just correct an old oversight, > that of an email address not being a required contact detail. > >> >All persons and organisations assigned an IP address should >> >act to prevent abusive messages originating from that IP address. >> >> I don't believe that RIPE has any authority over what >> ISP customers do with their Internet connection. If >> a customer has a contract with and ISP for the purposes >> of originating abusive messages, then what authority >> does RIPE have to forbid this? On the other hand, if this >> is something which should be forbidden, who is the proper >> authority to take action? My answers are "None" and >> "National governments". >> > > Would it be acceptable to you if it said: > > |All persons and organisations assigned an IP address should > act to prevent abusive messages originating from that IP address > without their knowledge" or smt similarly toothless?? > From Woeber at CC.UniVie.ac.at Wed Sep 27 00:02:22 2006 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 26 Sep 2006 22:02:22 +0000 Subject: [address-policy-wg] 2006-04 Draft Document will be produced (Contact e-mail Address Requirements) In-Reply-To: <45196510.1010108@ripe.net> References: <20060926131033.E112D2F583@herring.ripe.net> <45196510.1010108@ripe.net> Message-ID: <4519A36E.7020701@CC.UniVie.ac.at> Denis Walker wrote: [...] > ... If you feel this > should have a higher priority then you may raise the issue on the Database > Working Group or Antispam Working Group or Address Policy Working Group > mailing lists." My feeling is that the only appropriate one is the AP-WG - if at all. Anti-Spam seems to be a niche market, looking at the number of different abusive behaviour patterns, and DB-WG usually looks at issues regarding the tools and the registration machinery. In particular, DB-WG is very reluctant to get drawn into (human) resource allocation (i.e. money :-) ) discussions... Wilfried. PS: I know I am not making new friends with the following text, but still: Spam is not a network or addressing problem - it is an application and socio-economic problem. Now shoot - you know where to find me :-) From leo at ripe.net Tue Sep 26 10:59:57 2006 From: leo at ripe.net (leo vegoda) Date: Tue, 26 Sep 2006 10:59:57 +0200 Subject: [address-policy-wg] [ncc-co@ripe.net] [ncc-announce] 2005-02 implementation: IP assignments for anycasting DNS Message-ID: <271D7BC3-CF74-4877-A993-5918714DD514@ripe.net> Dear Colleagues, We are pleased to announce that we will be able to accept e-mailed requests for assignments for anycasting DNS servers from 2 October 2006. The request form and supporting notes will be available from the RIPE Document Store at: http://www.ripe.net/ripe/docs/internet-registries.html We will make a separate announcement when it is possible to make requests via the LIR Portal. Assignments for anycasting DNS will come from reserved blocks: * IPv4 Anycast Assignments (/24) from 194.0.0.0/18 * IPv6 Anycast Assignments (/48) from 2001:0678::/29 You may want to update your filters. Regards, -- leo vegoda Registration Services Manager RIPE NCC From Michael.Dillon at btradianz.com Wed Sep 27 11:15:44 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 27 Sep 2006 10:15:44 +0100 Subject: [address-policy-wg] 2006-04 Draft Document will be produced (Contact e-mail Address Requirements) In-Reply-To: Message-ID: > > This policy is directed at ISPs and at their customers. > > What makes you think this? Who else has IP addresses? > Would it be acceptable to you if it said: > > |All persons and organisations assigned an IP address should > act to prevent abusive messages originating from that IP address > without their knowledge" or smt similarly toothless?? No, because I don't believe it is appropriate for RIPE to require 3rd parties to supply any information at all, not email address, not company name, nothing at all. If the organization using the addresses has no legal contract with RIPE, then RIPE cannot oblige them to submit data for publication. I do think that it is a good idea for RIPE to require all LIRs to have an active, responsive email address that is published. And I think it is good for RIPE to allow 3rd parties to publish contact info if they operate an active and responsive email address. But if the 3rd party does not have a NOC or an abuse desk, then I would rather see no contact info published so that the LIR is the first point of contact. Since the LIR does have a contractual relationship with the 3rd party, they will know how to get their attention. Basically, I think this policy and much of the thinking behind the whois directory which RIPE publishes, is obsolete and has been obsolete for almost 10 years. Such things can only work in a collegial environment such as a university or a research consortium, but they have proven themselves to be totally unworkable on the public Internet. By publishing incorrect information, RIPE encourages people with abuse issues to waste valuable time trying to contact the wrong people. The fix to this problem is to remove all incorrect information from the whois directory that is published. --Michael Dillon From nils at druecke.strg-alt-entf.org Wed Sep 27 11:17:40 2006 From: nils at druecke.strg-alt-entf.org (Nils Ketelsen) Date: Wed, 27 Sep 2006 11:17:40 +0200 Subject: [address-policy-wg] 2006-04 Draft Document will be produced (Contact e-mail Address Requirements) In-Reply-To: References: Message-ID: <20060927091740.GA5176@h8000.serverkompetenz.net> On Wed, Sep 27, 2006 at 10:15:44AM +0100, Michael.Dillon at btradianz.com wrote: > > > This policy is directed at ISPs and at their customers. > > What makes you think this? > Who else has IP addresses? Corporate networks. And they do not need unique ones, to route them in the global routing table, but in other companies networks they connect to. Nils -- > What's the title for the head of the Greek Orthodox church? God [Rowan Mayfair ] From jordi.palet at consulintel.es Wed Sep 27 11:52:47 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 27 Sep 2006 11:52:47 +0200 Subject: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-02) Message-ID: Hi all, As the discussion period for this proposal (http://www.ripe.net/ripe/policies/proposals/2006-01.html) is almost over, I will like to ask for the latest inputs in order to further decide how to proceed. Filiz arranged some stats about the discussion (thanks a lot for that !) last July, and afterwards, even if the discussion period has been extended, I don't recall having seen new comments. The stats don't include my own postings: >>> - there were 39 posts from 14 different individuals about it. >>> >>> - 8 people supported it. >>> >>> - 1 person *seemed* to be in favour of keeping the current policy. >>> >>> - 5 people made comments which I could not identify a clear support or >>> objection. So someone else will like to say anything new or clarify their view in favor or opposition to the proposal ? Regards, Jordi ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From jordi.palet at consulintel.es Wed Sep 27 11:56:10 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 27 Sep 2006 11:56:10 +0200 Subject: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01) Message-ID: Hi all, Sorry confused stats. Ignore the previous email ... As the discussion period for this proposal (http://www.ripe.net/ripe/policies/proposals/2006-01.html) is almost over, I will like to ask for the latest inputs in order to further decide how to proceed. Filiz arranged some stats about the discussion (thanks a lot for that !) last July, and afterwards, even if the discussion period has been extended, I don't recall having seen new comments. The stats don't include my own postings: >>> - there were 9 posts from 8 individuals about it. >>> >>> - 5 people supported it. 1 of these made some comments though, that he >>> prefers a longer prefix than a /32 clearly in his mail. >>> >>> - 1 person stated he supports "PI" but he is not supporting this proposal. >>> >>> - 2 people said "No". So someone else will like to say anything new or clarify their view in favor or opposition to the proposal ? Regards, Jordi ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From denis at ripe.net Wed Sep 27 11:59:33 2006 From: denis at ripe.net (Denis Walker) Date: Wed, 27 Sep 2006 11:59:33 +0200 Subject: [address-policy-wg] 2006-04 Draft Document will be produced (Contact e-mail Address Requirements) In-Reply-To: <4519A36E.7020701@CC.UniVie.ac.at> References: <20060926131033.E112D2F583@herring.ripe.net> <45196510.1010108@ripe.net> <4519A36E.7020701@CC.UniVie.ac.at> Message-ID: <451A4B85.4040203@ripe.net> Wilfried Woeber, UniVie/ACOnet wrote: > Denis Walker wrote: > > [...] > >> ... If you feel this >> should have a higher priority then you may raise the issue on the Database >> Working Group or Antispam Working Group or Address Policy Working Group >> mailing lists." >> > > My feeling is that the only appropriate one is the AP-WG - if at all. > we can easily change this if the AP-WG is considered to be the best place to raise such issues. > Anti-Spam seems to be a niche market, looking at the number of different > abusive behaviour patterns, and DB-WG usually looks at issues regarding > the tools and the registration machinery. > > In particular, DB-WG is very reluctant to get drawn into (human) resource > allocation (i.e. money :-) ) discussions... > > Wilfried. > > PS: I know I am not making new friends with the following text, but still: > Spam is not a network or addressing problem - it is an application and > socio-economic problem. Now shoot - you know where to find me :-) > I think we are confusing two seperate issues here. Spam itself is a socio-economic-political problem. How to stop spam is outside the scope of network operations and addressing policy issues. But the issue here is if I can identify an individual spammer who is causing me problems who should I contact to try to have this person/organisation disconnected? This ties into the whole discussion on the irt object and abuse-mailbox: attributes. Even if we get this part exactly right, if the final email address we present to someone is invalid then the whole system breaks down. This brings us back to the question of how to enforce a policy that says everyone should keep their contact details up to date. I know it is a difficult question, but until it is addressed the whole policy on abuse handling fails. regards Denis Walker Software Engineering Department RIPE NCC From jordi.palet at consulintel.es Wed Sep 27 12:01:56 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Wed, 27 Sep 2006 12:01:56 +0200 Subject: [address-policy-wg] IPv6 Address Allocation and Assignment Policy (2006-02) Message-ID: Hi all, Same for this one ... Looking for further inputs to this policy proposal. As the discussion period for this proposal (http://www.ripe.net/ripe/policies/proposals/2006-02.html) is almost over, I will like to ask for the latest inputs in order to further decide how to proceed. Filiz arranged some stats about the discussion (thanks a lot for that !) last July, and afterwards, even if the discussion period has been extended, I don't recall having seen new comments. The stats don't include my own postings: >>> - there were 39 posts from 14 different individuals about it. >>> >>> - 8 people supported it. >>> >>> - 1 person *seemed* to be in favour of keeping the current policy. >>> >>> - 5 people made comments which I could not identify a clear support or >>> objection. So someone else will like to say anything new or clarify their view in favor or opposition to the proposal ? Regards, Jordi ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From Michael.Dillon at btradianz.com Wed Sep 27 13:15:53 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 27 Sep 2006 12:15:53 +0100 Subject: [address-policy-wg] 2006-04 Draft Document will be produced (Contact e-mail Address Requirements) In-Reply-To: <451A4B85.4040203@ripe.net> Message-ID: > But the issue here > is if I can identify an individual spammer who is causing me problems > who should I contact to try to have this person/organisation > disconnected? The answer is; you should contact someone who has committed to receive and act upon reports of network abuse. RIPE can get involved by requiring its LIRs to maintain an abuse desk that commits to receive and act upon abuse reports. Beyond this RIPE can publish the contact details for any 3rd parties who have committed to receive and act upon abuse reports. > This brings us back to the question of how to enforce a policy that says > everyone should keep their contact details up to date. I know it is a > difficult question, but until it is addressed the whole policy on abuse > handling fails. You are right that this is the key question. "Everyone" does not have a contractual relationship with RIPE therefore RIPE policies do not apply to "Everyone". This is unlikely to change. In any case, it is a waste of time directing abuse reports at "Everyone" because, chances are, "Everyone" has not made a commitment to receive and act upon abuse reports. Some might say; but "Everyone" should make such a commitment. That is a noble sentiment and one which often drives politicians to make laws. If you really believe in this sentiment then RIPE is the wrong place to discuss it because RIPE members are not politicians and RIPE has no input into national or EU laws. --Michael Dillon From kristian at spritelink.se Wed Sep 27 14:54:27 2006 From: kristian at spritelink.se (Kristian Larsson) Date: Wed, 27 Sep 2006 14:54:27 +0200 Subject: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01) In-Reply-To: References: Message-ID: <20060927125426.GJ20336@spritelink.se> On Wed, Sep 27, 2006 at 11:56:10AM +0200, JORDI PALET MARTINEZ wrote: > Hi all, > > Sorry confused stats. Ignore the previous email ... > > As the discussion period for this proposal > (http://www.ripe.net/ripe/policies/proposals/2006-01.html) is almost over, I > will like to ask for the latest inputs in order to further decide how to > proceed. > > Filiz arranged some stats about the discussion (thanks a lot for that !) > last July, and afterwards, even if the discussion period has been extended, > I don't recall having seen new comments. > > The stats don't include my own postings: > > >>> - there were 9 posts from 8 individuals about it. > >>> > >>> - 5 people supported it. 1 of these made some comments though, that he > >>> prefers a longer prefix than a /32 clearly in his mail. > >>> > >>> - 1 person stated he supports "PI" but he is not supporting this proposal. > >>> > >>> - 2 people said "No". > > So someone else will like to say anything new or clarify their view in favor > or opposition to the proposal ? I beleive most arguments have been spoken so I see no reason to delve further into this discussion but will instead promptly place my vote in favour of this proposal. Best regards, Kristian. -- Kristian Larsson KLL-RIPE Network Engineer Net at Once [AS35706] +46 704 910401 kristian at spritelink.se From marc.van.selm at nc3a.nato.int Thu Sep 28 09:50:30 2006 From: marc.van.selm at nc3a.nato.int (Marc van Selm) Date: Thu, 28 Sep 2006 09:50:30 +0200 Subject: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01) In-Reply-To: References: Message-ID: <200609280950.30905.marc.van.selm@nc3a.nato.int> Jordi, I support PI for IPv6 but I personally do not like the section: "Expiry for Assignments: Assignment blocks made under this proposal to address Multihoming issues must be returned to the RIPE NCC after a maximum period of three years. The three year period will run from the date that an alternative technically valid and deployable solution becomes available and is accepted by the Internet community. Any organisations that want to avoid renumbering would, at this time, be able to opt to become an LIR, if they qualify, and be allocated the same prefix." I'd recommend copying the accepted ARIN PI policy verbatim. One could discuss /32 or /48 but I would prefer a global policy over a regional policy. I won't be at the next RIPE meeting (have other commitments) but as one of the authors of NATO's IPv6 adoption plan I do not like the Expiry section although I understand that its there as a compromise. (We recommend in our plan for NATO to adopt the LIR route instead). So this is my vote: I support PI for IPv6 but I do not support this proposal. I recommend to follow ARIN which has beaten us to it... Best regards, Marc van Selm On Wednesday 27 September 2006 11:56, JORDI PALET MARTINEZ wrote: > Hi all, > > Sorry confused stats. Ignore the previous email ... > > As the discussion period for this proposal > (http://www.ripe.net/ripe/policies/proposals/2006-01.html) is almost over, > I will like to ask for the latest inputs in order to further decide how to > proceed. > > Filiz arranged some stats about the discussion (thanks a lot for that !) > last July, and afterwards, even if the discussion period has been extended, > I don't recall having seen new comments. > > The stats don't include my own postings: > >>> - there were 9 posts from 8 individuals about it. > >>> > >>> - 5 people supported it. 1 of these made some comments though, that he > >>> prefers a longer prefix than a /32 clearly in his mail. > >>> > >>> - 1 person stated he supports "PI" but he is not supporting this > >>> proposal. > >>> > >>> - 2 people said "No". > > So someone else will like to say anything new or clarify their view in > favor or opposition to the proposal ? > > Regards, > Jordi > > > > > > > ********************************************** > The IPv6 Portal: http://www.ipv6tf.org > > Bye 6Bone. Hi, IPv6 ! > http://www.ipv6day.org > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the > individual(s) named above. If you are not the intended recipient be aware > that any disclosure, copying, distribution or use of the contents of this > information, including attached files, is prohibited. -- -- This mail is personal -- All statements in this mail are made from my own personal perspective and do not necessarily reflect my employer's opinions or policies. From president at ukraine.su Thu Sep 28 14:11:48 2006 From: president at ukraine.su (Max Tulyev) Date: Thu, 28 Sep 2006 12:11:48 +0000 Subject: [address-policy-wg] 2006-04 Draft Document will be produced (Contact e-mail Address Requirements) In-Reply-To: References: Message-ID: <451BBC04.9070403@ukraine.su> Michael.Dillon at btradianz.com wrote: >>> This policy is directed at ISPs and at their customers. >> What makes you think this? > > Who else has IP addresses? Corporate, educational, goverment (yes, for example Security service of Ukraine, ex-KGB branch in Ukraine, have PI 193.29.204.0/24! :-) ). Even some individuals have it. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From Michael.Dillon at btradianz.com Thu Sep 28 11:42:01 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 28 Sep 2006 10:42:01 +0100 Subject: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01) In-Reply-To: <200609280950.30905.marc.van.selm@nc3a.nato.int> Message-ID: > I support PI for IPv6 but I personally do not like the section: > > "Expiry for Assignments: I agree that putting in an expiry date for non-experimental allocations is a bad idea. The only time an expiry date makes sense is when the allocation is being used for some kind of network research on a temporary basis. RIPE has the opportunity to change its policies at any time and if it is necessary to claw back those allocations then it could be done by a future change of policy. The people who make that future policy will be better informed about the situation than we are because they will have factual data about PI allocations. We can only guess about what will happen. It is far better to make sure that all organizations who receive assignments or allocations direct from RIPE have some kind of contractual obligation to RIPE and that contract includes the obligation to maintain accurate contact information. It doesn't mean that they have to publish the information, just make sure RIPE knows when they move or get bought by someone else so that if the policy changes in the future, we know where to contact them. This way we avoid the swamp problem where nobody knows how to contact many of the orgs that received swamp allocations. They may still exist at new addresses with a new name but we have lost touch. --Michael Dillon From jordi.palet at consulintel.es Thu Sep 28 12:24:36 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 28 Sep 2006 12:24:36 +0200 Subject: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01) In-Reply-To: <200609280950.30905.marc.van.selm@nc3a.nato.int> Message-ID: Hi Marc, Thanks a lot for your comments. Let me try to explain my motivation for the expiry date: Being honest with ourselves. The point is that some people don't like PI (including myself), while some other people may believe that may be (or not) an alternative technical solution in the future. Setting a temporary policy say everybody "this is only until we have a solution". In fact it is not required *because* the community can just cancel this policy when this solution is available, but it seem to me more honest to say in advance what is our plan (which anyway, can be changed in the future). Somehow, in my point of view, it may help to avoid some PI assignments if they are not *really* needed, or when regular assignments are possible (for example your own case, suggesting that because the type of infrastructure/organization, its better to go for becoming an LIR). Regarding the /32 or /48, I think we had very long discussions on that. I just don't believe the /48 will be reachable from all the networks, because many filter longer prefixes than /32, and this is not going to change easily, so consequently, I don't think people requiring PI, will take the risk. Is a non-sense asking for PI but not being sure it will be visible everywhere ... I've some cases of critical infrastructures which have got /48 instead of /32 and they are not visible, quite nice and *critical* for a critical infrastructure :-( Last, but not least, I also will prefer a "common" policy across the different regions, but I think we can't call it "global", because ICANN process, and in any case, it may be very difficult to coordinate that if not too late and impossible ... Regards, Jordi > De: Marc van Selm > Responder a: > Fecha: Thu, 28 Sep 2006 09:50:30 +0200 > Para: "address-policy-wg at ripe.net" > Asunto: Re: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for > End User Organisations (2006-01) > > Jordi, > > I support PI for IPv6 but I personally do not like the section: > > "Expiry for Assignments: > Assignment blocks made under this proposal to address Multihoming issues must > be returned to the RIPE NCC after a maximum period of three years. The three > year period will run from the date that an alternative technically valid and > deployable solution becomes available and is accepted by the Internet > community. Any organisations that want to avoid renumbering would, at this > time, be able to opt to become an LIR, if they qualify, and be allocated the > same prefix." > > I'd recommend copying the accepted ARIN PI policy verbatim. One could > discuss /32 or /48 but I would prefer a global policy over a regional policy. > > I won't be at the next RIPE meeting (have other commitments) but as one of the > authors of NATO's IPv6 adoption plan I do not like the Expiry section > although I understand that its there as a compromise. (We recommend in our > plan for NATO to adopt the LIR route instead). So this is my vote: I support > PI for IPv6 but I do not support this proposal. I recommend to follow ARIN > which has beaten us to it... > > Best regards, Marc van Selm > > On Wednesday 27 September 2006 11:56, JORDI PALET MARTINEZ wrote: >> Hi all, >> >> Sorry confused stats. Ignore the previous email ... >> >> As the discussion period for this proposal >> (http://www.ripe.net/ripe/policies/proposals/2006-01.html) is almost over, >> I will like to ask for the latest inputs in order to further decide how to >> proceed. >> >> Filiz arranged some stats about the discussion (thanks a lot for that !) >> last July, and afterwards, even if the discussion period has been extended, >> I don't recall having seen new comments. >> >> The stats don't include my own postings: >>>>> - there were 9 posts from 8 individuals about it. >>>>> >>>>> - 5 people supported it. 1 of these made some comments though, that he >>>>> prefers a longer prefix than a /32 clearly in his mail. >>>>> >>>>> - 1 person stated he supports "PI" but he is not supporting this >>>>> proposal. >>>>> >>>>> - 2 people said "No". >> >> So someone else will like to say anything new or clarify their view in >> favor or opposition to the proposal ? >> >> Regards, >> Jordi >> >> >> >> >> >> >> ********************************************** >> The IPv6 Portal: http://www.ipv6tf.org >> >> Bye 6Bone. Hi, IPv6 ! >> http://www.ipv6day.org >> >> This electronic message contains information which may be privileged or >> confidential. The information is intended to be for the use of the >> individual(s) named above. If you are not the intended recipient be aware >> that any disclosure, copying, distribution or use of the contents of this >> information, including attached files, is prohibited. > > -- > > -- This mail is personal -- > All statements in this mail are made from my own personal > perspective and do not necessarily reflect my employer's > opinions or policies. > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From tim.streater at dante.org.uk Thu Sep 28 12:28:24 2006 From: tim.streater at dante.org.uk (Tim Streater) Date: Thu, 28 Sep 2006 11:28:24 +0100 Subject: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01) In-Reply-To: References: Message-ID: <6.2.3.4.2.20060928112744.050669a8@mail.dante.org.uk> At 10:56 27/09/2006, JORDI PALET MARTINEZ wrote: >Hi all, > >Sorry confused stats. Ignore the previous email ... > >As the discussion period for this proposal >(http://www.ripe.net/ripe/policies/proposals/2006-01.html) is almost over, I >will like to ask for the latest inputs in order to further decide how to >proceed. > >Filiz arranged some stats about the discussion (thanks a lot for that !) >last July, and afterwards, even if the discussion period has been extended, >I don't recall having seen new comments. > >The stats don't include my own postings: > > >>> - there were 9 posts from 8 individuals about it. > >>> > >>> - 5 people supported it. 1 of these made some comments though, that he > >>> prefers a longer prefix than a /32 clearly in his mail. > >>> > >>> - 1 person stated he supports "PI" but he is not supporting this proposal. > >>> > >>> - 2 people said "No". > >So someone else will like to say anything new or clarify their view in favor >or opposition to the proposal ? Jordi, I also support this proposal. -- Tim From iljitsch at muada.com Thu Sep 28 12:46:35 2006 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 28 Sep 2006 12:46:35 +0200 Subject: [address-policy-wg] PI vs PA in routing table In-Reply-To: <45100F92.7080200@ukraine.su> References: <45100F92.7080200@ukraine.su> Message-ID: On 19-sep-2006, at 17:41, Max Tulyev wrote: > Is there a graphs shows how much prefixes in global route table are PA > and how much - PI (maybe in percents)? > And also this one year-by-year (monthly?)? > Maybe there is no real "route table PI pollution" trouble in the > real world? Ok a bit late but maybe this is useful: - there is no easy way to distinguish between a PI and a PA prefix - increase in RIR delegations last year was about 6%, increase in advertised prefixes around 16% - there are less than 20000 AS numbers and some 180000 prefixes, so at least 160000 of these prefixes aren't the result of multihoming as such (although multihomers can also advertise more than one prefix for traffic engineering reasons or no reason at all of course) (If multihoming is going to be a problem then look at AS numbers, the ASes used by ISPs won't be significant in that case) From president at ukraine.su Thu Sep 28 16:51:27 2006 From: president at ukraine.su (Max Tulyev) Date: Thu, 28 Sep 2006 14:51:27 +0000 Subject: [address-policy-wg] PI vs PA in routing table In-Reply-To: References: <45100F92.7080200@ukraine.su> Message-ID: <451BE16F.8000401@ukraine.su> Iljitsch van Beijnum wrote: > Ok a bit late but maybe this is useful: > > - there is no easy way to distinguish between a PI and a PA prefix RIPE (and other RIRs) DB? > - increase in RIR delegations last year was about 6%, increase in > advertised prefixes around 16% > > - there are less than 20000 AS numbers and some 180000 prefixes, so at > least 160000 of these prefixes aren't the result of multihoming as such > (although multihomers can also advertise more than one prefix for > traffic engineering reasons or no reason at all of course) > > (If multihoming is going to be a problem then look at AS numbers, the > ASes used by ISPs won't be significant in that case) This is not PI specific, as I can see. There is a lot of PA holders (LIRs) having just one uplink channel. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From marc.van.selm at nc3a.nato.int Thu Sep 28 12:58:36 2006 From: marc.van.selm at nc3a.nato.int (Marc van Selm) Date: Thu, 28 Sep 2006 12:58:36 +0200 Subject: [address-policy-wg] IPv6 Address Allocation and Assignment Policy (2006-02) In-Reply-To: References: Message-ID: <200609281258.36866.marc.van.selm@nc3a.nato.int> On Wednesday 27 September 2006 12:01, JORDI PALET MARTINEZ wrote: > Hi all, > > Same for this one ... Looking for further inputs to this policy proposal. I fully supported this proposal at it removes some arbitraby and virtually impossible to verify (for the RIPE-NCC) qualifiers. Marc -- -- This mail is personal -- All statements in this mail are made from my own personal perspective and do not necessarily reflect my employer's opinions or policies. From rogerj at jorgensen.no Thu Sep 28 13:16:04 2006 From: rogerj at jorgensen.no (Roger Jorgensen) Date: Thu, 28 Sep 2006 13:16:04 +0200 (CEST) Subject: [address-policy-wg] IPv6 Address Allocation and Assignment Policy (2006-02) In-Reply-To: <200609281258.36866.marc.van.selm@nc3a.nato.int> References: <200609281258.36866.marc.van.selm@nc3a.nato.int> Message-ID: It's now almost at the point where I start to wonder if Jordi have been arranging for people to send in their support. On Thu, 28 Sep 2006, Marc van Selm wrote: > On Wednesday 27 September 2006 12:01, JORDI PALET MARTINEZ wrote: > > Hi all, > > > > Same for this one ... Looking for further inputs to this policy proposal. -- ------------------------------ Roger Jorgensen | roger at jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- From Woeber at CC.UniVie.ac.at Thu Sep 28 13:32:29 2006 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 28 Sep 2006 11:32:29 +0000 Subject: [address-policy-wg] IPv6 Address Allocation and Assignment Policy (2006-02) In-Reply-To: References: <200609281258.36866.marc.van.selm@nc3a.nato.int> Message-ID: <451BB2CD.3040604@CC.UniVie.ac.at> Roger Jorgensen wrote: > It's now almost at the point where I start to wonder if Jordi have been > arranging for people to send in their support. Could you please be a bit more specific, in what you "really" want to say? > On Thu, 28 Sep 2006, Marc van Selm wrote: > >>On Wednesday 27 September 2006 12:01, JORDI PALET MARTINEZ wrote: >> >>>Hi all, >>> >>>Same for this one ... Looking for further inputs to this policy proposal. > > Otherwise I would consider your message off topic and inappropriate. But that's just my personal point of view, of course you are entitled to your point of view... Wilfried. From jordi.palet at consulintel.es Thu Sep 28 13:52:54 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 28 Sep 2006 13:52:54 +0200 Subject: [address-policy-wg] IPv6 Address Allocation and Assignment Policy (2006-02) In-Reply-To: Message-ID: Hi Roger, Not sure if you mean if I convinced in private to some people. If that was your idea, believe me, it has not been the case, I really prefer very open debate. I hate doing so, and actually if anyone contacted me in private, I always suggested to do it in the list (and there was one specific case only, who already went to the list). Even if it will not be "illegal" to try to convince people, as said, I'm not a fan at all of that, and actually seems to me more productive to raise all the pros and cons in the list. That's why we have a list, right ? And by the way, it has been my fault in the last months not having achieved more discussion on this, because I was too busy, so hopefully this is going to help before the end of the discussion period :-). Regards, Jordi > De: Roger Jorgensen > Responder a: > Fecha: Thu, 28 Sep 2006 13:16:04 +0200 (CEST) > Para: Marc van Selm > CC: "address-policy-wg at ripe.net" > Asunto: Re: [address-policy-wg] IPv6 Address Allocation and Assignment Policy > (2006-02) > > It's now almost at the point where I start to wonder if Jordi have been > arranging for people to send in their support. > > > > On Thu, 28 Sep 2006, Marc van Selm wrote: >> On Wednesday 27 September 2006 12:01, JORDI PALET MARTINEZ wrote: >>> Hi all, >>> >>> Same for this one ... Looking for further inputs to this policy proposal. > > > > > -- > > ------------------------------ > Roger Jorgensen | > roger at jorgensen.no | - IPv6 is The Key! > ------------------------------------------------------- > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From leo at ripe.net Thu Sep 28 13:55:31 2006 From: leo at ripe.net (leo vegoda) Date: Thu, 28 Sep 2006 13:55:31 +0200 Subject: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01) In-Reply-To: References: Message-ID: <31720A48-ECBB-40C3-A614-2D0673839A6D@ripe.net> Jordi, On 27 Sep 2006, at 11:56GMT+02:00, JORDI PALET MARTINEZ wrote: [...] > So someone else will like to say anything new or clarify their view > in favor > or opposition to the proposal ? The current draft policy text in your proposal includes this paragraph: "Expiry for Assignments: Assignment blocks made under this proposal to address Multihoming issues must be returned to the RIPE NCC after a maximum period of three years. The three year period will run from the date that an alternative technically valid and deployable solution becomes available and is accepted by the Internet community. Any organisations that want to avoid renumbering would, at this time, be able to opt to become an LIR, if they qualify, and be allocated the same prefix." We have reviewed this text from the perspective of the organisation implementing the proposed reclaim process. There are a few areas where we are not sure what is intended. Firstly, in the summary section of your proposal you state that PI assignments are useful because they facilitate multihoming and ease the process of changing upstream provider. However, the expiry clause in your draft text starts with the phrase "Assignment blocks made under this proposal to address Multihoming issues". Does this mean that only those prefixes assigned to enable multihoming would be subject to reclaim by the RIPE NCC? Would assignments made to allow stable addressing when changing from one upstream to another not be subject to reclaim? Does the alternative technological solution need to solve the multihoming problem or the address stability problem, or both? Also, can you help us understand what you mean by "is accepted by the Internet community"? Would you expect us to survey network operators for their opinions on the suitability of proposed solutions, or should we look to other methods of determining acceptance, like a RIPE document going through the RIPE PDP? Many thanks, -- leo vegoda Registration Services Manager RIPE NCC From Woeber at CC.UniVie.ac.at Thu Sep 28 14:00:39 2006 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 28 Sep 2006 12:00:39 +0000 Subject: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01) In-Reply-To: References: Message-ID: <451BB967.7070201@CC.UniVie.ac.at> JORDI PALET MARTINEZ wrote: [ ... ] > Last, but not least, I also will prefer a "common" policy across the > different regions, but I think we can't call it "global", because ICANN > process, and in any case, it may be very difficult to coordinate that if not > too late and impossible ... That is actually an issue I'd like to comment on. Regarding the use of words, what we can *try* to achieve across the regions is a thing that is called "globally coordinated". The first time we applied that approach to come up with (almost) identical, or at least very similar, polocies in all regions was the (dreaded) "200 Customer rule" for IPv6 PA Allocations. Whether it was wise to work towards such a compromise, which in retrospect left many in the community unhappy, is a different story... So - is anyone in a position to summarize for us which regions are doing that already (ARIN afair, others?) and what the size detais are, or which regions are working towards such a policy (RIPE obviously is). Can the NCC help out here? Wilfried. From jordi.palet at consulintel.es Thu Sep 28 14:10:21 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 28 Sep 2006 14:10:21 +0200 Subject: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01) In-Reply-To: <451BB967.7070201@CC.UniVie.ac.at> Message-ID: Hi Wilfried, I think I can do it, having been in all the RIR meeting since this started 2-3 years ago ... So in short, at the time being has been implemented only in ARIN, but is in last call also in APNIC since a couple of weeks ago (last meeting), as an IPv6 PI policy (using /48) policy achieved consensus. I've submitted basically the same proposal in LACNIC, AfriNIC and RIPE service regions, and there is no any other similar proposal in those regions. I also submitted it in APNIC but didn't achieved consensus (another proposal did, as indicated above). Regards, Jordi > De: "Wilfried Woeber, UniVie/ACOnet" > Organizaci?n: UniVie - ACOnet > Responder a: > Fecha: Thu, 28 Sep 2006 12:00:39 +0000 > Para: > CC: "address-policy-wg at ripe.net" > Asunto: Re: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for > End User Organisations (2006-01) > > JORDI PALET MARTINEZ wrote: > > [ ... ] >> Last, but not least, I also will prefer a "common" policy across the >> different regions, but I think we can't call it "global", because ICANN >> process, and in any case, it may be very difficult to coordinate that if not >> too late and impossible ... > > That is actually an issue I'd like to comment on. > > Regarding the use of words, what we can *try* to achieve across the regions is > a thing that is called "globally coordinated". The first time we applied that > approach to come up with (almost) identical, or at least very similar, > polocies > in all regions was the (dreaded) "200 Customer rule" for IPv6 PA Allocations. > > Whether it was wise to work towards such a compromise, which in retrospect > left > many in the community unhappy, is a different story... > > So - is anyone in a position to summarize for us which regions are doing that > already (ARIN afair, others?) and what the size detais are, or which regions > are working towards such a policy (RIPE obviously is). > > Can the NCC help out here? > > Wilfried. > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From Woeber at CC.UniVie.ac.at Thu Sep 28 14:14:56 2006 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 28 Sep 2006 12:14:56 +0000 Subject: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01) In-Reply-To: References: Message-ID: <451BBCC0.8090508@CC.UniVie.ac.at> JORDI PALET MARTINEZ wrote: [ ... ] > Regarding the /32 or /48, I think we had very long discussions on that. I > just don't believe the /48 will be reachable from all the networks, because > many filter longer prefixes than /32, and this is not going to change > easily, so consequently, I don't think people requiring PI, will take the > risk. Is a non-sense asking for PI but not being sure it will be visible > everywhere ... I've some cases of critical infrastructures which have got > /48 instead of /32 and they are not visible, quite nice and *critical* for a > critical infrastructure :-( I am *very* reluctant to accept the reasoning that we have to distribute "big" blocks (for any definition of big), because some ISPs have developed a habit of installing filters which are not compatible, or rather "properly take into account", developing address distribution mechanisms. I'd rather see a discussion regarding the "primary" target for this policy. Btw, my reasoning below is related to the "LIR/no LIR/LIR later" issue which I will address in a different message. So what's our target? I read the proposal as primarily being relevant to (quote from the proposal) "End User Organisations". This is what we usually refer to as a Site. And a Site usually gets a /48. Ignoring the discussions regarding *this* paricular default for the moment. For me, the conclusion is to use the /48 assingment size under this policy - unless a "globally coordinated" approach would suggest otherwise, of course. So here is a formal change request from my end to replace /32 by /48, in particular as there is a provision for requesting more, if necessary (quote from the proposal): "The minimum size of the assignment is /32. However, a larger assignment can be provided if duly documented and justified." While I do support the general idea of PI-Assignments for IPv6, I do *not* support this proposal as it is worded *right now*. Wilfried. From jordi.palet at consulintel.es Thu Sep 28 14:20:11 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 28 Sep 2006 14:20:11 +0200 Subject: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01) In-Reply-To: <31720A48-ECBB-40C3-A614-2D0673839A6D@ripe.net> Message-ID: Hi Leo, Thanks a lot for your inputs. See below, in-line. Regards, Jordi > De: leo vegoda > Responder a: > Fecha: Thu, 28 Sep 2006 13:55:31 +0200 > Para: > CC: > Asunto: Re: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for > End User Organisations (2006-01) > > Jordi, > > On 27 Sep 2006, at 11:56GMT+02:00, JORDI PALET MARTINEZ wrote: > > [...] > >> So someone else will like to say anything new or clarify their view >> in favor >> or opposition to the proposal ? > > The current draft policy text in your proposal includes this paragraph: > > "Expiry for Assignments: > Assignment blocks made under this proposal to address Multihoming > issues must be returned to the RIPE NCC after a maximum period of > three years. The three year period will run from the date that an > alternative technically valid and deployable solution becomes > available and is accepted by the Internet community. Any > organisations that want to avoid renumbering would, at this time, be > able to opt to become an LIR, if they qualify, and be allocated the > same prefix." > > We have reviewed this text from the perspective of the organisation > implementing the proposed reclaim process. There are a few areas > where we are not sure what is intended. Firstly, in the summary > section of your proposal you state that PI assignments are useful > because they facilitate multihoming and ease the process of changing > upstream provider. However, the expiry clause in your draft text > starts with the phrase "Assignment blocks made under this proposal to > address Multihoming issues". Does this mean that only those prefixes > assigned to enable multihoming would be subject to reclaim by the > RIPE NCC? Would assignments made to allow stable addressing when > changing from one upstream to another not be subject to reclaim? That was the idea in principle, to reclaim only those used for multihoming. However, I just realized that depending on the technical solution, it may be the case that this solution also solves the other scenarios, then we could reclaim all. To be honest, I'm not quite sure myself. We could probably tidy up the wording to keep that open, depending on the community decision at the time of the technical solution is "accepted". > > Does the alternative technological solution need to solve the > multihoming problem or the address stability problem, or both? We don't know yet, it may be or may be not, that's the point ... > > Also, can you help us understand what you mean by "is accepted by the > Internet community"? Would you expect us to survey network operators > for their opinions on the suitability of proposed solutions, or > should we look to other methods of determining acceptance, like a > RIPE document going through the RIPE PDP? I think the ideal will be to follow the RIPE PDP for that, however, a survey may always be useful in order to help in the PDP process. One doesn't exclude the other, and the final text, if this proposal become accepted should probably define that. Remember that my point about the "temporarily" is that any policy can be changed or amended thru the PDP process, but seems to me more honest doing it upfront. Otherwise, why we have "temporary policies" ? It will not make any sense ... > > Many thanks, > > -- > leo vegoda > Registration Services Manager > RIPE NCC > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From Michael.Dillon at btradianz.com Thu Sep 28 14:25:22 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 28 Sep 2006 13:25:22 +0100 Subject: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01) In-Reply-To: Message-ID: > ...but > it seem to me more honest to say in advance what is our plan (which anyway, > can be changed in the future). Exactly! Al plans are subject to change so it is not a question of honesty. > Somehow, in my point of view, it may help to > avoid some PI assignments if they are not *really* needed, or when regular > assignments are possible (for example your own case, suggesting that because > the type of infrastructure/organization, its better to go for becoming an > LIR). This is why the PI policy requires the sponsoring LIR to suggest alternate solutions to the applicant and the PI form asks the applicant if the LIR did discuss alternate solutions with them. I don't believe that an expiry date is an "honest" way to address this issue. If it is an issue then the policy should address it directly. > Regarding the /32 or /48, I think we had very long discussions on that. I > just don't believe the /48 will be reachable from all the networks, This automatically causes the policy to expire because if people notice that a policy doesn't work, they will get rid of it at some future time. On the other hand, we do not have the wisdom to see the future so we should not assume that reachability will be a problem. And if it is not a problem, then it is foolish for the policy to automatically expire. > Last, but not least, I also will prefer a "common" policy across the > different regions, but I think we can't call it "global", because ICANN > process, and in any case, it may be very difficult to coordinate that if not > too late and impossible ... The only way to achieve a common policy is to muddle through, make lots of mistakes, keep an eye on the other 4 RIRs and be willing to fix mistakes by changing policy WHEN WE HAVE THE INFORMATION to see what is really a mistake and what is not. We cannot legislate common policy in advance. And we will get to a common policy quicker if we accept that it is hard to write a 100% perfect policy but it is OK to have 50% of perfection the first time and then fix it later with a new proposal. --Michael Dillon From Woeber at CC.UniVie.ac.at Thu Sep 28 14:27:41 2006 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 28 Sep 2006 12:27:41 +0000 Subject: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01) In-Reply-To: References: Message-ID: <451BBFBD.8000404@CC.UniVie.ac.at> Michael.Dillon at btradianz.com wrote: >>I support PI for IPv6 but I personally do not like the section: >> >>"Expiry for Assignments: Nor do I. In particular I am missing a common understanding of how this is supposed to work in real life, regarding the path of submitting a request. Both from the point of view of a potential conflict of interest if we assume the same arrangement like for v4-PI, i.e. find a friendly LIR in good standing and ask them to submit the request on their account. This particularly delicate if the *assignment* size would remain at /32 as proposed, equal to the LIRs *allocation* size. And this approach of requesting resources "by proxy" has unwanted side effects like financial implications or loss of contact with the holder of the PI block. One of the real show-stoppers for me is (quote from the Proposal): "Any organisations that want to avoid renumbering would, at this time, be able to opt to become an LIR, if they qualify, and be allocated the same prefix." I am sorry, this doesn't cut it. So here is another formal change request: "An organisation that intends to request IPv6 PI Addresses under "this" policy have to become a Member of the RIPE NCC. The address assignment remains valid as long as the ... you know :-)" Cancelling the contractual relationship with the NCC should have the "usual" consequences, including those still to be developed like expiration of the digital certificate or RevDNS service, or address recalamtion, or... Btw, - what we are doing here is sort of opening a (controlled?) way around the 200 Customer Rule. Wilfried. From jordi.palet at consulintel.es Thu Sep 28 14:35:12 2006 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Thu, 28 Sep 2006 14:35:12 +0200 Subject: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01) In-Reply-To: <451BBCC0.8090508@CC.UniVie.ac.at> Message-ID: Hi Wilfried, Thanks again for your inputs. I fully understand your point, but you need to balance it with being temporary. We are not allocating this space for ever. Also it is not clear to me that a few hundreds of extras /32 will make a difference in terms of lifetime, specially having in a few years alternative technical solutions (again we are doing a temporary thing). On the other way around, what operators do to filter or not, is not our problem (as RIPE community), and we can't do nothing against that, so, do you really think it make sense to arrange a policy that may work only in some networks ? Let's be realistic ! One possibility will be to allocate /48 but keep reserved the remaining /32. If the applicant justify that the /48 is getting filtered, then he may opt to justify to obtain the /32. Is this a possible compromise solution ? Regards, Jordi > De: "Wilfried Woeber, UniVie/ACOnet" > Organizaci?n: UniVie - ACOnet > Responder a: > Fecha: Thu, 28 Sep 2006 12:14:56 +0000 > Para: > CC: "address-policy-wg at ripe.net" > Asunto: Re: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for > End User Organisations (2006-01) > > JORDI PALET MARTINEZ wrote: > > [ ... ] >> Regarding the /32 or /48, I think we had very long discussions on that. I >> just don't believe the /48 will be reachable from all the networks, because >> many filter longer prefixes than /32, and this is not going to change >> easily, so consequently, I don't think people requiring PI, will take the >> risk. Is a non-sense asking for PI but not being sure it will be visible >> everywhere ... I've some cases of critical infrastructures which have got >> /48 instead of /32 and they are not visible, quite nice and *critical* for a >> critical infrastructure :-( > > I am *very* reluctant to accept the reasoning that we have to distribute "big" > blocks (for any definition of big), because some ISPs have developed a habit > of installing filters which are not compatible, or rather "properly take into > account", developing address distribution mechanisms. > > I'd rather see a discussion regarding the "primary" target for this policy. > Btw, my reasoning below is related to the "LIR/no LIR/LIR later" issue which I > will address in a different message. > > So what's our target? I read the proposal as primarily being relevant to > (quote > from the proposal) "End User Organisations". This is what we usually refer to > as > a Site. And a Site usually gets a /48. Ignoring the discussions regarding > *this* > paricular default for the moment. > > For me, the conclusion is to use the /48 assingment size under this policy - > unless > a "globally coordinated" approach would suggest otherwise, of course. > > So here is a formal change request from my end to replace /32 by /48, in > particular > as there is a provision for requesting more, if necessary (quote from the > proposal): > > "The minimum size of the assignment is /32. However, a larger assignment can > be > provided if duly documented and justified." > > While I do support the general idea of PI-Assignments for IPv6, I do *not* > support > this proposal as it is worded *right now*. > > Wilfried. > ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From cfriacas at fccn.pt Thu Sep 28 14:36:33 2006 From: cfriacas at fccn.pt (Carlos Friacas) Date: Thu, 28 Sep 2006 13:36:33 +0100 (WEST) Subject: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01) In-Reply-To: <451BBCC0.8090508@CC.UniVie.ac.at> References: <451BBCC0.8090508@CC.UniVie.ac.at> Message-ID: Hello, While I do support the general idea of PI-Assignments for IPv6 (mainly as a way of facilitating certain networks to move into IPv6...), at the moment i do *NOT* support this 2006-01 proposal due to some specific wording, already mentioned by other participants. I'm also in favour of going with /48s, and grow from there if needed. Best Regards, ./Carlos -------------- Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (196663/675), naming (millions) and... people!" From cfriacas at fccn.pt Thu Sep 28 14:50:18 2006 From: cfriacas at fccn.pt (Carlos Friacas) Date: Thu, 28 Sep 2006 13:50:18 +0100 (WEST) Subject: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01) In-Reply-To: References: Message-ID: On Thu, 28 Sep 2006, JORDI PALET MARTINEZ wrote: > Hi Wilfried, Hi All, > Thanks again for your inputs. > > I fully understand your point, but you need to balance it with being > temporary. We are not allocating this space for ever. Imho, that's a risky thing to say. :-)) Afaik, experiments can be extended, and then extended, and later extended a bit more... > Also it is not clear > to me that a few hundreds of extras /32 will make a difference in terms of > lifetime, specially having in a few years alternative technical solutions > (again we are doing a temporary thing). Out of plain curiosity: are really those alternatives bound to happen in say 5-10 years? > On the other way around, what operators do to filter or not, is not our > problem (as RIPE community), and we can't do nothing against that, so, do > you really think it make sense to arrange a policy that may work only in > some networks ? Let's be realistic ! Here i fully agree with Wilfried! If operator A is filtering out PI network B, then customer C (which is paying operator A) is entitled to complain and "suggest" operator A to correct its filtering (or he can always find a new operator, with a better customer needs' focus!) > One possibility will be to allocate /48 but keep reserved the remaining /32. > If the applicant justify that the /48 is getting filtered, then he may opt > to justify to obtain the /32. Is this a possible compromise solution ? A lot more reasonable yes, but if he needs an upgrade from /48 -> /40 he should get a /40, not immediately a /32. :-) > Regards, > Jordi Regards, ./Carlos -------------- Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (196663/675), naming (millions) and... people!" From Woeber at CC.UniVie.ac.at Thu Sep 28 14:55:44 2006 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 28 Sep 2006 12:55:44 +0000 Subject: [address-policy-wg] PI vs PA in routing table In-Reply-To: References: <45100F92.7080200@ukraine.su> Message-ID: <451BC650.2030208@CC.UniVie.ac.at> Iljitsch van Beijnum wrote: [...] > - there is no easy way to distinguish between a PI and a PA prefix I presume the RIPE NCC would assign those blocks from a "separate" address range, much like it is the habit for IPv4 PI. And of coure include that informtion in the *usual* reports and places. Maybe this should go into the proposal? Wilfried. From Woeber at CC.UniVie.ac.at Thu Sep 28 16:20:04 2006 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 28 Sep 2006 14:20:04 +0000 Subject: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01) In-Reply-To: References: Message-ID: <451BDA14.1070404@CC.UniVie.ac.at> ?Hola Jordi! JORDI PALET MARTINEZ wrote: > Hi Wilfried, > > Thanks again for your inputs. > > I fully understand your point, but you need to balance it with being > temporary. We are not allocating this space for ever. It is a noble mindset to assume just a transient issue, but in reality nothing tends to last longer than a quick hack :-) > Also it is not clear > to me that a few hundreds of extras /32 will make a difference in terms of > lifetime, No, I agree. But whay are we having the discussion on /48, /56, /?? then and the impact of different values of HD_ratio on the lifetime of IPv6? It won't fly to propose reducing /48 to say a /56 for the "masses" of *PA* space users and in parallel give away a /32 for a *PI* Site at the same time. > specially having in a few years alternative technical solutions > (again we are doing a temporary thing). Right now I am not holding my breath. Not because I don't belive in a solution being theoretically possible, but rather looking at the fact that nobody cares, really. Still readin the CIDR Report, anyone ;-) > On the other way around, what operators do to filter or not, is not our > problem (as RIPE community), Exactly, but my conclusion is different :-) > and we can't do nothing against that, so, do > you really think it make sense to arrange a policy that may work only in > some networks ? Let's be realistic ! I can't see why "this" address space is sooo different. We always have to deal with ISPs that don't track real life developments. And there may be ISPs which - for whaterever "good" reason - may want to block those address ranges. Playing silly games with the *size* won't make a big difference. What *will* make a difference is full integration into the regular set of proactive provisions trying to minimize those *accidental* problems. Like announcing a test prefix from the range, alerting people that assignemnts from a different block of addresses will commence soon, and the like. This is business as usal already in our Service Region. The rest is an issue for a trouble ticket and for obtaining support from your upstream(s) you are paying money to, in particular for providing *end-to-end* connectivity :-) > One possibility will be to allocate /48 but keep reserved the remaining /32. > If the applicant justify that the /48 is getting filtered, then he may opt > to justify to obtain the /32. Is this a possible compromise solution ? Come on, what's in a "justify" to get a free upgrade to "business class"? Your ISP(s) would be more than happy to "prove" that. Their product development folks might even offer that as a commercial service :-) I'm convinced that the NCC will be doing "The Right Thing[TM]" to make sure there's room to grow, and maybe even to upgrade such an End-Site PI block to a regular LIR PA block. Actually that might be conflicting goals, and may involve re-numbering :-( > Regards, > Jordi Saludos, Wilfried. From filiz at ripe.net Thu Sep 28 16:24:46 2006 From: filiz at ripe.net (Filiz Yilmaz) Date: Thu, 28 Sep 2006 16:24:46 +0200 Subject: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01) In-Reply-To: <451BB967.7070201@CC.UniVie.ac.at> References: <451BB967.7070201@CC.UniVie.ac.at> Message-ID: <451BDB2E.4010904@ripe.net> Hello, Jordi already answered the question specifically about this proposal. There is a presentation scheduled during RIPE 53 next week, on 5 October, for Thursday Plenary session. It will give a summary about this proposal and others that are common across regions. Kind regards, Filiz Yilmaz RIPE NCC Policy Development Officer Wilfried Woeber, UniVie/ACOnet wrote: > JORDI PALET MARTINEZ wrote: > > [ ... ] > >>Last, but not least, I also will prefer a "common" policy across the >>different regions, but I think we can't call it "global", because ICANN >>process, and in any case, it may be very difficult to coordinate that if not >>too late and impossible ... > > > That is actually an issue I'd like to comment on. > > Regarding the use of words, what we can *try* to achieve across the regions is > a thing that is called "globally coordinated". The first time we applied that > approach to come up with (almost) identical, or at least very similar, polocies > in all regions was the (dreaded) "200 Customer rule" for IPv6 PA Allocations. > > Whether it was wise to work towards such a compromise, which in retrospect left > many in the community unhappy, is a different story... > > So - is anyone in a position to summarize for us which regions are doing that > already (ARIN afair, others?) and what the size detais are, or which regions > are working towards such a policy (RIPE obviously is). > > Can the NCC help out here? > > Wilfried. > From iljitsch at muada.com Thu Sep 28 17:51:42 2006 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Thu, 28 Sep 2006 17:51:42 +0200 Subject: Keeping in reserve, was: Re: [address-policy-wg] Provider Independent (PI) IPv6 Assignments for End User Organisations (2006-01) In-Reply-To: References: Message-ID: On 28-sep-2006, at 14:35, JORDI PALET MARTINEZ wrote: > One possibility will be to allocate /48 but keep reserved the > remaining /32. > If the applicant justify that the /48 is getting filtered, then he > may opt > to justify to obtain the /32. Is this a possible compromise solution ? History, both in IPv4 and IPv6, has shown that keeping space in reserve to accommodate future request doesn't work very well: people often end up announcing several blocks anyway. So let's not waste the space and make filtering harder by doing this. Also, since a /48 is an incredible amount of space to begin with, coming back for more should be rare in IPv6. The advantage of only giving out /48s with no unused space between them is that if, for instance, 12000 /48s are given out, that will be from a single /34 and allowing /48s from a /34 allows 16384 routes, while allowing /48s from a /20 (because for every /48 of 12000 a /32 is kept in reserve) allows 268 million routes, more than enough to overload any reasonable routing system in an attack. From leo at ripe.net Tue Sep 26 10:59:57 2006 From: leo at ripe.net (leo vegoda) Date: Tue, 26 Sep 2006 10:59:57 +0200 Subject: [address-policy-wg] [ncc-co@ripe.net] [ncc-announce] 2005-02 implementation: IP assignments for anycasting DNS Message-ID: <271D7BC3-CF74-4877-A993-5918714DD514@ripe.net> Dear Colleagues, We are pleased to announce that we will be able to accept e-mailed requests for assignments for anycasting DNS servers from 2 October 2006. The request form and supporting notes will be available from the RIPE Document Store at: http://www.ripe.net/ripe/docs/internet-registries.html We will make a separate announcement when it is possible to make requests via the LIR Portal. Assignments for anycasting DNS will come from reserved blocks: * IPv4 Anycast Assignments (/24) from 194.0.0.0/18 * IPv6 Anycast Assignments (/48) from 2001:0678::/29 You may want to update your filters. Regards, -- leo vegoda Registration Services Manager RIPE NCC