From ebais at a2b-internet.com Tue Feb 1 12:14:51 2011 From: ebais at a2b-internet.com (Erik Bais) Date: Tue, 1 Feb 2011 12:14:51 +0100 Subject: [address-policy-wg] RE: [policy-announce] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: <20101021113639.C265D6A008@postboy.ripe.net> References: <20101021113639.C265D6A008@postboy.ripe.net> Message-ID: <001d01cbc201$3f3c8dc0$bdb5a940$@com> Hi, I was wondering what the status is of this policy. I haven't seen any updates or feedback on this and I think that it would make a lot of sense to proceed with this proposal. For those that didn't go to the RIPE 61 meeting (like myself) or missed Nick Hilliard his preso on the topic : http://ripe61.ripe.net/presentations/318-inex-ripe-rome-apwg-minassignments- 2010-11-17.pdf 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 Regards, Erik Bais From erik at bais.name Tue Feb 1 12:21:04 2011 From: erik at bais.name (Erik Bais) Date: Tue, 1 Feb 2011 12:21:04 +0100 Subject: [address-policy-wg] FW: [policy-announce] 2006-05 New Draft Document Published (PI Assignment Size) Message-ID: <3D7F7C92CA8EEF458B7AC7BACD7D619102F193C69053@EXVS002.netsourcing.lan> Hi, I was wondering what the status is of this policy. I haven't seen any updates or feedback on this and I think that it would make a lot of sense to proceed with this proposal. For those that didn't go to the RIPE 61 meeting (like myself) or missed Nick Hilliard his preso on the topic : http://ripe61.ripe.net/presentations/318-inex-ripe-rome-apwg-minassignments-2010-11-17.pdf 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 Regards, Erik Bais From nick at inex.ie Tue Feb 1 12:55:19 2011 From: nick at inex.ie (Nick Hilliard) Date: Tue, 01 Feb 2011 11:55:19 +0000 Subject: [address-policy-wg] Re: [policy-announce] 2006-05 New Draft Document Published (PI Assignment Size) In-Reply-To: <001d01cbc201$3f3c8dc0$bdb5a940$@com> References: <20101021113639.C265D6A008@postboy.ripe.net> <001d01cbc201$3f3c8dc0$bdb5a940$@com> Message-ID: <4D47F4A7.3020500@inex.ie> On 01/02/2011 11:14, Erik Bais wrote: > I was wondering what the status is of this policy. Hi Eric, It's blocking on me to re-formulate and send back to the working group. Unfortunately, I'm just tied up with other stuff at the moment. I'm hoping to get time to deal with this soon. Nick From Woeber at CC.UniVie.ac.at Thu Feb 3 14:00:55 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 03 Feb 2011 13:00:55 +0000 Subject: [address-policy-wg] Invitation to particpate in a RIPE Task-Force Message-ID: <4D4AA707.2080805@CC.UniVie.ac.at> Invitation to join and actively contribute to a RIPE Taskforce on "Abuse Contact Management in the RIPE Database" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Background: The RIPE Database serves as a data repository for Internet resource assignments and allocations in the RIPE NCC's service region. Among other purposes, it serves as a contact repository for administrative, technical and operational matters regarding IP address ranges and autonomous system numbers. Over time, some mechanisms became available, such as the Incident Response Team (IRT) object and an abuse-mailbox: attribute. Different communities seem to have developed varying expectations and understanding of how the data quality for such contact information can be maintained at a high level, and how and when a report sent to such a contact mechanism will be responded to or otherwise acted upon. Recently, some RIPE Policy Proposals were submitted for consideration and these proposals (2010-08, 2010-09 and 2010-10) were discussed in the Address Policy Working Group, the Anti-Abuse Working Group and briefly in the Database Working Group during the RIPE 61 Meeting in Rome. Deliberations among the responsible working group chairs and senior policy experts suggested that investigation be carried out to get a deeper understanding of the motivations behind the policy proposals, the expected outcomes, the operational and maintenance implications and the role the RIPE Database could perform to support the desired results. It was then suggested to the community and the policy proponents that the most efficient way to progress the issue would be the creation of a RIPE Task Force. There was no objection raised by the members of the community present at the meeting. Call for Participation ----------------------- We invite members of the RIPE community, from the security as well as from the anti-abuse areas, to volunteer and contribute to the proposed task force. Ideally, we would like to bring together the security and anti-abuse communities and the IP resource management and network operations communities to jointly analyse and refine the issue. *Draft* Mandate for the Task Force ---------------------------------- [This draft mandate is for consideration, modification and refinement by the task force] The task force is mandated to: - Agree on a useful name for the task force and, with the help of the RIPE NCC, arrange the logistics and report back to the community about the establishment of the task force - Collect all relevant input that is readily available, in particular policy proposals, information from presentations given recently by the RIPE NCC regarding ideas on the future structure, credibility and quality of data, and the maintenance mechanisms for entries in the RIPE Database - Collect and document comparable mechanisms and proposals in the other RIR Regions (APNIC, AfriNIC, ARIN and LACNIC) - Work with the interested community and the RIPE NCC to understand the problem at hand and the environment in which to develop a proposal. This analysis of the environment should include legal aspects, formal responsibilities for the use of resources on the Internet, well-established operating procedures and relevant operational aspects. - Develop one or more (policy) proposals and/or general recommendations on how collection and maintainace of relevant information in the Registry Database should be organised, including a description of potentially alternative implementations or approaches and the related impact on all parties involved *Draft* Timeline ----------------- The Taskforce should: - Try to collect the core group of participants before end of February 2010 - Start work on the dedicated mailing list as soon as possible, with a view to meet for a face-to-face meeting in advance of RIPE 62 (May 2011) - Report on the task force's progress during RIPE 62 (May 2011) and collect regular input from the RIPE community - Submit a first draft of a recommendation(s) and/or policy proposal(s) before RIPE 63 - Agree on the proposal(s) and agree on the expected implementation deadline Submitting statements of intent to actively participate -------------------------------------------------------- If you would like to participate in the task force, please email the RIPE NCC's Database Manager, Paul Palse, at . ________________________________________________________________________ Best regards, Wilfried, circulating this invitation on behalf of the group of the proponents, with kudos to the colleagues at the RIPE NCC for their help with wording! From gert at space.net Thu Feb 3 18:40:11 2011 From: gert at space.net (Gert Doering) Date: Thu, 3 Feb 2011 18:40:11 +0100 Subject: [address-policy-wg] regarding 2008-08 - was: RIPE NCC Resource Certification service update In-Reply-To: References: Message-ID: <20110203174011.GJ44800@Space.Net> Hello APWG, (copying in NCC services WG, but since this is more regarding the formal policy proposal side of things, the place to discuss it is the apwg list -> reply-To: has been set accordingly). We have a slightly weird situation here where we have a policy proposal (2008-08) that has not *yet* concluded, which give the RIPE NCC the mandate to setup and operate the infrastructure to give out certificates to LIRs from the RIPE region (PA space holders, for a start, PI to be done in the next round). This proposal has not yet concluded, due to mostly "word smithing" reasons, and also due to somewhat lacking feedback from the community (that's *you*). There was no strong resistance either, so I assume that it might eventually reach consensus. On the other hand, the RIPE NCC sees the necessity for this sort of machinery, and has started the service *already* (see below for the mail from Alex Band with the NCC view of things), without waiting for the proposal to conclude. The RIPE NCC members have approved the expenses for this as part of the NCC business plan, so the NCC has the necessary (at least financial) backing to go forward here. So, technically, we might question whether we need the policy proposal 2008-08 at all anymore, or whether it should be withdrawn (being obsoleted by events). I have discussed this with the certification task force (CA-TF) and Alex' mail also answers this - the NCC wants a clear policy document that says that not only the financial side is OK, but also that the address policy community agrees with what the NCC is doing, and gives their support to the NCC. As a consequence, you'll see 2008-08 v3.0 show up here soon, for another round of review, and I *really* would appreciate a somewhat more active feedback from the WG (you!) this time. regards, Gert Doering, APWG chair On Mon, Jan 31, 2011 at 09:30:25AM +0100, Alex Band wrote: > Dear colleagues, > > It's been one month since I sent the announcement about the RIPE NCC Resource Certification service. I would like to give you an overview of the current status. > > The facts by numbers: > ------------------------------ > LIRs who have enabled the service: 219 > Number of Route Origin Authorisations they created: 170 > Number of prefixes covered by these ROAs: 469 > Total IPv4 space covered by ROAs in the RIPE region: 40159 /24s > Total IPv6 space covered by ROAs in the RIPE region: 7340035 /48s > Unique visitors to ripe.net/certification: 1564 > Downloads of the RIPE NCC Validator: 117 > > So while 219 LIRs have enabled the service, and very diligently created a large number of ROAs to specify their routing policy, unfortunately nobody gave any feedback on any of the mailing lists. It is very important that you let your voice be heard and provide input on policy proposal 2008-08: > http://ripe.net/ripe/policies/proposals/2008-08.html > > Please note that version 3.0 of this proposal will be published very soon. As soon as it is available, I urge you to read it and provide feedback, because the fact that the current service not backed by a policy is not a sustainable state of affairs. > > Kind regards, > > Alex Band > Product Manager, RIPE NCC > http://ripe.net/certification > > P.S. Here are some links courtesy of LACNIC in case you would like to track the progress: > http://www.labs.lacnic.net/~rpki/rpki-monitor/rpki-ta-status.xml > http://www.labs.lacnic.net/~rpki/rpki-evolution-report_EN.txt > http://www.labs.lacnic.net/~rpki/rpki-heatmaps/latest/ripe-roa-heatmap.png 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3583 bytes Desc: not available URL: From andrea at ripe.net Mon Feb 7 10:31:06 2011 From: andrea at ripe.net (Andrea Cima) Date: Mon, 07 Feb 2011 10:31:06 +0100 Subject: [address-policy-wg] New IPv4 block allocated to RIPE NCC Message-ID: <4D4FBBDA.8040704@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [Apologies for duplicate mails] Dear Colleagues, The RIPE NCC has received the IPv4 address range 185/8 from the IANA. This is the final allocation of IPv4 address space that the RIPE NCC will receive from the IANA as stated in ripe-436, "Global Policy for the Allocation of the Remaining IPv4 Address Space". The minimum allocation size for this /8 has been set at /22. You may wish to adjust any filters you have in place accordingly. More information on the IP address space administered by the RIPE NCC can be found on our website at: https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html Additionally, please note that three "pilot" prefixes will be announced from this /8. The prefixes are: 185.0.0.0/16 185.1.0.0/21 185.1.24.0/24 They all originate in AS12654. The pingable addresses will be: 185.0.0.1 185.1.0.1 185.1.24.1 More information on this activity is available in the document "De-Bogonising New Address Blocks", which can be found at: http://www.ripe.net/ripe/docs/ripe-351.html Kind regards, Andrea Cima Registration Services Manager RIPE NCC -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAk1Pu9kACgkQXOgsmPkFrjM9FgCgsaT8cFxK0YKTFUFzj41L0PQT N1AAoIgmL1zUY8JjkCSa05xt0t8oppgP =woX5 -----END PGP SIGNATURE----- From emadaio at ripe.net Wed Feb 9 15:00:35 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Wed, 09 Feb 2011 15:00:35 +0100 Subject: [address-policy-wg] 2008-08 New Version and Draft Document Published (Initial Certification Policy for Provider Aggregatable Address Space Holders) Message-ID: <20110209140036.9C4BB6A002@postboy.ripe.net> Dear Colleagues, The new version (3.0) of the proposal 2008-08 has been published. The draft document for the proposal and the impact analysis have also been published. The proposal will now undergo a two weeks Review Phase as explained in the previous message available at: http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2011/msg00022.html 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 strongly encourage you to read the draft document text and send comments, ideas, feedback to address-policy-wg at ripe.net before 23 February 2011. Regards Emilio Madaio Policy Development Officer RIPE NCC From gert at space.net Wed Feb 9 15:13:12 2011 From: gert at space.net (Gert Doering) Date: Wed, 9 Feb 2011 15:13:12 +0100 Subject: [address-policy-wg] 2008-08 New Version and Draft Document Published (Initial Certification Policy for Provider Aggregatable Address Space Holders) In-Reply-To: <20110209140036.9C4BB6A002@postboy.ripe.net> References: <20110209140036.9C4BB6A002@postboy.ripe.net> Message-ID: <20110209141312.GD44800@Space.Net> Dear Working Group, as you might have noticed, this proposal is nicknamed "the icelandic saga" because it goes on and on and on and on... We'd really like to bring this to conclusion, and for that, we need *feedback from the community*. So please let us know: - this is what you want to see implemented - you're in favour of the general principle, but this specific wording is not what you want - you're in favour of the general principle, want some details changed, but agree to pospone that to the next round of certificate-related proposals (like "this proposal does not cover PI" - yes, we know, the plan was to "start with the easy bits = PA"). - you're completely opposed to this proposal (in that case, giving some background why you don't want it would be very helpful) thanks, Gert Doering APWG chair On Wed, Feb 09, 2011 at 03:00:35PM +0100, Emilio Madaio wrote: > > Dear Colleagues, > > The new version (3.0) of the proposal 2008-08 has been published. > > The draft document for the proposal and the impact analysis have also > been published. > > The proposal will now undergo a two weeks Review Phase as explained in > the previous message available at: > > http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2011/msg00022.html > > > 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 strongly encourage you to read the draft document text and send > comments, ideas, feedback to address-policy-wg at ripe.net before 23 > February 2011. > > Regards > > Emilio Madaio > Policy Development Officer > RIPE NCC > -- 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 From james.blessing at despres.co.uk Wed Feb 9 15:21:11 2011 From: james.blessing at despres.co.uk (James Blessing) Date: Wed, 9 Feb 2011 14:21:11 +0000 Subject: [address-policy-wg] 2008-08 New Version and Draft Document Published (Initial Certification Policy for Provider Aggregatable Address Space Holders) In-Reply-To: <20110209141312.GD44800@Space.Net> References: <20110209140036.9C4BB6A002@postboy.ripe.net> <20110209141312.GD44800@Space.Net> Message-ID: On 9 February 2011 14:13, Gert Doering wrote: As epic as this is, my problem with that document is that it contains things like "Resource Public Key Infrastructure (RPKI) certificates over their Provider Aggregatable" which I think I understand, but feels like I might be reading it wrong (I think over is the wrong word) "RIPE NCC members in good standing" Not seen 'in good standing' defined anywhere "Certificates will be issued with a validity period of up to 18 months or as otherwise stated in the RIPE NCC Certificate Practice Statement." which is silly and should loose the whole 18 months bit (or the practice statement bit) > ?- you're in favour of the general principle, but this specific wording > ? is not what you want most definitely J -- James Blessing 07989 039 476 From Jac.Kloots at surfnet.nl Wed Feb 9 15:22:43 2011 From: Jac.Kloots at surfnet.nl (Jac Kloots) Date: Wed, 9 Feb 2011 15:22:43 +0100 (CET) Subject: [address-policy-wg] 2008-08 New Version and Draft Document Published (Initial Certification Policy for Provider Aggregatable Address Space Holders) In-Reply-To: <20110209141312.GD44800@Space.Net> References: <20110209140036.9C4BB6A002@postboy.ripe.net> <20110209141312.GD44800@Space.Net> Message-ID: On Wed, 9 Feb 2011, Gert Doering wrote: > Dear Working Group, > > as you might have noticed, this proposal is nicknamed "the icelandic > saga" because it goes on and on and on and on... > > We'd really like to bring this to conclusion, and for that, we need > *feedback from the community*. So please let us know: > > - this is what you want to see implemented want to see this implemented. One question; what happens after the validity period of the certificate expires? Jac -- Jac Kloots Network Services SURFnet bv From sander at steffann.nl Wed Feb 9 15:52:27 2011 From: sander at steffann.nl (Sander Steffann) Date: Wed, 9 Feb 2011 15:52:27 +0100 Subject: [address-policy-wg] 2008-08 New Version and Draft Document Published (Initial Certification Policy for Provider Aggregatable Address Space Holders) In-Reply-To: References: <20110209140036.9C4BB6A002@postboy.ripe.net> <20110209141312.GD44800@Space.Net> Message-ID: <1D1904D8-1527-4CC4-8FB3-B3D419AB41DF@steffann.nl> Hi Jac, > One question; what happens after the validity period of the certificate expires? You have an invalid certificate :) But at that point in time you will also have received a new certificate with a new validity period. As long as you still meet the criteria for receiving the certificate of course. - Sander From Jac.Kloots at surfnet.nl Wed Feb 9 16:05:41 2011 From: Jac.Kloots at surfnet.nl (Jac Kloots) Date: Wed, 9 Feb 2011 16:05:41 +0100 (CET) Subject: [address-policy-wg] 2008-08 New Version and Draft Document Published (Initial Certification Policy for Provider Aggregatable Address Space Holders) In-Reply-To: <1D1904D8-1527-4CC4-8FB3-B3D419AB41DF@steffann.nl> References: <20110209140036.9C4BB6A002@postboy.ripe.net> <20110209141312.GD44800@Space.Net> <1D1904D8-1527-4CC4-8FB3-B3D419AB41DF@steffann.nl> Message-ID: Sander, On Wed, 9 Feb 2011, Sander Steffann wrote: > Hi Jac, > >> One question; what happens after the validity period of the certificate expires? > > You have an invalid certificate :) That's the obvious answer. > But at that point in time you will also have received a new certificate > with a new validity period. And this will be a new policy, the current doesn't state any policy about this? I was aiming at the fact that this policy doesn't give any clue about what happens when the validity period expires while the Abstract of the proposal does mention 'how these certificates should be maintained'. Expiring certificates are part of this, expering due to CRL's is mentioned, but expering due to validity period is open. Jac -- Jac Kloots Network Services SURFnet bv From sander at steffann.nl Wed Feb 9 16:10:45 2011 From: sander at steffann.nl (Sander Steffann) Date: Wed, 9 Feb 2011 16:10:45 +0100 Subject: [address-policy-wg] 2008-08 New Version and Draft Document Published (Initial Certification Policy for Provider Aggregatable Address Space Holders) In-Reply-To: References: <20110209140036.9C4BB6A002@postboy.ripe.net> <20110209141312.GD44800@Space.Net> <1D1904D8-1527-4CC4-8FB3-B3D419AB41DF@steffann.nl> Message-ID: Hi, >> But at that point in time you will also have received a new certificate with a new validity period. > > And this will be a new policy, the current doesn't state any policy about this? It states 'Certificates will at all times reflect the registration status of the resource.', so as long as the registration status is ok you can get certificates for it. - Sander From alexb at ripe.net Wed Feb 9 16:43:00 2011 From: alexb at ripe.net (Alex Band) Date: Wed, 9 Feb 2011 16:43:00 +0100 Subject: [address-policy-wg] 2008-08 New Version and Draft Document Published (Initial Certification Policy for Provider Aggregatable Address Space Holders) In-Reply-To: References: <20110209140036.9C4BB6A002@postboy.ripe.net> <20110209141312.GD44800@Space.Net> Message-ID: <1D5D8351-256A-4AF4-B0C5-43C7ED5F3330@ripe.net> On 9 Feb 2011, at 15:22, Jac Kloots wrote: > On Wed, 9 Feb 2011, Gert Doering wrote: > >> Dear Working Group, >> >> as you might have noticed, this proposal is nicknamed "the icelandic >> saga" because it goes on and on and on and on... >> >> We'd really like to bring this to conclusion, and for that, we need >> *feedback from the community*. So please let us know: >> >> - this is what you want to see implemented > > want to see this implemented. > > One question; what happens after the validity period of the certificate expires? The validity set on a certificate is 18 months, but it is automatically renewed every 12 months for as long as you have resources registered. Like it says in the Policy proposal: > Certificates will at all times reflect the registration status of the resource. This means when new resources are added to your registry, an updated certificate listing the new set of resources is automatically issued. When you return resources to the RIPE NCC, a new, updated certificate is issued and the old one is revoked. It is not possible for a resource certificate to exist listing no resources at all. So when you seize to be an LIR and all of your resources are returned to the RIPE NCC, the result is that the certificate and all child objects automatically disappear from the repository. This exactly matches the business processes of the RIPE NCC. Cheers, Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1728 bytes Desc: not available URL: From ebais at a2b-internet.com Wed Feb 9 16:50:20 2011 From: ebais at a2b-internet.com (Erik Bais) Date: Wed, 9 Feb 2011 16:50:20 +0100 Subject: [address-policy-wg] 2008-08 New Version and Draft Document Published (Initial Certification Policy for Provider Aggregatable Address Space Holders) In-Reply-To: <20110209141312.GD44800@Space.Net> References: <20110209140036.9C4BB6A002@postboy.ripe.net> <20110209141312.GD44800@Space.Net> Message-ID: <00d901cbc871$0e966cb0$2bc34610$@com> >?- you're in favour of the general principle, want some details changed, >?? but agree to pospone that to the next round of certificate-related >?? proposals (like "this proposal does not cover PI" - yes, we know, the >?? plan was to "start with the easy bits = PA"). Why is it stated : > This proposal only applies to IPv4 ALLOCATED PA blocks that were issued by the RIPE NCC and excludes early registration and legacy space, as well as > blocks marked as ALLOCATED UNSPECIFIED or ALLOCATED PI. That was one of the topics I noticed when I used the certification website for my own LIR. ( After some peer pressure by a guy named Alex B. ) I would think/argue that this would be more useful for specifically PI, rather than just doing it for PA. And to make things probably worse for the discussion, I would think that having the LIR manage this on behalf of their PI customers, might not be a bad idea, also because the location of the online certification site is in the LIR portal and this could be seen as one of the tasks a LIR does on behalf for their customers. PI LIR customers that doesn't want their specific LIR to deal with their certification process, could either change LIR or change to a Direct Assignment End-User, but I'm guessing that would be a very small group of all PI customers. It is my experience that PI customers don't want to deal with the 'RIPE stuff' and/or are not very responsive into sorting their stuff out, as long as they have access to their addresses/objects. And yes, I do realize that having a third party in the middle (the LIR) might be seen as an additional security risk, specifically in dealing with certificates, but that could be a different discussion. If the CA-TF isn't planning to change the policy to include ALLOCATED PI, is there a set time-frame on when this will be proposed / implemented ? Regards, Erik Bais Erik Bais | A2B Internet BV?| +31 299 707 115 ( Office ) | +31 6 5122 1952 ( Dutch cell ) | ebais at a2b-internet.com | From Jac.Kloots at surfnet.nl Wed Feb 9 16:51:31 2011 From: Jac.Kloots at surfnet.nl (Jac Kloots) Date: Wed, 9 Feb 2011 16:51:31 +0100 (CET) Subject: [address-policy-wg] 2008-08 New Version and Draft Document Published (Initial Certification Policy for Provider Aggregatable Address Space Holders) In-Reply-To: <1D5D8351-256A-4AF4-B0C5-43C7ED5F3330@ripe.net> References: <20110209140036.9C4BB6A002@postboy.ripe.net> <20110209141312.GD44800@Space.Net> <1D5D8351-256A-4AF4-B0C5-43C7ED5F3330@ripe.net> Message-ID: Alex, On Wed, 9 Feb 2011, Alex Band wrote: >> One question; what happens after the validity period of the certificate expires? > > The validity set on a certificate is 18 months, but it is automatically > renewed every 12 months for as long as you have resources registered. Like > it says in the Policy proposal: This is exactly what I was looking for, the 12 month automatically renewal mechanisme. As this is a policy, shouldn't this be stated in this policy? Regards, Jac -- Jac Kloots Network Services SURFnet bv From nigel at titley.com Wed Feb 9 16:31:02 2011 From: nigel at titley.com (Nigel Titley) Date: Wed, 09 Feb 2011 15:31:02 +0000 Subject: [address-policy-wg] 2008-08 New Version and Draft Document Published (Initial Certification Policy for Provider Aggregatable Address Space Holders) In-Reply-To: References: <20110209140036.9C4BB6A002@postboy.ripe.net> <20110209141312.GD44800@Space.Net> Message-ID: <1297265462.1881.196.camel@ntitley-laptop> On Wed, 2011-02-09 at 14:21 +0000, James Blessing wrote: > On 9 February 2011 14:13, Gert Doering wrote: > > As epic as this is, my problem with that document is that it contains > things like > > "Resource Public Key Infrastructure (RPKI) certificates over their > Provider Aggregatable" > > which I think I understand, but feels like I might be reading it wrong > (I think over is the wrong word) Well, we have to decide where we stop with explanations. I have to admit that we assumed that members would be aware of what an RKPI certificate was (at least in general terms) and also that they knew what Provider Aggregatable space was. We did expand the acronyms, at least. > "RIPE NCC members in good standing" > > Not seen 'in good standing' defined anywhere True, although this form of words is pretty universally understood to mean "having paid their bill and not having been suspended for any reason". The full rules on membership are defined in the Articles of Association, (ripe-514) > > "Certificates will be issued with a validity period of up to 18 months > or as otherwise stated in the RIPE NCC Certificate Practice > Statement." > > which is silly and should loose the whole 18 months bit (or the > practice statement bit) This derives from the fact that when this version of the policy was written, the CPS had still not been finalised. The intent of the statement is "the CPS takes precedent if it exists, otherwise 18 months" which seems a sensible way of putting in a default. Nigel From alexb at ripe.net Wed Feb 9 17:17:13 2011 From: alexb at ripe.net (Alex Band) Date: Wed, 9 Feb 2011 17:17:13 +0100 Subject: [address-policy-wg] 2008-08 New Version and Draft Document Published (Initial Certification Policy for Provider Aggregatable Address Space Holders) In-Reply-To: References: <20110209140036.9C4BB6A002@postboy.ripe.net> <20110209141312.GD44800@Space.Net> <1D5D8351-256A-4AF4-B0C5-43C7ED5F3330@ripe.net> Message-ID: On 9 Feb 2011, at 16:51, Jac Kloots wrote: > > Alex, > > On Wed, 9 Feb 2011, Alex Band wrote: > >>> One question; what happens after the validity period of the certificate expires? >> >> The validity set on a certificate is 18 months, but it is automatically renewed every 12 months for as long as you have resources registered. Like it says in the Policy proposal: > > This is exactly what I was looking for, the 12 month automatically renewal mechanisme. As this is a policy, shouldn't this be stated in this policy? This is described in the Certification Practice Statement: http://www.ripe.net/lir-services/resource-management/certification/cps/view See section 4.2.2. Approval of certificate applications The validity and renewal of certificates is operational (this is why it in described as such in the CPS), because it needs to match with other RIPE NCC business processes. You'll notice that the six months grace period is exactly matching to the different billing phases an LIR enters when their membership is not renewed. These phases last six months in total, after which the RIPE NCC will starts the process of closing the LIR and de-register their resources. The result being that their certificate is revoked (because no resources = no resource certificate). -Alex Reference: http://www.ripe.net/lir-services/member-support/info/billing/billing-fees-lir -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1728 bytes Desc: not available URL: From gert at space.net Wed Feb 9 18:09:40 2011 From: gert at space.net (Gert Doering) Date: Wed, 9 Feb 2011 18:09:40 +0100 Subject: [address-policy-wg] 2008-08 New Version and Draft Document Published (Initial Certification Policy for Provider Aggregatable Address Space Holders) In-Reply-To: <00d901cbc871$0e966cb0$2bc34610$@com> References: <20110209140036.9C4BB6A002@postboy.ripe.net> <20110209141312.GD44800@Space.Net> <00d901cbc871$0e966cb0$2bc34610$@com> Message-ID: <20110209170940.GE44800@Space.Net> Hi, On Wed, Feb 09, 2011 at 04:50:20PM +0100, Erik Bais wrote: > >?- you're in favour of the general principle, want some details changed, > >?? but agree to pospone that to the next round of certificate-related > >?? proposals (like "this proposal does not cover PI" - yes, we know, the > >?? plan was to "start with the easy bits = PA"). > > Why is it stated : > > > This proposal only applies to IPv4 ALLOCATED PA blocks that were issued by > the RIPE NCC and excludes early registration and legacy space, as well as > > blocks marked as ALLOCATED UNSPECIFIED or ALLOCATED PI. As I said: "start with the easy bits". *This* proposal is "start with PA" (because the CA TF though that it would be easier to start with just a subset). When we get this done, the CA-TF - or anyone else who wants to driver this forward - can do another one for PI and/or ERX space. [..] > And to make things probably worse for the discussion, I would think that > having the LIR manage this on behalf of their PI customers, might not be a > bad idea, also because the location of the online certification site is in > the LIR portal and this could be seen as one of the tasks a LIR does on > behalf for their customers. > PI LIR customers that doesn't want their specific LIR to deal with their > certification process, could either change LIR or change to a Direct > Assignment End-User, but I'm guessing that would be a very small group of > all PI customers. This sounds like a good rationale why we didn't cover PI in this initial proposal - more thought is needed. So please don't drag this specific thread into "how to do it with PI?" land, but focus on *this* proposal "do certificates for PA, or not?" > If the CA-TF isn't planning to change the policy to include ALLOCATED PI, is > there a set time-frame on when this will be proposed / implemented ? You're welcome to propose a parallel proposal for PI right away - but I think process-wise it would be easier to wait for a decision on this one, and then base the next on it. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 306 bytes Desc: not available URL: From emadaio at ripe.net Thu Feb 10 08:49:51 2011 From: emadaio at ripe.net (emadaio at ripe.net) Date: Thu, 10 Feb 2011 08:49:51 +0100 Subject: [address-policy-wg] 2010-06 Proposal Accepted (Registration Requirements for IPv6 End User Assignments) Message-ID: <20110210074951.87C2C6A002@postboy.ripe.net> Dear Colleagues, Consensus has been reached, and the proposal described in 2010-06 has been accepted by the RIPE community. The updated policy "IPv6 Address Allocation and Assignment Policy" is available at: http://www.ripe.net/ripe/docs/ripe-512 The new policy "Value of the "status:" and "assignment-size:" attributes in inet6num objects for sub-assigned PA space" is available at: http://www.ripe.net/ripe/docs/ripe-513 You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2010-06 Thank you for your input. Regards Emilio Madaio Policy Development Officer RIPE NCC From leo.vegoda at icann.org Sat Feb 12 00:46:16 2011 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 11 Feb 2011 15:46:16 -0800 Subject: [address-policy-wg] Re: [policy-announce] 2008-08 New Version and Draft Document Published (Initial Certification Policy for Provider Aggregatable Address Space Holders) In-Reply-To: <20110209140036.9C4BB6A002@postboy.ripe.net> References: <20110209140036.9C4BB6A002@postboy.ripe.net> Message-ID: Hi, On 9 Feb 2011, at 6:00, Emilio Madaio wrote: [...] > The proposal will now undergo a two weeks Review Phase as explained in > the previous message available at: > > http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2011/msg00022.html > > > 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 It would be useful if you could hyperlink from the draft policy document to the CPS and/or include the URL for the CPS in the body of the text. Incidentally, is the CPS considered an integral part of the policy? Section 5. 4. 4 implies that the CPS is likely to be updated in the future. If so, what kind of review will this WG be asked to do before a new CPS comes into effect? Also, what notice period is given before updating the CPS? Regards, Leo Vegoda From ysimeonov at neterra.net Mon Feb 14 11:12:44 2011 From: ysimeonov at neterra.net (Yasen Simeonov(Neterra NMT)) Date: Mon, 14 Feb 2011 12:12:44 +0200 Subject: [address-policy-wg] IPv6 PI resource question! Message-ID: <4D59001C.7080306@neterra.net> Hi, please explain me the following case: There is a small company /ISP/ that wants PI IPs to be independent of upstream providers. The company would not make sub-allocation and will only provide its customers with addresses for Internet access, but these IPs will be the company's infrastructural addresses. The company will use DHCP pool to distribute the addresses to its customers, these will be its own infrastructure addresses and not to the customers /they may receive every time different addresses/. Can that company receive PI IPv6 considering the policy? Thanks, Yasen Simeonov -- Yasen Simeonov Network Management Team Neterra Ltd. Sofia, Bulgaria Phone: +359 2 974 33 11 Fax: +359 2 975 34 36 Mobile: +359 887 477 540 http://www.neterra.net From sander at steffann.nl Mon Feb 14 11:43:28 2011 From: sander at steffann.nl (Sander Steffann) Date: Mon, 14 Feb 2011 11:43:28 +0100 Subject: [address-policy-wg] IPv6 PI resource question! In-Reply-To: <4D59001C.7080306@neterra.net> References: <4D59001C.7080306@neterra.net> Message-ID: <2D61CF3D-0859-4A27-A49A-371E75325BBB@steffann.nl> Hello Yasen, > There is a small company /ISP/ that wants PI IPs to be independent of upstream providers. > The company would not make sub-allocation and will only provide its customers with addresses for Internet access, but these IPs will be the company's infrastructural addresses. > The company will use DHCP pool to distribute the addresses to its customers, these will be its own infrastructure addresses and not to the customers /they may receive every time different addresses/. > > Can that company receive PI IPv6 considering the policy? With IPv6 you don't give every user one IP address (which would be your infrastructure), but you usually assign them a block of addresses. For making assignments to end-users you need a PA block. And: there is no 'your infrastructure' rule for IPv6. That is only defined for IPv4. This difference has been discussed in the past, and the conclusion was that this difference is intentional. Does anyone feel that this should be re-evaluated? In short: if you provide IPv6 access services to customers you will need to become an LIR and get an IPv6-PA block. I hope this clarifies things for you, Sander From ysimeonov at neterra.net Mon Feb 14 13:59:37 2011 From: ysimeonov at neterra.net (Yasen Simeonov(Neterra NMT)) Date: Mon, 14 Feb 2011 14:59:37 +0200 Subject: [address-policy-wg] IPv6 PI resource question! In-Reply-To: <2D61CF3D-0859-4A27-A49A-371E75325BBB@steffann.nl> References: <4D59001C.7080306@neterra.net> <2D61CF3D-0859-4A27-A49A-371E75325BBB@steffann.nl> Message-ID: <4D592739.2050004@neterra.net> Thanks for the replay. I think this should be reevaluated! On 14/02/2011 12:43, Sander Steffann wrote: > With IPv6 you don't give every user one IP address (which would be your infrastructure), but you usually assign them a block of addresses. For making assignments to end-users you need a PA block. And: there is no 'your infrastructure' rule for IPv6. That is only defined for IPv4. Is that mean that the ISPs should make an entry in the RIPE's database for each household to which gives access to the Internet? Here is reveal the danger we as LIR can not give PI IPv6 to this ISP, but some of our competitors /another LIR/ to conceal the fact that they will be given to end customers / households / and the ISP will receive this resource. How would you advise a small ISP in a small rural area which has no financial ability to pay the fee for becoming LIR, to be independent from the upstream provider ? What would be the reason a company that deals with Internet delivery can not get a PI IPv6 resources, but a company which is engaged in other activity can get it. Please share your opinion. -- Yasen Simeonov Network Management Team Neterra Ltd. Sofia, Bulgaria Phone: +359 2 974 33 11 Fax: +359 2 975 34 36 Mobile: +359 887 477 540 http://www.neterra.net From vegar at rentarack.no Mon Feb 14 14:08:15 2011 From: vegar at rentarack.no (=?ISO-8859-1?Q?Vegar_L=F8v=E5s?=) Date: Mon, 14 Feb 2011 14:08:15 +0100 Subject: [address-policy-wg] IPv6 PI resource question! In-Reply-To: <4D592739.2050004@neterra.net> References: <4D59001C.7080306@neterra.net> <2D61CF3D-0859-4A27-A49A-371E75325BBB@steffann.nl> <4D592739.2050004@neterra.net> Message-ID: <4D59293F.3050300@rentarack.no> Hello, I also thinks this policy should be reevaluated. We are experiencing almost the same issue, but more related to the "your infrastructure" part. One of our customers is a hosting company, and their application got rejected because they wanted to use the addresses for their shared hosting service. This is not how it should be, as a shared hosting server has 1 IP address shared among all of the customers. Why would each customer need it's own allocation? -- Best regards, Vegar L?v?s Rent a Rack AS On 14.02.2011 13:59, Yasen Simeonov(Neterra NMT) wrote: > Thanks for the replay. > I think this should be reevaluated! > > On 14/02/2011 12:43, Sander Steffann wrote: >> With IPv6 you don't give every user one IP address (which would be >> your infrastructure), but you usually assign them a block of >> addresses. For making assignments to end-users you need a PA block. >> And: there is no 'your infrastructure' rule for IPv6. That is only >> defined for IPv4. > Is that mean that the ISPs should make an entry in the RIPE's database > for each household to which gives access to the Internet? > > > Here is reveal the danger we as LIR can not give PI IPv6 to this ISP, > but some of our competitors /another LIR/ > to conceal the fact that they will be given to end customers / > households / and the ISP will receive this resource. > > How would you advise a small ISP in a small rural area which has no > financial ability to pay the fee for becoming LIR, > to be independent from the upstream provider ? > > What would be the reason a company that deals with Internet delivery can > not get a PI IPv6 resources, but a company which is engaged in other > activity can get it. > > Please share your opinion. > > From Jasper.Jans at espritxb.nl Mon Feb 14 14:43:37 2011 From: Jasper.Jans at espritxb.nl (Jasper Jans) Date: Mon, 14 Feb 2011 14:43:37 +0100 Subject: [address-policy-wg] IPv6 PI resource question! In-Reply-To: <4D59293F.3050300@rentarack.no> References: <4D59001C.7080306@neterra.net> <2D61CF3D-0859-4A27-A49A-371E75325BBB@steffann.nl> <4D592739.2050004@neterra.net> <4D59293F.3050300@rentarack.no> Message-ID: <55557D0EBE9495428BFE94EF8BC5EBD20101CE61AE99@EXCH01.campus.local> We are facing a different issue but would also like a reevaluation of the policy. We have a fair amount of customers that have IPv4 PI space for valid reasons. The IPv6 PI policy calls for demonstrated multihoming - which if we read it correctly means that if these customers want to migrate from IPv4 to IPv6 all of a sudden they will require an ASN as well as a second transit provider. We would like to see a provision in the policy that allows IPv4 to IPv6 migrations with regards to PI space - say if you qualified for IPv4 PI space - irrespective of what the rules are for IPv6 PI space - you will always qualify for IPv6 PI space. This will allow stricter rules for new applications while also easing the migration from v4 to v6. Jasper -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Vegar L?v?s Sent: Monday, February 14, 2011 2:08 PM To: Yasen Simeonov(Neterra NMT) Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] IPv6 PI resource question! Hello, I also thinks this policy should be reevaluated. We are experiencing almost the same issue, but more related to the "your infrastructure" part. One of our customers is a hosting company, and their application got rejected because they wanted to use the addresses for their shared hosting service. This is not how it should be, as a shared hosting server has 1 IP address shared among all of the customers. Why would each customer need it's own allocation? -- Best regards, Vegar L?v?s Rent a Rack AS On 14.02.2011 13:59, Yasen Simeonov(Neterra NMT) wrote: > Thanks for the replay. > I think this should be reevaluated! > > On 14/02/2011 12:43, Sander Steffann wrote: >> With IPv6 you don't give every user one IP address (which would be >> your infrastructure), but you usually assign them a block of >> addresses. For making assignments to end-users you need a PA block. >> And: there is no 'your infrastructure' rule for IPv6. That is only >> defined for IPv4. > Is that mean that the ISPs should make an entry in the RIPE's database > for each household to which gives access to the Internet? > > > Here is reveal the danger we as LIR can not give PI IPv6 to this ISP, > but some of our competitors /another LIR/ > to conceal the fact that they will be given to end customers / > households / and the ISP will receive this resource. > > How would you advise a small ISP in a small rural area which has no > financial ability to pay the fee for becoming LIR, > to be independent from the upstream provider ? > > What would be the reason a company that deals with Internet delivery can > not get a PI IPv6 resources, but a company which is engaged in other > activity can get it. > > Please share your opinion. > > Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer From sander at steffann.nl Mon Feb 14 15:44:04 2011 From: sander at steffann.nl (Sander Steffann) Date: Mon, 14 Feb 2011 15:44:04 +0100 Subject: [address-policy-wg] IPv6 PI resource question! In-Reply-To: <4D592739.2050004@neterra.net> References: <4D59001C.7080306@neterra.net> <2D61CF3D-0859-4A27-A49A-371E75325BBB@steffann.nl> <4D592739.2050004@neterra.net> Message-ID: <8F621F87-82DF-45AB-B363-FF761A3FD61C@steffann.nl> Hi Yasen, > Thanks for the replay. > I think this should be reevaluated! Can you give your reasons to reevaluate this? The way it currently works is that if you delegate addresses to your customers you must be an LIR. Why and how should that be changed in your opinion? >> With IPv6 you don't give every user one IP address (which would be your infrastructure), but you usually assign them a block of addresses. For making assignments to end-users you need a PA block. And: there is no 'your infrastructure' rule for IPv6. That is only defined for IPv4. > Is that mean that the ISPs should make an entry in the RIPE's database for each household to which gives access to the Internet? No, that is not necessary. A policy proposal that describes what you can do has just been accepted (http://www.ripe.net/ripe/policies/proposals/2010-06). > How would you advise a small ISP in a small rural area which has no financial ability to pay the fee for becoming LIR, > to be independent from the upstream provider ? The problem here is that this financial barrier can not be resolved here. The RIPE NCC membership fee is set by the RIPE NCC General Meeting, not here. > What would be the reason a company that deals with Internet delivery can not get a PI IPv6 resources, but a company which is engaged in other activity can get it. An ISP can still get PI addresses. You just can't delegate addresses from PI space to customers. You need PA space for that. - Sander From jordi.palet at consulintel.es Mon Feb 14 15:50:39 2011 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 14 Feb 2011 15:50:39 +0100 Subject: [address-policy-wg] IPv6 PI resource question! In-Reply-To: <8F621F87-82DF-45AB-B363-FF761A3FD61C@steffann.nl> Message-ID: Hi Sander, Not exactly the same issue, but last week I was consulting a customer that requires PI, because the type of services they offer and they have hundreds of sites in Europe, and not all them are multihomed. Somehow, one choice may be to become an LIR, but because not all the sites are using the same ISP, they will need to announce /48 from the /32, not a good way. So the alternative is to request a PI for each site, and today, they can only get this for those multihomed. The other point, is that in some situations, it will be good to aggregate all those PI (or some of them), which will depend on the RIPE NCC staff to be able to provide contiguous /48s. So ... should we propose to remove the multihoming barrier ? What is the feeling of the list members ? Regards, Jordi -----Mensaje original----- De: Sander Steffann Responder a: Fecha: Mon, 14 Feb 2011 15:44:04 +0100 Para: "Yasen Simeonov (Neterra NMT)" CC: Asunto: Re: [address-policy-wg] IPv6 PI resource question! >Hi Yasen, > >> Thanks for the replay. >> I think this should be reevaluated! > >Can you give your reasons to reevaluate this? The way it currently works >is that if you delegate addresses to your customers you must be an LIR. >Why and how should that be changed in your opinion? > >>> With IPv6 you don't give every user one IP address (which would be >>>your infrastructure), but you usually assign them a block of addresses. >>>For making assignments to end-users you need a PA block. And: there is >>>no 'your infrastructure' rule for IPv6. That is only defined for IPv4. >> Is that mean that the ISPs should make an entry in the RIPE's database >>for each household to which gives access to the Internet? > >No, that is not necessary. A policy proposal that describes what you can >do has just been accepted >(http://www.ripe.net/ripe/policies/proposals/2010-06). > >> How would you advise a small ISP in a small rural area which has no >>financial ability to pay the fee for becoming LIR, >> to be independent from the upstream provider ? > >The problem here is that this financial barrier can not be resolved here. >The RIPE NCC membership fee is set by the RIPE NCC General Meeting, not >here. > >> What would be the reason a company that deals with Internet delivery >>can not get a PI IPv6 resources, but a company which is engaged in other >>activity can get it. > >An ISP can still get PI addresses. You just can't delegate addresses from >PI space to customers. You need PA space for that. > >- Sander > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.facebook.com/IPv6.now This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From Jamie.Stallwood at imerja.com Mon Feb 14 15:50:33 2011 From: Jamie.Stallwood at imerja.com (Jamie Stallwood) Date: Mon, 14 Feb 2011 14:50:33 -0000 Subject: [address-policy-wg] IPv6 PI resource question! References: <4D59001C.7080306@neterra.net> <2D61CF3D-0859-4A27-A49A-371E75325BBB@steffann.nl> <4D592739.2050004@neterra.net> <8F621F87-82DF-45AB-B363-FF761A3FD61C@steffann.nl> Message-ID: <7B640CC73C18D94F83479A1D0B9A140402AD35CB@bhw-srv-dc1.imerja.com> And SUB-ALLOCATED PA space can be independently routed, if you really don't want to become a LIR; but of course it's dependent on maintaining a relationship with a friendly LIR... Kind regards Jamie Stallwood -- Jamie Stallwood Security Specialist Imerja Limited Tel: 07795 840385 jamie.stallwood at imerja.com -----Original Message----- From: address-policy-wg-admin at ripe.net on behalf of Sander Steffann Sent: Mon 14/02/2011 14:44 To: Yasen Simeonov(Neterra NMT) Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] IPv6 PI resource question! Hi Yasen, > Thanks for the replay. > I think this should be reevaluated! Can you give your reasons to reevaluate this? The way it currently works is that if you delegate addresses to your customers you must be an LIR. Why and how should that be changed in your opinion? >> With IPv6 you don't give every user one IP address (which would be your infrastructure), but you usually assign them a block of addresses. For making assignments to end-users you need a PA block. And: there is no 'your infrastructure' rule for IPv6. That is only defined for IPv4. > Is that mean that the ISPs should make an entry in the RIPE's database for each household to which gives access to the Internet? No, that is not necessary. A policy proposal that describes what you can do has just been accepted (http://www.ripe.net/ripe/policies/proposals/2010-06). > How would you advise a small ISP in a small rural area which has no financial ability to pay the fee for becoming LIR, > to be independent from the upstream provider ? The problem here is that this financial barrier can not be resolved here. The RIPE NCC membership fee is set by the RIPE NCC General Meeting, not here. > What would be the reason a company that deals with Internet delivery can not get a PI IPv6 resources, but a company which is engaged in other activity can get it. An ISP can still get PI addresses. You just can't delegate addresses from PI space to customers. You need PA space for that. - Sander -- Imerja Limited Tel: 0870 8611488 | Fax: 0870 8611489 | 24x7 ISOC: 0870 8611490 | Web: www.imerja.com Registered Office: Paragon House, Paragon Business Park, Chorley New Road, Horwich, Bolton BL6 6HG Registered in England and Wales No. 5180119 VAT Registered No. 845 0647 22 ISO Registered Firm No. GB2001527 This email is confidential and intended solely for the person or organisation to which it is addressed. It may contain privileged and confidential information. If you are not the intended recipient(s) you should not use, copy, distribute or take any action or reliance on it, since to do so is strictly prohibited and may be unlawful. If you have received this transmission in error please notify the sender immediately by email reply and delete it from your system. E-mail messages are not secure and attachments could contain software viruses which may damage your system. Whilst every reasonable precaution has been taken to minimise this risk, Imerja Limited cannot accept any liability for any damage sustained as a result of these factors. You are advised to carry out your own virus checks before opening any attachment. Any views or opinions expressed in this e-mail are solely those of the author and do not represent those of Imerja Limited unless otherwise stated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Mon Feb 14 16:24:05 2011 From: sander at steffann.nl (Sander Steffann) Date: Mon, 14 Feb 2011 16:24:05 +0100 Subject: [address-policy-wg] IPv6 PI resource question! In-Reply-To: References: Message-ID: Hi, > So ... should we propose to remove the multihoming barrier ? > > What is the feeling of the list members ? The last time we discussed this the feeling seemed to be that such a limitation was necessary to prevent an explosion of the IPv6 routing table. On the other hand we want people to start using IPv6. I am really curious what the rest of the list thinks about this. - Sander From gert at space.net Mon Feb 14 16:51:24 2011 From: gert at space.net (Gert Doering) Date: Mon, 14 Feb 2011 16:51:24 +0100 Subject: [address-policy-wg] IPv6 PI resource question! In-Reply-To: References: <8F621F87-82DF-45AB-B363-FF761A3FD61C@steffann.nl> Message-ID: <20110214155124.GQ44800@Space.Net> Hi, On Mon, Feb 14, 2011 at 03:50:39PM +0100, JORDI PALET MARTINEZ wrote: > requires PI, because the type of services they offer and they have Could you elaborate on this? What type of *service* needs PI? In the discussions leading to the current PI policy, the consensus was "for BGP-style multihoming, an entry in the global routing table is inevitable, so PI won't make this better or worse" - so people agreed that this specific usage case warrants PI, and for everything else, they (well, *you* - this community!) wanted to see aggregateable addresses used... 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 From sergey at devnull.ru Mon Feb 14 17:12:46 2011 From: sergey at devnull.ru (Sergey Myasoedov) Date: Mon, 14 Feb 2011 17:12:46 +0100 Subject: [address-policy-wg] IPv6 PI resource question! In-Reply-To: References: Message-ID: <523082263.20110214171246@devnull.ru> Hello, Monday, February 14, 2011, 4:24:05 PM, you wrote: >> So ... should we propose to remove the multihoming barrier ? >> What is the feeling of the list members ? SS> The last time we discussed this the feeling seemed to be that such a SS> limitation was necessary to prevent an explosion of the IPv6 routing SS> table. On the other hand we want people to start using IPv6. I am really SS> curious what the rest of the list thinks about this. I think that current IPv6 assignment policy delays IPv6 implementation. ISPs can assign addresses using point-to-point protocols or even give /64 from the PI /48 assignment or use whole /48 for own infrastructure - you'll never know this exactly. As for me, an additional barrier for migration to IPv6 should be removed. -- Sergey From emadaio at ripe.net Mon Feb 14 16:57:06 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Mon, 14 Feb 2011 16:57:06 +0100 Subject: [address-policy-wg] RIPE 61 Address Policy WG Meeting Draft Minutes Message-ID: <4D5950D2.5040300@ripe.net> Dear Colleagues, The draft minutes of Address Policy Working Group sessions from RIPE 61 are now available at: http://www.ripe.net/ripe/groups/wg/ap/minutes/minutes-from-ripe-61 Best Regards Emilio Madaio Policy Development Officer RIPE NCC From mark at streamservice.nl Mon Feb 14 19:15:28 2011 From: mark at streamservice.nl (Mark Scholten) Date: Mon, 14 Feb 2011 19:15:28 +0100 Subject: [address-policy-wg] IPv6 PI resource question! In-Reply-To: References: Message-ID: <022701cbcc73$288aee10$79a0ca30$@nl> > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Sander Steffann > Sent: Monday, February 14, 2011 4:24 PM > Hi, > > > So ... should we propose to remove the multihoming barrier ? > > > > What is the feeling of the list members ? > > The last time we discussed this the feeling seemed to be that such a > limitation was necessary to prevent an explosion of the IPv6 routing > table. On the other hand we want people to start using IPv6. I am > really curious what the rest of the list thinks about this. > > - Sander Hello Sander, I would prefer to remove some limitations. The current option for someone that has IPv4 PI space to get IPv6 PI space isn't easy enough if you ask me. Making the transition as easy as possible (while keeping PA or PI space) should be possible I think. Another option (but that isn't something for this list I guess) is to have some LIR extra light account with just 1 IPv6 range and for more you need to become a normal LIR, an extra limitation could be that it would be required that you've some IPv4 PI space. Regards, Mark From jordi.palet at consulintel.es Mon Feb 14 20:21:32 2011 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Mon, 14 Feb 2011 20:21:32 +0100 Subject: [address-policy-wg] IPv6 PI resource question! In-Reply-To: <20110214155124.GQ44800@Space.Net> Message-ID: I know ... very well :-) I will let the customer, which is in the list to decide if they want to provide details, I can't disclose them. Regards, Jordi -----Mensaje original----- De: Gert Doering Responder a: Fecha: Mon, 14 Feb 2011 16:51:24 +0100 Para: Jordi Palet Martinez CC: Asunto: Re: [address-policy-wg] IPv6 PI resource question! >Hi, > >On Mon, Feb 14, 2011 at 03:50:39PM +0100, JORDI PALET MARTINEZ wrote: >> requires PI, because the type of services they offer and they have > >Could you elaborate on this? What type of *service* needs PI? > >In the discussions leading to the current PI policy, the consensus was >"for BGP-style multihoming, an entry in the global routing table is >inevitable, so PI won't make this better or worse" - so people agreed >that this specific usage case warrants PI, and for everything else, >they (well, *you* - this community!) wanted to see aggregateable >addresses used... > >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 > ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.facebook.com/IPv6.now This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From sander at steffann.nl Mon Feb 14 23:26:29 2011 From: sander at steffann.nl (Sander Steffann) Date: Mon, 14 Feb 2011 23:26:29 +0100 Subject: [address-policy-wg] IPv6 PI resource question! In-Reply-To: <022701cbcc73$288aee10$79a0ca30$@nl> References: <022701cbcc73$288aee10$79a0ca30$@nl> Message-ID: Hi Mark, > Another option (but that isn't something for > this list I guess) is to have some LIR extra light account with just 1 IPv6 > range and for more you need to become a normal LIR, an extra limitation > could be that it would be required that you've some IPv4 PI space. This might be a valid option, but indeed not as something for this list but as something for the RIPE NCC GM. I do get the impression here that the current policy (Get a /32 or larger PA for providing access service to customers, or get a /48 PI as a multi homed end-user) is not 'wrong', but that people have problems with the cost of running an LIR. If this is the case I am not sure if we should start changing the policy... - Sander From mark at streamservice.nl Mon Feb 14 23:44:41 2011 From: mark at streamservice.nl (Mark Scholten) Date: Mon, 14 Feb 2011 23:44:41 +0100 Subject: [address-policy-wg] IPv6 PI resource question! In-Reply-To: References: <022701cbcc73$288aee10$79a0ca30$@nl> Message-ID: <028e01cbcc98$c4de7640$4e9b62c0$@nl> > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Sander Steffann > > Another option (but that isn't something for > > this list I guess) is to have some LIR extra light account with just > 1 IPv6 > > range and for more you need to become a normal LIR, an extra > limitation > > could be that it would be required that you've some IPv4 PI space. > > This might be a valid option, but indeed not as something for this list > but as something for the RIPE NCC GM. > > I do get the impression here that the current policy (Get a /32 or > larger PA for providing access service to customers, or get a /48 PI as > a multi homed end-user) is not 'wrong', but that people have problems > with the cost of running an LIR. If this is the case I am not sure if > we should start changing the policy... Hello Sander, However as this isn't an option for this list (and I don't know if this idea is something that people could agree on at the RIPE NCC GM) I think this list should look for other options to "solve" this practical problem. That could be changing a policy to make it easier to get IPv6 PI if you already own IPv4 PI. I'm happy to write down a proposal for the changes. However I'll vote against it when it isn't accepted and the RIPE NCC GM did decide before that moment to create some option for this problem that is cheaper (but possible very limited, like only 1 IPv6 /48 range and for more you need a LIR account like they currently exist). Regards, Mark From leo.vegoda at icann.org Tue Feb 15 01:52:43 2011 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 14 Feb 2011 16:52:43 -0800 Subject: [address-policy-wg] IPv6 PI resource question! In-Reply-To: References: <022701cbcc73$288aee10$79a0ca30$@nl> Message-ID: <72CC3721-E974-42A0-8781-74A9C74A02E5@icann.org> Sander, On Feb 14, 2011, at 2:26 PM, Sander Steffann wrote: [?] > I do get the impression here that the current policy (Get a /32 or larger PA for providing access service to customers, or get a /48 PI as a multi homed end-user) is not 'wrong', but that people have problems with the cost of running an LIR. If this is the case I am not sure if we should start changing the policy? I think you have highlighted a major element of the current system. If you are multi-homed you can either get an IPv6 PI block for whatever a friendly LIR will charge you but possibly less than ?100 per year. If you are prepared to pay whatever it costs to sign-up you can get a far larger block and do not have to multi-home. If some ISPs are going to try to get by on a /48 of PI to avoid the higher fees for becoming an LIR, their subscribers are less likely to be able to get decent sized assignments for their own networks. That means their ability to get the full benefit of the innovation we hope will happen around IPv6 will be diminished. Perhaps it would be fairer to take one of two options. Either require an LIR to be multi-homed to qualify for a /32 allocation, using the same justification as is used for the current IPv6 PI policy, or remove the artificial distinction between PI and PA for IPv6. That is, make anyone with a block of addresses received directly from the RIPE NCC a member. Doing the former would probably slow down IPv6 adoption. Doing the latter might well speed it up and it is even possible that the additional of an extra few thousand members would help to lower the annual fee to something that is more accessible to everyone. While that second issue is not strictly on topic for this WG, the fact is that the current billing scheme is built around the policy framework. Changing the policy framework will have knock-on consequences for the billing scheme and it would be irresponsible not to consider the likely impact of a major change to the policy on the billing scheme. Regards, Leo Vegoda From twilde at cymru.com Mon Feb 14 18:08:54 2011 From: twilde at cymru.com (Tim Wilde) Date: Mon, 14 Feb 2011 12:08:54 -0500 Subject: [address-policy-wg] Re: New IPv4 block allocated to RIPE NCC In-Reply-To: <4D4FBBDA.8040704@ripe.net> References: <4D4FBBDA.8040704@ripe.net> Message-ID: <4D5961A6.6030201@cymru.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings Andrea & Team, Are there any plans for these allocations to show up in the authoritative delegated-ripencc-latest file at ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest ? We use this file as the basis for our fullbogon efforts, which list all blocks that have not yet been allocated by RIRs, and as best as I can tell, these debogon blocks do not exist there, even though they are in the RIPE WHOIS. It would be ideal if this type of allocation could be included in the delegated file as well so we do not have to manually maintain exceptions, and so that users of our fullbogons feed can properly hit your debogon addresses. Best regards, Tim Wilde On 2/7/2011 4:31 AM, Andrea Cima wrote: > > [Apologies for duplicate mails] > > Dear Colleagues, > > The RIPE NCC has received the IPv4 address range 185/8 from the IANA. > > This is the final allocation of IPv4 address space that the RIPE NCC > will receive from the IANA as stated in ripe-436, "Global Policy for the > Allocation of the Remaining IPv4 Address Space". > > The minimum allocation size for this /8 has been set at /22. > > You may wish to adjust any filters you have in place accordingly. > > More information on the IP address space administered by the RIPE NCC > can be found on our website at: > > https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html > > Additionally, please note that three "pilot" prefixes will be announced > from this /8. The prefixes are: > > 185.0.0.0/16 > 185.1.0.0/21 > 185.1.24.0/24 > > They all originate in AS12654. > > The pingable addresses will be: > > 185.0.0.1 > 185.1.0.1 > 185.1.24.1 > > More information on this activity is available in the document > "De-Bogonising New Address Blocks", which can be found at: > > http://www.ripe.net/ripe/docs/ripe-351.html > > > Kind regards, > > Andrea Cima > Registration Services Manager > RIPE NCC > > > > - -- Tim Wilde, Senior Software Engineer, Team Cymru, Inc. twilde at cymru.com | +1-630-230-5433 | http://www.team-cymru.org/ -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAk1ZYaYACgkQluRbRini9tjvSwCbBfInbsBCpZFMSri0RpL6izHC gP0An0PLvq25ywtb6YTsaagGN9qj5Xwo =vTk+ -----END PGP SIGNATURE----- From emadaio at ripe.net Tue Feb 15 08:46:44 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 15 Feb 2011 08:46:44 +0100 Subject: [address-policy-wg] REMINDER; WAS Re: 2008-08 New Version and Draft Document Published (Initial Certification Policy for Provider Aggregatable Address Space Holders) Message-ID: <4D5A2F64.9030905@ripe.net> [Apologies for duplicates. Courtesy copy sent to Routing Working Group and RIPE NCC Services Working Group. Please direct feedback to the Address Policy Working Group mailing list.] Dear Colleagues, The new version of RIPE Policy Proposal 2008-08, "Initial Certification Policy for Provider Aggregatable Address Space Holders", was published on 9 February 2011. The time period for community review ends on 23 February 2011. Some feedback was sent to the Address Policy Working Group mailing list. However, to maintain the discussion, we strongly recommend that you share your ideas and comments and clearly let the community know if you: - Support the implementation of the proposal - Support the general principle of the proposal but would prefer another wording - Support the general principle with some details changed but agree to postpone this discussion until another stage of the policy proposal review. (This is an initial proposal that covers only PA resources. If the community supports extending certification to all resources, then another version of the proposal will be necessary.) - Do not support the proposal (please explain your motivations) 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 Please send an email with your comments to address-policy-wg at ripe.net by 23 February 2011. Best regards, Emilio Madaio From dr at cluenet.de Tue Feb 15 08:48:13 2011 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 15 Feb 2011 08:48:13 +0100 Subject: [address-policy-wg] Re: IPv6 PI resource question! In-Reply-To: References: <8F621F87-82DF-45AB-B363-FF761A3FD61C@steffann.nl> Message-ID: <20110215074813.GA334@srv03.cluenet.de> On Mon, Feb 14, 2011 at 03:50:39PM +0100, JORDI PALET MARTINEZ wrote: > So ... should we propose to remove the multihoming barrier ? > > What is the feeling of the list members ? +1 On one side, RIPE advocates "we don't care about routing" (IPv4 PI prefix size, see stalled proposal 2006-05 to fix that), on the other side RIPE requests routing policy (multihoming for IPv6 PI). This is arguing with split tongue. You can't have it both ways. IP address space is not only for use on "the Internet". It's also for private networks or hybrid networks (extranets etc.). Requiring "Internet" multihoming is an artificial limitation not really justified when claiming the role of sole owner of IP addresses in a region. So yes, get rid of the multihoming requirement. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From ysimeonov at neterra.net Tue Feb 15 09:22:49 2011 From: ysimeonov at neterra.net (Yasen Simeonov(Neterra NMT)) Date: Tue, 15 Feb 2011 10:22:49 +0200 Subject: [address-policy-wg] IPv6 PI resource question! In-Reply-To: <8F621F87-82DF-45AB-B363-FF761A3FD61C@steffann.nl> References: <4D59001C.7080306@neterra.net> <2D61CF3D-0859-4A27-A49A-371E75325BBB@steffann.nl> <4D592739.2050004@neterra.net> <8F621F87-82DF-45AB-B363-FF761A3FD61C@steffann.nl> Message-ID: <4D5A37D9.8000303@neterra.net> Hi Sander, I think it is wrong to not allow an ISP to be independent of it's providers. There are regions with ISPs that have very few customers, and I think this policy discriminates against them. Why every other company can have PI, but ISPs can't? Let them be able to receive independent resources without making sub-allocation. I'm sure that IPV6 routing table will explode and PI certainly will not be the reason. If you do not give smaller ISPs PI they have to use sub-allocation of any LIR, and because most ISPs are multihomed they will announce their sub-allocation to another provider, the LIR's addresses will be split and that will be the impact over the routing table. On 14/02/2011 16:44, Sander Steffann wrote: > An ISP can still get PI addresses. You just can't delegate addresses from PI space to customers. You need PA space for that. If so then the problem is solved, the ISP will not delegate addresses to the customers. He will give them one address with which they will connect to the ISPs network, but he will not allocate it to them. Best regards, Yasen -- Yasen Simeonov Network Management Team Neterra Ltd. Sofia, Bulgaria Phone: +359 2 974 33 11 Fax: +359 2 975 34 36 Mobile: +359 887 477 540 http://www.neterra.net From sander at steffann.nl Tue Feb 15 09:38:28 2011 From: sander at steffann.nl (Sander Steffann) Date: Tue, 15 Feb 2011 09:38:28 +0100 Subject: [address-policy-wg] IPv6 PI resource question! In-Reply-To: <4D5A37D9.8000303@neterra.net> References: <4D59001C.7080306@neterra.net> <2D61CF3D-0859-4A27-A49A-371E75325BBB@steffann.nl> <4D592739.2050004@neterra.net> <8F621F87-82DF-45AB-B363-FF761A3FD61C@steffann.nl> <4D5A37D9.8000303@neterra.net> Message-ID: Hi, > I think it is wrong to not allow an ISP to be independent of it's providers. > There are regions with ISPs that have very few customers, and I think this policy discriminates against them. > Why every other company can have PI, but ISPs can't? An ISP can get PI spac, but only for their own networks, not for customers. > Let them be able to receive independent resources without making sub-allocation. This is possible. > >> An ISP can still get PI addresses. You just can't delegate addresses from PI space to customers. You need PA space for that. > If so then the problem is solved, the ISP will not delegate addresses to the customers. > He will give them one address with which they will connect to the ISPs network, but he will not allocate it to them. That's not how IPv6 works... And the IPv6 policy does not have the 'point to point links to customers are considered your own infrastructure' rule, so tjis would not be according to polcy anyway. - Sander From lutz at iks-jena.de Tue Feb 15 09:52:54 2011 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Tue, 15 Feb 2011 08:52:54 +0000 (UTC) Subject: [address-policy-wg] IPv6 PI resource question! References: <4D5A37D9.8000303@neterra.net> Message-ID: * Yasen Simeonov(Neterra NMT) wrote: > Why every other company can have PI, but ISPs can't? Because ISPs should use PA (as LIR). It's their job to hand out addresses to their customers. From shane at time-travellers.org Tue Feb 15 10:14:41 2011 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 15 Feb 2011 10:14:41 +0100 Subject: [address-policy-wg] Re: IPv6 PI resource question! In-Reply-To: <20110215074813.GA334@srv03.cluenet.de> References: <8F621F87-82DF-45AB-B363-FF761A3FD61C@steffann.nl> <20110215074813.GA334@srv03.cluenet.de> Message-ID: <1297761281.4268.21.camel@shane-desktop> Daniel, On Tue, 2011-02-15 at 08:48 +0100, Daniel Roesen wrote: > On Mon, Feb 14, 2011 at 03:50:39PM +0100, JORDI PALET MARTINEZ wrote: > > So ... should we propose to remove the multihoming barrier ? > > > > What is the feeling of the list members ? > > +1 > > On one side, RIPE advocates "we don't care about routing" (IPv4 PI > prefix size, see stalled proposal 2006-05 to fix that), on the other > side RIPE requests routing policy (multihoming for IPv6 PI). This > is arguing with split tongue. You can't have it both ways. > > IP address space is not only for use on "the Internet". It's also for > private networks or hybrid networks (extranets etc.). Requiring > "Internet" multihoming is an artificial limitation not really justified > when claiming the role of sole owner of IP addresses in a region. > > So yes, get rid of the multihoming requirement. Speaking only from the IPv6 side, there are several options if you only need IPv6 space for internal reasons: * ULA addresses, with random addresses * 6to4 addresses, using one or more of your IPv4 addresses Perhaps someday we'll see ULA with a central registry too (that is in itself a long-going, bikeshed discussion that makes me very sleepy). http://en.wikipedia.org/wiki/Unique_local_address -- Shane From dr at cluenet.de Tue Feb 15 10:47:27 2011 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 15 Feb 2011 10:47:27 +0100 Subject: [address-policy-wg] Re: Re: IPv6 PI resource question! In-Reply-To: <1297761281.4268.21.camel@shane-desktop> References: <8F621F87-82DF-45AB-B363-FF761A3FD61C@steffann.nl> <20110215074813.GA334@srv03.cluenet.de> <1297761281.4268.21.camel@shane-desktop> Message-ID: <20110215094727.GA8717@srv03.cluenet.de> On Tue, Feb 15, 2011 at 10:14:41AM +0100, Shane Kerr wrote: > * ULA addresses, with random addresses Doesn't work for hybrids unless NAT is used for the (potentially single-homed) Internet connection. Didn't we want to avoid NAT? > * 6to4 addresses, using one or more of your IPv4 addresses "What IPv4 addresses?" :-) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From michiel at klaver.it Tue Feb 15 10:48:25 2011 From: michiel at klaver.it (Michiel Klaver) Date: Tue, 15 Feb 2011 10:48:25 +0100 Subject: [address-policy-wg] IPv6 PI resource question! In-Reply-To: References: <4D5A37D9.8000303@neterra.net> Message-ID: <4D5A4BE9.1030301@klaver.it> At 15-02-2011 09:52, Lutz Donnerhacke wrote: > * Yasen Simeonov(Neterra NMT) wrote: >> Why every other company can have PI, but ISPs can't? > > Because ISPs should use PA (as LIR). It's their job to hand out addresses to > their customers. > Isn't this supposed to be a market of current LIRs to act as a local registry agent and hand out (renting) smaller blocks (/48 for example) of their own PA space to anyone who is willing to use and route it? A LIR does not have to be an ISP, and vice-versa. It just happens most companies are both for the ease of administration. A LIR is nothing more than an administration office and has to act according to RIPE policies when assigning address space to their customers and keep the RIPE whois database up-to-date. As small ISP you can contact any LIR for registry services and receive parts of their PA space if they agree. https://www.ripe.net/membership/indices/ From elmi at 4ever.de Tue Feb 15 10:16:08 2011 From: elmi at 4ever.de (Elmar K. Bins) Date: Tue, 15 Feb 2011 10:16:08 +0100 Subject: [address-policy-wg] IPv6 PI resource question! In-Reply-To: References: <4D5A37D9.8000303@neterra.net> Message-ID: <20110215091608.GB8632@detebe.org> lutz at iks-jena.de (Lutz Donnerhacke) wrote: > * Yasen Simeonov(Neterra NMT) wrote: > > Why every other company can have PI, but ISPs can't? > > Because ISPs should use PA (as LIR). It's their job to hand out addresses to > their customers. Lutz, nothing against terse answers, especially towards people who are not really explaining and/or addressing the problems at hand, but: ISPs can certainly receive PI space if they can justify the need. Usually ISPs get PI space for a specific customer, working as a handling agent, but in certain special cases, PI space gets issued to ISPs directly. The point in this discussion is that Yasen either does not or does not want to understand the actual issue... Elmar. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: Digital signature URL: From alexb at ripe.net Tue Feb 15 11:05:07 2011 From: alexb at ripe.net (Alex Band) Date: Tue, 15 Feb 2011 11:05:07 +0100 Subject: [address-policy-wg] Re: [policy-announce] 2008-08 New Version and Draft Document Published (Initial Certification Policy for Provider Aggregatable Address Space Holders) In-Reply-To: References: <20110209140036.9C4BB6A002@postboy.ripe.net> Message-ID: On 12 Feb 2011, at 00:46, Leo Vegoda wrote: >> > It would be useful if you could hyperlink from the draft policy document to the CPS and/or include the URL for the CPS in the body of the text. That sounds like a a good idea. > Incidentally, is the CPS considered an integral part of the policy? Section 5. The CPS is a practice statement that works within the boundaries of the Certification policy, but is not subject to the PDP. It merely describes how we implement the policy, i.e. what the RIPE NCC does operationally. Please see section "1.5.4. CPS approval procedures" of the CPS for details. We do, of course, value feedback on the CPS. > 4. > 4 implies that the CPS is likely to be updated in the future. If so, what kind of review will this WG be asked to do before a new CPS comes into effect? Also, what notice period is given before updating the CPS? We don't have any strict notice period set for changes to the CPS. -Alex Band -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 1728 bytes Desc: not available URL: From shane at time-travellers.org Tue Feb 15 13:01:15 2011 From: shane at time-travellers.org (Shane Kerr) Date: Tue, 15 Feb 2011 13:01:15 +0100 Subject: [address-policy-wg] Re: Re: IPv6 PI resource question! In-Reply-To: <20110215094727.GA8717@srv03.cluenet.de> References: <8F621F87-82DF-45AB-B363-FF761A3FD61C@steffann.nl> <20110215074813.GA334@srv03.cluenet.de> <1297761281.4268.21.camel@shane-desktop> <20110215094727.GA8717@srv03.cluenet.de> Message-ID: <1297771275.4268.34.camel@shane-desktop> Daniel, On Tue, 2011-02-15 at 10:47 +0100, Daniel Roesen wrote: > On Tue, Feb 15, 2011 at 10:14:41AM +0100, Shane Kerr wrote: > > * ULA addresses, with random addresses > > Doesn't work for hybrids unless NAT is used for the (potentially > single-homed) Internet connection. Didn't we want to avoid NAT? I'm not sure what you mean by "hybrid". Can you explain or give a reference to what you mean? If you mean a site that needs both internal-only and externally-visible addresses, then with IPv6 I think the simple answer is to use ULA for the internal addresses, and PA space for the external addresses. All IPv6 devices can handle multiple addresses. > > * 6to4 addresses, using one or more of your IPv4 addresses > > "What IPv4 addresses?" :-) Funny, but you only need a /32 for most purposes here, since each IPv4 /32 becomes a /48 under 2002::/16. It's not for everyone, but if you have even a single IPv4 address you can use this for your internal network numbering. Unless you need more than a /48, in which case are you sure you don't want to multihome? :-P -- Shane From andrea at ripe.net Tue Feb 15 13:38:56 2011 From: andrea at ripe.net (Andrea Cima) Date: Tue, 15 Feb 2011 13:38:56 +0100 Subject: [address-policy-wg] Re: New IPv4 block allocated to RIPE NCC In-Reply-To: <4D5961A6.6030201@cymru.com> References: <4D4FBBDA.8040704@ripe.net> <4D5961A6.6030201@cymru.com> Message-ID: <4D5A73E0.8020804@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Tim, The file you mention contains all IP ranges allocated and assigned by the RIPE NCC. IP ranges from the new /8(s) will only appear in this list once the RIPE NCC starts using it for allocations (and, if applicable, for assignments). A complete list of allocated and available resources, including the new /8(s) are listed here: http://labs.ripe.net/Members/mirjam/new-ripe-ncc-address-statistics-reports and specifically in: http://albatross.ripe.net/delegated-extended/delegated-ripencc-extended-latest.bz2 I hope this helps. Best regards, Andrea Cima RIPE NCC Tim Wilde wrote: > Greetings Andrea & Team, > > Are there any plans for these allocations to show up in the > authoritative delegated-ripencc-latest file at > ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-latest ? We use > this file as the basis for our fullbogon efforts, which list all blocks > that have not yet been allocated by RIRs, and as best as I can tell, > these debogon blocks do not exist there, even though they are in the > RIPE WHOIS. It would be ideal if this type of allocation could be > included in the delegated file as well so we do not have to manually > maintain exceptions, and so that users of our fullbogons feed can > properly hit your debogon addresses. > > Best regards, > Tim Wilde > > On 2/7/2011 4:31 AM, Andrea Cima wrote: >> [Apologies for duplicate mails] > >> Dear Colleagues, > >> The RIPE NCC has received the IPv4 address range 185/8 from the IANA. > >> This is the final allocation of IPv4 address space that the RIPE NCC >> will receive from the IANA as stated in ripe-436, "Global Policy for the >> Allocation of the Remaining IPv4 Address Space". > >> The minimum allocation size for this /8 has been set at /22. > >> You may wish to adjust any filters you have in place accordingly. > >> More information on the IP address space administered by the RIPE NCC >> can be found on our website at: > >> https://www.ripe.net/ripe/docs/ripe-ncc-managed-address-space.html > >> Additionally, please note that three "pilot" prefixes will be announced >> from this /8. The prefixes are: > >> 185.0.0.0/16 >> 185.1.0.0/21 >> 185.1.24.0/24 > >> They all originate in AS12654. > >> The pingable addresses will be: > >> 185.0.0.1 >> 185.1.0.1 >> 185.1.24.1 > >> More information on this activity is available in the document >> "De-Bogonising New Address Blocks", which can be found at: > >> http://www.ripe.net/ripe/docs/ripe-351.html > > >> Kind regards, > >> Andrea Cima >> Registration Services Manager >> RIPE NCC > > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAk1ac+AACgkQXOgsmPkFrjOH/ACdHXnEyaGljIchFgSETyzL0Zwl bSMAoJYi0IV+UhPCvcu4rtpQB2jc4SbE =qLdL -----END PGP SIGNATURE----- From matoa-ml at vayu.net Tue Feb 15 17:41:50 2011 From: matoa-ml at vayu.net (Mathieu Paonessa) Date: Tue, 15 Feb 2011 17:41:50 +0100 Subject: [address-policy-wg] IPv6 PI resource question - Not for ISP but hosting Message-ID: <4D5AACCE.2030402@vayu.net> Hi All, I've been following the previous thread concerning IPv6 PI assignment but I'm running into a special case and need your input. As a LIR, I did send an IPv6 PI request for one of our customers few days ago and the hostmaster did point me to this previous thread saying that we are in the same case and that he may reject this request. The company requesting the IPv6 PI is a hosting company providing software as a service solution for its customers. All the infrastructure (servers, routers...) is owned by them. For security reasons, they chose to isolate each of their customers on a separate VLAN. Their customer don't have administrative access to the servers and just uses the software hosted on them for their CRM, extranet or other corporate applications. Would you consider this to be the exact same case as an ISP assigning an IP to a customer's CPE? I really don't see the point for such a company to become a LIR as they will only use those IPs for them. They also don't need more than a /48 as they are currently having about 50 customers. Regards, Mathieu Paonessa From sander at steffann.nl Tue Feb 15 18:04:29 2011 From: sander at steffann.nl (Sander Steffann) Date: Tue, 15 Feb 2011 18:04:29 +0100 Subject: [address-policy-wg] IPv6 PI resource question - Not for ISP but hosting In-Reply-To: <4D5AACCE.2030402@vayu.net> References: <4D5AACCE.2030402@vayu.net> Message-ID: <5A3E23FB-3C48-473F-B840-617AB360F202@steffann.nl> Hi, > The company requesting the IPv6 PI is a hosting company providing > software as a service solution for its customers. All the infrastructure > (servers, routers...) is owned by them. For security reasons, they chose > to isolate each of their customers on a separate VLAN. Their customer > don't have administrative access to the servers and just uses the > software hosted on them for their CRM, extranet or other corporate > applications. > > Would you consider this to be the exact same case as an ISP assigning an > IP to a customer's CPE? No. This all sounds like their own infrastructure/network/equipment. That they run software for customers, and that they choose a certain numbering plan shouldn't make a difference here. When they provide network services to their customer it starts to become more complicated, but this doesn't sound like a problem for IPv6 PI space to me. (based on the given information of course. I'm not trying to tell an IPRA what to do... They might have based their evaluation on different information) But the way you describe it it does not sound like they assign address space to other organizations. It sounds like they assign address space to parts of their own server farm. But this is my personal interpretation of the current policy. If someone disagrees with this, please speak up! Sander From Woeber at CC.UniVie.ac.at Tue Feb 15 19:01:57 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 15 Feb 2011 18:01:57 +0000 Subject: [address-policy-wg] 2008-08 New Version and Draft Document Published (Initial Certification Policy for Provider Aggregatable Address Space Holders) In-Reply-To: <20110209141312.GD44800@Space.Net> References: <20110209140036.9C4BB6A002@postboy.ripe.net> <20110209141312.GD44800@Space.Net> Message-ID: <4D5ABF95.7070209@CC.UniVie.ac.at> Hi Gert, AP-WG Gert Doering wrote: > Dear Working Group, > > as you might have noticed, this proposal is nicknamed "the icelandic > saga" because it goes on and on and on and on... > > We'd really like to bring this to conclusion, and for that, we need > *feedback from the community*. So please let us know: > > - this is what you want to see implemented in principle, yes > - you're in favour of the general principle, but this specific wording > is not what you want exactly, in particular I am pretty unhappy to be asked to agree to a policy, because the NCC is - at the moment - feeling like having no policy mandate. But, at the same time, some quite important stuff is left to the CPS. My feeling is that that doesn't match. [...] I have sumbitted some suggestions and questions after the Rome meeting, based on the discussions there, (please see attachement) which do not seem to be reflected in the new version or being taken into account in the text. > thanks, > > Gert Doering > APWG chair So, to sum it up, I do not oppose the idea or the proposal, but I think it is not good enough yet to become policy. If we can't do better, I'd prefer to continue on the basis of the provisional(?) CPS for now. Best regards, Wilfried. -------------- next part -------------- An embedded message was scrubbed... From: "Wilfried Woeber, UniVie/ACOnet" Subject: Re: 2008-08 - Certificates [was: Re: Unique prefixes for all proposals] Date: Thu, 25 Nov 2010 21:36:05 +0000 Size: 11557 URL: From Jasper.Jans at espritxb.nl Tue Feb 15 20:13:58 2011 From: Jasper.Jans at espritxb.nl (Jasper Jans) Date: Tue, 15 Feb 2011 20:13:58 +0100 Subject: [address-policy-wg] IPv6 PI resource question - Not for ISP but hosting In-Reply-To: <5A3E23FB-3C48-473F-B840-617AB360F202@steffann.nl> References: <4D5AACCE.2030402@vayu.net>,<5A3E23FB-3C48-473F-B840-617AB360F202@steffann.nl> Message-ID: <55557D0EBE9495428BFE94EF8BC5EBD20101CE510CE4@EXCH01.campus.local> Sander, I agree with you on the interpretation. We are facing a similar situation where our customer is in the security business. They host several hundred alarm receivers currently on ipv4 pi space. This is all their own infrastructure and the reason for pi space is the requirement for global unique addressing on the alarm receivers since they are connected to both the Internet and many vpns. Being provider independent brings them the ability to dual home in the future without renumbering as well as switch ISP all together. However since they do not dual home at the moment under the current policy they cannot get ipv6 pi space. Pa space is not an option since over 120000 alarm senders deployed at their end customers nationally would have to be reprogrammed in case of a change in connectivity. Would you agree with me that in this scenario the use of pi space is warranted yet strictly speaking not allowed under the current policy? Jasper ________________________________________ From: address-policy-wg-admin at ripe.net [address-policy-wg-admin at ripe.net] On Behalf Of Sander Steffann [sander at steffann.nl] Sent: Tuesday, February 15, 2011 6:04 PM To: Mathieu Paonessa Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] IPv6 PI resource question - Not for ISP but hosting Hi, > The company requesting the IPv6 PI is a hosting company providing > software as a service solution for its customers. All the infrastructure > (servers, routers...) is owned by them. For security reasons, they chose > to isolate each of their customers on a separate VLAN. Their customer > don't have administrative access to the servers and just uses the > software hosted on them for their CRM, extranet or other corporate > applications. > > Would you consider this to be the exact same case as an ISP assigning an > IP to a customer's CPE? No. This all sounds like their own infrastructure/network/equipment. That they run software for customers, and that they choose a certain numbering plan shouldn't make a difference here. When they provide network services to their customer it starts to become more complicated, but this doesn't sound like a problem for IPv6 PI space to me. (based on the given information of course. I'm not trying to tell an IPRA what to do... They might have based their evaluation on different information) But the way you describe it it does not sound like they assign address space to other organizations. It sounds like they assign address space to parts of their own server farm. But this is my personal interpretation of the current policy. If someone disagrees with this, please speak up! Sander Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer From sander at steffann.nl Tue Feb 15 20:34:47 2011 From: sander at steffann.nl (Sander Steffann) Date: Tue, 15 Feb 2011 20:34:47 +0100 Subject: [address-policy-wg] IPv6 PI resource question - Not for ISP but hosting In-Reply-To: <55557D0EBE9495428BFE94EF8BC5EBD20101CE510CE4@EXCH01.campus.local> References: <4D5AACCE.2030402@vayu.net> <5A3E23FB-3C48-473F-B840-617AB360F202@steffann.nl> <55557D0EBE9495428BFE94EF8BC5EBD20101CE510CE4@EXCH01.campus.local> Message-ID: Hi, > Would you agree with me that in this scenario the use of pi space is warranted yet strictly speaking not allowed under the current policy? I don't know if this is a waranted use of PI space. The problem here is that the extra route has a global cost for everyone. This would not be neccesary if you make sure that you can easilly renumber in the future. Playing devil's advocate: why should everyone pay so that you don't have to invest in better device management? So I do understand your problem, but I don't know what the best sollution is... Sander From dr at cluenet.de Tue Feb 15 20:41:29 2011 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 15 Feb 2011 20:41:29 +0100 Subject: [address-policy-wg] Re: Re: Re: IPv6 PI resource question! In-Reply-To: <1297771275.4268.34.camel@shane-desktop> References: <8F621F87-82DF-45AB-B363-FF761A3FD61C@steffann.nl> <20110215074813.GA334@srv03.cluenet.de> <1297761281.4268.21.camel@shane-desktop> <20110215094727.GA8717@srv03.cluenet.de> <1297771275.4268.34.camel@shane-desktop> Message-ID: <20110215194129.GA13990@srv03.cluenet.de> Hi, On Tue, Feb 15, 2011 at 01:01:15PM +0100, Shane Kerr wrote: > I'm not sure what you mean by "hybrid". Can you explain or give a > reference to what you mean? Networks connected to both Internet and in Extranet fashion privately with other networks. > If you mean a site that needs both internal-only and externally-visible > addresses, then with IPv6 I think the simple answer is to use ULA for > the internal addresses, and PA space for the external addresses. So also need to run split DNS for services accessible via Internet and via private Extranets. That's signficant operational burden and fails for anything which needs literal stable addresses to connect to (like e.g. sensors). > All IPv6 devices can handle multiple addresses. Just like every IPv6 stack implements IPSEC, right? We're allowing PIv6 for "multihomed" (whatever that means really) sites. Those could "just simply" use PA space from any ISP they connect to. Why do we make Internet multihoming special compared to Internet-plus-others? With the "multiple IPs per device" argument there cannot be PIv6. I thought we've left that behind by now. > > > * 6to4 addresses, using one or more of your IPv4 addresses > > > > "What IPv4 addresses?" :-) > > Funny, but you only need a /32 for most purposes here, since each > IPv4 /32 becomes a /48 under 2002::/16. It's not for everyone, but if > you have even a single IPv4 address you can use this for your internal > network numbering. Unless you need more than a /48, in which case are > you sure you don't want to multihome? :-P 6to4 is special address space and considered "lucky if it works". You certainly didn't want to really propose using a 2002::/16 6to4 scheme derrived /48 as "stable addressing" for internal use?!? Did you consider that folks WILL use 6to4 anycast to reach such addresses? Cannot be meant serious?! Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From matoa-ml at vayu.net Tue Feb 15 20:58:54 2011 From: matoa-ml at vayu.net (Mathieu Paonessa) Date: Tue, 15 Feb 2011 20:58:54 +0100 Subject: [address-policy-wg] IPv6 PI resource question - Not for ISP but hosting In-Reply-To: <55557D0EBE9495428BFE94EF8BC5EBD20101CE510CE4@EXCH01.campus.local> References: <4D5AACCE.2030402@vayu.net>,<5A3E23FB-3C48-473F-B840-617AB360F202@steffann.nl> <55557D0EBE9495428BFE94EF8BC5EBD20101CE510CE4@EXCH01.campus.local> Message-ID: <4D5ADAFE.8060505@vayu.net> Hi jasper, > I agree with you on the interpretation. We are facing a similar situation where our customer is in the security business. They host several hundred alarm receivers currently on ipv4 pi space. This is all their own infrastructure and the reason for pi space is the requirement for global unique addressing on the alarm receivers since they are connected to both the Internet and many vpns. Being provider independent brings them the ability to dual home in the future without renumbering as well as switch ISP all together. However since they do not dual home at the moment under the current policy they cannot get ipv6 pi space. Pa space is not an option since over 120000 alarm senders deployed at their end customers nationally would have to be reprogrammed in case of a change in connectivity. > > Would you agree with me that in this scenario the use of pi space is warranted yet strictly speaking not allowed under the current policy? Your case is not really like ours. Even if for your customer it would make sense to have IPv6 PI space (IMHO), the current policy doesn't allow it since he is not currently multihomed. It's up to this working group to make it evolve or not. In our case, the customer is already multihomed on his IPv4 space and they will also be dual homed for their IPv6 space. It's just a question of interpretation of who is the ultimate owner of the IPs. Regards, Mathieu From dr at cluenet.de Tue Feb 15 21:04:42 2011 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 15 Feb 2011 21:04:42 +0100 Subject: [address-policy-wg] Re: IPv6 PI resource question - Not for ISP but hosting In-Reply-To: References: <4D5AACCE.2030402@vayu.net> <5A3E23FB-3C48-473F-B840-617AB360F202@steffann.nl> <55557D0EBE9495428BFE94EF8BC5EBD20101CE510CE4@EXCH01.campus.local> Message-ID: <20110215200442.GB13990@srv03.cluenet.de> On Tue, Feb 15, 2011 at 08:34:47PM +0100, Sander Steffann wrote: > The problem here is that the extra route has a global cost for everyone. Just as every LIR PA block is at the global cost of everyone. But of course, LIRs are "special" so that cost isn't questioned as long as they pay their share to run the RIRs - /32, no questions asked (single homed? no problem. polluting the DFZ with a lot of deaggs - hey, not a biggie - connecting customers? sure, just throw them a /48). It's just those pesky customers who insubordinately ask for their independence and operational sanity just like the LIRs enjoy every day. We should really search for more artificial reasons to deny them PI space. We could e.g. ask for especially expensive routers deployed (and certificate of first ownership incl. invoice!) - that will make them shy away even more! Or we could ask for certified BGP engineers, just to save the DFZ from more deaggregate pollution. At least they shelled out money to buy themselves "in". No surprised that non-LIRs are so much underrepresented in RIR policy processes. It's basically a hopeless position to take. SCNR, Daniel (having a bad day, tired of all the hypocrisy in that PI debate) -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From sander at steffann.nl Tue Feb 15 21:42:04 2011 From: sander at steffann.nl (Sander Steffann) Date: Tue, 15 Feb 2011 21:42:04 +0100 Subject: [address-policy-wg] Re: IPv6 PI resource question - Not for ISP but hosting In-Reply-To: <20110215200442.GB13990@srv03.cluenet.de> References: <4D5AACCE.2030402@vayu.net> <5A3E23FB-3C48-473F-B840-617AB360F202@steffann.nl> <55557D0EBE9495428BFE94EF8BC5EBD20101CE510CE4@EXCH01.campus.local> <20110215200442.GB13990@srv03.cluenet.de> Message-ID: <509765A8-2AE2-4AB9-8020-A045AC3A2D01@steffann.nl> >> The problem here is that the extra route has a global cost for everyone. > > Just as every LIR PA block is at the global cost of everyone. Correct. The idea is that one LIR PA block covers lots of customers. It's a matter of scalability... I would love to give every organization it's own block of addresses. If someone finds a way to make that scale please let us know. > No surprised that non-LIRs are so much underrepresented in RIR policy processes. It's basically a hopeless position to take. It certainly is not. A few years ago the was no IPv6 PI policy, and now we have one. It's not perfect, but it provides addresses for those that need them for multi-homing. At that point in time that was seen as the only valid reason for IPv6 PI. In this whole discussion about PI space I have seen several other reasons why people want PI space: - They already provide access services with IPv4 PI space According to the current policy they should become an LIR and get PA space. When we last discussed this here the conclusion was that this was intentional. The cost for setting up an LIR seem to be a problem for some here. - They want to avoid renumbering Preventing possible renumbering in the future has (until now at least) not been seen as a good enough reason to get PI addresses. IPv6 does make renumbering already a bit easier than it was with IPv6, and I really hope that more effort will be put into making it even easier. If we (=working group) decide that there should be IPv6 PI for these or other purposes, let's discuss that. This is a working group. If you want to see something changed: write a proposal and it will be discussed! Thanks, Sander From sander at steffann.nl Tue Feb 15 21:49:15 2011 From: sander at steffann.nl (Sander Steffann) Date: Tue, 15 Feb 2011 21:49:15 +0100 Subject: [address-policy-wg] Re: IPv6 PI resource question - Not for ISP but hosting In-Reply-To: References: <4D5AACCE.2030402@vayu.net> <5A3E23FB-3C48-473F-B840-617AB360F202@steffann.nl> <55557D0EBE9495428BFE94EF8BC5EBD20101CE510CE4@EXCH01.campus.local> <20110215200442.GB13990@srv03.cluenet.de> <509765A8-2AE2-4AB9-8020-A045AC3A2D01@steffann.nl> Message-ID: >> Correct. The idea is that one LIR PA block covers lots of customers. It's a matter of scalability... I would love to give every organization it's own block of addresses. If someone finds a way to make that scale please let us know. > > FWIW, LISP is attempting to do just that. I know. I *really* hope it will work and be accepted as a solution. I would love a situation where we don't have to worry about the future routing table size!!! Thanks, Sander From dr at cluenet.de Tue Feb 15 22:31:47 2011 From: dr at cluenet.de (Daniel Roesen) Date: Tue, 15 Feb 2011 22:31:47 +0100 Subject: [address-policy-wg] Re: Re: IPv6 PI resource question - Not for ISP but hosting In-Reply-To: <509765A8-2AE2-4AB9-8020-A045AC3A2D01@steffann.nl> References: <4D5AACCE.2030402@vayu.net> <5A3E23FB-3C48-473F-B840-617AB360F202@steffann.nl> <55557D0EBE9495428BFE94EF8BC5EBD20101CE510CE4@EXCH01.campus.local> <20110215200442.GB13990@srv03.cluenet.de> <509765A8-2AE2-4AB9-8020-A045AC3A2D01@steffann.nl> Message-ID: <20110215213147.GA22524@srv03.cluenet.de> On Tue, Feb 15, 2011 at 09:42:04PM +0100, Sander Steffann wrote: > >> The problem here is that the extra route has a global cost for everyone. > > > > Just as every LIR PA block is at the global cost of everyone. > > Correct. The idea is that one LIR PA block covers lots of customers. > It's a matter of scalability... An "enterprise" becoming LIR to get their /32-no-questions-asked as effective PI doesn't aggregate any customers as well. With that argument, you have to avoid non-ISPs becoming LIRs as well. > > No surprised that non-LIRs are so much underrepresented in RIR policy processes. It's basically a hopeless position to take. > > It certainly is not. A few years ago the was no IPv6 PI policy, and > now we have one. Yes, but why? Not to do customers a favour, but the LIRs realized that IPv6 migration won't really happen unless they give the relevant content players PI for their operations. Which induces a lot of operational headache and cost primarily on the ISP side. "Enterprises" are already used to NATting their day away - ISPs not. What I see coming is that ULA + NAT will be vast IPv6 reality. Thanks that the IPv6 end-to-end promise is killed off again via restrictive policies made by ISPs for ISPs. > - They already provide access services with IPv4 PI space > According to the current policy they should become an LIR and get PA space. So just "make them pay a penalty". They are not aggregating customers, so no good reason for PA other than artificial hurdle. > If we (=working group) decide that there should be IPv6 PI for these or > other purposes, let's discuss that. This is a working group. A working group with almost zero lobby for non-LIRs. Don't start fights you cannot win. > If you want to see something changed: write a proposal and it will be > discussed! Yes, between folks who have zero business interest for such a proposal to pass. See above - a fight you cannot win. Non-LIRs aren't organized enough to have any effective influence on RIR policy development process. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From sander at steffann.nl Tue Feb 15 23:09:50 2011 From: sander at steffann.nl (Sander Steffann) Date: Tue, 15 Feb 2011 23:09:50 +0100 Subject: [address-policy-wg] Re: Re: IPv6 PI resource question - Not for ISP but hosting In-Reply-To: <20110215213147.GA22524@srv03.cluenet.de> References: <4D5AACCE.2030402@vayu.net> <5A3E23FB-3C48-473F-B840-617AB360F202@steffann.nl> <55557D0EBE9495428BFE94EF8BC5EBD20101CE510CE4@EXCH01.campus.local> <20110215200442.GB13990@srv03.cluenet.de> <509765A8-2AE2-4AB9-8020-A045AC3A2D01@steffann.nl> <20110215213147.GA22524@srv03.cluenet.de> Message-ID: <4E738178-F887-4316-96F9-59A54499D443@steffann.nl> > What I see coming is that ULA + NAT will be vast IPv6 reality. Thanks > that the IPv6 end-to-end promise is killed off again via restrictive > policies made by ISPs for ISPs. I'm sorry, but this working group is not restricted to ISPs. It's open for *everyone*. >> - They already provide access services with IPv4 PI space >> According to the current policy they should become an LIR and get PA space. > > So just "make them pay a penalty". They are not aggregating customers, > so no good reason for PA other than artificial hurdle. ??? This situation is _all_ about aggregating customers... >> If we (=working group) decide that there should be IPv6 PI for these or >> other purposes, let's discuss that. This is a working group. > > A working group with almost zero lobby for non-LIRs. Don't start fights > you cannot win. The is no lobby. There is no such thing here as 'a fight you cannot win'. The only reason that a proposal doesn't reach consensus is when not enough people care, or if there are good arguments against the proposal. Please get non-LIRs to participate here to form a workable solution. You seem to propose PI space as a solution, someone suggested LISP as a solution, let's see what is a workable solution for everybody involved. (Yes: everybody, both ISPs and Enterprises) >> If you want to see something changed: write a proposal and it will be >> discussed! > > Yes, between folks who have zero business interest for such a proposal > to pass. See above - a fight you cannot win. > > Non-LIRs aren't organized enough to have any effective influence on RIR > policy development process. Nobody here is 'organized'. Everybody speaks for him/herself here. This working group consists of people, not organizations... Sander From twilde at cymru.com Tue Feb 15 19:39:57 2011 From: twilde at cymru.com (Tim Wilde) Date: Tue, 15 Feb 2011 13:39:57 -0500 Subject: [address-policy-wg] Re: New IPv4 block allocated to RIPE NCC In-Reply-To: <4D5A73E0.8020804@ripe.net> References: <4D4FBBDA.8040704@ripe.net> <4D5961A6.6030201@cymru.com> <4D5A73E0.8020804@ripe.net> Message-ID: <4D5AC87D.9060603@cymru.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/15/2011 7:38 AM, Andrea Cima wrote: > The file you mention contains all IP ranges allocated and assigned by > the RIPE NCC. IP ranges from the new /8(s) will only appear in this list > once the RIPE NCC starts using it for allocations (and, if applicable, > for assignments). > > A complete list of allocated and available resources, including the new > /8(s) are listed here: > http://labs.ripe.net/Members/mirjam/new-ripe-ncc-address-statistics-reports > > and specifically in: > http://albatross.ripe.net/delegated-extended/delegated-ripencc-extended-latest.bz2 Andrea, Thank you for this pointer, this is indeed an interesting and helpful file. However, I note that it has the same problem as the traditional delegated prefixes file, ie, it lists the "debogon" prefixes listed in your announcement (185.0.0.0/16, 185.1.0.0/21, and 185.1.24.0/24) as available as part of an "available" listing for all of 185.0.0.0/10: ripencc||ipv4|185.0.0.0|4194304||available If we were to use this file, we would have the same problem that we have using the traditional delegated list; we would list your "debogon" prefixes as bogon, because, according to your records, they are available, ie unallocated/unassigned, ie bogon. Do you see the problem we're running into? From my perspective, the "debogon" prefixes should be considered allocated - it's an internal allocation, and a temporary one, but it's still an allocation. This is, in fact, how 185.0.0.0/17 is listed in the RIPE WHOIS database: % Information related to '185.0.0.0 - 185.1.255.255' inetnum: 185.0.0.0 - 185.1.255.255 netname: EU-ZZ-20100510 org: ORG-NCC1-RIPE descr: RIPE NCC Test Announce country: EU admin-c: HU266-RIPE tech-c: RISM-RIPE status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT mnt-by: RIPE-NCC-RIS-MNT source: RIPE # Filtered But this is not reflected in the delegated-latest file. Should it not be there (and in this new experimental file) as an allocation, since that's what WHOIS says it is? Best regards, Tim Wilde - -- Tim Wilde, Senior Software Engineer, Team Cymru, Inc. twilde at cymru.com | +1-630-230-5433 | http://www.team-cymru.org/ -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAk1ayH0ACgkQluRbRini9tg3KwCeNgN73SAWCcPaZvhgDq9Ak790 WXYAn0SgdxRNBPzDkMSNMGXpYlrfg/+W =pE2t -----END PGP SIGNATURE----- From matoa at vayu.net Tue Feb 15 20:45:16 2011 From: matoa at vayu.net (Mathieu Paonessa) Date: Tue, 15 Feb 2011 20:45:16 +0100 Subject: [address-policy-wg] IPv6 PI resource question - Not for ISP but hosting In-Reply-To: <55557D0EBE9495428BFE94EF8BC5EBD20101CE510CE4@EXCH01.campus.local> References: <4D5AACCE.2030402@vayu.net>,<5A3E23FB-3C48-473F-B840-617AB360F202@steffann.nl> <55557D0EBE9495428BFE94EF8BC5EBD20101CE510CE4@EXCH01.campus.local> Message-ID: <4D5AD7CC.5020305@vayu.net> Hi Jasper, > I agree with you on the interpretation. We are facing a similar situation where our customer is in the security business. They host several hundred alarm receivers currently on ipv4 pi space. This is all their own infrastructure and the reason for pi space is the requirement for global unique addressing on the alarm receivers since they are connected to both the Internet and many vpns. Being provider independent brings them the ability to dual home in the future without renumbering as well as switch ISP all together. However since they do not dual home at the moment under the current policy they cannot get ipv6 pi space. Pa space is not an option since over 120000 alarm senders deployed at their end customers nationally would have to be reprogrammed in case of a change in connectivity. > > Would you agree with me that in this scenario the use of pi space is warranted yet strictly speaking not allowed under the current policy? Your case is not really like ours. Even if for your customer it would make sense to have IPv6 PI space (IMHO), the current policy doesn't allow it since he is not currently multihomed. It's up to this working group to make it evolve or not. In our case, the customer is already multihomed on his IPv4 space and they will also be dual homed for their IPv6 space. It's just a question of interpretation of who is the ultimate owner of the IPs. Regards, Mathieu From fweimer at bfk.de Wed Feb 16 11:18:22 2011 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 16 Feb 2011 10:18:22 +0000 Subject: [address-policy-wg] IPv6 PI resource question - Not for ISP but hosting In-Reply-To: (Sander Steffann's message of "Tue\, 15 Feb 2011 20\:34\:47 +0100") References: <4D5AACCE.2030402@vayu.net> <5A3E23FB-3C48-473F-B840-617AB360F202@steffann.nl> <55557D0EBE9495428BFE94EF8BC5EBD20101CE510CE4@EXCH01.campus.local> Message-ID: <82y65g2sgh.fsf@mid.bfk.de> * Sander Steffann: > I don't know if this is a waranted use of PI space. The problem here > is that the extra route has a global cost for everyone. This is an extremely short-sighted viewpoint. More routing table entries enable finer-grained routing decisions. In many cases, this leads to improvements according to some cost metric. There are isolated inefficiencies, but you cannot remove them without decreasing overall performance. Isn't BGP UPDATE rate more of an issue than the table size these days, anyway? -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From sander at steffann.nl Wed Feb 16 11:24:03 2011 From: sander at steffann.nl (Sander Steffann) Date: Wed, 16 Feb 2011 11:24:03 +0100 Subject: [address-policy-wg] IPv6 PI resource question - Not for ISP but hosting In-Reply-To: <82y65g2sgh.fsf@mid.bfk.de> References: <4D5AACCE.2030402@vayu.net> <5A3E23FB-3C48-473F-B840-617AB360F202@steffann.nl> <55557D0EBE9495428BFE94EF8BC5EBD20101CE510CE4@EXCH01.campus.local> <82y65g2sgh.fsf@mid.bfk.de> Message-ID: Hi Florian, >> I don't know if this is a waranted use of PI space. The problem here >> is that the extra route has a global cost for everyone. > > This is an extremely short-sighted viewpoint. > > More routing table entries enable finer-grained routing decisions. In > many cases, this leads to improvements according to some cost metric. > There are isolated inefficiencies, but you cannot remove them without > decreasing overall performance. > > Isn't BGP UPDATE rate more of an issue than the table size these days, > anyway? If the people in the working group feel that routing table size is not as important anymore as it was a few years ago it might be possible to relax the policy about IPv6 PI space. It doesn't solve the problem that access providers that run on IPv4 PI space can't run on IPv6 PI space. These seem to be two separate issues. Thanks, Sander From fweimer at bfk.de Wed Feb 16 11:30:43 2011 From: fweimer at bfk.de (Florian Weimer) Date: Wed, 16 Feb 2011 10:30:43 +0000 Subject: [address-policy-wg] IPv6 PI resource question - Not for ISP but hosting In-Reply-To: (Sander Steffann's message of "Wed\, 16 Feb 2011 11\:24\:03 +0100") References: <4D5AACCE.2030402@vayu.net> <5A3E23FB-3C48-473F-B840-617AB360F202@steffann.nl> <55557D0EBE9495428BFE94EF8BC5EBD20101CE510CE4@EXCH01.campus.local> <82y65g2sgh.fsf@mid.bfk.de> Message-ID: <82oc6c2rvw.fsf@mid.bfk.de> * Sander Steffann: > If the people in the working group feel that routing table size is > not as important anymore as it was a few years ago it might be > possible to relax the policy about IPv6 PI space. As one data point, it is a total non-issue for the technology we use. We probably can't process an IPv6 routing table which carries as much information as the IPv4 routing table today, but we are ready to adopt. (We're certainly not representative, but you've got to start somewhere.) > It doesn't solve the problem that access providers that run on IPv4 > PI space can't run on IPv6 PI space. These seem to be two separate > issues. Not really. If LIRs could hand out independently routable /48 chunks of their PA space, then those folks wouldn't need PI space at all. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From Remco.vanMook at eu.equinix.com Wed Feb 16 11:43:42 2011 From: Remco.vanMook at eu.equinix.com (Remco Van Mook) Date: Wed, 16 Feb 2011 10:43:42 +0000 Subject: [address-policy-wg] IPv6 PI resource question - Not for ISP but hosting In-Reply-To: <82oc6c2rvw.fsf@mid.bfk.de> References: <4D5AACCE.2030402@vayu.net> <5A3E23FB-3C48-473F-B840-617AB360F202@steffann.nl> <55557D0EBE9495428BFE94EF8BC5EBD20101CE510CE4@EXCH01.campus.local> <82y65g2sgh.fsf@mid.bfk.de> <82oc6c2rvw.fsf@mid.bfk.de> Message-ID: Florian Weimer wrote: > > It doesn't solve the problem that access providers that run on IPv4 PI > > space can't run on IPv6 PI space. These seem to be two separate > > issues. > > Not really. If LIRs could hand out independently routable /48 chunks of their > PA space, then those folks wouldn't need PI space at all. So that hits the nail right on the head. We're trying to change address policy because we don't like accepted routing policy. This is what RFC1925 says about a construct like this: (6) It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it. So I'm not sure that's the right idea. If you don't like routing policy, change routing policy. (On a semi-related note, nobody likes paying money. If for some reason policy is adopted where some ISPs can get "low cost" address space for whatever reason, that means other people end up paying more for theirs. Previous experience learns us that more policy means executing policy gets more expensive. ) Remco, no hats. This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, 4 Thomas More Square, London E1W 1YW. Registered in England and Wales, No. 6293383. From shane at time-travellers.org Wed Feb 16 14:15:40 2011 From: shane at time-travellers.org (Shane Kerr) Date: Wed, 16 Feb 2011 14:15:40 +0100 Subject: [address-policy-wg] Re: Re: Re: IPv6 PI resource question! In-Reply-To: <20110215194129.GA13990@srv03.cluenet.de> References: <8F621F87-82DF-45AB-B363-FF761A3FD61C@steffann.nl> <20110215074813.GA334@srv03.cluenet.de> <1297761281.4268.21.camel@shane-desktop> <20110215094727.GA8717@srv03.cluenet.de> <1297771275.4268.34.camel@shane-desktop> <20110215194129.GA13990@srv03.cluenet.de> Message-ID: <1297862140.4268.68.camel@shane-desktop> Daniel, On Tue, 2011-02-15 at 20:41 +0100, Daniel Roesen wrote: > Hi, > > On Tue, Feb 15, 2011 at 01:01:15PM +0100, Shane Kerr wrote: > > I'm not sure what you mean by "hybrid". Can you explain or give a > > reference to what you mean? > > Networks connected to both Internet and in Extranet fashion privately > with other networks. Right. So peering with a vendor to gain access to certain services or databases while also connecting to the Internet, for example? > > If you mean a site that needs both internal-only and externally-visible > > addresses, then with IPv6 I think the simple answer is to use ULA for > > the internal addresses, and PA space for the external addresses. > > So also need to run split DNS for services accessible via Internet and > via private Extranets. That's signficant operational burden and fails > for anything which needs literal stable addresses to connect to (like > e.g. sensors). Why do you need a split DNS? Just publish your local information on the Internet. If your concern is with hiding information about internal networks for whatever reason (security, trade secrets, and so on), then you'll need some sort of split DNS anyway. > > All IPv6 devices can handle multiple addresses. > > Just like every IPv6 stack implements IPSEC, right? It's hardly the same. I have never seen an IPv6 deployment that actually used IPSEC. OTOH, every IPv6-enabled device that I have seen supports multiple addresses. Indeed, I cannot imagine how a device would work without this, since you typically need at least one link-local and one global address. > We're allowing PIv6 for "multihomed" (whatever that means really) sites. > Those could "just simply" use PA space from any ISP they connect to. Why > do we make Internet multihoming special compared to Internet-plus-others? > With the "multiple IPs per device" argument there cannot be PIv6. I > thought we've left that behind by now. I'll address this in a separate e-mail. (And I won't address the 6to4 suggestion, which you realize isn't entirely serious.) ;) -- Shane From shane at time-travellers.org Wed Feb 16 14:55:25 2011 From: shane at time-travellers.org (Shane Kerr) Date: Wed, 16 Feb 2011 14:55:25 +0100 Subject: [address-policy-wg] PI concept in general, was IPv6 PI resource question! In-Reply-To: <20110215194129.GA13990@srv03.cluenet.de> References: <8F621F87-82DF-45AB-B363-FF761A3FD61C@steffann.nl> <20110215074813.GA334@srv03.cluenet.de> <1297761281.4268.21.camel@shane-desktop> <20110215094727.GA8717@srv03.cluenet.de> <1297771275.4268.34.camel@shane-desktop> <20110215194129.GA13990@srv03.cluenet.de> Message-ID: <1297864525.4268.92.camel@shane-desktop> Daniel, On Tue, 2011-02-15 at 20:41 +0100, Daniel Roesen wrote: > We're allowing PIv6 for "multihomed" (whatever that means really) sites. > Those could "just simply" use PA space from any ISP they connect to. Why > do we make Internet multihoming special compared to Internet-plus-others? > With the "multiple IPs per device" argument there cannot be PIv6. I > thought we've left that behind by now. So I was wondering "why do we allow PI for IPv6 for multihoming?", and realized "that's how we do things in IPv4". AIUI people don't consider it reasonable to get one ISP to carry routes from another on behalf of their customers. Fair enough. ---- In this IPv6 PI discussion people say it is too expensive to be an LIR. This strikes me as weird... even cheap network gear costs way more than the LIR fee, and certainly the personnel costs are many times that, even in countries where technical folks are poorly paid. But anyway.... On the other side we hear the concerns about unchecked routing table growth. This has been addressed many times; it is usually presented as a basic "tragedy of the commons", where the costs of the increased size are borne by everyone but the benefits go to each network which advertises any given route. This position is directly refuted by Geoff Huston who claims that memory is cheap, what we really need to care about is update frequency, which is not actually closely related to the total number of routes today but is more related to a number of problematic AS (see chart at end): http://bgpupdates.potaroo.net/instability/bgpupd.html Further, in IPv6 we're much less likely to have multiple routes per organization (although of course as companies merge and diversify this won't be 100% true). Plus we have the advantage that as IPv4 gets more scarce, it is likely that the number of addresses per advertisement will get smaller, so the IPv6 will be able to use whatever technological means is used to keep IPv4 creaking along. So... it may be there is no routing reason to hold back on PI blocks. ---- Is there another reason to want to limit PI assignments? There may be. Certainly the folks over in abuse-land think we should have super strict controls over all addresses, and revoke them at the first hint of naughtiness. Or there may be administrative reasons - an entirely different kind of infrastructure is needed to manage hundreds of thousands of low-fee (well, NO fee now) PI-holders than thousands of high-fee LIRs. I don't know. So... do you think we should simply remove all restrictions for IPv6 PI and issue space if someone wants it, period? If not, what possible restriction would there be? ---- Finally, I think what bothers me about PI in general though is that once the initial assignment is made... that's it. At least with RIPE 452 we have *some* contractual relationship with the PI holder, but that's about it. I guess the "LIR middleman" model comes from the mists of time, long ago in history. It certainly reduces the burden on the RIPE NCC, but it never really struck me as sensible. After all, isn't the whole point of PI space that you don't want to have to depend on an LIR? -- Shane From dr at cluenet.de Wed Feb 16 16:24:48 2011 From: dr at cluenet.de (Daniel Roesen) Date: Wed, 16 Feb 2011 16:24:48 +0100 Subject: [address-policy-wg] Re: Re: Re: Re: IPv6 PI resource question! In-Reply-To: <1297862140.4268.68.camel@shane-desktop> References: <8F621F87-82DF-45AB-B363-FF761A3FD61C@steffann.nl> <20110215074813.GA334@srv03.cluenet.de> <1297761281.4268.21.camel@shane-desktop> <20110215094727.GA8717@srv03.cluenet.de> <1297771275.4268.34.camel@shane-desktop> <20110215194129.GA13990@srv03.cluenet.de> <1297862140.4268.68.camel@shane-desktop> Message-ID: <20110216152448.GA27513@srv03.cluenet.de> On Wed, Feb 16, 2011 at 02:15:40PM +0100, Shane Kerr wrote: > Right. So peering with a vendor to gain access to certain services or > databases while also connecting to the Internet, for example? Yep. > Why do you need a split DNS? Just publish your local information on the > Internet. ULA are not supposed to be Internet routable, so you would have to present globally routable PA space-de-jour AAAA to DNS requestors from "the Internet", and present stable ULA AAAA to others. > If your concern is with hiding information about internal networks for > whatever reason (security, trade secrets, and so on), then you'll need > some sort of split DNS anyway. No, that's not my (personal) concern in this debate for now. > (And I won't address the 6to4 suggestion, which you realize isn't > entirely serious.) ;) *phew* :-) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr at cluenet.de -- dr at IRCnet -- PGP: 0xA85C8AA0 From millnert at gmail.com Wed Feb 16 17:28:20 2011 From: millnert at gmail.com (Martin Millnert) Date: Wed, 16 Feb 2011 11:28:20 -0500 Subject: [address-policy-wg] PI concept in general, was IPv6 PI resource question! In-Reply-To: <1297864525.4268.92.camel@shane-desktop> References: <8F621F87-82DF-45AB-B363-FF761A3FD61C@steffann.nl> <20110215074813.GA334@srv03.cluenet.de> <1297761281.4268.21.camel@shane-desktop> <20110215094727.GA8717@srv03.cluenet.de> <1297771275.4268.34.camel@shane-desktop> <20110215194129.GA13990@srv03.cluenet.de> <1297864525.4268.92.camel@shane-desktop> Message-ID: Chipping in 1.5 cents, On Wed, Feb 16, 2011 at 8:55 AM, Shane Kerr wrote: > Daniel, > > On Tue, 2011-02-15 at 20:41 +0100, Daniel Roesen wrote: >> We're allowing PIv6 for "multihomed" (whatever that means really) sites. >> Those could "just simply" use PA space from any ISP they connect to. Why >> do we make Internet multihoming special compared to Internet-plus-others? >> With the "multiple IPs per device" argument there cannot be PIv6. I >> thought we've left that behind by now. > > So I was wondering "why do we allow PI for IPv6 for multihoming?", and > realized "that's how we do things in IPv4". AIUI people don't consider > it reasonable to get one ISP to carry routes from another on behalf of > their customers. Fair enough. Routing slots notwithstanding, the hurdles the RIPE community puts up for PIv6 is *directly* contra-productive to roll-out of IPv6 in general, and the "end-to-end"-roll-out specifically. In the absence of a solution to the renumbering problem that your random IT-staffed medium sized company can actually understand and use, NAT:ing is a lot simpler, and in many cases fits the v4 model anyway. Forgetting for a moment that having a chunk of your LIRs space is "PA" and not PI, this whole idea that you should route a more-specific of a LIR's allocation is also contra-productive to the ease of understanding and implementing filtering in v6-land (which is key to the future of the 2000::/3 trial, if you will). It makes the PI holder dependent on the LIR, not only for the lease of the address block, but in the face of routing policy, also its reachability. Irregardless of the address block being PI or not, it is the same number of routing slots in an unfiltered DFZ. And I see only clear downsides to "de-aggregating" the LIRs blocks. It also make route lookups deeper. LIRs (in terms of LIRs) are short-sighted to think easening up PI is a threat to their business anyway IMO, since the potential customer base, the size of the market, would grow considerably. > In this IPv6 PI discussion people say it is too expensive to be an LIR. > This strikes me as weird... even cheap network gear costs way more than > the LIR fee, and certainly the personnel costs are many times that, even > in countries where technical folks are poorly paid. But anyway.... I find it hard to motivate a difference between PIv4 and PIv6 in this regard. > Is there another reason to want to limit PI assignments? There may be. > Certainly the folks over in abuse-land think we should have super strict > controls over all addresses, and revoke them at the first hint of > naughtiness. Or there may be administrative reasons - an entirely > different kind of infrastructure is needed to manage hundreds of > thousands of low-fee (well, NO fee now) PI-holders than thousands of > high-fee LIRs. I don't know. Do you mean there is a superlinear growth of IPRA needs at the RIR if PI scales up? Why? I don't get why that would be the case at all. Isn't it just more of the same? The monetary cost for an application should cover the true costs of the RIR in handling it of course. (The fee for a end-user direct contractual relationship with RIPE is comparative to LIR status today anyway) > So... do you think we should simply remove all restrictions for IPv6 PI > and issue space if someone wants it, period? If not, what possible > restriction would there be? Clue-filter seems appropriate and sufficient, ie, no change from v4, except the need to be creative is inherently smaller with PIv6 than PIv4 which is a good thing. > I guess the "LIR middleman" model comes from the mists of time, long ago > in history. It certainly reduces the burden on the RIPE NCC, but it > never really struck me as sensible. After all, isn't the whole point of > PI space that you don't want to have to depend on an LIR? Indeed. You go to the IP shop and leave your name and number, and a pay small fee and then you walk out with your leased space. Then you go to the Internet field and start playing with it. The only function of a LIR in this sense is to increase the number of shops where you can get the PI, making it more available, so you won't have to travel to the head quarters, if it is far away. :) There is little reason, except for consulting services, for you to be in contract with your random local PI shop for this, since it is only a service mediator for the head quarters. /Martin IPv6 to the people! From andrea at ripe.net Wed Feb 16 17:12:40 2011 From: andrea at ripe.net (Andrea Cima) Date: Wed, 16 Feb 2011 17:12:40 +0100 Subject: [address-policy-wg] Re: New IPv4 block allocated to RIPE NCC In-Reply-To: <4D5AC87D.9060603@cymru.com> References: <4D4FBBDA.8040704@ripe.net> <4D5961A6.6030201@cymru.com> <4D5A73E0.8020804@ripe.net> <4D5AC87D.9060603@cymru.com> Message-ID: <4D5BF778.50709@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Tim, Tim Wilde wrote: [...] > Andrea, > > Thank you for this pointer, this is indeed an interesting and helpful > file. However, I note that it has the same problem as the traditional > delegated prefixes file, ie, it lists the "debogon" prefixes listed in > your announcement (185.0.0.0/16, 185.1.0.0/21, and 185.1.24.0/24) as > available as part of an "available" listing for all of 185.0.0.0/10: > > ripencc||ipv4|185.0.0.0|4194304||available > > If we were to use this file, we would have the same problem that we have > using the traditional delegated list; we would list your "debogon" > prefixes as bogon, because, according to your records, they are > available, ie unallocated/unassigned, ie bogon. Do you see the problem > we're running into? From my perspective, the "debogon" prefixes should > be considered allocated - it's an internal allocation, and a temporary > one, but it's still an allocation. This is, in fact, how 185.0.0.0/17 > is listed in the RIPE WHOIS database: > > % Information related to '185.0.0.0 - 185.1.255.255' > > inetnum: 185.0.0.0 - 185.1.255.255 > netname: EU-ZZ-20100510 > org: ORG-NCC1-RIPE > descr: RIPE NCC Test Announce > country: EU > admin-c: HU266-RIPE > tech-c: RISM-RIPE > status: ALLOCATED PA > mnt-by: RIPE-NCC-HM-MNT > mnt-by: RIPE-NCC-RIS-MNT > source: RIPE # Filtered > > But this is not reflected in the delegated-latest file. Should it not > be there (and in this new experimental file) as an allocation, since > that's what WHOIS says it is? Historically these pilot prefixes have never been listed in the delegated-latest file. However I agree with you that they should. We will add these temporary allocations to the delegated-latest file in the coming days. Best regards, Andrea Cima RIPE NCC > Best regards, > Tim Wilde > -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAk1b93gACgkQXOgsmPkFrjMPwwCgiqYrdIhlGWvk87v7LH+MXHVS 4pkAoJJUbYrHpEKBbuQ5TIx/gnLYndiu =iJ0m -----END PGP SIGNATURE----- From ebais at a2b-internet.com Wed Feb 16 18:08:58 2011 From: ebais at a2b-internet.com (Erik Bais) Date: Wed, 16 Feb 2011 18:08:58 +0100 Subject: [address-policy-wg] PI concept in general, was IPv6 PI resource question! In-Reply-To: <1297864525.4268.92.camel@shane-desktop> References: <8F621F87-82DF-45AB-B363-FF761A3FD61C@steffann.nl> <20110215074813.GA334@srv03.cluenet.de> <1297761281.4268.21.camel@shane-desktop> <20110215094727.GA8717@srv03.cluenet.de> <1297771275.4268.34.camel@shane-desktop> <20110215194129.GA13990@srv03.cluenet.de> <1297864525.4268.92.camel@shane-desktop> Message-ID: <003701cbcdfc$33a62410$9af26c30$@com> Hi Shane & Daniel, On Tue, 2011-02-15 at 20:41 +0100, Daniel Roesen wrote: > We're allowing PIv6 for "multihomed" (whatever that means really) sites. > Those could "just simply" use PA space from any ISP they connect to. I see customers that don't want to become a LIR or have the intention to do multi-homing, however they would like to have the option to request IPv6 addresses that are not tied to their provider (PA space). And as a LIR, sorting out their request for PI address space is something we charge for. If they don't want to shell out a couple hundred euro's for the handling of the request via us as their LIR or the cost for a direct end-user assignment or LIR fee, they can use IP's from our PA space which they would have to give back when they decide to take their business elsewhere. The term multi-homing by using BGP in the policy, is something I'm personally as a network provider not very keen on, as every AS they would need to connect to, is a connection to another provider that is a direct competitor. Simple as that. Is it better for the routing table / routers etc, to have larger blocks and as little as small prefixes as possible ? Sure, it will scale a lot better, however as the option of obtainable PI IPv6 space is there, people could request it for their own infrastructure and use it. The limitation of PIv6 in combination with multihomed (as in multihomed with its own AS using BGP) is something I personally would rather see dropped than enforced. Some companies actually take the steps into v6 & multi-homing in steps or want to take the approach, renumber once ... and NEVER again !! And we'll see in the future if multi-homed is going to be pursued or required. ---- > In this IPv6 PI discussion people say it is too expensive to be an LIR. > This strikes me as weird... even cheap network gear costs way more than > the LIR fee, and certainly the personnel costs are many times that, even > in countries where technical folks are poorly paid. But anyway.... The cost for a LIR status are not the issue from what I see for most of the companies I speak with. Most of them just don't want to deal with the RIPE stuff (yet). They don't see themselves as an ISP or hoster and are perfectly happy with the fact they can only use PI for their own infrastructure. Next to the stated cost of router equip, most of them are very happy to deal with racks of servers and linux patches etc. but are not up to speed on routing / networking / bgp etc. They just want to be prepared in case they move and / or grow to a size where they would want to run their own network equipment because it is at some point cheaper to sort out their own traffic / network. ---- >Is there another reason to want to limit PI assignments? There may be. >Certainly the folks over in abuse-land think we should have super strict >controls over all addresses, and revoke them at the first hint of >naughtiness. Or there may be administrative reasons - an entirely >different kind of infrastructure is needed to manage hundreds of >thousands of low-fee (well, NO fee now) PI-holders than thousands of >high-fee LIRs. I don't know. >So... do you think we should simply remove all restrictions for IPv6 PI >and issue space if someone wants it, period? If not, what possible >restriction would there be? In my personal opinion, cost isn't always the topic when deciding for PI. I would even dare to say that currently PI objects are way too cheap. And I wouldn't mind to ask customers to pay a yearly fee of 250 euro up-to 400 Euro per /48 PI IPv6 if they wouldn't have the multi-homing requirement. And by making it a bit more expensive, it will also provide a barrier that this isn't free or something to have for fun. But the companies that really want it for their own reasons, they will request it anyway. ---- >Finally, I think what bothers me about PI in general though is that once >the initial assignment is made... that's it. At least with RIPE 452 we >have *some* contractual relationship with the PI holder, but that's >about it. >I guess the "LIR middleman" model comes from the mists of time, long ago >in history. It certainly reduces the burden on the RIPE NCC, but it >never really struck me as sensible. After all, isn't the whole point of >PI space that you don't want to have to depend on an LIR? Not completely, having a LIR dealing with your requests, db updates and sorting out the route-objects etc. could still add value to those customers that don't want to become a LIR. As said above, a lot of my PI customers have no clue about networking or RIPE policies, having a LIR to fall-back to, adds value to them and it is cheaper than becoming a direct end-user or a LIR themselves. Regards, Erik Bais From nick at inex.ie Wed Feb 16 18:33:22 2011 From: nick at inex.ie (Nick Hilliard) Date: Wed, 16 Feb 2011 17:33:22 +0000 Subject: [address-policy-wg] PI concept in general, was IPv6 PI resource question! In-Reply-To: References: <8F621F87-82DF-45AB-B363-FF761A3FD61C@steffann.nl> <20110215074813.GA334@srv03.cluenet.de> <1297761281.4268.21.camel@shane-desktop> <20110215094727.GA8717@srv03.cluenet.de> <1297771275.4268.34.camel@shane-desktop> <20110215194129.GA13990@srv03.cluenet.de> <1297864525.4268.92.camel@shane-desktop> Message-ID: <4D5C0A62.4030609@inex.ie> On 16/02/2011 16:28, Martin Millnert wrote: > Routing slots notwithstanding, the hurdles the RIPE community puts up > for PIv6 is *directly* contra-productive to roll-out of IPv6 in > general, and the "end-to-end"-roll-out specifically. possibly. But these hurdles are insignificant compared to the other hurdles you're going to run into for an ipv6 deployment, including: - poor vendor support, still - training and support costs - poor existing ipv6 connectivity - low cost:return ratio Regarding routing slots, here's some hand-waving / back-of-a-napkin / finger in the air analysis: ipv6 generally takes up either 2 or 4 times the amount of lookup engine space that ipv4 does (implementation / hardware dependent). Unique ASNs on the internet are currently at about ~37000, and increasing at a rate of ~2500 a year. So if we assume that every ASN gets at least one IPv6 prefix in the next two years, and there's going to be an average of 1.4 prefixes per ASN (which seems to be what it's at right now), in two years time, we end up with the following number of TCAM slots (assuming 4 x ipv4 = 1 x ipv6): (37000 + 2500*2) * 1.4 * 4 = 235000 ipv4 equivalent slots. For ipv4, we're currently at 340k and growing at 50k/annum. In two years, we might be at 440k slots, assuming that resource exhaustion doesn't cause massive de-aggregation. This would indicate maybe around 675k ipv4-equivalent lookup engine slots. Then you add in your mpls, IGP and multicast slots. So, within 2 years on a small network, 1m route lookup entries may still work, but almost certainly will not work on a large network. If there is massive ipv6 deaggregation, it will cause 4x the damage of the equivalent ipv4 deaggregation. This is bad, and it will cost lots of people lots of money. Nick -- [note: while no animals were harmed during the production of these numbers, they are basically pulled out of a hat with no real consideration of whether they might correlate to reality in any way. Please don't bother trying to argue with me about them. I _will_ deny everything / plead insanity / blame it on the cat taking over my keyboard] From millnert at gmail.com Wed Feb 16 20:03:05 2011 From: millnert at gmail.com (Martin Millnert) Date: Wed, 16 Feb 2011 14:03:05 -0500 Subject: [address-policy-wg] PI concept in general, was IPv6 PI resource question! In-Reply-To: <4D5C0A62.4030609@inex.ie> References: <8F621F87-82DF-45AB-B363-FF761A3FD61C@steffann.nl> <20110215074813.GA334@srv03.cluenet.de> <1297761281.4268.21.camel@shane-desktop> <20110215094727.GA8717@srv03.cluenet.de> <1297771275.4268.34.camel@shane-desktop> <20110215194129.GA13990@srv03.cluenet.de> <1297864525.4268.92.camel@shane-desktop> <4D5C0A62.4030609@inex.ie> Message-ID: On Wed, Feb 16, 2011 at 12:33 PM, Nick Hilliard wrote: > Regarding routing slots, here's some hand-waving / back-of-a-napkin / finger > in the air analysis: [...] > If there is massive ipv6 deaggregation, it will cause 4x the damage of the > equivalent ipv4 deaggregation. ?This is bad, and it will cost lots of people > lots of money. > > Nick Yeah, and this is exactly why I believe keeping stuff simple (eg, approximately 10^3.14 times better with a PIv6 for a AS-cust who wants to announce a route than cracking away at the "PA" LIR-blocks), enables networks to filter deaggs in a much less destructive way. Which brings us into LIR/BGP territory: IMNSHO policies should / should continue to advice operators that "PA" space is provider-dependent whereas PI is PI, in terms of non-guaranteed but best-effort-expected routing goes. ;) There is a much better chance to get it right with v6 due to its size than v4, since we can be pretty specific about where PI and micro allocs come from and where /32s-or-shorter come from, and they're not overlapped. While address assignment policies traditionally does not dictate routing policies (it actually does set the lower bar in v6, plus there's the multihoming bit :) ), it is better to lay the framework for a constructive v6-land then a destructive one. Also, costs, policies and administrativia should incentivize networks to not check out a discontinuous PIv6 /48 per site if they have many. Obviously, it is beneficial that networks operate out of contiguous space rather than fragmented, since it allows routing policies to automatically drop more-specifics. Whether or not someone decides to do so is up to them, of course. The key is of course that the addressing allows it to happen. This is how I mean address assignment policies perhaps not dictate routing policies, but they certainly lays the framework for how it can operate. Cheers, Martin From igor at ergens.org Wed Feb 16 20:08:07 2011 From: igor at ergens.org (Igor Ybema) Date: Wed, 16 Feb 2011 20:08:07 +0100 Subject: [address-policy-wg] IPv6 PI resource question! Message-ID: Hi, I'm new to the list but would like to comment on this subject. I'm also trying to receive IPv6 PI for a webhosting customer of us which seems to be a big problem. I do not understand why everyone claims that 'the routing table growth' is the reason not to allow too much IPv6 PI. Those currently having IPv4 PI would of course require IPv6 PI because they still want to be indepentent. If they need to be a LIR to get IPv6 PA the problem is not solved for the routing-table issue. A prefix is still entered into the same global routing-table. I would suggest changing the IPv6 PI policy to make it more clear for hosting/isp company's to get IPv6 PI by enforcing that the equipment on which the IPv6 addresses are installed in rooms accessible by that company. Multi-homing is a good reason also. I'm not sure if we should delete that reason. This makes the company more aware that they are really independend. This suggestion solves two things: - large broadband ISP's with CPE in office-building, homes etc do not fit into this policy. The equipment is behind other company's doors. This enforces these company's to assign block to their customers from PA space as it was meant to be. - small ISP's/hosting company's with a few racks installed at one ore more DC's (which we talk about in this postings) do fit into this policy and will be independend to their internet suppliers. Of course, they should request another PI (or get assigned-PA from a LIR) for their customers which buy dedicated racks from them and receiving their own key to the lock. This is exactly what we would like to see it. What do other people on the list think about this? regards, Igor Ybema -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at inex.ie Wed Feb 16 23:11:04 2011 From: nick at inex.ie (Nick Hilliard) Date: Wed, 16 Feb 2011 22:11:04 +0000 Subject: [address-policy-wg] IPv6 PI resource question! In-Reply-To: References: Message-ID: <4D5C4B78.70601@inex.ie> On 16/02/2011 19:08, Igor Ybema wrote: > I do not understand why everyone claims that 'the routing table growth' > is the reason not to allow too much IPv6 PI. This is not really relevant to address-policy-wg, but it probably does need some explanation, because there are probably people on the mailing list who may not understand why some people get so upset about the issue. When a packet passes through a router, the router needs to decide where to send that packet. The way it works is that the router examines the destination IP address of the packet and performs a search through the entire routing table to see what the next hop address of that packet should be. The component on a router which does this lookup is called a "lookup engine", and depending on how big the router is, it will be implemented in one of a couple of different ways. On a low-end router (e.g. Juniper J series or Cisco 7200/7300), this is done on the main CPU. As this is a generic purpose CPU, this means that a router of this form will only be able to handle forwarding a certain number of packets per second before the CPU gets to busy to handle any more. A router of this form is generally referred to as a "software router". On a higher-end router (e.g. Juniper MX / M / T series, or Cisco GSR/CRS/7600), they use dedicated hardware lookup-engines, and in a chassis + blade system, these lookup engines will often be located on the line cards themselves. The advantage of this is that you can achieve _much_ higher throughput on the router. The disadvantage is that dedicated hardware of this form tends to be very expensive. A router of this form is generally referred to as a "hardware router". One of the more common hardware components for performing IP address lookups is called TCAM - ternary content addressable memory. It performs a similar function to an associative array in a language like PHP, except it's implemented in hardware. It's ridiculously fast and ridiculously expensive, and because it's so expensive, router manufacturers tend not to put large quantities into their lookup engines. So, a router vendor like Cisco might create a router with a lookup engine which had enough TCAM for 256000 ipv4 addresses (e.g. C7600/SUP7203B), or 500,000 entries (e.g. ASR1001), or they might make a line card with its own dedicated lookup engine which could handle 1,000,000 ipv4 addresses (e.g. ASR9000, brocade XMR). While you get very good performance from these lookup engines, you are also constrained by the fact that if the number of prefixes on your router exceeds the number of TCAM slots, then your router will either drop the packets or else do the lookup on the route-processor CPU. I.e. the moment you hit 1,000,001 prefixes, your ?200,000 C7600 with 20 x 10G ports will turn into a software router with the performance of a C7200VXR. This is generally considered to be a Bad Thing. If there are too many routes on the internet, this will cause the capacity of these routers to be exceeded, and they will need to be upgraded with a device with more lookup capacity. Replacing one or two routers like this for a small service provider is expensive, but if you have to perform a forklift upgrade on a continental or global infrastructure, you may be talking about hundreds of millions of ? / $ / ? worth of investment. Getting back to IPv6 PI assignments, the reason that people are so upset about them is that an IPv6 prefix can take up to 4 times the amount of TCAM than an ipv4 prefix. I.e. it fills up your router's routing slots 4 times faster. So, it will cause serious problems in future years if there is lots of IPv6 PI assigned to lots of end-users. Nick From Jasper.Jans at espritxb.nl Thu Feb 17 00:10:31 2011 From: Jasper.Jans at espritxb.nl (Jasper Jans) Date: Thu, 17 Feb 2011 00:10:31 +0100 Subject: [address-policy-wg] IPv6 PI resource question! In-Reply-To: <4D5C4B78.70601@inex.ie> References: <4D5C4B78.70601@inex.ie> Message-ID: <55557D0EBE9495428BFE94EF8BC5EBD20101CE6D2961@EXCH01.campus.local> Nick, Although your explanation of why large routing table are unwanted in the current discussion with regards to PI space I fail to see the point. Our customers want independence for a number of reasons - with IPv4 they could get PI space and have that independence. With regards to IPv6 the rules are currently different and they cannot get PI space. As suggested on this list many a time a work around is to become a LIR and get your own PA space. In the end these customers *will* generate new routes. The artificial hurdle in place now is in effect only slowing down the IPv6 adaptation in the case of our customers, it will not stop them from achieving their goals of being independent. Jasper -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Nick Hilliard Sent: Wednesday, February 16, 2011 11:11 PM To: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] IPv6 PI resource question! On 16/02/2011 19:08, Igor Ybema wrote: > I do not understand why everyone claims that 'the routing table growth' > is the reason not to allow too much IPv6 PI. This is not really relevant to address-policy-wg, but it probably does need some explanation, because there are probably people on the mailing list who may not understand why some people get so upset about the issue. When a packet passes through a router, the router needs to decide where to send that packet. The way it works is that the router examines the destination IP address of the packet and performs a search through the entire routing table to see what the next hop address of that packet should be. The component on a router which does this lookup is called a "lookup engine", and depending on how big the router is, it will be implemented in one of a couple of different ways. On a low-end router (e.g. Juniper J series or Cisco 7200/7300), this is done on the main CPU. As this is a generic purpose CPU, this means that a router of this form will only be able to handle forwarding a certain number of packets per second before the CPU gets to busy to handle any more. A router of this form is generally referred to as a "software router". On a higher-end router (e.g. Juniper MX / M / T series, or Cisco GSR/CRS/7600), they use dedicated hardware lookup-engines, and in a chassis + blade system, these lookup engines will often be located on the line cards themselves. The advantage of this is that you can achieve _much_ higher throughput on the router. The disadvantage is that dedicated hardware of this form tends to be very expensive. A router of this form is generally referred to as a "hardware router". One of the more common hardware components for performing IP address lookups is called TCAM - ternary content addressable memory. It performs a similar function to an associative array in a language like PHP, except it's implemented in hardware. It's ridiculously fast and ridiculously expensive, and because it's so expensive, router manufacturers tend not to put large quantities into their lookup engines. So, a router vendor like Cisco might create a router with a lookup engine which had enough TCAM for 256000 ipv4 addresses (e.g. C7600/SUP7203B), or 500,000 entries (e.g. ASR1001), or they might make a line card with its own dedicated lookup engine which could handle 1,000,000 ipv4 addresses (e.g. ASR9000, brocade XMR). While you get very good performance from these lookup engines, you are also constrained by the fact that if the number of prefixes on your router exceeds the number of TCAM slots, then your router will either drop the packets or else do the lookup on the route-processor CPU. I.e. the moment you hit 1,000,001 prefixes, your ?200,000 C7600 with 20 x 10G ports will turn into a software router with the performance of a C7200VXR. This is generally considered to be a Bad Thing. If there are too many routes on the internet, this will cause the capacity of these routers to be exceeded, and they will need to be upgraded with a device with more lookup capacity. Replacing one or two routers like this for a small service provider is expensive, but if you have to perform a forklift upgrade on a continental or global infrastructure, you may be talking about hundreds of millions of ? / $ / ? worth of investment. Getting back to IPv6 PI assignments, the reason that people are so upset about them is that an IPv6 prefix can take up to 4 times the amount of TCAM than an ipv4 prefix. I.e. it fills up your router's routing slots 4 times faster. So, it will cause serious problems in future years if there is lots of IPv6 PI assigned to lots of end-users. Nick Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer From Jasper.Jans at espritxb.nl Thu Feb 17 00:12:56 2011 From: Jasper.Jans at espritxb.nl (Jasper Jans) Date: Thu, 17 Feb 2011 00:12:56 +0100 Subject: [address-policy-wg] PI concept in general, was IPv6 PI resource question! In-Reply-To: <003701cbcdfc$33a62410$9af26c30$@com> References: <8F621F87-82DF-45AB-B363-FF761A3FD61C@steffann.nl> <20110215074813.GA334@srv03.cluenet.de> <1297761281.4268.21.camel@shane-desktop> <20110215094727.GA8717@srv03.cluenet.de> <1297771275.4268.34.camel@shane-desktop> <20110215194129.GA13990@srv03.cluenet.de> <1297864525.4268.92.camel@shane-desktop> <003701cbcdfc$33a62410$9af26c30$@com> Message-ID: <55557D0EBE9495428BFE94EF8BC5EBD20101CE6D2962@EXCH01.campus.local> Erik, Thank you for wording our exact problems so clearly. We as ISP and sponsor are also really not waiting to see our customers get connectivity from the competition just so that they can qualify for IPv6 space. Because that is what the current policy dictates - dual homing is required for both PI as well as PA space. Jasper -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Erik Bais Sent: Wednesday, February 16, 2011 6:09 PM To: 'Shane Kerr'; 'Daniel Roesen' Cc: address-policy-wg at ripe.net Subject: RE: [address-policy-wg] PI concept in general, was IPv6 PI resource question! Hi Shane & Daniel, On Tue, 2011-02-15 at 20:41 +0100, Daniel Roesen wrote: > We're allowing PIv6 for "multihomed" (whatever that means really) sites. > Those could "just simply" use PA space from any ISP they connect to. I see customers that don't want to become a LIR or have the intention to do multi-homing, however they would like to have the option to request IPv6 addresses that are not tied to their provider (PA space). And as a LIR, sorting out their request for PI address space is something we charge for. If they don't want to shell out a couple hundred euro's for the handling of the request via us as their LIR or the cost for a direct end-user assignment or LIR fee, they can use IP's from our PA space which they would have to give back when they decide to take their business elsewhere. The term multi-homing by using BGP in the policy, is something I'm personally as a network provider not very keen on, as every AS they would need to connect to, is a connection to another provider that is a direct competitor. Simple as that. Is it better for the routing table / routers etc, to have larger blocks and as little as small prefixes as possible ? Sure, it will scale a lot better, however as the option of obtainable PI IPv6 space is there, people could request it for their own infrastructure and use it. The limitation of PIv6 in combination with multihomed (as in multihomed with its own AS using BGP) is something I personally would rather see dropped than enforced. Some companies actually take the steps into v6 & multi-homing in steps or want to take the approach, renumber once ... and NEVER again !! And we'll see in the future if multi-homed is going to be pursued or required. ---- > In this IPv6 PI discussion people say it is too expensive to be an LIR. > This strikes me as weird... even cheap network gear costs way more than > the LIR fee, and certainly the personnel costs are many times that, even > in countries where technical folks are poorly paid. But anyway.... The cost for a LIR status are not the issue from what I see for most of the companies I speak with. Most of them just don't want to deal with the RIPE stuff (yet). They don't see themselves as an ISP or hoster and are perfectly happy with the fact they can only use PI for their own infrastructure. Next to the stated cost of router equip, most of them are very happy to deal with racks of servers and linux patches etc. but are not up to speed on routing / networking / bgp etc. They just want to be prepared in case they move and / or grow to a size where they would want to run their own network equipment because it is at some point cheaper to sort out their own traffic / network. ---- >Is there another reason to want to limit PI assignments? There may be. >Certainly the folks over in abuse-land think we should have super strict >controls over all addresses, and revoke them at the first hint of >naughtiness. Or there may be administrative reasons - an entirely >different kind of infrastructure is needed to manage hundreds of >thousands of low-fee (well, NO fee now) PI-holders than thousands of >high-fee LIRs. I don't know. >So... do you think we should simply remove all restrictions for IPv6 PI >and issue space if someone wants it, period? If not, what possible >restriction would there be? In my personal opinion, cost isn't always the topic when deciding for PI. I would even dare to say that currently PI objects are way too cheap. And I wouldn't mind to ask customers to pay a yearly fee of 250 euro up-to 400 Euro per /48 PI IPv6 if they wouldn't have the multi-homing requirement. And by making it a bit more expensive, it will also provide a barrier that this isn't free or something to have for fun. But the companies that really want it for their own reasons, they will request it anyway. ---- >Finally, I think what bothers me about PI in general though is that once >the initial assignment is made... that's it. At least with RIPE 452 we >have *some* contractual relationship with the PI holder, but that's >about it. >I guess the "LIR middleman" model comes from the mists of time, long ago >in history. It certainly reduces the burden on the RIPE NCC, but it >never really struck me as sensible. After all, isn't the whole point of >PI space that you don't want to have to depend on an LIR? Not completely, having a LIR dealing with your requests, db updates and sorting out the route-objects etc. could still add value to those customers that don't want to become a LIR. As said above, a lot of my PI customers have no clue about networking or RIPE policies, having a LIR to fall-back to, adds value to them and it is cheaper than becoming a direct end-user or a LIR themselves. Regards, Erik Bais Op dit e-mailbericht is een disclaimer van toepassing, welke te vinden is op http://www.espritxb.nl/disclaimer From twilde at cymru.com Wed Feb 16 19:47:33 2011 From: twilde at cymru.com (Tim Wilde) Date: Wed, 16 Feb 2011 13:47:33 -0500 Subject: [address-policy-wg] Re: [TC-NOC] New IPv4 block allocated to RIPE NCC In-Reply-To: <4D5BF778.50709@ripe.net> References: <4D4FBBDA.8040704@ripe.net> <4D5961A6.6030201@cymru.com> <4D5A73E0.8020804@ripe.net> <4D5AC87D.9060603@cymru.com> <4D5BF778.50709@ripe.net> Message-ID: <4D5C1BC5.8080204@cymru.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/16/2011 11:12 AM, Andrea Cima wrote: > Historically these pilot prefixes have never been listed in the > delegated-latest file. However I agree with you that they should. > We will add these temporary allocations to the delegated-latest file in > the coming days. Andrea, Great, thanks, I'm glad to hear it! Best regards, Tim Wilde - -- Tim Wilde, Senior Software Engineer, Team Cymru, Inc. twilde at cymru.com | +1-630-230-5433 | http://www.team-cymru.org/ -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAk1cG8UACgkQluRbRini9ti06wCcCTrkV4AxO6NwaYRFdCRVT/Ib 7sQAn3Tv5KgPEFXmJbfG45Hy32pArqJB =Xxqi -----END PGP SIGNATURE----- From matoa-ml at vayu.net Thu Feb 17 10:09:32 2011 From: matoa-ml at vayu.net (Mathieu Paonessa) Date: Thu, 17 Feb 2011 10:09:32 +0100 Subject: [address-policy-wg] IPv6 PI resource question - Not for ISP but hosting In-Reply-To: <5A3E23FB-3C48-473F-B840-617AB360F202@steffann.nl> References: <4D5AACCE.2030402@vayu.net> <5A3E23FB-3C48-473F-B840-617AB360F202@steffann.nl> Message-ID: <4D5CE5CC.1090908@vayu.net> On 2/15/11 6:04 PM, Sander Steffann wrote: > No. This all sounds like their own infrastructure/network/equipment. That they run software for customers, and that they choose a certain numbering plan shouldn't make a difference here. When they provide network services to their customer it starts to become more complicated, but this doesn't sound like a problem for IPv6 PI space to me. (based on the given information of course. I'm not trying to tell an IPRA what to do... They might have based their evaluation on different information) > > But the way you describe it it does not sound like they assign address space to other organizations. It sounds like they assign address space to parts of their own server farm. > > But this is my personal interpretation of the current policy. If someone disagrees with this, please speak up! The request finally got rejected because the IPRA considered that this was a sub-allocation. They encouraged our customer to become a LIR (which they clearly don't want to) or get a PA from us and then deaggregate it over BGP (which we clearly don't want to). If this community wants IPv6 to be more deployed, we really need to have this policy evolved. Mathieu From millnert at gmail.com Thu Feb 17 10:14:09 2011 From: millnert at gmail.com (Martin Millnert) Date: Thu, 17 Feb 2011 04:14:09 -0500 Subject: [address-policy-wg] IPv6 PI resource question - Not for ISP but hosting In-Reply-To: <4D5CE5CC.1090908@vayu.net> References: <4D5AACCE.2030402@vayu.net> <5A3E23FB-3C48-473F-B840-617AB360F202@steffann.nl> <4D5CE5CC.1090908@vayu.net> Message-ID: On Thu, Feb 17, 2011 at 4:09 AM, Mathieu Paonessa wrote: > If this community wants IPv6 to be more deployed, we really need to have > this policy evolved. > > Mathieu Write a proposal :) Regards, Martin From jim at rfc1035.com Thu Feb 17 10:54:05 2011 From: jim at rfc1035.com (Jim Reid) Date: Thu, 17 Feb 2011 09:54:05 +0000 Subject: [address-policy-wg] IPv6 PI for profit, webhosting and route deaggregation In-Reply-To: References: Message-ID: On 16 Feb 2011, at 19:08, Igor Ybema wrote: > I'm also trying to receive IPv6 PI for a webhosting customer of us > which seems to be a big problem. Well perhaps you could explain to us why you or your customer feel they need IPv6 PI space for webhosting. I'm struggling to see what the justification might be for any sort of PI space for that. > I do not understand why everyone claims that 'the routing table > growth' is > the reason not to allow too much IPv6 PI. There's no reason to repeat the same mistakes with IPv6 allocation policy as we did with IPv4. Doling out lots of non-aggregatable IPv6 PI allocations will just give us a re-run of today's IPv4 routing table scalability horrors. Except with much longer prefixes => burning even more router memory and CPU. IPv6 gives us the potential to waste more space on PI vanity projects. That doesn't mean we should do so just because we can. Just think of the number of edge devices that are likely to get IPv6 addresses and have suppliers/vendors managing those edge address assignments: consumer electronics gadgets, RFID tags, phones, utility meters, lightbulbs, sensor networks, etc, etc. If these suppliers/vendors head down the PI path, life will get unpleasant. Unless you are a Cisco, Juniper or semiconductor shareholder. We now know a great deal more about how address policies affect route deaggregation than we did back in the good old days. Since IPv6 allocation policy is essentially starting from a blank sheet of paper, it shouldn't be encumbered with all the cruft and bad ideas that IPv4 policies picked up along the path to their eventual oblivion. This does of course mean that we can (and probably will) make new mistakes with IPv6 address allocation. It should not mean repeating the earlier ones. Please also bear in mind that there will be even more IPv4 deaggregation as the run-out starts to bite. So let's not make the router problems even worse by facilitating an explosion in the IPv6 routing table as that other problem gathers momentum. > Those currently having IPv4 PI would of course require IPv6 PI > because they > still want to be indepentent. If they need to be a LIR to get IPv6 > PA the > problem is not solved for the routing-table issue. A prefix is still > entered > into the same global routing-table. This is true but misses the point Igor. Consider an LIR which doles out a /80 (say) to each of its customers who buys its web hosting services. These prefixes can be aggregated behind a single /64 (or whatever) => 1 routing table entry. If each of those customers got its own IPv6 PI space (why?), that's N routing table entries, all with longer prefixes, etc, etc. I'm unconvinced that "wanting to be independent" (of what?) for someone who's only needing some web hosting is a justification for PI space. From nick at inex.ie Thu Feb 17 11:29:50 2011 From: nick at inex.ie (Nick Hilliard) Date: Thu, 17 Feb 2011 10:29:50 +0000 Subject: [address-policy-wg] IPv6 PI for profit, webhosting and route deaggregation In-Reply-To: References: Message-ID: <4D5CF89E.4090909@inex.ie> On 17/02/2011 09:54, Jim Reid wrote: > Well perhaps you could explain to us why you or your customer feel they > need IPv6 PI space for webhosting. I'm struggling to see what the > justification might be for any sort of PI space for that. For exactly the same reason that you want your own IP address space for customer DSL access, or generic ISP service, or whatever. Even for very small businesses, it's still a bad business idea to shackle yourself to a single service provider. What if that relationship goes bad? Your business can go down the drain. Nick From ebais at a2b-internet.com Thu Feb 17 11:47:57 2011 From: ebais at a2b-internet.com (Erik Bais) Date: Thu, 17 Feb 2011 11:47:57 +0100 Subject: [address-policy-wg] IPv6 PI for profit, webhosting and route deaggregation In-Reply-To: References: Message-ID: <002801cbce90$23a01fa0$6ae05ee0$@com> Hi Jim, > I'm unconvinced that "wanting to be independent" (of what?) for? > someone who's only needing some web hosting is a justification for PI? > space. You made a nice speech about routing table size, de-aggregation and not understanding why someone would want to be independent. I don't see it like that. The way the policy is currently, doesn't solve your points. Let's take the following cases. A customer wants to be independent. They ask for PI but doesn't want to multi-home. They want to be independent of their providers IP addresses, they basically want their own. Let's take as an example they are a webhosting company with some shared webservers for shared webhosting and VPS's on their own infrastructure OR for instance a city with x number of desktops and possibility to be aggregated with other cities into a single larger city (this is happening a lot in The Netherlands currently, cities merging together.) Those cities want to be able to have unique IP's without having to change all IP's with each change of the government when they decide to aggregate multiple smaller cities into a larger city. As the policy is currently, both will not get IPv6. They could get IPv4 PI and that's it. This same webhoster OR city, applies for a LIR membership. They get a /32 V6, they get a /21 IPv4, no questions asked. This points out exactly my statement, this policy flaw currently isn't about de-aggregation, routing table size or something else. It's a money issue. If you pay a LIR membership, you get all what you want. If you want a 'cheaper than a LIR membership cost' PI prefix, you need to change your infrastructure setup in order to comply if you don't want to buy your way into the community. As suggested yesterday as well, increase the cost for a /48 IPv6 PI object from 50 Euro to a 200 or 400 euro maintenance cost per year to avoid pet projects at home behind a DSL line and get rid of the multi-homing requirement. I've actually seen multiple cities get IP's denied by their current provider, got fed up with it and apply for a LIR membership and decided to do it themselves. Regards, Erik Bais From emadaio at ripe.net Tue Feb 22 09:38:48 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Tue, 22 Feb 2011 09:38:48 +0100 Subject: [address-policy-wg] 2010-05 Discussion Period extended until 22 March 2011 (Global Policy for IPv4 Allocation by the IANA Post Exhaustion) Message-ID: <20110222083849.2E1836A002@postboy.ripe.net> Dear Colleagues, The Discussion Period for the global policy proposal 2010-05 has been extended until 22 March 2011. The extension was decided due to the lack of feedback in the Initial Discussion Period. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2010-05 We encourage you to review this policy proposal and send your comments to . Regards, Emilio Madaio Policy Development Officer RIPE NCC From k13 at nikhef.nl Tue Feb 22 15:57:37 2011 From: k13 at nikhef.nl (Rob Blokzijl) Date: Tue, 22 Feb 2011 15:57:37 +0100 (MET) Subject: [address-policy-wg] 2008-08 New Version and Draft Document Published (Initial Certification Policy for Provider Aggregatable Address Space Holders) In-Reply-To: <20110209140036.9C4BB6A002@postboy.ripe.net> References: <20110209140036.9C4BB6A002@postboy.ripe.net> Message-ID: I think that the proposed policy adequately covers the current certfication service: an hosted service for LIR's PA space. Two remarks: 1. full details of the current service are described in the Certification Practice Statement, which can be found at: www.ripe.net/lir-services/resource-management/certification/cps/ 2. given the development time of this proposal it is high time that work on the next version is started: up/down, PI space, legacy space. So, let's aprrove this proposed policy, and start working on a more comprhensive policy. Rob From vegar at rentarack.no Tue Feb 22 17:49:27 2011 From: vegar at rentarack.no (=?iso-8859-1?Q?Vegar_L=F8v=E5s?=) Date: Tue, 22 Feb 2011 17:49:27 +0100 Subject: [address-policy-wg] IPv6 PI for profit, webhosting and route deaggregation In-Reply-To: <002801cbce90$23a01fa0$6ae05ee0$@com> References: <002801cbce90$23a01fa0$6ae05ee0$@com> Message-ID: Hello, > As suggested yesterday as well, increase the cost for a /48 IPv6 PI object > from 50 Euro to a 200 or 400 euro maintenance cost per year to avoid pet > projects at home behind a DSL line and get rid of the multi-homing > requirement. I support this too. It shouldn't be necessary to apply for a LIR membership just to be independent from your upstream provider. This text should also be added to the IPv6 policy, as in IPv4: "IP addresses used solely for the connection of an End User to a service provider (e.g. point-to-point links) are considered part of the service provider's infrastructure." One of our end-user's application for PI IPv6 was rejected because the IPRA considered the IP addresses of their shared hosting web servers as assignments to other end-users. Most of the websites on the internet are hosted on shared hosting providers. These companies is running hundreds of websites on the same IP address, and it's impossible to use IPv6 for these providers if their end-users must apply for their own IPv6 assignment. It also doesn't make sense if a colocation customer with 1 server has to get their own assignment because the hosting provider wants to be independent. To make an easier transition to IPv6, we must allow hosting providers to use PI IPv6 for their hosting services. Most of them have PI IPv4 today, and don't want a PA allocation for their IPv6 needs either. -- Best regards, Vegar L?v?s Rent a Rack AS From millnert at gmail.com Tue Feb 22 20:55:14 2011 From: millnert at gmail.com (Martin Millnert) Date: Tue, 22 Feb 2011 14:55:14 -0500 Subject: [address-policy-wg] Query for the RIPE NCC: Size of PIv4 assignments used for access networks Message-ID: Hi, I would like to request from the RIPE NCC an answer to the following query: ?What is the size, in number of addresses, of all PIv4 assignments that are (mostly) used for access networks? Access networks in this context means traditional ISP:s who let humans access the internet. I believe the RIPE NCC keeps documentation over what justifies an assignment, so I imagine it will be possible to come up with some kind of answer to this question even if it is outright impossible to answer based on data in the database. If it is indeed possible to answer the above question with some form of accuracy (+/- 50% or so: order of magnitude most important to get right), I would like to run the question also for PAv4. This is required data to reach some form of informed policy decision/consensus on the PIv4 / PIv6 discrepancy issue which has resurfaced. Regards, Martin From mattias.gyllenvarg at bredband2.se Wed Feb 23 16:24:04 2011 From: mattias.gyllenvarg at bredband2.se (Wyatt Mattias Gyllenvarg) Date: Wed, 23 Feb 2011 16:24:04 +0100 Subject: [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD Message-ID: <4D652694.4050401@bredband2.se> Hi We would like to weigh in here. We feel that it should be RIPEs policy to allocate ONE /32 to any LIR who requests it for 6rd. 6rd is the only way for us to reach all our residential customers. Especially those in Municipal Networks that are very slow to invest in their networks and often do not have the competence and time to impelment IPv6. Also, Cisco has not yet implemented even a small part of the protective mechanisms we rely on in IPv4 to secure our residential networks. Many of these features are required to meet the demands contracted with the customers. We cannot use native IPv6 until Cisco implements these features and we have tested and rolled them out on hundreds of switches. 6rd bypasses all these issues. IF we can get a /32 for that purpuse. -- Med V?nliga H?lsningar - Best regards Mattias Gyllenvarg Network Operations Center Bredband2 ---------------------- end of line --------------------------- From mohacsi at niif.hu Thu Feb 24 10:27:04 2011 From: mohacsi at niif.hu (Mohacsi Janos) Date: Thu, 24 Feb 2011 10:27:04 +0100 (CET) Subject: [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <4D652694.4050401@bredband2.se> References: <4D652694.4050401@bredband2.se> Message-ID: On Wed, 23 Feb 2011, Wyatt Mattias Gyllenvarg wrote: > Hi > > We would like to weigh in here. > We feel that it should be RIPEs policy to allocate ONE /32 to any LIR who > requests it for 6rd. > > 6rd is the only way for us to reach all our residential customers. Especially > those in Municipal Networks that are very slow to invest in their networks > and often do not have the competence and time to impelment IPv6. > > Also, Cisco has not yet implemented even a small part of the protective > mechanisms we rely on in IPv4 to secure our residential networks. Many of > these features are required to meet the demands contracted with the > customers. We cannot use native IPv6 until Cisco implements these features > and we have tested and rolled them out on hundreds of switches. > > 6rd bypasses all these issues. IF we can get a /32 for that purpuse. I think /32 for each LIR which wants to deploy 6RD is rather overwhelming: if you allocated /16 to your broadband customers from your IPv4 pool, then you might use that pool and for 6RD tunneling. You have allocated /32 in IPv6 from your RIR: Then you can omit the most significant 16 bits of (or less if you prefer) from forming the 6RD IPv6 prefix since it is always that 16 bit, and use only the least significant bits of IPv4 address which is 16 bits. Then at the end you decide to assign /56 for your broadband customers (which is acceptable - 256 subnets), then you can easily put all your broadband customers: 56-16 = 40 bits. You use only a single /40 for your broadband customers. If you allocate /8 for you broadband customers - with the same /56 IPv6 assignment, your IPv6 broadband allocations will be: 32-8 = 24 significant bit 56-24 = 32 bits for IPv6 broadband customers. Note: For non-mass deployment probably you don't want to use 6RD, but a real dual-stack deployment Best Regards, Janos Mohacsi > > -- > > Med V?nliga H?lsningar - Best regards > Mattias Gyllenvarg > Network Operations Center > Bredband2 > > ---------------------- end of line --------------------------- > > From Woeber at CC.UniVie.ac.at Thu Feb 24 13:05:23 2011 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 24 Feb 2011 12:05:23 +0000 Subject: [address-policy-wg] 2008-08 New Version and Draft Document Published (Initial Certification Policy for Provider Aggregatable Address Space Holders) In-Reply-To: <4D5ABF95.7070209@CC.UniVie.ac.at> References: <20110209140036.9C4BB6A002@postboy.ripe.net> <20110209141312.GD44800@Space.Net> <4D5ABF95.7070209@CC.UniVie.ac.at> Message-ID: <4D664983.6040001@CC.UniVie.ac.at> Wilfried Woeber, UniVie/ACOnet wrote: [...] > So, to sum it up, I do not oppose the idea or the proposal, but I think > it is not good enough yet to become policy. If we can't do better, I'd > prefer to continue on the basis of the provisional(?) CPS for now. > > Best regards, > Wilfried. After considering Rob's comment and R?diger's contribution, I'd like to change my position as quoted above to: Not perfect, flaws identitified and to be considered in a future version, but I support he proposal as circulated. Wilfried. From ahmed at tamkien.com Thu Feb 24 14:48:05 2011 From: ahmed at tamkien.com (Ahmed Abu-Abed) Date: Thu, 24 Feb 2011 15:48:05 +0200 Subject: [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <4D652694.4050401@bredband2.se> References: <4D652694.4050401@bredband2.se> Message-ID: <3F545002E3DA4FF7B951A7CAA36C7655@mTOSH> Hello, I am new to the Address Policy WG and this seems like quite an old discussion. I endorse assigning a /32 to LIRs regardless of the IPv6 access method they use. Other than to 6RD, TSP is another protocol (RFC 5572) that can be used to enable IPv6 to end users rapidly over intermediate IPv4 nodes. A useful comparison between TSP, 6RD and other IPv6 access tunneling protocols is shown in http://gogoware.gogo6.com/4105/file.asp?file_id=942 As for IPv6 CPE and server gateways availability, there are commercial solutions in the market that implement 6RD and TSP for both sides of the tunnel. Regards, -Ahmed From: Wyatt Mattias Gyllenvarg Sent: Wednesday, February 23, 2011 5:24 PM To: address-policy-wg at ripe.net Subject: RE: [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD Hi We would like to weigh in here. We feel that it should be RIPEs policy to allocate ONE /32 to any LIR who requests it for 6rd. 6rd is the only way for us to reach all our residential customers. Especially those in Municipal Networks that are very slow to invest in their networks and often do not have the competence and time to impelment IPv6. Also, Cisco has not yet implemented even a small part of the protective mechanisms we rely on in IPv4 to secure our residential networks. Many of these features are required to meet the demands contracted with the customers. We cannot use native IPv6 until Cisco implements these features and we have tested and rolled them out on hundreds of switches. 6rd bypasses all these issues. IF we can get a /32 for that purpuse. -- Med V?nliga H?lsningar - Best regards Mattias Gyllenvarg Network Operations Center Bredband2 ---------------------- end of line --------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From turchanyi.geza at gmail.com Thu Feb 24 15:25:49 2011 From: turchanyi.geza at gmail.com (Turchanyi Geza) Date: Thu, 24 Feb 2011 15:25:49 +0100 Subject: [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <3F545002E3DA4FF7B951A7CAA36C7655@mTOSH> References: <4D652694.4050401@bredband2.se> <3F545002E3DA4FF7B951A7CAA36C7655@mTOSH> Message-ID: Hello Ahmed, Many thanks for forwarding the comparison table. Temporary solutions are usefull in the transition phase. However, I would prefere emphasize even in the address allocation mechanism if a solution is temporary and should go away in long term. Therefore I fully agree with J?nos, the smallest address space the best in case of 6RD and other non-real-dual-stack method. G?za On Thu, Feb 24, 2011 at 2:48 PM, Ahmed Abu-Abed wrote: > Hello, > > I am new to the Address Policy WG and this seems like quite an old > discussion. I endorse assigning a /32 to LIRs regardless of the IPv6 access > method they use. > > Other than to 6RD, TSP is another protocol (RFC 5572) that can be used to > enable IPv6 to end users rapidly over intermediate IPv4 nodes. A useful > comparison between TSP, 6RD and other IPv6 access tunneling protocols is > shown in http://gogoware.gogo6.com/4105/file.asp?file_id=942 > > As for IPv6 CPE and server gateways availability, there are commercial > solutions in the market that implement 6RD and TSP for both sides of the > tunnel. > > Regards, > -Ahmed > > > *From:* Wyatt Mattias Gyllenvarg > *Sent:* Wednesday, February 23, 2011 5:24 PM > *To:* address-policy-wg at ripe.net > *Subject:* RE: [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD > > Hi > > We would like to weigh in here. > We feel that it should be RIPEs policy to allocate ONE /32 to any LIR > who requests it for 6rd. > > 6rd is the only way for us to reach all our residential customers. > Especially those in Municipal Networks that are very slow to invest in > their networks and often do not have the competence and time to > impelment IPv6. > > Also, Cisco has not yet implemented even a small part of the protective > mechanisms we rely on in IPv4 to secure our residential networks. Many > of these features are required to meet the demands contracted with the > customers. We cannot use native IPv6 until Cisco implements these > features and we have tested and rolled them out on hundreds of switches. > > 6rd bypasses all these issues. IF we can get a /32 for that purpuse. > > -- > > Med V?nliga H?lsningar - Best regards > Mattias Gyllenvarg > Network Operations Center > Bredband2 > > ---------------------- end of line --------------------------- > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahmed at tamkien.com Thu Feb 24 15:43:57 2011 From: ahmed at tamkien.com (Ahmed Abu-Abed) Date: Thu, 24 Feb 2011 16:43:57 +0200 Subject: [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: <4D652694.4050401@bredband2.se><3F545002E3DA4FF7B951A7CAA36C7655@mTOSH> Message-ID: HI G?za, Given IPv4's imminent depletion at the RIR level, dual-stacking without tunneling or translation will be a short term solution too. Pure dual-stacking, up to the consumer's premise, assumes you are laying out dual-stack (with both IPv4 and IPv6 enabled) nodes from core up to the CPE, and the customer is getting both IPv6 and IPv4 public addresses, and the latter is very scarce. So for v4 and v6 to coexist for the next 10 years or so we need tunneling, or some form of IPv6-only at the customers terminal with translation to IPv4 if needed. Hence my /32 endorsement for all IPv6 access methods. Regards, -Ahmed From: Turchanyi Geza Sent: Thursday, February 24, 2011 4:25 PM To: Ahmed Abu-Abed ; address-policy-wg at ripe.net Cc: Wyatt Mattias Gyllenvarg Subject: Re: [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD Hello Ahmed, Many thanks for forwarding the comparison table. Temporary solutions are usefull in the transition phase. However, I would prefere emphasize even in the address allocation mechanism if a solution is temporary and should go away in long term. Therefore I fully agree with J?nos, the smallest address space the best in case of 6RD and other non-real-dual-stack method. G?za On Thu, Feb 24, 2011 at 2:48 PM, Ahmed Abu-Abed wrote: Hello, I am new to the Address Policy WG and this seems like quite an old discussion. I endorse assigning a /32 to LIRs regardless of the IPv6 access method they use. Other than to 6RD, TSP is another protocol (RFC 5572) that can be used to enable IPv6 to end users rapidly over intermediate IPv4 nodes. A useful comparison between TSP, 6RD and other IPv6 access tunneling protocols is shown in http://gogoware.gogo6.com/4105/file.asp?file_id=942 As for IPv6 CPE and server gateways availability, there are commercial solutions in the market that implement 6RD and TSP for both sides of the tunnel. Regards, -Ahmed From: Wyatt Mattias Gyllenvarg Sent: Wednesday, February 23, 2011 5:24 PM To: address-policy-wg at ripe.net Subject: RE: [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD Hi We would like to weigh in here. We feel that it should be RIPEs policy to allocate ONE /32 to any LIR who requests it for 6rd. 6rd is the only way for us to reach all our residential customers. Especially those in Municipal Networks that are very slow to invest in their networks and often do not have the competence and time to impelment IPv6. Also, Cisco has not yet implemented even a small part of the protective mechanisms we rely on in IPv4 to secure our residential networks. Many of these features are required to meet the demands contracted with the customers. We cannot use native IPv6 until Cisco implements these features and we have tested and rolled them out on hundreds of switches. 6rd bypasses all these issues. IF we can get a /32 for that purpuse. -- Med V?nliga H?lsningar - Best regards Mattias Gyllenvarg Network Operations Center Bredband2 ---------------------- end of line --------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rv at NIC.DTAG.DE Thu Feb 24 00:00:40 2011 From: rv at NIC.DTAG.DE (Ruediger Volk, Deutsche Telekom T-Com - TE141-P1) Date: Thu, 24 Feb 2011 00:00:40 +0100 Subject: [routing-wg] [address-policy-wg] REMINDER; WAS Re: 2008-08 New Version and Draft Document Published (Initial Certification Policy for Provider Aggregatable Address Space Holders) In-Reply-To: Your message of "Tue, 15 Feb 2011 08:46:44 +0100." <4D5A2F64.9030905@ripe.net> Message-ID: <24010.1298502040@x37.NIC.DTAG.DE> Dear colleagues, I apologize for my bad habits and tradition for sending comments at the very last minute. > Dear Colleagues, > > The new version of RIPE Policy Proposal 2008-08, "Initial Certification > Policy for Provider Aggregatable Address Space Holders", was published > on 9 February 2011. The time period for community review ends on 23 > February 2011. > > Some feedback was sent to the Address Policy Working Group mailing list. > However, to maintain the discussion, we strongly recommend that you > share your ideas and comments and clearly let the community know if you: > > - Support the implementation of the proposal I support the implementation of the proposal; please find additional comments below that point out some problems and some ideas regarding required work. > - Support the general principle of the proposal but would prefer another > wording > - Support the general principle with some details changed but agree to > postpone this discussion until another stage of the policy proposal > review. (This is an initial proposal that covers only PA resources. If > the community supports extending certification to all resources, then > another version of the proposal will be necessary.) > - Do not support the proposal (please explain your motivations) > > > 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 > > Please send an email with your comments to address-policy-wg at ripe.net by > 23 February 2011. > > Best regards, > Emilio Madaio My "vote" on the proposal is: I agree to the policy proposal (consisting of "Summary", "Policy Text", and "Rationale") and want to see it fully executed as a minimum first step of implementing full RPKI support by RIPE NCC fitting into the global RPKI infrastructure. This MUST NOT be delayed any further (considering the long time this has been worked AND having missed a committed delivery date [Jan 1 2011] already. I have more comments (which may seem to dilute the primary statement, but hopefully help to fix problems and make more progress) This policy is simpler and more limited than would seem adequate and desirable in today's situation; it was more appropriate when initial versions were proposed. Even while some open ends are recognized the initial policy should be put in place to clearly indicate that the RIPE community is in control of setting policy for the operation of the NCC RPKI service; however we also need to recognize there is a challenge to deal here with more complexity and deeper technical detail compared with [most] other RIPE policies; this includes even the question of just how to identify/separate community and user relevant policy from implementation details. I see need for discussion of the NCC's impact analysis and other related documents (potentially including the process for document control). I have one clear and simple problem (=objection) to the NCC's impact analysis: I do not understand how the NCC can conclude that "this proposal only applies to IPv4 ..."; I do not see such restriction in the language of the proposal - and I'm sure that contributors to the proposal certainly would have expressed this unambiguously if that had been the intention. So I would like to emphasize that the intended policy OF COURSE covers both address families - and the definition of RPKI anyway! Inclusion of IPv6 is a MUST! If RIPE NCC has not yet implemented support of IPv6 they need to tell us the expected delivery date! As related documents I see (a) CPS (b) "... Deregistration of Internet number resources" (c) Certification Service Terms and Conditions (d) Certification Repository Terms and Conditions The need for (a) and (b) has been pointed out for more than 2 years; progress has been slow and late. Having a CPS is a standard requirement for serious [R]PKI CAs. I don't remember that there has been any mentioning of something like (c) and (d) in previous discussion and so they show up as somewhat of a surprise. The documents and their relation need some discussion, in particular with regard to how functions are distributed and to identify (and place) the relevant policy pieces. Somewhat as an example I'd like to mention: The elaborate standard structure that is defined for the CPS clearly includes parts that are defining user relevant policy details (some of which came up in the discussion of this policy proposal) as well as documentation of lots of implementation details that clearly should be left completely in the NCC's responsibility. (c) duplicates parts of the CPS and claims priority over the CPS and classifies the CPS as "explanatory document" - this looks questionable to me. Is it really acceptable that no notifications about replacements for revoked certificates are provided? (maybe OK for hosted service; hard to believe with full RPKI distributed CAs) For meeting the challenges and more satisfactory and satisfying results we need to establish a more detailed activity plan and focussed work. Regards, Ruediger Ruediger Volk Deutsche Telekom AG -- Internet Backbone Engineering E-Mail: rv at NIC.DTAG.DE From gert at space.net Thu Feb 24 16:31:57 2011 From: gert at space.net (Gert Doering) Date: Thu, 24 Feb 2011 16:31:57 +0100 Subject: [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <3F545002E3DA4FF7B951A7CAA36C7655@mTOSH> References: <4D652694.4050401@bredband2.se> <3F545002E3DA4FF7B951A7CAA36C7655@mTOSH> Message-ID: <20110224153157.GH30227@Space.Net> Hi, On Thu, Feb 24, 2011 at 03:48:05PM +0200, Ahmed Abu-Abed wrote: > I am new to the Address Policy WG and this seems like quite an old discussion. I endorse assigning a /32 to LIRs regardless of the IPv6 access method they use. Uh, what exactly are we discussing here? Just to make this very clear: Any RIPE LIR can get a /32 IPv6 PA right away, just by asking. Only if you want *multiple* /32, or "bigger than a /32", this is where it gets tricky (multiple distinct /32s are not possible under the current policy, "bigger than a /32" needs documentation that you have the necessary amount of customers). 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 From mohacsi at niif.hu Thu Feb 24 16:37:08 2011 From: mohacsi at niif.hu (Mohacsi Janos) Date: Thu, 24 Feb 2011 16:37:08 +0100 (CET) Subject: [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <20110224153157.GH30227@Space.Net> References: <4D652694.4050401@bredband2.se> <3F545002E3DA4FF7B951A7CAA36C7655@mTOSH> <20110224153157.GH30227@Space.Net> Message-ID: On Thu, 24 Feb 2011, Gert Doering wrote: > Hi, > > On Thu, Feb 24, 2011 at 03:48:05PM +0200, Ahmed Abu-Abed wrote: >> I am new to the Address Policy WG and this seems like quite an old discussion. I endorse assigning a /32 to LIRs regardless of the IPv6 access method they use. > > Uh, what exactly are we discussing here? > > Just to make this very clear: > > Any RIPE LIR can get a /32 IPv6 PA right away, just by asking. > > Only if you want *multiple* /32, or "bigger than a /32", this is where > it gets tricky (multiple distinct /32s are not possible under the > current policy, "bigger than a /32" needs documentation that you have > the necessary amount of customers). > > Gert Doering > -- APWG chair Yes Agreed. I am against the idea, that 6RD deployment automatically grant another /32 allocation. Best Regards, Janos From emadaio at ripe.net Fri Feb 25 08:51:24 2011 From: emadaio at ripe.net (Emilio Madaio) Date: Fri, 25 Feb 2011 08:51:24 +0100 Subject: [routing-wg] [address-policy-wg] REMINDER; WAS Re: 2008-08 New Version and Draft Document Published (Initial Certification Policy for Provider Aggregatable Address Space Holders) In-Reply-To: <24010.1298502040@x37.NIC.DTAG.DE> References: <24010.1298502040@x37.NIC.DTAG.DE> Message-ID: <4D675F7C.9060902@ripe.net> Dear Wilfried and Rudiger, thank you very much for your feedback and contribution to the review of the proposal on the mailing list. I hereby will try to clarify furthermore the Impact Analysis performed and published in the Review Phase. The policy text specifically states: " Following guidelines are to apply only for certification of Provider Aggregatable (PA) address space that are held by the RIPE NCC members in good standing. " Purely in terms of policy analysis, in the RIPE NCC service region Provider Aggregatable address space is defined only in the "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region", ripe-509, available at http://www.ripe.net/ripe/docs/ripe-509 Hence, according to the existing policies approved by the RIPE community, only IPv4 address space can be Provider Aggregatable. As Rudiger highlighted, we are challenged with this proposal to identify/separate community relevant policies from implementation details. The explanation given in the RIPE NCC's Understanding belongs only to the former: community relevant policies. The Understanding is meant to clarify to the community what the NCC reads in the proposal in order to give some information on how it would be implemented. The goal of the Impact Analysis is to provide relevant supporting information to facilitate the discussions. In this case, it leads into a deeper consideration of what the proposal means and the community's intentions on the whole Certification Service. I am already in touch with the proposer on this matter. Yours and all the other feedbacks presented during the last two weeks of Review Phase are going to be considered together with the Address Policy WG chairs and the next step of the policy making process will be announced to the community accordingly to the PDP. Best Regards Emilio Madaio Policy Development Officer On 2/24/11 12:00 AM, Ruediger Volk, Deutsche Telekom T-Com - TE141-P1 wrote: > Dear colleagues, > > I apologize for my bad habits and tradition for sending comments > at the very last minute. > > > Dear Colleagues, > > > > The new version of RIPE Policy Proposal 2008-08, "Initial Certification > > Policy for Provider Aggregatable Address Space Holders", was published > > on 9 February 2011. The time period for community review ends on 23 > > February 2011. > > > > Some feedback was sent to the Address Policy Working Group mailing list. > > However, to maintain the discussion, we strongly recommend that you > > share your ideas and comments and clearly let the community know if you: > > > > - Support the implementation of the proposal > I support the implementation of the proposal; > please find additional comments below that point out some problems > and some ideas regarding required work. > > > - Support the general principle of the proposal but would prefer another > > wording > > - Support the general principle with some details changed but agree to > > postpone this discussion until another stage of the policy proposal > > review. (This is an initial proposal that covers only PA resources. If > > the community supports extending certification to all resources, then > > another version of the proposal will be necessary.) > > - Do not support the proposal (please explain your motivations) > > > > > > 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 > > > > Please send an email with your comments to address-policy-wg at ripe.net by > > 23 February 2011. > > > > Best regards, > > Emilio Madaio > > > > My "vote" on the proposal is: > > I agree to the policy proposal (consisting of "Summary", "Policy Text", > and "Rationale") and want to see it fully executed as a minimum > first step of implementing full RPKI support by RIPE NCC fitting > into the global RPKI infrastructure. > This MUST NOT be delayed any further (considering the long time this has > been worked AND having missed a committed delivery date [Jan 1 2011] already. > > I have more comments (which may seem to dilute the primary statement, > but hopefully help to fix problems and make more progress) > > This policy is simpler and more limited than would seem adequate and desirable > in today's situation; it was more appropriate when initial versions were > proposed. > Even while some open ends are recognized the initial policy should be put > in place to clearly indicate that the RIPE community is in control of setting > policy for the operation of the NCC RPKI service; however we also need to > recognize there is a challenge to deal here with more complexity and deeper > technical detail compared with [most] other RIPE policies; this includes even > the question of just how to identify/separate community and user relevant policy > from implementation details. > > I see need for discussion of the NCC's impact analysis and > other related documents (potentially including the process for > document control). > > I have one clear and simple problem (=objection) to the NCC's impact analysis: > I do not understand how the NCC can conclude that "this proposal only applies > to IPv4 ..."; I do not see such restriction in the language > of the proposal - and I'm sure that contributors to the proposal > certainly would have expressed this unambiguously if that had been the > intention. > So I would like to emphasize that the intended policy OF COURSE covers both > address families - and the definition of RPKI anyway! > Inclusion of IPv6 is a MUST! > If RIPE NCC has not yet implemented support of IPv6 they need to tell us > the expected delivery date! > > As related documents I see > > (a) CPS > (b) "... Deregistration of Internet number resources" > (c) Certification Service Terms and Conditions > (d) Certification Repository Terms and Conditions > > The need for (a) and (b) has been pointed out for more than 2 years; > progress has been slow and late. > Having a CPS is a standard requirement for serious [R]PKI CAs. > I don't remember that there has been any mentioning of something like > (c) and (d) in previous discussion and so they show up as somewhat > of a surprise. > The documents and their relation need some discussion, in particular with > regard to how functions are distributed and to identify (and place) > the relevant policy pieces. > > Somewhat as an example I'd like to mention: > The elaborate standard structure that is defined for the CPS clearly includes > parts that are defining user relevant policy details (some of which came up > in the discussion of this policy proposal) as well as documentation of lots of > implementation details that clearly should be left completely in the > NCC's responsibility. > (c) duplicates parts of the CPS and claims priority over the CPS and > classifies the CPS as "explanatory document" - this looks questionable to me. > Is it really acceptable that no notifications about replacements for > revoked certificates are provided? (maybe OK for hosted service; > hard to believe with full RPKI distributed CAs) > > For meeting the challenges and more satisfactory and satisfying results we > need to establish a more detailed activity plan and focussed work. > > > Regards, > Ruediger > > > Ruediger Volk > > Deutsche Telekom AG -- Internet Backbone Engineering > > E-Mail: rv at NIC.DTAG.DE > From mark at townsley.net Fri Feb 25 16:31:19 2011 From: mark at townsley.net (Mark Townsley) Date: Fri, 25 Feb 2011 16:31:19 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: <4D652694.4050401@bredband2.se> <3F545002E3DA4FF7B951A7CAA36C7655@mTOSH> <20110224153157.GH30227@Space.Net> Message-ID: <9916E4B6-8CC9-4BDC-9784-26555A5B80CE@townsley.net> This is not the first time this has come up on this list. It came up a few months back at ARIN as well, and resulted in a policy change that now allows subsequent allocations to ISPs that already have begun deployment within a /32 allocated in the past, but need additional space for continued deployment (for whatever reason, of which 6rd was one of the motivational factors presented). ARIN rejected mention of 6rd specifically as there were understandable objections to mentioning one particular transition technology over another, but it was certainly present in the open discussion leading up to the change. But, regardless of what ARIN has done, the issues boil down to this: Native residential IPv6 is proving difficult today. This is particularly problematic for IPoE DSL deployments where the vast majority of equipment deployed in the past 0-5 years which relies on snooping of DHCP, ARP, IMGP, etc. in order to operate in a split-horizon mode with subscribers connected into the same VLAN has largely no support for IPv6, DHCPv6, Neighbor Discovery, MLD, etc. Ironically, architectures based on "last-generation" PPP or simpler 1:1 VLAN models tend to work much better with IPv6 than the latest-greatest architectures that were built up in the past decade. This is true not only in DSL, but throughout the industry as somewhere after the dot-com boom and before the recent realization of IPv4 address exhaustion, much of the industry forgot to keep IPv6 in mind while inventing lots of new stuff. As such, overlays are needed, and 6rd is a particularly well-suited one for residential deployments. At the moment, 6rd is responsible for the majority of ISP-supported IPv6 traffic on the Internet today (based verbal comments from a very large content provider that supports v6), and based on the number of SPs I see successfully turning up 6rd vs. native service, I expect this will continue to be the case for at least the next few years. With a /32, 6rd easily supports a single /64 to a site. 6rd includes the ability to be more efficient with the address mapping algorithm, but this comes with additional overhead in provisioning that the ISP must endure. I know of SPs that have managed to plan for fairly efficient mappings by setting up several 6rd domains. However, others have difficulties in doing so, and at the end of the day mapping a full 32 bits into the IPv6 prefix is *always* simpler and easier. If an ISP cannot get a prefix shorter than /32 to operate 6rd within, at some point a decision is made between operational complexity of multiple 6rd domains, cost of native IPv6, cost and scalability of stateful tunnels such as TSP or L2TP, all vs. 6rd with a /64 to the customer. What I'm worried about is that the latter will win, and we'll end up with no subnets in the home. A /64 IPv6 service seriously complicates the design of IPv6 in home networks that have more than a single LAN (including those that simply have a "home" and "guest" SSID).... unless we just give up and have the CPE NAT IPv6, which is another real possibility if we let /64 become the least common denominator service to the home. All of this is why I would be in strong support of a policy that would allow a /28 to an ISP that requires 6rd in order to deploy IPv6 to its customer base and actually does so within, say, 6-12 months (the most significant limiting factor outside of the direct control of the ISP would be the CPE itself; ISPs which own their own CPE should have a plan for 6rd in future releases, and those without direct control on the CPE should be able to at least point their customers to a 6rd compatible CPE model if they choose to buy one). This allows an ISP that cannot deploy native IPv6 in the near term to deploy IPv6 with 6rd and still allow at least a /60 to the home, which is far, far, better than /64. It's hard enough to get CPE to do IPv6 correctly, and I would really like to avoid them having to get creative enough to figure out how to do IPv6 with a single /64. As a sidenote: Medium to Large ISPs in the RIPE region are managing to get the space they need for 6rd under existing policies that allow for planning /48s to all sites. As such, the above would effectively end up being a policy change for "smaller" ISPs. To combat fear that the sum of these small ISPs would exhaust all of our v6 address space, we could draw up requirements to identify blocking factors to native IPv6 or 6rd with multiple domains where the alternative would be either no IPv6 or IPv6 with a /64. I'd even go so far as to give preferential treatment to ISPs that can show they will have to resort to CGN deployment before IPv6 could otherwise be deployed. I'd rather avoid all that complexity though. I think a policy of allowing a /28 to an ISP that is going to deploy and support IPv6 to their users within a short period of time (with a threat of taking it back if they don't!), is not a bad way to spend our address space over the next few years (which is another time limit we could put on the policy). From what I can see, I think we could get a pretty good IPv6 adoption return on that investment. - Mark From twilde at cymru.com Fri Feb 25 18:52:16 2011 From: twilde at cymru.com (Tim Wilde) Date: Fri, 25 Feb 2011 11:52:16 -0600 Subject: [address-policy-wg] Re: New IPv4 block allocated to RIPE NCC In-Reply-To: <4D5BF778.50709@ripe.net> References: <4D4FBBDA.8040704@ripe.net> <4D5961A6.6030201@cymru.com> <4D5A73E0.8020804@ripe.net> <4D5AC87D.9060603@cymru.com> <4D5BF778.50709@ripe.net> Message-ID: <4D67EC50.6040908@cymru.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/16/2011 10:12 AM, Andrea Cima wrote: > Historically these pilot prefixes have never been listed in the > delegated-latest file. However I agree with you that they should. > We will add these temporary allocations to the delegated-latest file in > the coming days. Greetings Andrea, Do you have any idea of a timeline for these blocks to be added to the delegated-latest file? I just checked the most recent file and still do not see any allocations within 185/8, including the debogon tests. Thanks, Tim Wilde - -- Tim Wilde, Senior Software Engineer, Team Cymru, Inc. twilde at cymru.com | +1-630-230-5433 | http://www.team-cymru.org/ -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAk1n7FAACgkQluRbRini9tij6QCfSd1h8RgE3CaL69AsncQhooBG T5UAn1LjaVjtoqeQcIDNhWM+X+sdTVey =gWSx -----END PGP SIGNATURE----- From K.Smolderen at edpnet.net Mon Feb 28 10:13:51 2011 From: K.Smolderen at edpnet.net (Kurt Smolderen) Date: Mon, 28 Feb 2011 10:13:51 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD Message-ID: <57AA98804597B540B30CB73408043AD877C78B4A56@SRV-EDPNET-03.edpnet.net> 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 From randy at psg.com Mon Feb 28 10:29:08 2011 From: randy at psg.com (Randy Bush) Date: Mon, 28 Feb 2011 18:29:08 +0900 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <57AA98804597B540B30CB73408043AD877C78B4A56@SRV-EDPNET-03.edpnet.net> References: <57AA98804597B540B30CB73408043AD877C78B4A56@SRV-EDPNET-03.edpnet.net> Message-ID: > 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. only problem is that 6rd is not a transition mechanism. it is an anti-transition mechanism. randy From ahmed at tamkien.com Mon Feb 28 10:42:41 2011 From: ahmed at tamkien.com (Ahmed Abu-Abed) Date: Mon, 28 Feb 2011 11:42:41 +0200 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <57AA98804597B540B30CB73408043AD877C78B4A56@SRV-EDPNET-03.edpnet.net> References: <57AA98804597B540B30CB73408043AD877C78B4A56@SRV-EDPNET-03.edpnet.net> Message-ID: <2B451FEAC0D747228A2B0D3273D17CBF@mTOSH> Greetings, Compared to 6RD, the TSP protocol (RFC 5572) can also rapidly deploy IPv6, needing one /32 allocation while customer site prefixes can be /64, /56 or /48. Reason is TSP doesn't embed the customer's IPv4 address in its IPv6 address as 6RD does. Being a hot topic nowadays, its worth mentioning customer site access gear (CPE) requirements are more relaxed with TSP as it doesn't need the Service Provider IPv4-only access modem to be changed or upgraded. A TSP client can run in a small hardware device (thru an Ethernet interface connection) or a software client in the home network behind the SP modem while enabling all v6 capable nodes with the assigned prefix by automatically establishing a tunnel to the SP TSP tunnel server. Since TSP allows for static prefix assignment and larger prefixes than /64 without wasting v6 space, this would mimic a native deployment more closely. The stateful tunneling could be seen as any other encapsulation in the access, and a few service providers have it running already. In the long term, both 6RD and TSP will give way to reverse tunneling i.e. v4-in-v6, as this is the only way (after IPv4 depletion) for both protocols to co-exist on a host while having a mix of v4-only and dual-stack accessible services/website. Reverse tunneling's current protocols, DS-Lite and DSTM, are very similar to TSP's concept so the same clients & servers supporting TSP can be adapted to support DS-Lite. Unfortunately, until IPv4 disappears from web content, hosts and servers these coexistence mechanisms will be needed. Regards, -Ahmed From: Kurt Smolderen Sent: Monday, February 28, 2011 11:13 AM To: address-policy-wg at ripe.net Subject: RE: [address-policy-wg] IPv6 allocations for 6RD 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahmed at tamkien.com Mon Feb 28 13:44:53 2011 From: ahmed at tamkien.com (Ahmed Abu-Abed) Date: Mon, 28 Feb 2011 14:44:53 +0200 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <57AA98804597B540B30CB73408043AD877C78B4A56@SRV-EDPNET-03.edpnet.net> References: <57AA98804597B540B30CB73408043AD877C78B4A56@SRV-EDPNET-03.edpnet.net> Message-ID: <9FC46597D80C48919ADC9BEBD89A7159@mTOSH> Hi Kurt, If you implement 6RD then an internal network can use multiple /64s, with each /64 coming from one of the few IPv4 public addresses such an internal network uses. And all this happens under one /32 assignment. Note that the /64 limitation is specific to 6RD protocol as I explained in an earlier email. Other transition protocols may not have this limitation. As for native IPv6 deployment, if you mean IPv6-only (i.e. not Dual-Stack) then I doubt it has much use for the coming few years as much of the content and applications are IPv4-only. New translation protocols, to enable IPv6-only host reaching IPv4 content, are being developed but they have their limitations. Even deploying Dual-Stack (DS) end-to-end, without tunneling, is not enough. The logic behind this is content will still be mostly IPv4 for years to come, while public IPv4 addresses are in very short supply. Thus one is forced to use private IPv4 addresses for end users, but these are not routable. The solution is then to tunnel the private IPv4 in public IPv6 addresses, hence DS-Lite protocol. But this assumes you have a full Dual-Stack deployment end-to-end; if not then you need to overlay IPv6 over IPv4 using 6RD, TSP or L2TP as an interim solution. Regards, -Ahmed From: Kurt Smolderen Sent: Monday, February 28, 2011 11:13 AM To: address-policy-wg at ripe.net Subject: RE: [address-policy-wg] IPv6 allocations for 6RD 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Mon Feb 28 15:20:42 2011 From: gert at space.net (Gert Doering) Date: Mon, 28 Feb 2011 15:20:42 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <57AA98804597B540B30CB73408043AD877C78B4A56@SRV-EDPNET-03.edpnet.net> References: <57AA98804597B540B30CB73408043AD877C78B4A56@SRV-EDPNET-03.edpnet.net> Message-ID: <20110228142042.GL30227@Space.Net> Hi, On Mon, Feb 28, 2011 at 10:13:51AM +0100, Kurt Smolderen wrote: > 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. Without commenting on the general idea of allocating a larger chunk of addresses to ISPs, I want to make sure that the underlying facts are presented correctly. While RFC 5569 (the 6rd RFC) takes the "naive" approach of blindly mapping IPv4 <-> IPv6 using the whole 32bits, it doesn't *have* to be that way - the current 6rd work in the IETF (draft-ietf-softwire-ipv6-6rd-10.txt) uses a more flexible approach: ---- quote ---- 6rd allows the SP to adjust the size of the 6rd prefix, how many bits used by the 6rd mechanism, and how many bits are left to be delegated to customer sites. ... For example, if the 6rd prefix is /32 and 24 bits of the CE IPv4 address is used (e.g all CE IPv4 addresses can be aggregated by a 10.0.0.0/8), then the size of the 6rd delegated prefix for each CE is automatically calculated to be /56 (32 + 24 = 56). ---- quote ---- so, depending on the size and fragmentation of the IPv4 address allocations an ISP might have available, he could run fully-functional 6rd with "/60 to end users" in a /36 IPv6 space (by only mapping 24 bits). So what I would like to see added to this discussion is: - what 6rd implementations are there "out in the market" today? (both provider and CPE side) - what approach do they take? "always use 32 bits for mapping" or the configurable approach from the i-d quoted above (IPv4MaskLen > 0)? 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 From K.Smolderen at edpnet.net Mon Feb 28 15:54:11 2011 From: K.Smolderen at edpnet.net (Kurt Smolderen) Date: Mon, 28 Feb 2011 15:54:11 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <9FC46597D80C48919ADC9BEBD89A7159@mTOSH> References: <57AA98804597B540B30CB73408043AD877C78B4A56@SRV-EDPNET-03.edpnet.net> <9FC46597D80C48919ADC9BEBD89A7159@mTOSH> Message-ID: <57AA98804597B540B30CB73408043AD877C78B4B92@SRV-EDPNET-03.edpnet.net> Hi Ahmed, Do I understand correctly that you are actually saying that an organization should base its IPv6 addressing scheme upon its existing (legacy) IPv4 addressing scheme? As this seems to me what one would actually do if you drop native IPv6/ dual-stack implementation "in favor" of 6rd... If this is what you are pointing at, I really have to disagree as I don't believe this is the way to go. IPv6 is different from IPv4 and so a different addressing plan makes sense. So let us give an organization the possibility to do its IPv6 address assignments right from the beginning and let's not force them to get stuck in transition methods (as this will convert them into anti-transition mechanisms as suggested in a previous message in this thread). Regarding your other remarks/ suggestions: 1. I do agree 6rd has its limitations, but on the other hand, an organization might have some perfect good reasons to prefer 6rd above another transition protocol (for instance because it is - in contrary to other transition protocols - fully supported by both the CPE devices as well as the ISP's edge routers). 2. What I actually mean with native IPv6 is dual stack with the IPv6 stack "free of tunnels" (sorry for the confusion). I do realize we cannot neglect the fact IPv4 will be around for a while and thus still needs native support as well. Regards, Kurt From: Ahmed Abu-Abed [mailto:ahmed at tamkien.com] Sent: maandag 28 februari 2011 13:45 To: Kurt Smolderen; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] IPv6 allocations for 6RD Hi Kurt, If you implement 6RD then an internal network can use multiple /64s, with each /64 coming from one of the few IPv4 public addresses such an internal network uses. And all this happens under one /32 assignment. Note that the /64 limitation is specific to 6RD protocol as I explained in an earlier email. Other transition protocols may not have this limitation. As for native IPv6 deployment, if you mean IPv6-only (i.e. not Dual-Stack) then I doubt it has much use for the coming few years as much of the content and applications are IPv4-only. New translation protocols, to enable IPv6-only host reaching IPv4 content, are being developed but they have their limitations. Even deploying Dual-Stack (DS) end-to-end, without tunneling, is not enough. The logic behind this is content will still be mostly IPv4 for years to come, while public IPv4 addresses are in very short supply. Thus one is forced to use private IPv4 addresses for end users, but these are not routable. The solution is then to tunnel the private IPv4 in public IPv6 addresses, hence DS-Lite protocol. But this assumes you have a full Dual-Stack deployment end-to-end; if not then you need to overlay IPv6 over IPv4 using 6RD, TSP or L2TP as an interim solution. Regards, -Ahmed From: Kurt Smolderen Sent: Monday, February 28, 2011 11:13 AM To: address-policy-wg at ripe.net Subject: RE: [address-policy-wg] IPv6 allocations for 6RD 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at townsley.net Mon Feb 28 21:44:49 2011 From: mark at townsley.net (Mark Townsley) Date: Mon, 28 Feb 2011 21:44:49 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <20110228142042.GL30227@Space.Net> References: <57AA98804597B540B30CB73408043AD877C78B4A56@SRV-EDPNET-03.edpnet.net> <20110228142042.GL30227@Space.Net> Message-ID: On Feb 28, 2011, at 3:20 PM, Gert Doering wrote: > Hi, > > On Mon, Feb 28, 2011 at 10:13:51AM +0100, Kurt Smolderen wrote: >> 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. > > Without commenting on the general idea of allocating a larger chunk of > addresses to ISPs, I want to make sure that the underlying facts are > presented correctly. > > While RFC 5569 (the 6rd RFC) takes the "naive" approach of blindly mapping > IPv4 <-> IPv6 using the whole 32bits, it doesn't *have* to be that way - > the current 6rd work in the IETF (draft-ietf-softwire-ipv6-6rd-10.txt) > uses a more flexible approach: Yes! Except that is now published RFC 5969. RFC 5569 (five five six nine) describes the deployment at Free Telecom. RFC 5969 (five nine six nine) describes the IETF standards track protocol spec for 6rd. I really hope that most implementations are using RFC 5969 (certainly the commercial ones I know of are). > > ---- quote ---- > 6rd allows the SP to adjust the size of the 6rd prefix, > how many bits used by the 6rd mechanism, and how many bits are left > to be delegated to customer sites. > ... > For example, if the 6rd prefix is /32 and 24 bits of the CE IPv4 > address is used (e.g all CE IPv4 addresses can be aggregated by a > 10.0.0.0/8), then the size of the 6rd delegated prefix for each CE is > automatically calculated to be /56 (32 + 24 = 56). > ---- quote ---- > > so, depending on the size and fragmentation of the IPv4 address allocations > an ISP might have available, he could run fully-functional 6rd with "/60 to > end users" in a /36 IPv6 space (by only mapping 24 bits). > > > So what I would like to see added to this discussion is: > > - what 6rd implementations are there "out in the market" today? > (both provider and CPE side) For Cisco: Cisco has been shipping a BR (provider) side side since mid-2010. CE-side in IOS products since a few months after that. linksys gear has been part of many SP trials around the world since mid last year, and is expected to appear on retail shelves RSN. > > - what approach do they take? "always use 32 bits for mapping" or > the configurable approach from the i-d quoted above (IPv4MaskLen > 0)? The majority of deployments I have seen use IPv4MaskLen == 0. There is no arguing that provisioning is simpler in this mode. . - Mark > > > 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 > From ahmed at tamkien.com Mon Feb 28 21:45:17 2011 From: ahmed at tamkien.com (Ahmed Abu-Abed) Date: Mon, 28 Feb 2011 22:45:17 +0200 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <57AA98804597B540B30CB73408043AD877C78B4B92@SRV-EDPNET-03.edpnet.net> References: <57AA98804597B540B30CB73408043AD877C78B4A56@SRV-EDPNET-03.edpnet.net> <9FC46597D80C48919ADC9BEBD89A7159@mTOSH> <57AA98804597B540B30CB73408043AD877C78B4B92@SRV-EDPNET-03.edpnet.net> Message-ID: <92F07BE0504E420E9279C73A26238C94@mTOSH> Hi Kurt, In 6RD, part of the IPv6 address takes the IPv4 address of the CPE, so there is an IPv4 dependency but only in the access side. Note that TSP is also supported by CPEs and edge servers solutions. Regards, -Ahmed From: Kurt Smolderen Sent: Monday, February 28, 2011 4:54 PM To: Ahmed Abu-Abed ; address-policy-wg at ripe.net Subject: RE: [address-policy-wg] IPv6 allocations for 6RD Hi Ahmed, Do I understand correctly that you are actually saying that an organization should base its IPv6 addressing scheme upon its existing (legacy) IPv4 addressing scheme? As this seems to me what one would actually do if you drop native IPv6/ dual-stack implementation "in favor" of 6rd. If this is what you are pointing at, I really have to disagree as I don't believe this is the way to go. IPv6 is different from IPv4 and so a different addressing plan makes sense. So let us give an organization the possibility to do its IPv6 address assignments right from the beginning and let's not force them to get stuck in transition methods (as this will convert them into anti-transition mechanisms as suggested in a previous message in this thread). Regarding your other remarks/ suggestions: 1. I do agree 6rd has its limitations, but on the other hand, an organization might have some perfect good reasons to prefer 6rd above another transition protocol (for instance because it is - in contrary to other transition protocols - fully supported by both the CPE devices as well as the ISP's edge routers). 2. What I actually mean with native IPv6 is dual stack with the IPv6 stack "free of tunnels" (sorry for the confusion). I do realize we cannot neglect the fact IPv4 will be around for a while and thus still needs native support as well. Regards, Kurt From: Ahmed Abu-Abed [mailto:ahmed at tamkien.com] Sent: maandag 28 februari 2011 13:45 To: Kurt Smolderen; address-policy-wg at ripe.net Subject: Re: [address-policy-wg] IPv6 allocations for 6RD Hi Kurt, If you implement 6RD then an internal network can use multiple /64s, with each /64 coming from one of the few IPv4 public addresses such an internal network uses. And all this happens under one /32 assignment. Note that the /64 limitation is specific to 6RD protocol as I explained in an earlier email. Other transition protocols may not have this limitation. As for native IPv6 deployment, if you mean IPv6-only (i.e. not Dual-Stack) then I doubt it has much use for the coming few years as much of the content and applications are IPv4-only. New translation protocols, to enable IPv6-only host reaching IPv4 content, are being developed but they have their limitations. Even deploying Dual-Stack (DS) end-to-end, without tunneling, is not enough. The logic behind this is content will still be mostly IPv4 for years to come, while public IPv4 addresses are in very short supply. Thus one is forced to use private IPv4 addresses for end users, but these are not routable. The solution is then to tunnel the private IPv4 in public IPv6 addresses, hence DS-Lite protocol. But this assumes you have a full Dual-Stack deployment end-to-end; if not then you need to overlay IPv6 over IPv4 using 6RD, TSP or L2TP as an interim solution. Regards, -Ahmed From: Kurt Smolderen Sent: Monday, February 28, 2011 11:13 AM To: address-policy-wg at ripe.net Subject: RE: [address-policy-wg] IPv6 allocations for 6RD 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at townsley.net Mon Feb 28 22:23:33 2011 From: mark at townsley.net (Mark Townsley) Date: Mon, 28 Feb 2011 22:23:33 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <2B451FEAC0D747228A2B0D3273D17CBF@mTOSH> References: <57AA98804597B540B30CB73408043AD877C78B4A56@SRV-EDPNET-03.edpnet.net> <2B451FEAC0D747228A2B0D3273D17CBF@mTOSH> Message-ID: <7FDB97C0-64F5-4801-A75E-FC2DB7B2D9CD@townsley.net> On Feb 28, 2011, at 10:42 AM, Ahmed Abu-Abed wrote: > Greetings, > > Compared to 6RD, the TSP protocol (RFC 5572) can also rapidly deploy IPv6, needing one /32 allocation while customer site prefixes can be /64, /56 or /48. Reason is TSP doesn't embed the customer's IPv4 address in its IPv6 address as 6RD does. TSP is stateful, and thus scales in proportion to the number of subscriber endpoints supported as opposed to simply the number of IPv6 packets transported (e.g., TSP servers will likely have a "per-user" license or at least a per-user scaling limit per box. In contrast, 6rd has no concept of the number of users it is supporting, only the number of packets it is pushing). - Mark > > Being a hot topic nowadays, its worth mentioning customer site access gear (CPE) requirements are more relaxed with TSP as it doesn't need the Service Provider IPv4-only access modem to be changed or upgraded. A TSP client can run in a small hardware device (thru an Ethernet interface connection) or a software client in the home network behind the SP modem while enabling all v6 capable nodes with the assigned prefix by automatically establishing a tunnel to the SP TSP tunnel server. > > Since TSP allows for static prefix assignment and larger prefixes than /64 without wasting v6 space, this would mimic a native deployment more closely. The stateful tunneling could be seen as any other encapsulation in the access, and a few service providers have it running already. > > In the long term, both 6RD and TSP will give way to reverse tunneling i.e. v4-in-v6, as this is the only way (after IPv4 depletion) for both protocols to co-exist on a host while having a mix of v4-only and dual-stack accessible services/website. Reverse tunneling's current protocols, DS-Lite and DSTM, are very similar to TSP's concept so the same clients & servers supporting TSP can be adapted to support DS-Lite. > > Unfortunately, until IPv4 disappears from web content, hosts and servers these coexistence mechanisms will be needed. > > Regards, > -Ahmed > > > From: Kurt Smolderen > Sent: Monday, February 28, 2011 11:13 AM > To: address-policy-wg at ripe.net > Subject: RE: [address-policy-wg] IPv6 allocations for 6RD > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: