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

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