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

Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region)
by Sander Steffann 02 Jun '11

02 Jun '11

Hello WG, I asked the RIPE NCC to get legal counsel on the possibilities of a court ordering the RIPE NCC to revoke or confiscate RPKI certificates. Here is the full answer we received: ========== The RIPE NCC is an association under Dutch law and therefore subject to the Dutch legislation. RIPE NCC has consulted several external lawyers, and has obtained an analysis of the legal situation based on current, existing Dutch legislation. This analysis takes into account Dutch Criminal, Civil and Administrative law. Certificates are directly linked to the registration of the Internet number resources. There is no specific Dutch legislation that can be used to order the deregistration of Internet number resources or change the registration details of Internet number resources. Nor is there any legislation that applies to the revocation of certificates over Internet number resources. In the absence of such legislation, a court cannot order the revocation of certificates. It is the RIPE NCC’s view, based on this analysis, that the RIPE NCC cannot be ordered to revoke resource certificates. ========== Of course laws can change, but the advice above may address some of the concerns raised about the RPKI infrastructure. Sander Steffann APWG co-chair

24 84

Cosmetic Surgery Project: Extended Review period on the new draft document for IPv6 Address Policy
by Emilio Madaio 31 May '11

31 May '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. As already announced, the latest draft document produced according to the project is available at: http://www.ripe.net/ripe/updated-documents/ This is the merger of the three policy documents: -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" The announcement of the publication of this new draft is available at: http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2011/msg00243… The Address Policy Working Group co-Chairs decided to extend the review period until 13 June 2011 to allow the community more time to give their feedback. We encourage you to read this merged version and send any comments to address-policy-wg(a)ripe.net by 13 June 2011. Best Regards Emilio Madaio Policy Development Officer RIPE NCC

3 2

2011-03 New Policy Proposal (Post-depletion IPv4 address recycling)
by Emilio Madaio 27 May '11

27 May '11

Dear Colleagues, A proposed change to RIPE Document ripe-509, "IPv4 Address Allocation and Assignment Policy for the RIPE NCC Service Region", is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2011-03/ We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 17 June 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC

19 40

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

23 May '11

>> 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...

10 14

re: [address-policy-wg] 2011-03 New Policy Proposal (Post-depletion IPv4 address recycling)
by boggits 20 May '11

20 May '11

On 20 May 2011 14:15, Remco Van Mook <Remco.vanMook(a)eu.equinix.com> wrote: > > Unsurprisingly, as the author I fully support this policy proposal and I > would for the sake of the PDP encourage others to voice their agreement as > well - no response means no progress. I also support the proposal, my only thought would be if it might be better to use this change to make an overwrite of the 'current process' at the point of the first allocation of a /22 from the last /8 for the purpose of the avoidance of doubt... J -- James Blessing 07989 039 476 -- James Blessing 07989 039 476

1 0

PP - 2011-02 - Removal of multihomed requirement for IPv6
by Adil H. Baghir 16 May '11

16 May '11

Hi, I highly support the policy... Adil H. Baghir Internet Development Chief Engineer Data & Solutions Planning and Design P.O.Box 69179 Riyadh 11423 Kingdom of Saudi Arabia Tel: +966 56 031 3263 Fax: +966 56 041 3263 Mobile: +966 542 33 66 00 eMail: a.baghir(a)mobily.com.sa<mailto:a.baghir@mobily.com.sa> [cid:image001.jpg@01CC13AD.44C394C0] ------Disclaimer------ This email and any files transmitted with are classified as confidential unless otherwise specified. This e-mail is intended solely for the use of the individual or entity to whom this e-mail is addressed. If you have received this email by mistake, please notify the sender and delete this e-mail immediately and permanently. Although measures were taken to free this e-mail and its attachments from any malicious code infection, it is the responsibility of the recipient to check this email and any attachments for the presence of such infection. The use of EEC(Mobily) e-mail service is limited for EEC(Mobily) business use only.

1 0

minutes from RIPE 61
by Gert Doering 13 May '11

13 May '11

Hi APWG, since there were no more comments, we have declared the minutes from RIPE 61 (Rome) to be final. The minutes can be found here: https://www.ripe.net/ripe/apwg/minutes61 Gert Doering -- NetMaster -- 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

RE: address-policy-wg digest, Vol 1 #1326 - 4 msgs
by ABS EMEA NIC - IPA Support AT&T 13 May '11

13 May '11

