- address-policy-wg - mailman.ripe.net

RE: [address-policy-wg] getting second IPv6 PA as a LIR
by poty＠iiat.ru 04 May '11

04 May '11

On 05/04/2011 10:25 AM, poty(a)iiat.ru wrote: > When we add several hundred thousands IPV6 routes we are going to > extremely upgrades our infrastructure, but smaller ISP (business...) > which can't pay $100/month will not be able to do so definitely. > You know - they are different. :) Mostly they have distributed computing > environment and hardware programmed to do specific operations, huge > backbones and many-many other things which PC lacks. Not really. BGP table calculation isn't distributed (you need single place for this calculation final table). If we imagine your hundred thousands IPV6 routes scenario, CPU on these "hardware" routers will have troubles, too. --------------- I'm not arguing about that. All equipment will have troubles in case of routing table explosions. It's my point too. But BGP table calculation is only one process in the router. As Sascha Lenz have pointed out - the main problem with PC is forwarding (calculating the interface to which the packets should go and actually put it here). In this case the distributed calculations have the biggest impact. /////////////////////////// > The widespread PI will definitely adds significant amount to the number > of routes, so your forwarding problem will be much worse. Deaggregation of PA address space causes similar problems and nobody really can do anything with this. And routers aren't making difference between PI and PA. Look into IPv4 routing table, what mess is here caused not by PI assignments, but by announced /24 from aggregatable /20, /19, from PA blocks... same thing is already happening in IPv6, where're more specifics than /32 announced from PA blocks. With blocking PI you cause only one thing - people will start deaggregation of PA space more widely. And any kind of (RIPE) policy cannot forbid this. For each restriction in RIPE policy people discover some policy-conforming workaround... PI vs PA separation is just administrative thing for RIPE NCC evidence. It's impossible to force network operators filter some prefixes, just because prefix is deaggregated. You can filter in your own network, but probably nobody will filter his paying customer - money are on the first place... --------------------- While I could agree with you in some point I cannot agree fully. We all know the "rule" for IPv4 about not routing longer than /24. I got this problem with some of our PI customers and have learnt, that the money here not always help. So, the filtering is not imaginary thing. Then the deaggregation would be limited (in spite of unlimited PIs). On the other hand: if the problem arises in the future the more organized (and less in numbers) LIRs can come to agreement easier than much more "independent" crowd of PI-holders which are even now deaf to any arguments, just claiming "independence" for any cost. Of course some "clever people" will break the rules in some "smart" ways, but I don't think it would be so widespread comparing to the "get as much as you want for free" paradigm. Regards, Vladislav Potapov IIAT, Ltd.

3 3

RE: [address-policy-wg] getting second IPv6 PA as a LIR
by poty＠iiat.ru 04 May '11

04 May '11

On 05/04/2011 11:06 AM, poty(a)iiat.ru wrote: > I'm not arguing about that. All equipment will have troubles in case of routing table explosions. It's my point too. I don't expect any huge explosion. Reasons was described already in the list. Growth will copy current IPv4 curve... ----------------- Both "sides" doesn't have arguments and reasons, just predictions. PI in IPv4 was a long developed decision, with a lot of restrictions from the beginning, several tuning across its life. So IPv6 PIs will not have the same curve definitely. You have ignored all other my arguments. \\\\\\\\\\\\\\\\\\\\\\\\\\\\ On 05/04/2011 11:10 AM, poty(a)iiat.ru wrote: > Even at 200Mbit|s with 2 upstreams it is almost impossible to deal > with full table. On 05/04/2011 11:06 AM, poty(a)iiat.ru wrote: > the main problem with PC is forwarding (calculating the interface to which the packets should go and actually put it here). In this case the distributed calculations have the biggest impact. With proper hardware not really. It's not a problem handle 10Gbps interface on PC these days. And I know about real deployment, where PC is used for routing >8Gbps of traffic. ------------------------- To HAVE the interface doesn't mean to USE it fully. Routing 8Gbps on a PC is unrealistic definitely, even in theory. Many people (try to) pass the desirable for reality. You can certainly incorporate some hardware port accelerators in a PC, additional interfaces, make a cluster... But it seems it would be not cheap at first and claim a competence which small ISPs can't afford at second. It is not a cheap PC with common OS we are speaking about. ///////////////////////////////// > We all know the "rule" for IPv4 about not routing longer than /24. I got this problem with some of our PI customers and have learnt, that the money here not always help. So, the filtering is not imaginary thing. Then the deaggregation would be limited (in spite of unlimited PIs). Minimum PI assignment in IPv6 is /48 - see RIPE 512. Also assigned anycasts in IPv6 are /48 - i expect, that /48 for IPv6 becames similar well-know minimum rule as /24 in IPv4 world. There're legal operational /48 assignments these days - for anycasted TLD-DNS, for example. And /48 can be assigned from /32 PA easily, there's lot of space available. And then easily announced into the BGP and almost nobody will filter it (see current IPv6 table)... ------------------- If it is so easy - use it! Why then you should apply for PI? In case of problems RIPE (for example) would speak with a single LIR, not with thousands of widespread customers. Regards, Vladislav

