From shane at time-travellers.org Wed Nov 4 04:09:55 2009 From: shane at time-travellers.org (Shane Kerr) Date: Wed, 04 Nov 2009 04:09:55 +0100 Subject: [ipv6-wg] Proposal for new charter: Version 2 Message-ID: <1257304195.19704.1606.camel@shane-asus-laptop> All, I've tried to combine all of the input and comments and produce a version of the text which hopefully includes all suggestions. Hopefully it is not too long: ----------------------------------------------------------------------- IPv6 is the next-generation IP protocol. The IPv6 working group exists to promote IPv6 adoption. The working group activities may be anything useful in helping people to deploy IPv6, and to manage IPv4/IPv6 co-existence. These activities include: * Outreach * Education * Sharing deployment experiences * Discussing operational issues The working group will co-operate within the networking industry and without, to share resources and combine efforts. ----------------------------------------------------------------------- Changes: * The 2nd paragraph was updated as per Sander's input. * I took David's point and removed "co-operation" as a activity, since as he indicated it is quite vague without the explanation. Instead I added the sentence at the end there. The idea is to make sure that we note that we have a goal of not duplicating work, but rather use the good stuff that other IPv6 and non-IPv6 organizations have done. If this doesn't make sense in the charter, we can of course leave it out. * I added David's activity about sharing deployment experiences - it seems to make sense. * I added a slightly modified activity based on David's last new one. His was "propose solutions for operational issues". I would rather see this as a more general discussion of operational issues - presumably solutions will be proposed where appropriate. If we want to focus on solutions, then we can revert to David's idea about proposing solutions. I think we are very close, and hopefully people are happy with this one. I don't have any objection to further modifications, although I am looking forward to moving past the rechartering and getting to some planning of what to do with the new-found working group super-powers! :) -- Shane From michael.dillon at bt.com Wed Nov 4 12:55:20 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 4 Nov 2009 11:55:20 -0000 Subject: [ipv6-wg] Proposal for new charter: Version 2 In-Reply-To: <1257304195.19704.1606.camel@shane-asus-laptop> Message-ID: <28E139F46D45AF49A31950F88C49745803E4F970@E03MVZ2-UKDY.domain1.systemhost.net> > IPv6 is the next-generation IP protocol. The IPv6 working > group exists to promote IPv6 adoption. > > The working group activities may be anything useful in > helping people to deploy IPv6, and to manage IPv4/IPv6 > co-existence. These activities > include: > > * Outreach > * Education > * Sharing deployment experiences > * Discussing operational issues > > The working group will co-operate within the networking > industry and without, to share resources and combine efforts. This is good. Clear, concise, and still targeted enough to give the group focus. --Michael Dillon From us at sweet-sorrow.com Wed Nov 4 13:58:29 2009 From: us at sweet-sorrow.com (Us) Date: Wed, 04 Nov 2009 12:58:29 +0000 Subject: [ipv6-wg] Proposal for new charter: Version 2 In-Reply-To: <28E139F46D45AF49A31950F88C49745803E4F970@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745803E4F970@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4AF17A75.6030604@sweet-sorrow.com> michael.dillon at bt.com wrote: >> IPv6 is the next-generation IP protocol. The IPv6 working >> group exists to promote IPv6 adoption. >> >> The working group activities may be anything useful in >> helping people to deploy IPv6, and to manage IPv4/IPv6 >> co-existence. These activities >> include: >> >> * Outreach >> * Education >> * Sharing deployment experiences >> * Discussing operational issues >> >> The working group will co-operate within the networking >> industry and without, to share resources and combine efforts. > > This is good. Clear, concise, and still targeted enough to give the > group focus. > > --Michael Dillon > > Agreed, nice summary. Ragnar Belial Us From Ralph.Smit at nxs.nl Wed Nov 4 14:57:39 2009 From: Ralph.Smit at nxs.nl (Ralph Smit) Date: Wed, 4 Nov 2009 14:57:39 +0100 Subject: [ipv6-wg] Proposal for new charter: Version 2 In-Reply-To: <1257304195.19704.1606.camel@shane-asus-laptop> References: <1257304195.19704.1606.camel@shane-asus-laptop> Message-ID: Hello List, I think Shane did a very good job. I support this version. Ralph. -----Original Message----- From: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] On Behalf Of Shane Kerr Sent: woensdag 4 november 2009 4:10 To: ipv6-wg Subject: [ipv6-wg] Proposal for new charter: Version 2 All, I've tried to combine all of the input and comments and produce a version of the text which hopefully includes all suggestions. Hopefully it is not too long: ----------------------------------------------------------------------- IPv6 is the next-generation IP protocol. The IPv6 working group exists to promote IPv6 adoption. The working group activities may be anything useful in helping people to deploy IPv6, and to manage IPv4/IPv6 co-existence. These activities include: * Outreach * Education * Sharing deployment experiences * Discussing operational issues The working group will co-operate within the networking industry and without, to share resources and combine efforts. ----------------------------------------------------------------------- Changes: * The 2nd paragraph was updated as per Sander's input. * I took David's point and removed "co-operation" as a activity, since as he indicated it is quite vague without the explanation. Instead I added the sentence at the end there. The idea is to make sure that we note that we have a goal of not duplicating work, but rather use the good stuff that other IPv6 and non-IPv6 organizations have done. If this doesn't make sense in the charter, we can of course leave it out. * I added David's activity about sharing deployment experiences - it seems to make sense. * I added a slightly modified activity based on David's last new one. His was "propose solutions for operational issues". I would rather see this as a more general discussion of operational issues - presumably solutions will be proposed where appropriate. If we want to focus on solutions, then we can revert to David's idea about proposing solutions. I think we are very close, and hopefully people are happy with this one. I don't have any objection to further modifications, although I am looking forward to moving past the rechartering and getting to some planning of what to do with the new-found working group super-powers! :) -- Shane From marcoh at marcoh.net Wed Nov 4 15:04:41 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Wed, 4 Nov 2009 15:04:41 +0100 Subject: [ipv6-wg] Proposal for new charter: Version 2 In-Reply-To: References: <1257304195.19704.1606.camel@shane-asus-laptop> Message-ID: <84E5E4F9-DA81-4528-ABBA-D64D2C25B9B0@marcoh.net> On 4 nov 2009, at 14:57, Ralph Smit wrote: > Hello List, > > I think Shane did a very good job. > I support this version. > > Ralph. Hate to do it this way, but "me too!!" Good job Shane. Groet, MarcoH From sander at steffann.nl Wed Nov 4 15:50:56 2009 From: sander at steffann.nl (Sander Steffann) Date: Wed, 4 Nov 2009 15:50:56 +0100 (CET) Subject: [ipv6-wg] Proposal for new charter: Version 2 In-Reply-To: <1257304195.19704.1606.camel@shane-asus-laptop> References: <1257304195.19704.1606.camel@shane-asus-laptop> Message-ID: <1357.80.101.103.96.1257346256.squirrel@webmail.sintact.nl> Hi Shane, > ----------------------------------------------------------------------- > IPv6 is the next-generation IP protocol. The IPv6 working group exists > to promote IPv6 adoption. > > The working group activities may be anything useful in helping people > to deploy IPv6, and to manage IPv4/IPv6 co-existence. These activities > include: > > * Outreach > * Education > * Sharing deployment experiences > * Discussing operational issues > > The working group will co-operate within the networking industry and > without, to share resources and combine efforts. > ----------------------------------------------------------------------- Good job! Thank you, Sander From Ragnar.Anfinsen at altibox.no Wed Nov 4 16:01:56 2009 From: Ragnar.Anfinsen at altibox.no (Anfinsen, Ragnar) Date: Wed, 4 Nov 2009 16:01:56 +0100 Subject: SV: [ipv6-wg] Proposal for new charter: Version 2 In-Reply-To: <1257304195.19704.1606.camel@shane-asus-laptop> References: <1257304195.19704.1606.camel@shane-asus-laptop> Message-ID: I like it. And support it. Best Regards? Ragnar Anfinsen Altibox AS? Network Engineer? Phone +47 51 90 80 00? Phone?direct +47 51 90?82?35 Mobile +47 93 48 82?35 E-mail:?ragnar.anfinsen at altibox.no www.altibox.no www.lyse.no -----Opprinnelig melding----- Fra: ipv6-wg-admin at ripe.net [mailto:ipv6-wg-admin at ripe.net] P? vegne av Shane Kerr Sendt: 4. november 2009 04:10 Til: ipv6-wg Emne: [ipv6-wg] Proposal for new charter: Version 2 All, I've tried to combine all of the input and comments and produce a version of the text which hopefully includes all suggestions. Hopefully it is not too long: ----------------------------------------------------------------------- IPv6 is the next-generation IP protocol. The IPv6 working group exists to promote IPv6 adoption. The working group activities may be anything useful in helping people to deploy IPv6, and to manage IPv4/IPv6 co-existence. These activities include: * Outreach * Education * Sharing deployment experiences * Discussing operational issues The working group will co-operate within the networking industry and without, to share resources and combine efforts. ----------------------------------------------------------------------- Changes: * The 2nd paragraph was updated as per Sander's input. * I took David's point and removed "co-operation" as a activity, since as he indicated it is quite vague without the explanation. Instead I added the sentence at the end there. The idea is to make sure that we note that we have a goal of not duplicating work, but rather use the good stuff that other IPv6 and non-IPv6 organizations have done. If this doesn't make sense in the charter, we can of course leave it out. * I added David's activity about sharing deployment experiences - it seems to make sense. * I added a slightly modified activity based on David's last new one. His was "propose solutions for operational issues". I would rather see this as a more general discussion of operational issues - presumably solutions will be proposed where appropriate. If we want to focus on solutions, then we can revert to David's idea about proposing solutions. I think we are very close, and hopefully people are happy with this one. I don't have any objection to further modifications, although I am looking forward to moving past the rechartering and getting to some planning of what to do with the new-found working group super-powers! :) -- Shane From spz at serpens.de Wed Nov 4 18:14:39 2009 From: spz at serpens.de (S.P.Zeidler) Date: Wed, 4 Nov 2009 18:14:39 +0100 Subject: [ipv6-wg] Proposal for new charter: Version 2 In-Reply-To: <1257304195.19704.1606.camel@shane-asus-laptop> References: <1257304195.19704.1606.camel@shane-asus-laptop> Message-ID: <20091104171438.GB10416@serpens.de> Hi Shane, Thus wrote Shane Kerr (shane at time-travellers.org): > Hopefully > it is not too long: 14 lines.. that should fit most terminals in one page ;-P > * I added a slightly modified activity based on David's last new > one. His was "propose solutions for operational issues". I would > rather see this as a more general discussion of operational > issues - presumably solutions will be proposed where > appropriate. If we want to focus on solutions, then we can > revert to David's idea about proposing solutions. I think 'discussion' is better than focussing on 'solutions' only, because sometimes you don't have a solution, but only the choice which bear trap to stick your foot in, and knowing there is such a trade ahead can be very valuable indeed. In short, I like. :) regards, spz -- spz at serpens.de (S.P.Zeidler) From jan at go6.si Wed Nov 4 18:56:23 2009 From: jan at go6.si (Jan Zorz @ go6.si) Date: Wed, 04 Nov 2009 18:56:23 +0100 Subject: [ipv6-wg] Proposal for new charter: Version 2 In-Reply-To: <1257304195.19704.1606.camel@shane-asus-laptop> References: <1257304195.19704.1606.camel@shane-asus-laptop> Message-ID: <4AF1C047.2080105@go6.si> > ----------------------------------------------------------------------- > IPv6 is the next-generation IP protocol. The IPv6 working group exists > to promote IPv6 adoption. > > The working group activities may be anything useful in helping people > to deploy IPv6, and to manage IPv4/IPv6 co-existence. These activities > include: > > * Outreach > * Education > * Sharing deployment experiences > * Discussing operational issues > > The working group will co-operate within the networking industry and > without, to share resources and combine efforts. > ----------------------------------------------------------------------- Agree with full support. :) Jan Zorz From david.kessens at nsn.com Thu Nov 5 07:54:46 2009 From: david.kessens at nsn.com (David Kessens) Date: Wed, 4 Nov 2009 22:54:46 -0800 Subject: [ipv6-wg] Proposal for new charter: Version 2 In-Reply-To: <1257304195.19704.1606.camel@shane-asus-laptop> References: <1257304195.19704.1606.camel@shane-asus-laptop> Message-ID: <20091105065445.GD2737@nsn.com> Shane, Please see below for a few comments in my role as a private individual contributor to this working group: I think that this version captures the comments on the list quite well and I can support this version as-is. I do think that a tiny bit of polishing could make the charter say the same thing but make it a bit smoother worded and professional looking, especially for people who read our charter but who are not directly involved in the industry as a network operator: On Wed, Nov 04, 2009 at 04:09:55AM +0100, Shane Kerr wrote: > IPv6 is the next-generation IP protocol. I don't think there should be a '-' between 'next' and 'generation'. > The IPv6 working group exists to promote IPv6 adoption. I used the word 'advance' instead of 'promote' in my text as I was looking for a different word than 'further' but that had a similar meaning. I don't think there is anything wrong with the word 'promote' but I have a somewhat ambivalent attitude towards 'promoters/marketers/sales people'. Is there another alternative like 'advance' that doesn't cause such associations (what about 'encourages') ? > The working group activities may be anything useful in helping people > to deploy IPv6, and to manage IPv4/IPv6 co-existence. The core of this sentence just sounds a bit unpolished: 'may be anything useful in helping people to deploy IPv6', In my earlier proposed text I replaced that with: 'cover anything that facilitates the deployment of IPv6' making it 'The working group activities cover anything that facilitates the deployment of IPv6,' I am sure that there are many other options. Another one could be: The working group discusses all topics that stimulate the deployment of IPv6 and that support the co-existence of IPv6 and IPv4. The current sentence just doesn't read that well. In addition, as written, > * Sharing deployment experiences > * Discussing operational issues are not the same but end up being the same thing in practise. I would prefer a bit stronger wording than just 'discuss' to support Geert Jan's case and to encourage ourselves to actually do something about a problem instead of just discussing it. > The working group will co-operate within the networking industry and I prefer the spelling for cooperate without a '-' (just like the 'cooperation working group' spells the word ;-)). Note that the list of comments sounds quite long since I tried to give a few alternatives but that most issues brought up are fairly straightforward to fix. I hope this helps, David Kessens --- From fm at st-kilda.org Thu Nov 5 10:38:05 2009 From: fm at st-kilda.org (Fearghas McKay) Date: Thu, 5 Nov 2009 09:38:05 +0000 Subject: [ipv6-wg] Proposal for new charter: Version 2 In-Reply-To: <1257304195.19704.1606.camel@shane-asus-laptop> References: <1257304195.19704.1606.camel@shane-asus-laptop> Message-ID: <12A0F7CA-31B9-473C-A67B-EAA8AA12B2C6@st-kilda.org> Shane On 4 Nov 2009, at 03:09, Shane Kerr wrote: Looks good. > The working group will co-operate within the networking industry and > without, to share resources and combine efforts. My only nitpick would be the use of within and without - without is not really in common useage. Perhaps: The working group will co-operate with both the networking industry and the wider internet (or perhaps user?) community, to share resources and combine efforts. HTH f From joao at bondis.org Sat Nov 7 07:53:45 2009 From: joao at bondis.org (joao damas) Date: Sat, 7 Nov 2009 14:53:45 +0800 Subject: [ipv6-wg] Proposal for new charter: Version 2 In-Reply-To: <1257304195.19704.1606.camel@shane-asus-laptop> References: <1257304195.19704.1606.camel@shane-asus-laptop> Message-ID: <8774A4B3-8743-43A7-904E-69DE0949DB3B@bondis.org> coming in late due to travel but wanted to add a "me too!" to previous support for this text Joao On 4 Nov 2009, at 11:09, Shane Kerr wrote: > All, > > I've tried to combine all of the input and comments and produce a > version of the text which hopefully includes all suggestions. > Hopefully > it is not too long: > > ----------------------------------------------------------------------- > IPv6 is the next-generation IP protocol. The IPv6 working group exists > to promote IPv6 adoption. > > The working group activities may be anything useful in helping people > to deploy IPv6, and to manage IPv4/IPv6 co-existence. These activities > include: > > * Outreach > * Education > * Sharing deployment experiences > * Discussing operational issues > > The working group will co-operate within the networking industry and > without, to share resources and combine efforts. > ----------------------------------------------------------------------- > > Changes: > > * The 2nd paragraph was updated as per Sander's input. > * I took David's point and removed "co-operation" as a activity, > since as he indicated it is quite vague without the > explanation. > Instead I added the sentence at the end there. The idea is to > make sure that we note that we have a goal of not duplicating > work, but rather use the good stuff that other IPv6 and non- > IPv6 > organizations have done. If this doesn't make sense in the > charter, we can of course leave it out. > * I added David's activity about sharing deployment experiences - > it seems to make sense. > * I added a slightly modified activity based on David's last new > one. His was "propose solutions for operational issues". I > would > rather see this as a more general discussion of operational > issues - presumably solutions will be proposed where > appropriate. If we want to focus on solutions, then we can > revert to David's idea about proposing solutions. > > I think we are very close, and hopefully people are happy with this > one. > I don't have any objection to further modifications, although I am > looking forward to moving past the rechartering and getting to some > planning of what to do with the new-found working group super- > powers! :) > > -- > Shane > From mtinka at globaltransit.net Sat Nov 7 08:34:54 2009 From: mtinka at globaltransit.net (Mark Tinka) Date: Sat, 7 Nov 2009 15:34:54 +0800 Subject: [ipv6-wg] Proposal for new charter: Version 2 In-Reply-To: <12A0F7CA-31B9-473C-A67B-EAA8AA12B2C6@st-kilda.org> References: <1257304195.19704.1606.camel@shane-asus-laptop> <12A0F7CA-31B9-473C-A67B-EAA8AA12B2C6@st-kilda.org> Message-ID: <200911071534.55721.mtinka@globaltransit.net> On Thursday 05 November 2009 05:38:05 pm Fearghas McKay wrote: > > The working group will co-operate within the networking > > industry and without, to share resources and combine > > efforts. > > My only nitpick would be the use of within and without - > without is not really in common useage. I'd humbly propose that, in this case, rather than "without", we could use "outside of", to fully read: The working group will co-operate within the networking industry, as well as outside of it, to share resources and combine efforts. OR The working group will co-operate within and outside of the networking industry, to share resources and combine efforts. Cheers, Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: From training at ripe.net Tue Nov 10 16:45:46 2009 From: training at ripe.net (Training Mailbox) Date: Tue, 10 Nov 2009 16:45:46 +0100 Subject: [ipv6-wg] Announcement: RIPE NCC Training Courses Message-ID: <4AF98AAA.8010502@ripe.net> [Apologies for duplicate e-mails] Dear Colleagues, The RIPE NCC invites you to register for one of our upcoming training courses: - The LIR Training Course This course teaches LIRs how to request Internet number resources and interact with the RIPE NCC. A course outline is available at: http://www.ripe.net/training/lir/outline.html - The Routing Registry Training Course This course teaches LIRs how to use the RIPE Database for routing. A course outline is available at: http://www.ripe.net/training/rr/outline.html - The IPv6 Training Course This course teaches LIRs about the need for IPv6 and includes basic information on how to plan your deployment. A course outline is available at: http://www.ripe.net/training/ipv6/outline.html To see the location of upcoming courses and to register, please use the LIR Portal or complete the registration form on our website at: RIPE NCC Upcoming Courses List & Registration https://lirportal.ripe.net/lirportal/training/course-list.html If you have any questions, please do not hesitate to contact us at . Kind regards, Rumy Kanis Training Services Manager RIPE NCC From jan at go6.si Tue Nov 24 13:01:04 2009 From: jan at go6.si (Jan Zorz @ go6.si) Date: Tue, 24 Nov 2009 13:01:04 +0100 Subject: [ipv6-wg] Proposal for new charter: Version 2 In-Reply-To: <200911071534.55721.mtinka@globaltransit.net> References: <1257304195.19704.1606.camel@shane-asus-laptop> <12A0F7CA-31B9-473C-A67B-EAA8AA12B2C6@st-kilda.org> <200911071534.55721.mtinka@globaltransit.net> Message-ID: <4B0BCB00.3060007@go6.si> Hi @all. Is this thread on-hold? thnx, Jan From david.kessens at nsn.com Tue Nov 24 17:52:20 2009 From: david.kessens at nsn.com (David Kessens) Date: Tue, 24 Nov 2009 08:52:20 -0800 Subject: [ipv6-wg] Proposal for new charter: Version 2 In-Reply-To: <4B0BCB00.3060007@go6.si> References: <1257304195.19704.1606.camel@shane-asus-laptop> <12A0F7CA-31B9-473C-A67B-EAA8AA12B2C6@st-kilda.org> <200911071534.55721.mtinka@globaltransit.net> <4B0BCB00.3060007@go6.si> Message-ID: <20091124165220.GB3585@nsn.com> Jan, On Tue, Nov 24, 2009 at 01:01:04PM +0100, Jan Zorz @ go6.si wrote: > > Is this thread on-hold? Both me and Shane have been very busy due to the IETF this month. We did discuss the charter during the IETF and you should see mail from Shane soon. David Kessens --- From boogman at ip-plus.net Wed Nov 25 16:44:23 2009 From: boogman at ip-plus.net (Jan Boogman) Date: Wed, 25 Nov 2009 16:44:23 +0100 Subject: [ipv6-wg] IPv6 allocations for 6RD Message-ID: Hi, we are planning to offer IPv6 connectivity to our xDSL and FTTH customer base via IPv6-6RD. (see or for a working implementation Free's presentation at RIPE-58: ). We asked RIPE NCC for a larger than /32 allocation (because of the way how 6RD encapsulates the customers IPv4 address in his IPv6 address and also because we want to give the customer a small subnet). The IPRA now isn't sure how to proceed and after consultation with the Policy Development Manager asked me to pose the question to the community at large. What do you think, should RIPE NCC allocate larger than /32 blocks to LIRs for cases like this and not only based on the number of end-customers? Cheers Jan Swisscom IP-Plus - AS3303 From sander at steffann.nl Wed Nov 25 17:02:12 2009 From: sander at steffann.nl (Sander Steffann) Date: Wed, 25 Nov 2009 17:02:12 +0100 (CET) Subject: [ipv6-wg] Re: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: Message-ID: <1484.80.101.103.96.1259164932.squirrel@webmail.sintact.nl> Hi Jan, > We asked RIPE NCC for a larger than /32 allocation (because of the way how > 6RD encapsulates the customers IPv4 address in his IPv6 address and also > because we want to give the customer a small subnet). In draft-townsley-ipv6-6rd-01 the following example is given: This example show how the 6rd prefix is created based on a /32 IPv6 prefix with a private IPv4 address were the first octet is "compressed" out: SP prefix: 2001:0DB8::/32 6rd IPv4 prefix: 10.0.0.0/8 6rd router IPv4 address: 10.100.100.1 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56 With this scheme you can still give every customer out of an IPv4 /8 an IPv6 /56 subnet. If you have an IPv4 /16 with customers you could "compress" so that every customer has an IPv6 /48. And if you have more than 65k customers you should have no problem with getting a bigger IPv6 allocation. Because the IPRA refuses to give you more addresses based on your customer base I suspect that you have less than 65k customers. With a smart IPv4 <--> IPv6-RD mapping that should not be a problem for IPv6-RD. Can you give some extra background information that explains why you need more than a /32? - Sander From boogman at ip-plus.net Wed Nov 25 17:12:36 2009 From: boogman at ip-plus.net (Jan Boogman) Date: Wed, 25 Nov 2009 17:12:36 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <1484.80.101.103.96.1259164932.squirrel@webmail.sintact.nl> References: <1484.80.101.103.96.1259164932.squirrel@webmail.sintact.nl> Message-ID: <78B046C9-9108-46A7-BA93-7CFB21C5CE5D@ip-plus.net> Hi Sander >> We asked RIPE NCC for a larger than /32 allocation (because of the way how >> 6RD encapsulates the customers IPv4 address in his IPv6 address and also >> because we want to give the customer a small subnet). > > In draft-townsley-ipv6-6rd-01 the following example is given: > > This example show how the 6rd prefix is created based on a /32 IPv6 prefix > with a private IPv4 address were the first octet is "compressed" out: > SP prefix: 2001:0DB8::/32 > 6rd IPv4 prefix: 10.0.0.0/8 > 6rd router IPv4 address: 10.100.100.1 > 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56 > > With this scheme you can still give every customer out of an IPv4 /8 an > IPv6 /56 subnet. If you have an IPv4 /16 with customers you could > "compress" so that every customer has an IPv6 /48. And if you have more > than 65k customers you should have no problem with getting a bigger IPv6 > allocation. > > Because the IPRA refuses to give you more addresses based on your customer > base I suspect that you have less than 65k customers. With a smart IPv4 > <--> IPv6-RD mapping that should not be a problem for IPv6-RD. > > Can you give some extra background information that explains why you need > more than a /32? we have much more than 65k customers, with IPv4 addresses dispersed in many different /8 We therefore cannot easily compress the IPv4 address and want to use the whole 32bit. However, we plan to allocate only a /60 subnet to the end customer. This results in a request for a /28 Jan From florian at frotzler.priv.at Wed Nov 25 17:27:27 2009 From: florian at frotzler.priv.at (Florian Frotzler) Date: Wed, 25 Nov 2009 17:27:27 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <1484.80.101.103.96.1259164932.squirrel@webmail.sintact.nl> References: <1484.80.101.103.96.1259164932.squirrel@webmail.sintact.nl> Message-ID: <966645c70911250827o5c86236cx4a8bf05ecac240d5@mail.gmail.com> Hi Sander, It is clearly stated in the draft that you can only aggregate IPv4 address space if there is a common prefix, like "10" in 10.0.0.0/8. If you use public address space this is not possible and you are forced to use all 32 bits. If you have an SP prefix of 32 bits and 32 bits for the IPv4 address you end up having none for subnetting. So yes, Swisscom needs more than a /32. But... Free.fr got a /26, as they state in their RIPE-58 presentation, so they obviously could argument their need for the address space in front of RIPE. This leaves two flows to follow... -> either it depends on who from the hostmasters is dealing with your allocation request, because why would RIPE deal with Swisscom different than with free.fr? -> or Swisscom could not argue the need to RIPE in the same way as free.fr? Maybe someone from RIPE can clarify this. Cheers, Florian 2009/11/25 Sander Steffann : > Hi Jan, > >> We asked RIPE NCC for a larger than /32 allocation (because of the way how >> 6RD encapsulates the customers IPv4 address in his IPv6 address and also >> because we want to give the customer a small subnet). > > In draft-townsley-ipv6-6rd-01 the following example is given: > > This example show how the 6rd prefix is created based on a /32 IPv6 prefix > with a private IPv4 address were the first octet is "compressed" out: > ?SP prefix: 2001:0DB8::/32 > ?6rd IPv4 prefix: 10.0.0.0/8 > ?6rd router IPv4 address: 10.100.100.1 > ?6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56 > > With this scheme you can still give every customer out of an IPv4 /8 an > IPv6 /56 subnet. If you have an IPv4 /16 with customers you could > "compress" so that every customer has an IPv6 /48. And if you have more > than 65k customers you should have no problem with getting a bigger IPv6 > allocation. > > Because the IPRA refuses to give you more addresses based on your customer > base I suspect that you have less than 65k customers. With a smart IPv4 > <--> IPv6-RD mapping that should not be a problem for IPv6-RD. > > Can you give some extra background information that explains why you need > more than a /32? > > - Sander > > > From sander at steffann.nl Wed Nov 25 17:35:06 2009 From: sander at steffann.nl (Sander Steffann) Date: Wed, 25 Nov 2009 17:35:06 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] IPv6 allocations for 6RD Message-ID: <78B046C9-9108-46A7-BA93-7CFB21C5CE5D@ip-plus.net> Hi Jan, With that many customers getting more than a /32 shouldn't be any problem... Why did the IPRA refuse it? This might just be a misunderstanding somewhere... Sander Jan Boogman schreef: >Hi Sander > >>> We asked RIPE NCC for a larger than /32 allocation (because of the way how >>> 6RD encapsulates the customers IPv4 address in his IPv6 address and also >>> because we want to give the customer a small subnet). >> >> In draft-townsley-ipv6-6rd-01 the following example is given: >> >> This example show how the 6rd prefix is created based on a /32 IPv6 prefix >> with a private IPv4 address were the first octet is "compressed" out: >> SP prefix: 2001:0DB8::/32 >> 6rd IPv4 prefix: 10.0.0.0/8 >> 6rd router IPv4 address: 10.100.100.1 >> 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56 >> >> With this scheme you can still give every customer out of an IPv4 /8 an >> IPv6 /56 subnet. If you have an IPv4 /16 with customers you could >> "compress" so that every customer has an IPv6 /48. And if you have more >> than 65k customers you should have no problem with getting a bigger IPv6 >> allocation. > >> >> Because the IPRA refuses to give you more addresses based on your customer >> base I suspect that you have less than 65k customers. With a smart IPv4 >> <--> IPv6-RD mapping that should not be a problem for IPv6-RD. >> >> Can you give some extra background information that explains why you need >> more than a /32? > >we have much more than 65k customers, with IPv4 addresses dispersed in many different /8 >We therefore cannot easily compress the IPv4 address and want to use the whole 32bit. >However, we plan to allocate only a /60 subnet to the end customer. >This results in a request for a /28 > >Jan From boogman at ip-plus.net Wed Nov 25 17:40:42 2009 From: boogman at ip-plus.net (Jan Boogman) Date: Wed, 25 Nov 2009 17:40:42 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <78B046C9-9108-46A7-BA93-7CFB21C5CE5D@ip-plus.net> References: <78B046C9-9108-46A7-BA93-7CFB21C5CE5D@ip-plus.net> Message-ID: Hi Sander he didn't refuse it, yet. He asked me to get to the wg because he was unsure if this scenario is in the spirit of the RIPE policies. Cheers Jan Am 25.11.2009 um 17:35 schrieb Sander Steffann: > Hi Jan, > > With that many customers getting more than a /32 shouldn't be any problem... Why did the IPRA refuse it? This might just be a misunderstanding somewhere... > > Sander > > Jan Boogman schreef: > >> Hi Sander >> >>>> We asked RIPE NCC for a larger than /32 allocation (because of the way how >>>> 6RD encapsulates the customers IPv4 address in his IPv6 address and also >>>> because we want to give the customer a small subnet). >>> >>> In draft-townsley-ipv6-6rd-01 the following example is given: >>> >>> This example show how the 6rd prefix is created based on a /32 IPv6 prefix >>> with a private IPv4 address were the first octet is "compressed" out: >>> SP prefix: 2001:0DB8::/32 >>> 6rd IPv4 prefix: 10.0.0.0/8 >>> 6rd router IPv4 address: 10.100.100.1 >>> 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56 >>> >>> With this scheme you can still give every customer out of an IPv4 /8 an >>> IPv6 /56 subnet. If you have an IPv4 /16 with customers you could >>> "compress" so that every customer has an IPv6 /48. And if you have more >>> than 65k customers you should have no problem with getting a bigger IPv6 >>> allocation. >> >>> >>> Because the IPRA refuses to give you more addresses based on your customer >>> base I suspect that you have less than 65k customers. With a smart IPv4 >>> <--> IPv6-RD mapping that should not be a problem for IPv6-RD. >>> >>> Can you give some extra background information that explains why you need >>> more than a /32? >> >> we have much more than 65k customers, with IPv4 addresses dispersed in many different /8 >> We therefore cannot easily compress the IPv4 address and want to use the whole 32bit. >> However, we plan to allocate only a /60 subnet to the end customer. >> This results in a request for a /28 >> >> Jan From sander at steffann.nl Wed Nov 25 22:09:11 2009 From: sander at steffann.nl (Sander Steffann) Date: Wed, 25 Nov 2009 22:09:11 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <966645c70911250827o5c86236cx4a8bf05ecac240d5@mail.gmail.com> References: <1484.80.101.103.96.1259164932.squirrel@webmail.sintact.nl> <966645c70911250827o5c86236cx4a8bf05ecac240d5@mail.gmail.com> Message-ID: Hi Florian, > It is clearly stated in the draft that you can only aggregate IPv4 > address space if there is a common prefix, like "10" in 10.0.0.0/8. I was thinking about mapping different common prefixes to different IPv6 ranges by running several IPv6-6RD setups in parallel, but I don't even know if that is possible or feasible. It would be a waste of address space to use one IPv6-6RD setup with 32 bits for the IPv4 address when most of those addresses will never be used. We have a lot of bits in an IPv6 address, but doing this doesn't seem to make sense. > Free.fr got a /26, as they state in their RIPE-58 presentation, so > they obviously could argument their need for the address space in > front of RIPE. This leaves two flows to follow... > > -> either it depends on who from the hostmasters is dealing with your > allocation request, because why would RIPE deal with Swisscom > different than with free.fr? > -> or Swisscom could not argue the need to RIPE in the same way as free.fr? Good question, but this is something that Swisscom and RIPE NCC should discuss. RIPE NCC won't publicly discuss allocation request details, and that confidentiality is good. What we need to do as address policy WG is think about how we want to deal with this in general. Do we want/need special policy for IPv6-6RD users? If we think we do, we should define the rules and conditions by writing a formal policy proposal. But we need to check if the current policy isn't good enough already. I think we should have as few 'special' policies as possible. Sander From florian at frotzler.priv.at Wed Nov 25 22:59:34 2009 From: florian at frotzler.priv.at (Florian Frotzler) Date: Wed, 25 Nov 2009 22:59:34 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: <1484.80.101.103.96.1259164932.squirrel@webmail.sintact.nl> <966645c70911250827o5c86236cx4a8bf05ecac240d5@mail.gmail.com> Message-ID: <966645c70911251359k45e01749x2ef9d000ccbcda1@mail.gmail.com> Hi Sander, With the current draft of 6RD you can not use different IPv4 prefixes as the 6RD gateway just would not know when to use which prefix. IMHO, using public IP addresses you need to use 32 bit, but maybe this issue is corrected before it becomes an RFC, I don't know. This IS definitely a flaw in the 6RD design. I am not a fan of handing out everyone who implements 6RD a /28 or even larger allocation, but we should not hamper the rollout of v6 with this issue! Being this discussion a private one between RIPE-NCC and Swisscom or not, the IPRA explicitly asked Swisscom to take this topic to the community, so they have to bear with the question of whether it is fair to assign a /26 to free.fr and decline a /28 to Swisscom -> for the same implementation <- Was the address policy a different one at the time free.fr got their prefix? Cheers, Florian 2009/11/25 Sander Steffann : > Hi Florian, > >> It is clearly stated in the draft that you can only aggregate IPv4 >> address space if there is a common prefix, like "10" in 10.0.0.0/8. > > I was thinking about mapping different common prefixes to different IPv6 ranges by running several IPv6-6RD setups in parallel, but I don't even know if that is possible or feasible. It would be a waste of address space to use one IPv6-6RD setup with 32 bits for the IPv4 address when most of those addresses will never be used. We have a lot of bits in an IPv6 address, but doing this doesn't seem to make sense. > >> Free.fr got a /26, as they state in their RIPE-58 presentation, so >> they obviously could argument their need for the address space in >> front of RIPE. This leaves two flows to follow... >> >> -> either it depends on who from the hostmasters is dealing with your >> allocation request, because why would RIPE deal with Swisscom >> different than with free.fr? >> -> or Swisscom could not argue the need to RIPE in the same way as free.fr? > > Good question, but this is something that Swisscom and RIPE NCC should discuss. RIPE NCC won't publicly discuss allocation request details, and that confidentiality is good. > > What we need to do as address policy WG is think about how we want to deal with this in general. Do we want/need special policy for IPv6-6RD users? If we think we do, we should define the rules and conditions by writing a formal policy proposal. But we need to check if the current policy isn't good enough already. I think we should have as few 'special' policies as possible. > > Sander > > From michael.dillon at bt.com Thu Nov 26 00:29:27 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Wed, 25 Nov 2009 23:29:27 -0000 Subject: [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <78B046C9-9108-46A7-BA93-7CFB21C5CE5D@ip-plus.net> Message-ID: <28E139F46D45AF49A31950F88C497458043A82F1@E03MVZ2-UKDY.domain1.systemhost.net> > we have much more than 65k customers, with IPv4 addresses > dispersed in many different /8 We therefore cannot easily > compress the IPv4 address and want to use the whole 32bit. > However, we plan to allocate only a /60 subnet to the end customer. > This results in a request for a /28 If you have a lot of customers then I see nothing wrong with giving an allocation larger than /32. There are clear technical reasons that make this necessary. However, I would like to see RIPE discourage end customer prefixes longer than /56 for general Internet access. In other words, I believe that you should get a bigger block than /28, big enough so that you can allocate /56 subnets to each customer. --Michael Dillon From florian at frotzler.priv.at Thu Nov 26 01:08:18 2009 From: florian at frotzler.priv.at (Florian Frotzler) Date: Thu, 26 Nov 2009 01:08:18 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <25B76451F7215744AFD4195362E55A1CF34606@NLEN1EX1.eu.win.equinix.com> References: <1484.80.101.103.96.1259164932.squirrel@webmail.sintact.nl> <78B046C9-9108-46A7-BA93-7CFB21C5CE5D@ip-plus.net> <25B76451F7215744AFD4195362E55A1CF34606@NLEN1EX1.eu.win.equinix.com> Message-ID: <966645c70911251608i4062e076jb8c8ea4e7f52f2b5@mail.gmail.com> Hi Remco, Either you or me have a wrong understanding of how 6RD works. I understand it like that some high order bits of the IPv4 prefixes need to match so that you can aggregate. How many high order bits of IP addresses of which the first octet is <128 do you see matching with an octet being >=128? Cheers, Florian 2009/11/25 Remco van Mook : > Hi Jan, > > I see the problem you have trying to get a fragmented address space such > as yours play nicely with 6rd. However, given the dimension of your > network (some quick digging gave me a figure of roughly a million v4 > addresses) do you think that asking for 4 billion /60 prefixes is a good > idea? To borrow somebody else's words here, that doesn't scale. > > Here's another idea. You've got ~135 prefixes announced, but if I > aggregate those to the nearest /16 (remember, if there are blocks of > space that aren't yours in between it doesn't matter for 6rd because the > ipv6 sp prefix will be different anyway) you end up with a (sparsely > filled) block or 30. From there on it's a matter of a simple mapping to > about 21 bits of uniquely identified addresses, removing an easy 3 > orders of magnitude from your address requirement. All of a sudden, you > no longer need to have a /28 for just migrating your v4 customers but a > mere /39, giving you tons of space for deployment of new and exciting > IPv6 services for years even with the standard /32 allocation. > > Since we're talking about drafts, not standards, perhaps something like > this should be taken in consideration reviewing a new version of the > draft. We've wasted enough IPv6 space in standards already, IMNSHO. > > Best, > > Remco > > -----Original Message----- > From: address-policy-wg-admin at ripe.net > [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Jan Boogman > Sent: woensdag 25 november 2009 17:13 > To: Sander Steffann > Cc: address-policy-wg at ripe.net; ipv6-wg at ripe.net > Subject: Re: [address-policy-wg] IPv6 allocations for 6RD > > Hi Sander > >>> We asked RIPE NCC for a larger than /32 allocation (because of the > way how >>> 6RD encapsulates the customers IPv4 address in his IPv6 address and > also >>> because we want to give the customer a small subnet). >> >> In draft-townsley-ipv6-6rd-01 the following example is given: >> >> This example show how the 6rd prefix is created based on a /32 IPv6 > prefix >> with a private IPv4 address were the first octet is "compressed" out: >> ?SP prefix: 2001:0DB8::/32 >> ?6rd IPv4 prefix: 10.0.0.0/8 >> ?6rd router IPv4 address: 10.100.100.1 >> ?6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56 >> >> With this scheme you can still give every customer out of an IPv4 /8 > an >> IPv6 /56 subnet. If you have an IPv4 /16 with customers you could >> "compress" so that every customer has an IPv6 /48. And if you have > more >> than 65k customers you should have no problem with getting a bigger > IPv6 >> allocation. > >> >> Because the IPRA refuses to give you more addresses based on your > customer >> base I suspect that you have less than 65k customers. With a smart > IPv4 >> <--> IPv6-RD mapping that should not be a problem for IPv6-RD. >> >> Can you give some extra background information that explains why you > need >> more than a /32? > > we have much more than 65k customers, with IPv4 addresses dispersed in > many different /8 > We therefore cannot easily compress the IPv4 address and want to use the > whole 32bit. > However, we plan to allocate only a /60 subnet to the end customer. > This results in a request for a /28 > > Jan > > > This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. ?Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383. > > From Remco.vanMook at eu.equinix.com Wed Nov 25 22:53:13 2009 From: Remco.vanMook at eu.equinix.com (Remco van Mook) Date: Wed, 25 Nov 2009 22:53:13 +0100 Subject: [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD References: <1484.80.101.103.96.1259164932.squirrel@webmail.sintact.nl> <78B046C9-9108-46A7-BA93-7CFB21C5CE5D@ip-plus.net> Message-ID: <25B76451F7215744AFD4195362E55A1CF34606@NLEN1EX1.eu.win.equinix.com> Hi Jan, I see the problem you have trying to get a fragmented address space such as yours play nicely with 6rd. However, given the dimension of your network (some quick digging gave me a figure of roughly a million v4 addresses) do you think that asking for 4 billion /60 prefixes is a good idea? To borrow somebody else's words here, that doesn't scale. Here's another idea. You've got ~135 prefixes announced, but if I aggregate those to the nearest /16 (remember, if there are blocks of space that aren't yours in between it doesn't matter for 6rd because the ipv6 sp prefix will be different anyway) you end up with a (sparsely filled) block or 30. From there on it's a matter of a simple mapping to about 21 bits of uniquely identified addresses, removing an easy 3 orders of magnitude from your address requirement. All of a sudden, you no longer need to have a /28 for just migrating your v4 customers but a mere /39, giving you tons of space for deployment of new and exciting IPv6 services for years even with the standard /32 allocation. Since we're talking about drafts, not standards, perhaps something like this should be taken in consideration reviewing a new version of the draft. We've wasted enough IPv6 space in standards already, IMNSHO. Best, Remco -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Jan Boogman Sent: woensdag 25 november 2009 17:13 To: Sander Steffann Cc: address-policy-wg at ripe.net; ipv6-wg at ripe.net Subject: Re: [address-policy-wg] IPv6 allocations for 6RD Hi Sander >> We asked RIPE NCC for a larger than /32 allocation (because of the way how >> 6RD encapsulates the customers IPv4 address in his IPv6 address and also >> because we want to give the customer a small subnet). > > In draft-townsley-ipv6-6rd-01 the following example is given: > > This example show how the 6rd prefix is created based on a /32 IPv6 prefix > with a private IPv4 address were the first octet is "compressed" out: > SP prefix: 2001:0DB8::/32 > 6rd IPv4 prefix: 10.0.0.0/8 > 6rd router IPv4 address: 10.100.100.1 > 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56 > > With this scheme you can still give every customer out of an IPv4 /8 an > IPv6 /56 subnet. If you have an IPv4 /16 with customers you could > "compress" so that every customer has an IPv6 /48. And if you have more > than 65k customers you should have no problem with getting a bigger IPv6 > allocation. > > Because the IPRA refuses to give you more addresses based on your customer > base I suspect that you have less than 65k customers. With a smart IPv4 > <--> IPv6-RD mapping that should not be a problem for IPv6-RD. > > Can you give some extra background information that explains why you need > more than a /32? we have much more than 65k customers, with IPv4 addresses dispersed in many different /8 We therefore cannot easily compress the IPv4 address and want to use the whole 32bit. However, we plan to allocate only a /60 subnet to the end customer. This results in a request for a /28 Jan This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383. From sander at steffann.nl Thu Nov 26 09:21:40 2009 From: sander at steffann.nl (Sander Steffann) Date: Thu, 26 Nov 2009 09:21:40 +0100 Subject: [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <25B76451F7215744AFD4195362E55A1CF34606@NLEN1EX1.eu.win.equinix.com> References: <1484.80.101.103.96.1259164932.squirrel@webmail.sintact.nl> <78B046C9-9108-46A7-BA93-7CFB21C5CE5D@ip-plus.net> <25B76451F7215744AFD4195362E55A1CF34606@NLEN1EX1.eu.win.equinix.com> Message-ID: <7DCF458E-0DFF-4A3F-A6A1-A2DA7A3E7257@steffann.nl> Hi Remco, > Since we're talking about drafts, not standards, perhaps something like > this should be taken in consideration reviewing a new version of the > draft. We've wasted enough IPv6 space in standards already, IMNSHO. Very good point. Sander From Remco.vanMook at eu.equinix.com Thu Nov 26 09:23:19 2009 From: Remco.vanMook at eu.equinix.com (Remco van Mook) Date: Thu, 26 Nov 2009 09:23:19 +0100 Subject: [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD References: <1484.80.101.103.96.1259164932.squirrel@webmail.sintact.nl> <78B046C9-9108-46A7-BA93-7CFB21C5CE5D@ip-plus.net> <25B76451F7215744AFD4195362E55A1CF34606@NLEN1EX1.eu.win.equinix.com> <966645c70911251608i4062e076jb8c8ea4e7f52f2b5@mail.gmail.com> Message-ID: <25B76451F7215744AFD4195362E55A1CF34629@NLEN1EX1.eu.win.equinix.com> Hi Florian It's entirely possible my understanding of how 6rd should work is wrong, but at the same time we must realize it's a draft, not a standard and as far as I know nobody has implemented it anywhere yet. But I do see a few assumptions I don't like: - You can only do 6rd once in an entire network - It only works for IPv4 /8s and larger - It only works for IPv6 /32s and larger I don't see why it wouldn't work for multiple instances and arbitrary prefix sizes for both IPv4 and IPv6. So, taking the example from Mark Townsley's draft: SP prefix: 2001:0DB8::/32 6rd IPv4 prefix: 10.0.0.0/8 6rd router IPv4 address: 10.100.100.1 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56 I don't see why this wouldn't work with a /44 SP prefix, a /16 of IPv4 and /60 6rd site IPv6 prefixes. Or any other CIDR-size, for that matter. Use multiple instances of 6rd of whatever size fits best (they don't even need to be identical) to cover whatever set of allocations you've received over the last 15 years. In Jan's case these instances together would easily fit in a /39 of space; even extending the site IPv6 prefix to a /56 wouldn't extend this beyond a /35 requirement. If a single 6rd instance is accepted as a rule the end result of that will be that every ISP in the world with non-contiguous allocations will be asking for a /24 next, knowing full well that they're only going to use 0,1% of the network side of that space, ever. Remco -----Original Message----- From: Florian Frotzler [mailto:florian at frotzler.priv.at] Sent: donderdag 26 november 2009 1:08 To: Remco van Mook Cc: Jan Boogman; Sander Steffann; address-policy-wg at ripe.net; ipv6-wg at ripe.net Subject: Re: [address-policy-wg] IPv6 allocations for 6RD Hi Remco, Either you or me have a wrong understanding of how 6RD works. I understand it like that some high order bits of the IPv4 prefixes need to match so that you can aggregate. How many high order bits of IP addresses of which the first octet is <128 do you see matching with an octet being >=128? Cheers, Florian 2009/11/25 Remco van Mook : > Hi Jan, > > I see the problem you have trying to get a fragmented address space such > as yours play nicely with 6rd. However, given the dimension of your > network (some quick digging gave me a figure of roughly a million v4 > addresses) do you think that asking for 4 billion /60 prefixes is a good > idea? To borrow somebody else's words here, that doesn't scale. > > Here's another idea. You've got ~135 prefixes announced, but if I > aggregate those to the nearest /16 (remember, if there are blocks of > space that aren't yours in between it doesn't matter for 6rd because the > ipv6 sp prefix will be different anyway) you end up with a (sparsely > filled) block or 30. From there on it's a matter of a simple mapping to > about 21 bits of uniquely identified addresses, removing an easy 3 > orders of magnitude from your address requirement. All of a sudden, you > no longer need to have a /28 for just migrating your v4 customers but a > mere /39, giving you tons of space for deployment of new and exciting > IPv6 services for years even with the standard /32 allocation. > > Since we're talking about drafts, not standards, perhaps something like > this should be taken in consideration reviewing a new version of the > draft. We've wasted enough IPv6 space in standards already, IMNSHO. > > Best, > > Remco > > -----Original Message----- > From: address-policy-wg-admin at ripe.net > [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Jan Boogman > Sent: woensdag 25 november 2009 17:13 > To: Sander Steffann > Cc: address-policy-wg at ripe.net; ipv6-wg at ripe.net > Subject: Re: [address-policy-wg] IPv6 allocations for 6RD > > Hi Sander > >>> We asked RIPE NCC for a larger than /32 allocation (because of the > way how >>> 6RD encapsulates the customers IPv4 address in his IPv6 address and > also >>> because we want to give the customer a small subnet). >> >> In draft-townsley-ipv6-6rd-01 the following example is given: >> >> This example show how the 6rd prefix is created based on a /32 IPv6 > prefix >> with a private IPv4 address were the first octet is "compressed" out: >> ?SP prefix: 2001:0DB8::/32 >> ?6rd IPv4 prefix: 10.0.0.0/8 >> ?6rd router IPv4 address: 10.100.100.1 >> ?6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56 >> >> With this scheme you can still give every customer out of an IPv4 /8 > an >> IPv6 /56 subnet. If you have an IPv4 /16 with customers you could >> "compress" so that every customer has an IPv6 /48. And if you have > more >> than 65k customers you should have no problem with getting a bigger > IPv6 >> allocation. > >> >> Because the IPRA refuses to give you more addresses based on your > customer >> base I suspect that you have less than 65k customers. With a smart > IPv4 >> <--> IPv6-RD mapping that should not be a problem for IPv6-RD. >> >> Can you give some extra background information that explains why you > need >> more than a /32? > > we have much more than 65k customers, with IPv4 addresses dispersed in > many different /8 > We therefore cannot easily compress the IPv4 address and want to use the > whole 32bit. > However, we plan to allocate only a /60 subnet to the end customer. > This results in a request for a /28 > > Jan > > > This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. ?Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383. > > From florian at frotzler.priv.at Thu Nov 26 09:56:04 2009 From: florian at frotzler.priv.at (Florian Frotzler) Date: Thu, 26 Nov 2009 09:56:04 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <25B76451F7215744AFD4195362E55A1CF34629@NLEN1EX1.eu.win.equinix.com> References: <1484.80.101.103.96.1259164932.squirrel@webmail.sintact.nl> <78B046C9-9108-46A7-BA93-7CFB21C5CE5D@ip-plus.net> <25B76451F7215744AFD4195362E55A1CF34606@NLEN1EX1.eu.win.equinix.com> <966645c70911251608i4062e076jb8c8ea4e7f52f2b5@mail.gmail.com> <25B76451F7215744AFD4195362E55A1CF34629@NLEN1EX1.eu.win.equinix.com> Message-ID: <966645c70911260056pc339694i1dcf5b1d226a323f@mail.gmail.com> 2009/11/26 Remco van Mook : > Hi Florian Hi Remco, > It's entirely possible my understanding of how 6rd should work is wrong, but at the same time we must realize it's a draft, not a standard and as far as I know nobody has implemented it anywhere yet. But I do see a few assumptions I don't like: Free.fr is one of the largest providers in Europe offering IPv6 services to its customers. They are the reason why 6RD became known because they have a working installation of 6RD and are very successful. Please take a look at the link Jan postet in his original message. > - You can only do 6rd once in an entire network If you have enought bits, you can subnet -> in front <- of the embedded IPv4 prefix (like free.fr did) and so you can address different 6RD gateways. This is infrastructure subnetting and not to be confused with customer subnetting like what Jan tries to establish. Multiple 6RD GWs are therefore technically possible IMHO, but may be messy regarding your CPE provisioning. > - It only works for IPv4 /8s and larger > - It only works for IPv6 /32s and larger > Why? You can aggregate on any boundary as long as there are common high order bits. > I don't see why it wouldn't work for multiple instances and arbitrary prefix sizes for both IPv4 and IPv6. So, taking the example from Mark Townsley's draft: > > ? ? ? ? ? SP prefix: 2001:0DB8::/32 > ? ? ? ? 6rd IPv4 prefix: 10.0.0.0/8 > ? ? ? ? 6rd router IPv4 address: 10.100.100.1 > ? ? ? ? 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56 > > I don't see why this wouldn't work with a /44 SP prefix, a /16 of IPv4 and /60 6rd site IPv6 prefixes. Or any other CIDR-size, for that matter. Use multiple instances of 6rd of whatever size fits best (they don't even need to be identical) to cover whatever set of allocations you've received over the last 15 years. In Jan's case these instances together would easily fit in a /39 of space; even extending the site IPv6 prefix to a /56 wouldn't extend this beyond a /35 requirement. > > If a single 6rd instance is accepted as a rule the end result of that will be that every ISP in the world with non-contiguous allocations will be asking for a /24 next, knowing full well that they're only going to use 0,1% of the network side of that space, ever. Can you give an example? How does the GW chose the prefix for encapsulation if there is more than one possible? > Remco > Florian > > -----Original Message----- > From: Florian Frotzler [mailto:florian at frotzler.priv.at] > Sent: donderdag 26 november 2009 1:08 > To: Remco van Mook > Cc: Jan Boogman; Sander Steffann; address-policy-wg at ripe.net; ipv6-wg at ripe.net > Subject: Re: [address-policy-wg] IPv6 allocations for 6RD > > Hi Remco, > > Either you or me have a wrong understanding of how 6RD works. I > understand it like that some high order bits of the IPv4 prefixes need > to match so that you can aggregate. How many high order bits of IP > addresses of which the first octet is <128 do you see matching with an > octet being >=128? > > Cheers, > Florian > > > 2009/11/25 Remco van Mook : >> Hi Jan, >> >> I see the problem you have trying to get a fragmented address space such >> as yours play nicely with 6rd. However, given the dimension of your >> network (some quick digging gave me a figure of roughly a million v4 >> addresses) do you think that asking for 4 billion /60 prefixes is a good >> idea? To borrow somebody else's words here, that doesn't scale. >> >> Here's another idea. You've got ~135 prefixes announced, but if I >> aggregate those to the nearest /16 (remember, if there are blocks of >> space that aren't yours in between it doesn't matter for 6rd because the >> ipv6 sp prefix will be different anyway) you end up with a (sparsely >> filled) block or 30. From there on it's a matter of a simple mapping to >> about 21 bits of uniquely identified addresses, removing an easy 3 >> orders of magnitude from your address requirement. All of a sudden, you >> no longer need to have a /28 for just migrating your v4 customers but a >> mere /39, giving you tons of space for deployment of new and exciting >> IPv6 services for years even with the standard /32 allocation. >> >> Since we're talking about drafts, not standards, perhaps something like >> this should be taken in consideration reviewing a new version of the >> draft. We've wasted enough IPv6 space in standards already, IMNSHO. >> >> Best, >> >> Remco >> >> -----Original Message----- >> From: address-policy-wg-admin at ripe.net >> [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Jan Boogman >> Sent: woensdag 25 november 2009 17:13 >> To: Sander Steffann >> Cc: address-policy-wg at ripe.net; ipv6-wg at ripe.net >> Subject: Re: [address-policy-wg] IPv6 allocations for 6RD >> >> Hi Sander >> >>>> We asked RIPE NCC for a larger than /32 allocation (because of the >> way how >>>> 6RD encapsulates the customers IPv4 address in his IPv6 address and >> also >>>> because we want to give the customer a small subnet). >>> >>> In draft-townsley-ipv6-6rd-01 the following example is given: >>> >>> This example show how the 6rd prefix is created based on a /32 IPv6 >> prefix >>> with a private IPv4 address were the first octet is "compressed" out: >>> ?SP prefix: 2001:0DB8::/32 >>> ?6rd IPv4 prefix: 10.0.0.0/8 >>> ?6rd router IPv4 address: 10.100.100.1 >>> ?6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56 >>> >>> With this scheme you can still give every customer out of an IPv4 /8 >> an >>> IPv6 /56 subnet. If you have an IPv4 /16 with customers you could >>> "compress" so that every customer has an IPv6 /48. And if you have >> more >>> than 65k customers you should have no problem with getting a bigger >> IPv6 >>> allocation. >> >>> >>> Because the IPRA refuses to give you more addresses based on your >> customer >>> base I suspect that you have less than 65k customers. With a smart >> IPv4 >>> <--> IPv6-RD mapping that should not be a problem for IPv6-RD. >>> >>> Can you give some extra background information that explains why you >> need >>> more than a /32? >> >> we have much more than 65k customers, with IPv4 addresses dispersed in >> many different /8 >> We therefore cannot easily compress the IPv4 address and want to use the >> whole 32bit. >> However, we plan to allocate only a /60 subnet to the end customer. >> This results in a request for a /28 >> >> Jan >> >> >> This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. ?Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383. >> >> > From michael.dillon at bt.com Thu Nov 26 10:12:05 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Thu, 26 Nov 2009 09:12:05 -0000 Subject: [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <25B76451F7215744AFD4195362E55A1CF34629@NLEN1EX1.eu.win.equinix.com> Message-ID: <28E139F46D45AF49A31950F88C4974580442D27D@E03MVZ2-UKDY.domain1.systemhost.net> > If a single 6rd instance is accepted as a rule the end result > of that will be that every ISP in the world with > non-contiguous allocations will be asking for a /24 next, > knowing full well that they're only going to use 0,1% of the > network side of that space, ever. A lot of numbers have been thrown around fairly casually in this conversation, but /24 is a nice one to focus on because everyone understands how many /24s there are in a number space. If we could have run the IPv4 Internet by only giving every ISP a single /24, then we would never have run out of IPv4 addresses. Conversely, giving every ISP an IPv6 /24 is not radical and is not even wasteful given the large number of /24s that we have in stock at RIPE and at IANA. As for your comment about 0.1%, I'd like to know how you calculated that number. In general, I'm only interested in numbers that count /56s (or /48s) and /32s since those are the only ones that are meaningful in making policy. --Michael Dillon From Remco.vanMook at eu.equinix.com Thu Nov 26 10:09:35 2009 From: Remco.vanMook at eu.equinix.com (Remco van Mook) Date: Thu, 26 Nov 2009 10:09:35 +0100 Subject: [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD References: <1484.80.101.103.96.1259164932.squirrel@webmail.sintact.nl> <78B046C9-9108-46A7-BA93-7CFB21C5CE5D@ip-plus.net> <25B76451F7215744AFD4195362E55A1CF34606@NLEN1EX1.eu.win.equinix.com> <966645c70911251608i4062e076jb8c8ea4e7f52f2b5@mail.gmail.com> <25B76451F7215744AFD4195362E55A1CF34629@NLEN1EX1.eu.win.equinix.com> <966645c70911260056pc339694i1dcf5b1d226a323f@mail.gmail.com> Message-ID: <25B76451F7215744AFD4195362E55A1CF3464E@NLEN1EX1.eu.win.equinix.com> Hi Florian, 'it may be messy' is not a particularly strong argument I think, considering that the current deployed IPv4 setup is already more complicated than this. Every IPv4 subnet already has its own DHCP definition, adding a few lines to tell how that will translate isn't going to be hard. As for v6->v4 translation, every piece of v4 will have a separate v6 SP prefix so that's going to be easy, too. I was at RIPE58 to see Free's presentation and I don't see how any of that conflicts with what I'm trying to say here. Remco -----Original Message----- From: Florian Frotzler [mailto:florian at frotzler.priv.at] Sent: donderdag 26 november 2009 9:56 To: Remco van Mook Cc: Jan Boogman; Sander Steffann; address-policy-wg at ripe.net; ipv6-wg at ripe.net Subject: Re: [address-policy-wg] IPv6 allocations for 6RD 2009/11/26 Remco van Mook : > Hi Florian Hi Remco, > It's entirely possible my understanding of how 6rd should work is wrong, but at the same time we must realize it's a draft, not a standard and as far as I know nobody has implemented it anywhere yet. But I do see a few assumptions I don't like: Free.fr is one of the largest providers in Europe offering IPv6 services to its customers. They are the reason why 6RD became known because they have a working installation of 6RD and are very successful. Please take a look at the link Jan postet in his original message. > - You can only do 6rd once in an entire network If you have enought bits, you can subnet -> in front <- of the embedded IPv4 prefix (like free.fr did) and so you can address different 6RD gateways. This is infrastructure subnetting and not to be confused with customer subnetting like what Jan tries to establish. Multiple 6RD GWs are therefore technically possible IMHO, but may be messy regarding your CPE provisioning. > - It only works for IPv4 /8s and larger > - It only works for IPv6 /32s and larger > Why? You can aggregate on any boundary as long as there are common high order bits. > I don't see why it wouldn't work for multiple instances and arbitrary prefix sizes for both IPv4 and IPv6. So, taking the example from Mark Townsley's draft: > > ? ? ? ? ? SP prefix: 2001:0DB8::/32 > ? ? ? ? 6rd IPv4 prefix: 10.0.0.0/8 > ? ? ? ? 6rd router IPv4 address: 10.100.100.1 > ? ? ? ? 6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56 > > I don't see why this wouldn't work with a /44 SP prefix, a /16 of IPv4 and /60 6rd site IPv6 prefixes. Or any other CIDR-size, for that matter. Use multiple instances of 6rd of whatever size fits best (they don't even need to be identical) to cover whatever set of allocations you've received over the last 15 years. In Jan's case these instances together would easily fit in a /39 of space; even extending the site IPv6 prefix to a /56 wouldn't extend this beyond a /35 requirement. > > If a single 6rd instance is accepted as a rule the end result of that will be that every ISP in the world with non-contiguous allocations will be asking for a /24 next, knowing full well that they're only going to use 0,1% of the network side of that space, ever. Can you give an example? How does the GW chose the prefix for encapsulation if there is more than one possible? > Remco > Florian > > -----Original Message----- > From: Florian Frotzler [mailto:florian at frotzler.priv.at] > Sent: donderdag 26 november 2009 1:08 > To: Remco van Mook > Cc: Jan Boogman; Sander Steffann; address-policy-wg at ripe.net; ipv6-wg at ripe.net > Subject: Re: [address-policy-wg] IPv6 allocations for 6RD > > Hi Remco, > > Either you or me have a wrong understanding of how 6RD works. I > understand it like that some high order bits of the IPv4 prefixes need > to match so that you can aggregate. How many high order bits of IP > addresses of which the first octet is <128 do you see matching with an > octet being >=128? > > Cheers, > Florian > > > 2009/11/25 Remco van Mook : >> Hi Jan, >> >> I see the problem you have trying to get a fragmented address space such >> as yours play nicely with 6rd. However, given the dimension of your >> network (some quick digging gave me a figure of roughly a million v4 >> addresses) do you think that asking for 4 billion /60 prefixes is a good >> idea? To borrow somebody else's words here, that doesn't scale. >> >> Here's another idea. You've got ~135 prefixes announced, but if I >> aggregate those to the nearest /16 (remember, if there are blocks of >> space that aren't yours in between it doesn't matter for 6rd because the >> ipv6 sp prefix will be different anyway) you end up with a (sparsely >> filled) block or 30. From there on it's a matter of a simple mapping to >> about 21 bits of uniquely identified addresses, removing an easy 3 >> orders of magnitude from your address requirement. All of a sudden, you >> no longer need to have a /28 for just migrating your v4 customers but a >> mere /39, giving you tons of space for deployment of new and exciting >> IPv6 services for years even with the standard /32 allocation. >> >> Since we're talking about drafts, not standards, perhaps something like >> this should be taken in consideration reviewing a new version of the >> draft. We've wasted enough IPv6 space in standards already, IMNSHO. >> >> Best, >> >> Remco >> >> -----Original Message----- >> From: address-policy-wg-admin at ripe.net >> [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Jan Boogman >> Sent: woensdag 25 november 2009 17:13 >> To: Sander Steffann >> Cc: address-policy-wg at ripe.net; ipv6-wg at ripe.net >> Subject: Re: [address-policy-wg] IPv6 allocations for 6RD >> >> Hi Sander >> >>>> We asked RIPE NCC for a larger than /32 allocation (because of the >> way how >>>> 6RD encapsulates the customers IPv4 address in his IPv6 address and >> also >>>> because we want to give the customer a small subnet). >>> >>> In draft-townsley-ipv6-6rd-01 the following example is given: >>> >>> This example show how the 6rd prefix is created based on a /32 IPv6 >> prefix >>> with a private IPv4 address were the first octet is "compressed" out: >>> ?SP prefix: 2001:0DB8::/32 >>> ?6rd IPv4 prefix: 10.0.0.0/8 >>> ?6rd router IPv4 address: 10.100.100.1 >>> ?6rd site IPv6 prefix: 2001:0DB8:6464:0100::/56 >>> >>> With this scheme you can still give every customer out of an IPv4 /8 >> an >>> IPv6 /56 subnet. If you have an IPv4 /16 with customers you could >>> "compress" so that every customer has an IPv6 /48. And if you have >> more >>> than 65k customers you should have no problem with getting a bigger >> IPv6 >>> allocation. >> >>> >>> Because the IPRA refuses to give you more addresses based on your >> customer >>> base I suspect that you have less than 65k customers. With a smart >> IPv4 >>> <--> IPv6-RD mapping that should not be a problem for IPv6-RD. >>> >>> Can you give some extra background information that explains why you >> need >>> more than a /32? >> >> we have much more than 65k customers, with IPv4 addresses dispersed in >> many different /8 >> We therefore cannot easily compress the IPv4 address and want to use the >> whole 32bit. >> However, we plan to allocate only a /60 subnet to the end customer. >> This results in a request for a /28 >> >> Jan >> >> >> This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. ?Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383. >> >> > From Sam.Wilson at ed.ac.uk Thu Nov 26 09:47:13 2009 From: Sam.Wilson at ed.ac.uk (Sam.Wilson at ed.ac.uk) Date: 26 Nov 2009 08:47:13 GMT Subject: [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: Your message <7DCF458E-0DFF-4A3F-A6A1-A2DA7A3E7257@steffann.nl> Message-ID: <200911260847.nAQ8lDrA025037@holyrood.ed.ac.uk> An embedded and charset-unspecified text was scrubbed... Name: not available URL: From Remco.vanMook at eu.equinix.com Thu Nov 26 10:24:21 2009 From: Remco.vanMook at eu.equinix.com (Remco van Mook) Date: Thu, 26 Nov 2009 10:24:21 +0100 Subject: [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD References: <28E139F46D45AF49A31950F88C4974580442D27D@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <25B76451F7215744AFD4195362E55A1CF3465E@NLEN1EX1.eu.win.equinix.com> Fair enough, I'll bite. Given 2^32(or 4 billion) IPv4 addresses, and say, 4 million IP's allocated to the average ISP (I'm being generous here) there's your 0.1%. The rest of the space will go unused since we're using 32 bits to identify these sparse blocks in the v4->v6 translation. Not counting customer /56s, 48s, /60s or whatever. The more dangerous bit here is that you're going to have a hard time using the other pieces of that 32 bits you've allocated to 6rd elsewhere - it'll only give you v6 for people you're currently handing out a v4 address as well. I agree that handing an ISP a /24 should last them an eternity, but only if they make sensible use of it. Remco -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of michael.dillon at bt.com Sent: donderdag 26 november 2009 10:12 To: address-policy-wg at ripe.net; ipv6-wg at ripe.net Subject: RE: [address-policy-wg] IPv6 allocations for 6RD > If a single 6rd instance is accepted as a rule the end result > of that will be that every ISP in the world with > non-contiguous allocations will be asking for a /24 next, > knowing full well that they're only going to use 0,1% of the > network side of that space, ever. A lot of numbers have been thrown around fairly casually in this conversation, but /24 is a nice one to focus on because everyone understands how many /24s there are in a number space. If we could have run the IPv4 Internet by only giving every ISP a single /24, then we would never have run out of IPv4 addresses. Conversely, giving every ISP an IPv6 /24 is not radical and is not even wasteful given the large number of /24s that we have in stock at RIPE and at IANA. As for your comment about 0.1%, I'd like to know how you calculated that number. In general, I'm only interested in numbers that count /56s (or /48s) and /32s since those are the only ones that are meaningful in making policy. --Michael Dillon This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383. From gert at space.net Thu Nov 26 14:22:42 2009 From: gert at space.net (Gert Doering) Date: Thu, 26 Nov 2009 14:22:42 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <25B76451F7215744AFD4195362E55A1CF34629@NLEN1EX1.eu.win.equinix.com> References: <1484.80.101.103.96.1259164932.squirrel@webmail.sintact.nl> <78B046C9-9108-46A7-BA93-7CFB21C5CE5D@ip-plus.net> <25B76451F7215744AFD4195362E55A1CF34606@NLEN1EX1.eu.win.equinix.com> <966645c70911251608i4062e076jb8c8ea4e7f52f2b5@mail.gmail.com> <25B76451F7215744AFD4195362E55A1CF34629@NLEN1EX1.eu.win.equinix.com> Message-ID: <20091126132242.GE32226@Space.Net> Hi, On Thu, Nov 26, 2009 at 09:23:19AM +0100, Remco van Mook wrote: > If a single 6rd instance is accepted as a rule the end result of > that will be that every ISP in the world with non-contiguous > allocations will be asking for a /24 next, knowing full well that > they're only going to use 0,1% of the network side of that space, > ever. Just to drop a bit of bait into this lively discussion :-9 - we could actually afford to give every organization that reasonably claims to serve IP connectivity to more than 1000 customers a /24. There's 10 million /24s inside FP 001. All in all, the RIRs have about 20.000 members today - 1/500th of that. Of course that's not my call to make, but would require a formal policy change (and isn't actually the point of this discussion - which is "provide guidance to the IPRAs on whether the WG is considering this to be acceptable use"). Gert Doering -- APWG chair -- Total number of prefixes smaller than registry allocations: 144438 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 marcoh at marcoh.net Thu Nov 26 15:13:05 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Thu, 26 Nov 2009 15:13:05 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <20091126132242.GE32226@Space.Net> References: <1484.80.101.103.96.1259164932.squirrel@webmail.sintact.nl> <78B046C9-9108-46A7-BA93-7CFB21C5CE5D@ip-plus.net> <25B76451F7215744AFD4195362E55A1CF34606@NLEN1EX1.eu.win.equinix.com> <966645c70911251608i4062e076jb8c8ea4e7f52f2b5@mail.gmail.com> <25B76451F7215744AFD4195362E55A1CF34629@NLEN1EX1.eu.win.equinix.com> <20091126132242.GE32226@Space.Net> Message-ID: <0FC4111C-051F-4BEC-8E3D-545E8E5682ED@marcoh.net> > Just to drop a bit of bait into this lively discussion :-9 - we could > actually afford to give every organization that reasonably claims to > serve IP connectivity to more than 1000 customers a /24. There's 10 > million /24s inside FP 001. All in all, the RIRs have about 20.000 > members today - 1/500th of that. I think I'm with Remco here, there is a way around it and it might be worth adding something on how to do that to the drafr. I don't think 'it's messy' or 'we have enough space' are strong arguments to simply give everybody a /24, let's not forget there was that day once when a /8 was the default assignment size. Groet, MarcoH From alexlh at ripe.net Thu Nov 26 16:39:23 2009 From: alexlh at ripe.net (Alex Le Heux) Date: Thu, 26 Nov 2009 16:39:23 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <966645c70911251359k45e01749x2ef9d000ccbcda1@mail.gmail.com> References: <1484.80.101.103.96.1259164932.squirrel@webmail.sintact.nl> <966645c70911250827o5c86236cx4a8bf05ecac240d5@mail.gmail.com> <966645c70911251359k45e01749x2ef9d000ccbcda1@mail.gmail.com> Message-ID: <98A9B9F6-F765-4DC2-A9DF-8C2C5782C4F2@ripe.net> Dear Colleagues, > I am not a fan of handing out everyone who implements 6RD a /28 or > even larger allocation, but we should not hamper the rollout of v6 > with this issue! Being this discussion a private one between RIPE-NCC > and Swisscom or not, the IPRA explicitly asked Swisscom to take this > topic to the community, so they have to bear with the question of > whether it is fair to assign a /26 to free.fr and decline a /28 to > Swisscom -> for the same implementation <- The size of all allocations that we make is based on the information that the LIR supplies during the evaluation process and the IPv6 Address Policy. The details of the information that our members supply to us during the evaluation of their requests are confidential and therefore we cannot disclose these. We do ensure that all our members and their requests are treated in an impartial and fair way. > Was the address policy a different one at the time free.fr got their > prefix? There have been several changes to the address policies since Free.fr received their allocation, but their request would not result in a different size block today. Best regards, Alex Le Heux RIPE NCC From Remco.vanMook at eu.equinix.com Fri Nov 27 11:52:03 2009 From: Remco.vanMook at eu.equinix.com (Remco van Mook) Date: Fri, 27 Nov 2009 11:52:03 +0100 Subject: [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD References: <28E139F46D45AF49A31950F88C4974580442E1A1@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <25B76451F7215744AFD4195362E55A1CF34895@NLEN1EX1.eu.win.equinix.com> Michael key words here are 'average' and 'generous'. Perhaps you should try to read first. Same goes for your statement of counting addresses. In cases like these, I think orders of magnitude are more interesting than narrowly defined numbers. 4 million is roughly 0.1% of the IPv4 pool. Since I think the AVERAGE ISP is probably smaller than that (either in customer count or allocated space), giving all of them 32 bits (or the full IPv4 space) PLUS 4-8 bits of network space (not host space!) for their 6rd plan sounds wasteful to me. The 6rd draft has prefix compression for a reason. Sparse number spaces for expansion and automation are fine. Very sparse number spaces you know from the outset will never be filled or usable for other purposes, are not. That is why deploying multiple instances of 6rd in order to benefit from prefix compression to collapse that required number space without losing functionality sounds like the right direction for me. Remco (and if we decide that a /24 is a better standard to hand out to LIRs than a /32, I can predict today that somebody will come up with a very clever reason to say that /16s are probably even better. Repeat until bored - or out of space.) -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of michael.dillon at bt.com Sent: vrijdag 27 november 2009 11:04 To: address-policy-wg at ripe.net; ipv6-wg at ripe.net Subject: RE: [address-policy-wg] IPv6 allocations for 6RD > Fair enough, I'll bite. Given 2^32(or 4 billion) IPv4 > addresses, and say, 4 million IP's allocated to the average > ISP (I'm being generous > here) there's your 0.1%. The rest of the space will go unused > since we're using 32 bits to identify these sparse blocks in > the v4->v6 translation. Not counting customer /56s, 48s, /60s > or whatever. But customers, and /56s are the essential things to count. Again, you just throw in the number 4 million without explaining where it comes from. IPv4 ISPs come in all sizes with one /24 allocation and some with many allocations of sizes ranging from /17 to /12. Counting IP addresses in IPv6 makes no sense. The addressing hierarchy of IPv6 is designed to have large blocks of unused and unusable addresses. This is both to allow for expansion without changing the network architecture, and to allow for automated address assignment functions which rely on large sparse number spaces to avoid collisions. --Michael Dillon This email is from Equinix Europe Limited or one of its associated/subsidiary companies. This email, and any files transmitted with it, contains information which is confidential, may be legally privileged and is solely for the use of the intended recipient. If you have received this email in error, please notify the sender and delete this email immediately. Equinix Europe Limited. Registered Office: Quadrant House, Floor 6, 17 Thomas More Street, Thomas More Square, London E1W 1YW. Registered in England and Wales No. 6293383. From michael.dillon at bt.com Fri Nov 27 13:28:37 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 27 Nov 2009 12:28:37 -0000 Subject: [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <20091126132242.GE32226@Space.Net> Message-ID: <28E139F46D45AF49A31950F88C49745804487D02@E03MVZ2-UKDY.domain1.systemhost.net> > Just to drop a bit of bait into this lively discussion :-9 - > we could actually afford to give every organization that > reasonably claims to serve IP connectivity to more than 1000 > customers a /24. There's 10 million /24s inside FP 001. All > in all, the RIRs have about 20.000 members today - 1/500th of that. Now those are numbers that I can understand. I think everyone knows what a /24 is, because even in IPv6 it is the same percentage of the total number space as it is in IPv4. Either we accept the fact that 6RD relies on assigning address blocks sparsely within the allocation for technical reasons, and just give 6RD ISP's an allocation big enough to do the job, or we write a special policy for 6RD ISPs. There are only 2 reasons that I can see to write a special policy. One is to encourage ISPs to assign /56 prefixes to customers, not longer ones like /60. And the other is to restrict 6RD allocations only to ISPs that maintain a certain amount of density, i.e. if an ISP has lots of IPv4 allocations scattered all around the IPv4 number space, we might say that they cannot have an IPv6 allocation to cover more than x number of IPv4 /8s. But given that there is no shortage of IPv6 addresses in the foreseeable future, I'm not yet convinced that a new policy is needed. --Michael Dillon From townsley at cisco.com Fri Nov 27 15:50:23 2009 From: townsley at cisco.com (Mark Townsley) Date: Fri, 27 Nov 2009 15:50:23 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <25B76451F7215744AFD4195362E55A1CF34895@NLEN1EX1.eu.win.equinix.com> References: <28E139F46D45AF49A31950F88C4974580442E1A1@E03MVZ2-UKDY.domain1.systemhost.net> <25B76451F7215744AFD4195362E55A1CF34895@NLEN1EX1.eu.win.equinix.com> Message-ID: <4B0FE72F.7060007@cisco.com> Remco van Mook wrote: > Michael > > key words here are 'average' and 'generous'. Perhaps you should try to > read first. Same goes for your statement of counting addresses. In cases > like these, I think orders of magnitude are more interesting than > narrowly defined numbers. 4 million is roughly 0.1% of the IPv4 pool. > Since I think the AVERAGE ISP is probably smaller than that (either in > customer count or allocated space), giving all of them 32 bits (or the > full IPv4 space) PLUS 4-8 bits of network space (not host space!) for > their 6rd plan sounds wasteful to me. > > The 6rd draft has prefix compression for a reason. Sparse number spaces > for expansion and automation are fine. Very sparse number spaces you > know from the outset will never be filled or usable for other purposes, > are not. > Actually, the main reason we added this is for easy and obvious compression for when an SP has decided to run NAT. The RFC1918 space is nicely aggregated. Please don't give SPs more reasons to deploy NATted IPv4 service. Most SPs I talk to don't really like the idea of compressing the global space, if nothing else because they have no assurance that the global IPv4 space they have now will be the same in the future. They'd sooner give the customer a /64, which I've already stated why I personally think is dangerous. > That is why deploying multiple instances of 6rd in order to benefit from > prefix compression to collapse that required number space without > losing functionality sounds like the right direction for me. > There is nothing prohibiting multiple instances of 6rd in the current version of the draft, however note that this does not come without operational complexity - which is exactly what 6rd is trying to allow an SP to avoid. So, there's a cost tradeoff here. Increased prudence of IPv6 space vs. increased cost for ISPs to deploy IPv6. It's quite easy to be penny-wise and pound-foolish here, and given the rate of native deployment of IPv6 thus far, I'd err on the side of getting IPv6 out the door in the short term until we are sure it no longer needs a boost. Consider it similar to stimulus funds to counter a depression if you must, but if an ISP which would otherwise qualify for a /30 needs a /28 or /26 to get IPv6 deployed now vs. later, I'd choose handing out a few more bits until we no longer think it necessary for native IPv6 adoption to occur. - Mark From townsley at cisco.com Fri Nov 27 16:06:30 2009 From: townsley at cisco.com (Mark Townsley) Date: Fri, 27 Nov 2009 16:06:30 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <28E139F46D45AF49A31950F88C49745804487D02@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745804487D02@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4B0FEAF6.20808@cisco.com> michael.dillon at bt.com wrote: >> Just to drop a bit of bait into this lively discussion :-9 - >> we could actually afford to give every organization that >> reasonably claims to serve IP connectivity to more than 1000 >> customers a /24. There's 10 million /24s inside FP 001. All >> in all, the RIRs have about 20.000 members today - 1/500th of that. >> > > Now those are numbers that I can understand. I think everyone knows > what a /24 is, because even in IPv6 it is the same percentage of the > total number space as it is in IPv4. > > Either we accept the fact that 6RD relies on assigning > address blocks sparsely within the allocation for technical > reasons, and just give 6RD ISP's an allocation big enough > to do the job, or we write a special policy for 6RD ISPs. > > There are only 2 reasons that I can see to write a special policy. > One is to encourage ISPs to assign /56 prefixes to customers, > not longer ones like /60. Or /60s vs. /64s. I think you may be a little optimistic if you think that /60 is the low end of the totem pole here. Case in point is that when Free first offered its IPv6 service, it did so within the /32 it had by giving /64s to all its customers. A few folks like myself complained, and they changed it only because they were able to get a large enough allocation from RIPE (which they had to go back and ask for). If that had not happened, it's not like Free would have ripped out its entire DSLAM infrastructure and upgraded it to offer a /60 or /56. The choice would have been /64 or nothing. Period. So, here's a case where RIPE's decision, for whatever reason at the time, of asking Free to hand in its /32 (and, yes, Free gave it back AFAIK) and giving them a /26 instead directly affected the IPv6 service to myself and several hundred thousand IPv6 Internet subscribers in France. RIPE NCC, thank you kindly for that! (and for the socials!) > And the other is to restrict 6RD > allocations only to ISPs that maintain a certain amount of > density, i.e. if an ISP has lots of IPv4 allocations scattered > all around the IPv4 number space, we might say that they cannot > have an IPv6 allocation to cover more than x number of IPv4 /8s. > > But given that there is no shortage of IPv6 addresses in the > foreseeable future, I'm not yet convinced that a new policy is > needed. > I'd be perfectly fine with no new policy, as long as ISPs, even relatively small ones, do not delay IPv6 deployment over lack of obtainable space. Right now, I'm seeing timelines for Ipv6 pushed up rather than pushed back, in a number of cases due to 6rd. As long as we are not reversing that trend, I'll calmly go back to not posting here :-) - Mark > --Michael Dillon > > > From michael.dillon at bt.com Fri Nov 27 16:28:28 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 27 Nov 2009 15:28:28 -0000 Subject: [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <4B0FEAF6.20808@cisco.com> Message-ID: <28E139F46D45AF49A31950F88C497458044880A9@E03MVZ2-UKDY.domain1.systemhost.net> > > There are only 2 reasons that I can see to write a special policy. > > One is to encourage ISPs to assign /56 prefixes to customers, not > > longer ones like /60. > Or /60s vs. /64s. I think you may be a little optimistic if > you think that /60 is the low end of the totem pole here. I don't believe that RIR policy should ever encourage ISPs to assign customer sites a prefix longer than /56. In fact, we really should discourage assigning anything other than a /48 or a /56 because part of the benefit of IPv6 comes from giving the customers a spacious number space in which they can subnet. This also allows for greater portability, i.e. I can switch providers without changing my network architecture, or I can relocate to another country and know that I will get the same prefix length assignment. > Case in point is that when Free first offered its IPv6 > service, it did so within the /32 it had by giving /64s to > all its customers. A few folks like myself complained, and > they changed it only because they were able to get a large > enough allocation from RIPE (which they had to go back and > ask for). If that had not happened, it's not like Free would > have ripped out its entire DSLAM infrastructure and upgraded > it to offer a /60 or /56. The choice would have been /64 or > nothing. Period. The point is that it did happen. RIPE did give them enough address space to offer customers more than a /64. That is the way things should be because there is no shortage of IPv6 address space. In fact, RIPE should refuse to give ISPs an allocation so small that it forces them to offer customers anything longer than a /56 prefix. > I'd be perfectly fine with no new policy, as long as ISPs, > even relatively small ones, do not delay IPv6 deployment over > lack of obtainable space. Yet another reason why RIPE should be liberal with IPv6 space. In IPv4, a /32 will number one host. In IPv6, the same prefix will provide many ISPs enough address space to last them 20 to 50 years. In IPv4, a /24 is something that you assign to customers and a /21 is a small ISP. Why should we be more restrictive in IPv6? I can see no good reason to not hand out ISPs a /24 or a /21 if they need it to make their IPv6 access service work. Even though my employer, a rather large ISP, expects to fit within a /21 with native IPv6 services, I do not see the need to require every other ISP to use their IPv6 allocation as efficiently as we do. Cost efficiency is more important, and if a medium sized ISP needs a /21 in order to get their IPv6 service rolled out faster, then I believe we should give them that /21. The sooner we get the IPv6 transition into full gear, the better it will be for all of us. Network effects demand that we help our competitors by removing any barriers that limit them or slow them down. --Michael Dillon From townsley at cisco.com Fri Nov 27 16:56:26 2009 From: townsley at cisco.com (Mark Townsley) Date: Fri, 27 Nov 2009 16:56:26 +0100 Subject: [ipv6-wg] Re: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <28E139F46D45AF49A31950F88C497458044880A9@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458044880A9@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <4B0FF6AA.9040705@cisco.com> michael.dillon at bt.com wrote: >>> There are only 2 reasons that I can see to write a special policy. >>> One is to encourage ISPs to assign /56 prefixes to customers, not >>> longer ones like /60. >>> >> Or /60s vs. /64s. I think you may be a little optimistic if >> you think that /60 is the low end of the totem pole here. >> > > I don't believe that RIR policy should ever encourage ISPs > to assign customer sites a prefix longer than /56. In fact, > we really should discourage assigning anything other than > a /48 or a /56 because part of the benefit of IPv6 comes > from giving the customers a spacious number space in which > they can subnet. This also allows for greater portability, > i.e. I can switch providers without changing my network > architecture, or I can relocate to another country and know > that I will get the same prefix length assignment. > > >> Case in point is that when Free first offered its IPv6 >> service, it did so within the /32 it had by giving /64s to >> all its customers. A few folks like myself complained, and >> they changed it only because they were able to get a large >> enough allocation from RIPE (which they had to go back and >> ask for). If that had not happened, it's not like Free would >> have ripped out its entire DSLAM infrastructure and upgraded >> it to offer a /60 or /56. The choice would have been /64 or >> nothing. Period. >> > > The point is that it did happen. RIPE did give them enough address > space to offer customers more than a /64. That is the way things > should be because there is no shortage of IPv6 address space. > > In fact, RIPE should refuse to give ISPs an allocation so small > that it forces them to offer customers anything longer than a > /56 prefix. > I'm sure Free would have been happy to get a /22 vs. a /26, and might even pass that on to its customers via a /56 vs. a /60. > > >> I'd be perfectly fine with no new policy, as long as ISPs, >> even relatively small ones, do not delay IPv6 deployment over >> lack of obtainable space. >> > > Yet another reason why RIPE should be liberal with IPv6 space. > > In IPv4, a /32 will number one host. In IPv6, the same prefix > will provide many ISPs enough address space to last them 20 > to 50 years. In IPv4, a /24 is something that you assign to > customers and a /21 is a small ISP. Why should we be more > restrictive in IPv6? I can see no good reason to not hand out > ISPs a /24 or a /21 if they need it to make their IPv6 access > service work. > I agree 100%, I'm just telling you my experience in talking with ISPs. In some cases, it starts with "why not a /128?" then once we get to the point that /64 is really the absolute minimum, then /56 is is the next target. It's often a battle just to get to that point though. > Even though my employer, a rather large ISP, expects to fit > within a /21 with native IPv6 services, I do not see the need > to require every other ISP to use their IPv6 allocation as > efficiently as we do. Cost efficiency is more important, and > if a medium sized ISP needs a /21 in order to get their IPv6 > service rolled out faster, then I believe we should give them > that /21. A /21 should be ample for any ISP to run 6rd and several other native services as well. > The sooner we get the IPv6 transition into full gear, the better > it will be for all of us. Network effects demand that we help our > competitors by removing any barriers that limit them or slow > them down. > Absolutely. The value of the network, and the protocol it runs on, is proportional to the square of the users of course. - Mark > --Michael Dillon > > > From mohacsi at niif.hu Mon Nov 30 09:27:33 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Mon, 30 Nov 2009 09:27:33 +0100 (CET) Subject: [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <28E139F46D45AF49A31950F88C497458044880A9@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458044880A9@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: On Fri, 27 Nov 2009, michael.dillon at bt.com wrote: >>> There are only 2 reasons that I can see to write a special policy. >>> One is to encourage ISPs to assign /56 prefixes to customers, not >>> longer ones like /60. >> Or /60s vs. /64s. I think you may be a little optimistic if >> you think that /60 is the low end of the totem pole here. > > I don't believe that RIR policy should ever encourage ISPs > to assign customer sites a prefix longer than /56. In fact, > we really should discourage assigning anything other than > a /48 or a /56 because part of the benefit of IPv6 comes > from giving the customers a spacious number space in which > they can subnet. This also allows for greater portability, > i.e. I can switch providers without changing my network > architecture, or I can relocate to another country and know > that I will get the same prefix length assignment. > >> Case in point is that when Free first offered its IPv6 >> service, it did so within the /32 it had by giving /64s to >> all its customers. A few folks like myself complained, and >> they changed it only because they were able to get a large >> enough allocation from RIPE (which they had to go back and >> ask for). If that had not happened, it's not like Free would >> have ripped out its entire DSLAM infrastructure and upgraded >> it to offer a /60 or /56. The choice would have been /64 or >> nothing. Period. > > The point is that it did happen. RIPE did give them enough address > space to offer customers more than a /64. That is the way things > should be because there is no shortage of IPv6 address space. > > In fact, RIPE should refuse to give ISPs an allocation so small > that it forces them to offer customers anything longer than a > /56 prefix. > > >> I'd be perfectly fine with no new policy, as long as ISPs, >> even relatively small ones, do not delay IPv6 deployment over >> lack of obtainable space. > > Yet another reason why RIPE should be liberal with IPv6 space. > > In IPv4, a /32 will number one host. In IPv6, the same prefix > will provide many ISPs enough address space to last them 20 > to 50 years. In IPv4, a /24 is something that you assign to > customers and a /21 is a small ISP. Why should we be more > restrictive in IPv6? I can see no good reason to not hand out > ISPs a /24 or a /21 if they need it to make their IPv6 access > service work. > > Even though my employer, a rather large ISP, expects to fit > within a /21 with native IPv6 services, I do not see the need > to require every other ISP to use their IPv6 allocation as > efficiently as we do. Cost efficiency is more important, and > if a medium sized ISP needs a /21 in order to get their IPv6 > service rolled out faster, then I believe we should give them > that /21. > > The sooner we get the IPv6 transition into full gear, the better > it will be for all of us. Network effects demand that we help our > competitors by removing any barriers that limit them or slow > them down. > > --Michael Dillon You forget an important point: 6RD is developed for large amount of small customers (e.g. home users). Giving them /56-/60 should not be a problem. 6RD is not universal! Larger customers your should implement dual-stack solution and give them /48. One size does not fit for all! Best Regards, Janos Mohacsi From michael.dillon at bt.com Mon Nov 30 10:56:07 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 30 Nov 2009 09:56:07 -0000 Subject: [ipv6-wg] RE: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C4974580448868D@E03MVZ2-UKDY.domain1.systemhost.net> > You forget an important point: 6RD is developed for large > amount of small customers (e.g. home users). Giving them > /56-/60 should not be a problem. > 6RD is not universal! Larger customers your should implement > dual-stack solution and give them /48. One size does not fit for all! I consider it a problem if anyone is giving private residence customers a /60. Nobody should get less than a /56 block and if anyone believes that RIPE rules force them to give less than a /56 block, then RIPE should either clarify the situation (education) or we should change the rules. Yes, I agree that non-residential customers should get a /48 and run dual stack on their network, or use other transition mechanisms like Teredo, 6to4, etc. The total cost of transition will be minimized this way. --Michael Dillon