What is different when customer get PA instead of PI ? Don't you have to update the same prefix table ? Do you see any compromise between approve/deny this proposal ? let's say limited number of PI addresses for each End user ? Best regards _____________________________________ Pavol Kovac -----Original Message----- From: address-policy-wg-admin(a)ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of address-policy-wg-request(a)ripe.net Sent: Friday, May 13, 2011 12:00 PM To: address-policy-wg(a)ripe.net Subject: address-policy-wg digest, Vol 1 #1326 - 4 msgs Send address-policy-wg mailing list submissions to address-policy-wg(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit http://www.ripe.net/mailman/listinfo/address-policy-wg or, via email, send a message with subject or body 'help' to address-policy-wg-request(a)ripe.net You can reach the person managing the list at address-policy-wg-admin(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of address-policy-wg digest..." Today's Topics: 1. Removal of multihomed requirement for IPv6 (Elmar Germann) 2. Re: Removal of multihomed requirement for IPv6 (Sascha Lenz) 3. FW: [address-policy-wg] Removal of multihomed requirement for IPv6 (poty(a)iiat.ru) 4. Re: Removal of multihomed requirement for IPv6 (thabet(a)gmail.com) --__--__-- Message: 1 Date: Thu, 12 May 2011 22:36:16 +0200 (CEST) From: Elmar Germann <germann(a)global-village.de> To: address-policy-wg(a)ripe.net Subject: [address-policy-wg] Removal of multihomed requirement for IPv6 Hello, we do not support this policy. Removing the requirement for multihomed announcements would simply result in more unnecessary PI assignments which will increase the prefix table. We were already asked from several customers for new PI assignments just to draw down the work in case of an ISP change. PI address space should always be bound to technical requirements so that only end users with real requirements are able to request an assignment. I agree that there's currently a discriminating between IPv6 PA und PI address space, but the conculsion should be changeing the policy for the PA address space and not offering PI address space without technical requirements. Kind regards, Elmar Germann. -- Global Village GmbH Tel +49 2855 9651 0 GF Marcus Faure Mehrumer Str. 16 Fax +49 2855 9651 110 Amtsgericht Duisburg HRB9987 D-46562 Voerde eMail info(a)globvill.de Ust-Id DE180295363 --__--__-- Message: 2 Subject: Re: [address-policy-wg] Removal of multihomed requirement for IPv6 From: Sascha Lenz <slz(a)baycix.de> Date: Fri, 13 May 2011 09:47:34 +0200 To: address-policy-wg(a)ripe.net Hay, Am 12.05.2011 um 22:36 schrieb Elmar Germann: > Hello, >=20 > we do not support this policy. Removing the requirement for multihomed = announcements would simply result in more unnecessary PI assignments = which will increase the prefix table. We were already asked from several = customers for new PI assignments just to draw down the work in case of = an ISP change. PI address space should always be bound to technical = requirements so that only end users with real requirements are able to = request an assignment. > I agree that there's currently a discriminating between IPv6 PA und PI = address space, but the conculsion should be changeing the policy for the = PA address space and not offering PI address space without technical = requirements. that might be a rather shortsighted and possibly dangerous view on the = matter. Because instead of just getting a PI prefix which you as clueful ISP = will inject in the DFZ, this just leads to most of them asking for a happy-meal including an ASN and = you have to deal with another unmaintained and possibly unstable AS in the DFZ because they just pay a = consultant once to set up BGP on their router and the Tunnel to he.net as a 2nd Upstream for = free and never care about it anymore. Or worse, they do it themselves with help from their = favorite search-engine *shudder*. ...just my 0.01 EUR And yes i don't understand the whining about the requirement anyways. It's easy to circumvent. So it's not at all doing anything good at all. (I indeed support the proposal for various non-technical reasons. If things with PI vs. PA might change anyways in the foreseeable future, = this=20 IPv4 vs. IPv6 PI policy distinction is doing nothing but hinder the desperately needed widespread IPv6 deployment at = the very moment. One has to set the right priorities here.) --=20 Mit freundlichen Gr=FC=DFen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect --__--__-- Message: 3 Subject: FW: [address-policy-wg] Removal of multihomed requirement for IPv6 Date: Fri, 13 May 2011 12:44:42 +0400 From: <poty(a)iiat.ru> To: <address-policy-wg(a)ripe.net> Hello, I do not support this proposal. We are speaking about real possibilities = and real impact. The proposers doesn't know exactly the impact of the = changes and are deaf to the other people pointing to the real troubles = relating the grooving number of prefixes. Their na=EFve assumptions = about cheap BGP routers show their inability to broader the mind just = outside their small nets needs. Technical requirements should be the = only way of making decisions. If someone has tendency to lie - it would lie anyway - one thing or = another. Regards, Vladislav Potapov Ru.iiat --__--__-- Message: 4 Reply-To: thabet(a)gmail.com Subject: Re: [address-policy-wg] Removal of multihomed requirement for IPv6 To: poty@iiat.ru,address-policy-wg-admin@ripe.net,address-policy-wg@ripe.net From: thabet(a)gmail.com Date: Fri, 13 May 2011 08:47:20 +0000 SSBhZ3JlZSB3aXRoIFZsYWRpc2xhdiBQb3RhcG92DQoNCg0KU2VudCBmcm9tIG15IEJsYWNrQmVy cnmuIHNtYXJ0cGhvbmUgZnJvbSBkdQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogPHBvdHlAaWlhdC5ydT4NClNlbmRlcjogYWRkcmVzcy1wb2xpY3ktd2ctYWRtaW5AcmlwZS5u ZXQNCkRhdGU6IEZyaSwgMTMgTWF5IDIwMTEgMTI6NDQ6NDIgDQpUbzogPGFkZHJlc3MtcG9saWN5 LXdnQHJpcGUubmV0Pg0KU3ViamVjdDogRlc6IFthZGRyZXNzLXBvbGljeS13Z10gUmVtb3ZhbCBv ZiBtdWx0aWhvbWVkIHJlcXVpcmVtZW50IGZvciBJUHY2DQoNCkhlbGxvLA0KSSBkbyBub3Qgc3Vw cG9ydCB0aGlzIHByb3Bvc2FsLiBXZSBhcmUgc3BlYWtpbmcgYWJvdXQgcmVhbCBwb3NzaWJpbGl0 aWVzIGFuZCByZWFsIGltcGFjdC4gVGhlIHByb3Bvc2VycyBkb2Vzbid0IGtub3cgZXhhY3RseSB0 aGUgaW1wYWN0IG9mIHRoZSBjaGFuZ2VzIGFuZCBhcmUgZGVhZiB0byB0aGUgb3RoZXIgcGVvcGxl IHBvaW50aW5nIHRvIHRoZSByZWFsIHRyb3VibGVzIHJlbGF0aW5nIHRoZSBncm9vdmluZyBudW1i ZXIgb2YgcHJlZml4ZXMuIFRoZWlyIG5h73ZlIGFzc3VtcHRpb25zIGFib3V0IGNoZWFwIEJHUCBy b3V0ZXJzIHNob3cgdGhlaXIgaW5hYmlsaXR5IHRvIGJyb2FkZXIgdGhlIG1pbmQganVzdCBvdXRz aWRlIHRoZWlyIHNtYWxsIG5ldHMgbmVlZHMuIFRlY2huaWNhbCByZXF1aXJlbWVudHMgc2hvdWxk IGJlIHRoZSBvbmx5IHdheSBvZiBtYWtpbmcgZGVjaXNpb25zLg0KSWYgc29tZW9uZSBoYXMgdGVu ZGVuY3kgdG8gbGllIC0gaXQgd291bGQgbGllIGFueXdheSAtIG9uZSB0aGluZyBvciBhbm90aGVy Lg0KDQpSZWdhcmRzLA0KVmxhZGlzbGF2IFBvdGFwb3YNClJ1LmlpYXQNCg0K End of address-policy-wg Digest