2 1

RE: [address-policy-wg] getting second IPv6 PA as a LIR
by poty＠iiat.ru 04 May '11

04 May '11

> Sascha Lenz [SLZ-RIPE] > ---------------------- > Small companies start with small routers, PC based Linux Quagga Boxes, > or Routerboards, > or Juniper J-Series or whatever - not really much costs here (see other > replies). > -------------- > > They will not be able to "start with small routers", because calculating > constantly changing routes (presumable from several sources) costs > processing power, routing decisions with huge routing table cost > processing power, even receiving and sending plain packets costs > processing power. And all this costs money. PC-based routers are not > able to do all of this at once and in this anount. > The "selfish" small ISPs could easily drive himself into trap of trouble > when they have to spent much more money for equipment (and made all > others do it) rather than using PA from LIR. Don't worry about computing power, small ISPs usually are less than 200Mbit/s total upstreams, to even if they handle 1G with today's CPUs it is not a big deal (rather stability can be a problem). More, probably within 1-2 years there will be a set of drivers/kernel support of handling packets by high efficients processors from... graphics ;) ------------------ I'm waiting for the event some 10 years by now. Until now it is only bad predictions. Even at 200Mbit|s with 2 upstreams it is almost impossible to deal with full table. Regards, Vladislav Potapov IIAT, Ltd.

1 0

RE: [address-policy-wg] getting second IPv6 PA as a LIR
by poty＠iiat.ru 04 May '11

04 May '11

Hay, Am 03.05.2011 um 15:37 schrieb <poty(a)iiat.ru> <poty(a)iiat.ru>: >>> And why wouldn't the Internet work with 600,000 prefixes in the DFZ? >> >> Now all of a sudden for instance Cisco 7600 3CXL isn't enough to old a > full table (at around 750k). >> >> Also, IPv6 uses twice the TCAM resources as IPv4... > > so, basically what you are saying is that you know that your routers > need an upgrade in 5 years and you > don't want to pay for an upgrade or you can't figure out a business plan > which covers the costs for that? > But you are telling small ISPs/NCOs/"hobbyusers"/whatever THEY don't get > their business plan right > if they don't can afford paying $$$ for PI space or rather would prefer > to pay other bills with the > money? WTF?! > > ------ > No, the problem that the small ISPs you are speaking about will have to > spend that money to swallow such routing table. And it is not $2000, > "slightly" more... Sascha Lenz [SLZ-RIPE] ---------------------- Small companies start with small routers, PC based Linux Quagga Boxes, or Routerboards, or Juniper J-Series or whatever - not really much costs here (see other replies). -------------- They will not be able to "start with small routers", because calculating constantly changing routes (presumable from several sources) costs processing power, routing decisions with huge routing table cost processing power, even receiving and sending plain packets costs processing power. And all this costs money. PC-based routers are not able to do all of this at once and in this anount. The "selfish" small ISPs could easily drive himself into trap of trouble when they have to spent much more money for equipment (and made all others do it) rather than using PA from LIR.

3 2

RE: [address-policy-wg] getting second IPv6 PA as a LIR
by poty＠iiat.ru 04 May '11

04 May '11

