From contact at ripe.net Wed Aug 9 13:06:25 2006 From: contact at ripe.net (Paul Rendek) Date: Wed, 09 Aug 2006 13:06:25 +0200 Subject: [address-policy-wg] Second Call For Nominations for NRO Number Council Seat 2006 Message-ID: <44D9C1B1.1030207@ripe.net> [Apologies for duplicate e-mails] Dear Colleagues, This is a second call for nominations from the RIPE NCC service region to fill one vacant seat on the Number Resource Organization (NRO) Number Council (NC). 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. For more information about the NRO NC, nominations and the election process, see: http://www.ripe.net/info/resource-admin/nro2006/ Nominations can be sent to: nominations at ripe.net ========================================================================== Deadline for nominations: 4 September, 2006 Elections: 4 October, 2006, at the RIPE 53 Meeting, Amsterdam, the Netherlands =========================================================================== Regards, Paul Rendek Head of Member Services & Communications RIPE NCC From filiz at ripe.net Mon Aug 21 14:11:37 2006 From: filiz at ripe.net (Filiz Yilmaz) Date: Mon, 21 Aug 2006 14:11:37 +0200 Subject: [address-policy-wg] 2005-12 Last Call for Comments (4-Byte AS Number Policy) Message-ID: <20060821121137.D44322F592@herring.ripe.net> PDP Number: 2005-12 4-Byte AS Number Policy Dear Colleagues The proposal described in 2005-12 is now at its final stage. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-12.html and the draft documents at: http://www.ripe.net/ripe/draft-documents/2005-12-draft.html Please e-mail any final comments about this proposal to address-policy-wg at ripe.net before 18 September 2006. We will publish the new policy after this date if we receive no objections. Regards Filiz Yilmaz RIPE NCC Policy Development Officer From swmike at swm.pp.se Mon Aug 21 14:31:38 2006 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 21 Aug 2006 14:31:38 +0200 (CEST) Subject: [address-policy-wg] Proposal for change to the IPv4 PI allocation policy Message-ID: Hello. Following a discussion between some people and the resulting request to bring the discussion here I would like to propose a change to allocation policy for small PI blocks. Today it's a problem that the ISP industry BCP involves filtering all announcements smaller than /24 from BGP, this meaning that a smaller allocation from RIPE is pretty much unusual in the "real world" if you want to be on the public internet. I would therefore like to see a discussion about making it an option to actually get a /24 for routing reasons, disregarding current policy of disallowing routing problems as justification to request an allocation bigger than you might be able to justify from address usage alone. I know I ran into this problem when I first started in the ISP business around 1995, and it's still there, so might it be time to change? People with enough experience will creatively "enhance" (ie lie) address requests to actually reach the /24 size today, and people without experience will make an honest request and then run into practical problems with their newly allocated space when they want to use it in real life, due to it being filtered because it's too small according to industry BCP. This is of course a bad situation either way and I hope it can be rectified. Thanks for your attention. -- Mikael Abrahamsson email: swmike at swm.pp.se From dmitry at volia.net Mon Aug 21 14:40:17 2006 From: dmitry at volia.net (Dmitry Kiselev) Date: Mon, 21 Aug 2006 15:40:17 +0300 Subject: [address-policy-wg] Proposal for change to the IPv4 PI allocation policy In-Reply-To: References: Message-ID: <20060821124017.GD56407@f17.dmitry.net> Hello! On Mon, Aug 21, 2006 at 02:31:38PM +0200, Mikael Abrahamsson wrote: > Hello. > > Following a discussion between some people and the resulting request to > bring the discussion here I would like to propose a change to allocation > policy for small PI blocks. > > Today it's a problem that the ISP industry BCP involves filtering all > announcements smaller than /24 from BGP, this meaning that a smaller > allocation from RIPE is pretty much unusual in the "real world" if you > want to be on the public internet. > > I would therefore like to see a discussion about making it an option to > actually get a /24 for routing reasons, disregarding current policy of > disallowing routing problems as justification to request an allocation > bigger than you might be able to justify from address usage alone. > > I know I ran into this problem when I first started in the ISP business > around 1995, and it's still there, so might it be time to change? People > with enough experience will creatively "enhance" (ie lie) address requests > to actually reach the /24 size today, and people without experience will > make an honest request and then run into practical problems with their > newly allocated space when they want to use it in real life, due to it > being filtered because it's too small according to industry BCP. This is > of course a bad situation either way and I hope it can be rectified. > > Thanks for your attention. Do You mean PI *ASSIGNMENT*? According to ripe-368, no new PI allocations are allowed. -- Dmitry Kiselev From president at ukraine.su Mon Aug 21 18:54:42 2006 From: president at ukraine.su (Max Tulyev) Date: Mon, 21 Aug 2006 16:54:42 +0000 Subject: [address-policy-wg] Proposal for change to the IPv4 PI allocation policy In-Reply-To: <20060821124017.GD56407@f17.dmitry.net> References: <20060821124017.GD56407@f17.dmitry.net> Message-ID: <44E9E552.5050305@ukraine.su> Hi! Dmitry Kiselev wrote: > Hello! > > On Mon, Aug 21, 2006 at 02:31:38PM +0200, Mikael Abrahamsson wrote: > > >> Hello. >> >> Following a discussion between some people and the resulting request to >> bring the discussion here I would like to propose a change to allocation >> policy for small PI blocks. >> >> Today it's a problem that the ISP industry BCP involves filtering all >> announcements smaller than /24 from BGP, this meaning that a smaller >> allocation from RIPE is pretty much unusual in the "real world" if you >> want to be on the public internet. >> >> I would therefore like to see a discussion about making it an option to >> actually get a /24 for routing reasons, disregarding current policy of >> disallowing routing problems as justification to request an allocation >> bigger than you might be able to justify from address usage alone. >> >> I know I ran into this problem when I first started in the ISP business >> around 1995, and it's still there, so might it be time to change? People >> with enough experience will creatively "enhance" (ie lie) address requests >> to actually reach the /24 size today, and people without experience will >> make an honest request and then run into practical problems with their >> newly allocated space when they want to use it in real life, due to it >> being filtered because it's too small according to industry BCP. This is >> of course a bad situation either way and I hope it can be rectified. >> >> Thanks for your attention. >> > > > Do You mean PI *ASSIGNMENT*? According to ripe-368, no new PI allocations > are allowed. > > Yes, it seems to be about assignments. As many persons like to write in blogs and forums - "+1" from me ;) It is a good idea to set formalities as close to real life as possible, and also prevent unexperienced people from troubles. Another good idea is to remove user scaring story about PI is worse routeable than PA from RIPE documents. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From slz at baycix.de Mon Aug 21 14:59:13 2006 From: slz at baycix.de (Sascha Lenz) Date: Mon, 21 Aug 2006 14:59:13 +0200 Subject: [address-policy-wg] Proposal for change to the IPv4 PI allocation policy In-Reply-To: References: Message-ID: <44E9AE21.6060301@baycix.de> Hi, Mikael Abrahamsson wrote: > > Hello. > > Following a discussion between some people and the resulting request to > bring the discussion here I would like to propose a change to allocation > policy for small PI blocks. > > Today it's a problem that the ISP industry BCP involves filtering all > announcements smaller than /24 from BGP, this meaning that a smaller > allocation from RIPE is pretty much unusual in the "real world" if you > want to be on the public internet. > > I would therefore like to see a discussion about making it an option to > actually get a /24 for routing reasons, disregarding current policy of > disallowing routing problems as justification to request an allocation > bigger than you might be able to justify from address usage alone. > > I know I ran into this problem when I first started in the ISP business > around 1995, and it's still there, so might it be time to change? People > with enough experience will creatively "enhance" (ie lie) address > requests to actually reach the /24 size today, and people without > experience will make an honest request and then run into practical > problems with their newly allocated space when they want to use it in > real life, due to it being filtered because it's too small according to > industry BCP. This is of course a bad situation either way and I hope it > can be rectified. [...i assume you mean PI _Assignments_...] The problem is, there is no way to tell anyone what prefixes they "have to accept" or not, and i see "the common /24 filter" coming up soon in my crystal ball (once again due to RAM/TCAM restrictions). Filtering everything longer than /24 is just what the majority of ASs do today. Hence, no real way to put such an abitrary number in a policy document. I have no problem with wasting IPv4 space at all, so i won't object any change of the policy to allow people to get a /24 or /23 PI as minimum. But what comes next? Same for IPv6? Let's assign /32 due to routing reasons? (yes, yes, yes! stubborn /32-/35 filter-guys die die die :-) ) Probably we just should keep the policy, but put some more stress on the routing issue in the supporting documents/FAQs, so "new" people don't waste their time requesting 100 IPv4 PI Addresses or so and rant about it after they started realizing that this probably isn't what they wanted in the first place. Though, that doesn't solve the "lieing" problem. ...just my 0.02EUR without thinking about the issue in deep since IPv4 is legacy anyways :-) -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From filiz at ripe.net Mon Aug 21 15:02:01 2006 From: filiz at ripe.net (Filiz Yilmaz) Date: Mon, 21 Aug 2006 15:02:01 +0200 Subject: [address-policy-wg] 2006-01 Discussion Period extended until 2 October 2006 (Provider Independent (PI) IPv6 Assignments for End User Organisations) Message-ID: <20060821130201.E1F682F5AD@herring.ripe.net> PDP Number: 2006-01 Provider Independent (PI) IPv6 Assignments for End User Organisations and PDP Number: 2006-02 IPv6 Address Allocation and Assignment Policy Dear Colleagues The Discussion Period for proposals 2006-01 and 2006-02 has been extended until 2 October 2006 2006-01 is intended to provide a solution for organisations that need IPv6 Provider Independent (PI) assignments and 2006-02 is to change the IPv6 Initial Allocation criteria, the End Site definition and assignment of multiple /48s to a single End Site as outlined in the "IPv6 Address Allocation and Assignment Policy". You can find the full proposals at: http://www.ripe.net/ripe/policies/proposals/2006-01.html and http://www.ripe.net/ripe/policies/proposals/2006-02.html We encourage you to review this policy proposal and send your comments to . Regards Filiz Yilmaz RIPE NCC Policy Development Officer From swmike at swm.pp.se Mon Aug 21 15:22:29 2006 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Mon, 21 Aug 2006 15:22:29 +0200 (CEST) Subject: [address-policy-wg] Proposal for change to the IPv4 PI allocation policy In-Reply-To: <44E9AE21.6060301@baycix.de> References: <44E9AE21.6060301@baycix.de> Message-ID: On Mon, 21 Aug 2006, Sascha Lenz wrote: > The problem is, there is no way to tell anyone what prefixes they "have > to accept" or not, and i see "the common /24 filter" coming up soon in > my crystal ball (once again due to RAM/TCAM restrictions). > Filtering everything longer than /24 is just what the majority of ASs do > today. Yes, so if you want to use your assignment (excuse me for not understanding the difference) in real life internet, you need /24 or bigger. > Hence, no real way to put such an abitrary number in a policy document. Well, if you remove the "you cannot use routing reasons for requesting a certain size"-part of the policy, the requesting party can try to justify their request from all aspects that they need to take into account. If the space is not going to be routed, they can use smaller than /24, if they want to multihome and have good justification, then they can request a /24 even if they cannot justify it from a pure IP usage aspect. > I have no problem with wasting IPv4 space at all, so i won't object any Well, I am not sure it's wasting IPv4 space anyway, as people still get /24 today, but they get it by falsifying information. A lot of people know in practice how to get what they want, but they need to be creative with the truth to get there. > But what comes next? Same for IPv6? Let's assign /32 due to routing > reasons? (yes, yes, yes! stubborn /32-/35 filter-guys die die die :-) ) Could we please look at each proposed change on its own merit without expanding the scope to other protocols? I am not sure there is a BCP on IPv6 yet? If there is, I am sure it's much more flexible and can be more easily changed than current IPv4 implementation. > Probably we just should keep the policy, but put some more stress on the > routing issue in the supporting documents/FAQs, so "new" people don't > waste their time requesting 100 IPv4 PI Addresses or so and rant about > it after they started realizing that this probably isn't what they > wanted in the first place. > Though, that doesn't solve the "lieing" problem. Exactly. My view is that if you need to multihome on the public internet today you need a /24 in real life to get it to work. If you cannot get that /24, you might as well not get anything at all. Assigning a /27 to them will not solve their problem. I think it's very important to make RIPE, ARIN, AP-NIC et al, who assign addresses to work together with the people doing the routing BCPs. Addresses are nothing without routing, and we need to look at the big picture. People want to communicate. -- Mikael Abrahamsson email: swmike at swm.pp.se From filiz at ripe.net Mon Aug 21 16:52:07 2006 From: filiz at ripe.net (Filiz Yilmaz) Date: Mon, 21 Aug 2006 16:52:07 +0200 Subject: [address-policy-wg] 2005-02 Last Call for Comments (IP Assignments for Anycasting DNS) Message-ID: <20060821145207.1CFE12F592@herring.ripe.net> PDP Number: 2005-02 IP Assignments for anycasting DNS Dear Colleagues The proposal described in 2005-02 is now in its Concluding Phase. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2005-2.html During the review phase, we received feedback that suggested improvements to the text: - The resulting policy text should explicitly state that it is for ccTLDs and gTLDs - The text should explicitly state that the RIPE NCC will make assignments directly when a request is submitted through an existing LIR. We have incorporated this in the draft documents that you can find at: http://www.ripe.net/ripe/draft-documents/2005-02-draft.html http://www.ripe.net/ripe/draft-documents/2005-02-v6-draft.html Please e-mail any final comments about this proposal to address-policy-wg at ripe.net before 18 September 2006. If we receive no objections, we will publish the new policy after this date. Regards Filiz Yilmaz RIPE NCC Policy Development Officer From nick at inex.ie Mon Aug 21 17:05:57 2006 From: nick at inex.ie (Nick Hilliard) Date: Mon, 21 Aug 2006 16:05:57 +0100 Subject: [address-policy-wg] 2005-02 Last Call for Comments (IP Assignments for Anycasting DNS) In-Reply-To: <20060821145207.1CFE12F592@herring.ripe.net> References: <20060821145207.1CFE12F592@herring.ripe.net> Message-ID: <1156172757.97028.64.camel@pancake.netability.ie> > - The resulting policy text should explicitly state that it is for > ccTLDs and gTLDs Have ENUM country subdelegations been considered for inclusion in this category? Nick From filiz at ripe.net Wed Aug 23 14:24:14 2006 From: filiz at ripe.net (Filiz Yilmaz) Date: Wed, 23 Aug 2006 14:24:14 +0200 Subject: [address-policy-wg] 2006-04 New Policy Proposal (Contact e-mail Address Requirements) Message-ID: <20060823122414.447732F599@herring.ripe.net> PDP Number: 2006-04 Contact e-mail Address Requirements Dear Colleagues, A new RIPE Policy proposal has been made and is now available for discussion. 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. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2006-04.html We encourage you to review this proposal and send your comments to before 20 September 2006. Regards, Filiz Yilmaz RIPE NCC Policy Development Officer From gert at space.net Wed Aug 23 15:58:24 2006 From: gert at space.net (Gert Doering) Date: Wed, 23 Aug 2006 15:58:24 +0200 Subject: [address-policy-wg] Proposal for change to the IPv4 PI allocation policy In-Reply-To: <44E9E552.5050305@ukraine.su> References: <20060821124017.GD56407@f17.dmitry.net> <44E9E552.5050305@ukraine.su> Message-ID: <20060823135824.GX88409@Space.Net> Hi, On Mon, Aug 21, 2006 at 04:54:42PM +0000, Max Tulyev wrote: > Another good idea is to remove user scaring story about PI is worse > routeable than PA from RIPE documents. Well - that won't tell the truth. PI *is* worse to debug if some targets can't be reached (if only because you normally can't run traceroutes from inside customer PI networks). 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 president at ukraine.su Wed Aug 23 20:16:49 2006 From: president at ukraine.su (Max Tulyev) Date: Wed, 23 Aug 2006 18:16:49 +0000 Subject: [address-policy-wg] Proposal for change to the IPv4 PI allocation policy In-Reply-To: <20060823135824.GX88409@Space.Net> References: <20060821124017.GD56407@f17.dmitry.net> <44E9E552.5050305@ukraine.su> <20060823135824.GX88409@Space.Net> Message-ID: <44EC9B91.8020502@ukraine.su> Hi, Gert Doering wrote: > Hi, > > On Mon, Aug 21, 2006 at 04:54:42PM +0000, Max Tulyev wrote: >> Another good idea is to remove user scaring story about PI is worse >> routeable than PA from RIPE documents. > > Well - that won't tell the truth. > > PI *is* worse to debug if some targets can't be reached (if only because > you normally can't run traceroutes from inside customer PI networks). But what exactly (versus PA) is worse? Same ping and traceroute, same bgp debug, so on. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From gert at space.net Wed Aug 23 16:28:19 2006 From: gert at space.net (Gert Doering) Date: Wed, 23 Aug 2006 16:28:19 +0200 Subject: [address-policy-wg] Proposal for change to the IPv4 PI allocation policy In-Reply-To: <44EC9B91.8020502@ukraine.su> References: <20060821124017.GD56407@f17.dmitry.net> <44E9E552.5050305@ukraine.su> <20060823135824.GX88409@Space.Net> <44EC9B91.8020502@ukraine.su> Message-ID: <20060823142819.GB88409@Space.Net> Hi, On Wed, Aug 23, 2006 at 06:16:49PM +0000, Max Tulyev wrote: > > PI *is* worse to debug if some targets can't be reached (if only because > > you normally can't run traceroutes from inside customer PI networks). > > But what exactly (versus PA) is worse? Same ping and traceroute, same > bgp debug, so on. With PA, you can debug from *your* network - with customer's PI, you can't (normally) run probes (traceroute, ping) from *their* IP addresses - and if your PA works, but their PI is filtered, this makes it harder to debug. Furthermore, /24s tend to be damped more quickly and for longer times than /16... 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 garry at nethinks.com Wed Aug 23 17:58:33 2006 From: garry at nethinks.com (Garry Glendown) Date: Wed, 23 Aug 2006 17:58:33 +0200 Subject: [address-policy-wg] Proposal for change to the IPv4 PI allocation policy In-Reply-To: <44EC9B91.8020502@ukraine.su> References: <20060821124017.GD56407@f17.dmitry.net> <44E9E552.5050305@ukraine.su> <20060823135824.GX88409@Space.Net> <44EC9B91.8020502@ukraine.su> Message-ID: <44EC7B29.1040709@nethinks.com> Max Tulyev wrote: > Hi, > > Gert Doering wrote: >> Hi, >> >> On Mon, Aug 21, 2006 at 04:54:42PM +0000, Max Tulyev wrote: >>> Another good idea is to remove user scaring story about PI is worse >>> routeable than PA from RIPE documents. >> Well - that won't tell the truth. >> >> PI *is* worse to debug if some targets can't be reached (if only because >> you normally can't run traceroutes from inside customer PI networks). > > But what exactly (versus PA) is worse? Same ping and traceroute, same > bgp debug, so on. There is a possibility of people being tight on memory and filtering something like /24 or /23, and then not being able to reach or be reached by a /24 PI, because they also neglected to have a default route to their uplink ... Apart from that, I have not been informed of any problems with /24 or larger PI networks ... But then, RIPE policies would allow for (or even enforce) PI networks smaller than /24 to be assigned - which will most likely NOT be reachable from the Internet ... -gg From baess at denic.de Wed Aug 23 20:12:40 2006 From: baess at denic.de (Andreas =?ISO-8859-1?Q?B=E4=DF=2FDenic?=) Date: Wed, 23 Aug 2006 20:12:40 +0200 Subject: [address-policy-wg] 2005-02 Last Call for Comments (IP Assignments for Anycasting DNS) In-Reply-To: <1156172757.97028.64.camel@pancake.netability.ie> Message-ID: Dear Nick, > > - The resulting policy text should explicitly state that it is for > > ccTLDs and gTLDs > > Have ENUM country subdelegations been considered for inclusion in this > category? ENUM subdelegations have so far not been discussed to be eligible for this policy. I have no feelings if there are objections against adding ENUM subdelegations to the list. I prefer to bring the consensus of two year discusion into a policy now and start the discussion about adding ENUM subdelegations as soon as the policy has passed. As the deployment of ENUM grows it should be no problem to reach consensus to assign anycast resources to ENUM subdelegations as well. This can be very important for those who will not, or cannot share anycast resources between domains. I hope this approach is okay with you Andreas From md at Linux.IT Wed Aug 23 15:17:50 2006 From: md at Linux.IT (Marco d'Itri) Date: Wed, 23 Aug 2006 15:17:50 +0200 Subject: [address-policy-wg] [jeffc@surbl.org: Re: RIPE policy proposal on contact e-mail addresses] Message-ID: <20060823131750.GA10096@wonderland.linux.it> ----- Forwarded message from Jeff Chan ----- From: Jeff Chan Reply-To: Jeff Chan Organization: SURBL To: Marco d'Itri Subject: Re: RIPE policy proposal on contact e-mail addresses Wednesday, August 23, 2006, 5:41:25 AM, Marco d'Itri wrote: > Summary of Proposal: > 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. > http://ripe.net/ripe/policies/proposals/2006-04.html > If you want to argue for or against it please post to the address-policy > WG mailing list. Hello Marco, I don't have access to that list so could you relay my comments that current and accurate contact info should be required and that lack thereof should be possible grounds for de-allocation, depeering, disconnection, etc. Many of the most abusive spam gangs use completely fraudulent and broken contact info. Jeff C. -- Jeff Chan mailto:jeffc at surbl.org http://www.surbl.org/ ----- End forwarded message ----- -- ciao, Marco From nick at inex.ie Wed Aug 23 22:28:37 2006 From: nick at inex.ie (Nick Hilliard) Date: Wed, 23 Aug 2006 21:28:37 +0100 Subject: [address-policy-wg] 2005-02 Last Call for Comments (IP Assignments for Anycasting DNS) In-Reply-To: References: Message-ID: <1156364917.62901.1.camel@crumpet.netability.ie> > I have no feelings if there are objections against adding ENUM > subdelegations to the list. I prefer to bring the consensus of two year > discusion into a policy now and start the discussion about adding ENUM > subdelegations as soon as the policy has passed. I think that this is probably the best way to deal with the issue. ENUM deployment is not widespread right now, and there seems no reason to delay the implementation of 2005-02 on this basis. But it may need to be addressed in a future policy amendment proposal. Nick From andy at nosignal.org Wed Aug 23 22:34:10 2006 From: andy at nosignal.org (Andy Davidson) Date: Wed, 23 Aug 2006 21:34:10 +0100 Subject: [address-policy-wg] 2006-04 New Policy Proposal (Contact e-mail Address Requirements) In-Reply-To: <20060823122414.447732F599@herring.ripe.net> References: <20060823122414.447732F599@herring.ripe.net> Message-ID: On 23 Aug 2006, at 13:24, Filiz Yilmaz wrote: > A new RIPE Policy proposal has been made and is now available for > discussion. > 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 well intentioned proposal, I support the spirit of it. I do recommend that we clarify what a 'working' email address is (e.g. state that the mailbox should also be manned, by someone who can read at least the local language). I also think that 4.0's modification should encourage an ISP to make best efforts to limit all network abuse, not just 'abusive messages'. The rationale 'b' doesn't seem to be complete, the document seems to be truncated at 'which implies "correct documentation'. I also think we should offer for debate, an amendment that LIRs should man a mailbox at an address which might be known by only ripe and the LIR. This could, in an efficient organisation, be a 'fasttrack' escalation mailbox that solves the issues described in Rationale A of the proposal. Andy (AJBD-RIPE) From president at ukraine.su Wed Aug 23 22:05:29 2006 From: president at ukraine.su (Max Tulyev) Date: Thu, 24 Aug 2006 00:05:29 +0400 Subject: [address-policy-wg] Proposal for change to the IPv4 PI allocation policy In-Reply-To: <44EC7B29.1040709@nethinks.com> References: <20060821124017.GD56407@f17.dmitry.net> <44E9E552.5050305@ukraine.su> <20060823135824.GX88409@Space.Net> <44EC9B91.8020502@ukraine.su> <44EC7B29.1040709@nethinks.com> Message-ID: <44ECB509.3060909@ukraine.su> Garry Glendown wrote > There is a possibility of people being tight on memory and filtering > something like /24 or /23, and then not being able to reach or be > reached by a /24 PI, because they also neglected to have a default route > to their uplink ... Apart from that, I have not been informed of any > problems with /24 or larger PI networks ... > I got near hundred of PIs for my clients at almost all RIPE region, and never hear about any problems with reachability. So it is just scare tale in fact ;) > But then, RIPE policies would allow for (or even enforce) PI networks > smaller than /24 to be assigned - which will most likely NOT be > reachable from the Internet ... > It is very simple: don't ask PI smaller /24 if you want to announce it worldwide. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From michele at mneylon.com Wed Aug 23 14:32:24 2006 From: michele at mneylon.com (Michele) Date: Wed, 23 Aug 2006 13:32:24 +0100 Subject: [address-policy-wg] RE: [policy-announce] 2006-04 New Policy Proposal (Contact e-mail Address Requirements) In-Reply-To: <20060823122414.447732F599@herring.ripe.net> Message-ID: <01a601c6c6b0$3034d3b0$88c5c657@arthur> One question I have about this: "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." Several ISPs maintain abuse email addresses, but when you submit abuse reports to the supplied address they send an auto-responder forcing you to resubmit the data via a web form. What is the RIPE policy on this? Surely ISPs should not be making it hard for users / admins etc., to report abuse to them Regards Michele Michele http://www.mneylon.com/blog/ http://www.searchenginecookbook.com/ http://www.irishblogs.info - top Irish blogs/bloggers From jscribner at asienterprises.com Wed Aug 23 15:07:48 2006 From: jscribner at asienterprises.com (Jeff Scribner) Date: Wed, 23 Aug 2006 09:07:48 -0400 Subject: [address-policy-wg] Re: [policy-announce] 2006-04 New Policy Proposal (Contact e-mail Address Requirements) Message-ID: <001a01c6c6b5$2367e730$6401a8c0@PC236745275100> Michele, The proposal as written should cover this. The requirement is for a working e-mail address that will accept messages - not one that will direct you to a web site. Regards, Jeff From: Michele To: filiz at ripe.net ; address-policy-wg at ripe.net Cc: 'Jeffrey L. Scribner' ; 'Hans Petter Holen' Sent: Wednesday, August 23, 2006 08:32 Subject: RE: [policy-announce] 2006-04 New Policy Proposal (Contact e-mail Address Requirements) One question I have about this: "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." Several ISPs maintain abuse email addresses, but when you submit abuse reports to the supplied address they send an auto-responder forcing you to resubmit the data via a web form. What is the RIPE policy on this? Surely ISPs should not be making it hard for users / admins etc., to report abuse to them Regards Michele Michele http://www.mneylon.com/blog/ http://www.searchenginecookbook.com/ http://www.irishblogs.info - top Irish blogs/bloggers -------------- next part -------------- An HTML attachment was scrubbed... URL: From eh at solnet.ch Thu Aug 24 09:01:07 2006 From: eh at solnet.ch (Erich Hohermuth) Date: Thu, 24 Aug 2006 09:01:07 +0200 Subject: [address-policy-wg] RE: [policy-announce] 2006-04 New Policy Proposal (Contact e-mail Address Requirements) In-Reply-To: <01a601c6c6b0$3034d3b0$88c5c657@arthur> References: <01a601c6c6b0$3034d3b0$88c5c657@arthur> Message-ID: <1156402867.13293.12.camel@localhost.localdomain> Hi, > Several ISPs maintain abuse email addresses, but when you submit abuse > reports to the supplied address they send an auto-responder forcing you to > resubmit the data via a web form. This is the reaction to all this stupid auto complain tools which sends you a mail on every packet their IDS reports. Sometimes over 100 to the same incident. The other thing is you get allot of mails which doesn't include any useful information like header, source or destination ip address etc. I also want to mention the copyright infringements mails which are also abuse the system. > Surely ISPs should not be making it hard for users / admins etc., to report > abuse to them True, but you need also a policy for the admins ;-) Erich -- * Erich Hohermuth IP Engineer - SolNet (AS 9044) PGPKEY-46A08FCB * * phone: +41 32 686 8220 / sip:9044*463 at inoc-dba.pch.net * From president at ukraine.su Thu Aug 24 13:50:03 2006 From: president at ukraine.su (Max Tulyev) Date: Thu, 24 Aug 2006 11:50:03 +0000 Subject: [address-policy-wg] RE: [policy-announce] 2006-04 New Policy Proposal (Contact e-mail Address Requirements) In-Reply-To: <01a601c6c6b0$3034d3b0$88c5c657@arthur> References: <01a601c6c6b0$3034d3b0$88c5c657@arthur> Message-ID: <44ED926B.3000201@ukraine.su> Michele wrote: > "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." > > Several ISPs maintain abuse email addresses, but when you submit abuse > reports to the supplied address they send an auto-responder forcing you to > resubmit the data via a web form. > > What is the RIPE policy on this? Do you really not tied of reading tons of spam (yes, super wise guys send spam right to abuse@! It is cool! ;) )? So sometime it is only way to be sure it is a human is sending that e-mail... I think we should see not on the form, but on the reaction for the abuse report. Also I think it is good idea to periodically check other contacts (fax, phone) provided in RIPE objects, as well as adding "pager:" contact information (ICQ,AIM,JABBER,etc). -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From Karsten.Koepp at lambdanet.net Thu Aug 24 10:30:21 2006 From: Karsten.Koepp at lambdanet.net (Koepp, Karsten) Date: Thu, 24 Aug 2006 10:30:21 +0200 Subject: [address-policy-wg] RE: [policy-announce] 2006-04 New Policy Proposal (Contact e-mail Address Requirements) Message-ID: <39F27E3F569FD4119EF200508BAF85B9079B94EB@CCGNT30> Hi Michele, I also support the goal of the proposal although I believe it will be hard to enforce. > Several ISPs maintain abuse email addresses, but when you submit abuse > reports to the supplied address they send an auto-responder > forcing you to > resubmit the data via a web form. > Think the other way around. 99% of your abuse inbox is spam itself. And people just forward spam to abuse contacts to complain. How can you make sure serious mails are being detected within the junk. A web form is just a measure to make sure abuse complaints reach people and are being dealt with. It is not overdemanded to fill in a form if you ask someone to spend working time solving your problem. YMMV. regards Karsten > What is the RIPE policy on this? > > Surely ISPs should not be making it hard for users / admins > etc., to report > abuse to them > > Regards > > Michele > > > Michele > http://www.mneylon.com/blog/ > http://www.searchenginecookbook.com/ > http://www.irishblogs.info - top Irish blogs/bloggers > From michele at mneylon.com Fri Aug 25 01:50:19 2006 From: michele at mneylon.com (Michele Neylon) Date: Fri, 25 Aug 2006 00:50:19 +0100 Subject: [address-policy-wg] Re: [policy-announce] 2006-04 New Policy Proposal (Contact e-mail Address Requirements) In-Reply-To: <001a01c6c6b5$2367e730$6401a8c0@PC236745275100> References: <001a01c6c6b5$2367e730$6401a8c0@PC236745275100> Message-ID: <44EE3B3B.1070006@mneylon.com> Jeff Scribner wrote: > Michele, > > The proposal as written should cover this. The requirement is for a > working e-mail address that will accept messages - not one that will > direct you to a web site. > > Regards, > > Jeff > > Jeff that's fair enough, but what if the Ripe member ignores the policy? Is there any recourse? Michele -- http://www.mneylon.com/blog http://www.irishwebmasterforum.com/ http://www.armchair.ie/ From jscribner at asienterprises.com Fri Aug 25 02:42:40 2006 From: jscribner at asienterprises.com (Jeff Scribner) Date: Thu, 24 Aug 2006 20:42:40 -0400 Subject: [address-policy-wg] Re: [policy-announce] 2006-04 New Policy Proposal (Contact e-mail Address Requirements) Message-ID: <01c001c6c7df$6053b1d0$6401a8c0@PC236745275100> Michele, The original proposal provided for enforcement. That part was removed because it crosses into another area of responsibility. However, if the proposal is adopted and then violated, another proposal could be made providing for enforcement. At least that is my understanding of the situation. You might note that I made this proposal because our security department was running into e-mail addresses that didn't work, were missing or directed one to a web site. All of these results dramatically increase the time required to report abuse of an IP address. If the proposal is adopted, I think there will be a lot of people and organizations interested in enforcement. Regards, Jeff ----- Original Message ----- From: Michele Neylon To: Jeff Scribner Cc: hph at oslo.net ; Filiz Yilmaz ; address-policy-wg at ripe.net Sent: Thursday, August 24, 2006 19:50 Subject: Re: [policy-announce] 2006-04 New Policy Proposal (Contact e-mail Address Requirements) Jeff Scribner wrote: > Michele, > > The proposal as written should cover this. The requirement is for a > working e-mail address that will accept messages - not one that will > direct you to a web site. > > Regards, > > Jeff > > Jeff that's fair enough, but what if the Ripe member ignores the policy? Is there any recourse? Michele -- http://www.mneylon.com/blog http://www.irishwebmasterforum.com/ http://www.armchair.ie/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From michele at mneylon.com Fri Aug 25 02:51:16 2006 From: michele at mneylon.com (Michele Neylon) Date: Fri, 25 Aug 2006 01:51:16 +0100 Subject: [address-policy-wg] Re: [policy-announce] 2006-04 New Policy Proposal (Contact e-mail Address Requirements) In-Reply-To: <01c001c6c7df$6053b1d0$6401a8c0@PC236745275100> References: <01c001c6c7df$6053b1d0$6401a8c0@PC236745275100> Message-ID: <44EE4984.8060709@mneylon.com> Jeff Scribner wrote: > Michele, > > The original proposal provided for enforcement. That part was removed > because it crosses into another area of responsibility. However, if the > proposal is adopted and then violated, another proposal could be made > providing for enforcement. At least that is my understanding of the > situation. > > You might note that I made this proposal because our security department > was running into e-mail addresses that didn't work, were missing or > directed one to a web site. All of these results dramatically increase > the time required to report abuse of an IP address. If the proposal is > adopted, I think there will be a lot of people and organizations > interested in enforcement. > > Regards, > > Jeff Jeff that sounds reasonable. We've had a similar experience when trying to report abuse. Although I am subbed to this list from my personal address I am also one of the abuse contacts for a RIPE LIR :) A lack of response to an abuse report doesn't bother me, but bounces and web redirects are incredibly frustrating, especially when the web form is incomprehensible Thanks for the extra info Regards Michele -- http://www.mneylon.com/blog http://www.irishwebmasterforum.com/ http://www.armchair.ie/ From gert at space.net Mon Aug 28 17:19:53 2006 From: gert at space.net (Gert Doering) Date: Mon, 28 Aug 2006 17:19:53 +0200 Subject: [address-policy-wg] RE: [policy-announce] 2006-04 New Policy Proposal (Contact e-mail Address Requirements) In-Reply-To: <39F27E3F569FD4119EF200508BAF85B9079B94EB@CCGNT30> References: <39F27E3F569FD4119EF200508BAF85B9079B94EB@CCGNT30> Message-ID: <20060828151953.GU88409@Space.Net> Hi, On Thu, Aug 24, 2006 at 10:30:21AM +0200, Koepp, Karsten wrote: > It is not overdemanded to fill in a form if you ask > someone to spend working time solving your problem. I find it very annoying. Some ISP's users are misbehaving (e.g. because they have been hacked), I send the ISP a very detailed log file, and get back a "please fill in our (completely unsuitable for the job) web form!!" auto-response. I *do* see the other side - but just referring people to a web form, or (which is even worse) not handling abuse complaints at all can not be the right answer either. 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 president at ukraine.su Mon Aug 28 21:23:32 2006 From: president at ukraine.su (Max Tulyev) Date: Mon, 28 Aug 2006 19:23:32 +0000 Subject: [address-policy-wg] RE: [policy-announce] 2006-04 New Policy Proposal (Contact e-mail Address Requirements) In-Reply-To: <20060828151953.GU88409@Space.Net> References: <39F27E3F569FD4119EF200508BAF85B9079B94EB@CCGNT30> <20060828151953.GU88409@Space.Net> Message-ID: <44F342B4.6000102@ukraine.su> Hi, In case system is hacked you can't send mail with same probability as fill web form ;) May be you can - may be you can't. So please do phone call on case of real emergency. Gert Doering wrote: > Hi, > > On Thu, Aug 24, 2006 at 10:30:21AM +0200, Koepp, Karsten wrote: >> It is not overdemanded to fill in a form if you ask >> someone to spend working time solving your problem. > > I find it very annoying. > > Some ISP's users are misbehaving (e.g. because they have been hacked), > I send the ISP a very detailed log file, and get back a "please fill in > our (completely unsuitable for the job) web form!!" auto-response. > > I *do* see the other side - but just referring people to a web form, or > (which is even worse) not handling abuse complaints at all can not be the > right answer either. > > Gert Doering > -- NetMaster -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From president at ukraine.su Mon Aug 28 21:37:38 2006 From: president at ukraine.su (Max Tulyev) Date: Mon, 28 Aug 2006 19:37:38 +0000 Subject: [address-policy-wg] Proposal for change to the IPv4 PI allocation policy In-Reply-To: <20060828152444.GV88409@Space.Net> References: <20060821124017.GD56407@f17.dmitry.net> <44E9E552.5050305@ukraine.su> <20060823135824.GX88409@Space.Net> <44EC9B91.8020502@ukraine.su> <20060823142819.GB88409@Space.Net> <44ECB333.7070804@ukraine.su> <20060828152444.GV88409@Space.Net> Message-ID: <44F34602.6080002@ukraine.su> Hi, I warn all my clients that PI (and any kind of their own) address space and/or AS is also a great responsibility. And they sure need a more qualified system administrator to rule it. If client asks for a help ("the Internet doesn't work") and rejects in help with doing some tests from its side - I say I can't help you in that case, goodbye. It is true as well for PI as for PA. Gert Doering wrote: > Hi, > > On Wed, Aug 23, 2006 at 11:57:39PM +0400, Max Tulyev wrote: >> Gert Doering wrote: >>> With PA, you can debug from *your* network - with customer's PI, you >>> can't (normally) run probes (traceroute, ping) from *their* IP addresses >>> - and if your PA works, but their PI is filtered, this makes it harder >>> to debug. >> PI means that it is *not* your network administratively and technically. >> If customer have PI and AS - it is an independent part of Internet, and, >> in fact, not your just customer in usual terms. You don't go debug for >> example your downstream's and peer's networks as your, isn't it? > > You need to distinguish between "customers with their own network block, > their own AS number, BGP speaking routers, multiple upstreams, and local > clue" and "customers that want PI space because they don't want to > renumber when they change upstreams". > > The latter sort will want *you* to announce their PI for them, and if > there are any routing problems, yell at you because "the Internet doesn't > work". > > I have no issues with the former sort, especially when there is enough > local clue present. > >>> Furthermore, /24s tend to be damped more quickly and for longer times >>> than /16... >> Again, why? ;) > > Because flap dampening recommendations said so... > > Gert Doering > -- NetMaster -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From gert at space.net Mon Aug 28 17:53:01 2006 From: gert at space.net (Gert Doering) Date: Mon, 28 Aug 2006 17:53:01 +0200 Subject: [address-policy-wg] RE: [policy-announce] 2006-04 New Policy Proposal (Contact e-mail Address Requirements) In-Reply-To: <44F342B4.6000102@ukraine.su> References: <39F27E3F569FD4119EF200508BAF85B9079B94EB@CCGNT30> <20060828151953.GU88409@Space.Net> <44F342B4.6000102@ukraine.su> Message-ID: <20060828155301.GZ88409@Space.Net> Hi, On Mon, Aug 28, 2006 at 07:23:32PM +0000, Max Tulyev wrote: > In case system is hacked you can't send mail with same probability as > fill web form ;) May be you can - may be you can't. Typically the *end customers* get hacked, and I want to inform the *ISP*. Different point of contact (which is why the irt: object could be quite useful, if only more ISPs used it). Talking to the end customers of a different ISP is usually moot anyway ("Who are you? What are you talking about?"). 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 jwkckid1 at ix.netcom.com Tue Aug 29 07:44:28 2006 From: jwkckid1 at ix.netcom.com (Jeff Williams) Date: Mon, 28 Aug 2006 22:44:28 -0700 Subject: [address-policy-wg] RE: [policy-announce] 2006-04 New Policy Proposal (Contact e-mail Address Requirements) References: <39F27E3F569FD4119EF200508BAF85B9079B94EB@CCGNT30> <20060828151953.GU88409@Space.Net> Message-ID: <44F3D43C.1CF84AFA@ix.netcom.com> Gert and all, Such is alse very typical of RIR's and LIR's. Gert Doering wrote: > Hi, > > On Thu, Aug 24, 2006 at 10:30:21AM +0200, Koepp, Karsten wrote: > > It is not overdemanded to fill in a form if you ask > > someone to spend working time solving your problem. > > I find it very annoying. > > Some ISP's users are misbehaving (e.g. because they have been hacked), > I send the ISP a very detailed log file, and get back a "please fill in > our (completely unsuitable for the job) web form!!" auto-response. > > I *do* see the other side - but just referring people to a web form, or > (which is even worse) not handling abuse complaints at all can not be the > right answer either. > > 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 Regards, -- Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!) "Obediance of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1 at ix.netcom.com Registered Email addr with the USPS Contact Number: 214-244-4827 From filiz at ripe.net Tue Aug 29 10:25:15 2006 From: filiz at ripe.net (Filiz Yilmaz) Date: Tue, 29 Aug 2006 10:25:15 +0200 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) Message-ID: <20060829082515.EA0922F592@herring.ripe.net> 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. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-05.html We encourage you to review this proposal and send your comments to before 26 September 2006. Regards, Filiz Yilmaz RIPE NCC Policy Development Officer From swmike at swm.pp.se Tue Aug 29 10:45:40 2006 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 29 Aug 2006 10:45:40 +0200 (CEST) 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: On Tue, 29 Aug 2006, Filiz Yilmaz wrote: > 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. > > http://www.ripe.net/ripe/policies/proposals/2006-05.html > > We encourage you to review this proposal and send your comments to > before 26 September 2006. Hello. This proposal is proposing the same things I was arguing in my email, so I second this. I have a question though, the proposal includes the notion of "major issue", perhaps this could be specified a bit more? Or is it clear how this would be interpreted by a hostmaster processing an application, that if the customer adds "I need to advertise this on the public internet" it will automatically be known that a at least a /24 is needed? -- Mikael Abrahamsson email: swmike at swm.pp.se From slz at baycix.de Tue Aug 29 10:58:38 2006 From: slz at baycix.de (Sascha Lenz) Date: Tue, 29 Aug 2006 10:58:38 +0200 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: References: <20060829082515.EA0922F592@herring.ripe.net> Message-ID: <44F401BE.9030600@baycix.de> Hi, Mikael Abrahamsson wrote: > On Tue, 29 Aug 2006, Filiz Yilmaz wrote: > >> 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. >> >> http://www.ripe.net/ripe/policies/proposals/2006-05.html >> >> We encourage you to review this proposal and send your comments to >> before 26 September 2006. > > Hello. This proposal is proposing the same things I was arguing in my > email, so I second this. > > I have a question though, the proposal includes the notion of "major > issue", perhaps this could be specified a bit more? Or is it clear how > this would be interpreted by a hostmaster processing an application, > that if the customer adds "I need to advertise this on the public > internet" it will automatically be known that a at least a /24 is needed? i think it's better to be that unspecific then to put in too tight wording - it's a policy, it needs months to be changed again later. Hostmasters at RIPE usually have a fair amount of wisdom :-) As stated earlier, I have no problems with wasting IPv4 address space anymore (there is IPv6, and most projections suggest, there's enough IPv4 space for decades to come, too) - so no problems with the change. Although one should think about what happens if /24 gets "not routable" due to the upcoming next round of memory restrains in BGP routers. Is it /23 then as next minimum? I didn't really get any comments on this a week ago on the discussion leading to this proposal, so i assume, it's not an issue to think about right now for most people? . 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..) -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From eh at solnet.ch Tue Aug 29 11:02:27 2006 From: eh at solnet.ch (Erich Hohermuth) Date: Tue, 29 Aug 2006 11:02:27 +0200 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: References: <20060829082515.EA0922F592@herring.ripe.net> Message-ID: <1156842147.20677.43.camel@localhost.localdomain> Hi > > http://www.ripe.net/ripe/policies/proposals/2006-05.html > > > > We encourage you to review this proposal and send your comments to > > before 26 September 2006. The proposal make sense but we have to look deeper into the problem of increase the prefixes. If someone ask for multihoming with PI Space, it makes sense that we assign a size which will work with the current filtering policies. But maybe we have to change the policy about PI Space in general ? The question is, which "problems" do we rate as a higher risk; waste of ip space, amount of prefixes, reach ability of a subnet. What do you think ? Regards Erich -- * Erich Hohermuth IP Engineer - SolNet (AS 9044) PGPKEY-46A08FCB * * phone: +41 32 686 8220 / sip:9044*463 at inoc-dba.pch.net * From swmike at swm.pp.se Tue Aug 29 11:20:39 2006 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Tue, 29 Aug 2006 11:20:39 +0200 (CEST) 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: On Tue, 29 Aug 2006, Sascha Lenz wrote: > Although one should think about what happens if /24 gets "not routable" > due to the upcoming next round of memory restrains in BGP routers. > Is it /23 then as next minimum? Well, the larger ISPs use routers that can handle more than 240k routes, and as long as they carry the routes, if smaller ISPs filter they will soon see a loss of customers due to this. I also forsee these smaller ISPs getting a default-route as well from their upstreams to handle their inability to handle all routes. > I didn't really get any comments on this a week ago on the discussion > leading to this proposal, so i assume, it's not an issue to think about > right now for most people? Well, IPv6 solves the addressing issue but it does nothing for the routing issue. Multihoming in IPv6 is still an issue being debated due to exact same reasons you mention. > . 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..) Probably because the solution is a radical change from how things are done today and people are quite hesitant to commit to a paradigm shift, especially since the "throw faster hardware at the problem" has worked so far? It would of course be interesting to send the proposal to groups like NANOG and see their reaction, as there are quite a lot of more routing people there that cares less for addressing. -- Mikael Abrahamsson email: swmike at swm.pp.se From dmitry at volia.net Tue Aug 29 11:39:25 2006 From: dmitry at volia.net (Dmitry Kiselev) Date: Tue, 29 Aug 2006 12:39:25 +0300 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <1156842147.20677.43.camel@localhost.localdomain> References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> Message-ID: <20060829093925.GT56407@f17.dmitry.net> On Tue, Aug 29, 2006 at 11:02:27AM +0200, Erich Hohermuth wrote: > > > http://www.ripe.net/ripe/policies/proposals/2006-05.html > > > > > > We encourage you to review this proposal and send your comments to > > > before 26 September 2006. > > The proposal make sense but we have to look deeper into the problem of > increase the prefixes. If someone ask for multihoming with PI Space, it > makes sense that we assign a size which will work with the current > filtering policies. But maybe we have to change the policy about PI > Space in general ? The question is, which "problems" do we rate as a > higher risk; waste of ip space, amount of prefixes, reach ability of a > subnet. What do you think ? On my practice multihoming PI users ask one more prefix each time the previous one exhausted. Its coused by difficults while receiving one large enough PI subnet. Instead of becoming LIR and have no problems with PA, such users save money and got a couple of small PIs for a space solution... Yeah, here, in xUSSR, it is common practice. :( As IPv4 PI qustion rised again, in my opinion, we have think about reasonable and clear limits for maximum PI assignment size to reduce described above problem and coused routing table impact. -- Dmitry Kiselev From Michael.Dillon at btradianz.com Tue Aug 29 12:12:53 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 29 Aug 2006 11:12:53 +0100 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: Message-ID: > I have a question though, the proposal includes the notion of "major > issue", perhaps this could be specified a bit more? Or is it clear how > this would be interpreted by a hostmaster processing an application, that > if the customer adds "I need to advertise this on the public internet" it > will automatically be known that a at least a /24 is needed? If the organization is simultaneously applying for an AS number or the organization already has an AS number, then we should consider routing to be a major issue if the organization says that it is. After all, the only purpose of having an AS number is to do routing. --Michael Dillon From Michael.Dillon at btradianz.com Tue Aug 29 12:17:31 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 29 Aug 2006 11:17:31 +0100 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: Message-ID: > Well, IPv6 solves the addressing issue but it does nothing for the routing > issue. Multihoming in IPv6 is still an issue being debated due to exact > same reasons you mention. IPv6 allows organizations to REDUCE the number of prefixes that they announce in the global routing table. Most ISPs will only announce one single /32 route in IPv6. This makes a big difference. The debate you refer to is whether or not someone can invent a newer and better way of handling routing in IPv6. Even if they never succeed at this, the same old BGP4 multihoming continues to work with less routes in the IPv6 global routing table than in the IPv4 global routing table. --Michael Dillon From garry at nethinks.com Tue Aug 29 12:43:22 2006 From: garry at nethinks.com (Garry Glendown) Date: Tue, 29 Aug 2006 12:43:22 +0200 Subject: [address-policy-wg] 2006-05 New Policy Proposal (PI Assignment Size) In-Reply-To: <20060829093925.GT56407@f17.dmitry.net> References: <20060829082515.EA0922F592@herring.ripe.net> <1156842147.20677.43.camel@localhost.localdomain> <20060829093925.GT56407@f17.dmitry.net> Message-ID: <44F41A4A.6050907@nethinks.com> I also support this proposal. Being at the "receiving end" of an ISP, we've seen customer requirements often enough - many times we have been able to redirect the customer wishes towards regular PA space (which of course we'd rather assign, as it keeps customer "in line" more than PI), but larger places often have gone through IP renumbering before (sometimes when switching to us), so they know the cost involved. The prospect of e.g. shelling out the time & money for renumbering again is not very appealing. Of course, those bigger places often require more than a /24, so the issue of non-routable PIs doesn't necessarily apply. Anyway, there are situations where the number of IPs involved is smaller, but the implications are a lot bigger - best example is the current PI I had been asked to request - while the usage is somewhere in the 90 area (totalling in at or around /25+/26 given the network structure and organization), RIPE proposed assigning a /26+/27 which is (of course) useless. While the number of currently used IPs would not necessarily warant a /24 due to rather low work changing THOSE IPs, they are currently in the first roll-out phase of POS terminals - boxes, which have the destination for their communication hard-coded in Flash. Of course chaging one is possible, but imagine doing that on several tenthousands of the boxes at some point ... you will understand that the cost involved is not paid from pocket change ... my mistake was not artificially blowing up the requirements in order to end up in the 230-250 IPs range but attaching a correct, real IP plan ... :( Dmitry Kiselev wrote: > On my practice multihoming PI users ask one more prefix each time > the previous one exhausted. Its coused by difficults while receiving > one large enough PI subnet. Instead of becoming LIR and have no > problems with PA, such users save money and got a couple of small > PIs for a space solution... Yeah, here, in xUSSR, it is common > practice. :( 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? The main reason is not being dependent of a single provider, being able to switch providers when technically necessary without a sh at tload of problems and quite non-trivial cost issues afterwards due to changes in IP addresses ... being an LIR is pointless for non-ISPs or SMBs (and most likely for large ones, too). Erich Hohermuth wrote: > increase the prefixes. If someone ask for multihoming with PI Space, it > makes sense that we assign a size which will work with the current > filtering policies. But maybe we have to change the policy about PI > Space in general ? The question is, which "problems" do we rate as a > higher risk; waste of ip space, amount of prefixes, reach ability of a > subnet. What do you think ? Multihoming as such I don't see as the core reason for PI space - assigning PA space by two providers isn't a problem, less so than announcing the same size PI prefix, as there should always be a less-specific /19 or bigger to fall back to ... If the amount of prefixes were a reason, shouldn't ISPs be (en)forced to aggregate their announcements? Looking at e.g. the peering tables I get at DECIX or via our uplinks, I see hundreds and thousands of subnets announced by providers from their own PA space, broken down into _many_ subnets, additionally to the aggregated prefix. And I don't think all (or even a mentionable percentage of) those customers are multi-homed and therefore require the smaller announcement be made due to more-specific routing ... at that point, possibly 25% of the routing tables could be saved ... 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? Please correct me if I got this wrong, but at the moment, PI networks count towards the LIR's rating. 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. By defining a rate of ?X per /24 would one on hand reduce the requested size of the requests, and also make users think twice about requesting technically unnecessary PI space ... Michael.Dillon at btradianz.com wrote: > If the organization is simultaneously applying for an AS > number or the organization already has an AS number, then > we should consider routing to be a major issue if the > organization says that it is. After all, the only purpose > of having an AS number is to do routing. Indeed. Still, an AS should not be a prerequisite though, as using an PI could be the first part of setting up "advanced routing". Regards, -garry From henk at ripe.net Tue Aug 29 12:49:10 2006 From: henk at ripe.net (Henk Uijterwaal) Date: Tue, 29 Aug 2006 12:49:10 +0200 Subject: [address-policy-wg] Fwd: Last Call: 'BGP Support for Four-octet AS Number Space' to Proposed Standard (draft-ietf-idr-as4bytes) Message-ID: <7.0.1.0.2.20060829124840.03504278@ripe.net> For those interested in PDP 2005-12... >Begin forwarded message: > >>From: The IESG >>Date: August 28, 2006 10:01:15 PM GMT+02:00 >>To: IETF-Announce >>Cc: idr at ietf.org >>Subject: Last Call: 'BGP Support for Four-octet AS Number Space' >>to Proposed Standard (draft-ietf-idr-as4bytes) >>Reply-To: iesg at ietf.org >> >>The IESG has received a request from the Inter-Domain Routing WG to >>consider the following document: >> >>- 'BGP Support for Four-octet AS Number Space ' >> as a Proposed Standard >> >>The IESG plans to make a decision in the next few weeks, and solicits >>final comments on this action. Please send any comments to the >>iesg at ietf.org or ietf at ietf.org mailing lists by 2006-09-12. >> >>The file can be obtained via >>http://www.ietf.org/internet-drafts/draft-ietf-idr-as4bytes-12.txt >> >>The implementation report can be obtained via >>http://www.ietf.org/IESG/Implementations/bgp4_impleme.txt >> >> >>_______________________________________________ >>IETF-Announce mailing list >>IETF-Announce at ietf.org >>https://www1.ietf.org/mailman/listinfo/ietf-announce > >----------------------------------------------------------- >Olaf M. Kolkman >NLnet Labs >http://www.nlnetlabs.nl/ > > ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ 1160438400 + 381600 = 1160820000. From david.kessens at nokia.com Thu Aug 31 05:04:24 2006 From: david.kessens at nokia.com (David Kessens) Date: Wed, 30 Aug 2006 20:04:24 -0700 Subject: [address-policy-wg] [info@arin.net: [arin-announce] NRPM version 2006.2 - New Policy Implementations] Message-ID: <20060831030424.GA30987@nokia.com> For your information. Please post followups regarding these policy changes to the address policy working group only. David Kessens --- ----- Forwarded message from Member Services ----- Delivered-To: arin-announce at lists.arin.net From: Member Services To: ARIN Announce , "'Public Policy Mailing List'" Date: Wed, 30 Aug 2006 19:22:07 -0400 Subject: [arin-announce] NRPM version 2006.2 - New Policy Implementations Reply-To: info at arin.net On 9 May 2006, the ARIN Board of Trustees, based on the recommendation of the Advisory Council and noting that the Internet Resource Policy Evaluation Process had been followed, adopted the following policy proposals: 2005-1: Provider-independent IPv6 Assignments for End Sites 2005-8: Proposal to amend ARIN IPv6 assignment and utilisation requirement 2005-9: 4-Byte AS Number These policy proposals have been incorporated into version 2006.2 of the ARIN Number Resource Policy Manual (NRPM) which is effective 30 August 2006. NRPM version 2006.2 supersedes previous versions. See Appendix A of the NRPM for information regarding changes to the manual. The NRPM can be found at: http://www.arin.net/policy/nrpm.html Appendix A can be found at: http://www.arin.net/policy/nrpm_changelog.html On 11 July 2006, the ARIN Board of Trustees added IPv6 Assignments to the ARIN fee schedule. The Board waived all but $500 of the IPv6 Initial Assignment fee through 31 December 2007. The fee schedule can be found at: http://www.arin.net/billing/fee_schedule.html For information about requesting an IPv6 assignment, please see the guidelines at: http://www.arin.net/registration/guidelines/ipv6_assignment.html Regards, Member Services American Registry for Internet Numbers (ARIN) _______________________________________________ ARIN-announce mailing list ARIN-announce at arin.net http://lists.arin.net/mailman/listinfo/arin-announce "To Unsubscribe,<mailto:arin-announce-request at arin.net?subject=unsubscribe>." ----- End forwarded message ----- From president at ukraine.su Thu Aug 31 13:26:41 2006 From: president at ukraine.su (Max Tulyev) Date: Thu, 31 Aug 2006 11:26:41 +0000 Subject: [address-policy-wg] Re: [ipv6-wg] [info@arin.net: [arin-announce] NRPM version 2006.2 - New Policy Implementations] In-Reply-To: <20060831030424.GA30987@nokia.com> References: <20060831030424.GA30987@nokia.com> Message-ID: <44F6C771.7000204@ukraine.su> David Kessens wrote: > 2005-1: Provider-independent IPv6 Assignments for End Sites YES!!! They really did it? -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From leo at ripe.net Thu Aug 31 10:52:45 2006 From: leo at ripe.net (leo vegoda) Date: Thu, 31 Aug 2006 10:52:45 +0200 Subject: [address-policy-wg] New IPv4 blocks allocated to RIPE NCC Message-ID: <5AF59DCD-983F-4C8C-8183-A3D30DDAF14D@ripe.net> [Apologies for duplicate mails] Dear Colleagues, The RIPE NCC received the IPv4 address ranges 77.0.0.0/8 and 78.0.0.0/7 from the IANA in August 2006. We will begin allocating from these ranges in the near future. The minimum allocation size for these four /8s has been set at /21. You may wish to adjust any filters you have in place accordingly. More information on the IP space administered by the RIPE NCC can be found on our web site at: https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html Additionally, please note that two "pilot" prefixes are being announced from each /8. Details of the prefixes, 'pingable' target names and addresses for each prefix can be found on our web site at: http://www.ris.ripe.net/debogon/debogon.html Best regards, -- leo vegoda Registration Services Manager RIPE NCC From leo at ripe.net Thu Aug 31 11:00:45 2006 From: leo at ripe.net (leo vegoda) Date: Thu, 31 Aug 2006 11:00:45 +0200 Subject: [address-policy-wg] Re: New IPv4 blocks allocated to RIPE NCC In-Reply-To: <5AF59DCD-983F-4C8C-8183-A3D30DDAF14D@ripe.net> References: <5AF59DCD-983F-4C8C-8183-A3D30DDAF14D@ripe.net> Message-ID: On 31 Aug 2006, at 10:52GMT+02:00, leo vegoda wrote: > [Apologies for duplicate mails] > > Dear Colleagues, > > The RIPE NCC received the IPv4 address ranges 77.0.0.0/8 and > 78.0.0.0/7 > from the IANA in August 2006. We will begin allocating from these > ranges > in the near future. > > The minimum allocation size for these four /8s has been set at /21. > You > may wish to adjust any filters you have in place accordingly. Typo. That's three /8s, not four. Sorry. -- leo vegoda Registration Services Manager RIPE NCC From Michael.Dillon at btradianz.com Thu Aug 31 11:16:24 2006 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 31 Aug 2006 10:16:24 +0100 Subject: [address-policy-wg] Re: [ipv6-wg] [info@arin.net: [arin-announce] NRPM version 2006.2 - New Policy Implementations] In-Reply-To: <44F6C771.7000204@ukraine.su> Message-ID: > > 2005-1: Provider-independent IPv6 Assignments for End Sites > They really did it? That's right. Look here for details: http://www.arin.net/policy/proposals/2005_1.html You can see that it took a while and it was discussed at many meetings. --Michael Dillon