1 0

FW: [address-policy-wg] Removal of multihomed requirement for IPv6
by poty＠iiat.ru 13 May '11

13 May '11

Hello, I do not support this proposal. We are speaking about real possibilities and real impact. The proposers doesn't know exactly the impact of the changes and are deaf to the other people pointing to the real troubles relating the grooving number of prefixes. Their naïve assumptions about cheap BGP routers show their inability to broader the mind just outside their small nets needs. Technical requirements should be the only way of making decisions. If someone has tendency to lie - it would lie anyway - one thing or another. Regards, Vladislav Potapov Ru.iiat

2 1

Removal of multihomed requirement for IPv6
by Elmar Germann 13 May '11

13 May '11

Hello, we do not support this policy. Removing the requirement for multihomed announcements would simply result in more unnecessary PI assignments which will increase the prefix table. We were already asked from several customers for new PI assignments just to draw down the work in case of an ISP change. PI address space should always be bound to technical requirements so that only end users with real requirements are able to request an assignment. I agree that there's currently a discriminating between IPv6 PA und PI address space, but the conculsion should be changeing the policy for the PA address space and not offering PI address space without technical requirements. Kind regards, Elmar Germann. -- Global Village GmbH Tel +49 2855 9651 0 GF Marcus Faure Mehrumer Str. 16 Fax +49 2855 9651 110 Amtsgericht Duisburg HRB9987 D-46562 Voerde eMail info(a)globvill.de Ust-Id DE180295363

2 1

Re: [address-policy-wg] 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call
by Malcolm Hutty 10 May '11