[...] > Sascha Lenz [SLZ-RIPE] > ---------------------- > Small companies start with small routers, PC based Linux Quagga Boxes, > or Routerboards, > or Juniper J-Series or whatever - not really much costs here (see other > replies). > -------------- > > They will not be able to "start with small routers", because calculating > constantly changing routes (presumable from several sources) costs > processing power, routing decisions with huge routing table cost > processing power, even receiving and sending plain packets costs > processing power. And all this costs money. PC-based routers are not > able to do all of this at once and in this anount. > The "selfish" small ISPs could easily drive himself into trap of trouble > when they have to spent much more money for equipment (and made all > others do it) rather than using PA from LIR. > > do you have any numbers on that? because i don't see it. Even my old Pentium4 route servers do very nicely with that. --------------------- With what? My company is very small and even currently used hardware routers can't handle 3-4 (1Gbit|sec) upstream connections efficiently (doing BGP in addition of course). When we add several hundred thousands IPV6 routes we are going to extremely upgrades our infrastructure, but smaller ISP (business...) which can't pay $100/month will not be able to do so definitely. > Sascha Lenz [SLZ-RIPE] ------------------------ And look at the processing power of the Route Engines of the hardware routers... wow are they slow! ------------------------ You know - they are different. :) Mostly they have distributed computing environment and hardware programmed to do specific operations, huge backbones and many-many other things which PC lacks. The widespread PI will definitely adds significant amount to the number of routes, so your forwarding problem will be much worse. Regards, Vladislav Potapov IIAT, Ltd. P.S. Sorry for some earlier messages without signature.

2 1

getting second IPv6 PA as a LIR
by Marcin Kuczera 04 May '11

04 May '11

hello, Is it possible to discuss ability of getting second IPv6 PA allocation as a LIR without filling first one ? The reason for such a need is a change of IPv6 PI rules, it is no longer possible to use IPv6 PI as ISP (/128 for subscibers). So, solution is that LIR segment /32 into smaller units an assigning them to their SponsorLIR agreement customers. However, first /32 IPv6 allocation is in our case advertized as whole by our AS13000. Once some internal policy for suballocations is used, this prefix can not be divided into smaller prefixes. For SponsorLIR agreement customers - little ISPs, willing to advertise their i.e. /48 from our /32 without any overlapping prefixes, second /32 IPv6 PA (not advertised as whole by LIRs ASes) would be great... Regards, Marcin

18 60

RE: [address-policy-wg] getting second IPv6 PA as a LIR
by poty＠iiat.ru 04 May '11

04 May '11

-----Original Message----- From: Martin Millnert [mailto:millnert@gmail.com] Sent: Tuesday, May 03, 2011 6:23 PM To: Potapov Vladislav Cc: slz(a)baycix.de; address-policy-wg(a)ripe.net Subject: Re: [address-policy-wg] getting second IPv6 PA as a LIR On Tue, May 3, 2011 at 9:37 AM, <poty(a)iiat.ru> wrote: >>> And why wouldn't the Internet work with 600,000 prefixes in the DFZ? >> >> Now all of a sudden for instance Cisco 7600 3CXL isn't enough to old a > full table (at around 750k). >> >> Also, IPv6 uses twice the TCAM resources as IPv4... > > so, basically what you are saying is that you know that your routers > need an upgrade in 5 years and you > don't want to pay for an upgrade or you can't figure out a business plan > which covers the costs for that? > But you are telling small ISPs/NCOs/"hobbyusers"/whatever THEY don't get > their business plan right > if they don't can afford paying $$$ for PI space or rather would prefer > to pay other bills with the > money? WTF?! > > ------ > No, the problem that the small ISPs you are speaking about will have to > spend that money to swallow such routing table. And it is not $2000, > "slightly" more... Not really; normal PC RAM is pretty cheap. 16GB ECC/REG ~400 EUR. /M -------- It's not about storing, it's all about using. And here we get to the problem.

1 0

help
by Kovac, Pavol 03 May '11

03 May '11

Dear RIPE wg, I would like to ask you about present proposal "Removal of Multihomed requirement for IPv6 PI" version 1.0 12 April 2011. I see Current Phase Ends: 13 May 2011. What will happened after 13rd May ? I registered as a subscriber of this mailing list. Will I receive any info about changes on this proposal ? Thank you Pavol Kovac

