From kolesik at nask.pl Tue Nov 4 14:30:42 2008 From: kolesik at nask.pl (Krzysztof Olesik) Date: Tue, 04 Nov 2008 14:30:42 +0100 Subject: [address-policy-wg] Assignments for Critical Infrastruction Message-ID: <49104E82.1020403@nask.pl> Hello, > We would like to see policy for IPv4 and IPv6 modified > to allow /24 *minimum* for IPv4 and /48 *minimum* to > gTLD/ccTLD. > > First reason behind this is that one PI is not really > enough and it's blocking us to deploy more DNS servers > and make our TLD service more reliable. > > Second reason is that if we deploy more Anycasted DNS > servers we could keep (or drop down) number of NS records > for TLD, so we could manage to keep DNS reply size low > even with DNSSEC. As for .pl, we support the idea. In the future we would like to have another anycast cloud run in co-operation with other ccTLD. Best regards, Krzysztof Olesik NASK From sander at steffann.nl Mon Nov 10 16:40:42 2008 From: sander at steffann.nl (Sander Steffann) Date: Mon, 10 Nov 2008 16:40:42 +0100 Subject: [address-policy-wg] Policy proposal 2007-08 will go to Last Call Message-ID: <491855FA.2040603@steffann.nl> The RIPE Address Policy Working Group chairs have decided to move policy proposal 2007-08 to Last Call. This policy proposal has been discussed on the mailing list since 23 October 2007. Version 2 of this proposal was published on 18 March 2008, and version 3 has been published on 18 September 2008. In the last review phase version 3 of this proposal was discussed. Each version used the feedback on the previous version from the community. Most of the objections to version 2 of the proposal have been handled in version 3. There were three remaining objections after version 3 was published: 1) This policy will give IPv4 addresses financial value This subject has been discussed on the mailing list. The feeling was that IPv4 addresses already have financial value, but there was no proof for this. Remco van Mook has demonstrated that there are organizations that will pay money for IPv4 addresses, which proves that the financial value already exists. 2) There will be no market for IPv4 address In the same presentation Remco van Mook has shown that there are currently both sellers and buyers for IPv4 addresses, which proves the existence of such a market. 3) Reclaim/reuse is more efficient than transfering Alex Le Heux from RIPE NCC has provided statistics on the amount of IPv4 addresses that have been reclaimed. These statistics show that the amount of addresses that are effectively reclaimed (instead of returned to the NCC in exchange for a bigger allocation) is negligible. The current version of this proposal is version 4, which only has a minor change to close a potential loophole in version 3: "An LIR may only receive a transferred allocation after their need is evaluated by the RIPE NCC" is changed to "An LIR may only receive a transferred allocation after their need is evaluated and approved by the RIPE NCC". Because the change is so small, we have chosen not to go to the Review phase again. Because all objections to this proposal have been handled and because of the strong support that has been shown we feel confident that we can declare consensus and move this proposal to Last Call. Sander Steffann Address Policy Working Group co-chair From anamatic at ripe.net Mon Nov 10 17:05:33 2008 From: anamatic at ripe.net (Ana Matic) Date: Mon, 10 Nov 2008 17:05:33 +0100 Subject: [address-policy-wg] 2007-08 Last Call for Comments (Enabling Methods for Reallocation of IPv4 Resources) Message-ID: <20081110160535.CD3732F583@herring.ripe.net> PDP Number: 2007-08 Enabling Methods for Reallocation of IPv4 Resources Dear Colleagues, The proposal described in 2007-08 (version 4.0) is now at its Concluding Phase. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2007-08.html Please e-mail any final comments about this proposal to address-policy-wg at ripe.net before 08 December 2008. Regards, Ana Matic RIPE NCC From brettlists at gmail.com Mon Nov 17 14:59:11 2008 From: brettlists at gmail.com (B C) Date: Mon, 17 Nov 2008 13:59:11 +0000 Subject: [address-policy-wg] Assignments for Critical Infrastruction In-Reply-To: References: Message-ID: <5c494b510811170559w34f5990bgb0971cc054f9e308@mail.gmail.com> Ondrej, in the light of the comments on my proposal for ENUM anycast assignments discussed in Dubai, I was planning to write a revised policy proposal to go through PDP, I will be taking action on this as soon as the minutes/webcast from Dubai are available. I think it's safe to say we are working towards the same/similar goal and I think it's important that we don't both do the same work. I will have a first draft of my proposal here in the next couple of weeks. Regards Brett Carr Nominet UK On Tue, Oct 28, 2008 at 10:48 AM, Ond?ej Sur? wrote: > Hello everybody, > > I would like to post unformal proposal before writing > official policy modification proposal (and/or having > discussion tomorrow on Open Hour). > > We would like to see policy for IPv4 and IPv6 modified > to allow /24 *minimum* for IPv4 and /48 *minimum* to > gTLD/ccTLD. > > First reason behind this is that one PI is not really > enough and it's blocking us to deploy more DNS servers > and make our TLD service more reliable. > > Second reason is that if we deploy more Anycasted DNS > servers we could keep (or drop down) number of NS records > for TLD, so we could manage to keep DNS reply size low > even with DNSSEC. > > And last, but not least, it would be good to keep this > synchronized with other regions (see [1],[2]). Note: > we may also extend the list of requestors to: > Root DNS, ccTLD, gTLD, IANA, RIRs. > Which I think is reasonable list. > > 1. http://www.nro.net/documents/comp-pol.html#2-4-2 > 2. http://www.nro.net/documents/comp-pol.html#3-4-1 > > If there is at least some consensus, I am willing to > write official policy change proposal. > > Ondrej > -- > Ond?ej Sur? > technick? ?editel/Chief Technical Officer > ----------------------------------------- > CZ.NIC, z.s.p.o. -- .cz domain registry > Americk? 23,120 00 Praha 2,Czech Republic > mailto:ondrej.sury at nic.cz http://nic.cz/ > sip:ondrej.sury at nic.cz tel:+420.222745110 > mob:+420.739013699 fax:+420.222745112 > ----------------------------------------- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgp2 at linuxadmin.org Mon Nov 17 15:55:22 2008 From: bgp2 at linuxadmin.org (Greg L.) Date: Mon, 17 Nov 2008 16:55:22 +0200 Subject: [address-policy-wg] Assignments for Critical Infrastruction In-Reply-To: <5c494b510811170559w34f5990bgb0971cc054f9e308@mail.gmail.co m> References: <5c494b510811170559w34f5990bgb0971cc054f9e308@mail.gmail.com> Message-ID: <6.1.2.0.2.20081117164428.02ddfb58@66.36.228.26> Current IPv4 already provides more advantage to ccTLD and gTLD with IPv4 /24 prefix allocations for BGP anycast than for other business entities that would like to get /24 prefix for BGP anycast DNS deployments. I don't see a reason why more resources should be allocated to a specific group/entities named under "Critical infrastructure" category that still compete with businesses that are unable to get /24 BGP anycast assignment for DNS solutions from Ripe. This is not fair (it was a bit fair when gTLD and ccTLD started out 5+ years ago). This is why many European companies prefer Arin's IP space. Welcome to Arin! At 18:09 2008.11.17.t C?', you wrote: >Ondrej, > in the light of the comments on my proposal for ENUM anycast > assignments discussed in Dubai, I was planning to write a revised policy > proposal to go through PDP, I will be taking action on this as soon as > the minutes/webcast from Dubai are available. I think it's safe to say we > are working towards the same/similar goal and I think it's important that > we don't both do the same work. I will have a first draft of my proposal > here in the next couple of weeks. > >Regards > >Brett Carr > >Nominet UK > > >On Tue, Oct 28, 2008 at 10:48 AM, Ond?ej Sur? ><ondrej.sury at nic.cz> wrote: >Hello everybody, > >I would like to post unformal proposal before writing >official policy modification proposal (and/or having >discussion tomorrow on Open Hour). > >We would like to see policy for IPv4 and IPv6 modified >to allow /24 *minimum* for IPv4 and /48 *minimum* to >gTLD/ccTLD. > >First reason behind this is that one PI is not really >enough and it's blocking us to deploy more DNS servers >and make our TLD service more reliable. > >Second reason is that if we deploy more Anycasted DNS >servers we could keep (or drop down) number of NS records >for TLD, so we could manage to keep DNS reply size low >even with DNSSEC. > >And last, but not least, it would be good to keep this >synchronized with other regions (see [1],[2]). Note: >we may also extend the list of requestors to: >Root DNS, ccTLD, gTLD, IANA, RIRs. >Which I think is reasonable list. > >1. >http://www.nro.net/documents/comp-pol.html#2-4-2 >2. http://www.nro.net/documents/comp-pol.html#3-4-1 > >If there is at least some consensus, I am willing to >write official policy change proposal. > >Ondrej >-- > Ond?ej Sur? > technick? ?editel/Chief Technical Officer > ----------------------------------------- > CZ.NIC, z.s.p.o. -- .cz domain registry > Americk? 23,120 00 Praha 2,Czech Republic > mailto:ondrej.sury at nic.cz http://nic.cz/ > sip:ondrej.sury at nic.cz tel:+420.222745110 > mob:+420.739013699 fax:+420.222745112 > ----------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brettlists at gmail.com Mon Nov 17 17:15:16 2008 From: brettlists at gmail.com (B C) Date: Mon, 17 Nov 2008 16:15:16 +0000 Subject: [address-policy-wg] Assignments for Critical Infrastruction In-Reply-To: <6.1.2.0.2.20081117164428.02ddfb58@66.36.228.26> References: <5c494b510811170559w34f5990bgb0971cc054f9e308@mail.gmail.com> <6.1.2.0.2.20081117164428.02ddfb58@66.36.228.26> Message-ID: <5c494b510811170815h723598cfw743c204a3183935c@mail.gmail.com> On Mon, Nov 17, 2008 at 2:55 PM, Greg L. wrote: > Current IPv4 already provides more advantage to ccTLD and gTLD with IPv4 > /24 prefix allocations for BGP anycast than for other business entities that > would like to get /24 prefix for BGP anycast DNS deployments. > > I don't see a reason why more resources should be allocated to a specific > group/entities named under "Critical infrastructure" category that still > compete with businesses that are unable to get /24 BGP anycast assignment > for DNS solutions from Ripe. > I think that the term Critical Infrastructure speaks for itself really doesn't it, without scalable and stable DNS deployments at the TLD level the businesses you refer to would be at risk because of their parents potential instability. I guess it depends on what you define as Critical Infrastructure, I am just talking about ccTLD/gTLD and ENUM registries/entity getting allocations for Anycasting their TLD DNS servers, by definition these are not in competition with businesses who are not in the TLD arena and therefore I don't believe there is a 'fairness' issue. > This is not fair (it was a bit fair when gTLD and ccTLD started out 5+ > years ago). > I'm interested to know what has changed in this area in the last 5 years and why you consider the fairness has changed? > This is why many European companies prefer Arin's IP space. Welcome to > Arin! > Well of course they are free to use ARIN space if they are able to meet their allocation policies. Brett > > At 18:09 2008.11.17.t C?', you wrote: > > Ondrej, > in the light of the comments on my proposal for ENUM anycast > assignments discussed in Dubai, I was planning to write a revised policy > proposal to go through PDP, I will be taking action on this as soon as the > minutes/webcast from Dubai are available. I think it's safe to say we are > working towards the same/similar goal and I think it's important that we > don't both do the same work. I will have a first draft of my proposal here > in the next couple of weeks. > > Regards > > Brett Carr > > Nominet UK > > > On Tue, Oct 28, 2008 at 10:48 AM, Ond?ej Sur? wrote: > Hello everybody, > > I would like to post unformal proposal before writing > official policy modification proposal (and/or having > discussion tomorrow on Open Hour). > > We would like to see policy for IPv4 and IPv6 modified > to allow /24 *minimum* for IPv4 and /48 *minimum* to > gTLD/ccTLD. > > First reason behind this is that one PI is not really > enough and it's blocking us to deploy more DNS servers > and make our TLD service more reliable. > > Second reason is that if we deploy more Anycasted DNS > servers we could keep (or drop down) number of NS records > for TLD, so we could manage to keep DNS reply size low > even with DNSSEC. > > And last, but not least, it would be good to keep this > synchronized with other regions (see [1],[2]). Note: > we may also extend the list of requestors to: > Root DNS, ccTLD, gTLD, IANA, RIRs. > Which I think is reasonable list. > > 1. http://www.nro.net/documents/comp-pol.html#2-4-2 > 2. http://www.nro.net/documents/comp-pol.html#3-4-1 > > If there is at least some consensus, I am willing to > write official policy change proposal. > > Ondrej > -- > Ond?ej Sur? > technick? ?editel/Chief Technical Officer > ----------------------------------------- > CZ.NIC, z.s.p.o. -- .cz domain registry > Americk? 23,120 00 Praha 2,Czech Republic > mailto:ondrej.sury at nic.cz http://nic.cz/ > sip:ondrej.sury at nic.cz tel:+420.222745110 > mob:+420.739013699 fax:+420.222745112 > ----------------------------------------- > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ondrej.sury at nic.cz Mon Nov 17 17:49:20 2008 From: ondrej.sury at nic.cz (=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Mon, 17 Nov 2008 17:49:20 +0100 Subject: [address-policy-wg] Assignments for Critical Infrastruction In-Reply-To: <6.1.2.0.2.20081117164428.02ddfb58@66.36.228.26> References: <5c494b510811170559w34f5990bgb0971cc054f9e308@mail.gmail.com> <6.1.2.0.2.20081117164428.02ddfb58@66.36.228.26> Message-ID: Greg, 2008/11/17 Greg L. : > Current IPv4 already provides more advantage to ccTLD and gTLD with IPv4 /24 > prefix allocations for BGP anycast than for other business entities that > would like to get /24 prefix for BGP anycast DNS deployments. It does not provide 'more advantage", RIPE policy provides just 'exactly ONE /24 IPv4 prefix and exactly ONE /48 IPv6 prefix' and it's not enough if you want to provide reliable infrastructure for TLD. > I don't see a reason why more resources should be allocated to a specific > group/entities named under "Critical infrastructure" category that still > compete with businesses that are unable to get /24 BGP anycast assignment > for DNS solutions from Ripe. This is not fair (it was a bit fair when gTLD > and ccTLD started out 5+ years ago). All these other businesses relies on services provided by ccTLD/gTLD, that's why. ccTLD/gTLD operation is almost as important as root servers operations. Certainly there are some categories of TLDs according to number of registered domains, but I would like to avoid a discussion about how much domain you need to have registered to be allowed to have /24 anycast prefix. Other reason could be that this would align RIPE policy with other RIRs policies. > This is why many European companies prefer Arin's IP space. Welcome to Arin! I am no ARIN policy expert, but from what I remember there is no special policy for other businesses in ARIN policy. But there is a special policy for 'critical infrastructure' and TLD DNS operators is already using that. Now that's unfair, we are basically punished for being in RIPE region, since you can get more anycast prefixes from all other RIRs. And please note that most of European TLDs are unable to move to other regions because of legal stuff. It's much easier to get legal status in US if you are private owned then if you are not-for-profit. Ondrej. -- Ond?ej Sur? technick? ?editel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americk? 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury at nic.cz http://nic.cz/ sip:ondrej.sury at nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- From ondrej.sury at nic.cz Mon Nov 17 17:35:48 2008 From: ondrej.sury at nic.cz (=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Mon, 17 Nov 2008 17:35:48 +0100 Subject: [address-policy-wg] Assignments for Critical Infrastruction In-Reply-To: <5c494b510811170559w34f5990bgb0971cc054f9e308@mail.gmail.com> References: <5c494b510811170559w34f5990bgb0971cc054f9e308@mail.gmail.com> Message-ID: Brett, I already sent my proposals to modify ipv4 and ipv6 policies to wg chairs while in Dubai. But incorporating ENUM should be as easy as listing ENUM Tier-1 registry to list of what is 'Critical Infrastructure'. Ondrej. 2008/11/17 B C : > Ondrej, > in the light of the comments on my proposal for ENUM anycast > assignments discussed in Dubai, I was planning to write a revised policy > proposal to go through PDP, I will be taking action on this as soon as the > minutes/webcast from Dubai are available. I think it's safe to say we are > working towards the same/similar goal and I think it's important that we > don't both do the same work. I will have a first draft of my proposal here > in the next couple of weeks. > > Regards > > Brett Carr > > Nominet UK > > > On Tue, Oct 28, 2008 at 10:48 AM, Ond?ej Sur? wrote: >> >> Hello everybody, >> >> I would like to post unformal proposal before writing >> official policy modification proposal (and/or having >> discussion tomorrow on Open Hour). >> >> We would like to see policy for IPv4 and IPv6 modified >> to allow /24 *minimum* for IPv4 and /48 *minimum* to >> gTLD/ccTLD. >> >> First reason behind this is that one PI is not really >> enough and it's blocking us to deploy more DNS servers >> and make our TLD service more reliable. >> >> Second reason is that if we deploy more Anycasted DNS >> servers we could keep (or drop down) number of NS records >> for TLD, so we could manage to keep DNS reply size low >> even with DNSSEC. >> >> And last, but not least, it would be good to keep this >> synchronized with other regions (see [1],[2]). Note: >> we may also extend the list of requestors to: >> Root DNS, ccTLD, gTLD, IANA, RIRs. >> Which I think is reasonable list. >> >> 1. http://www.nro.net/documents/comp-pol.html#2-4-2 >> 2. http://www.nro.net/documents/comp-pol.html#3-4-1 >> >> If there is at least some consensus, I am willing to >> write official policy change proposal. >> >> Ondrej >> -- >> Ond?ej Sur? >> technick? ?editel/Chief Technical Officer >> ----------------------------------------- >> CZ.NIC, z.s.p.o. -- .cz domain registry >> Americk? 23,120 00 Praha 2,Czech Republic >> mailto:ondrej.sury at nic.cz http://nic.cz/ >> sip:ondrej.sury at nic.cz tel:+420.222745110 >> mob:+420.739013699 fax:+420.222745112 >> ----------------------------------------- > > -- Ond?ej Sur? technick? ?editel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americk? 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury at nic.cz http://nic.cz/ sip:ondrej.sury at nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- From bgp2 at linuxadmin.org Mon Nov 17 19:53:29 2008 From: bgp2 at linuxadmin.org (Greg L.) Date: Mon, 17 Nov 2008 20:53:29 +0200 Subject: [address-policy-wg] Assignments for Critical Infrastruction In-Reply-To: References: <5c494b510811170559w34f5990bgb0971cc054f9e308@mail.gmail.com> <6.1.2.0.2.20081117164428.02ddfb58@66.36.228.26> Message-ID: <6.1.2.0.2.20081117204409.03770d78@66.36.228.26> Thanks for your fast reply. To be honest, I haven't seen multiple /24 IPv4 prefixes allocated (legally) to a single entity in Arin region just for DNS BGP Anycast service. In Ripe region you can't get /24 prefix allocated for DNS BGP anycast hosting if you are a normal business (like a DNS service provider who just wants to compete in this business crowd) unless you are gTLD or ccTLD. In Arin region you can get ONE /24 prefix for this purpose... This is why I am harsh with my comments to gTLD and ccTLD owners who now want more than one /24 prefix for DNS hosting in Ripe region... Sorry... Thanks! Greg http://www.linuxadmin.org/ At 19:54 2008.11.17., you wrote: >Greg, 2008/11/17 Greg L. : > Current IPv4 already >provides more advantage to ccTLD and gTLD with IPv4 /24 > prefix >allocations for BGP anycast than for other business entities that > would >like to get /24 prefix for BGP anycast DNS deployments. It does not >provide 'more advantage", RIPE policy provides just 'exactly ONE /24 IPv4 >prefix and exactly ONE /48 IPv6 prefix' and it's not enough if you want to >provide reliable infrastructure for TLD. > I don't see a reason why more >resources should be allocated to a specific > group/entities named under >"Critical infrastructure" category that still > compete with businesses >that are unable to get /24 BGP anycast assignment > for DNS solutions from >Ripe. This is not fair (it was a bit fair when gTLD > and ccTLD started >out 5+ years ago). All these other businesses relies on services provided >by ccTLD/gTLD, that's why. ccTLD/gTLD operation is almost as important as >root servers operations. Certainly there are some categories of TLDs >according to number of registered domains, but I would like to avoid a >discussion about how much domain you need to have registered to be allowed >to have /24 anycast prefix. Other reason could be that this would align >RIPE policy with other RIRs policies. > This is why many European >companies prefer Arin's IP space. Welcome to Arin! I am no ARIN policy >expert, but from what I remember there is no special policy for other >businesses in ARIN policy. But there is a special policy for 'critical >infrastructure' and TLD DNS operators is already using that. Now that's >unfair, we are basically punished for being in RIPE region, since you can >get more anycast prefixes from all other RIRs. And please note that most >of European TLDs are unable to move to other regions because of legal >stuff. It's much easier to get legal status in US if you are private >owned then if you are not-for-profit. Ondrej. -- Ond??ej Sur?? technick?? >??editel/Chief Technical Officer ----------------------------------------- >CZ.NIC, z.s.p.o. -- .cz domain registry Americk?? 23,120 00 Praha >2,Czech Republic mailto:ondrej.sury at nic.cz http://nic.cz/ >sip:ondrej.sury at nic.cz tel:+420.222745110 >mob:+420.739013699 fax:+420.222745112 >----------------------------------------- From bgp2 at linuxadmin.org Mon Nov 17 20:29:25 2008 From: bgp2 at linuxadmin.org (Greg L.) Date: Mon, 17 Nov 2008 21:29:25 +0200 Subject: [address-policy-wg] Assignments for Critical Infrastruction In-Reply-To: <5c494b510811170815h723598cfw743c204a3183935c@mail.gmail.co m> References: <5c494b510811170559w34f5990bgb0971cc054f9e308@mail.gmail.com> <6.1.2.0.2.20081117164428.02ddfb58@66.36.228.26> <5c494b510811170815h723598cfw743c204a3183935c@mail.gmail.com> Message-ID: <6.1.2.0.2.20081117211525.03787de8@66.36.228.26> At 18:15 2008.11.17.t C?', B C wrote: >On Mon, Nov 17, 2008 at 2:55 PM, Greg L. ><bgp2 at linuxadmin.org> wrote: >Current IPv4 already provides more advantage to ccTLD and gTLD with IPv4 >/24 prefix allocations for BGP anycast than for other business entities >that would like to get /24 prefix for BGP anycast DNS deployments. > > I don't see a reason why more resources should be allocated to a > specific group/entities named under "Critical infrastructure" category > that still compete with businesses that are unable to get /24 BGP anycast > assignment for DNS solutions from Ripe. > > >I think that the term Critical Infrastructure speaks for itself really >doesn't it, without scalable and stable DNS deployments at the TLD level >the businesses you refer to would be at risk because of their parents >potential instability. > >I guess it depends on what you define as Critical Infrastructure, I am >just talking about ccTLD/gTLD and ENUM registries/entity getting >allocations for Anycasting their TLD DNS servers, by definition these are >not in competition with businesses who are not in the TLD arena and >therefore I don't believe there is a 'fairness' issue. One /24 prefix for TLD's DNS should be more than enough anyway. If you are hosting ccTLD or gTLD it shouldn't automatically qualify you for "Critical infrastructure". A small country with 200 ccTLD domains registered is not more critical than some business hosting 120,000 .com/.net domains (a DNS service not ccTLD or gTLD). Maybe a high reliability and uptime for this company is more critical to be in business than a small ccTLD with just 2 million of DNS queries. However, the small ccTLD get's /24 allocated without problems in Ripe region, the other company does NOT. Well I do not care much anyway since we have moved clients to Arin IP space and meet all the requirements there and we are happy. I just wanted to comment that /24 prefix for anycast should be more open to businesses that meet some other criteria not just ccTLD or gTLD hosting. > >This is not fair (it was a bit fair when gTLD and ccTLD started out 5+ >years ago). > > >I'm interested to know what has changed in this area in the last 5 years >and why you consider the fairness has changed? Faster pipes, CPU power, better firewalls.... (cheaper HW)... Greg > >This is why many European companies prefer Arin's IP space. Welcome to Arin! > > >Well of course they are free to use ARIN space if they are able to meet >their allocation policies. > >Brett > > > >At 18:09 2008.11.17.t C?', you wrote: >>Ondrej, >> in the light of the comments on my proposal for ENUM anycast >> assignments discussed in Dubai, I was planning to write a revised policy >> proposal to go through PDP, I will be taking action on this as soon as >> the minutes/webcast from Dubai are available. I think it's safe to say >> we are working towards the same/similar goal and I think it's important >> that we don't both do the same work. I will have a first draft of my >> proposal here in the next couple of weeks. >> >>Regards >> >>Brett Carr >> >>Nominet UK >> >> >>On Tue, Oct 28, 2008 at 10:48 AM, Ond?ej Sur? >><ondrej.sury at nic.cz> wrote: >>Hello everybody, >>I would like to post unformal proposal before writing >>official policy modification proposal (and/or having >>discussion tomorrow on Open Hour). >>We would like to see policy for IPv4 and IPv6 modified >>to allow /24 *minimum* for IPv4 and /48 *minimum* to >>gTLD/ccTLD. >>First reason behind this is that one PI is not really >>enough and it's blocking us to deploy more DNS servers >>and make our TLD service more reliable. >>Second reason is that if we deploy more Anycasted DNS >>servers we could keep (or drop down) number of NS records >>for TLD, so we could manage to keep DNS reply size low >>even with DNSSEC. >>And last, but not least, it would be good to keep this >>synchronized with other regions (see [1],[2]). Note: >>we may also extend the list of requestors to: >>Root DNS, ccTLD, gTLD, IANA, RIRs. >>Which I think is reasonable list. >>1. >>http://www.nro.net/documents/comp-pol.html#2-4-2 >> >>2. http://www.nro.net/documents/comp-pol.html#3-4-1 >>If there is at least some consensus, I am willing to >>write official policy change proposal. >>Ondrej >>-- >> Ond?ej Sur? >> technick? ?editel/Chief Technical Officer >> ----------------------------------------- >> CZ.NIC, z.s.p.o. -- .cz domain registry >> Americk? 23,120 00 Praha 2,Czech Republic >> mailto:ondrej.sury at nic.cz http://nic.cz/ >> sip:ondrej.sury at nic.cz tel:+420.222745110 >> mob:+420.739013699 fax:+420.222745112 >> ----------------------------------------- >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ondrej.sury at nic.cz Mon Nov 17 20:32:02 2008 From: ondrej.sury at nic.cz (=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Mon, 17 Nov 2008 20:32:02 +0100 Subject: [address-policy-wg] Assignments for Critical Infrastruction In-Reply-To: <6.1.2.0.2.20081117204409.03770d78@66.36.228.26> References: <5c494b510811170559w34f5990bgb0971cc054f9e308@mail.gmail.com> <6.1.2.0.2.20081117164428.02ddfb58@66.36.228.26> <6.1.2.0.2.20081117204409.03770d78@66.36.228.26> Message-ID: Greg, > In Ripe region you can't get /24 prefix allocated for DNS BGP anycast > hosting if you are a normal business (like a DNS service provider who just > wants to compete in this business crowd) unless you are gTLD or ccTLD. In > Arin region you can get ONE /24 prefix for this purpose... This is why I am > harsh with my comments to gTLD and ccTLD owners who now want more than one > /24 prefix for DNS hosting in Ripe region... Sorry... if you want to change policy, feel free to write a proposal and let's discuss it here. And if we get a consensus that such policy enhancement should be implemented in RIPE region then we are going to implement it. Meanwhile let's not stop TLDs from getting more anycast address space just because other businesses cannot get it. Ondrej -- Ondrej Sury technicky reditel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americka 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury at nic.cz http://nic.cz/ sip:ondrej.sury at nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- From leo.vegoda at icann.org Mon Nov 17 20:34:42 2008 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 17 Nov 2008 11:34:42 -0800 Subject: [address-policy-wg] Assignments for Critical Infrastruction In-Reply-To: <6.1.2.0.2.20081117204409.03770d78@66.36.228.26> Message-ID: Hi Greg, On 17/11/2008 7:53, "Greg L." wrote: [...] > In Ripe region you can't get /24 prefix allocated for DNS BGP anycast > hosting if you are a normal business (like a DNS service provider who just > wants to compete in this business crowd) unless you are gTLD or ccTLD. In > Arin region you can get ONE /24 prefix for this purpose... This is why I am > harsh with my comments to gTLD and ccTLD owners who now want more than one > /24 prefix for DNS hosting in Ripe region... Sorry... I think that the problem ccTLDs and company suffer from is that their DNS anycast networks don't use enough addresses to justify a /24 PI assignment under the normal policy. But if you are a regular business you are less likely to have just one customer and so the problem of not qualifying under the normal policy should be less likely. The RIPE NCC appear to have assigned just over 880 /24 PI assignments so far this year. /24s don't seem to be too difficult to get in the general case, just in this particular case. Regards, Leo Vegoda From ondrej.sury at nic.cz Mon Nov 17 20:46:40 2008 From: ondrej.sury at nic.cz (=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Mon, 17 Nov 2008 20:46:40 +0100 Subject: [address-policy-wg] Assignments for Critical Infrastruction In-Reply-To: <6.1.2.0.2.20081117211525.03787de8@66.36.228.26> References: <5c494b510811170559w34f5990bgb0971cc054f9e308@mail.gmail.com> <6.1.2.0.2.20081117164428.02ddfb58@66.36.228.26> <5c494b510811170815h723598cfw743c204a3183935c@mail.gmail.com> <6.1.2.0.2.20081117211525.03787de8@66.36.228.26> Message-ID: 2008/11/17 Greg L. : > One /24 prefix for TLD's DNS should be more than enough anyway. Why do you think so? > If you are hosting ccTLD or gTLD it shouldn't automatically qualify you > for "Critical infrastructure". A small country with 200 ccTLD domains > registered is not more critical than some business hosting 120,000 > .com/.net domains (a DNS service not ccTLD or gTLD). Maybe a high > reliability and uptime for this company is more critical to be in business > than a small ccTLD with just 2 million of DNS queries. I agree here with you. My proposal is same as ARINs policy that CI MAY get more then one prefix and it should be up to RIPE NCC hostmaster decision if they allow TLD to get more then one prefix. Something like a plan of deployment, etc. - small TLD would not be able to deploy many anycast nodes around the globe. > However, the small ccTLD get's /24 allocated without problems in Ripe > region, the other company does NOT. Again "the other company does NOT" should not be a reason why TLD should not be able to get more than one prefix. If you don't like current policy change it or at least try to change it. Blocking reasonable (my POV) proposal just because you're angry that you had to move to Arin region will get us nowhere. > Well I do not care much anyway since we have moved clients to Arin IP space > and meet all the requirements there and we are happy. Alright now you are saying that Arin's policy is good. Maybe you should started your email conversation with proposal that you would like to see RIPE policy to allow PI assignments to other businesses as well. > I just wanted to comment that /24 prefix for anycast should be more open > to businesses that meet some other criteria not just ccTLD or gTLD hosting. Here we may get to some level of agreement. Constructive proposals are most welcome. Ondrej. -- Ondrej Sury technicky reditel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americka 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury at nic.cz http://nic.cz/ sip:ondrej.sury at nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- From bgp2 at linuxadmin.org Mon Nov 17 21:25:50 2008 From: bgp2 at linuxadmin.org (Greg L.) Date: Mon, 17 Nov 2008 22:25:50 +0200 Subject: [address-policy-wg] Assignments for Critical Infrastruction In-Reply-To: References: <5c494b510811170559w34f5990bgb0971cc054f9e308@mail.gmail.com> <6.1.2.0.2.20081117164428.02ddfb58@66.36.228.26> <5c494b510811170815h723598cfw743c204a3183935c@mail.gmail.com> <6.1.2.0.2.20081117211525.03787de8@66.36.228.26> Message-ID: <6.1.2.0.2.20081117221349.0374e188@66.36.228.26> Yes, correct.. my main point was not to block any proposals, I just wanted to comment that PI assignations must be more open to businesses that require it for BGP anycasting (multihoming etc) in Ripe region as it is in Arin region. My apologies for the comments that I sent in reply to your emails - probably a wrong discussion/thread. I just remember the problems we had and how easy it was when we moved our client to Arin IP space. However, I believe http://www.ripe.net/ripe/policies/proposals/2006-05.html "PI Assignment Size" proposal is aimed to solve the problem with PI allocation of /24 when routing is the major issue. This is something that Arin already has in their policy and works like a charm. Unfortunately, I haven't heard much about this proposal lately - it's been in "Awaiting Decision from WG Chair " status. Greg At 21:46 2008.11.17.t C?', Ond??ej Sur?? wrote: >2008/11/17 Greg L. : > > One /24 prefix for TLD's DNS should be more than enough anyway. > >Why do you think so? > > > If you are hosting ccTLD or gTLD it shouldn't automatically qualify you > > for "Critical infrastructure". A small country with 200 ccTLD domains > > registered is not more critical than some business hosting 120,000 > > .com/.net domains (a DNS service not ccTLD or gTLD). Maybe a high > > reliability and uptime for this company is more critical to be in business > > than a small ccTLD with just 2 million of DNS queries. > >I agree here with you. My proposal is same as ARINs policy that CI MAY get >more then one prefix and it should be up to RIPE NCC hostmaster decision >if they allow TLD to get more then one prefix. Something like a plan >of deployment, etc. - small TLD would not be able to deploy many anycast >nodes around the globe. > > > However, the small ccTLD get's /24 allocated without problems in Ripe > > region, the other company does NOT. > >Again "the other company does NOT" should not be a reason why TLD should not >be able to get more than one prefix. If you don't like current policy change >it or at least try to change it. Blocking reasonable (my POV) proposal just >because you're angry that you had to move to Arin region will get us nowhere. > > > Well I do not care much anyway since we have moved clients to Arin IP space > > and meet all the requirements there and we are happy. > >Alright now you are saying that Arin's policy is good. Maybe you should >started your email conversation with proposal that you would like to see >RIPE policy to allow PI assignments to other businesses as well. > > > I just wanted to comment that /24 prefix for anycast should be more open > > to businesses that meet some other criteria not just ccTLD or gTLD hosting. > >Here we may get to some level of agreement. Constructive proposals are most >welcome. > >Ondrej. >-- > Ondrej Sury > technicky reditel/Chief Technical Officer > ----------------------------------------- > CZ.NIC, z.s.p.o. -- .cz domain registry > Americka 23,120 00 Praha 2,Czech Republic > mailto:ondrej.sury at nic.cz http://nic.cz/ > sip:ondrej.sury at nic.cz tel:+420.222745110 > mob:+420.739013699 fax:+420.222745112 > ----------------------------------------- From gert at space.net Tue Nov 18 23:06:54 2008 From: gert at space.net (Gert Doering) Date: Tue, 18 Nov 2008 23:06:54 +0100 Subject: [address-policy-wg] Assignments for Critical Infrastruction In-Reply-To: <6.1.2.0.2.20081117164428.02ddfb58@66.36.228.26> References: <5c494b510811170559w34f5990bgb0971cc054f9e308@mail.gmail.com> <6.1.2.0.2.20081117164428.02ddfb58@66.36.228.26> Message-ID: <20081118220654.GH89033@Space.Net> Hi, On Mon, Nov 17, 2008 at 04:55:22PM +0200, Greg L. wrote: > Current IPv4 already provides more advantage to ccTLD and gTLD with IPv4 > /24 prefix allocations for BGP anycast than for other business entities > that would like to get /24 prefix for BGP anycast DNS deployments. Well. I have not yet seen a specific proposal coming from a company that explains what they are doing with anycast and that is *not* running a *TLD (or ENUM). So who are you, what are you doing, and what would be your proposal how to amend the policies? (If you're happy with Arin space, be my guest - less work for us) Gert Doering -- NetMaster -- 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 andrei at ripe.net Wed Nov 19 14:10:29 2008 From: andrei at ripe.net (Andrei Robachevsky) Date: Wed, 19 Nov 2008 14:10:29 +0100 Subject: [address-policy-wg] IPv6 assignment for the RIPE meeting network Message-ID: <49241045.5060707@ripe.net> Dear Colleagues, This is an informal submission of the proposal that was presented at RIPE 57 in Dubai (http://www.ripe.net/ripe/meetings/ripe-57/presentations/Robachevsky-IPv6_assignment_for_RIPE_meeting_network.pdf), as was suggested by the community. Your feedback is appreciated as well as your opinion whether a formal submission should follow. Regards, Andrei Robachevsky RIPE NCC IPv6 address space assignment for RIPE Meetings --------------------------------------- A dedicated IPv6 prefix is assigned to the organisation that organises the RIPE Meetings. The size of this prefix is a /48 and the assignment will be valid as long as the organisation is responsible for organising the RIPE Meetings and the usage of the prefix is limited to RIPE Meeting networks. The status of this assignment will be 'ASSIGNED MEETING? in the RIPE Database and must be returned to the RIPE NCC if not in use for RIPE Meeting networks. Rationale: -------- a. Arguments supporting the proposal RIPE NCC has been organising RIPE Meetings for over a decade now and it is still responsible for the setup of the meeting network. As IPv6 deployment has became more of a necessity, the RIPE NCC has been providing IPv6 network during RIPE Meetings too. Although first couple of setups were more at an experimental level, currently we offer this as a production-grade service to the attendees. The IPv6 space for these networks so far has been provided by some other organisations and so the assignments were in temporary nature. We appreciate the support these organisations have provided so far. Today a permanent IPv6 prefix is a necessity to be able to provide a stable and high quality service during RIPE Meetings. Having such a permanent and dedicated prefix, the RIPE Meeting Team of the RIPE NCC will be able to design and test the RIPE meeting network beforehand, which will ensure stable operation of the IPv6 network during the RIPE Meetings. This will also allow the team to have complete control over the network to effectively address issues related to security, redundancy and setting efficient routing policies with third parties. The proposal is worded in a way that the IPv6 prefix will be provided to the RIPE Meeting organiser. This is to ensure that the prefix will stay with the meeting organiser for the sole usage in RIPE meetings. This means if the RIPE NCC ceases being the RIPE Meeting organiser in the future, the prefix will be returned to the free pool. The reason for the size being set to a /48 is about routing reasons. Because this is the minimum excepted routable assignment size that is common among all regions, we think a prefix in this size will guarantee connectivity during RIPE Meetings. b. Arguments opposing the proposal Some may argue that this will cause waste of address space because the prefix will be only in use effectively during RIPE meeting From jeroen at unfix.org Wed Nov 19 14:39:42 2008 From: jeroen at unfix.org (Jeroen Massar) Date: Wed, 19 Nov 2008 14:39:42 +0100 Subject: [address-policy-wg] IPv6 assignment for the RIPE meeting network In-Reply-To: <49241045.5060707@ripe.net> References: <49241045.5060707@ripe.net> Message-ID: <4924171E.90209@spaghetti.zurich.ibm.com> [nasty email following, partially nice at the end] Andrei Robachevsky wrote: [..] > IPv6 address space assignment for RIPE Meetings > --------------------------------------- > > A dedicated IPv6 prefix is assigned to the organisation that organises > the RIPE Meetings. The size of this prefix is a /48 and the assignment > will be valid as long as the organisation is responsible for organising > the RIPE Meetings and the usage of the prefix is limited to RIPE Meeting > networks. > > The status of this assignment will be 'ASSIGNED MEETING? in the RIPE > Database and must be returned to the RIPE NCC if not in use for RIPE > Meeting networks. Wow, that will really make RIPE special wouldn't it? A special status, just for RIPE. How much time will the Database team need to fix that up in the code of the whois server, and how many external tools need to be updated to handle that special status? [..] > Today a permanent IPv6 prefix is a necessity to be able to provide a > stable and high quality service during RIPE Meetings. You mean to say that the networks where RIPE meetings was making use of before where unstable and of bad quality? > Having such a > permanent and dedicated prefix, the RIPE Meeting Team of the RIPE NCC > will be able to design and test the RIPE meeting network beforehand, Which is of course not possible when I tell you several months in advance (I guess you need to book hotels, meeting rooms etc way in advance thus you know where you are going to) that your prefix is going to be 2001:db8:b4d:1dea::/48* that you can't "test" with that? > which will ensure stable operation of the IPv6 network during the RIPE > Meetings. This will also allow the team to have complete control over > the network to effectively address issues related to security, Because you can't firewall on another prefix nor can the /48 be properly entered in the RIPE db so that it contains proper contact info. > redundancy and setting efficient routing policies with third parties. because you just want to fill up the routing table with /48's... And people will have to punch a special hole in their prefix filters for this exact prefix all of a sudden. Wow that really makes you special. It seems to me that RIPE NCC is making this big case for "IPv6 PI", wonderful. > The proposal is worded in a way that the IPv6 prefix will be provided to > the RIPE Meeting organiser. This is to ensure that the prefix will stay > with the meeting organiser for the sole usage in RIPE meetings. This > means if the RIPE NCC ceases being the RIPE Meeting organiser in the > future, the prefix will be returned to the free pool. (I guess you would mean that if the "Meeting Organiser" changes that the prefix would go to the new one, and when "RIPE meetings" end that the prefix will be returned to the free pool) > The reason for the size being set to a /48 is about routing reasons. I thought that prefixes where allocated based on address space need. Though a /48 is of course a site, which makes it the minimum allocation size, which would be more or less a valid reason, still it isn't. > Because this is the minimum excepted routable assignment size that is > common among all regions, we think a prefix in this size will guarantee > connectivity during RIPE Meetings. Non-sense, if your prefix is worthy enough (aka the content or you pay them enough) people will route it, whatever the size it is. > b. Arguments opposing the proposal > > Some may argue that this will cause waste of address space because the > prefix will be only in use effectively during RIPE meeting And what about every other "meeting", I tend to have "meetings" at my home, you know "Whisky Meetings", can I get a special free PI block for that too. More seriously, will this also work for IETF, CCC, What The Hack, LanPartyXYZ, etc etc etc. Most of these setup their network a week in advance, as they also need to do a lot of other things to get things working properly, maybe that is the way to go for RIPE meetings? Thus, if there is going to be a 'meeting policy' then it should be well defined and very generic and also allow every other "Meeting" to make use of it, even if the event is a one-timer. And as we have End-user/LIR payment now, somebody has to foot the bill for them too. Greets, Jeroen * = too many bits in network on purpose -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 187 bytes Desc: OpenPGP digital signature URL: From Remco.vanMook at eu.equinix.com Wed Nov 19 15:15:29 2008 From: Remco.vanMook at eu.equinix.com (Remco van Mook) Date: Wed, 19 Nov 2008 15:15:29 +0100 Subject: [address-policy-wg] IPv6 assignment for the RIPE meeting network References: <49241045.5060707@ripe.net> Message-ID: <2E61C47A190CA44ABFCF23147E57E4BC5BED39@NLEN1EX1.eu.win.equinix.com> Dear Andrei, all, While I appreciate what you're getting at, I'd prefer a more general proposal for 'resources for the NCC'. As any resource allocated to the NCC can be perceived as a conflict between the NCC and ALL of its members (the resources won't be available for them :) I'd suggest that we create a policy that lets the NCC file a request in the ordinary way and then have a few members of the NCC arbiter pool evaluate that request, sitting in the chair of the hostmasters^Wresource analysts. Since the NCC is the only party that can't sign a contract with the NCC, it stands to reason that we have something in place to handle this. Best, Remco van Mook (incidentally one of those arbiters) > -----Original Message----- > From: address-policy-wg-admin at ripe.net > [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Andrei > Robachevsky > Sent: woensdag 19 november 2008 14:10 > To: address-policy-wg at ripe.net > Subject: [address-policy-wg] IPv6 assignment for the RIPE > meeting network > > Dear Colleagues, > > This is an informal submission of the proposal that was presented at > RIPE 57 in Dubai > (http://www.ripe.net/ripe/meetings/ripe-57/presentations/Robac > hevsky-IPv6_assignment_for_RIPE_meeting_network.pdf), > as was suggested by the community. > > Your feedback is appreciated as well as your opinion whether a formal > submission should follow. > > Regards, > > Andrei Robachevsky > RIPE NCC > > > IPv6 address space assignment for RIPE Meetings > --------------------------------------- > > A dedicated IPv6 prefix is assigned to the organisation that organises > the RIPE Meetings. The size of this prefix is a /48 and the assignment > will be valid as long as the organisation is responsible for > organising > the RIPE Meetings and the usage of the prefix is limited to > RIPE Meeting > networks. > > The status of this assignment will be 'ASSIGNED MEETING' in the RIPE > Database and must be returned to the RIPE NCC if not in use for RIPE > Meeting networks. > > Rationale: > -------- > a. Arguments supporting the proposal > > RIPE NCC has been organising RIPE Meetings for over a decade > now and it > is still responsible for the setup of the meeting network. > > As IPv6 deployment has became more of a necessity, the RIPE > NCC has been > providing IPv6 network during RIPE Meetings too. Although first couple > of setups were more at an experimental level, currently we > offer this as > a production-grade service to the attendees. The IPv6 space for these > networks so far has been provided by some other organisations > and so the > assignments were in temporary nature. We appreciate the support these > organisations have provided so far. > > Today a permanent IPv6 prefix is a necessity to be able to provide a > stable and high quality service during RIPE Meetings. Having such a > permanent and dedicated prefix, the RIPE Meeting Team of the RIPE NCC > will be able to design and test the RIPE meeting network beforehand, > which will ensure stable operation of the IPv6 network during the RIPE > Meetings. This will also allow the team to have complete control over > the network to effectively address issues related to security, > redundancy and setting efficient routing policies with third parties. > > The proposal is worded in a way that the IPv6 prefix will be > provided to > the RIPE Meeting organiser. This is to ensure that the prefix > will stay > with the meeting organiser for the sole usage in RIPE meetings. This > means if the RIPE NCC ceases being the RIPE Meeting organiser in the > future, the prefix will be returned to the free pool. > > The reason for the size being set to a /48 is about routing reasons. > Because this is the minimum excepted routable assignment size that is > common among all regions, we think a prefix in this size will > guarantee > connectivity during RIPE Meetings. > > > b. Arguments opposing the proposal > > Some may argue that this will cause waste of address space because the > prefix will be only in use effectively during RIPE meeting > > 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 andrei at ripe.net Thu Nov 20 14:48:28 2008 From: andrei at ripe.net (Andrei Robachevsky) Date: Thu, 20 Nov 2008 14:48:28 +0100 Subject: [address-policy-wg] IPv6 assignment for the RIPE meeting network In-Reply-To: <4924171E.90209@spaghetti.zurich.ibm.com> References: <49241045.5060707@ripe.net> <4924171E.90209@spaghetti.zurich.ibm.com> Message-ID: <49256AAC.9050000@ripe.net> Jeroen, thank you for your comments, I think it is important that we agree on the main idea. That's why this proposal was send to the wg for informal discussion, rather then submitted to the PDP. Jeroen Massar wrote on 19-11-2008 14:39: [...] > > Thus, if there is going to be a 'meeting policy' then it should be well > defined and very generic and also allow every other "Meeting" to make > use of it, even if the event is a one-timer. And as we have End-user/LIR > payment now, somebody has to foot the bill for them too. > Whether that is going to be a meeting policy, or as Remco suggested a RIPE NCC policy, or just a policy to document that specific assignment is equally fine by me. I leave this to people more experienced in the policy area. Our objective is to get a permanent dedicated assignment for a community meeting. This is not unusual, for example IETF got such assignment from APNIC. > Greets, > Jeroen > > * = too many bits in network on purpose > Regards, Andrei Robachevsky RIPE NCC From niels=apwg at bakker.net Thu Nov 20 15:51:20 2008 From: niels=apwg at bakker.net (Niels Bakker) Date: Thu, 20 Nov 2008 15:51:20 +0100 Subject: [address-policy-wg] IPv6 assignment for the RIPE meeting network In-Reply-To: <49241045.5060707@ripe.net> References: <49241045.5060707@ripe.net> Message-ID: <20081120145120.GA83136@burnout.tpb.net> * andrei at ripe.net (Andrei Robachevsky) [Thu 20 Nov 2008, 09:41 CET]: >IPv6 address space assignment for RIPE Meetings >--------------------------------------- > > A dedicated IPv6 prefix is assigned to the organisation that organises > the RIPE Meetings. The size of this prefix is a /48 and the assignment > will be valid as long as the organisation is responsible for organising > the RIPE Meetings and the usage of the prefix is limited to RIPE > Meeting networks. > > The status of this assignment will be 'ASSIGNED MEETING' in the RIPE > Database and must be returned to the RIPE NCC if not in use for RIPE > Meeting networks. Hey, I run networks at conferences too, albeit in my spare time. Can I get a special case for me as well? While Remco van Mook has a point about the NCC not being able to sign contracts with itself, I find it a stretch to then do away with the policies altogether. It's not as if RIPE meetings are critical infrastructure in any sense of the word, and to be honest I've never had problems with IPv6 routing at them that weren't caused by router brokenness. Given that one of the IPng design criteria was easier renumbering I find it hilarious that you quote the ability to test with the same numbers as justification for this dedicated prefix. -- Niels. -- From Woeber at CC.UniVie.ac.at Thu Nov 20 17:43:28 2008 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 20 Nov 2008 16:43:28 +0000 Subject: [address-policy-wg] IPv6 assignment for the RIPE meeting network In-Reply-To: <49256AAC.9050000@ripe.net> References: <49241045.5060707@ripe.net> <4924171E.90209@spaghetti.zurich.ibm.com> <49256AAC.9050000@ripe.net> Message-ID: <492593B0.3060908@CC.UniVie.ac.at> Hi Andrei, community, Andrei Robachevsky wrote: > Jeroen, thank you for your comments, > > I think it is important that we agree on the main idea. Before trying to make up my mind in favour or against, I think we need a better understanding (definition) of responsibilities and activities. After a very rough reading, there seems to be a mixture of - the NCC as (currently) being responsible for the setup of meetings - the local host and/or connectivity provider - the NCC as an RIR. My first approach would be having the NCC (as the party responsible) talk to the NCC (the RIR) and tag a particular prefix with transient, for (RIPE) Meetings. As soon as the planning for the next meeting starts, it should be easy to assign that prefix to either the local host or the connectivty provider for the (virtual) site RIPE Meeting. Everything else, like who operates the network, who announces the prefix, who does the is then an internal issue. After the meeting ends, the prefix goes back to the pool (with the label to not be given away for other things :-) ) Only when and if some services should remain accessible beyond the end of the meeting, we should think about a (formally) permanent solution. Even then, those services might better be found in the regular NCC's address space between meetings? > That's why this > proposal was send to the wg for informal discussion, rather then > submitted to the PDP. Thanks, Wilfried (wearing a similar hat like Remco does, incidentally). > Jeroen Massar wrote on 19-11-2008 14:39: > [...] > > >>Thus, if there is going to be a 'meeting policy' then it should be well >>defined and very generic and also allow every other "Meeting" to make >>use of it, even if the event is a one-timer. And as we have End-user/LIR >>payment now, somebody has to foot the bill for them too. >> > > > Whether that is going to be a meeting policy, or as Remco suggested a > RIPE NCC policy, or just a policy to document that specific assignment > is equally fine by me. I leave this to people more experienced in the > policy area. > > Our objective is to get a permanent dedicated assignment for a community > meeting. This is not unusual, for example IETF got such assignment from > APNIC. > > >>Greets, >> Jeroen >> >>* = too many bits in network on purpose >> > > > Regards, > > Andrei Robachevsky > RIPE NCC > > From ondrej.sury at nic.cz Thu Nov 20 18:28:47 2008 From: ondrej.sury at nic.cz (=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Thu, 20 Nov 2008 18:28:47 +0100 Subject: [address-policy-wg] IPv6 assignment for the RIPE meeting network In-Reply-To: <49241045.5060707@ripe.net> References: <49241045.5060707@ripe.net> Message-ID: Andrei, 2008/11/19 Andrei Robachevsky : > Dear Colleagues, > > This is an informal submission of the proposal that was presented at > RIPE 57 in Dubai > (http://www.ripe.net/ripe/meetings/ripe-57/presentations/Robachevsky-IPv6_assignment_for_RIPE_meeting_network.pdf), > as was suggested by the community. > > Your feedback is appreciated as well as your opinion whether a formal > submission should follow. Brett and I are now working on updating 2008-05 proposal to modify PI assignments for Critical Infrastructure. I think that what we just need is to enlist RIPE NCC into Critical Infrastructure providers and then there will be no need for some special rule just for RIPE NCC. Two other notes: a) 'RIPE Meeting organiser' - I think it's just too much complicated, while not just say, that RIPE NCC get's prefix for RIPE Meetings and there is a time that RIPE NCC is not organiser of the meeting it will allow new organization to use that prefix? b) My experience with /48 shows that it's not 'common accepted' - you can check IPv6 anycast d.ns.nic.cz in DNSMON service. But I support this size, since if routing is broken during RIPE Meeting it will most likely get fixed very soon ;). But generally speaking I support idea in this proposal. Ondrej -- Ondrej Sury technicky reditel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americka 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury at nic.cz http://nic.cz/ sip:ondrej.sury at nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- From nick at inex.ie Thu Nov 20 21:48:47 2008 From: nick at inex.ie (Nick Hilliard) Date: Thu, 20 Nov 2008 20:48:47 +0000 Subject: [address-policy-wg] IPv6 assignment for the RIPE meeting network In-Reply-To: <49241045.5060707@ripe.net> References: <49241045.5060707@ripe.net> Message-ID: <4925CD2F.5090609@inex.ie> Andrei Robachevsky wrote: > A dedicated IPv6 prefix is assigned to the organisation that organises > the RIPE Meetings. The size of this prefix is a /48 and the assignment > will be valid as long as the organisation is responsible for organising > the RIPE Meetings and the usage of the prefix is limited to RIPE Meeting > networks. As far as I can see, the RIPE NCC's requirements for address space require provider independence from both political and technical points of view. So let's acknowledge this and create a proposal to allow the NCC to assign itself new provider independent resources as required and formalise its existing numbering arrangements. For this reason, I'm in favour of neither this current draft nor the current G?delian bureaucratic paralysis which is currently prohibiting the NCC from dealing sensibly with its own addressing requirements. If this draft were to become policy, it would lead to the following situation: - ipv4 infrastructure: assigned pi, issued by eu.zz, early assignment - ipv6 infrastructure: a /48 carved out of SARA's /32 PA assignment. - ASN infrastructure: AS3333, early assignment - ipv4 meetings: assigned pi, issued by eu.zz, early assignment - ipv6 meetings: a /48 assigned by policy decree - ASN meetings: AS2121, early assignment Spotting the inconsistencies herein is left as an exercise for the reader. If proposal 2006-01 is passed, and if there is a new policy proposal to allow RIPE to assign itself provider independent number resources, there will be a clear and consistent mechanism for RIPE to formalise all its addressing requirements, past and future. Nick {disclaimer: I have no idea if the NCC is in favour of this thinking} From randy at psg.com Thu Nov 20 21:55:21 2008 From: randy at psg.com (Randy Bush) Date: Thu, 20 Nov 2008 14:55:21 -0600 Subject: [address-policy-wg] IPv6 assignment for the RIPE meeting network In-Reply-To: <4925CD2F.5090609@inex.ie> References: <49241045.5060707@ripe.net> <4925CD2F.5090609@inex.ie> Message-ID: <4925CEB9.5070905@psg.com> > As far as I can see, the RIPE NCC's requirements for address space require > provider independence from both political and technical points of view. luckily, no other entity has this problem randy From anamatic at ripe.net Tue Nov 25 11:56:22 2008 From: anamatic at ripe.net (Ana Matic) Date: Tue, 25 Nov 2008 11:56:22 +0100 Subject: [address-policy-wg] Revised 2006-01 set back to Discussion Phase (Provider Independent (PI) IPv6 Assignments for End User Organisations) Message-ID: <20081125105622.618F22F592@herring.ripe.net> PDP Number: 2006-01 Provider Independent (PI) IPv6 Assignments for End User Organisations Dear Colleagues, The text of the policy proposal 2006-01 has been revised based on the community feedback received on the mailing list and during RIPE 56 and 57. We have published the new version (version 4) 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/2006-01.html We encourage you to review this policy proposal and send your comments to before 23 December 2008. Regards, Ana Matic RIPE NCC Policy Development Officer From anamatic at ripe.net Tue Nov 25 15:42:18 2008 From: anamatic at ripe.net (Ana Matic) Date: Tue, 25 Nov 2008 15:42:18 +0100 Subject: [address-policy-wg] 2007-05 Policy Proposal Withdrawn (IPv6 ULA-Central) Message-ID: <20081125144218.843912F592@herring.ripe.net> PDP Number: 2007-05 IPv6 ULA-Central Dear Colleagues, The proposal 2007-05, "IPv6 ULA-Central" has been withdrawn. The proposer decided to withdraw this proposal and wait for the IETF process on the subject to conclude. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2007-05.html Regards, Ana Matic RIPE NCC Asst. Policy Development Officer From president at ukraine.su Tue Nov 25 16:10:48 2008 From: president at ukraine.su (Max Tulyev) Date: Tue, 25 Nov 2008 17:10:48 +0200 Subject: [address-policy-wg] Revised 2006-01 set back to Discussion Phase (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <20081125105622.618F22F592@herring.ripe.net> References: <20081125105622.618F22F592@herring.ripe.net> Message-ID: <492C1578.7090907@ukraine.su> Hello, I support this proposal. Ana Matic wrote: > PDP Number: 2006-01 > Provider Independent (PI) IPv6 Assignments for End User Organisations > > Dear Colleagues, > > The text of the policy proposal 2006-01 has been revised based on the community feedback received > on the mailing list and during RIPE 56 and 57. > > We have published the new version (version 4) 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/2006-01.html > > > We encourage you to review this policy proposal and send your comments > to before 23 December 2008. > > Regards, > > Ana Matic > RIPE NCC > Policy Development Officer > > -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From lists-ripe at c4inet.net Tue Nov 25 18:21:22 2008 From: lists-ripe at c4inet.net (lists-ripe at c4inet.net) Date: Tue, 25 Nov 2008 17:21:22 +0000 Subject: [address-policy-wg] Revised 2006-01 set back to Discussion Phase (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <20081125105622.618F22F592@herring.ripe.net> References: <20081125105622.618F22F592@herring.ripe.net> Message-ID: <20081125172122.GA2174@cilantro.c4inet.net> On Tue, Nov 25, 2008 at 11:56:22AM +0100, Ana Matic wrote: > PDP Number: 2006-01 > Provider Independent (PI) IPv6 Assignments for End User Organisations Without further ado, I support this proposal. From christian at errxtx.net Tue Nov 25 17:46:13 2008 From: christian at errxtx.net (Christian Meutes) Date: Tue, 25 Nov 2008 17:46:13 +0100 Subject: [address-policy-wg] Revised 2006-01 set back to Discussion Phase (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <20081125105622.618F22F592@herring.ripe.net> References: <20081125105622.618F22F592@herring.ripe.net> Message-ID: Howdy, --On Thuesday, 25. November 2008 11:56 +0100 Ana Matic wrote: > We encourage you to review this policy proposal and send your comments > to before 23 December 2008. I support it. Cheers, Christian From llc at dansketelecom.com Tue Nov 25 19:10:57 2008 From: llc at dansketelecom.com (Lars Lystrup Christensen) Date: Tue, 25 Nov 2008 19:10:57 +0100 Subject: [address-policy-wg] Revised 2006-01 set back to Discussion Phase (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: References: <20081125105622.618F22F592@herring.ripe.net> Message-ID: <44417CD2F19FEA4F885088340A71D332019907F0@mail.office.dansketelecom.com> I support it as well... ______________________________________ Med venlig hilsen / Kind regards Lars Lystrup Christensen Director of Engineering, CCIE(tm) #20292 Danske Telecom A/S - Clearwire Denmark Sundkrogsgade 13, 4 2100 K?benhavn ? -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Christian Meutes Sent: 25. november 2008 17:46 To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] Revised 2006-01 set back to Discussion Phase (Provider Independent (PI) IPv6 Assignments for End User Organisations) Howdy, --On Thuesday, 25. November 2008 11:56 +0100 Ana Matic wrote: > We encourage you to review this policy proposal and send your comments > to before 23 December 2008. I support it. Cheers, Christian From nick at inex.ie Tue Nov 25 19:20:47 2008 From: nick at inex.ie (Nick Hilliard) Date: Tue, 25 Nov 2008 18:20:47 +0000 Subject: [address-policy-wg] Revised 2006-01 set back to Discussion Phase (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <20081125105622.618F22F592@herring.ripe.net> References: <20081125105622.618F22F592@herring.ripe.net> Message-ID: <492C41FF.5040202@inex.ie> Ana Matic wrote: > We encourage you to review this policy proposal and send your comments > to before 23 December 2008. This proposal has improved substantially since v3.0, and it is long overdue. While I support it as-is, I have two comments. - the "temporary" status of the proposal has been changed to permanent. This is a good move, and merely recognition that reclaiming address space is an enormously difficult challenge, even if assigned on a temporary basis. - while a requirement for multihoming is useful, it should be made clear during implementation that this is not necessarily a requirement for multihoming using ASNs and BGP on the public Internet (however we care to define that term). Private interconnection to third parties is also a fully legitimate justification for assignment of provider independent number resources. Nick From Remco.vanMook at eu.equinix.com Tue Nov 25 19:27:14 2008 From: Remco.vanMook at eu.equinix.com (Remco van Mook) Date: Tue, 25 Nov 2008 19:27:14 +0100 Subject: [address-policy-wg] Revised 2006-01 set back to Discussion Phase (Provider Independent (PI) IPv6 Assignments for End User Organisations) Message-ID: <2E61C47A190CA44ABFCF23147E57E4BC5BED65@NLEN1EX1.eu.win.equinix.com> With the comments of Nick in mind I support this proposal. Best, Remco ----- Original Message ----- From: address-policy-wg-admin at ripe.net To: address-policy-wg at ripe.net Cc: Jordi Palet Martinez Sent: Tue Nov 25 18:20:47 2008 Subject: Re: [address-policy-wg] Revised 2006-01 set back to Discussion Phase (Provider Independent (PI) IPv6 Assignments for End User Organisations) Ana Matic wrote: > We encourage you to review this policy proposal and send your comments > to before 23 December 2008. This proposal has improved substantially since v3.0, and it is long overdue. While I support it as-is, I have two comments. - the "temporary" status of the proposal has been changed to permanent. This is a good move, and merely recognition that reclaiming address space is an enormously difficult challenge, even if assigned on a temporary basis. - while a requirement for multihoming is useful, it should be made clear during implementation that this is not necessarily a requirement for multihoming using ASNs and BGP on the public Internet (however we care to define that term). Private interconnection to third parties is also a fully legitimate justification for assignment of provider independent number resources. Nick 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 garry at nethinks.com Tue Nov 25 20:45:45 2008 From: garry at nethinks.com (Garry Glendown) Date: Tue, 25 Nov 2008 20:45:45 +0100 Subject: [address-policy-wg] Revised 2006-01 set back to Discussion Phase (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <492C41FF.5040202@inex.ie> References: <20081125105622.618F22F592@herring.ripe.net> <492C41FF.5040202@inex.ie> Message-ID: <492C55E9.8080804@nethinks.com> Nick Hilliard wrote: > - while a requirement for multihoming is useful, it should be made clear > during implementation that this is not necessarily a requirement for > multihoming using ASNs and BGP on the public Internet (however we care to > define that term). Private interconnection to third parties is also a > fully legitimate justification for assignment of provider independent > number resources. > Concurred. E.g., IPv6 might not be available from the second provider of a customer yet ... Another "pro": Having customers with operational (and multi-homed-able) IPv6 might increase pressure on those other ISPs that still haven't put IPv6 into productive operation ... -garry From drixter at e-utp.net Tue Nov 25 20:23:39 2008 From: drixter at e-utp.net (Marcin Gondek) Date: Tue, 25 Nov 2008 20:23:39 +0100 Subject: [address-policy-wg] Revised 2006-01 set back to Discussion Phase (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <20081125105622.618F22F592@herring.ripe.net> References: <20081125105622.618F22F592@herring.ripe.net> Message-ID: <4D63E8A8-C0AF-44C2-B6AB-4BCC95AB6581@e-utp.net> Wiadomo?? napisana w dniu 2008-11-25, o godz. 11:56, przez Ana Matic: > PDP Number: 2006-01 > Provider Independent (PI) IPv6 Assignments for End User Organisations > > Dear Colleagues, > > The text of the policy proposal 2006-01 has been revised based on > the community feedback received > on the mailing list and during RIPE 56 and 57. > > We have published the new version (version 4) today. > As a result a new Discussion Phase is set for the proposal. You can > find the full proposal at: > As I'm not RIPE member but IPv6 user, I support it and waiting for implementation. Regards, -- Marcin Gondek / Drixter e-utp.net NIP: PL1181589645 REGON: 140584662 Tel. +48602159929 Fax. +48222012418 office at e-utp.net http://www.e-utp.net From slz at baycix.de Tue Nov 25 20:58:15 2008 From: slz at baycix.de (Sascha Lenz) Date: Tue, 25 Nov 2008 20:58:15 +0100 Subject: [address-policy-wg] Revised 2006-01 set back to Discussion Phase (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <20081125105622.618F22F592@herring.ripe.net> References: <20081125105622.618F22F592@herring.ripe.net> Message-ID: <492C58D7.8080208@baycix.de> Hi, Ana Matic schrieb: > PDP Number: 2006-01 > Provider Independent (PI) IPv6 Assignments for End User Organisations > > Dear Colleagues, > > The text of the policy proposal 2006-01 has been revised based on the community feedback received > on the mailing list and during RIPE 56 and 57. > > We have published the new version (version 4) 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/2006-01.html > > > We encourage you to review this policy proposal and send your comments > to before 23 December 2008. the proposal still has my full support. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz at baycix.de = = Network Design & Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ======================================================================== From frederic at placenet.org Tue Nov 25 21:03:55 2008 From: frederic at placenet.org (Frederic) Date: Tue, 25 Nov 2008 21:03:55 +0100 Subject: [address-policy-wg] Revised 2006-01 set back to Discussion Phase (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <492C58D7.8080208@baycix.de> References: <20081125105622.618F22F592@herring.ripe.net> <492C58D7.8080208@baycix.de> Message-ID: <492C5A2B.2010105@placenet.org> Sascha Lenz a ?crit : > Hi, > > Ana Matic schrieb: >> PDP Number: 2006-01 >> Provider Independent (PI) IPv6 Assignments for End User Organisations >> >> Dear Colleagues, >> >> The text of the policy proposal 2006-01 has been revised based on the >> community feedback received >> on the mailing list and during RIPE 56 and 57. >> We have published the new version (version 4) 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/2006-01.html >> >> >> We encourage you to review this policy proposal and send your comments >> to before 23 December 2008. > > the proposal still has my full support. > Yes we full support too. bst regards. Frederic CELLA From michael.dillon at bt.com Tue Nov 25 21:14:42 2008 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Tue, 25 Nov 2008 20:14:42 -0000 Subject: [address-policy-wg] Revised 2006-01 set back to Discussion Phase (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <20081125105622.618F22F592@herring.ripe.net> Message-ID: > http://www.ripe.net/ripe/policies/proposals/2006-01.html I don't like this. >IPv6 Provider Independent (PI) Assignments: >To qualify for an IPv6 PI address space, an organisation must: >a) not be an IPv6 LIR; >b) demonstrate that it will be multihomed (for example by showing contracts of the peering partners) "For example" should not be in a policy sentence like this. This sentence style encourages the writer to be too brief. If it is really necessary to include examples of what constitutes a "demonstration" of multihoming, then it should be enumerated like this: 1) faxing the first page and signature page of contracts of peering partners 2) asking peering partners to send supporting email direct to RIPE 3) faxing orders for peering interconnect circuits 4) providing a letter from a signing officer of the organization stating that it will be multihoming in the near future >c) meet the requirements of the policies described in the RIPE NCC document entitled "Contractual Requirements for Provider Independent Resources Holders in the RIPE NCC Service Region" This is awful. The policies described in the referenced document basically boil down to requiring the end user to have a contractual relationship with an LIR or with RIPE. Could we not say simply: c) provide a faxed copy of the first page and signature page of the signed end user contract with an LIR or RIPE. >The prefix will be assigned by the RIPE NCC directly to the End User Organisations upon a request properly submitted to the RIPE NCC, either directly or through a sponsoring LIR. >The minimum size of the assignment is a /48. Organisations requesting a larger assignment (shorter prefix) must provide documentation justifying the need for additional subnets. >Additional assignments may also be made when there is a technical need demanding this or usage justified. When possible, these further assignments will be made from an adjacent address block. >Assignments will be allocated from a separate 'designated block' to facilitate filtering practices. >The PI assignment cannot be further assigned to other organisations. --Michael Dillon From berni at birkenwald.de Tue Nov 25 22:25:57 2008 From: berni at birkenwald.de (Bernhard Schmidt) Date: Tue, 25 Nov 2008 22:25:57 +0100 Subject: [address-policy-wg] Revised 2006-01 set back to Discussion Phase (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <20081125105622.618F22F592@herring.ripe.net> References: <20081125105622.618F22F592@herring.ripe.net> Message-ID: <492C6D65.4040803@birkenwald.de> > PDP Number: 2006-01 > Provider Independent (PI) IPv6 Assignments for End User Organisations ... > We have published the new version (version 4) 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/2006-01.html Under the assumption that | c) meet the requirements of the policies described in the RIPE NCC document entitled | "Contractual Requirements for Provider Independent Resources Holders in | the RIPE NCC Service Region" won't be just a paper tiger I fully support this proposal. Bernhard From president at ukraine.su Tue Nov 25 23:07:30 2008 From: president at ukraine.su (Max Tulyev) Date: Wed, 26 Nov 2008 00:07:30 +0200 Subject: [address-policy-wg] Revised 2006-01 set back to Discussion Phase (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <492C41FF.5040202@inex.ie> References: <20081125105622.618F22F592@herring.ripe.net> <492C41FF.5040202@inex.ie> Message-ID: <492C7722.1020200@ukraine.su> Nick Hilliard wrote: > - while a requirement for multihoming is useful, it should be made clear > during implementation that this is not necessarily a requirement for > multihoming using ASNs and BGP on the public Internet (however we care to > define that term). Private interconnection to third parties is also a > fully legitimate justification for assignment of provider independent > number resources. I also saw a lot of cases when PI announced via upstream's ASN, not via user's one. I think, it is OK and it is not against multihoming, as this ASN is multihomed of course. -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253 at FIDO) From leo.vegoda at icann.org Wed Nov 26 08:08:31 2008 From: leo.vegoda at icann.org (Leo Vegoda) Date: Tue, 25 Nov 2008 23:08:31 -0800 Subject: [address-policy-wg] Revised 2006-01 set back to Discussion Phase (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <20081125105622.618F22F592@herring.ripe.net> Message-ID: Hi, > To qualify for an IPv6 PI address space, an organisation must: > a) not be an IPv6 LIR; Does this mean that the IPv6 PI assignment must be reclaimed by the RIPE NCC if a company that runs an LIR and has an IPv6 allocation buys a company that uses an IPv6 PI assignment? [...] > c) meet the requirements of the policies described in the RIPE NCC document > entitled ?Contractual Requirements for Provider Independent Resources Holders > in the RIPE NCC Service Region? Is this document available for review yet? It seems to form an integral part of the proposed policy. [...] > The minimum size of the assignment is a /48. Organisations requesting a larger > assignment (shorter prefix) must provide documentation justifying the need for > additional subnets. > > Additional assignments may also be made when there is a technical need > demanding this or usage justified. When possible, these further assignments > will be made from an adjacent address block. The phrase "a technical need demanding this or usage justified" is a bit vague. It would be nice to have some kind of guide so that applicants and the RIPE NCC have an idea of what the bar is (meant to be). > Assignments will be allocated from a separate 'designated block' to facilitate I'd suggest changing the word "allocated" to "taken". Regards, Leo Vegoda From sergey at devnull.ru Wed Nov 26 08:13:58 2008 From: sergey at devnull.ru (sergey miassoedov) Date: Wed, 26 Nov 2008 08:13:58 +0100 Subject: [address-policy-wg] Revised 2006-01 set back to Discussion Phase (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: References: <20081125105622.618F22F592@herring.ripe.net> Message-ID: <1905479305.20081126081358@devnull.ru> Hello, Wednesday, November 26, 2008, 8:08:31 AM, you wrote: >> c) meet the requirements of the policies described in the RIPE NCC document >> entitled ?Contractual Requirements for Provider Independent Resources Holders >> in the RIPE NCC Service Region? LV> Is this document available for review yet? It seems to form an integral part LV> of the proposed policy. This is a part of accepted policy. http://ripe.net/ripe/draft-documents/ripe-new-draft2007-01-v4.html -- Kind regards, sergey myasoedov From leo.vegoda at icann.org Wed Nov 26 10:21:13 2008 From: leo.vegoda at icann.org (Leo Vegoda) Date: Wed, 26 Nov 2008 01:21:13 -0800 Subject: [address-policy-wg] Revised 2006-01 set back to Discussion Phase (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <1905479305.20081126081358@devnull.ru> Message-ID: Hi Sergey, On 26/11/2008 8:13, "sergey miassoedov" wrote: [...] >>> c) meet the requirements of the policies described in the RIPE NCC document >>> entitled ?Contractual Requirements for Provider Independent Resources >>> Holders >>> in the RIPE NCC Service Region? > LV> Is this document available for review yet? It seems to form an integral > part > LV> of the proposed policy. > > This is a part of accepted policy. > http://ripe.net/ripe/draft-documents/ripe-new-draft2007-01-v4.html Thanks for the reference. Much appreciated! It would be fab if the RIPE NCC could provide appropriate linkage from the proposal page to the Contractual Requirements document, so that anyone reviewing the proposal can easily read the associated document. Thanks, Leo From gerald at ax.tc Wed Nov 26 10:35:39 2008 From: gerald at ax.tc (gerald at ax.tc) Date: Wed, 26 Nov 2008 10:35:39 +0100 Subject: [address-policy-wg] Revised 2006-01 set back to Discussion Phase (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: <20081125105622.618F22F592@herring.ripe.net> References: <20081125105622.618F22F592@herring.ripe.net> Message-ID: <492D186B.8030501@ax.tc> On 25.11.2008 11:56, Ana Matic wrote: > PDP Number: 2006-01 > Provider Independent (PI) IPv6 Assignments for End User Organisations > > Dear Colleagues, > > The text of the policy proposal 2006-01 has been revised based on the community feedback received > on the mailing list and during RIPE 56 and 57. > > We have published the new version (version 4) 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/2006-01.html > > > We encourage you to review this policy proposal and send your comments > to before 23 December 2008. We as a LIR (pop-interactive/DE) support this proposal. -- Gerald Krause From anamatic at ripe.net Wed Nov 26 15:59:05 2008 From: anamatic at ripe.net (Ana Matic) Date: Wed, 26 Nov 2008 15:59:05 +0100 Subject: [address-policy-wg] Revised 2006-01 set back to Discussion Phase (Provider Independent (PI) IPv6 Assignments for End User Organisations) In-Reply-To: References: Message-ID: <492D6439.7060103@ripe.net> Dear Leo, we have now added the link from the proposal page to the document "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region". You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2006-01.html Regards, Ana Matic RIPE NCC Leo Vegoda wrote: > Hi Sergey, > > On 26/11/2008 8:13, "sergey miassoedov" wrote: > > [...] > > >>>> c) meet the requirements of the policies described in the RIPE NCC document >>>> entitled ?Contractual Requirements for Provider Independent Resources >>>> Holders >>>> in the RIPE NCC Service Region? >>>> >> LV> Is this document available for review yet? It seems to form an integral >> part >> LV> of the proposed policy. >> >> This is a part of accepted policy. >> http://ripe.net/ripe/draft-documents/ripe-new-draft2007-01-v4.html >> > > Thanks for the reference. Much appreciated! > > It would be fab if the RIPE NCC could provide appropriate linkage from the > proposal page to the Contractual Requirements document, so that anyone > reviewing the proposal can easily read the associated document. > > Thanks, > > Leo > >