10 May '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am afraid I don't believe this policy should be adopted at this time. My reason is that I think it creates a legal and political risk that is substantial and as yet uninvestigated in the PDP, but which may in the long term reduce the overall robustness of Internet infrastructure to an extent that greatly outweigh the security benefits of the policy. This is not a minor, administrative policy. It is (even if not intended as such) the first step in a process the end result of which would be a major change to the Internet architecture. I am afraid that the ultimate outcome could be that the Internet becomes more fragile as a consequence. True, it's only the first step. But if it's a step in the wrong direction, let's not do it. I don't think we should approve this policy until we are certain that this approach is necessary, worth the risk, that no acceptable alternative solutions (or partial solutions) to the problem exist, and that we've also established all appropriate measures to mitigate the foreseeable risks. The complete argument about why I fear a bad outcome will be too long and complex for a first post on this subject, so let me try to give the briefest summary I can manage instead: I believe that if this policy is adopted, and if it is taken up significantly be operators, it will encourage a dramatic increase in the number of demands from law enforcement and private litigants to the RIPE NCC to revoke both allocation of resources and their certificates, without the consent of the person to whom the resource is delegated. Once legislators realise that the NCC has a more effective power to revoke allocations than previously existed, and has become more capable of making networks appear to "go offline" than it currently is able, legislators will likely respond by creating new powers for law enforcement to oblige the NCC to revoke resource allocations as a tool to address undesired behaviour by network users. In short, in a world where reachability is significantly affected by the ability to produce a valid certificate under this policy, the RIPE NCC will be seen as a "one-stop-shop" for knocking networks offline, to control illicit content and online activity. (Perhaps reachability will not be affected because network operators will ignore these certificates, but if we believe that then isn't this policy a waste of time and effort? And operators may not have a free choice: new legal powers were created by the EU last year that could easily be used to compel adoption). Thus, the RIPE NCC would be gradually transformed into a much more political body; indeed, I think at least as political as ICANN currently is. My concerns are not merely academic, they are immediate and practical. We know that many countries, including the EU, have adopted or are actively considering adopting legal requirements for network operators to block packet transit to/from network addresses outside their network in order to inhibit illicit content or activity (e.g. copyright infringement). LEAs already attend RIPE meetings (Co-operation WG) to ask the community to develop policies to transfer allocations of network blocks to the LEA following an allegation by the LEA that the netblock is being used for illicit purposes, the idea being to seize control of routing. Earlier this year the RIPE NCC attended at least one meeting that I know of to discuss this with EU officials. So far the NCC has fended off such requests, I understand, on the grounds that it doesn't have control over routing. If this policy proceeds, is adopted and successful, that argument will be greatly weakened. Would making RIPE NCC such an attractive single point of failure really make the Internet more secure and robust? I believe that before this policy is adopted the community should consider in depth: i) whether these concerns are at least potentially valid (I am convinced they are); ii) If so, whether the problem that this policy addresses is sufficiently serious to warrant accepting these new risks [1]; and iii) Even if the problem is serious enough, whether alternative means to address it could be found that would mitigate these risks [2]. (For example, if the problem could be 80% solved using a model that does not give RIRs a power to revoke and expire certificates "needed" for routing, is the residual 20% of the problem really serious enough to warrant creating the risks I describe). iv) Even if the problem still justifies adopting the approach taken in this policy proposal, what other steps should be taken simultaineously to mitigate these risks. For myself, I am convinced about (i). I have serious doubts about (ii) and (iii) myself, and perhaps more importantly can see no evidence on the list archive that the community has actively assessed whether (ii) is true, and no evidence that other potential architectures or system designs have been considered as a possible alternative that might better mitigate the risks I describe. Nor has there been any visible discussion of (iv). Even if I've missed something, do we really think the community has considered these issues in depth? Or have they been shunted off as a problem to be looked at later, or elsewhere? The presentation at yesterdays RIPE meeting plenary by Randy Bush and the discussion that followed convinced me that there is much more for the community to discuss. I have raised this issue at previous RIPE meetings but only recently become aware that to affect the PDP it was necessary to post on this list, for which my apologies. However I now see such objections are the explicit purpose of the Last Call, so I hope you'll consider this objection carefully. There is much more I could say, but for a first post on the subject I'll leave it at that; I don't want to create a bigger "wall of text" than absolutely necessary. I would be grateful if those who agree with me that this discussion warrants delaying adoption of the proposal would say so now, so that the WG Chair can see whether there is a "serious objection" that prevents a rough consensus being declared at this time. My apologies to those who have worked so long and hard on this, with only the best of motives, on the assumption that there was general support for this approach. But I'm afraid this issue is too important to let this pass without raising my concerns, and asking the community to stand with me. Malcolm. [1] Yes, route hijacking does happen, sometimes by mistake and sometimes by malice. But how often? Are current responses sufficient to deal with it proportionately? Could they be made more effective without any kind of certification scheme? Would something new, that's not a certification scheme suffice? [2] For example, could we creates "webs of trust" rather than a single hierarchy? Would that be "good enough" or is a hierarchy essential? Could a PKI for address allocations work sufficiently well without investing the hierarchy with authority to revoke certificates? Should we consider an architecture with a distributed issuer/revoker, spread across multiple jurisdictions? What other models exist? - -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ London Internet Exchange Ltd Maya House, 134-138 Borough High Street, London SE1 1LB Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2/56YACgkQJiK3ugcyKhTdwgCgp02ZpOj7XhT1TlN5xk7vOF9l ZdAAoIe+LF1Dt70q9Gonk2/CsoLG6N2O =z7io -----END PGP SIGNATURE-----