2 1

Re: [address-policy-wg] 2008-08 (Initial Certification Policy
by Sascha Luck 03 May '11

03 May '11

Hi ap-wg, I do NOT support this proposal for the very same reasons that Malcolm so eruditely laid out in his post. All that's left for me is to state that, in this case, the cure is infinitely worse than the disease. Kind Regards, Sascha Luck

1 0

2006-05 New Draft Document Published (PI Assignment Size)
by Emilio Madaio 26 Apr '11

26 Apr '11

Dear Colleagues, Following the feedback received at RIPE 60, the proposal 2006-05 was taken over by a new proposer and a new version was produced. The draft document for the new version of the proposal has been published. The impact analysis that was conducted for this proposal has also been published. You can find the full proposal at: http://ripe.net/ripe/policies/proposals/2006-05.html and the draft document at: http://ripe.net/ripe/draft-documents/ripe-492-draft2006-05.html We encourage you to read the draft document text and send any comments to address-policy-wg(a)ripe.net before 18 November 2010. Regards Emilio Madaio Policy Development Officer RIPE NCC

10 16

2008-08 Last Call for Comments (Initial Certification Policy in the RIPE NCC Service Region)
by Emilio Madaio 26 Apr '11

26 Apr '11

Dear Colleagues, The proposal described in 2008-08 is now at its Concluding Phase, as per decision of the Address Policy WG Chairs. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2008-08 Please e-mail any final comments about this proposal to address-policy-wg(a)ripe.net before 24 May 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

2011-01 Discussion Period extended until 19 May 2011 (Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA)
by Emilio Madaio 26 Apr '11

26 Apr '11

Dear Colleagues, The Discussion Period for the global policy proposal 2011-01 has been extended, in agreement with the proposer, until 19 May 2011. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2011-01 We encourage you to review this policy proposal and send your comments to <address-policy-wg(a)ripe.net>. Regards, Emilio Madaio Policy Development Officer RIPE NCC

2 1

2008-08 New Draft Document Published (Initial Certification Policy in the RIPE NCC Service Region)
by Emilio Madaio 25 Apr '11

25 Apr '11

Dear Colleagues, Following the feedback received, the draft document for the proposal described in 2008-08 was edited and published. The new impact analysis that was conducted for this proposal has also been published. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2008-08 and the draft document at: http://www.ripe.net/ripe/policies/proposals/2008-08/draft We encourage you to read the draft document text and send any comments to address-policy-wg(a)ripe.net before 26 April 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC

3 2

Cosmetic Surgery Project: New Draft Document for IPv6 Address Allocation and Assignment Policy
by Emilio Madaio 20 Apr '11

20 Apr '11

Dear colleagues, At RIPE 59 in Lisbon in October 2009, the RIPE NCC announced that it would undertake a project to make various RIPE Policy Documents easier to understand without changing the meaning of the text. We have just finished merging the following three policies into one document: -ripe-512 "IPv6 Address Allocation and Assignment Policy" -ripe-451 "IPv6 Address Space Policy for Internet Exchange Points" -ripe-233 "IPv6 Addresses for Internet Root Servers in the RIPE Region" A draft of the new merged document is online and ready for community review at: http://www.ripe.net/ripe/updated-documents/ We encourage you to read this merged version and send any comments to address-policy-wg(a)ripe.net <mailto:address-policy-wg@ripe.net> by 18 May 2011. Kind Regards, Emilio Madaio Policy Development Officer RIPE NCC

2 1

AW: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6)
by Marcus.Gerdon 19 Apr '11

19 Apr '11

Michiel, > Not everything on the internet is a bussiness with needs and > a large bag of > cash. Please also consider the non-profit organisations with > valid reasons > of running their own PI network. I'd be quite interested in hearing/reading your thoughts about the 'valid reasons' you see. I currently can't think of any non-multihoming PI requirement in establishing internet access for enterprises (and non-profits / ngo are alike in the meanwhile) that validate driving additional cost for every network to support their PI without technical need. kind regards, Marcus

1 0

AP meeting at RIPE 62 - Agenda draft
by Gert Doering 15 Apr '11

15 Apr '11

