From poty at iiat.ru Mon Jun 1 12:15:08 2009 From: poty at iiat.ru (poty at iiat.ru) Date: Mon, 1 Jun 2009 14:15:08 +0400 Subject: [address-policy-wg] RE: [policy-announce] 2009-06 New Policy Proposal (Removing Routing Requirements from the IPv6 Address Allocation Policy) Message-ID: > -----Original Message----- > From: Wilfried Woeber, UniVie/ACOnet [mailto:Woeber at CC.UniVie.ac.at] > Sent: Saturday, May 30, 2009 12:09 AM > To: Potapov Vladislav > Cc: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] RE: [policy-announce] 2009-06 New > Policy Proposal (Removing Routing Requirements from the IPv6 Address > Allocation Policy) > > Vladislav, > > I have to strongly disagree with your assertions. > > poty at iiat.ru wrote: > > > Nick, just because there is the word "private". > > Why should RIPE or some other organization (including mine) provide > the > > registration and supporting service (for example - uniqueness) for > PRIVATE > > networks? > > First of all, RIPE is the Community, the RIPE NCC is executing the > policies > and providing e.g. the Registration Services. > RIPE = RIPE NCC of course in my writings. Just to be more short. > Every organsiation obtaining services, e.g. an IP-Address Assignment or > an Allocation are contributing to offset the expenses; either directly > or by way of an existing LIR. What service do YOU mean? Could it be possible for me (just for prestige of my company) to obtain several class-A IPv4 blocks just paying for the RIPE NCC (now correctly written?) service? We are discriminating here not to waste the address space for that? Why we should be so happy to waste the space in the other way? I speak not about expenses, you know! > > If a company wants to use interconnection with other companies - > > it is their PRIVATE deal. And they should use their PRIVATE means for > > achieving that! > > The TCP/IP Technology (including the resources to uniquely identify the > individual components) are - and indeed should continue to be - > accessible > to the full community. Whether using this stuff on the "Internet" or > for > some other purpose is not a discriminating factor here. I fully agree with that! But companies, not involved in the communication with other parties, called the Internet, should create their own uniqueness for themselves. Why it should be achieved by help of irrelevant (read - the Internet) party? > PS: we have already seen the disadvantage of liberally applying > RFC1918, > i.e. non-unique, addressing in organisations that eventually were > (forced > to) connecting to other organisations.... Sometimes it IS disadvantage, sometimes - not. It is really depends on the point of view. I think RFC 1918 prolonged the life of v4 space and it IS an advantage. And problems... Problems were, is and will be... It shouldn't be use as an argument. Vladislav Potapov Ru.iiat From poty at iiat.ru Mon Jun 1 12:17:13 2009 From: poty at iiat.ru (poty at iiat.ru) Date: Mon, 1 Jun 2009 14:17:13 +0400 Subject: [address-policy-wg] RE: Private address space in IPv4 and IPv6 [was something irrelevantly titled] Message-ID: Yes, Wilfried, interesting, but it seems that YOU are behind the reality, not mine. > -----Original Message----- > From: Wilfried Woeber, UniVie/ACOnet [mailto:Woeber at CC.UniVie.ac.at] > Sent: Saturday, May 30, 2009 12:51 AM > To: Potapov Vladislav > Cc: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] RE: Private address space in IPv4 and > IPv6 [was something irrelevantly titled] > > poty at iiat.ru wrote: > > > IPv4 exists most of it's time without RIR at all. So it's not prove > > anything. > > May I suggest that you read up on reality, in particular the period > of substantial growth and wide-spread penetration? > > > Other consideration is only philosophy, not policy. > > Interesting... > My feeling is that we should go back to real-life issues. > > Wilfried. From poty at iiat.ru Mon Jun 1 12:24:42 2009 From: poty at iiat.ru (poty at iiat.ru) Date: Mon, 1 Jun 2009 14:24:42 +0400 Subject: [address-policy-wg] RE: Private address space in IPv4 and IPv6 [was something irrelevantly titled] Message-ID: > -----Original Message----- > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- > admin at ripe.net] On Behalf Of Gert Doering > Sent: Saturday, May 30, 2009 4:00 PM > To: michael.dillon at bt.com > Cc: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] RE: Private address space in IPv4 and > IPv6 [was something irrelevantly titled] > > Hi, > > On Fri, May 29, 2009 at 11:03:16AM +0100, michael.dillon at bt.com wrote: > > A very large number of organizations depend on these > > internetworks, and they would not be terribly happy if > > ISPs would hijack the entire IP address space for their > > own profits. But I think that the RIR boards understand > > this and have no intention of changing the rules to > > reserve IP addresses only for the public Internet. > > Let me second that. > > This has always been my understanding on the principles that govern > the RIRs' operation - "provide unique numbers to the people that need > unique numbers". Be it IPv4, IPv6 or ASes. No, because it has (providing the "numbers") the scope - the Internet, If I want to create my own network, not connected to the scope, I don't need to use any of rules of disconnected network. I'm surprised that you are not understanding and differentiating that. Maybe, following your thoughts, I could get the IP number for my pet? Just to be more "connected" to the network? > > Gert Doering > -- APWG chair > -- > Total number of prefixes smaller than registry allocations: 128645 > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner- > Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > Vladislav Potapov Ru.iiat From gert at space.net Mon Jun 1 12:32:05 2009 From: gert at space.net (Gert Doering) Date: Mon, 1 Jun 2009 12:32:05 +0200 Subject: [address-policy-wg] RE: Private address space in IPv4 and IPv6 [was something irrelevantly titled] In-Reply-To: References: Message-ID: <20090601103205.GC2776@Space.Net> Hi, On Mon, Jun 01, 2009 at 02:24:42PM +0400, poty at iiat.ru wrote: > > This has always been my understanding on the principles that govern > > the RIRs' operation - "provide unique numbers to the people that need > > unique numbers". Be it IPv4, IPv6 or ASes. > > No, because it has (providing the "numbers") the scope - the Internet, > If I want to create my own network, not connected to the scope, I don't > need to use any of rules of disconnected network. I'm surprised that you > are not understanding and differentiating that. To phrase this a bit more blunt: you're completely off-base. I was wording this in a polite way would have permitted you to step back without losing face. Before accusing people in this list that they have no clue or no understanding how this thing works, how the RIR system works, and so on - maybe you should actually try to do a bit of reading on how long some of these people have been actively working as part of the RIPE addressing community. > Maybe, following your thoughts, I could get the IP number for my pet? > Just to be more "connected" to the network? If your pet has an IP connection, and you can make a good point that it's very likely that your pet will be connected to other pets *using IP networks*, the point could be argued that this is a valid usage of IP resources. If your pet is not using IP networking technology, it doesn't need IP addresses. (This was my last e-mail on this topic, and I would kindly ask the other mailing list participants to refrain from answering this troll until he shows a bit more interesting in understanding reality). Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 128645 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 305 bytes Desc: not available URL: From poty at iiat.ru Mon Jun 1 12:36:33 2009 From: poty at iiat.ru (poty at iiat.ru) Date: Mon, 1 Jun 2009 14:36:33 +0400 Subject: [address-policy-wg] RE: Private address space in IPv4 and IPv6 [was something irrelevantly titled] Message-ID: > -----Original Message----- > From: Andy Davidson [mailto:andy at nosignal.org] > Sent: Sunday, May 31, 2009 10:55 AM > To: Potapov Vladislav > Cc: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] RE: Private address space in IPv4 and > IPv6 [was something irrelevantly titled] > > > On 29 May 2009, at 11:16, wrote: > > > Then Radianz could easily create its own rules without bothering the > > World, couldn't it? And so - use ANY IP addresses. Why should I see > > the > > internal networks (I use corrected "private" meanings) of Radianz or > > other such companys? If it is NEVER interact with my or the most of > > other networks in the Internet? > > Hi, Vladislav > > As others have tried to point out, private networks often still > connect to the Internet, so in order to prevent connectivity problems > between -- in this case, Radianz -- and another, unspecified network > on the Internet, then the addressing that Radianz need to use for > their private networks must be globally unique. Here we have several possibilities: 1. We have a tunnel between the internal networks - then Radianz network do not need to be GLOBALLY unique, it should be unique only between interconnected networks. 2. The same network should have access to the Internet. Then it should use NAT (not possibly in IPv6) or just be partially connected to the Internet. The second case - is announcing the block (or part of the block) to the Internet. The first case - internal network may have RFC 1918 or other IP addresses. > > Kind regards, > Andy Davidson Vladislav Potapov Ru.iiat From dmitry at volia.net Mon Jun 1 12:33:23 2009 From: dmitry at volia.net (Dmitry Kiselev) Date: Mon, 1 Jun 2009 13:33:23 +0300 Subject: [address-policy-wg] RE: [policy-announce] 2009-06 New Policy Proposal (Removing Routing Requirements from the IPv6 Address Allocation Policy) In-Reply-To: References: Message-ID: <20090601103323.GG1222@f17.dmitry.net> Hello! On Mon, Jun 01, 2009 at 02:15:08PM +0400, poty at iiat.ru wrote: > > > If a company wants to use interconnection with other companies - > > > it is their PRIVATE deal. And they should use their PRIVATE means > for > > > achieving that! > > > > The TCP/IP Technology (including the resources to uniquely identify > the > > individual components) are - and indeed should continue to be - > > accessible > > to the full community. Whether using this stuff on the "Internet" or > > for > > some other purpose is not a discriminating factor here. > I fully agree with that! But companies, not involved in the > communication with other parties, called the Internet, should create > their own uniqueness for themselves. Why it should be achieved by help > of irrelevant (read - the Internet) party? OK, but what they should do if one of them decide to come to Internet? Renumber a whole mesh to avoid duplicates? If I remember correctly, few years ago FastWeb went through silimar situation with their modem's address space. Why we should push some parties to this? -- Dmitry Kiselev From poty at iiat.ru Mon Jun 1 12:42:36 2009 From: poty at iiat.ru (poty at iiat.ru) Date: Mon, 1 Jun 2009 14:42:36 +0400 Subject: [address-policy-wg] RE: Private address space in IPv4 and IPv6 [was something irrelevantly titled] Message-ID: You lose your arguments? And just braving your "involvements". Ha-Ha! I'm with RIPE from 1997, and yearly attending RIPE's meeting, so I can't be called "not working as part of the RIPE addressing community". But it IS not argument and I'll never be so puffed up to use it as an argument. Vladislav Potapov Ru.iiat > -----Original Message----- > From: Gert Doering [mailto:gert at space.net] > Sent: Monday, June 01, 2009 2:32 PM > To: Potapov Vladislav > Cc: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] RE: Private address space in IPv4 and > IPv6 [was something irrelevantly titled] > > Hi, > > On Mon, Jun 01, 2009 at 02:24:42PM +0400, poty at iiat.ru wrote: > > > This has always been my understanding on the principles that govern > > > the RIRs' operation - "provide unique numbers to the people that > > > need unique numbers". Be it IPv4, IPv6 or ASes. > > > > No, because it has (providing the "numbers") the scope - the > Internet, > > If I want to create my own network, not connected to the scope, I > > don't need to use any of rules of disconnected network. I'm surprised > > that you are not understanding and differentiating that. > > To phrase this a bit more blunt: you're completely off-base. I was > wording this in a polite way would have permitted you to step back > without losing face. > > Before accusing people in this list that they have no clue or no > understanding how this thing works, how the RIR system works, and so on > - maybe you should actually try to do a bit of reading on how long some > of these people have been actively working as part of the RIPE > addressing community. > > > > Maybe, following your thoughts, I could get the IP number for my pet? > > Just to be more "connected" to the network? > > If your pet has an IP connection, and you can make a good point that > it's very likely that your pet will be connected to other pets *using > IP networks*, the point could be argued that this is a valid usage of > IP resources. > > If your pet is not using IP networking technology, it doesn't need IP > addresses. > > > (This was my last e-mail on this topic, and I would kindly ask the > other mailing list participants to refrain from answering this troll > until he shows a bit more interesting in understanding reality). > > Gert Doering > -- APWG chair > -- > Total number of prefixes smaller than registry allocations: 128645 > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner- > Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From poty at iiat.ru Mon Jun 1 12:48:08 2009 From: poty at iiat.ru (poty at iiat.ru) Date: Mon, 1 Jun 2009 14:48:08 +0400 Subject: [address-policy-wg] RE: [policy-announce] 2009-06 New Policy Proposal (Removing Routing Requirements from the IPv6 Address Allocation Policy) Message-ID: In IPv4 - NAT could help them. In IPv6 - thoroughly arranged network can do this. There is a goal in the RIPE NCC policy - not to waste the address space. If we want to live in terms of "probability" and "global charity" we could easily drop this matter at all! Vladislav Potapov Ru.iiat > -----Original Message----- > From: Dmitry Kiselev [mailto:dmitry at volia.net] > Sent: Monday, June 01, 2009 2:33 PM > To: Potapov Vladislav > Cc: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] RE: [policy-announce] 2009-06 New > Policy Proposal (Removing Routing Requirements from the IPv6 Address > Allocation Policy) > > Hello! > > On Mon, Jun 01, 2009 at 02:15:08PM +0400, poty at iiat.ru wrote: > > > > > If a company wants to use interconnection with other companies - > > > > it is their PRIVATE deal. And they should use their PRIVATE means > > for > > > > achieving that! > > > > > > The TCP/IP Technology (including the resources to uniquely identify > > the > > > individual components) are - and indeed should continue to be - > > > accessible > > > to the full community. Whether using this stuff on the "Internet" > or > > > for > > > some other purpose is not a discriminating factor here. > > I fully agree with that! But companies, not involved in the > > communication with other parties, called the Internet, should create > > their own uniqueness for themselves. Why it should be achieved by > help > > of irrelevant (read - the Internet) party? > > > OK, but what they should do if one of them decide to come to Internet? > Renumber a whole mesh to avoid duplicates? > > If I remember correctly, few years ago FastWeb went through silimar > situation > with their modem's address space. Why we should push some parties to > this? > > -- > Dmitry Kiselev From michael.dillon at bt.com Mon Jun 1 13:30:11 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 1 Jun 2009 12:30:11 +0100 Subject: [address-policy-wg] RE: Private address space in IPv4 and IPv6 [was something irrelevantly titled] In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C497458016C24A4@E03MVZ2-UKDY.domain1.systemhost.net> > 2. The same network should have access to the Internet. Then > it should use NAT (not possibly in IPv6) or just be partially > connected to the Internet. The second case - is announcing > the block (or part of the > block) to the Internet. The first case - internal network may have RFC > 1918 or other IP addresses. Radianz is only one of several internetworks with connect many organizations together with circuits that are completely separate from the Internet. All of these organizations also have connections to the Internet. Internally, sometimes there is separate LAN cabling for the Radianz-connected workstations, and sometimes everything is on one LAN. If everything is on one LAN, then the only reason that Radianz is not connected to the Internet is because of many ACLs and firewall rules that control where traffic goes. People who make addressing policy, don't often think about ACLs and firewall rules, but they are at least as important as routing. If the Radianz network operates with globally unique IP addresses, then the subscribers can be confident that any ACLs blocking Radianz traffic from the Internet will never cause a problem for real Internet traffic. Globally unique addresses are required to have reliable ACLs in enterprise LANs. Technically speaking, you could claim that Radianz is actually connected to the Internet, even though they do not announce their address prefixes, and there are many ACLs and firewall rules blocking traffic from leaking out. Note that these types of traffic controls (ACLs) can be used in other scenarios. Network X could announce their addresses to some neighbour ASes in country A, and those ASes might not announce the routes to international peers. They might also implement ACLs so that no traffic can flow to international peers. Network X would still be on the Internet and their customers in country A would be happy that they can browse all kinds of sites on the Internet in country A. They could even send email internationally because it would be relayed by the ASes with international peering agreements. Is Network X on the Internet? Is the Radianz network on the Internet? Addressing policy would be just as complex as today if RIPE agreed that the scope for RIPE-NCC allocations should be restricted to "the Internet". There is no point in making such a change, and people who are ignorant of history need to take the time and learn about the history of the Internet, of IANA and of RIPE. Vlad, ne bud pizdetsom! Prochitay istoriyu i prekrashay svoyi glupie pisma. --Michael Dillon P.S. Radianz is merely an example of many other internetworks that carry IP traffic from many organizations, but which do not openly peer with the Internet. P.P.S. We are going through a time with lots of change, IPv4 runout, AS runout, RFC 1918 runout, AS32 introduction, IPv6 deployment. In addition, the landscape is not as uniform as it was back in the early days. LIR is no longer the same thing as ISP since there are now many more business models, and more diversity in how IP networks are built and operated. We need to keep a balanced view as we make changes to policy because RIPE policy has to be workable for everybody. From poty at iiat.ru Mon Jun 1 14:15:59 2009 From: poty at iiat.ru (poty at iiat.ru) Date: Mon, 1 Jun 2009 16:15:59 +0400 Subject: [address-policy-wg] RE: Private address space in IPv4 and IPv6 [was something irrelevantly titled] Message-ID: > -----Original Message----- > From: bmanning at vacation.karoshi.com > [mailto:bmanning at vacation.karoshi.com] > Sent: Monday, June 01, 2009 3:16 PM > To: Potapov Vladislav > Cc: andy at nosignal.org; address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] RE: Private address space in IPv4 and > IPv6 [was something irrelevantly titled] > ... > > 2. The same network should have access to the Internet. Then it > should > > use NAT (not possibly in IPv6) or just be partially connected to the > > > you should update your reading list. > I ahve been using IVI (an IPv6 NAT) for a little over > 18 months ... works just fine. > And you should look into the IETF BEHAVE work... all about > IPv6 and NAT. > > Thank you for pointing that - then there is one more possibility for IPv6. Vladislav Potapov Ru.iiat From poty at iiat.ru Mon Jun 1 14:24:52 2009 From: poty at iiat.ru (poty at iiat.ru) Date: Mon, 1 Jun 2009 16:24:52 +0400 Subject: [address-policy-wg] RE: Private address space in IPv4 and IPv6 [was something irrelevantly titled] Message-ID: > -----Original Message----- > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg- > admin at ripe.net] On Behalf Of michael.dillon at bt.com > Sent: Monday, June 01, 2009 3:30 PM > To: address-policy-wg at ripe.net > Subject: RE: [address-policy-wg] RE: Private address space in IPv4 and > IPv6 [was something irrelevantly titled] ... > People who make addressing policy, don't often think about ACLs > and firewall rules, but they are at least as important as > routing. If the Radianz network operates with globally unique > IP addresses, then the subscribers can be confident that any > ACLs blocking Radianz traffic from the Internet will never cause > a problem for real Internet traffic. Globally unique addresses > are required to have reliable ACLs in enterprise LANs. Administrative requirements never was an argument in the allocation/assignments. > Note that these types of traffic controls (ACLs) can be used > in other scenarios. Network X could announce their addresses > to some neighbour ASes in country A, and those ASes might > not announce the routes to international peers. They might > also implement ACLs so that no traffic can flow to > international peers. Network X would still be on the Internet > and their customers in country A would be happy that they > can browse all kinds of sites on the Internet in country A. > They could even send email internationally because it would > be relayed by the ASes with international peering agreements. > > Is Network X on the Internet? Is the Radianz network on the > Internet? There is a simple answer. If your address block is interacting with at least one announced prefix, then you should have globally unique addresses, otherwise - not. > > Addressing policy would be just as complex as today if RIPE > agreed that the scope for RIPE-NCC allocations should be > restricted to "the Internet". There is no point in making > such a change, and people who are ignorant of history need > to take the time and learn about the history of the Internet, > of IANA and of RIPE. Don't point to the history, because there was many changes in history. But POLICY of the RIPE NCC mean the scope - the Internet. Otherwise RIPE NCC should police any private IP-network in the world, even if the network doesn't want to be policed in any way, because does not leave several square meters of an office. Misha, derzi jazyk za zubami, i ne perehodi na lichnosti. From poty at iiat.ru Mon Jun 1 15:32:06 2009 From: poty at iiat.ru (poty at iiat.ru) Date: Mon, 1 Jun 2009 17:32:06 +0400 Subject: [address-policy-wg] RE: Private address space in IPv4 and IPv6 [was something irrelevantly titled] Message-ID: As already mentioned - to the shared network - the Internet. Opposing the internal network - how big and ugly it might be! > -----Original Message----- > From: bmanning at vacation.karoshi.com > [mailto:bmanning at vacation.karoshi.com] > Sent: Monday, June 01, 2009 5:12 PM > To: Potapov Vladislav > Cc: michael.dillon at bt.com; address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] RE: Private address space in IPv4 and > IPv6 [was something irrelevantly titled] > > On Mon, Jun 01, 2009 at 04:24:52PM +0400, poty at iiat.ru wrote: > > > > > > > Is Network X on the Internet? Is the Radianz network on the > > > Internet? > > There is a simple answer. If your address block is interacting with > at > > least one announced prefix, then you should have globally unique > > addresses, otherwise - not. > > > > announced to whom? > > --bill From bmanning at vacation.karoshi.com Mon Jun 1 13:15:55 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 1 Jun 2009 11:15:55 +0000 Subject: [address-policy-wg] RE: Private address space in IPv4 and IPv6 [was something irrelevantly titled] In-Reply-To: References: Message-ID: <20090601111555.GA11384@vacation.karoshi.com.> On Mon, Jun 01, 2009 at 02:36:33PM +0400, poty at iiat.ru wrote: > > > > -----Original Message----- > > From: Andy Davidson [mailto:andy at nosignal.org] > > Sent: Sunday, May 31, 2009 10:55 AM > > To: Potapov Vladislav > > Cc: address-policy-wg at ripe.net > > Subject: Re: [address-policy-wg] RE: Private address space in IPv4 and > > IPv6 [was something irrelevantly titled] > > > > > > On 29 May 2009, at 11:16, wrote: > > > > > Then Radianz could easily create its own rules without bothering the > > > World, couldn't it? And so - use ANY IP addresses. Why should I see > > > the > > > internal networks (I use corrected "private" meanings) of Radianz or > > > other such companys? If it is NEVER interact with my or the most of > > > other networks in the Internet? > > > > Hi, Vladislav > > > > As others have tried to point out, private networks often still > > connect to the Internet, so in order to prevent connectivity problems > > between -- in this case, Radianz -- and another, unspecified network > > on the Internet, then the addressing that Radianz need to use for > > their private networks must be globally unique. > Here we have several possibilities: > 1. We have a tunnel between the internal networks - then Radianz network > do not need to be GLOBALLY unique, it should be unique only between > interconnected networks. > 2. The same network should have access to the Internet. Then it should > use NAT (not possibly in IPv6) or just be partially connected to the you should update your reading list. I ahve been using IVI (an IPv6 NAT) for a little over 18 months ... works just fine. And you should look into the IETF BEHAVE work... all about IPv6 and NAT. > Internet. The second case - is announcing the block (or part of the > block) to the Internet. The first case - internal network may have RFC > 1918 or other IP addresses. > > > > > Kind regards, > > Andy Davidson > > Vladislav Potapov > Ru.iiat > From bmanning at vacation.karoshi.com Mon Jun 1 15:11:55 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 1 Jun 2009 13:11:55 +0000 Subject: [address-policy-wg] RE: Private address space in IPv4 and IPv6 [was something irrelevantly titled] In-Reply-To: References: Message-ID: <20090601131155.GA12490@vacation.karoshi.com.> On Mon, Jun 01, 2009 at 04:24:52PM +0400, poty at iiat.ru wrote: > > > > Is Network X on the Internet? Is the Radianz network on the > > Internet? > There is a simple answer. If your address block is interacting with at > least one announced prefix, then you should have globally unique > addresses, otherwise - not. > announced to whom? --bill From bmanning at vacation.karoshi.com Mon Jun 1 15:53:56 2009 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 1 Jun 2009 13:53:56 +0000 Subject: [address-policy-wg] RE: Private address space in IPv4 and IPv6 [was something irrelevantly titled] In-Reply-To: References: Message-ID: <20090601135356.GA12882@vacation.karoshi.com.> but how do you know that? peering is hop by hop. you can only announce to your peers. you have zero control over who they talk to or how they forward on reachability to your prefix roughly speaking, once packets cross my policy boundary (BGP?) then for all intents, I'm on the Internet... even if your prefixes aren't visible on/in my part of the universe. --bill On Mon, Jun 01, 2009 at 05:32:06PM +0400, poty at iiat.ru wrote: > As already mentioned - to the shared network - the Internet. Opposing > the internal network - how big and ugly it might be! > > > -----Original Message----- > > From: bmanning at vacation.karoshi.com > > [mailto:bmanning at vacation.karoshi.com] > > Sent: Monday, June 01, 2009 5:12 PM > > To: Potapov Vladislav > > Cc: michael.dillon at bt.com; address-policy-wg at ripe.net > > Subject: Re: [address-policy-wg] RE: Private address space in IPv4 and > > IPv6 [was something irrelevantly titled] > > > > On Mon, Jun 01, 2009 at 04:24:52PM +0400, poty at iiat.ru wrote: > > > > > > > > > > Is Network X on the Internet? Is the Radianz network on the > > > > Internet? > > > There is a simple answer. If your address block is interacting with > > at > > > least one announced prefix, then you should have globally unique > > > addresses, otherwise - not. > > > > > > > announced to whom? > > > > --bill > > From dave.wilson at heanet.ie Tue Jun 2 18:15:44 2009 From: dave.wilson at heanet.ie (Dave Wilson) Date: Tue, 02 Jun 2009 17:15:44 +0100 Subject: [address-policy-wg] RE: [policy-announce] 2009-06 New Policy Proposal (Removing Routing Requirements from the IPv6 Address Allocation Policy) In-Reply-To: References: Message-ID: <4A255030.4000301@heanet.ie> I'm sorry if I missed a crucial part of the conversation, but I've stopped understanding how this discussion relates to the policy proposal at hand. There is certainly a discussion that can be had about what type of network qualifies for unique address space. These types of networks can already trivially comply with the existing policy by announcing the address space on the public internet and nullrouting all traffic. Obviously not to be encouraged, but that's a consequence of a one-line requirement like this. So I do not see how changing the policy in this way has any effect (other than the beneficial effect of not encouraging such announcements) and I have seen no amendments to the policy that would have any effect. I would encourage someone to make a policy proposal on this topic - it is something that needs airing irrespective of 2009-06. The alternate argument that I see is that we should not shirk our responsibility to set good policies simply because we "don't do routing". I fully agree with this. If we are to do it in this document, however, then we have a fragile allocation policy that is subject to the winds of operational practice. Already we see requests to allow, say, multiple /32s for LIRs that operate multiple independent (and independently routed) networks. This is not just an abstract preference: already we see requests to allow, say, multiple /32s for LIRs that operate multiple independent (and independently routed) networks. A direct consequence of the existing policy is that they may not deaggregate. So we have tied the hands of routing best practice and will continue to do so unless and until we remove the routing restriction from the addressing policy and deal with it separately. So I can't see anything in the current arguments that are really affected by this policy proposal, at least not adversely. I'd like to see it ratified. We can work on separate proposals which might affect them. All the best, Dave -- Dave Wilson, Senior Network Engineer HEAnet Limited, Ireland's Education and Research Network 1st Floor, 5 George's Dock, IFSC, Dublin 1 Registered in Ireland, no 275301 tel: +353-1-660 9040 fax: +353-1-660 3666 web: http://www.heanet.ie/ H323 GDS:0035301101738 PGP: 1024D/C757ADA9 From ingrid at ripe.net Wed Jun 3 11:40:18 2009 From: ingrid at ripe.net (Ingrid Wijte) Date: Wed, 03 Jun 2009 11:40:18 +0200 Subject: [address-policy-wg] 2008-07 Discussion Period extended until 1 July 2009 (Ensuring efficient use of historical IPv4 resources) Message-ID: <20090603094018.3D9D32F5A5@herring.ripe.net> PDP Number: 2008-07 Ensuring efficient use of historical IPv4 resources Dear Colleagues, The text of the policy proposal 2008-07 has been revised based on the community feedback received on the mailing list. We have published the new version (version 2) today. As a result a new Discussion Phase is set for the proposal. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2008-07.html We encourage you to review this policy proposal and send your comments to address-policy-wg at ripe.net before 1 July 2009. Regards, Ingrid Wijte Policy Development Officer RIPE NCC From ingrid at ripe.net Wed Jun 3 12:09:53 2009 From: ingrid at ripe.net (Ingrid Wijte) Date: Wed, 03 Jun 2009 12:09:53 +0200 Subject: [address-policy-wg] 2009-08 New Policy Proposal (IPv6 Provider Independent (PI) Assignments for LIRs) Message-ID: <20090603100953.1B26A2F595@herring.ripe.net> PDP Number: 2009-08 IPv6 Provider Independent (PI) Assignments for LIRs Dear Colleagues A new RIPE Policy Proposal has been made and is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-08.html We encourage you to review this proposal and send your comments to address-policy-wg at ripe.net before 1 July 2009. Regards Ingrid Wijte Assistant Policy Development Officer RIPE NCC From remco.vanmook at eu.equinix.com Wed Jun 3 12:12:07 2009 From: remco.vanmook at eu.equinix.com (Remco van Mook) Date: Wed, 03 Jun 2009 12:12:07 +0200 Subject: [address-policy-wg] 2008-07 Discussion Period extended until 1 July 2009 (Ensuring efficient use of historical IPv4 resources) In-Reply-To: <20090603094018.3D9D32F5A5@herring.ripe.net> Message-ID: I support this proposal as it is. The obvious loophole would be that historical space would be moved to a non-LIR entity but there's no way to avoid that. Best, Remco On 03-06-09 11:40, "Ingrid Wijte" wrote: > PDP Number: 2008-07 > Ensuring efficient use of historical IPv4 resources > > Dear Colleagues, > > The text of the policy proposal 2008-07 has been revised based on the > community feedback received on the mailing list. > > We have published the new version (version 2) today. As a result a new > Discussion Phase is set for the proposal. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2008-07.html > > We encourage you to review this policy proposal and send your comments > to address-policy-wg at ripe.net before 1 July 2009. > > Regards, > > Ingrid Wijte > Policy Development Officer > RIPE NCC > > > This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383. From ula at ripn.net Wed Jun 3 13:28:01 2009 From: ula at ripn.net (Larisa A. Yurkina) Date: Wed, 3 Jun 2009 15:28:01 +0400 (MSD) Subject: [address-policy-wg] 2008-07 Discussion Period extended until 1 July 2009 (Ensuring efficient use of historical IPv4 resources) In-Reply-To: Message-ID: <20090603150154.F14286-100000@capral.ripn.net> On Wed, 3 Jun 2009, Remco van Mook wrote: > > I support this proposal as it is. The obvious loophole would be that > historical space would be moved to a non-LIR entity but there's no way to > avoid that. > > Best, > > Remco Hi, I propse to change "... documentation of all address resources they hold..." to "... documentation for all Assignments they made..." because otherwise it is not clear what 'documentation' is. At the same time, what is 'Documentation for Assignments' is clear from the current policy document (see 6.1). Documentation is forms for their infrastructure and their cutomers requests, it says. Second. To understand what 'pre-RIR registrations' means, one should aware when 'RIR registrations' started. Which is difficult. I propose remove '(this includes pre-RIR registrations).' from the text because this may confuse people. The definition of 'Historical resources' is much better, but i'd changed '...before the existence of the RIPE NCC' to '...before the RIPE NCC was established in 1998' Some my LIR's allocations have been recieved in 1995-1998. RIPE NCC did not exist as legal entity it exists now, but still it was an organisation which have allocated those blocks. Does it mean that we have Historical resources? Thank you. > > > On 03-06-09 11:40, "Ingrid Wijte" wrote: > > > PDP Number: 2008-07 > > Ensuring efficient use of historical IPv4 resources > > > > Dear Colleagues, > > > > The text of the policy proposal 2008-07 has been revised based on the > > community feedback received on the mailing list. > > > > We have published the new version (version 2) today. As a result a new > > Discussion Phase is set for the proposal. > > > > You can find the full proposal at: > > > > http://www.ripe.net/ripe/policies/proposals/2008-07.html > > > > We encourage you to review this policy proposal and send your comments > > to address-policy-wg at ripe.net before 1 July 2009. > > > > Regards, > > > > Ingrid Wijte > > Policy Development Officer > > RIPE NCC > > > > > > > > > > This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383. > > With respect, Larisa Yurkina --- RIPN Registry center ----- From Jerzy.Pawlus at cyf-kr.edu.pl Thu Jun 4 09:07:58 2009 From: Jerzy.Pawlus at cyf-kr.edu.pl (Jerzy Pawlus) Date: Thu, 4 Jun 2009 09:07:58 +0200 (METDST) Subject: [address-policy-wg] 2009-06 New Policy Proposal (Removing Routing Requirements from the IPv6 Address Allocation Policy) In-Reply-To: <20090526143034.7CB722F583@herring.ripe.net> (message from Filiz Yilmaz on Tue, 26 May 2009 16:30:34 +0200) References: <20090526143034.7CB722F583@herring.ripe.net> Message-ID: <200906040707.n5477wU3010635@nc.cyf-kr.edu.pl> Hi, > PDP Number: 2009-06 > Removing Routing Requirements from the IPv6 Address Allocation Policy > I support this policy. Unfortunately other RIR's like ARIN still have this routing requirement Regards, Jurek From scottleibrand at gmail.com Thu Jun 4 09:22:59 2009 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 4 Jun 2009 02:22:59 -0500 Subject: [address-policy-wg] 2009-06 New Policy Proposal (Removing Routing Requirements from the IPv6 Address Allocation Policy) In-Reply-To: <200906040707.n5477wU3010635@nc.cyf-kr.edu.pl> References: <20090526143034.7CB722F583@herring.ripe.net> <200906040707.n5477wU3010635@nc.cyf-kr.edu.pl> Message-ID: <8225DA57-270E-42CB-AB07-6D7D5D2587E6@gmail.com> A proposal to remove it in the ARIN region was just introduced as well. -Scott On Jun 4, 2009, at 2:07 AM, Jerzy Pawlus wrote: > > Hi, > >> PDP Number: 2009-06 >> Removing Routing Requirements from the IPv6 Address Allocation Policy >> > > I support this policy. > > Unfortunately other RIR's like ARIN still have this routing > requirement > > Regards, > > Jurek > From jerome.bouat at wanadoo.fr Thu Jun 4 12:50:47 2009 From: jerome.bouat at wanadoo.fr (=?ISO-8859-1?Q?J=E9r=F4me_Bouat?=) Date: Thu, 04 Jun 2009 12:50:47 +0200 Subject: [address-policy-wg] please remove invalid abuse contacts Message-ID: <4A27A707.7020907@wanadoo.fr> Hello, Your Whois database is providing "jhli_jl at mail.jl.cn" abuse contact email for IP 222.160.20.110. However, the mailbox is full (see attached error message). Please ensure each abuse complaint is processed by each network admin or remove useless contacts. Sometimes the user account or the domain name is invalid in the provided email. Thanks for you help. Regards. -------------- next part -------------- An embedded message was scrubbed... From: PostMaster at mail.jl.cn <> Subject: ???? mail.jl.cn ?????? Date: Thu, 04 Jun 2009 16:50:21 +0800 Size: 4635 URL: From jeroen at unfix.org Thu Jun 4 13:02:55 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 04 Jun 2009 13:02:55 +0200 Subject: [address-policy-wg] please remove invalid abuse contacts In-Reply-To: <4A27A707.7020907@wanadoo.fr> References: <4A27A707.7020907@wanadoo.fr> Message-ID: <4A27A9DF.4080409@spaghetti.zurich.ibm.com> J?r?me Bouat wrote: > Hello, > > Your Whois database is providing "jhli_jl at mail.jl.cn" abuse contact > email for IP 222.160.20.110. $ whois 222.160.20.110 % APNIC found the following authoritative answer from: whois.apnic.net [..] Otherwise said: this is an APNIC based IP address (not so strange with .cn being in the email address), thus quite outside of the RIPE region. > However, the mailbox is full (see attached error message). > > > Please ensure each abuse complaint is processed by each network admin or > remove useless contacts. How exactly are RIRs supposed to enforce this? > Sometimes the user account or the domain name is invalid in the provided > email. Thus, because an email box is full, that information should just be removed? What exactly does this help? Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From jerome.bouat at wanadoo.fr Thu Jun 4 13:55:28 2009 From: jerome.bouat at wanadoo.fr (=?ISO-8859-1?Q?J=E9r=F4me_Bouat?=) Date: Thu, 04 Jun 2009 13:55:28 +0200 Subject: [address-policy-wg] Re: please remove invalid abuse contacts In-Reply-To: <4A27A707.7020907@wanadoo.fr> References: <4A27A707.7020907@wanadoo.fr> Message-ID: <4A27B630.6040906@wanadoo.fr> Hello, I'm reporting many invalid contact to RIPE, APNIC, AFRINIC, ARIN, LACNIC. I made an error, the invalid contact which is related to you is: "abuse at ono.com" for IP 84.127.214.4. The issue is that the contact admin doesn't solve the abuse I encounter. Who should I contact if the RIPE database manager tell me he/she can't do anything and if you tell me you're not the right working group ? Thanks for your help. Regards. J?r?me Bouat a ?crit : > Hello, > > Your Whois database is providing "jhli_jl at mail.jl.cn" abuse contact > email for IP 222.160.20.110. > > However, the mailbox is full (see attached error message). > > > Please ensure each abuse complaint is processed by each network admin or > remove useless contacts. > > Sometimes the user account or the domain name is invalid in the provided > email. > > Thanks for you help. > > Regards. > > > ------------------------------------------------------------------------ > > Sujet: > ???? mail.jl.cn ?????? > Exp?diteur: > PostMaster at mail.jl.cn <> > Date: > Thu, 04 Jun 2009 16:50:21 +0800 > Destinataire: > jerome.bouat at wanadoo.fr > > Destinataire: > jerome.bouat at wanadoo.fr > > > ??????????: > >> ????: Thu, 4 Jun 2009 10:56:00 +0200 (CEST) >> ????: Spam Complaint [Msg#14209, IP 222.160.20.110]; >> ????: 2683 bytes ???? >> ????: ???? > > ??????????????????????????: > > jhli_jl:mail "(0), ErrMsg=Too many mails in mailbox. Mail count (3030) reaches or exceeds upper limit (3000)." > > ?????????????????????????????????????? ???????????????????????????????????????????????????????????????????????????? > > > ------------------------------------------------------------------------ > > Sujet: > Spam Complaint [Msg#14209, IP 222.160.20.110]; > Exp?diteur: > jerome.bouat at wanadoo.fr > Date: > Thu, 4 Jun 2009 10:56:00 +0200 (CEST) > Destinataire: > abuse at chinaunicom.cn, abuse at cnc-noc.net, jhli_jl at mail.jl.cn > > Destinataire: > abuse at chinaunicom.cn, abuse at cnc-noc.net, jhli_jl at mail.jl.cn > > > I have attached an unsolicited e-mail sent to my computer. Please investigate and prevent recurrences by acting on your Acceptable Use Policy. > > Your help is greatly appreciated. > > Thank You > > -------- Original Message -------- >>From - Thu Jun 4 10:20:54 2009 > X-Account-Key:account2 > X-UIDL:1186180440.17051 > X-Mozilla-Status:0001 > X-Mozilla-Status2:00000000 > X-Mozilla-Keys: > Return-Path: > Received:from mwinf8208.laposte.net (mwinf8208.laposte.net) > by mwinb7606 (SMTP Server) with LMTP; Thu, 04 Jun 2009 07:50:57 +0200 > X-Sieve:Server Sieve 2.2 > Received:from meplus.info (localhost [127.0.0.1]) > by mwinf8208.laposte.net (SMTP Server) with ESMTP id 89C0E240008A; > Thu, 4 Jun 2009 07:50:57 +0200 (CEST) > Received:from 193.251.214.113 (unknown [222.160.20.110]) > by mwinf8208.laposte.net (SMTP Server) with SMTP id 445C72400091; > Thu, 4 Jun 2009 07:50:38 +0200 (CEST) > X-ME-UUID:20090604055039280.445C72400091 at mwinf8208.laposte.net > Date:Thu, 04 Jun 2009 01:50:34 -0500 > From:"Le sexe le potentiel +100 %" > Message-ID: > To:jerome.borde at laposte.net > Subject:*** SPAM ***Re:Votre succ???s sexuel en 15 minutes. > MIME-Version:1.0 > Content-Type:text/html; charset=iso-8859-1 > Content-Transfer-Encoding:7bit > X-me-spamlevel:med > X-me-spamrating:89.099998 > X-me-spamcause:OK, (330)(1000)gggruggvucftvghtrhhoucdtuddrvdekvddrgeekucetggdotefuucfrrhhofhhilhgvmecuoehnohhnvgeqnecuuegrihhlohhuthemuceftddtnecujfhtmhhlqfhnlhihqddqqfdvkedvqdduvdculdeftddtmdennhhouchhohhsthcuuhhrlhculdeftddm > > > > From jeroen at unfix.org Thu Jun 4 14:11:43 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 04 Jun 2009 14:11:43 +0200 Subject: [address-policy-wg] Re: please remove invalid abuse contacts In-Reply-To: <4A27B630.6040906@wanadoo.fr> References: <4A27A707.7020907@wanadoo.fr> <4A27B630.6040906@wanadoo.fr> Message-ID: <4A27B9FF.6070504@spaghetti.zurich.ibm.com> J?r?me Bouat wrote: > Hello, > > I'm reporting many invalid contact to RIPE, APNIC, AFRINIC, ARIN, LACNIC. > > I made an error, the invalid contact which is related to you is: > "abuse at ono.com" for IP 84.127.214.4. > > The issue is that the contact admin doesn't solve the abuse I encounter. > > Who should I contact if the RIPE database manager tell me he/she can't > do anything and if you tell me you're not the right working group ? (I am not the "Working Group", just one of the voices in it) Abuse has nothing to do with Address Policy. If you don't get a response from the ISP in question, then I suggest you contact the upstream. In most of these kind of cases though you won't be able to resolve those questions and you are just wasting a lot of your time, as such choose the easy way: just block them. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From jerome.bouat at wanadoo.fr Thu Jun 4 14:20:07 2009 From: jerome.bouat at wanadoo.fr (=?ISO-8859-1?Q?J=E9r=F4me_Bouat?=) Date: Thu, 04 Jun 2009 14:20:07 +0200 Subject: [address-policy-wg] Re: please remove invalid abuse contacts In-Reply-To: <4A27B9FF.6070504@spaghetti.zurich.ibm.com> References: <4A27A707.7020907@wanadoo.fr> <4A27B630.6040906@wanadoo.fr> <4A27B9FF.6070504@spaghetti.zurich.ibm.com> Message-ID: <4A27BBF7.9000608@wanadoo.fr> > Abuse has nothing to do with Address Policy. If the abuse contact provided by the whois database is wrong then it is an address policy issue since the contact information was wrong when assigning an IP range. > If you don't get a response > from the ISP in question, > then I suggest you contact the upstream. Who is upstream ? > In most of these kind of cases > though you won't be able to resolve those > questions and you are just wasting a lot of your time, > as such choose the easy way: just block them. I don't agree. If the admin cut the network access of the spammer he/she won't continue to send Spam. Regards. Jeroen Massar a ?crit : > J?r?me Bouat wrote: >> Hello, >> >> I'm reporting many invalid contact to RIPE, APNIC, AFRINIC, ARIN, LACNIC. >> >> I made an error, the invalid contact which is related to you is: >> "abuse at ono.com" for IP 84.127.214.4. >> >> The issue is that the contact admin doesn't solve the abuse I encounter. >> >> Who should I contact if the RIPE database manager tell me he/she can't >> do anything and if you tell me you're not the right working group ? > > (I am not the "Working Group", just one of the voices in it) > > Abuse has nothing to do with Address Policy. If you don't get a response > from the ISP in question, then I suggest you contact the upstream. > > In most of these kind of cases though you won't be able to resolve those > questions and you are just wasting a lot of your time, as such choose > the easy way: just block them. > > Greets, > Jeroen > From tom.farrar at it-ps.com Thu Jun 4 14:30:38 2009 From: tom.farrar at it-ps.com (Tom Farrar) Date: Thu, 4 Jun 2009 13:30:38 +0100 Subject: [address-policy-wg] Re: please remove invalid abuse contacts In-Reply-To: <4A27BBF7.9000608@wanadoo.fr> References: <4A27A707.7020907@wanadoo.fr> <4A27B630.6040906@wanadoo.fr> <4A27B9FF.6070504@spaghetti.zurich.ibm.com> <4A27BBF7.9000608@wanadoo.fr> Message-ID: See here: http://www.ripe.net/info/faq/abuse/index.html#6 >6. Why are there no contact details or incorrect contact details for reporting spam email listed in the RIPE Database for the IP address I searched on? > >The records in the Regional Internet Registries' (RIR) databases are entered and maintained by the organisations that receive IP addresses from each >RIR. The RIRs do not check the accuracy of any of the records in the database or make any changes to the data maintained by these organisations. The >RIPE NCC has no power to update any of these records. You need to contact the 'ONO' (perhaps try ripe-tech at ono.es), not a RIPE working group. Major peers of 'ONO' are AS1273 and AS1299; you could try contacting them. -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of J?r?me Bouat Sent: 04 June 2009 13:20 To: Jeroen Massar Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] Re: please remove invalid abuse contacts > Abuse has nothing to do with Address Policy. If the abuse contact provided by the whois database is wrong then it is an address policy issue since the contact information was wrong when assigning an IP range. > If you don't get a response > from the ISP in question, > then I suggest you contact the upstream. Who is upstream ? > In most of these kind of cases > though you won't be able to resolve those > questions and you are just wasting a lot of your time, > as such choose the easy way: just block them. I don't agree. If the admin cut the network access of the spammer he/she won't continue to send Spam. Regards. Jeroen Massar a ?crit : > J?r?me Bouat wrote: >> Hello, >> >> I'm reporting many invalid contact to RIPE, APNIC, AFRINIC, ARIN, LACNIC. >> >> I made an error, the invalid contact which is related to you is: >> "abuse at ono.com" for IP 84.127.214.4. >> >> The issue is that the contact admin doesn't solve the abuse I encounter. >> >> Who should I contact if the RIPE database manager tell me he/she can't >> do anything and if you tell me you're not the right working group ? > > (I am not the "Working Group", just one of the voices in it) > > Abuse has nothing to do with Address Policy. If you don't get a response > from the ISP in question, then I suggest you contact the upstream. > > In most of these kind of cases though you won't be able to resolve those > questions and you are just wasting a lot of your time, as such choose > the easy way: just block them. > > Greets, > Jeroen > From jeroen at unfix.org Thu Jun 4 14:33:57 2009 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 04 Jun 2009 14:33:57 +0200 Subject: [address-policy-wg] Re: please remove invalid abuse contacts In-Reply-To: <4A27BBF7.9000608@wanadoo.fr> References: <4A27A707.7020907@wanadoo.fr> <4A27B630.6040906@wanadoo.fr> <4A27B9FF.6070504@spaghetti.zurich.ibm.com> <4A27BBF7.9000608@wanadoo.fr> Message-ID: <4A27BF35.2010403@spaghetti.zurich.ibm.com> J?r?me Bouat wrote: >> Abuse has nothing to do with Address Policy. > > If the abuse contact provided by the whois database is wrong then it is > an address policy issue since the contact information was wrong when > assigning an IP range. Then it could only be that the address is outdated. Nothing much *this* working group can do about. For outdated addresses etc in the RIPE database, you could possibly contact hostmaster at ripe.net, but they won't be able to do much about that either. >> If you don't get a response >> from the ISP in question, >> then I suggest you contact the upstream. > > Who is upstream ? If you do not know how to figure that out or even what that is, then I suggest you first take an educational course on how the Internet really works. >> In most of these kind of cases >> though you won't be able to resolve those >> questions and you are just wasting a lot of your time, >> as such choose the easy way: just block them. > > > I don't agree. If the admin cut the network access of the spammer he/she > won't continue to send Spam. The upstreams can (possibly) do that even if you can't reach them anymore as they provide the connectivity to them, and most very likely have a paying relationship and thus hopefully correct contacts. Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From jim at rfc1035.com Thu Jun 4 14:35:18 2009 From: jim at rfc1035.com (Jim Reid) Date: Thu, 4 Jun 2009 13:35:18 +0100 Subject: [address-policy-wg] Re: please remove invalid abuse contacts In-Reply-To: <4A27BBF7.9000608@wanadoo.fr> References: <4A27A707.7020907@wanadoo.fr> <4A27B630.6040906@wanadoo.fr> <4A27B9FF.6070504@spaghetti.zurich.ibm.com> <4A27BBF7.9000608@wanadoo.fr> Message-ID: <56FF8E45-9CFE-4083-BB52-3F34F34A13B7@rfc1035.com> On 4 Jun 2009, at 13:20, J?r?me Bouat wrote: > If the abuse contact provided by the whois database is wrong then it > is an address policy issue since the contact information was wrong > when assigning an IP range. Define "wrong". Apart from the data someone inputs for themself, how can anyone know for sure any contact data in whois is correct? For some definition of "correct". In any case, I fail to see how your gripe about a full mailbox for an abuse contact in the APNIC whois database has any relevance to this list. Please take this discussion somewhere else. I am sure there are APNIC-specific lists for discussing its database, address policy and abuse issues. From jerome.bouat at wanadoo.fr Thu Jun 4 14:48:04 2009 From: jerome.bouat at wanadoo.fr (=?ISO-8859-1?Q?J=E9r=F4me_Bouat?=) Date: Thu, 04 Jun 2009 14:48:04 +0200 Subject: [address-policy-wg] Re: please remove invalid abuse contacts In-Reply-To: References: <4A27A707.7020907@wanadoo.fr> <4A27B630.6040906@wanadoo.fr> <4A27B9FF.6070504@spaghetti.zurich.ibm.com> <4A27BBF7.9000608@wanadoo.fr> Message-ID: <4A27C284.6010906@wanadoo.fr> > perhaps try ripe-tech at ono.es The issue is I have no time to try and I would like the right contact at the first try. How to ensure the whois database is accurate just after the IP range registration ? Tom Farrar a ?crit : > See here: > > http://www.ripe.net/info/faq/abuse/index.html#6 > >> 6. Why are there no contact details or incorrect contact details for reporting spam email listed in the RIPE Database for the IP address I searched on? >> >> The records in the Regional Internet Registries' (RIR) databases are entered and maintained by the organisations that receive IP addresses from each >RIR. The RIRs do not check the accuracy of any of the records in the database or make any changes to the data maintained by these organisations. The >RIPE NCC has no power to update any of these records. > > You need to contact the 'ONO' (perhaps try ripe-tech at ono.es), not a RIPE working group. Major peers of 'ONO' are AS1273 and AS1299; you could try contacting them. > > > > > -----Original Message----- > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of J?r?me Bouat > Sent: 04 June 2009 13:20 > To: Jeroen Massar > Cc: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] Re: please remove invalid abuse contacts > > > Abuse has nothing to do with Address Policy. > > If the abuse contact provided by the whois database is wrong then it is > an address policy issue since the contact information was wrong when > assigning an IP range. > > > > If you don't get a response > > from the ISP in question, > > then I suggest you contact the upstream. > > Who is upstream ? > > > > In most of these kind of cases > > though you won't be able to resolve those > > questions and you are just wasting a lot of your time, > > as such choose the easy way: just block them. > > > I don't agree. If the admin cut the network access of the spammer he/she > won't continue to send Spam. > > > > Regards. > > > Jeroen Massar a ?crit : >> J?r?me Bouat wrote: >>> Hello, >>> >>> I'm reporting many invalid contact to RIPE, APNIC, AFRINIC, ARIN, LACNIC. >>> >>> I made an error, the invalid contact which is related to you is: >>> "abuse at ono.com" for IP 84.127.214.4. >>> >>> The issue is that the contact admin doesn't solve the abuse I encounter. >>> >>> Who should I contact if the RIPE database manager tell me he/she can't >>> do anything and if you tell me you're not the right working group ? >> (I am not the "Working Group", just one of the voices in it) >> >> Abuse has nothing to do with Address Policy. If you don't get a response >> from the ISP in question, then I suggest you contact the upstream. >> >> In most of these kind of cases though you won't be able to resolve those >> questions and you are just wasting a lot of your time, as such choose >> the easy way: just block them. >> >> Greets, >> Jeroen >> > > > From michael.dillon at bt.com Thu Jun 4 15:02:36 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 4 Jun 2009 14:02:36 +0100 Subject: [address-policy-wg] Re: please remove invalid abuse contacts In-Reply-To: <4A27C284.6010906@wanadoo.fr> Message-ID: <28E139F46D45AF49A31950F88C497458017E1C5E@E03MVZ2-UKDY.domain1.systemhost.net> > > perhaps try ripe-tech at ono.es > > > The issue is I have no time to try and I would like the right > contact at the first try. > > How to ensure the whois database is accurate just after the > IP range registration ? You really need to get some education on how the Internet works. First of all, this IP range was never registered with RIPE because it is from an APNIC allocation. Secondly, this email address was probably accurate at the time of registration. In fact, it was probably accurate two days ago as well. The email address exists and is active on an email server which replied to you that the mailbox is full. This often happens when a spammer starts sending email from a new source, and a flood of complaints fill up the mailbox during the next few hours. Thirdly, it is not your responsibility to police the APNIC database or the RIPE database. Fourthly, people who understand the dynamics of SPAM attacks, also understand why mailboxes are full, and since there are already lots of complaints, they decide that there is no point in adding one more complaint. Instead, they block that IP address (or IP address range) from their email servers for a few days. Finally, this RIPE address policy working group does not have the powers to create policies which police the APNIC database, and probably not even the RIPE database, because policing is not really in scope for RIPE. If there is some technical reason why you cannot solve this issue by blocking traffic from the IP address range of the source of the SPAM, then your only logical course of action is to contact the upstream peers of the SPAM source ISP and ask those peers to block your address range from receiving packets. Generally you only want to do this if it is a DDoS. --Michael Dillon P.S. Once evening, a policeman notices a man crawling on his knees searching for something under a lamppost. "Excuse me, sir, have you lost something?" he says. The man replies, "It's my car-keys, I dropped them". The policeman gets down on his knees and helps to search. After a moment, he says to the man, "Are you sure that you dropped them here?". "Oh no, says the man, I dropped them way down the street but it is too dark there to see anything so I came here under the street lamp where it is easier to see.". From jwkckid1 at ix.netcom.com Thu Jun 4 22:48:52 2009 From: jwkckid1 at ix.netcom.com (Jeffrey A. Williams) Date: Thu, 04 Jun 2009 13:48:52 -0700 Subject: [address-policy-wg] Re: please remove invalid abuse contacts References: <4A27A707.7020907@wanadoo.fr> <4A27B630.6040906@wanadoo.fr> <4A27B9FF.6070504@spaghetti.zurich.ibm.com> Message-ID: <4A283334.42C84F68@ix.netcom.com> Jeroen and all, Exactly right! I just block them, report them to DHS, and move on... Recognizing of course nothing or any consequence will be actually done about it and the fact that getting something done about it is really ICANN's job which of course it has fallen down on sense it very conception and continues to be negligent accordingly. Jeroen Massar wrote: > J?r?me Bouat wrote: > > Hello, > > > > I'm reporting many invalid contact to RIPE, APNIC, AFRINIC, ARIN, LACNIC. > > > > I made an error, the invalid contact which is related to you is: > > "abuse at ono.com" for IP 84.127.214.4. > > > > The issue is that the contact admin doesn't solve the abuse I encounter. > > > > Who should I contact if the RIPE database manager tell me he/she can't > > do anything and if you tell me you're not the right working group ? > > (I am not the "Working Group", just one of the voices in it) > > Abuse has nothing to do with Address Policy. If you don't get a response > from the ISP in question, then I suggest you contact the upstream. > > In most of these kind of cases though you won't be able to resolve those > questions and you are just wasting a lot of your time, as such choose > the easy way: just block them. > > Greets, > Jeroen > > ------------------------------------------------------------------------ > Name: signature.asc > signature.asc Type: application/pgp-signature > Description: OpenPGP digital signature Regards, Spokesman for INEGroup LLA. - (Over 284k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "YES WE CAN!" Barack ( Berry ) Obama "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 My Phone: 214-244-4827 From jerome.bouat at wanadoo.fr Mon Jun 8 16:43:19 2009 From: jerome.bouat at wanadoo.fr (=?ISO-8859-1?Q?J=E9r=F4me_Bouat?=) Date: Mon, 08 Jun 2009 16:43:19 +0200 Subject: [address-policy-wg] please remove ripe-staff@telecomitalia.it from the whois records Message-ID: <4A2D2387.80100@wanadoo.fr> Hello, I'm trying to find the right contact for network issues. Querying the RIPE whois database with the below command: --- whois -h whois.ripe.net 87.14.213.17 --- provides the below result: --- (...) e-mail: ripe-staff at telecomitalia.it (...) --- However it appears that the "ripe-staff" mail account is undefined on the "telecomitalia.it" mail server. This means that my Spam complaints never reach the network admin team. Could you please update the whois database (RIPE) by removing the invalid "ripe-staff at telecomitalia.it" email address and also provide a replacement ? Thanks for your help. Regards. From jerome.bouat at wanadoo.fr Mon Jun 8 16:50:11 2009 From: jerome.bouat at wanadoo.fr (=?ISO-8859-1?Q?J=E9r=F4me_Bouat?=) Date: Mon, 08 Jun 2009 16:50:11 +0200 Subject: [address-policy-wg] please remove ripe-staff@telecomitalia.it from the whois records In-Reply-To: <4A2D2387.80100@wanadoo.fr> References: <4A2D2387.80100@wanadoo.fr> Message-ID: <4A2D2523.1080009@wanadoo.fr> The reply I had to this message show that the "cgiadmin at cgi.interbusiness.it" mailbox is unreachable (550 #5.1.0 Address rejected). Regards. J?r?me Bouat a ?crit : > > Hello, > > > I'm trying to find the right contact for network issues. > > Querying the RIPE whois database with the below command: > --- > whois -h whois.ripe.net 87.14.213.17 > --- > > provides the below result: > --- > (...) > e-mail: ripe-staff at telecomitalia.it > (...) > --- > > However it appears that the "ripe-staff" mail account is undefined on > the "telecomitalia.it" mail server. > > This means that my Spam complaints never reach the network admin team. > > Could you please update the whois database (RIPE) by removing the > invalid "ripe-staff at telecomitalia.it" email address and also provide a > replacement ? > > Thanks for your help. > > > Regards. > > > -------------- next part -------------- An embedded message was scrubbed... From: MAILER-DAEMON at smtp.free.fr (Mail Delivery System) Subject: Undelivered Mail Returned to Sender Date: Mon, 8 Jun 2009 16:43:34 +0200 (CEST) Size: 4619 URL: From marcoh at marcoh.net Mon Jun 8 16:50:22 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Mon, 8 Jun 2009 16:50:22 +0200 Subject: [address-policy-wg] please remove ripe-staff@telecomitalia.it from the whois records In-Reply-To: <4A2D2387.80100@wanadoo.fr> References: <4A2D2387.80100@wanadoo.fr> Message-ID: <60D77A8E-969B-4A46-8047-6CEF105F4CF3@marcoh.net> Could you please stop sending this messages to the WG mailing list, it has nothing to do with address policy. TIA, Marco On 8 jun 2009, at 16:43, J?r?me Bouat wrote: > Hello, > > > I'm trying to find the right contact for network issues. > > Querying the RIPE whois database with the below command: > --- > whois -h whois.ripe.net 87.14.213.17 > --- > > provides the below result: > --- > (...) > e-mail: ripe-staff at telecomitalia.it > (...) > --- > > However it appears that the "ripe-staff" mail account is undefined > on the "telecomitalia.it" mail server. > > This means that my Spam complaints never reach the network admin team. > > Could you please update the whois database (RIPE) by removing the > invalid "ripe-staff at telecomitalia.it" email address and also provide > a replacement ? > > Thanks for your help. > > > Regards. > From niels=apwg at bakker.net Mon Jun 8 16:51:49 2009 From: niels=apwg at bakker.net (Niels Bakker) Date: Mon, 8 Jun 2009 16:51:49 +0200 Subject: [address-policy-wg] please remove ripe-staff@telecomitalia.it from the whois records In-Reply-To: <4A2D2387.80100@wanadoo.fr> References: <4A2D2387.80100@wanadoo.fr> Message-ID: <20090608145149.GE84365@burnout.tpb.net> * jerome.bouat at wanadoo.fr (J?r?me Bouat) [Mon 08 Jun 2009, 16:44 CEST]: >I'm trying to find the right contact for network issues. [..] >Thanks for your help. address-policy-wg is not that place. Please stop Cc'ing this list. -- Niels. -- From Marcus.Gerdon at versatel.de Mon Jun 8 18:43:57 2009 From: Marcus.Gerdon at versatel.de (Marcus.Gerdon) Date: Mon, 8 Jun 2009 18:43:57 +0200 Subject: [address-policy-wg] RE: [policy-announce] 2009-06 New Policy Proposal (Removing Routing Requirements from the IPv6 Address Allocation Policy) Message-ID: <227142482560EF458FF1F7E784E26AB898FDDA@FLBVEXCH01.versatel.local> Dear colleagues, I can't give support to this proposal as it is. Some of you have already argumented against the resulting de-aggregation and therefore polution of the (IPv6) routing table to be expected. The mindful use of 'Operators Choice' you can all see when browsing the IPv4 table. There *will* be operators de-aggregating an allocation just because they need one - i.e. - /40 to be traversing a defined link. Allowing allocations to be routed at operators liking (which is meant by 'Operators Choice' of course) without violating any policy will supposedly never again be confined once it has been started. Before starting to fire back arguments like 'filtering bcp is at minimum allocation size', 'RIPE doesn't guarantee routing/reachability' etc. think about how to get out of this later on. An example: tell a customer, possibly one of the larger ones you have, that the homemade isp at the other end of the world is polluting the global routing tables and therefore won't receive the customers emails as you are filtering *valid* advertisements (which would be the result after the policy change) based on a recommendation. This doesn't work out. Sooner or later anybody will somehow be forced to accept any de-aggregated trash. IPv6 had been designed for hierarchical addressing. I understand there is need for de-aggregation to support traffic engineering, load-sharing, localized routing or alike. I remember (darkly, so pls don't take me by word) a discussion along the IPv6 PI years (?) regarding geological allocation of address space. So why do we now want to go into the opposite direction? I'm not quite happy having IPv4 and IPv6 being compared in regards to policies and assignment of topics onto wg's. IPv6 has an inherent combination of address assignment/allocation and routing. Doing one without the other in mind will result in IPv4 world again. That said, I come to the part of 'as it is' I stated to the beginning. I suggest to modify the routing requirements to support some level of de-aggregation instead of removing them completely. Why not change b) advertise the allocation that they will receive as a single prefix if the prefix is to be used on the Internet; into something like (roughly worded for short) b) advertise the allocation in whole, and if needed additional overlapping more-specifics up to an 8th the allocations size at most I think this might help in limiting the number of de-aggregated routes within the tables while allowing for a still more stringent filtering based on the 'minimum allocation size'/8. In cases where regional routing or load-sharing across multiple links to the same peer is required special arrangements can always be made I think (using no-export or alike). At least the requirement of advertising the aggregated allocation would maintain reachability across min-alloc-size filters and allow for serious arguments - aka finger-pointing - in regards to customer discussions when traffic isn't able to traverse the aggregate route. regards, Marcus ---------------------------------------------------------------------------------------- Engineering IP Services Versatel West GmbH Unterste-Wilms-Strasse 29 D-44143 Dortmund Fon: +49-(0)231-399-4486 | Fax: +49-(0)231-399-4491 marcus.gerdon at versatel.de | www.versatel.de Sitz der Gesellschaft: Dortmund | Registergericht: Dortmund HRB 21738 Gesch?ftsf?hrer: Marc L?tzenkirchen, Dr. Hai Cheng, Dr. Max Padberg, Peter Schindler ---------------------------------------------------------------------------------------- AS8881 / AS8638 / AS13270 | MG3031-RIPE ---------------------------------------------------------------------------------------- > -----Urspr?ngliche Nachricht----- > Von: address-policy-wg-admin at ripe.net > [mailto:address-policy-wg-admin at ripe.net] Im Auftrag von Jeroen Massar > Gesendet: Mittwoch, 27. Mai 2009 18:37 > An: Frederic > Cc: alain.bidron at orange-ftgroup.com; address-policy-wg at ripe.net > Betreff: Re: [address-policy-wg] RE: [policy-announce] > 2009-06 New Policy Proposal (Removing Routing Requirements > from the IPv6 Address Allocation Policy) > > Frederic wrote: > > we do not support this proposal and we would garant routing for min > > ipv6-PI block assignement. > > RIPE NCC cannot guarantee anything regarding routing. You need to > communicate with the rest of the parties where you want your prefix to > go if they want to accept it or not. > > Please see: > http://www.ripe.net/ripe/docs/ipv6-policies.html#routability > (see section 4.2. Routability Not Guaranteed in RIPE-466) > As mentioned in the text of the proposal. > > > Clearly there is a lot of confusion about this, thus, as I > mentioned in > my other mail, the text can be amended by removing those > statements, but > then there should definitely be a clear link to the above document. > > Greets, > Jeroen > > From remco.vanmook at eu.equinix.com Mon Jun 8 20:02:42 2009 From: remco.vanmook at eu.equinix.com (Remco van Mook) Date: Mon, 08 Jun 2009 20:02:42 +0200 Subject: [address-policy-wg] 2009-08 New Policy Proposal (IPv6 Provider Independent (PI) Assignments for LIRs) In-Reply-To: <20090603100953.1B26A2F595@herring.ripe.net> Message-ID: Dear all, In line with my comments on this mailing list earlier this year, I support this proposal. While this proposal is similar in intention to 2009-06, I think having both options available for the community would be an improvement over having just one. Kind regards, Remco On 03-06-09 12:09, "Ingrid Wijte" wrote: > PDP Number: 2009-08 > IPv6 Provider Independent (PI) Assignments for LIRs > > Dear Colleagues > > A new RIPE Policy Proposal has been made and is now available for > discussion. > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2009-08.html > > We encourage you to review this proposal and send your comments to > address-policy-wg at ripe.net before 1 July 2009. > > Regards > > Ingrid Wijte > Assistant Policy Development Officer > RIPE NCC > > > This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383. -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederic at placenet.org Mon Jun 8 21:07:52 2009 From: frederic at placenet.org (Frederic) Date: Mon, 08 Jun 2009 21:07:52 +0200 Subject: [address-policy-wg] 2009-08 Message-ID: <1244488072.3583.1.camel@kzinti.placenet.org> hi, we support this proposal. http://www.ripe.net/ripe/policies/proposals/2009-08.html bst regards. Frederic From marcoh at marcoh.net Mon Jun 8 21:38:44 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Mon, 8 Jun 2009 21:38:44 +0200 Subject: [address-policy-wg] 2009-08 New Policy Proposal (IPv6 Provider Independent (PI) Assignments for LIRs) In-Reply-To: References: Message-ID: <31C6D80D-EBC5-4FDA-AF25-615B8382A2C6@marcoh.net> I support this proposal, however with 2 comments: - I would like to see a merger of the various proposals trying to change 466 so we can review the full changed document once - How do these changes relate to the first line "..It was developed through joint discussions among the APNIC, ARIN and RIPE communities." Grtx, marco On Jun 8, 2009, at 8:02 PM, Remco van Mook wrote: > > Dear all, > > In line with my comments on this mailing list earlier this year, I > support this proposal. While this proposal is similar in intention > to 2009-06, I think having both options available for the community > would be an improvement over having just one. > > Kind regards, > > Remco > > > On 03-06-09 12:09, "Ingrid Wijte" wrote: > >> PDP Number: 2009-08 >> IPv6 Provider Independent (PI) Assignments for LIRs >> >> Dear Colleagues >> >> A new RIPE Policy Proposal has been made and is now available for >> discussion. >> >> You can find the full proposal at: >> >> http://www.ripe.net/ripe/policies/proposals/2009-08.html >> >> We encourage you to review this proposal and send your comments to >> address-policy-wg at ripe.net before 1 July 2009. >> >> Regards >> >> Ingrid Wijte >> Assistant Policy Development Officer >> RIPE NCC >> >> >> > > > This email is from Equinix Europe Limited or one of its associated/ > subsidiary companies. This email, and any files transmitted with it, > contains information which is confidential, may be legally > privileged and is solely for the use of the intended recipient. If > you have received this email in error, please notify the sender and > delete this email immediately. Equinix Europe Limited. Registered > Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More > Square, London E1W 1YW. Registered in England and Wales No. 6293383. MarcoH From david.freedman at uk.clara.net Mon Jun 8 22:04:59 2009 From: david.freedman at uk.clara.net (David Freedman) Date: Mon, 8 Jun 2009 21:04:59 +0100 Subject: [address-policy-wg] 2009-08 References: <1244488072.3583.1.camel@kzinti.placenet.org> Message-ID: <7B8B0D6F623C3A40A0D0A80A66756E2B0D7BD6@EXVS01.claranet.local> Can I just ask for clarification of the following: "the LIR must demonstrate the unique routing requirements for the PI assignment." and "The LIR must return the IPv6 PI assignment within a period of six months should the unique routing requirements for the PI assignment no longer be met." 1. does this mean that the following question from RIPE-468 is no longer valid for routing? "% Is the End User requesting extra address space for routing and/or % administrative reasons? (Yes/No)" 2. Will this include the space not being routed at all? or does this require that the space be routed? Regards, Dave. ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net -----Original Message----- From: address-policy-wg-admin at ripe.net on behalf of Frederic Sent: Mon 6/8/2009 20:07 To: address-policy-wg at ripe.net Subject: [address-policy-wg] 2009-08 hi, we support this proposal. http://www.ripe.net/ripe/policies/proposals/2009-08.html bst regards. Frederic -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy at nosignal.org Mon Jun 8 23:09:39 2009 From: andy at nosignal.org (Andy Davidson) Date: Mon, 8 Jun 2009 22:09:39 +0100 Subject: [address-policy-wg] 2009-08 In-Reply-To: <7B8B0D6F623C3A40A0D0A80A66756E2B0D7BD6@EXVS01.claranet.local> References: <1244488072.3583.1.camel@kzinti.placenet.org> <7B8B0D6F623C3A40A0D0A80A66756E2B0D7BD6@EXVS01.claranet.local> Message-ID: <7F70E642-16BD-4CF7-AFC3-367EC4000A55@nosignal.org> Hi, David -- Thanks for your email. I am replying in capacity as author. On 8 Jun 2009, at 21:04, David Freedman wrote: > Can I just ask for clarification of the following: > > "the LIR must demonstrate the unique routing requirements for the PI > assignment." > and > "The LIR must return the IPv6 PI assignment within a period of six > months should the unique routing requirements for the PI assignment > no longer be met." > > 1. does this mean that the following question from RIPE-468 is no > longer valid for routing? > "% Is the End User requesting extra address space for routing and/or > % administrative reasons? (Yes/No)" > In my opinion it does not end the validity of this question, because - PI applications will come from non-LIRs as well as LIRs, where the policy is NOT changing. - PI applications from LIRs need to have 'yes' selected here. > 2. Will this include the space not being routed at all? or does this > require that the space be routed? > If your PA is routed on the internet, and your need some PI which will not be routed on the internet, then in my opinion there are two different routing policies for these subnets. Kind regards, Andy From info at streamservice.nl Tue Jun 9 02:45:07 2009 From: info at streamservice.nl (Stream Service) Date: Tue, 9 Jun 2009 02:45:07 +0200 Subject: [address-policy-wg] 2009-08 In-Reply-To: <7B8B0D6F623C3A40A0D0A80A66756E2B0D7BD6@EXVS01.claranet.local> References: <1244488072.3583.1.camel@kzinti.placenet.org> <7B8B0D6F623C3A40A0D0A80A66756E2B0D7BD6@EXVS01.claranet.local> Message-ID: <000601c9e89b$893b2760$9bb17620$@nl> Because of point 2 I don't support this proposal, if/when this point is removed I support this proposal. Some people don't want that RIPE is saying anything about routing policy, so it should also not look for this for returning IPv6/IPv4 IP assignments if you ask me. From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of David Freedman Sent: maandag 8 juni 2009 22:05 To: address-policy-wg at ripe.net Subject: RE: [address-policy-wg] 2009-08 Can I just ask for clarification of the following: "the LIR must demonstrate the unique routing requirements for the PI assignment." and "The LIR must return the IPv6 PI assignment within a period of six months should the unique routing requirements for the PI assignment no longer be met." 1. does this mean that the following question from RIPE-468 is no longer valid for routing? "% Is the End User requesting extra address space for routing and/or % administrative reasons? (Yes/No)" 2. Will this include the space not being routed at all? or does this require that the space be routed? Regards, Dave. ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net -----Original Message----- From: address-policy-wg-admin at ripe.net on behalf of Frederic Sent: Mon 6/8/2009 20:07 To: address-policy-wg at ripe.net Subject: [address-policy-wg] 2009-08 hi, we support this proposal. http://www.ripe.net/ripe/policies/proposals/2009-08.html bst regards. Frederic -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marcus.Gerdon at versatel.de Tue Jun 9 08:47:55 2009 From: Marcus.Gerdon at versatel.de (Marcus.Gerdon) Date: Tue, 9 Jun 2009 08:47:55 +0200 Subject: AW: [address-policy-wg] 2009-08 Message-ID: <227142482560EF458FF1F7E784E26AB898FE9C@FLBVEXCH01.versatel.local> I support this proposal as is. Where's the reason for treating LIR's different than end users in regards to 'validity of the assignment' and return of a resource? If routing reasons are the main criteria for assignment existing policies already define the return of the resource as soon as the reasons become invalid. Or did I miss something? kind regards, Marcus ---------------------------------------------------------------------------------------- Engineering IP Services Versatel West GmbH Unterste-Wilms-Strasse 29 D-44143 Dortmund Fon: +49-(0)231-399-4486 | Fax: +49-(0)231-399-4491 marcus.gerdon at versatel.de | www.versatel.de Sitz der Gesellschaft: Dortmund | Registergericht: Dortmund HRB 21738 Gesch?ftsf?hrer: Marc L?tzenkirchen, Dr. Hai Cheng, Dr. Max Padberg, Peter Schindler ---------------------------------------------------------------------------------------- AS8881 / AS8638 / AS13270 | MG3031-RIPE ---------------------------------------------------------------------------------------- ________________________________ Von: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] Im Auftrag von Stream Service Gesendet: Dienstag, 9. Juni 2009 02:45 An: address-policy-wg at ripe.net Betreff: RE: [address-policy-wg] 2009-08 Because of point 2 I don't support this proposal, if/when this point is removed I support this proposal. Some people don't want that RIPE is saying anything about routing policy, so it should also not look for this for returning IPv6/IPv4 IP assignments if you ask me. From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of David Freedman Sent: maandag 8 juni 2009 22:05 To: address-policy-wg at ripe.net Subject: RE: [address-policy-wg] 2009-08 Can I just ask for clarification of the following: "the LIR must demonstrate the unique routing requirements for the PI assignment." and "The LIR must return the IPv6 PI assignment within a period of six months should the unique routing requirements for the PI assignment no longer be met." 1. does this mean that the following question from RIPE-468 is no longer valid for routing? "% Is the End User requesting extra address space for routing and/or % administrative reasons? (Yes/No)" 2. Will this include the space not being routed at all? or does this require that the space be routed? Regards, Dave. ------------------------------------------------ David Freedman Group Network Engineering Claranet Limited http://www.clara.net -----Original Message----- From: address-policy-wg-admin at ripe.net on behalf of Frederic Sent: Mon 6/8/2009 20:07 To: address-policy-wg at ripe.net Subject: [address-policy-wg] 2009-08 hi, we support this proposal. http://www.ripe.net/ripe/policies/proposals/2009-08.html bst regards. Frederic From ingrid at ripe.net Tue Jun 16 09:22:52 2009 From: ingrid at ripe.net (Ingrid Wijte) Date: Tue, 16 Jun 2009 09:22:52 +0200 Subject: [address-policy-wg] 2009-02 Last Call for Comments (Allocating/Assigning Resources to the RIPE NCC) Message-ID: <20090616072252.522CC2F5A0@herring.ripe.net> PDP Number: 2009-02 Allocating/Assigning Resources to the RIPE NCC Dear Colleagues, The proposal described in 2009-02 is now at its Concluding Phase. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2009-02.html Please e-mail any final comments about this proposal to address-policy-wg at ripe.net before 14 July 2009. Regards Ingrid Wijte Policy Development Officer RIPE NCC From nick at inex.ie Tue Jun 16 17:18:40 2009 From: nick at inex.ie (Nick Hilliard) Date: Tue, 16 Jun 2009 16:18:40 +0100 Subject: [address-policy-wg] 2009-08 New Policy Proposal (IPv6 Provider Independent (PI) Assignments for LIRs) In-Reply-To: <20090603100953.1B26A2F595@herring.ripe.net> References: <20090603100953.1B26A2F595@herring.ripe.net> Message-ID: <4A37B7D0.5080300@inex.ie> On 03/06/2009 11:09, Ingrid Wijte wrote: > IPv6 Provider Independent (PI) Assignments for LIRs This policy proposal has merit, and is really a variety of the inherent aggregation "problem" which was "solved" in ipv6: namely that with ipv4, providers got smallish blocks of space which they could chop and dice in all sorts of flexible ways under the category of traffic engineering (because as we all know, deaggregation is bad and should be stamped out). With IPv6, the underlying assumption has been that /32 "should be enough for anyone". Indeed, for most people, it is - if you want to stick all your traffic engineering eggs in the one basket. But now that we're actually deploying IPv6 a little, it's becoming clearer that this is an operationally naive assumption to make. Turning it around slightly, the problem is an extension of the multihoming problem. We have no functional technical solution for this at the moment, other than to use the ipv4 bodge: namely multiple prefixes, each announced with an independent routing policy. So, really, the issue you're trying to solve here is probably not whether LIRs should be entitled to PI assignments (which is perhaps an interesting digression), but really how can LIRs engage in meaningful traffic engineering in the ipv6 world, and whether this should interact with address policy management. I sense a collision of policy and operations here. Nick From rendek at ripe.net Thu Jun 18 14:30:26 2009 From: rendek at ripe.net (Paul Rendek) Date: Thu, 18 Jun 2009 14:30:26 +0200 Subject: [address-policy-wg] IPv6 Deployment Monitoring Survey Now Underway! References: Message-ID: <32AA3A9A-2950-449F-8743-32EC789A7076@ripe.net> [Apologies for duplicates] Dear Colleagues, As announced at RIPE 58, TNO and GNKS Consult are working with the RIPE NCC to conduct a survey, sponsored by the European Commission, on the current and future use of IPv6 throughout the RIPE NCC service region. The IPv6 Deployment Monitoring Survey is now online, and we encourage all members of the RIPE community to participate: http://is-nri.com/take/?i=150597&h=1GwWe3dXXMcPrRrOw5s2yg The purpose of the survey is to better understand where the community is moving, and what can be done to ensure the Internet community is ready for the widespread adoption of IPv6. The survey was developed in consultation with members of the RIPE community, and is inspired by the 2008 survey conducted by ARIN and CAIDA in North America. It is sponsored by the European Commission, which has actively supported the adoption of IPv6, in the interests of innovation and the continuing competitiveness of European industry. We encourage all organisations in the RIPE NCC service region to participate in this survey, which we hope will establish a comprehensive view of present IPv6 penetration and future plans for IPv6 deployment. By making the survey design similar to the ARIN/CAIDA survey, we hope that the results will contribute to a better global picture of current and future IPv6 deployment. The survey is composed of 16 questions and can be completed in 10-15 minutes. For those without IPv6 allocations or assignments, or who have not yet deployed IPv6, the questions will be fewer in number. The survey will close on 3 July 2009. Results of the IPv6 Deployment Monitoring Survey will be presented and discussed at RIPE 59, which will be held 5-9 October in Lisbon, Portugal. Results will also be published on IPv6 Act Now: http://ipv6actnow.org Please provide your name and contact information on the survey form if you wish to receive the draft survey analysis when available. Please also indicate whether you are willing to share additional data with the TNO and GNKS Consult IPv6 Deployment Monitoring team. We appreciate your time and interest in completing this survey. If you have any questions concerning the survey, please send an email to . Regards, Paul Rendek Head of External Relations and Communications RIPE NCC From marc.blanchet at viagenie.ca Thu Jun 18 16:41:33 2009 From: marc.blanchet at viagenie.ca (Marc Blanchet) Date: Thu, 18 Jun 2009 10:41:33 -0400 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 Deployment Monitoring Survey Now Underway! In-Reply-To: <32AA3A9A-2950-449F-8743-32EC789A7076@ripe.net> References: <32AA3A9A-2950-449F-8743-32EC789A7076@ripe.net> Message-ID: <4A3A521D.9090805@viagenie.ca> I don't want to start a thread on the survey details, but I found one question missing an important choice. The question is: What are likely to be the biggest hurdle(s) when deploying IPv6? Our biggest hurdle (and I'm sure we are not the only ones) is "Upstream ISP not offering IPv6 transit". Currently, I have to write into the "other box". I really think that choice should be explicit to make the survey more precise on hurdles people feel. my 2 cents cdn... Marc. Paul Rendek a ?crit : > [Apologies for duplicates] > > > Dear Colleagues, > > As announced at RIPE 58, TNO and GNKS Consult are working with the RIPE > NCC to conduct a survey, sponsored by the European Commission, on the > current and future use of IPv6 throughout the RIPE NCC service region. > > The IPv6 Deployment Monitoring Survey is now online, and we encourage > all members of the RIPE community to participate: > http://is-nri.com/take/?i=150597&h=1GwWe3dXXMcPrRrOw5s2yg > > The purpose of the survey is to better understand where the community is > moving, and what can be done to ensure the Internet community is ready > for the widespread adoption of IPv6. The survey was developed in > consultation with members of the RIPE community, and is inspired by the > 2008 survey conducted by ARIN and CAIDA in North America. It is > sponsored by the European Commission, which has actively supported the > adoption of IPv6, in the interests of innovation and the continuing > competitiveness of European industry. > > We encourage all organisations in the RIPE NCC service region to > participate in this survey, which we hope will establish a comprehensive > view of present IPv6 penetration and future plans for IPv6 deployment. > By making the survey design similar to the ARIN/CAIDA survey, we hope > that the results will contribute to a better global picture of current > and future IPv6 deployment. > > The survey is composed of 16 questions and can be completed in 10-15 > minutes. For those without IPv6 allocations or assignments, or who have > not yet deployed IPv6, the questions will be fewer in number. > > The survey will close on 3 July 2009. > > Results of the IPv6 Deployment Monitoring Survey will be presented and > discussed at RIPE 59, which will be held 5-9 October in Lisbon, > Portugal. Results will also be published on IPv6 Act Now: > http://ipv6actnow.org > > Please provide your name and contact information on the survey form if > you wish to receive the draft survey analysis when available. Please > also indicate whether you are willing to share additional data with the > TNO and GNKS Consult IPv6 Deployment Monitoring team. > > We appreciate your time and interest in completing this survey. If you > have any questions concerning the survey, please send an email to > . > > > Regards, > > Paul Rendek > Head of External Relations and Communications > RIPE NCC -- ========= IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca DTN news service: http://reeves.viagenie.ca From patrik at frobbit.se Thu Jun 18 19:27:02 2009 From: patrik at frobbit.se (=?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?=) Date: Thu, 18 Jun 2009 19:27:02 +0200 Subject: [address-policy-wg] Re: [ipv6-wg] IPv6 Deployment Monitoring Survey Now Underway! In-Reply-To: <4A3A521D.9090805@viagenie.ca> References: <32AA3A9A-2950-449F-8743-32EC789A7076@ripe.net> <4A3A521D.9090805@viagenie.ca> Message-ID: There was also no alternative on "what kind of organisation are you" that is a hosting/dns/registrar service. Only ISP. If I am not selling IP packets, what to select? There was also only "selling transit" and "peering" (or similar). I am buying transit.., which connect me with the issue Marc bring up. Patrik On 18 jun 2009, at 16.41, Marc Blanchet wrote: > I don't want to start a thread on the survey details, but I found one > question missing an important choice. The question is: > > What are likely to be the biggest hurdle(s) when deploying IPv6? > > Our biggest hurdle (and I'm sure we are not the only ones) is > "Upstream > ISP not offering IPv6 transit". Currently, I have to write into the > "other box". I really think that choice should be explicit to make the > survey more precise on hurdles people feel. > > my 2 cents cdn... > > Marc. > > Paul Rendek a ?crit : >> [Apologies for duplicates] >> >> >> Dear Colleagues, >> >> As announced at RIPE 58, TNO and GNKS Consult are working with the >> RIPE >> NCC to conduct a survey, sponsored by the European Commission, on the >> current and future use of IPv6 throughout the RIPE NCC service >> region. >> >> The IPv6 Deployment Monitoring Survey is now online, and we encourage >> all members of the RIPE community to participate: >> http://is-nri.com/take/?i=150597&h=1GwWe3dXXMcPrRrOw5s2yg >> >> The purpose of the survey is to better understand where the >> community is >> moving, and what can be done to ensure the Internet community is >> ready >> for the widespread adoption of IPv6. The survey was developed in >> consultation with members of the RIPE community, and is inspired by >> the >> 2008 survey conducted by ARIN and CAIDA in North America. It is >> sponsored by the European Commission, which has actively supported >> the >> adoption of IPv6, in the interests of innovation and the continuing >> competitiveness of European industry. >> >> We encourage all organisations in the RIPE NCC service region to >> participate in this survey, which we hope will establish a >> comprehensive >> view of present IPv6 penetration and future plans for IPv6 >> deployment. >> By making the survey design similar to the ARIN/CAIDA survey, we hope >> that the results will contribute to a better global picture of >> current >> and future IPv6 deployment. >> >> The survey is composed of 16 questions and can be completed in 10-15 >> minutes. For those without IPv6 allocations or assignments, or who >> have >> not yet deployed IPv6, the questions will be fewer in number. >> >> The survey will close on 3 July 2009. >> >> Results of the IPv6 Deployment Monitoring Survey will be presented >> and >> discussed at RIPE 59, which will be held 5-9 October in Lisbon, >> Portugal. Results will also be published on IPv6 Act Now: >> http://ipv6actnow.org >> >> Please provide your name and contact information on the survey form >> if >> you wish to receive the draft survey analysis when available. Please >> also indicate whether you are willing to share additional data with >> the >> TNO and GNKS Consult IPv6 Deployment Monitoring team. >> >> We appreciate your time and interest in completing this survey. If >> you >> have any questions concerning the survey, please send an email to >> . >> >> >> Regards, >> >> Paul Rendek >> Head of External Relations and Communications >> RIPE NCC > > > -- > ========= > IPv6 book: Migrating to IPv6, Wiley. http://www.ipv6book.ca > Stun/Turn server for VoIP NAT-FW traversal: http://numb.viagenie.ca > DTN news service: http://reeves.viagenie.ca > > From fweimer at bfk.de Mon Jun 22 10:27:52 2009 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 22 Jun 2009 10:27:52 +0200 Subject: [address-policy-wg] 2008-05 Anycast for DLV zones In-Reply-To: (Jim Reid's message of "Wed\, 22 Apr 2009 12\:42\:01 +0100") References: <20090326130519.868942F583@herring.ripe.net> <823ac1jgge.fsf@mid.bfk.de> <824owhhrth.fsf@mid.bfk.de> Message-ID: <82hby84qrb.fsf@mid.bfk.de> * Jim Reid: >> Which part of the Internet depends on it? > > See above. Pretty much anything doing lookups in e164.arpa: Asterisk > servers, various other SIP services, VoIP providers, smartphones, etc. > ENUM may have a low usage. But unlike DLV, ENUM is not just for > consenting adults: everything and anything can do an ENUM lookup > straight out of the box. I don't think this is how things work. For sure, ENUM isn't enabled by default on many devices. Otherwise, a sizeable fraction of all calls to +1 numbers leaked to the e164.arpa server operators. This doesn't seem to be the case. Unfortunately, RIPE doesn't publish absolute query numbers, so it's impossible to even approximate how much ENUM usage there is out there. (Note that due to the way DNS works, the e164.arpa server operators see full phone numbers for non-delegated subtrees, and resolvers can't learn that a whole subtree does not exist, so negative caching only helps if the same phone number is called twice within the negative caching interval.) > This is not the case for DLV because DNSSEC- aware validators -- a > miniscule percentage of the world's resolving servers -- have to be > specially configured, DLV policies need to be defined, key mangament > issues have to be worked out, etc, etc. ENUM has to be specifically enabled by the end user, too. I would go as far to say that a German operator which ships a smartphone which performs ENUM lookups (perhaps indirectly) via e164.arpa has a very, very hard time fulfilling its obligations under ?88, 109 TKG. > Well I know there are paying customers and commercial services > dependent on ENUM in Austria, Romania and the UK. I expect this is > also true other countries: I can't be bothered to look. FYI the > Austrian regulator has set aside a block of their number space for > ENUM-only telephony. On the other hand, DENIC has been reporting for several years that demand for ENUM is below expectations, despite continuous marketing efforts. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From jim at rfc1035.com Mon Jun 22 12:35:49 2009 From: jim at rfc1035.com (Jim Reid) Date: Mon, 22 Jun 2009 11:35:49 +0100 Subject: [address-policy-wg] 2008-05 Anycast for DLV zones In-Reply-To: <82hby84qrb.fsf@mid.bfk.de> References: <20090326130519.868942F583@herring.ripe.net> <823ac1jgge.fsf@mid.bfk.de> <824owhhrth.fsf@mid.bfk.de> <82hby84qrb.fsf@mid.bfk.de> Message-ID: On 22 Jun 2009, at 09:27, Florian Weimer wrote: >>> Which part of the Internet depends on it? >> >> See above. Pretty much anything doing lookups in e164.arpa: Asterisk >> servers, various other SIP services, VoIP providers, smartphones, >> etc. >> ENUM may have a low usage. But unlike DLV, ENUM is not just for >> consenting adults: everything and anything can do an ENUM lookup >> straight out of the box. > > I don't think this is how things work. It is. Compare and contrast the effort needed to setup DLV (and make it work) on a DNS server with that needed for an ENUM lookup. Now do the same thing for on-going maintenance and administration of both technologies. Why this discussion has popped up in address-policy-wg and not dns-wg is "interesting".... Anyway, I fail to see what point you're making or what relevance it has. Please don't bother to do that now: I'm long past caring. FWIW any clarifications you provide probably shouldn't go to this list. Discussions about ENUM query rates are best taken to the ENUM WG or maybe the DNS WG. There's a consensus here to have anycast allocations for Tier-1 ENUM delegations. It's not clear whether you agree or disagree with that. You've never said either way: at least not that I remember. Instead, you've tried to open up a rat-hole about making DLV a special case. When you suggested DLV zones deserved anycast allocations, nobody on this list appears to have been in favour of that. IIRC few people explained why DLV zones did not merit these allocations. At least not at present. That looks to be the consensus position, not that I speak for this list/WG of course. I also note that although you seem keen to open up and explore rat- holes, you're not coming forward with anything constructive: eg amended text for a policy proposal or even new drafts in support of your point of view. This is not productive. I strongly suggest you end this discussion -- what have DNS query rates under e164.arpa got to do with address allocation? -- or take it somewhere else. It's no longer relevant or appropriate for address-policy-wg at ripe.net. To summarise, the recent updates to the NCC's address policy allow for anycast allocations to be made for "important" DNS zones: TLDs and Tier-1 ENUM delegations. These are considered to be critical infrastructure (for some definition of that term), not just by the technical community but by governments and regulators. It is therefore responsible and prudent for the NCC to have an addressing policy that facilitates a technology (anycasting) which can improve the robustness and stability of those important DNS zones. DLV is not considered as important by these communities. At least not yet. If and when DLV gets that recognition, or appears to be getting it, that will be the time for amending the address policy to accommodate anycast for DLV. This of course does not stop someone like ISC using a chunk of their existing address space to provide anycast service for dlv.isc.org (or whatever). IMO, it's up to the DLV cheerleaders to make the case that their zones are "important" enough to deserve special anycast allocations. That case has still to be made. From fweimer at bfk.de Mon Jun 22 13:11:12 2009 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 22 Jun 2009 13:11:12 +0200 Subject: [address-policy-wg] 2008-05 Anycast for DLV zones In-Reply-To: (Jim Reid's message of "Mon\, 22 Jun 2009 11\:35\:49 +0100") References: <20090326130519.868942F583@herring.ripe.net> <823ac1jgge.fsf@mid.bfk.de> <824owhhrth.fsf@mid.bfk.de> <82hby84qrb.fsf@mid.bfk.de> Message-ID: <82fxds34mn.fsf@mid.bfk.de> * Jim Reid: > It is. Compare and contrast the effort needed to setup DLV (and make > it work) on a DNS server with that needed for an ENUM lookup. Now do > the same thing for on-going maintenance and administration of both > technologies. Why this discussion has popped up in address-policy-wg > and not dns-wg is "interesting".... You claimed that ENUM is a critical service and therefore deserves special treatment as far as addressing policy is concerned. I think this is just wishful thinking. ENUM (in the public e164.arpa tree) hasn't got a significant user base. Certainly, it's not critical Internet infrastructure, and so it doesn't need special treatment for address allocation. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From michael.dillon at bt.com Mon Jun 22 13:20:00 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 22 Jun 2009 12:20:00 +0100 Subject: [address-policy-wg] 2008-05 Anycast for DLV zones In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C49745801C7564D@E03MVZ2-UKDY.domain1.systemhost.net> > This of > course does not stop someone like ISC using a chunk of their > existing address space to provide anycast service for > dlv.isc.org (or whatever). IMO, it's up to the DLV > cheerleaders to make the case that their zones are > "important" enough to deserve special anycast allocations. Your example is essentially saying there is no barrier for a holder of an anycast address block, to offer more than one anycast service from that block. I think that address policy should be addressing that general case of an anycast network services provider rather than dealing with various special cases of applications that require anycast network services. --Michael Dillon From mohta at necom830.hpcl.titech.ac.jp Mon Jun 22 14:08:07 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 22 Jun 2009 21:08:07 +0900 Subject: [address-policy-wg] 2008-05 Anycast for DLV zones In-Reply-To: <82fxds34mn.fsf@mid.bfk.de> References: <20090326130519.868942F583@herring.ripe.net> <823ac1jgge.fsf@mid.bfk.de> <824owhhrth.fsf@mid.bfk.de> <82hby84qrb.fsf@mid.bfk.de> <82fxds34mn.fsf@mid.bfk.de> Message-ID: <4A3F7427.8060300@necom830.hpcl.titech.ac.jp> Florian Weimer wrote: > I think this is just wishful thinking. ENUM (in the public e164.arpa > tree) hasn't got a significant user base. FYI, ENUM concept to let callee side, who won't pay calling fee, determine the internet-PSTN gateway is broken from the beginning. Telcos managing telephone numbers of callees will, as a default gateways of callees, choose the most profitable (which is likely to be unnecessarily expensive to callers) gateway for the telcos and callees will be uninterested in the choice. ENUM could be fixed, if access telcos only are allowed to be delegated ENUM records and the telcos are forced to have gateways from which all subscribers of the telco can be reached at least expensive rate. Still, ENUM is not a very interesting concept. > Certainly, it's not > critical Internet infrastructure, and so it doesn't need special > treatment for address allocation. True. Just as PSTN does not need public IP addresses, the Internet does not need E.164 addresses. Masataka Ohta From jim at rfc1035.com Mon Jun 22 14:38:22 2009 From: jim at rfc1035.com (Jim Reid) Date: Mon, 22 Jun 2009 13:38:22 +0100 Subject: [address-policy-wg] Anycasting for TLDs and ENUM In-Reply-To: <28E139F46D45AF49A31950F88C49745801C7564D@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745801C7564D@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: On 22 Jun 2009, at 12:20, wrote: > Your example is essentially saying there is no barrier for > a holder of an anycast address block, to offer more than one > anycast service from that block. Hmm. What you really seem to be saying here is there is no barrier for a holder of an address block to offer more than one service from that block. That principle should not come as a surprise. :-) To get back to the anycast allocation provisions, the new policy says these allocations are for DNS service for TLDs and ENUM Tier-1 delegations. So if the holders of these blocks used them for other things, they'd presumably be in violation of that policy. > I think that address policy should be addressing that general > case of an anycast network services provider rather than dealing > with various special cases of applications that require anycast > network services. I tend to sympathise with that view. However the current policy only concerns itself with anycast allocations for "important" DNS zones. Let's see how that works out in practice before considering how or if the policy should be extended. [My guess is the IPv4 shelves will be bare before we reach that point.] I'm also a bit concerned that a more liberal approach to anycasting allocations would be easy to game once the land-grab for the last chunks of IPv4 space kicks in. From mohta at necom830.hpcl.titech.ac.jp Mon Jun 22 14:52:20 2009 From: mohta at necom830.hpcl.titech.ac.jp (Masataka Ohta) Date: Mon, 22 Jun 2009 21:52:20 +0900 Subject: [address-policy-wg] Anycasting for TLDs and ENUM In-Reply-To: References: <28E139F46D45AF49A31950F88C49745801C7564D@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4A3F7E84.4010601@necom830.hpcl.titech.ac.jp> Jim Reid wrote: > To get back to the anycast allocation provisions, the new policy says > these allocations are for DNS service for TLDs and ENUM Tier-1 > delegations. So if the holders of these blocks used them for other > things, they'd presumably be in violation of that policy. For essential services, it's fine to allocate an entire /24 or /16 for an anycast address that there is no point to have address blocks for multiple anycast addresses. Masataka Ohta From sander at steffann.nl Mon Jun 22 17:41:47 2009 From: sander at steffann.nl (Sander Steffann) Date: Mon, 22 Jun 2009 17:41:47 +0200 Subject: [address-policy-wg] The final /8 policy proposals (2008-06 and 2009-04) Message-ID: <15DCEA7A-C02E-4E88-865B-DA1B2E3E0D66@steffann.nl> Hello WG, As many of you know there are two policy proposals that describe how the final /8 from IANA should be used. These are policy proposals 2008-06 and 2009-04. There are a lot of differences between those two proposals, and it is not really possible to have them both at the same time. That means that this working group has to decide which way to go. Because there are so many differences I want to focus the discussion on a specific question at this point in time: "Do we (this working group) want to put IPv6 related requirements in the policy?" The current proposals have the following IPv6 related requirements: - Proposal 2009-04 requires the LIR to meet the requirements of the Preparation (1st request) or Transition (subsequent requests) phase of the transition plan specified in RFC 5211. - Proposal 2008-06 does not define any IPv6 requirements for an LIR. I can see the benefit (stimulate native IPv6 deployment) of such requirements, but I can also see downsides (for example organisations that need IPv4 space but can't implement IPv6 for some reason). Do organisations that don't implement IPv6 cause a problem for the community (and do we need policy to prevent that), or do they only cause problems for themselves (and should we only limit the amount of IPv4 space they can get)? When discussion possible requirements we must remember that the RIPE NCC IP Resource Analysts (formerly known as Hostmasters) should be able to check those requirements when evaluating a request. We should also look at possible loopholes. I don't think we want an LIR to give IPv6 access to a handful of customers just to be able to get another big block of IPv4 space. Once we have discussed this basic issue I'll steer the discussion back to the other differences between the proposals. Please keep the discussion on this topic for now. Thank you, Sander Steffann APWG co-chair From info at streamservice.nl Mon Jun 22 17:49:20 2009 From: info at streamservice.nl (Stream Service) Date: Mon, 22 Jun 2009 17:49:20 +0200 Subject: [address-policy-wg] The final /8 policy proposals (2008-06 and 2009-04) In-Reply-To: <15DCEA7A-C02E-4E88-865B-DA1B2E3E0D66@steffann.nl> References: <15DCEA7A-C02E-4E88-865B-DA1B2E3E0D66@steffann.nl> Message-ID: <009b01c9f351$01b37b10$051a7130$@nl> Hello Sander, In my opinion there should be NO relation between IPv4 and IPv6 policy. If someone doesn't want to use IPv6? No problem: they'll be unreachable in the future. With kind regards, Mark Scholten -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Sander Steffann Sent: maandag 22 juni 2009 17:42 To: Address Policy Working Group Subject: [address-policy-wg] The final /8 policy proposals (2008-06 and 2009-04) Hello WG, As many of you know there are two policy proposals that describe how the final /8 from IANA should be used. These are policy proposals 2008-06 and 2009-04. There are a lot of differences between those two proposals, and it is not really possible to have them both at the same time. That means that this working group has to decide which way to go. Because there are so many differences I want to focus the discussion on a specific question at this point in time: "Do we (this working group) want to put IPv6 related requirements in the policy?" The current proposals have the following IPv6 related requirements: - Proposal 2009-04 requires the LIR to meet the requirements of the Preparation (1st request) or Transition (subsequent requests) phase of the transition plan specified in RFC 5211. - Proposal 2008-06 does not define any IPv6 requirements for an LIR. I can see the benefit (stimulate native IPv6 deployment) of such requirements, but I can also see downsides (for example organisations that need IPv4 space but can't implement IPv6 for some reason). Do organisations that don't implement IPv6 cause a problem for the community (and do we need policy to prevent that), or do they only cause problems for themselves (and should we only limit the amount of IPv4 space they can get)? When discussion possible requirements we must remember that the RIPE NCC IP Resource Analysts (formerly known as Hostmasters) should be able to check those requirements when evaluating a request. We should also look at possible loopholes. I don't think we want an LIR to give IPv6 access to a handful of customers just to be able to get another big block of IPv4 space. Once we have discussed this basic issue I'll steer the discussion back to the other differences between the proposals. Please keep the discussion on this topic for now. Thank you, Sander Steffann APWG co-chair From michael.dillon at bt.com Mon Jun 22 18:30:10 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 22 Jun 2009 17:30:10 +0100 Subject: [address-policy-wg] The final /8 policy proposals (2008-06 and 2009-04) In-Reply-To: <15DCEA7A-C02E-4E88-865B-DA1B2E3E0D66@steffann.nl> Message-ID: <28E139F46D45AF49A31950F88C49745801C75D80@E03MVZ2-UKDY.domain1.systemhost.net> > Because there are so many differences I want to focus the > discussion on a specific question at this point in time: "Do > we (this working group) want to put IPv6 related requirements > in the policy?" No. It would be wrong to favour the foresighted organizations who are deploying IPv6 because they are already in a stronger position since they have IPv6 in production or in test mode. > I can see the benefit (stimulate native IPv6 deployment) of > such requirements, but I can also see downsides (for example > organisations that need IPv4 space but can't implement IPv6 > for some reason). I haven't seen evidence that this kind of thing will stimulate IPv6 deployment. The decision makers responsible for approving investment in IPv6, are not likely to take note of the details of RIPE policy. The only thing that really matters at that level is that IPv4 will runout, and that runout is projected to happen as early as two years from now. Adding more details just muddies the waters of that clear message, and would hurt IPv6 deployment more than helping it. > Do organisations that don't implement IPv6 cause a problem > for the community (and do we need policy to prevent that), or > do they only cause problems for themselves (and should we > only limit the amount of IPv4 space they can get)? Yes, they cause a problem for the Internet community, but also for themselves because they will likely go out of business. Every few years there are circumstances in an industry that cause the stronger companies to take over the business of the weaker ones by some means or other. IPv6 deployment readiness is likely to be an important factor in this over the next few years, but RIPE is not responsible to do anything about it, just as it was not RIPE's responsibility to do anything about the telecoms collapse at the turn of the century. --Michael Dillon From ingrid at ripe.net Tue Jun 23 13:10:27 2009 From: ingrid at ripe.net (Ingrid Wijte) Date: Tue, 23 Jun 2009 13:10:27 +0200 Subject: [address-policy-wg] 2008-05 Proposal Accepted (Anycasting Assignments for TLDs and Tier 0/1 ENUM) Message-ID: <20090623111027.07AC92F583@herring.ripe.net> PDP Number: 2008-05 Anycasting Assignments for TLDs and Tier 0/1 ENUM Dear Colleagues Consensus has been reached, and the proposal described in 2008-05 has been accepted by the RIPE community. The related RIPE policy documents have now been updated, published and can be found at: IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region: http://www.ripe.net/ripe/docs/ripe-471.html and IPv6 Address Allocation and Assignment Policy: http://www.ripe.net/ripe/docs/ripe-472.html The proposal is now archived and can be found at: http://www.ripe.net/ripe/policies/proposals/2008-05.html The RIPE NCC will implement this new policy within one month. Thank you for your input. Regards Ingrid Wijte Policy Development Officer RIPE NCC From randy at psg.com Tue Jun 23 15:40:32 2009 From: randy at psg.com (Randy Bush) Date: Tue, 23 Jun 2009 06:40:32 -0700 Subject: [address-policy-wg] The final /8 policy proposals (2008-06 and 2009-04) In-Reply-To: <15DCEA7A-C02E-4E88-865B-DA1B2E3E0D66@steffann.nl> References: <15DCEA7A-C02E-4E88-865B-DA1B2E3E0D66@steffann.nl> Message-ID: > "Do we (this working group) want to put IPv6 related requirements in > the policy?" no. our expertise is technical engineering and not social engineering. if we were good at the latter, ipv6 would long be deployed. randy From brian.nisbet at heanet.ie Tue Jun 23 17:14:54 2009 From: brian.nisbet at heanet.ie (Brian Nisbet) Date: Tue, 23 Jun 2009 16:14:54 +0100 Subject: [address-policy-wg] The final /8 policy proposals (2008-06 and 2009-04) In-Reply-To: <15DCEA7A-C02E-4E88-865B-DA1B2E3E0D66@steffann.nl> References: <15DCEA7A-C02E-4E88-865B-DA1B2E3E0D66@steffann.nl> Message-ID: <4A40F16E.5080901@heanet.ie> Sander Steffann wrote the following on 22/06/2009 16:41: > > Do organisations that don't implement IPv6 cause a problem for the > community (and do we need policy to prevent that), or do they only cause > problems for themselves (and should we only limit the amount of IPv4 space > they can get)? Arguably yes, they cause a problem for the community, but I think that forcing v6 deployment via policy is both wrong and doomed to failure. > We should also look at possible loopholes. I don't think we want an LIR > to give IPv6 access to a handful of customers just to be able to get > another big block of IPv4 space. And this is a point also. There is nothing stopping someone from asking for a v4 allocation along with a v6 allocation and then doing nothing with the v6 allocation. It's not like reclaiming the v4 allocation will be easy. > Once we have discussed this basic issue I'll steer the discussion back to > the other differences between the proposals. Please keep the discussion > on this topic for now. I realise I'm repeating points here to a certain extent but I feel they're worth making. As with the others I do believe that, in the long run, the cost of not deploying IPv6 will be your business. We need to develop policy that will divide the remaining IPv4 resources in the fairest way possible and shackling the two together will not, imo, produce that fairness. Brian. From ncc at ripe.net Tue Jun 30 15:44:55 2009 From: ncc at ripe.net (Paul Rendek) Date: Tue, 30 Jun 2009 15:44:55 +0200 Subject: [address-policy-wg] IPv6 Deployment Monitoring Survey Reminder Message-ID: <195025B6-655A-40AD-A049-BEDA0E4B3D6D@ripe.net> [Apologies for duplicates] Dear Colleagues, This is a reminder that the IPv6 Deployment Monitoring Survey is online, and we encourage all members of the RIPE community to participate. The final date for submitting a response is Friday, 3 July 2009. You can access the survey at: http://is-nri.com/take/?i=150597&h=1GwWe3dXXMcPrRrOw5s2yg The survey is being conducted by TNO and GNKS Consult, working with the RIPE NCC and sponsored by the European Commission. The aim of the survey is to collect data on the current and future use of IPv6 throughout the RIPE NCC service region. The survey is composed of 16 questions and can be completed in 10-15 minutes. Results will be presented and discussed at RIPE 59 and published on IPv6 Act Now: http://ipv6actnow.org For more information on the IPv6 Deployment Monitoring Survey, please see: http://www.ripe.net/news/ipv6-deployment-monitoring-survey.html We appreciate your time and interest in completing this survey. If you have any questions concerning the survey, please send an email to . Regards, Paul Rendek Head of External Relations and Communications RIPE NCC