24 74

2008-08 (Initial Certification Policy in the RIPE NCC Service Region) going to Last Call
by Sander Steffann 09 May '11

09 May '11

Hello working group, The review period for the new RIPE Document described in proposal 2008-08 has ended. During the review phase we have seen on the mailing list: - one positive comment (Bais) - one comment to go forward in the PDP with some extra comments intended for the future evolution of a more comprehensive certification policy (Volk) Based on this feedback we (the address policy working group chairs) have decided to move this policy proposal to the Concluding Phase and start the Last Call for Comments. The documents on the website will be updated to reflect this and an official announcement will be sent out once this is done. Thank you all for your contributions, Sander Steffann RIPE Address Policy WG co-chair

10 12

2008-08 Most recent version of the CPS?
by Wilfried Woeber, UniVie/ACOnet 09 May '11

09 May '11

Folks, is the document RIPE NCC RPKI (without a ripe document ID :-/ ), labelled "Last updated December 2010" the most recent addition? If it is, I do have quite some issues with this text, in particular in its formal relationship to the 2008-08 draft policy text. If there's a more recent version I'd be grateful to be given a pointer or a reference. Tnx, Wilfried.

1 0

PP - 2011-02 - Removal of multihomed requirement for IPv6
by Adil H. Baghir 07 May '11

07 May '11

Hi, I highly support the policy... Adil H. Baghir Chief Engineer, Internet Development Data & Solutions Planning and Design P.O.Box 69179 Riyadh 11423 Kingdom of Saudi Arabia Tel: +966 56 031 3263 Fax: +966 56 041 3263 Mobile: +966 542 33 66 00 eMail: a.baghir(a)mobily.com.sa<mailto:a.baghir@mobily.com.sa> [cid:image002.jpg@01CC0D02.F7D02210] ------Disclaimer------ This email and any files transmitted with are classified as confidential unless otherwise specified. This e-mail is intended solely for the use of the individual or entity to whom this e-mail is addressed. If you have received this email by mistake, please notify the sender and delete this e-mail immediately and permanently. Although measures were taken to free this e-mail and its attachments from any malicious code infection, it is the responsibility of the recipient to check this email and any attachments for the presence of such infection. The use of EEC(Mobily) e-mail service is limited for EEC(Mobily) business use only.

1 0

Removal of multihomed requirement for IPv6
by ABS EMEA NIC - IPA Support AT&T 07 May '11

07 May '11