Hi APWG folks, RIPE meeting orga, below you can find a draft for the RIPE address policy WG meeting's agenda, which will take place in Amsterdam in the following three time slots: Thursday, May 05, 09:00 - 10:30 Thursday, May 05, 11:00 - 12:30 Friday, May 06, 09:00 - 11:30 The exact time lines depend a bit on how much discussion is going on, so we might move items one time slot "up" or "down". If you have anything else you want to see on the agenda, or of we need to change anything, please let us know. regards, Gert Doering, APWG chair ---------------------------------------------------------------------- Thursday, 09:00-10:30 ---------------------------------------------------------------------- A. Administrative Matters (welcome, thanking the scribe, approving the minutes, etc.) B. Current Policy Topics - Emilio Madaio - global policy overview "what's going on?" - common policy topics in all regions (end of IPv4, transfers, ...) - overview over concluded proposals in the RIPE region since RIPE61 2010-05 Global Policy for IPv4 ... post exhaustion - withdrawn 2010-06 Registration Requirements for IPv6 ... Assignments - accepted 2010-07 Ambiguity cleanup on IPv6 Addr. ... Policy for IXP - withdrawn 2010-02 Allocations from the last /8 - accepted 2008-07 Effcient Use of Historical IPv4 Resources - withdrawn 2010-01 Temporary Internet Number Assignment Polices - Last Call - brief overview over new proposals (2011-01, 2011-02) C. Document Cosmetic Surgeries Project - Emilio Madaio - update on current status - how to go forward? D. On IPv6 Documentation Requirements - Marco Hogewoning Short presentation explaining how the policy change 2010-06 and AGGREGATED-BY-LIR affects day-to-day business for LIRs assigning IPv6 blocks to end users. E. Rough Edges of the current policies Report from the RIPE NCC Registration Services department on issues and unintended side-effects showing up in the daily implementation of the RIPE policies. o policy for upgrade of "initial /32 allocation" assigned to large carriers to "something large enough for their needs" (Explanation how these cases are currently handled, Alex Le Heux) o IPv6 PI discussions between RIPE members and the NCC RS (Explanation to the audience where the "sore spots" are, Alex L.H.) ---------------------------------------------------------------------- Thursday, 11:00-12:30 ---------------------------------------------------------------------- L. On IPv6 PI Policy Discussion how the IPv6 PA/PI policies can be reworked in a fundamental way to better fit the needs of all IPv6 Users. Discussion led by working group chairs. M. Discussion of open policy proposals - IPv6 related 2011-02 (IPv6 PI multihoming) N. On Transfer Guidelines - David Wilson bringing non-obvious problems with transfers into the open goal: write a RIPE BCP document ---------------------------------------------------------------------- Friday, 09:00-10:30 ---------------------------------------------------------------------- S. More Rough Edges of the current policies "if more things show up" T. Discussion of open policy proposals 2006-05 IPv4 PI Assignment Size [ONGOING] 2008-08 Initial Certification Policy for (...) Address Space Holders [ONGOING] 2010-01 Temporary Internet Number Assignment Policies [ONGOING] 2011-01 Global Policy for post exhaustion IPv4 allocation mechanisms by the IANA [NEW policy proposal] Y. Open Policy Hour "The Open Policy Hour (OPH) is a showcase for your policy ideas. If you have a policy proposal you'd like to debut, prior to formally submitting it, here is your opportunity." (Idea from ARIN policy meeting) Z. AOB -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

1 0

APNIC activated to 'Final /8' policy
by Sander Steffann 14 Apr '11

14 Apr '11

Hi WG, The IPv4 pool of APNIC has just gone below 1 /8. Therefore APNIC is the first RIR who has activated their 'Final /8' policy: http://www.apnic.net/services/apply-for-resources Sander Steffann APWG co-chair

1 0

2010-01 Last Call for Comments (Temporary Internet Number Assignment Policies)
by Emilio Madaio 13 Apr '11

13 Apr '11

Dear Colleagues, The proposal described in 2010-01 is now at its Concluding Phase. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2010-01 Please e-mail any final comments about this proposal to address-policy-wg(a)ripe.net before 11 May 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

AW: [address-policy-wg] 2008-08 New Draft Document Published (Initial Certification Policy in the RIPE NCC Service Region)
by Klaus.Kinder＠telekom.de 12 Apr '11

12 Apr '11

Gesendet von meinem Windows® Phone. ----- Ursprüngliche Nachricht ----- Von: Emilio Madaio <emadaio(a)ripe.net> Gesendet: Dienstag, 12. April 2011 17:16 An: policy-announce(a)ripe.net <policy-announce(a)ripe.net> Cc: address-policy-wg(a)ripe.net <address-policy-wg(a)ripe.net> Betreff: [address-policy-wg] 2008-08 New Draft Document Published (Initial Certification Policy in the RIPE NCC Service Region) Dear Colleagues, Following the feedback received, the draft document for the proposal described in 2008-08 was edited and published. The new impact analysis that was conducted for this proposal has also been published. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2008-08 and the draft document at: http://www.ripe.net/ripe/policies/proposals/2008-08/draft We encourage you to read the draft document text and send any comments to address-policy-wg(a)ripe.net before 26 April 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

AW: [address-policy-wg] 2008-08 New Draft Document Published (Initial Certification Policy in the RIPE NCC Service Region)
by Klaus.Kinder＠telekom.de 12 Apr '11

12 Apr '11

Gesendet von meinem Windows® Phone. ----- Ursprüngliche Nachricht ----- Von: Emilio Madaio <emadaio(a)ripe.net> Gesendet: Dienstag, 12. April 2011 17:16 An: policy-announce(a)ripe.net <policy-announce(a)ripe.net> Cc: address-policy-wg(a)ripe.net <address-policy-wg(a)ripe.net> Betreff: [address-policy-wg] 2008-08 New Draft Document Published (Initial Certification Policy in the RIPE NCC Service Region) Dear Colleagues, Following the feedback received, the draft document for the proposal described in 2008-08 was edited and published. The new impact analysis that was conducted for this proposal has also been published. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2008-08 and the draft document at: http://www.ripe.net/ripe/policies/proposals/2008-08/draft We encourage you to read the draft document text and send any comments to address-policy-wg(a)ripe.net before 26 April 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

Status of 2010-01 (Temporary Internet Number Assignment Policies)
by Gert Doering 12 Apr '11

12 Apr '11

Dear AP Working Group, RIPE Policy Proposal 2010-01 (Temporary Internet Number Assignment Policies) concluded its Last Call phase on 28 December 2011. After consultation between the Working Group Chairs, however, it has been decided that reporting of the process in this case was insufficient, that is, the working group has not been properly informed why the WG chairs have decided to go to Last Call. It has therefore been decided that the Last Call phase for this proposal should be repeated. Emilio will announce a new Last Call phase today or tomorrow. The reason why we decided to go for Last Call in the first place, and are now doing it again: - Feedback to the mailing list regarding the proposal itself has been mostly positive. - A few people voiced concerns in the mailing list discussion, and at the RIPE 61 meeting, but when specifically asked at the RIPE 61 meeting whether they wanted to see changes now or go ahead with the proposal, those raising the concerns agreed to move forward with the Policy Development Process and look at changes in future revisions. - It was agreed that it's important to have a reservation for temporary IPv4 assignments in place while there still *is* something to reserve - and that the specific details of the implementation can always be changed later on. You can read the full text of the proposal at: http://ripe.net/ripe/policies/proposals/2010-01.html The (draft) meetings from the RIPE 61 APWG meeting can be found here: http://www.ripe.net/ripe/groups/wg/ap/minutes/minutes-from-ripe-61 (just search for 2010-01) Gert Doering -- APWG Chair -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

1 1

RIPE IPv4 Pool Graph
by Ahmed Abu-Abed 06 Apr '11

06 Apr '11

Greetings, RIPE NCC is now publishing an IPv4 pool graph with weekly updates, and the latest data show five /8 blocks are remaining. More at http://www.ripe.net/internet-coordination/ipv4-exhaustion/ipv4-available-po… Regards, -Ahmed

1 0

IPv6 PI request is turned down for my multihomed hosting facility - Why?
by Jan Tuomi 01 Apr '11

01 Apr '11