Hi All, I support this proposal. To have 2 ISPs is not a cheap solution. What in case if you have 2-ISPs and you are not satisfied with offered services with one of them and decide to have only 1-ISP. You cannot use IPv6 PI space. What in case if you want to change another ISP ? You have to renumber a lot of ip addresses and update firewalls and more. I think that keeping multihoming requirement for IPv6 PI space prevent to deploy of IPv6 especially for small end users (customers). Mikael Abrahamsson, Why do you think: "50 EUR PI with no technical requirements for multihoming or other is a recipe for longterm disaster in my book." ? 50 Eur works today for IPv4 PI space as well. Thank you Best regards _____________________________________ Pavol Kovac -----Original Message----- From: address-policy-wg-admin(a)ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of address-policy-wg-request(a)ripe.net Sent: Friday, May 06, 2011 12:00 PM To: address-policy-wg(a)ripe.net Subject: address-policy-wg digest, Vol 1 #1313 - 14 msgs Send address-policy-wg mailing list submissions to address-policy-wg(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit http://www.ripe.net/mailman/listinfo/address-policy-wg or, via email, send a message with subject or body 'help' to address-policy-wg-request(a)ripe.net You can reach the person managing the list at address-policy-wg-admin(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of address-policy-wg digest..." Today's Topics: 1. On the agenda for tomorrow: 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) (Sander Steffann) 2. Re: 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) (Mikael Abrahamsson) 3. Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) (Sander Steffann) 4. RE: 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) (poty(a)iiat.ru) 5. Re: Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) (Mikael Abrahamsson) 6. Re: 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) (=?ISO-8859-1?Q?Vegar_L=F8v=E5s?=) 7. Re: Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) (Malcolm Hutty) 8. pointer to ietf sidr wg (Randy Bush) 9. Re: Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) (boggits) --__--__-- Message: 1 From: Sander Steffann <sander(a)steffann.nl> Date: Thu, 5 May 2011 16:44:41 +0200 To: "address-policy-wg(a)ripe.net Working Group" <address-policy-wg(a)ripe.net> Subject: [address-policy-wg] On the agenda for tomorrow: 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) Hello WG, We will have a discussion about 2008-08 (Initial Certification Policy in = the RIPE NCC Service Region) on the agenda for tomorrow's address policy = session at RIPE 62. We also will have a short presentation there about = the issues that have been discussed on this mailing list over the last = couple of days. The session is from 9:00 to 10:30 and remote = participation is possible at http://ripe62.ripe.net/live/main. Thank you, Sander Steffann APWG co-chair --__--__-- Message: 2 Date: Thu, 5 May 2011 19:30:27 +0200 (CEST) From: Mikael Abrahamsson <swmike(a)swm.pp.se> To: address-policy-wg(a)ripe.net cc: policy-announce(a)ripe.net Subject: Re: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) Organization: People's Front Against WWW On Fri, 15 Apr 2011, Emilio Madaio wrote: > We encourage you to review this proposal and send your comments to > <address-policy-wg(a)ripe.net> before 13 May 2011. As has been stated by me before, 50 EUR PI with no technical requirements for multihoming or other is a recipe for longterm disaster in my book. I strongly oppose. -- Mikael Abrahamsson email: swmike(a)swm.pp.se --__--__-- Message: 3 From: Sander Steffann <sander(a)steffann.nl> Date: Fri, 6 May 2011 08:43:56 +0200 To: "address-policy-wg(a)ripe.net Working Group" <address-policy-wg(a)ripe.net> Subject: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) Hello WG, I asked the RIPE NCC to get legal counsel on the possibilities of a = court ordering the RIPE NCC to revoke or confiscate RPKI certificates. = Here is the full answer we received: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The RIPE NCC is an association under Dutch law and therefore subject to = the Dutch legislation. RIPE NCC has consulted several external lawyers, = and has obtained an analysis of the legal situation based on current, = existing Dutch legislation. This analysis takes into account Dutch = Criminal, Civil and Administrative law. Certificates are directly linked to the registration of the Internet = number resources. There is no specific Dutch legislation that can be used to order the = deregistration of Internet number resources or change the registration = details of Internet number resources. Nor is there any legislation that = applies to the revocation of certificates over Internet number = resources. In the absence of such legislation, a court cannot order the revocation = of certificates. It is the RIPE NCC=92s view, based on this analysis, that the RIPE NCC = cannot be ordered to revoke resource certificates. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Of course laws can change, but the advice above may address some of the = concerns raised about the RPKI infrastructure. Sander Steffann APWG co-chair --__--__-- Message: 4 Subject: RE: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) Date: Fri, 6 May 2011 10:59:44 +0400 From: <poty(a)iiat.ru> To: <swmike(a)swm.pp.se>, <address-policy-wg(a)ripe.net> Cc: <policy-announce(a)ripe.net> According to my messages to the WG earlier and taking into good consideration of the point of view of Mikael Abrahamsson I oppose the policy too. Vladislav Potapov IIAT, Ltd. -----Original Message----- From: address-policy-wg-admin(a)ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Mikael Abrahamsson Sent: Thursday, May 05, 2011 9:30 PM To: address-policy-wg(a)ripe.net Cc: policy-announce(a)ripe.net Subject: Re: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) On Fri, 15 Apr 2011, Emilio Madaio wrote: > We encourage you to review this proposal and send your comments to=20 > <address-policy-wg(a)ripe.net> before 13 May 2011. As has been stated by me before, 50 EUR PI with no technical requirements=20 for multihoming or other is a recipe for longterm disaster in my book. I strongly oppose. --=20 Mikael Abrahamsson email: swmike(a)swm.pp.se --__--__-- Message: 5 Date: Fri, 6 May 2011 09:01:27 +0200 (CEST) From: Mikael Abrahamsson <swmike(a)swm.pp.se> To: Sander Steffann <sander(a)steffann.nl> cc: "address-policy-wg(a)ripe.net Working Group" <address-policy-wg(a)ripe.net> Subject: Re: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) Organization: People's Front Against WWW On Fri, 6 May 2011, Sander Steffann wrote: > In the absence of such legislation, a court cannot order the revocation > of certificates. In several countries, we've seen courts ordering ISPs to block accessibility to certain sites involving not using DNS names (denmark and thepiratebay.org for instance, or the domain names transferred to US authorities just a few months ago) or block access IP-wise (Black Internet in Sweden). I am sure there was no specific law handling this, but the laws at least in these countries are flexible enough that other laws can be used to order things around. > Of course laws can change, but the advice above may address some of the > concerns raised about the RPKI infrastructure. It's good that it has been answered for dutch law, I wonder what equivalent question would have been answered in Sweden and Denmark or the US 5 years ago. -- Mikael Abrahamsson email: swmike(a)swm.pp.se --__--__-- Message: 6 Date: Fri, 06 May 2011 09:13:49 +0200 From: =?ISO-8859-1?Q?Vegar_L=F8v=E5s?= <vegar(a)rentarack.no> To: address-policy-wg(a)ripe.net Subject: Re: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) I agree with this proposal. --=20 Best regards Vegar L=F8v=E5s Rent a Rack AS On 15.04.2011 11:22, Emilio Madaio wrote: > Dear Colleagues, > > A proposed change to the RIPE Document ripe-512,"IPv6 Address > Allocation and Assignment Policy", is now available for discussion. > > > You can find the full proposal at: > > http://www.ripe.net/ripe/policies/proposals/2011-02 > > We encourage you to review this proposal and send your comments to > <address-policy-wg(a)ripe.net> before 13 May 2011. > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC > --__--__-- Message: 7 Date: Fri, 06 May 2011 08:28:44 +0100 From: Malcolm Hutty <malcolm(a)linx.net> To: address-policy-wg(a)ripe.net Subject: Re: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/05/2011 07:43, Sander Steffann wrote: > There is no specific Dutch legislation that can be used to order the > deregistration of Internet number resources or change the > registration details of Internet number resources. Nor is there any > legislation that applies to the revocation of certificates over > Internet number resources. >=20 > In the absence of such legislation, a court cannot order the > revocation of certificates. >=20 > It is the RIPE NCC=92s view, based on this analysis, that the RIPE NCC > cannot be ordered to revoke resource certificates. There are a couple of other possible current vectors, as well as the question of future legislation. 1. Legal counsel referred to the lack of legislation that specifically mentioned revocation of certificates. Most of the existing and draft legislation I know of (not Dutch, but some EU) refers instead to "preventing access to Internet [locations/sites/content]". As a generalisation, courts will not normally order someone to do something utterly outside their power, but may order someone to take such steps as they are able to achieve an end if they are seen as being able to make a significant contribution, even if that contribution won't be wholly successful. For example, courts sometimes order newspapers and broadcasters not to publish information, even though they know the information may end up being published online. Right now it is commonly said that RIPE NCC does not have control over routing, so a court would be unlikely to order the RIPE NCC to prevent access to an Internet location. If, as a result of this policy, RIPE NCC is seen to have the capability to significantly reduce the reachability of an Internet location, a court might be willing to order it to "prevent access to the location" to the extent that it is able. No explicit mention need be made of certificate revocation. 2. Within some jurisdictions LEAs argue that Internet intermediaries are themselves criminally liable if they "facilitate" criminal activity by refusing to prevent access to an Internet location where criminal activity is ongoing, once they have been informed of the criminal activity. Intermediaries are thus induced to block access without a court order being necessary. Within the EU, network operators have special protection against this threat from the E-Commerce Directive as "mere conduits", but unfortunately registries like the RIPE NCC probably do not fit the definition of "mere conduit". In the UK, Nominet (the .uk ccTLD registry) has been induced to suspend domain registrations using this argument. RIPE NCC might in future be exposed to the same pressure. 3. Finally, new legislation not only /could/ be created, but most certainly will. The Netherlands is subject to EU law. Whether such new law would affect the RIPE NCC we cannot be certain, but I am certain that the only thing restraining lobbyists is a lack of awareness of the existence of RIPE NCC (and awareness is increasing), and a belief that the RIPE NCC has no relevant technical capability, which this policy would change. - --=20 Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ London Internet Exchange Ltd Maya House, 134-138 Borough High Street, London SE1 1LB Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3DoywACgkQJiK3ugcyKhSlSACdGyEFtxJUai+xrWtGB/vwZjoJ VnUAoLpgRXaghPiUTTDwF3SIoQxgCEa+ =3DeFIF -----END PGP SIGNATURE----- --__--__-- Message: 8 Date: Fri, 06 May 2011 10:23:36 +0200 From: Randy Bush <randy(a)psg.com> To: RIPE address policy WG <address-policy-wg(a)ripe.net> Subject: [address-policy-wg] pointer to ietf sidr wg as requested by gert, here are pointers to the work of the sidr wg of the ietf main page of wg == documents http://datatracker.ietf.org/wg/sidr/ charter of sidr wg http://datatracker.ietf.org/wg/sidr/charter/ mailing list http://www.ietf.org/mail-archive/web/sidr/current/maillist.html if i can be of help in navigation or interpretation, feel free to write to me randy, just another bozo on the routing security bus --__--__-- Message: 9 Date: Fri, 6 May 2011 11:06:44 +0200 Subject: Re: [address-policy-wg] Legal counsel on 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) From: boggits <boggits(a)gmail.com> Cc: "address-policy-wg(a)ripe.net Working Group" <address-policy-wg(a)ripe.net> On 6 May 2011 08:43, Sander Steffann <sander(a)steffann.nl> wrote: > Of course laws can change, but the advice above may address some of the concerns raised about the RPKI infrastructure. > This is indeed true but misses the point that laws tend to exist either when there is an actual 'thing' to make laws about or are framed in such a way to allow the courts the latitude to include 'new things' in the same piece of legislation. Since RPKI is not currently a 'thing' but rather a 'new thing' I would be wary of relying on legal opinion that says: "There is no specific Dutch legislation that can be used to order the deregistration of Internet number resources or change the registration details of Internet number resources. Nor is there any legislation that applies to the revocation of certificates over Internet number resources." What you are looking for is legislation (as pointed out by Malcom) that can be used to restrict/control access to the internet which appears to exist at least at a European level J -- James Blessing 07989 039 476 End of address-policy-wg Digest