Hi, A have made a request for a IPv6 PI / 48 allocation for my hosting facility. I am mostly hosting shared services, but I also have a lot of Co-located services for my customers. I am already multihomed to have redundancy from two ISPs for IPv4 and I am going to setup the IPv6 Network the same way. My ASN is 196704, and I am multihoming trough IP-Only (AS12552) and Telenor (AS8434). My sponsoring LIR says that I can get an assignment from their PA-space right away, BUT then I would not be multi-homed, so that is NOT an option. The answer I get from you (RIPE) is: You mentioned that several of the subnets will be used to provide services to your customers (LEON Hosting, Co-location/Dedicated servers). Unfortunately current IPv6 address assignment and allocation policy does not permit the use of IPv6 PI address space for these services. At this time IPv6 PI address space cannot be used for any service where a customer would receive a subnet of IP space (including a single IP). Therefore it cannot be used for colocation services, dedicated servers, SSL certificates etc. There is currently a discussion on exactly this subject within the RIPE community. Ventiro AB are welcome to sign up for the mailing list and join the discussion. You can find the mailing list here: http://www.ripe.net/ripe/mail/ripe-lists/address-policy-wg I need to be multihomed because i feel its safer to have redandancy from separate upstreams with separate infrastructure than buying the redundancy from one provider. My business is to keep servers running in my hosting facility, part of them owned by me, part of them owned by the customers. Some servers are shared among several customers, some are dedicated to one customer only. With todays technology as far as I know I must have separate IPs for SSL-enabled services. Is it RIPEs hidden agenda to put small hosting facilitys out of business with IPv6 and force all customers to use the bigger ISPs? When I requested my IPv4 PI allocation, I was already planning to also run with IPv6 to be prepared for the future and somehow try to help with the transition to IPv6, so people dont have the arguments that we dont use IPv6 because there is no services, its now so much services from a global point of view, but it wouldnt be IPv4 only.... So what should I do? What are my options? // Janne _______________________ V E N T I R O ______ Janne Tuomi, tuomi(a)ventiro.se Tel: +46-11-36 52 00 GSM: +46-70-224 6000 Fax: +46-11-36 52 05

14 31

2011-01 New Policy Proposal (Global Policy for post exhaustion IPv4 mechanisms by the IANA)
by Emilio Madaio 22 Mar '11

22 Mar '11

Dear Colleagues, A new Global 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/2011-01/ We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 18 April 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC

6 7

RE: [address-policy-wg] IPv6 allocations for 6RD
by Kurt Smolderen 21 Mar '11

21 Mar '11

I strongly support the idea of assigning a smaller prefix to ISPs which are in a state of deploying IPv6 but need to use transitional mechanism for (some of) their customers. Mark has described one of the problems very clear in his email: if an ISP has only a /32 prefix and needs to use all 32 IPv4 bits in the 6rd configuration, only a /64 can be delivered to the home instead of the desired /56 or /48. Needing all 32 bits is for instance the case when an ISP offers internet connectivity to some of its customers via a partnership with another ISP. However, I want to point to an additional problem which appears when an ISP wants to deploy native IPv6 but needs to roll out 6rd (or any other transitional technique) as well. For native IPv6, the ISP will create an IPv6 addressing plan. This will normally include separate prefixes for the ISP's own servers, the ISP's backbone, the ISP's customers etc. For the 6rd domain, the full /32 range is however needed. So at this stage, the ISP has two options: 1) Implement 6rd only 2) Implement native IPv6 only and exclude some customers from being able to use IPv6 (those which would normally be connected through 6rd) I strongly believe we all agree 6rd is only a temporary solution. So I can't imagine we would prefer skipping native IPv6 deployments in favor of IPv6 transitional mechanisms. I also believe we all agree we should enable IPv6 for as much customers as we can, which makes me conclude the second 'option' is not really an option at all... My primary concern is that any ISP - regardless of how small or big it is - can independently of other organizations/ ISPs move forward with IPv6 deployment. RIPE can support this by adapting a policy which - albeit for a limited time span - allows the assignment of a contiguous IPv6 prefix which size does not only depend on the amount of customers the ISP has, but also incorporates the needed technologies to 'IPv6-enable' as much customers as possible. Regards, -Kurt

7 17