7 10

2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6)
by Emilio Madaio 06 May '11

06 May '11

Dear Colleagues, A proposed change to the RIPE Document ripe-512,"IPv6 Address Allocation and Assignment Policy", is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2011-02 We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 13 May 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC

27 50

Re: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6)
by Sascha Luck 06 May '11

06 May '11

I support this proposal. rgds, sascha Luck

1 0

pointer to ietf sidr wg
by Randy Bush 06 May '11

06 May '11

as requested by gert, here are pointers to the work of the sidr wg of the ietf main page of wg == documents http://datatracker.ietf.org/wg/sidr/ charter of sidr wg http://datatracker.ietf.org/wg/sidr/charter/ mailing list http://www.ietf.org/mail-archive/web/sidr/current/maillist.html if i can be of help in navigation or interpretation, feel free to write to me randy, just another bozo on the routing security bus

1 0

RE: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6)
by poty＠iiat.ru 06 May '11

06 May '11

According to my messages to the WG earlier and taking into good consideration of the point of view of Mikael Abrahamsson I oppose the policy too. Vladislav Potapov IIAT, Ltd. -----Original Message----- From: address-policy-wg-admin(a)ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Mikael Abrahamsson Sent: Thursday, May 05, 2011 9:30 PM To: address-policy-wg(a)ripe.net Cc: policy-announce(a)ripe.net Subject: Re: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) On Fri, 15 Apr 2011, Emilio Madaio wrote: > We encourage you to review this proposal and send your comments to > <address-policy-wg(a)ripe.net> before 13 May 2011. As has been stated by me before, 50 EUR PI with no technical requirements for multihoming or other is a recipe for longterm disaster in my book. I strongly oppose. -- Mikael Abrahamsson email: swmike(a)swm.pp.se

1 0

On the agenda for tomorrow: 2008-08 (Initial Certification Policy in the RIPE NCC Service Region)
by Sander Steffann 05 May '11

05 May '11

Hello WG, We will have a discussion about 2008-08 (Initial Certification Policy in the RIPE NCC Service Region) on the agenda for tomorrow's address policy session at RIPE 62. We also will have a short presentation there about the issues that have been discussed on this mailing list over the last couple of days. The session is from 9:00 to 10:30 and remote participation is possible at http://ripe62.ripe.net/live/main. Thank you, Sander Steffann APWG co-chair

1 0

Re: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6)
by Hamed Shafaghi 05 May '11

05 May '11

I agree with this proposal. Best Regards -- I Hamed Shafaghi I I Managing Director I I Skydsl® Telecom I hamed(a)skydsl.ir I www.skydsl.ir I

1 0

RE: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6)
by melchior.aelmans＠kpn.com 05 May '11

05 May '11

Dear Emilio, We support this proposal from Erik and Jordi. Thanks and regards, Melchior Aelmans KPN Mobile CARE Continuity Core Data From: address-policy-wg-admin(a)ripe.net [mailto:address-policy-wg-admin@ripe.net] On Behalf Of Emilio Madaio Sent: Friday, April 15, 2011 11:23 AM To: policy-announce(a)ripe.net Cc: address-policy-wg(a)ripe.net Subject: [address-policy-wg] 2011-02 New Policy Proposal (Removal of multihomed requirement for IPv6) Dear Colleagues, A proposed change to the RIPE Document ripe-512,"IPv6 Address Allocation and Assignment Policy", is now available for discussion. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2011-02 We encourage you to review this proposal and send your comments to <address-policy-wg(a)ripe.net> before 13 May 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC

1 0

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

05 May '11

On 05/04/2011 11:55 AM, poty(a)iiat.ru wrote: > 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. RIPE is always speaking with the LIR, in accordance to 2007-01 policy. All new PI users are always connected with some LIR. If you want obtain PI directly from RIPE, you'll pay additional money for the contract with RIPE, it's documented on the website. ----------------- Yes, but it means that RIPE is not always "speak" exclusively with LIRs. More than that, the "customer" has rights to change the hosting LIR in every moment. It further complicates things. //////////// And generally, I don't prefer crapping PA space with such deaggregation caused just by the PI-blocking policy. ----------------- It was my idea behind the lines. Most Internet players are not so bad to do illegal and harmful things. It's not only money matters.

1 0

Removal of multihomed requirement for IPv6 PI
by Kovac, Pavol 04 May '11

04 May '11

Hi, what is the current status for this topic ? Best regards _____________________________________ Pavol Kovac

2 2

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