From ripe at wari.net Thu Nov 5 22:02:33 2009 From: ripe at wari.net (Manfredo Miserocchi) Date: Thu, 05 Nov 2009 22:02:33 +0100 Subject: [address-policy-wg] Andrea Borgato Message-ID: Dear all, I've just received a phone call saying that Andrea isn't with us any more. For those who didn't know him, he was a real RIPE Community man for a long time, co-chairing this WG too. Friends can contact me directly (mis at wari.net). Thanks Manfredo Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario. Qualora il presente messaggio Le fosse pervenuto per errore, La invitiamo ad eliminarlo senza copiarlo ed a non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie. You are hereby informed that this message contains confidential informations intended for the addressee's use only. If yu're not the addressee and have received this message by mistake, please delete it and immediately notify us. You may not copy or disseminate this message to anyone. Thank you. From mis at wari.net Thu Nov 5 21:51:56 2009 From: mis at wari.net (Manfredo Miserocchi) Date: Thu, 05 Nov 2009 21:51:56 +0100 Subject: [address-policy-wg] Andrea Borgato Message-ID: Dear all, I've just received a phone call saying that Andrea isn't with us any more. For those who didn't know him, he was a real RIPE Community man for a long time, co-chairing this WG too. Friends can contact me directly. Thanks Manfredo Si precisa che le informazioni contenute in questo messaggio sono riservate e ad uso esclusivo del destinatario. Qualora il presente messaggio Le fosse pervenuto per errore, La invitiamo ad eliminarlo senza copiarlo ed a non inoltrarlo a terzi, dandocene gentilmente comunicazione. Grazie. You are hereby informed that this message contains confidential informations intended for the addressee's use only. If yu're not the addressee and have received this message by mistake, please delete it and immediately notify us. You may not copy or disseminate this message to anyone. Thank you. From gert at space.net Mon Nov 16 12:11:40 2009 From: gert at space.net (Gert Doering) Date: Mon, 16 Nov 2009 12:11:40 +0100 Subject: [address-policy-wg] (draft) Minutes from RIPE 59 are now online Message-ID: <20091116111140.GL32226@Space.Net> Dear APWG participants, the (draft) minutes of the APWG meeting at the RIPE meeting in Lisbon are now online: http://www.ripe.net/ripe/wg/address-policy/r59-minutes.html If you have been at the meeting, please check that everything is as you remember (so we can declare the minutes final at RIPE60), and let us know if something needs changing. If you have NOT been at the meeting, please feel free to read up what we have discussed. We have made a few decisions at the meeting, how to deal with ongoing issues, and I will announce these individually over the next weeks. A big thanks goes to the minute takers from the RIPE NCC! 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 schnizlein at isoc.org Tue Nov 17 20:58:36 2009 From: schnizlein at isoc.org (John Schnizlein) Date: Tue, 17 Nov 2009 14:58:36 -0500 Subject: [address-policy-wg] Securing Routing Information Message-ID: <6F21FDF2-6E2C-45F0-BE65-008924B76C21@isoc.org> FYI, here's a report from a group of operators who got together and discussed the issues. http://www.isoc.org/educpillar/resources/docs/routingroundtable_200909.pdf John -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: [address-policy-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: [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: [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: [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 lutz at iks-jena.de Wed Nov 25 17:14:33 2009 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Wed, 25 Nov 2009 17:14:33 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: Message-ID: <200911251614.nAPGEXvU028096@belenus.iks-jena.de> In ripe.address-policy-wg, you wrote: > we are planning to offer IPv6 connectivity to our xDSL and FTTH customer > base via IPv6-6RD. That's a bad idea. Please stick to 2002::/16 or simply provide native IPv6 in your backbone. > 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). We choosed to announce 2001:0:d911:c000::/52 as well as 2002:d911:c000::/36 in order to overcoming the anycast hassles for the first months. After that we had production stable IPv6 and dropped such tunneling hacks. I oppose handing out large amounts of address space for such legacy methods to save costs in IPv6 rollout. 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: [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 florian at frotzler.priv.at Wed Nov 25 17:46:51 2009 From: florian at frotzler.priv.at (Florian Frotzler) Date: Wed, 25 Nov 2009 17:46:51 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <200911251614.nAPGEXvU028096@belenus.iks-jena.de> References: <200911251614.nAPGEXvU028096@belenus.iks-jena.de> Message-ID: <966645c70911250846g66a4279fk7c9228faf192e5a0@mail.gmail.com> Hi Lutz, I totally disagree with you :-) This would slow down the IPv6 rollout. IPv6-RD is a good choice to bring IPv6 quickly to the customers and fight with the dual stack implementation later. Maybe you are working at a small ISP, but in the real world there are a lot of hazards on the way to implement end2end v6, especially with large ISPs. Cheers, Florian 2009/11/25 Lutz Donnerhacke : > In ripe.address-policy-wg, you wrote: >> we are planning to offer IPv6 connectivity to our xDSL and FTTH customer >> base via IPv6-6RD. > > That's a bad idea. Please stick to 2002::/16 or simply provide native IPv6 > in your backbone. > >> 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). > > We choosed to announce 2001:0:d911:c000::/52 as well as 2002:d911:c000::/36 > in order to overcoming the anycast hassles for the first months. After that > we had production stable IPv6 and dropped such tunneling hacks. > > I oppose handing out large amounts of address space for such legacy methods > to save costs in IPv6 rollout. > > From florian at frotzler.priv.at Wed Nov 25 17:53:34 2009 From: florian at frotzler.priv.at (Florian Frotzler) Date: Wed, 25 Nov 2009 17:53:34 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: <200911251614.nAPGEXvU028096@belenus.iks-jena.de> <966645c70911250846g66a4279fk7c9228faf192e5a0@mail.gmail.com> Message-ID: <966645c70911250853m3a82250dy61cf0bd7e30a1eaf@mail.gmail.com> still quicker as teaching all your IT tools to speak v6... Cheers, Florian 2009/11/25 Mohacsi Janos : > > > > On Wed, 25 Nov 2009, Florian Frotzler wrote: > >> Hi Lutz, >> >> I totally disagree with you :-) >> >> This would slow down the IPv6 rollout. IPv6-RD is a good choice to >> bring IPv6 quickly to the customers and fight with the dual stack >> implementation later. Maybe you are working at a small ISP, but in the >> real world there are a lot of hazards on the way to implement end2end >> v6, especially with large ISPs. > > 6rd is applicable only if the IP provider is controlling the CPE routers or > 6rd is widely implemented in customers CPEs. So not so quick roll-out. > ? ? ? ?Best Regards, > ? ? ? ? ? ? ? ? ? ? ? ?Janos Mohacsi > > >> >> Cheers, >> Florian >> >> 2009/11/25 Lutz Donnerhacke : >>> >>> In ripe.address-policy-wg, you wrote: >>>> >>>> we are planning to offer IPv6 connectivity to our xDSL and FTTH customer >>>> base via IPv6-6RD. >>> >>> That's a bad idea. Please stick to 2002::/16 or simply provide native >>> IPv6 >>> in your backbone. >>> >>>> 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). >>> >>> We choosed to announce 2001:0:d911:c000::/52 as well as >>> 2002:d911:c000::/36 >>> in order to overcoming the anycast hassles for the first months. After >>> that >>> we had production stable IPv6 and dropped such tunneling hacks. >>> >>> I oppose handing out large amounts of address space for such legacy >>> methods >>> to save costs in IPv6 rollout. >>> >>> >> >> > From mohacsi at niif.hu Wed Nov 25 17:51:36 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Wed, 25 Nov 2009 17:51:36 +0100 (CET) Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <966645c70911250846g66a4279fk7c9228faf192e5a0@mail.gmail.com> References: <200911251614.nAPGEXvU028096@belenus.iks-jena.de> <966645c70911250846g66a4279fk7c9228faf192e5a0@mail.gmail.com> Message-ID: On Wed, 25 Nov 2009, Florian Frotzler wrote: > Hi Lutz, > > I totally disagree with you :-) > > This would slow down the IPv6 rollout. IPv6-RD is a good choice to > bring IPv6 quickly to the customers and fight with the dual stack > implementation later. Maybe you are working at a small ISP, but in the > real world there are a lot of hazards on the way to implement end2end > v6, especially with large ISPs. 6rd is applicable only if the IP provider is controlling the CPE routers or 6rd is widely implemented in customers CPEs. So not so quick roll-out. Best Regards, Janos Mohacsi > > Cheers, > Florian > > 2009/11/25 Lutz Donnerhacke : >> In ripe.address-policy-wg, you wrote: >>> we are planning to offer IPv6 connectivity to our xDSL and FTTH customer >>> base via IPv6-6RD. >> >> That's a bad idea. Please stick to 2002::/16 or simply provide native IPv6 >> in your backbone. >> >>> 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). >> >> We choosed to announce 2001:0:d911:c000::/52 as well as 2002:d911:c000::/36 >> in order to overcoming the anycast hassles for the first months. After that >> we had production stable IPv6 and dropped such tunneling hacks. >> >> I oppose handing out large amounts of address space for such legacy methods >> to save costs in IPv6 rollout. >> >> > > From mohacsi at niif.hu Wed Nov 25 19:23:16 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Wed, 25 Nov 2009 19:23:16 +0100 (CET) Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <966645c70911250853m3a82250dy61cf0bd7e30a1eaf@mail.gmail.com> References: <200911251614.nAPGEXvU028096@belenus.iks-jena.de> <966645c70911250846g66a4279fk7c9228faf192e5a0@mail.gmail.com> <966645c70911250853m3a82250dy61cf0bd7e30a1eaf@mail.gmail.com> Message-ID: On Wed, 25 Nov 2009, Florian Frotzler wrote: > still quicker as teaching all your IT tools to speak v6... Use opensource, they are more IPv6 aware. By the way, you have to teach your IT tools to speak v6, since with 6RD you are using v6! Best Regards, Janos Mohacsi > > Cheers, > Florian > > 2009/11/25 Mohacsi Janos : >> >> >> >> On Wed, 25 Nov 2009, Florian Frotzler wrote: >> >>> Hi Lutz, >>> >>> I totally disagree with you :-) >>> >>> This would slow down the IPv6 rollout. IPv6-RD is a good choice to >>> bring IPv6 quickly to the customers and fight with the dual stack >>> implementation later. Maybe you are working at a small ISP, but in the >>> real world there are a lot of hazards on the way to implement end2end >>> v6, especially with large ISPs. >> >> 6rd is applicable only if the IP provider is controlling the CPE routers or >> 6rd is widely implemented in customers CPEs. So not so quick roll-out. >> ? ? ? ?Best Regards, >> ? ? ? ? ? ? ? ? ? ? ? ?Janos Mohacsi >> >> >>> >>> Cheers, >>> Florian >>> >>> 2009/11/25 Lutz Donnerhacke : >>>> >>>> In ripe.address-policy-wg, you wrote: >>>>> >>>>> we are planning to offer IPv6 connectivity to our xDSL and FTTH customer >>>>> base via IPv6-6RD. >>>> >>>> That's a bad idea. Please stick to 2002::/16 or simply provide native >>>> IPv6 >>>> in your backbone. >>>> >>>>> 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). >>>> >>>> We choosed to announce 2001:0:d911:c000::/52 as well as >>>> 2002:d911:c000::/36 >>>> in order to overcoming the anycast hassles for the first months. After >>>> that >>>> we had production stable IPv6 and dropped such tunneling hacks. >>>> >>>> I oppose handing out large amounts of address space for such legacy >>>> methods >>>> to save costs in IPv6 rollout. >>>> >>>> >>> >>> >> > From florian at frotzler.priv.at Wed Nov 25 20:09:45 2009 From: florian at frotzler.priv.at (Florian Frotzler) Date: Wed, 25 Nov 2009 20:09:45 +0100 Subject: AW: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: <200911251614.nAPGEXvU028096@belenus.iks-jena.de> <966645c70911250846g66a4279fk7c9228faf192e5a0@mail.gmail.com> <966645c70911250853m3a82250dy61cf0bd7e30a1eaf@mail.gmail.com> Message-ID: <001301ca6e02$daa11460$8fe33d20$@priv.at> No, using 6RD I do not need to account v6 and I do not need to provision network elements with v6. Ah yes, and my network elements in between do need to speak v6 so that I can leave them in their normal life cycle instead of investing a lot of money. Cheers, Florian -----Urspr?ngliche Nachricht----- Von: Mohacsi Janos [mailto:mohacsi at niif.hu] Gesendet: Mittwoch, 25. November 2009 19:23 An: Florian Frotzler Cc: address-policy-wg at ripe.net Betreff: Re: [address-policy-wg] IPv6 allocations for 6RD On Wed, 25 Nov 2009, Florian Frotzler wrote: > still quicker as teaching all your IT tools to speak v6... Use opensource, they are more IPv6 aware. By the way, you have to teach your IT tools to speak v6, since with 6RD you are using v6! Best Regards, Janos Mohacsi > > Cheers, > Florian > > 2009/11/25 Mohacsi Janos : >> >> >> >> On Wed, 25 Nov 2009, Florian Frotzler wrote: >> >>> Hi Lutz, >>> >>> I totally disagree with you :-) >>> >>> This would slow down the IPv6 rollout. IPv6-RD is a good choice to >>> bring IPv6 quickly to the customers and fight with the dual stack >>> implementation later. Maybe you are working at a small ISP, but in the >>> real world there are a lot of hazards on the way to implement end2end >>> v6, especially with large ISPs. >> >> 6rd is applicable only if the IP provider is controlling the CPE routers or >> 6rd is widely implemented in customers CPEs. So not so quick roll-out. >> ? ? ? ?Best Regards, >> ? ? ? ? ? ? ? ? ? ? ? ?Janos Mohacsi >> >> >>> >>> Cheers, >>> Florian >>> >>> 2009/11/25 Lutz Donnerhacke : >>>> >>>> In ripe.address-policy-wg, you wrote: >>>>> >>>>> we are planning to offer IPv6 connectivity to our xDSL and FTTH customer >>>>> base via IPv6-6RD. >>>> >>>> That's a bad idea. Please stick to 2002::/16 or simply provide native >>>> IPv6 >>>> in your backbone. >>>> >>>>> 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). >>>> >>>> We choosed to announce 2001:0:d911:c000::/52 as well as >>>> 2002:d911:c000::/36 >>>> in order to overcoming the anycast hassles for the first months. After >>>> that >>>> we had production stable IPv6 and dropped such tunneling hacks. >>>> >>>> I oppose handing out large amounts of address space for such legacy >>>> methods >>>> to save costs in IPv6 rollout. >>>> >>>> >>> >>> >> > From boogman at ip-plus.net Wed Nov 25 20:15:54 2009 From: boogman at ip-plus.net (Jan Boogman) Date: Wed, 25 Nov 2009 20:15:54 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: <200911251614.nAPGEXvU028096@belenus.iks-jena.de> <966645c70911250846g66a4279fk7c9228faf192e5a0@mail.gmail.com> Message-ID: One major CPE vendor gave us a commitment for early next year. 6RD is in the next Linux kernel and also at least one of the large router vendors is implementing 6RD gateway functionality for mid next year regards Jan Am 25.11.2009 um 17:51 schrieb Mohacsi Janos: > > > > On Wed, 25 Nov 2009, Florian Frotzler wrote: > >> Hi Lutz, >> >> I totally disagree with you :-) >> >> This would slow down the IPv6 rollout. IPv6-RD is a good choice to >> bring IPv6 quickly to the customers and fight with the dual stack >> implementation later. Maybe you are working at a small ISP, but in the >> real world there are a lot of hazards on the way to implement end2end >> v6, especially with large ISPs. > > 6rd is applicable only if the IP provider is controlling the CPE routers or 6rd is widely implemented in customers CPEs. So not so quick roll-out. > Best Regards, > Janos Mohacsi > > >> >> Cheers, >> Florian >> >> 2009/11/25 Lutz Donnerhacke : >>> In ripe.address-policy-wg, you wrote: >>>> we are planning to offer IPv6 connectivity to our xDSL and FTTH customer >>>> base via IPv6-6RD. >>> >>> That's a bad idea. Please stick to 2002::/16 or simply provide native IPv6 >>> in your backbone. >>> >>>> 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). >>> >>> We choosed to announce 2001:0:d911:c000::/52 as well as 2002:d911:c000::/36 >>> in order to overcoming the anycast hassles for the first months. After that >>> we had production stable IPv6 and dropped such tunneling hacks. >>> >>> I oppose handing out large amounts of address space for such legacy methods >>> to save costs in IPv6 rollout. >>> >>> >> >> > 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 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: [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 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: [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: [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 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: [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 mohacsi at niif.hu Thu Nov 26 09:36:20 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Thu, 26 Nov 2009 09:36:20 +0100 (CET) Subject: AW: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <001301ca6e02$daa11460$8fe33d20$@priv.at> References: <200911251614.nAPGEXvU028096@belenus.iks-jena.de> <966645c70911250846g66a4279fk7c9228faf192e5a0@mail.gmail.com> <966645c70911250853m3a82250dy61cf0bd7e30a1eaf@mail.gmail.com> <001301ca6e02$daa11460$8fe33d20$@priv.at> Message-ID: On Wed, 25 Nov 2009, Florian Frotzler wrote: > No, using 6RD I do not need to account v6 and I do not need to provision > network elements with v6. Ah yes, and my network elements in between do need > to speak v6 so that I can leave them in their normal life cycle instead of > investing a lot of money. You don't need provision CPE with IPv6, but you have to keep track IPv6 usage and allocations. You should be able to handle security incidents related to your IPv6 users. Better if you keep track complete IPv6 addresses, therefore some parts of your system needs v6 accounting. You can postopone upgrading some network elements to IPv6, but you need decent 6rd relay and IPv6 connectivity in your peers. Best Regards, Janos Mohacsi > > Cheers, > Florian > > -----Urspr?ngliche Nachricht----- > Von: Mohacsi Janos [mailto:mohacsi at niif.hu] > Gesendet: Mittwoch, 25. November 2009 19:23 > An: Florian Frotzler > Cc: address-policy-wg at ripe.net > Betreff: Re: [address-policy-wg] IPv6 allocations for 6RD > > > > > On Wed, 25 Nov 2009, Florian Frotzler wrote: > >> still quicker as teaching all your IT tools to speak v6... > > Use opensource, they are more IPv6 aware. By the way, you have to teach > your IT tools to speak v6, since with 6RD you are using v6! > > Best Regards, > Janos Mohacsi > > >> >> Cheers, >> Florian >> >> 2009/11/25 Mohacsi Janos : >>> >>> >>> >>> On Wed, 25 Nov 2009, Florian Frotzler wrote: >>> >>>> Hi Lutz, >>>> >>>> I totally disagree with you :-) >>>> >>>> This would slow down the IPv6 rollout. IPv6-RD is a good choice to >>>> bring IPv6 quickly to the customers and fight with the dual stack >>>> implementation later. Maybe you are working at a small ISP, but in the >>>> real world there are a lot of hazards on the way to implement end2end >>>> v6, especially with large ISPs. >>> >>> 6rd is applicable only if the IP provider is controlling the CPE routers > or >>> 6rd is widely implemented in customers CPEs. So not so quick roll-out. >>> ? ? ? ?Best Regards, >>> ? ? ? ? ? ? ? ? ? ? ? ?Janos Mohacsi >>> >>> >>>> >>>> Cheers, >>>> Florian >>>> >>>> 2009/11/25 Lutz Donnerhacke : >>>>> >>>>> In ripe.address-policy-wg, you wrote: >>>>>> >>>>>> we are planning to offer IPv6 connectivity to our xDSL and FTTH > customer >>>>>> base via IPv6-6RD. >>>>> >>>>> That's a bad idea. Please stick to 2002::/16 or simply provide native >>>>> IPv6 >>>>> in your backbone. >>>>> >>>>>> 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). >>>>> >>>>> We choosed to announce 2001:0:d911:c000::/52 as well as >>>>> 2002:d911:c000::/36 >>>>> in order to overcoming the anycast hassles for the first months. After >>>>> that >>>>> we had production stable IPv6 and dropped such tunneling hacks. >>>>> >>>>> I oppose handing out large amounts of address space for such legacy >>>>> methods >>>>> to save costs in IPv6 rollout. >>>>> >>>>> >>>> >>>> >>> >> > > 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: [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 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: [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 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: [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:24:21 2009 From: Remco.vanMook at eu.equinix.com (Remco van Mook) Date: Thu, 26 Nov 2009 10:24:21 +0100 Subject: [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 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 townsley at cisco.com Thu Nov 26 12:00:25 2009 From: townsley at cisco.com (Mark Townsley) Date: Thu, 26 Nov 2009 12:00:25 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD Message-ID: <4B0E5FC9.60202@cisco.com> All, My main goal with supporting 6rd is to see IPv6 deployed by Service Providers, preferably before the onslaught of CGNs leading to RFC1918 Private IPv4 as the new default Internet Access. As such, the fact that we are even having this conversation is rather encouraging. At the moment, 6rd accounts for the largest residential IPv6 Internet deployment to date. It's natural that some SPs are interested in replicating what has shown to work well for a neighboring SP. Not all of them want to go this route, but some do, and I?m thrilled as this very likely means a sooner IPv6 deployment in the world (at least among those SPs who see 6rd as their most viable alternative). I want to underscore here that we are not talking about forever allocating space away to a transition mechanism as was done with the /16 for 6to4, or the /32 for Teredo. Those address spaces will never be used for anything else, ever. The 6rd-related requests are, of course, for allocations to SPs that actually want to deploy IPv6 to their subscriber population in relative short order. One day, I hope that 6rd is not necessary for IPv6 deployment, but for the moment I'm firmly convinced that it is in a number of cases. Perhaps the WG could consider a temporary "early adopter" 6rd policy... e.g., for the next 3-5 years, those SPs that can show that native service is not economically viable for them, but commit that they can and will deploy with 6rd, will be allocated space necessary to get off the ground. At the end of this period, the WG could re-evaluate whether to abandon the more liberal policy in light of the ability to deploy natively at that time. As for the status of 6rd in the IETF, draft-townsley? is expired, and has been replaced by the Softwires Working Group document draft-ietf-softwire-ipv6-6rd-01.txt. Many Thanks, - Mark From tore at linpro.no Thu Nov 26 12:56:34 2009 From: tore at linpro.no (Tore Anderson) Date: Thu, 26 Nov 2009 12:56:34 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <4B0E5FC9.60202@cisco.com> References: <4B0E5FC9.60202@cisco.com> Message-ID: <4B0E6CF2.2020404@linpro.no> * Mark Townsley > I want to underscore here that we are not talking about forever > allocating space away to a transition mechanism as was done with the > /16 for 6to4, or the /32 for Teredo. Those address spaces will never > be used for anything else, ever. Free has 2a01:0e00::/26 allocated. Of this only one /28 is in use for 6rd (2a01:0e30::/28), the rest is network infrastructure and reserved for future use. To me that seems like a lot for even a big SP like Free. Perhaps allocation requests from Swisscom and other SPs that wants to use 6rd as a transition mechanism, could be handled like this instead: - A normal allocation of /32 (or whatever Swisscom would normally qualify for when disregarding 6rd) is granted. - A transition/6rd-only allocation of /28 valid only for as long as 6rd remains in use, is also granted. Later, when Swisscom complete their transition to native v6 and no longer use 6rd, the /28 can be easily reclaimed. Would something like this work for you, Jan? The two allocations could possibly be from the same /27 so that they can be announced as an aggregate, but in that case the unallocated space in that /27 would of course be unavailable for allocation to other SPs, and then there's always the chance that it will end up in use anyway (whether maliciously or not), so I'm not sure if would be worth it. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From randy at psg.com Thu Nov 26 13:25:31 2009 From: randy at psg.com (Randy Bush) Date: Thu, 26 Nov 2009 21:25:31 +0900 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <4B0E5FC9.60202@cisco.com> References: <4B0E5FC9.60202@cisco.com> Message-ID: > My main goal with supporting 6rd is to see IPv6 deployed by Service > Providers, preferably before the onslaught of CGNs leading to RFC1918 > Private IPv4 as the new default Internet Access. excuse that i am a little slow. how does 6rd address/obviate the issue which seem to drive ntt and others to cgn? from my understanding, it just lets end sites, who could care less, live in an ipv6 world through the nat4444444 core. randy From Remco.vanMook at eu.equinix.com Thu Nov 26 13:25:28 2009 From: Remco.vanMook at eu.equinix.com (Remco van Mook) Date: Thu, 26 Nov 2009 13:25:28 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD References: <4B0E5FC9.60202@cisco.com> Message-ID: <25B76451F7215744AFD4195362E55A1CF3470C@NLEN1EX1.eu.win.equinix.com> Hi Mark, thanks for your response. I'm also happy to see a feasible way of doing IPv6 deployment being developed; however I think this audience (including me) needs some guidance on how to apply address policy in this particular case. I agree that 6rd probably won't be the long term way of deploying IPv6. However, what's being suggested now is that 6rd in an environment with non-contiguous allocations pretty much *requires* reserving 32 bits (plus 4-8 bits for user prefixes) of v6-space for every single ISP out there because the aggregate set of IPv4 allocations to that ISP can't be compressed. I don't think that was how it was intended or how it should work. I hope you can help us shed some light here. Best, Remco -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Mark Townsley Sent: donderdag 26 november 2009 12:00 To: address-policy-wg at ripe.net Subject: RE: [address-policy-wg] IPv6 allocations for 6RD All, My main goal with supporting 6rd is to see IPv6 deployed by Service Providers, preferably before the onslaught of CGNs leading to RFC1918 Private IPv4 as the new default Internet Access. As such, the fact that we are even having this conversation is rather encouraging. At the moment, 6rd accounts for the largest residential IPv6 Internet deployment to date. It's natural that some SPs are interested in replicating what has shown to work well for a neighboring SP. Not all of them want to go this route, but some do, and I'm thrilled as this very likely means a sooner IPv6 deployment in the world (at least among those SPs who see 6rd as their most viable alternative). I want to underscore here that we are not talking about forever allocating space away to a transition mechanism as was done with the /16 for 6to4, or the /32 for Teredo. Those address spaces will never be used for anything else, ever. The 6rd-related requests are, of course, for allocations to SPs that actually want to deploy IPv6 to their subscriber population in relative short order. One day, I hope that 6rd is not necessary for IPv6 deployment, but for the moment I'm firmly convinced that it is in a number of cases. Perhaps the WG could consider a temporary "early adopter" 6rd policy... e.g., for the next 3-5 years, those SPs that can show that native service is not economically viable for them, but commit that they can and will deploy with 6rd, will be allocated space necessary to get off the ground. At the end of this period, the WG could re-evaluate whether to abandon the more liberal policy in light of the ability to deploy natively at that time. As for the status of 6rd in the IETF, draft-townsley... is expired, and has been replaced by the Softwires Working Group document draft-ietf-softwire-ipv6-6rd-01.txt. Many Thanks, - Mark 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 townsley at cisco.com Thu Nov 26 13:40:08 2009 From: townsley at cisco.com (Mark Townsley) Date: Thu, 26 Nov 2009 13:40:08 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: <4B0E5FC9.60202@cisco.com> Message-ID: <4B0E7728.3060609@cisco.com> Hi Randy, This statement refers back to something I presented at the last AMS RIPE meeting. There, I tried to underscore the point that we are at an inflection point in IPv4 NAT deployment, similar to the one we entered 10 years ago or so when the first level of NAT came on the scene. Then, the first level of NAT broke some applications that expected a global IPv4 address, and they eventually evolved to work around it (and so did perception of the average Internet user). The second level of NAT will break more, and there will be more evolution and change of perception. What I'd like to see is enough IPv6 out there at the same time this turmoil is taking place that the applications see value in including IPv6 in their repertoire of connectivity options. Hence the deadline in my mind that IPv6 needs to reach some level of critical mass to the end user before NAT44444 reaches a certain level of prevalence. It's essentially a war between these two, and I see 6rd as a weapon on the side of IPv6. Viable IPv6-only service to the residential home is a long way off, and that's not what I am suggesting. What I am suggesting is that 6rd moves up the timeline for dual-stack IPv4 (perhaps natted) and IPv6 deployment for at least some SPs. And, that this may be critically important for the success of IPv6. - Mark Randy Bush wrote: >> My main goal with supporting 6rd is to see IPv6 deployed by Service >> Providers, preferably before the onslaught of CGNs leading to RFC1918 >> Private IPv4 as the new default Internet Access. >> > > excuse that i am a little slow. how does 6rd address/obviate the issue > which seem to drive ntt and others to cgn? from my understanding, it > just lets end sites, who could care less, live in an ipv6 world through > the nat4444444 core. > > randy > > From lutz at iks-jena.de Thu Nov 26 13:17:13 2009 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Thu, 26 Nov 2009 12:17:13 +0000 (UTC) Subject: [address-policy-wg] IPv6 allocations for 6RD References: <4B0E5FC9.60202@cisco.com> Message-ID: * Mark Townsley wrote: > As for the status of 6rd in the IETF, draft-townsley? is expired, and > has been replaced by the Softwires Working Group document > draft-ietf-softwire-ipv6-6rd-01.txt. I still reading this draft and try hard to find the benefit over announcing more specific routes in 2002::/16. Can you please hit me into the right direction? > Perhaps the WG could consider a temporary "early adopter" 6rd policy... > e.g., for the next 3-5 years, those SPs that can show that native > service is not economically viable for them, but commit that they can > and will deploy with 6rd, will be allocated space necessary to get off I oppose handing out huge amounts of address space which is guaranteed to fit into a single prefix when removing protocol inherent holes. I'd favor inserting RPSL route objects below 2002::/16 by the RIR based on the corresponding IPv4 allocations. This process can be requested by the LIR and has a limited timescale (multiple renew allowed). From townsley at cisco.com Thu Nov 26 13:49:20 2009 From: townsley at cisco.com (Mark Townsley) Date: Thu, 26 Nov 2009 13:49:20 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <25B76451F7215744AFD4195362E55A1CF3470C@NLEN1EX1.eu.win.equinix.com> References: <4B0E5FC9.60202@cisco.com> <25B76451F7215744AFD4195362E55A1CF3470C@NLEN1EX1.eu.win.equinix.com> Message-ID: <4B0E7950.4070605@cisco.com> Remco van Mook wrote: > Hi Mark, > > thanks for your response. I'm also happy to see a feasible way of doing > IPv6 deployment being developed; however I think this audience > (including me) needs some guidance on how to apply address policy in > this particular case. I agree that 6rd probably won't be the long term > way of deploying IPv6. > I've seen a couple of suggestions so far. One from me, another from Tore, that allow an SP the 6rd option without unduly polluting the address space. And that's just day one, so it looks like there might be some viable options here. > However, what's being suggested now is that 6rd in an environment with > non-contiguous allocations pretty much *requires* reserving 32 bits > (plus 4-8 bits for user prefixes) of v6-space for every single ISP out > there because the aggregate set of IPv4 allocations to that ISP can't be > compressed. Not every single ISP out there, but for every single ISP that intends to use 6rd. Not all will, but some will, particularly those who want to move more quickly down the IPv6 delivery path - something that I can't help but be in passionate support of. > I don't think that was how it was intended or how it should > work. > Well, *intentions* were that native IPv6 service would be possible to everyone many years ago. So much for good intentions. I'd like to see the WG at least consider the various options for SPs that want to replicate Free's success in IPv6 deployment. The large SPs that already claimed their /19 or /20 years ago don't have to worry about that whether they are using the space or not, but the other SPs should get a fair shake as well. > I hope you can help us shed some light here. > Hope that helps, and that the WG can come up with some constructive options here. - Mark > Best, > > Remco > > -----Original Message----- > From: address-policy-wg-admin at ripe.net > [mailto:address-policy-wg-admin at ripe.net] On Behalf Of Mark Townsley > Sent: donderdag 26 november 2009 12:00 > To: address-policy-wg at ripe.net > Subject: RE: [address-policy-wg] IPv6 allocations for 6RD > > > All, > > My main goal with supporting 6rd is to see IPv6 deployed by Service > Providers, preferably before the onslaught of CGNs leading to RFC1918 > Private IPv4 as the new default Internet Access. As such, the fact that > we are even having this conversation is rather encouraging. > > At the moment, 6rd accounts for the largest residential IPv6 Internet > deployment to date. It's natural that some SPs are interested in > replicating what has shown to work well for a neighboring SP. Not all of > > them want to go this route, but some do, and I'm thrilled as this very > likely means a sooner IPv6 deployment in the world (at least among those > > SPs who see 6rd as their most viable alternative). I want to underscore > here that we are not talking about forever allocating space away to a > transition mechanism as was done with the /16 for 6to4, or the /32 for > Teredo. Those address spaces will never be used for anything else, ever. > > The 6rd-related requests are, of course, for allocations to SPs that > actually want to deploy IPv6 to their subscriber population in relative > short order. One day, I hope that 6rd is not necessary for IPv6 > deployment, but for the moment I'm firmly convinced that it is in a > number of cases. > > Perhaps the WG could consider a temporary "early adopter" 6rd policy... > e.g., for the next 3-5 years, those SPs that can show that native > service is not economically viable for them, but commit that they can > and will deploy with 6rd, will be allocated space necessary to get off > the ground. At the end of this period, the WG could re-evaluate whether > to abandon the more liberal policy in light of the ability to deploy > natively at that time. > > As for the status of 6rd in the IETF, draft-townsley... is expired, and > has been replaced by the Softwires Working Group document > draft-ietf-softwire-ipv6-6rd-01.txt. > > Many Thanks, > > - Mark > > > > 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 randy at psg.com Thu Nov 26 13:53:40 2009 From: randy at psg.com (Randy Bush) Date: Thu, 26 Nov 2009 21:53:40 +0900 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <4B0E7728.3060609@cisco.com> References: <4B0E5FC9.60202@cisco.com> <4B0E7728.3060609@cisco.com> Message-ID: > This statement refers back to something I presented at the last AMS RIPE > meeting. There, I tried to underscore the point that we are at an > inflection point in IPv4 NAT deployment, similar to the one we entered > 10 years ago or so when the first level of NAT came on the scene. Then, > the first level of NAT broke some applications that expected a global > IPv4 address, and they eventually evolved to work around it (and so did > perception of the average Internet user). The second level of NAT will > break more, and there will be more evolution and change of perception. > What I'd like to see is enough IPv6 out there at the same time this > turmoil is taking place that the applications see value in including > IPv6 in their repertoire of connectivity options. Hence the deadline in > my mind that IPv6 needs to reach some level of critical mass to the end > user before NAT44444 reaches a certain level of prevalence. It's > essentially a war between these two, and I see 6rd as a weapon on the > side of IPv6. > > Viable IPv6-only service to the residential home is a long way off, and > that's not what I am suggesting. What I am suggesting is that 6rd moves > up the timeline for dual-stack IPv4 (perhaps natted) and IPv6 deployment > for at least some SPs. And, that this may be critically important for > the success of IPv6. > > - Mark > > Randy Bush wrote: >>> My main goal with supporting 6rd is to see IPv6 deployed by Service >>> Providers, preferably before the onslaught of CGNs leading to RFC1918 >>> Private IPv4 as the new default Internet Access. >>> >> >> excuse that i am a little slow. how does 6rd address/obviate the issue >> which seem to drive ntt and others to cgn? from my understanding, it >> just lets end sites, who could care less, live in an ipv6 world through >> the nat4444444 core. lemme try once more. i think 6rd is cool. and it certainly is better than teredo and similar . but ... it does nothing to stave off nat44444 deployment as it does not address the big broadband provider's cloud address space issue. it lets an end site punch ipv6 through the nat44444, but why does the home user care if they're in 1918 space or ipv6 space? as you say, end user apps may be encouraged to become v6 capable. but aren't almost all v6 capable now, or moving quickly? so no harm. it's cool. but nothing to slow the horror of nat44444, which is gonna essentially break the internet. randy 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: [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 gert at space.net Thu Nov 26 14:29:10 2009 From: gert at space.net (Gert Doering) Date: Thu, 26 Nov 2009 14:29:10 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: <4B0E5FC9.60202@cisco.com> Message-ID: <20091126132910.GF32226@Space.Net> Hi, On Thu, Nov 26, 2009 at 12:17:13PM +0000, Lutz Donnerhacke wrote: > * Mark Townsley wrote: > > As for the status of 6rd in the IETF, draft-townsley??? is expired, and > > has been replaced by the Softwires Working Group document > > draft-ietf-softwire-ipv6-6rd-01.txt. > > I still reading this draft and try hard to find the benefit over announcing > more specific routes in 2002::/16. > > Can you please hit me into the right direction? Use of the same (known and working) technology without extra global routes (assuming that the ISP has a "normal" prefix in addition to the prefix used for 6rd) and without the mess created by not-really-working 6to4 relays and asymmetric paths. With 2002:: in use inside an ISP, packets from 6to4 aware peer hosts out in the world will be encapsulated into IPv4 at the sending host, and then travel over potentially broken IPv4 paths, instead of travelling natively IPv6 up to the ISPs relay... Gert Doering -- just argueing technology -- 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 tore at linpro.no Thu Nov 26 14:48:11 2009 From: tore at linpro.no (Tore Anderson) Date: Thu, 26 Nov 2009 14:48:11 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: <4B0E5FC9.60202@cisco.com> Message-ID: <4B0E871B.7060803@linpro.no> * Lutz Donnerhacke > I still reading this draft and try hard to find the benefit over > announcing more specific routes in 2002::/16. > > Can you please hit me into the right direction? RFC 3068. Modern client applications will prefer using IPv4 over IPv6 to connect to remote servers, if the local systems' IPv6 address is within 2002::/16. Even when behind IPv4 NAT. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27 From marcoh at marcoh.net Thu Nov 26 14:51:12 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Thu, 26 Nov 2009 14:51:12 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <4B0E871B.7060803@linpro.no> References: <4B0E5FC9.60202@cisco.com> <4B0E871B.7060803@linpro.no> Message-ID: <915F9989-1FD0-4922-A9F3-ABAACE7E07AF@marcoh.net> On 26 nov 2009, at 14:48, Tore Anderson wrote: > * Lutz Donnerhacke > >> I still reading this draft and try hard to find the benefit over >> announcing more specific routes in 2002::/16. >> >> Can you please hit me into the right direction? > > RFC 3068. Modern client applications will prefer using IPv4 over IPv6 > to connect to remote servers, if the local systems' IPv6 address is > within 2002::/16. Even when behind IPv4 NAT. Doesn't seem to be a problem in running 6rd since it's all designed to keep running IPv4 instead of IPv6. Groet, MarcoH 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 lutz at iks-jena.de Thu Nov 26 17:53:22 2009 From: lutz at iks-jena.de (Lutz Donnerhacke) Date: Thu, 26 Nov 2009 16:53:22 +0000 (UTC) Subject: [address-policy-wg] IPv6 allocations for 6RD References: <20091126132910.GF32226@Space.Net> Message-ID: * Gert Doering wrote: > Use of the same (known and working) technology without extra global > routes (assuming that the ISP has a "normal" prefix in addition to the > prefix used for 6rd) and without the mess created by not-really-working > 6to4 relays and asymmetric paths. You are suggesting to assign a new IP prefix every time, some implemtations out there fucked up? If you can't live with anycast, go and announce our unicast more specific! > With 2002:: in use inside an ISP, packets from 6to4 aware peer hosts out > in the world will be encapsulated into IPv4 at the sending host, and > then travel over potentially broken IPv4 paths, instead of travelling > natively IPv6 up to the ISPs relay... No, they don't otherwise firewalls would not work with IPv6 and 6to4 at all. Any nativly IPv6 connected host respond to any request from IPv6 addresses using IPv6. I see you point, that more specifics of 2002::/16 are disallowed by RFC3056, but this can easily be changed. 6rd uses the same way to modify RFC3056: It requires a huge parallel prefix (and route) per ISP. In order to overcome the situation I submitted a draft to the IETF. http://www.ietf.org/id/draft-donnerhacke-softwire-ipv6-6to4-00.txt Have fun. From berni at birkenwald.de Thu Nov 26 18:09:56 2009 From: berni at birkenwald.de (Bernhard Schmidt) Date: Thu, 26 Nov 2009 18:09:56 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: <20091126132910.GF32226@Space.Net> Message-ID: <4B0EB664.5070206@birkenwald.de> Hi, > I see you point, that more specifics of 2002::/16 are disallowed by RFC3056, > but this can easily be changed. 6rd uses the same way to modify RFC3056: It > requires a huge parallel prefix (and route) per ISP. > > In order to overcome the situation I submitted a draft to the IETF. > http://www.ietf.org/id/draft-donnerhacke-softwire-ipv6-6to4-00.txt Yeah, nice idea. Why not have router implementations do that by default? We just have hit 300k routes in IPv4, I see no reason why we should not have that amount in IPv6 as well. Bernhard From gert at space.net Thu Nov 26 19:18:32 2009 From: gert at space.net (Gert Doering) Date: Thu, 26 Nov 2009 19:18:32 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: <20091126132910.GF32226@Space.Net> Message-ID: <20091126181832.GL32226@Space.Net> Hi, On Thu, Nov 26, 2009 at 04:53:22PM +0000, Lutz Donnerhacke wrote: > I see you point, that more specifics of 2002::/16 are disallowed by RFC3056, > but this can easily be changed. 6rd uses the same way to modify RFC3056: It > requires a huge parallel prefix (and route) per ISP. Well, the point is that 6rd does *not* require another prefix per ISP, if done within their LIR allocation. As opposed to announce umpteen IPv4 prefixes that this LIR holds as more-specifics under 2002::/16. A second prefix for 6rd is only required under the proposal that a LIR could get a second (larger) temporary prefix to deploy IPv6 via 6rd, and later return that when all the network has migrated to "native" internal IPv6. I'm not convinced that this is a workable approach, as the criteria for "this has to be returned, if ...!" are usually quite hard to judge from the outside, and people tend to forget about good intentions... Gert Doering -- technologist -- 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 marc.neuckens at belgacom.be Thu Nov 26 23:23:06 2009 From: marc.neuckens at belgacom.be (marc.neuckens at belgacom.be) Date: Thu, 26 Nov 2009 23:23:06 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <20091126181832.GL32226@Space.Net> References: <20091126132910.GF32226@Space.Net> <20091126181832.GL32226@Space.Net> Message-ID: I read in the paragraph 4 (IPv6 Policy Principles) of the IPv6 Address Allocation and Assignment Policy : --------------- 4.4. Consideration of IPv4 infrastructure Where an existing IPv4 service provider requests IPv6 space for eventual transition of existing services to IPv6, the number of present IPv4 customers may be used to justify a larger request than would be justified if based solely on the IPv6 infrastructure. ------------- I suppose this justifies the request, no ? I don't see any problem in allocating an ipv6 allocation bigger than /32 for ISP with millions of existing customers. Who knows how many subnets we will assign in 10, 20 years. A /32 is only 2^16 or 16 million /56 subnets or 65536 /48. I prefer this than allocate now a /32, in 2 years extend to a /30 and then to a /27 and then an other /27. (even if the other /32 in the /27 are not allocated to other LIR) It all depends on how future-proof the address plan is. What is used now for 6rd and transition can be reused in the LIR for extra customers / applications in 5 years. Marc Neuckens Belgacom **** DISCLAIMER **** http://www.belgacom.be/maildisclaimer From chapuis at ip-plus.net Fri Nov 27 07:08:22 2009 From: chapuis at ip-plus.net (Andre Chapuis) Date: Fri, 27 Nov 2009 07:08:22 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: <20091126132910.GF32226@Space.Net> <20091126181832.GL32226@Space.Net> Message-ID: <4B0F6CD6.2020200@ip-plus.net> I fully agree with Marc: the policy currently allows allocating more than /32, so I see no need to change it. We are facing here a principle discussion. - the "R" in 6RD stays for "Rapid". And this is the most important point to consider. If we can rapidly bring millions of users to IPv6 without investing in big hardware/design changes (part. in these crisis times), combined with guys like Google/Youtube bringing traffic, then (and only then) v6 will become a reality. So this is in the interest of the RIPE community to make that happens. We have a successful POC with Free.fr - For the RIPE-NCC, this is imho even more important to push for v6 deployment and therefore to remove any potential obstacle for the ISPs and encourage them to implement 6-RD or similar solutions. If even getting IPv6 addresses becomes a fight, most ISPs may give up, since there is still no business case to justify it. Otherwise, in 2 years, the RIPE-NCC will have to be staffed with only 2-3 IPRAs and about 50 lawyers, since the market-price for IPv4 addresses will drive a huge business. (and to pay the lawyers, the membership fees will have to be about x10) Andr? marc.neuckens at belgacom.be wrote: > I read in the paragraph 4 (IPv6 Policy Principles) of the IPv6 Address Allocation and Assignment Policy : > > --------------- > 4.4. Consideration of IPv4 infrastructure > Where an existing IPv4 service provider requests IPv6 space for eventual transition of existing services to IPv6, the number of present IPv4 customers may be used to justify a larger request than would be justified if based solely on the IPv6 infrastructure. > ------------- > > I suppose this justifies the request, no ? > > I don't see any problem in allocating an ipv6 allocation bigger than /32 for ISP with millions of existing customers. > Who knows how many subnets we will assign in 10, 20 years. > > A /32 is only 2^16 or 16 million /56 subnets or 65536 /48. > > I prefer this than allocate now a /32, in 2 years extend to a /30 and then to a /27 and then an other /27. > (even if the other /32 in the /27 are not allocated to other LIR) > > It all depends on how future-proof the address plan is. > > What is used now for 6rd and transition can be reused in the LIR for extra customers / applications in 5 years. > > Marc Neuckens > Belgacom > > > **** DISCLAIMER **** > http://www.belgacom.be/maildisclaimer > From swmike at swm.pp.se Fri Nov 27 07:36:08 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 27 Nov 2009 07:36:08 +0100 (CET) Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <4B0F6CD6.2020200@ip-plus.net> References: <20091126132910.GF32226@Space.Net> <20091126181832.GL32226@Space.Net> <4B0F6CD6.2020200@ip-plus.net> Message-ID: On Fri, 27 Nov 2009, Andre Chapuis wrote: > - For the RIPE-NCC, this is imho even more important to push for v6 > deployment and therefore to remove any potential obstacle for the ISPs and > encourage them to implement 6-RD or similar solutions. 6RD can be adapted to work without mapping the entire 32 bits of IPv4 into IPv6. Also, if someone wants to deploy 6RD and do map entire IPv4 into IPv6 then I think they should be incetivised to get rid of it quickly as well, thus not allow /56 or /60 to each customer, but only a /64. This would mean ISPs could make do with their /32 they already have, and then they can put their native IPv6 customers into the IPv6 equivalent of 224.0.0.0/3 because there will be no 6RD traffic there. If someone wants to offer larger networks then they need to do 6RD smarter, instead of mapping the entire IPv4 space into IPv6. I do *not* think 6RD bad design (or implementation) should warrant giving each ISP a /24 or /28. -- Mikael Abrahamsson email: swmike at swm.pp.se From townsley at cisco.com Fri Nov 27 09:05:17 2009 From: townsley at cisco.com (Mark Townsley) Date: Fri, 27 Nov 2009 09:05:17 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: <20091126132910.GF32226@Space.Net> <20091126181832.GL32226@Space.Net> <4B0F6CD6.2020200@ip-plus.net> Message-ID: <4B0F883D.1050105@cisco.com> Mikael Abrahamsson wrote: > On Fri, 27 Nov 2009, Andre Chapuis wrote: > >> - For the RIPE-NCC, this is imho even more important to push for v6 >> deployment and therefore to remove any potential obstacle for the >> ISPs and encourage them to implement 6-RD or similar solutions. > > 6RD can be adapted to work without mapping the entire 32 bits of IPv4 > into IPv6. Also, if someone wants to deploy 6RD and do map entire IPv4 > into IPv6 then I think they should be incetivised to get rid of it > quickly as well, thus not allow /56 or /60 to each customer, but only > a /64. This would mean ISPs could make do with their /32 they already > have, and then they can put their native IPv6 customers into the IPv6 > equivalent of 224.0.0.0/3 because there will be no 6RD traffic there. I don't think that incentive is terribly realistic, and is if anything a recipe for IPv6 forever remaining a bridged service in the home, or worse, a further incentive for the adoption of IPv6 NAT. The incentive to move away from 6rd will be when IPv6 traffic and subscriber adoption reach levels where the associated economies of scale for IPv6-enabled equipment, applications, operational knowledge, etc. are at the point where it is economically viable to deploy natively vs. IPv4 alone. We're not there yet, but 6rd is helping. - Mark > > If someone wants to offer larger networks then they need to do 6RD > smarter, instead of mapping the entire IPv4 space into IPv6. > > I do *not* think 6RD bad design (or implementation) should warrant > giving each ISP a /24 or /28. > From townsley at cisco.com Fri Nov 27 09:39:34 2009 From: townsley at cisco.com (Mark Townsley) Date: Fri, 27 Nov 2009 09:39:34 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: <20091126132910.GF32226@Space.Net> <20091126181832.GL32226@Space.Net> Message-ID: <4B0F9046.7030000@cisco.com> marc.neuckens at belgacom.be wrote: > I read in the paragraph 4 (IPv6 Policy Principles) of the IPv6 Address Allocation and Assignment Policy : > > --------------- > 4.4. Consideration of IPv4 infrastructure > Where an existing IPv4 service provider requests IPv6 space for eventual transition of existing services to IPv6, the number of present IPv4 customers may be used to justify a larger request than would be justified if based solely on the IPv6 infrastructure. > ------------- > > I suppose this justifies the request, no ? > It does seem to allow for quite a bit of leeway. I wonder though if smaller ISPs (without many IPv4 users to base upon) might get stuck out in the cold though. One argument given on this thread was that smaller ISPs might be more able to natively deploy, but on the other hand it's smaller ISPs that may not have the (legal or otherwise) ability to upgrade the non-IPv6 capable access network that 6rd is so good at getting around. Small ISPs also happen to be the kind that typically can deploy bleeding edge new services like IPv6. So, before saying we're done on this alone, I'd like to at least know that we are not holding up small ISPs willing to deploy IPv6 to all their customers in, say, 2010 iff they can use 6rd. > I don't see any problem in allocating an ipv6 allocation bigger than /32 for ISP with millions of existing customers. > Who knows how many subnets we will assign in 10, 20 years. > > A /32 is only 2^16 or 16 million /56 subnets or 65536 /48. > So strictly speaking, for a /28 prefix (6rd /60 to the customer with no IPv4 compression), basing upon eventual service of /48 to all sites when the transition is gone, an ISP needs 2^20 IPv4 customers today. That seems to be the bar: If you are an ISP with one million subscribers, you have the option of a /28 to deploy 6rd under current policy (two or four million to sit comfortably with a /27 or /26 like Free). I'd like to know if there are smaller ISPs wanting to deploy with 6rd, and whether compression is an option, etc. I'm pretty sure there are at least one or two, but a I doubt all that many. If I'm right, opening the door a little more widely to just these few I cannot imagine is all that dangerous, and perhaps could even happen under current policy. > I prefer this than allocate now a /32, in 2 years extend to a /30 and then to a /27 and then an other /27. > (even if the other /32 in the /27 are not allocated to other LIR) > > It all depends on how future-proof the address plan is. > > What is used now for 6rd and transition can be reused in the LIR for extra customers / applications in 5 years. > Absolutely. And, if you give a little extra space to someone who *actually* deploys IPv6 now vs. later, I'd say that's a prize worth giving :-) - Mark > Marc Neuckens > Belgacom > > > **** DISCLAIMER **** > http://www.belgacom.be/maildisclaimer > > > From michael.dillon at bt.com Fri Nov 27 11:04:20 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 27 Nov 2009 10:04:20 -0000 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <25B76451F7215744AFD4195362E55A1CF3465E@NLEN1EX1.eu.win.equinix.com> Message-ID: <28E139F46D45AF49A31950F88C4974580442E1A1@E03MVZ2-UKDY.domain1.systemhost.net> > 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 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: [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: [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: [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: [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: [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: [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 remi.despres at free.fr Fri Nov 27 18:21:48 2009 From: remi.despres at free.fr (=?iso-8859-1?Q?R=E9mi_Despr=E9s?=) Date: Fri, 27 Nov 2009 18:21:48 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <316CA4C4-1445-45EC-AD50-6391C9330BD0@free.fr> References: <316CA4C4-1445-45EC-AD50-6391C9330BD0@free.fr> Message-ID: <57D61E37-F4CB-4471-92EF-134082A7EE5A@free.fr> Le 27 nov. 2009 ? 17:16, R?mi Despr?s a ?crit : > Mikael Abrahamsson wrote: > > I do *not* think 6RD bad design (or implementation) should warrant giving each ISP a /24 or /28. The objective of 6rd has been to make native IPv6 connectivity quickly available to millions of residential customers. For this, it was important to relieve the first concerned ISP of fear, uncertainty, and doubt, concerning expenses to be incurred. This objective has been brilliantly achieved when Free, after only 5 weeks, evolved from "we don't want to spend a Euro on IPv6" to "IPv6 is available to our customers who wish to activate it with a click". If promoting IPv6, not only with words but also in reality, is considered a legitimate objective, then it is fair to view 6rd as a "good design" for what it was set to achieve. Similarly, what Free did should be seen as a "remarkably fast and effective implementation". No hard feelings, but I felt this needed to be said. Regards, RD (Inventor of 6rd, no professional link with Free.) From swmike at swm.pp.se Fri Nov 27 19:36:33 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 27 Nov 2009 19:36:33 +0100 (CET) Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <57D61E37-F4CB-4471-92EF-134082A7EE5A@free.fr> References: <316CA4C4-1445-45EC-AD50-6391C9330BD0@free.fr> <57D61E37-F4CB-4471-92EF-134082A7EE5A@free.fr> Message-ID: On Fri, 27 Nov 2009, R?mi Despr?s wrote: > No hard feelings, but I felt this needed to be said. There is nothing wrong with 6RD in principle, it's when people map the entire IPv4 space into IPv6 blindly and then use a small fraction of it that it becomes wasteful. I don't have a problem with ISPs will millions of subscribers getting a /24, I have a problem when "every" mom and pop ISP with an AS number is getting a /24 because they want to run 6RD. As long as the policy incurs that you need to have a certain amount of customers to warrant running 6RD using all of IPv4 space and thus needing /24 or /28, otherwise you'd better map a smaller part of it and then you'll be able to fit it just fine into your /32 most likely. -- Mikael Abrahamsson email: swmike at swm.pp.se From michael.dillon at bt.com Fri Nov 27 21:34:51 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Fri, 27 Nov 2009 20:34:51 -0000 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: Message-ID: <28E139F46D45AF49A31950F88C49745804488337@E03MVZ2-UKDY.domain1.systemhost.net> > > No hard feelings, but I felt this needed to be said. > > There is nothing wrong with 6RD in principle, it's when > people map the entire IPv4 space into IPv6 blindly and then > use a small fraction of it that it becomes wasteful. This is not wasteful. It is an elegant extension to the IPv6 architecture. Using a standard /64 prefix for all network segments containing more than a single device, is also an elegant solution and is part of the IPv6 standard. The same is true of the standard /48 assignment per site which provides every site with 8 bits of space to subnet their site into /64 networks, regardless of whether they "need" 1 subnet or 100 subnets. Numbers cost nothing. By "wasting" lots of numbers, we can achieve a simpler design that saves real money, and real effort for millions of people building and managing IPv6 networks. IPv4 had a very limited address space and we had to be very careful about wasting numbers until there was a new protocol ready to replace it. That time has come, so there is no need to talk about wasting numbers any more. In reality, the issue wasn't how many numbers were wasted, but what percentage of the total number space was wasted. In IPv6, by design, we are putting entire ISPs into the same percentage of the total number space, /32, as a single host in IPv4. > I don't have a problem with ISPs will millions of subscribers > getting a /24, I have a problem when "every" mom and pop ISP > with an AS number is getting a /24 because they want to run 6RD. In IPv4, we gave out /24 blocks to actual real mom and pop ISPs not just metaphorical ones. I see no reason to treat IPv6 as a more scarce resource to IPv4, and therefore, if a mom and pop ISP really does need a /24 to transition using 6RD, then I would say we should give it to them. However, I suspect that small ISPs like that would not actually require a /24 to effectively do 6RD. > As long as the policy incurs that you need to have a certain > amount of customers to warrant running 6RD using all of IPv4 > space and thus needing > /24 or /28, otherwise you'd better map a smaller part of it > and then you'll be able to fit it just fine into your /32 most likely. You have probably written more detail on what a 6RD policy would look like than anyone so far. For the sake of clarity, perhaps you could submit a policy proposal and then we will all have something specific to discuss. I would support a special policy for 6RD even if it does nothing more than clarify how RIPE currently treats IPv6 requests for use with 6RD. --Michael Dillon From swmike at swm.pp.se Fri Nov 27 22:17:08 2009 From: swmike at swm.pp.se (Mikael Abrahamsson) Date: Fri, 27 Nov 2009 22:17:08 +0100 (CET) Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <28E139F46D45AF49A31950F88C49745804488337@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C49745804488337@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: On Fri, 27 Nov 2009, michael.dillon at bt.com wrote: > This is not wasteful. It is an elegant extension to the IPv6 > architecture. Using a standard /64 prefix for all network segments > containing more than a single device, is also an elegant solution and is > part of the IPv6 standard. The same is true of the standard /48 > assignment per site which provides every site with 8 bits of space to > subnet their site into /64 networks, regardless of whether they "need" 1 > subnet or 100 subnets. 16 bits between /48 and /64, but apart from that I'm in total agreement with you. > Numbers cost nothing. By "wasting" lots of numbers, we can > achieve a simpler design that saves real money, and real effort > for millions of people building and managing IPv6 networks. The thing here is that if you have an AS then you qualify for a /32. What I don't like about this policy is that then you come around and say "6RD" and then you get a /24 as well, this leads to DFZ pollution. > IPv4 had a very limited address space and we had to be very > careful about wasting numbers until there was a new protocol > ready to replace it. That time has come, so there is no need > to talk about wasting numbers any more. If all ASNs do this then we'll have done away with /8. That's not a large part of IPv6 space, so perhaps it's ok. > In IPv4, we gave out /24 blocks to actual real mom and pop ISPs I didn't say this was right. DFZ pollution. > not just metaphorical ones. I see no reason to treat IPv6 as > a more scarce resource to IPv4, and therefore, if a mom and pop > ISP really does need a /24 to transition using 6RD, then I would > say we should give it to them. However, I suspect that small ISPs > like that would not actually require a /24 to effectively do 6RD. How do you judge if they "really need it"? > You have probably written more detail on what a 6RD policy would look > like than anyone so far. For the sake of clarity, perhaps you could > submit a policy proposal and then we will all have something > specific to discuss. I'll write it in regular form then, grabbing some arbitrary numbers off the top of my head without any real motivation, because there are no hard limits. I'll put in some unjustified sticks with the carrots as well. here goes: An ISP/ASN qualifies for a /24 for 6RD if they fulfil the following criteria: * Have at least 4 different IPv4 subnets they have customers who will use 6RD in. * Will hand out /56 subnets to 6RD enabled customers. * Will return (if any) existing /32 IPv6 space already assigned, and use the highest /32 in the /24 for native IPv6 infrastructure and customers. When 6RD is no longer in use, the part of the /24 no longer motivated shall be returned. This proposal means no extra DFZ pollution, requires ISPs to use 6RD to actually hand out subnets and tells them to use the part of the /24 that maps into IPv4 class E space (240.0.0/4), thus not used, and when 6RD is no longer in use they keep that /32 unless they have grown and require more space. They can grow to /28 and still be in equivalent class E space. I'm not sure if we can even go to /27, I guess we don't need to map class D (224.0.0.0/4) either, the top /27 would be available? -- Mikael Abrahamsson email: swmike at swm.pp.se From remi.despres at free.fr Sat Nov 28 09:50:18 2009 From: remi.despres at free.fr (=?iso-8859-1?Q?R=E9mi_Despr=E9s?=) Date: Sat, 28 Nov 2009 09:50:18 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: <316CA4C4-1445-45EC-AD50-6391C9330BD0@free.fr> <57D61E37-F4CB-4471-92EF-134082A7EE5A@free.fr> Message-ID: <8821CE90-BCAE-4371-903D-4B175A0BEB8B@free.fr> Le 27 nov. 2009 ? 19:36, Mikael Abrahamsson a ?crit : > On Fri, 27 Nov 2009, R?mi Despr?s wrote: > >> No hard feelings, but I felt this needed to be said. > > There is nothing wrong with 6RD in principle, it's when people map the entire IPv4 space into IPv6 blindly and then use a small fraction of it that it becomes wasteful. Right (that's the use of 6rd which can create problems, not it's design or its implementation in gateways and home gateways). > I don't have a problem with ISPs will millions of subscribers getting a /24, I have a problem when "every" mom and pop ISP with an AS number is getting a /24 because they want to run 6RD. > > As long as the policy incurs that you need to have a certain amount of customers to warrant running 6RD using all of IPv4 space and thus needing /24 or /28, otherwise you'd better map a smaller part of it and then you'll be able to fit it just fine into your /32 most likely. /28 for any ISP having several IPv4 prefixes and committed to deploy 6rd would be IMHO a good choice. In practice, /60s to customer sites is quite sufficient, at least in the short term. (Note that mom and pop ISPs, presumably having each only one IPv4 prefix, would remain with /32s.) Then, going up to /24 for ISPs that deploy 6rd with at least 4 IPv4 prefixes, as you propose in another mail, would not be necessary, but could be a useful option. Regards, RD From Remco.vanMook at eu.equinix.com Sat Nov 28 15:57:49 2009 From: Remco.vanMook at eu.equinix.com (Remco van Mook) Date: Sat, 28 Nov 2009 15:57:49 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD References: <316CA4C4-1445-45EC-AD50-6391C9330BD0@free.fr> <57D61E37-F4CB-4471-92EF-134082A7EE5A@free.fr> <8821CE90-BCAE-4371-903D-4B175A0BEB8B@free.fr> Message-ID: <25B76451F7215744AFD4195362E55A1CF34936@NLEN1EX1.eu.win.equinix.com> Hi Remi, could you help me in understanding why an ISP with, say, a /14 and 2 /16s of address space would need a /28 of space to do 6rd? In my understanding, even using a /56 per customer would give you a requirement for just 19 bits of ipv6 space (18 bits for the /14, 1 extra to also make the /16s fit) on top of the /56s, if you just use 3 instances of 6rd and prefix compression. This gives a requirement of a /37 for deploying 6rd, not a /28. Even if you add a whole bunch of /15s and /24s to the mix, it will only add a few bits to the requirement, not 11. Not that I don't want to give out the space if needed, but I'm trying to understand the reasoning behind it. I find 'too complicated' a tough argument to swallow given that the current and working IPv4 setup in an environment like this is already way more complicated. Best, Remco -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of R?mi Despr?s Sent: zaterdag 28 november 2009 9:50 To: Mikael Abrahamsson Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] IPv6 allocations for 6RD Le 27 nov. 2009 ? 19:36, Mikael Abrahamsson a ?crit : > On Fri, 27 Nov 2009, R?mi Despr?s wrote: > >> No hard feelings, but I felt this needed to be said. > > There is nothing wrong with 6RD in principle, it's when people map the entire IPv4 space into IPv6 blindly and then use a small fraction of it that it becomes wasteful. Right (that's the use of 6rd which can create problems, not it's design or its implementation in gateways and home gateways). > I don't have a problem with ISPs will millions of subscribers getting a /24, I have a problem when "every" mom and pop ISP with an AS number is getting a /24 because they want to run 6RD. > > As long as the policy incurs that you need to have a certain amount of customers to warrant running 6RD using all of IPv4 space and thus needing /24 or /28, otherwise you'd better map a smaller part of it and then you'll be able to fit it just fine into your /32 most likely. /28 for any ISP having several IPv4 prefixes and committed to deploy 6rd would be IMHO a good choice. In practice, /60s to customer sites is quite sufficient, at least in the short term. (Note that mom and pop ISPs, presumably having each only one IPv4 prefix, would remain with /32s.) Then, going up to /24 for ISPs that deploy 6rd with at least 4 IPv4 prefixes, as you propose in another mail, would not be necessary, but could be a useful option. Regards, RD 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 marcoh at marcoh.net Sun Nov 29 11:11:27 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Sun, 29 Nov 2009 11:11:27 +0100 Subject: [address-policy-wg] 'Administrative ease' (was IPv6 allocations for 6RD) In-Reply-To: <25B76451F7215744AFD4195362E55A1CF34936@NLEN1EX1.eu.win.equinix.com> References: <316CA4C4-1445-45EC-AD50-6391C9330BD0@free.fr> <57D61E37-F4CB-4471-92EF-134082A7EE5A@free.fr> <8821CE90-BCAE-4371-903D-4B175A0BEB8B@free.fr> <25B76451F7215744AFD4195362E55A1CF34936@NLEN1EX1.eu.win.equinix.com> Message-ID: <62B13CF9-AD2E-4DB7-B4E3-3B4F0D0F249F@marcoh.net> On 28 nov 2009, at 15:57, Remco van Mook wrote: > Hi Remi, > > could you help me in understanding why an ISP with, say, a /14 and > 2 /16s of address space would need a /28 of space to do 6rd? In my > understanding, even using a /56 per customer would give you a > requirement for just 19 bits of ipv6 space (18 bits for the /14, 1 > extra to also make the /16s fit) on top of the /56s, if you just use > 3 instances of 6rd and prefix compression. This gives a requirement > of a /37 for deploying 6rd, not a /28. Even if you add a whole bunch > of /15s and /24s to the mix, it will only add a few bits to the > requirement, not 11. > > Not that I don't want to give out the space if needed, but I'm > trying to understand the reasoning behind it. I find 'too > complicated' a tough argument to swallow given that the current and > working IPv4 setup in an environment like this is already way more > complicated. My I propose to add the following to section 3.5 of RIPE-481 (or similair wording) analogues to 6.5 of the v4 policy: Current text: 3.5. Conservation Although IPv6 provides an extremely large pool of address space, address policies should avoid unnecessarily wasteful practices. Requests for address space should be supported by appropriate documentation and stockpiling of unused addresses should be avoided. Proposed new text: 3.5. Conservation and Administrative Ease Although IPv6 provides an extremely large pool of address space, historical evidence shows that what now seems infinit might one day turn out to become a scarce resource, Address policies should avoid unnecessarily wasteful practices of such resources. Requests for address space should be supported by appropriate documentation and stockpiling of unused addresses should be avoided. Assignment of address space based on the sole argument of administrative ease is not permitted. Examples of this include, but are not limited to, ease of billing administration and network management. Rationale: Classfull addressing in IPv4 proofs a nice example, but one can also look at 16 bit ASN or the global supply of oil for proof that resources that once seemed infinite can become scarce. Especially in 'greenfield' deployments such as 6rd, which is still in the process of being standardized, and IPv6 in general, circumstances which may be considered 'wastefull' can be easily avoided. Arguments supporting the proposal: We slowly become aware what the costs of deploying a new technique or protocol are, one of the prime arguments global addoption of 32 bit ASN and IPv6 is slow is cost. We should try and prevent future cost by doing the same exercise twice by all means. We keep telling our selves and the rest of the world IPv6 is not different, "96 bits no difference", it seems logical to keep the policies as much the same as possible. One might argue that with standardizing an ethernet subnet to 64 bits all was lost anyway, this is not the case and mistakes from the past should be used as an example to prevent further damage instead of a validation to make the same mistake twice. Arguments against this proposal: By addopting this change now we again create a difference between the early adopters and people who follow, this is similair to the assignment of /8 address blocks in the early days of IPv4. By prohibiting assignment for administrative ease we will slow IPv6 adoption even more MarcoH From michael.dillon at bt.com Sun Nov 29 18:52:01 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Sun, 29 Nov 2009 17:52:01 -0000 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <8821CE90-BCAE-4371-903D-4B175A0BEB8B@free.fr> Message-ID: <28E139F46D45AF49A31950F88C49745804488407@E03MVZ2-UKDY.domain1.systemhost.net> > /28 for any ISP having several IPv4 prefixes and committed > to deploy 6rd would be IMHO a good choice. > In practice, /60s to customer sites is quite sufficient, at > least in the short term. No, /60s to customer sites is not sufficient. It breaks the IPv6 model of fixed size site allocations which assumes that all sites will have /48 assignments unless they are private residences in which case they will have /56 prefixes. This uniformity is essential in order to allow people to innovate with IPv6. We should not force 6RD ISPs into making this kind of mistake, especially since 6RD is only a transition measure, and if an ISP gets /60 encoded into all their systems and processes, then they will be stuck with it long after 6RD has disappeared. That would be an IPv6 equivalent of the swamp, i.e. a short sighted, short term decision with negative long term consequences. --Michael Dillon From mohacsi at niif.hu Mon Nov 30 09:19:00 2009 From: mohacsi at niif.hu (Mohacsi Janos) Date: Mon, 30 Nov 2009 09:19:00 +0100 (CET) Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <4B0F6CD6.2020200@ip-plus.net> References: <20091126132910.GF32226@Space.Net> <20091126181832.GL32226@Space.Net> <4B0F6CD6.2020200@ip-plus.net> Message-ID: On Fri, 27 Nov 2009, Andre Chapuis wrote: > I fully agree with Marc: the policy currently allows allocating more than > /32, so I see no need to change it. > > We are facing here a principle discussion. > - the "R" in 6RD stays for "Rapid". And this is the most important point to > consider. If we can rapidly bring millions of users to IPv6 without investing > in big hardware/design changes (part. in these crisis times), combined with > guys like Google/Youtube bringing traffic, then (and only then) v6 will > become a reality. > So this is in the interest of the RIPE community to make that happens. We > have a successful POC with Free.fr Wrong: You need 6RD capable SOHO router. Free could dot it easily since Free is the owner and maintainer of the SOHO routers. The customers only leasing their CPEs. If your business modell is not similar you need big hardware changes.... > > - For the RIPE-NCC, this is imho even more important to push for v6 > deployment and therefore to remove any potential obstacle for the ISPs and > encourage them to implement 6-RD or similar solutions. > If even getting IPv6 addresses becomes a fight, most ISPs may give up, since > there is still no business case to justify it. No fight for getting IPv6 address: simple rules, If you are a LIR just read them, and fill out the form. Best Regards, Janos Mohacsi 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 fweimer at bfk.de Mon Nov 30 09:39:53 2009 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 30 Nov 2009 08:39:53 +0000 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <57D61E37-F4CB-4471-92EF-134082A7EE5A@free.fr> (=?iso-8859-1?Q?=22R=E9mi_Despr=E9s=22's?= message of "Fri\, 27 Nov 2009 18\:21\:48 +0100") References: <316CA4C4-1445-45EC-AD50-6391C9330BD0@free.fr> <57D61E37-F4CB-4471-92EF-134082A7EE5A@free.fr> Message-ID: <82ocmk9zja.fsf@mid.bfk.de> * R?mi Despr?s: > This objective has been brilliantly achieved when Free, after only 5 > weeks, evolved from "we don't want to spend a Euro on IPv6" to "IPv6 > is available to our customers who wish to activate it with a click". Does this approach give the customer the ability to connect multiple devices? If not, stateless autoconfiguration is probably unnecessary, and 6RD could do without /64 subnets, freeing additional bits for internal addressing at the ISP level. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From fweimer at bfk.de Mon Nov 30 09:45:52 2009 From: fweimer at bfk.de (Florian Weimer) Date: Mon, 30 Nov 2009 08:45:52 +0000 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <28E139F46D45AF49A31950F88C49745804488407@E03MVZ2-UKDY.domain1.systemhost.net> (michael dillon's message of "Sun\, 29 Nov 2009 17\:52\:01 -0000") References: <28E139F46D45AF49A31950F88C49745804488407@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <82k4x89z9b.fsf@mid.bfk.de> * michael dillon: > No, /60s to customer sites is not sufficient. It breaks the IPv6 > model of fixed size site allocations which assumes that all sites > will have /48 assignments unless they are private residences in > which case they will have /56 prefixes. This uniformity is essential > in order to allow people to innovate with IPv6. Ahem, future innovation with IPv6 (whatever that is, beyound disabling insecure protocol features) needs to take VSLM into account. It's also likely that the requirement that all unicast addresses most be within at least a /64 will be eventually overturned because those bits could be used in a more useful fashion. -- Florian Weimer BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstra?e 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 From remi.despres at free.fr Mon Nov 30 10:04:42 2009 From: remi.despres at free.fr (=?iso-8859-1?Q?R=E9mi_Despr=E9s?=) Date: Mon, 30 Nov 2009 10:04:42 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <82ocmk9zja.fsf@mid.bfk.de> References: <316CA4C4-1445-45EC-AD50-6391C9330BD0@free.fr> <57D61E37-F4CB-4471-92EF-134082A7EE5A@free.fr> <82ocmk9zja.fsf@mid.bfk.de> Message-ID: <2A886E3E-1E0A-45CA-B359-5D8E7449494C@free.fr> Le 30 nov. 2009 ? 09:39, Florian Weimer a ?crit : > * R?mi Despr?s: > >> This objective has been brilliantly achieved when Free, after only 5 >> weeks, evolved from "we don't want to spend a Euro on IPv6" to "IPv6 >> is available to our customers who wish to activate it with a click". > > Does this approach give the customer the ability to connect multiple > devices? Yes, and this is important. Each customer site can have as many Windows, OS X, and Linux PCs on its internal LAN. They automatically configure their IPv6 address (unless their IPv6 is not enabled), and then communicate in IPv6 with all servers that are IPv6 enabled (Google servers in particular) without users even noticing it. Having only a /64 in a residential site starts having consequences only if there is a need to install several LANs that are strictly independent (i.e. LANs that are not, like most Wifi and other Ethernet LANs, linked by layer 2 switches). Only sophisticated users would notice any limitation. Regards, RD > If not, stateless autoconfiguration is probably unnecessary, > and 6RD could do without /64 subnets, freeing additional bits for > internal addressing at the ISP level. > > -- > Florian Weimer > BFK edv-consulting GmbH http://www.bfk.de/ > Kriegsstra?e 100 tel: +49-721-96201-1 > D-76133 Karlsruhe fax: +49-721-96201-99 From michael.dillon at bt.com Mon Nov 30 10:49:40 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 30 Nov 2009 09:49:40 -0000 Subject: [address-policy-wg] 'Administrative ease' (was IPv6 allocations for 6RD) In-Reply-To: <62B13CF9-AD2E-4DB7-B4E3-3B4F0D0F249F@marcoh.net> Message-ID: <28E139F46D45AF49A31950F88C49745804488665@E03MVZ2-UKDY.domain1.systemhost.net> > Current text: > > 3.5. Conservation > Although IPv6 provides an extremely large pool of address > space, address policies should avoid unnecessarily wasteful > practices. > Requests for address space should be supported by appropriate > documentation and stockpiling of unused addresses should be avoided. Seems reasonable to me. It implies that giving someone a /21 based on their 6RD requirements is OK, but that they would have to return the allocation once they no longer need the transitional 6RD service. > Proposed new text: > > 3.5. Conservation and Administrative Ease Although IPv6 > provides an extremely large pool of address space, historical > evidence shows that what now seems infinit might one day turn > out to become a scarce resource, Address policies should > avoid unnecessarily wasteful practices of such resources. > Requests for address space should be supported by appropriate > documentation and stockpiling of unused addresses should be > avoided. Assignment of address space based on the sole > argument of administrative ease is not permitted. Examples of > this include, but are not limited to, ease of billing > administration and network management. I disagree with this. If we are willing to accept that allocations can be temporary, and should be returned when no longer needed, then administrative ease is a good reason to justify a larger allocation, particular when this supports transition to native IPv6 networks. If a company needs a /21 to ease the burden of transition, and will return it to RIPE in 5 to 10 years after native IPv6 is fully deployed in their network then that seems reasonable to me. Any concerns that we have with possible shortages of IPv6 address space are well beyond the IPv6 transition, therefore 10 years should be considered short-term. --Michael Dillon 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 From remi.despres at free.fr Mon Nov 30 11:49:24 2009 From: remi.despres at free.fr (=?iso-8859-1?Q?R=E9mi_Despr=E9s?=) Date: Mon, 30 Nov 2009 11:49:24 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <25B76451F7215744AFD4195362E55A1CF34936@NLEN1EX1.eu.win.equinix.com> References: <316CA4C4-1445-45EC-AD50-6391C9330BD0@free.fr> <57D61E37-F4CB-4471-92EF-134082A7EE5A@free.fr> <8821CE90-BCAE-4371-903D-4B175A0BEB8B@free.fr> <25B76451F7215744AFD4195362E55A1CF34936@NLEN1EX1.eu.win.equinix.com> Message-ID: <0F5D57A3-7258-43F7-B1B6-A99FEDBBAD9C@free.fr> Le 28 nov. 2009 ? 15:57, Remco van Mook a ?crit : > Hi Remi, > > could you help me in understanding why an ISP with, say, a /14 and 2 /16s of address space would need a /28 of space to do 6rd? In my understanding, even using a /56 per customer would give you a requirement for just 19 bits of ipv6 space (18 bits for the /14, 1 extra to also make the /16s fit) on top of the /56s, if you just use 3 instances of 6rd and prefix compression. This gives a requirement of a /37 for deploying 6rd, not a /28. Even if you add a whole bunch of /15s and /24s to the mix, it will only add a few bits to the requirement, not 11. The point is a tradeoff between simplicity, a condition for quick and safe deployment, and optimized use of address bits. 6rd is just what it is: a simple tool to offer quickly native IPv6 to customers, this without ISPs having, in a first step, to modify existing IPv4 infrastructures. Indeed, some more optimized address coding schemes are possible. But they introduce additional complexity (variable number of parameters, less readability of encoded addresses for maintenance, longer process to agree on detailed formats etc.). Now, drawbacks of not supporting this additional complexity, are in practice minimal: - Since RIRs allocate /32s and recommend to assign /48s to customers, each ISP having more than 64K customers should get at least a /28. With such a /28, any ISP that has several IPv4 prefixes can deploy 6rd with /60s assigned to all its customers (typically more than 64K). - A /60 per customer site is largely enough to start using IPv6, even for sophisticated users that configure several LANs in their sites. Furthermore, if 16 LANs is not enough in a site, ISATAP can be used to deploy IPv6 on its complex topology. - For an ISPs that initially gets only as /32 and has several IPv4 prefixes, assigning /64s to its customers is much better than no IPv6 at all (as Free has demonstrated, and because most sites don't support several LANs anyway). In summary, and IMHO: o ISPs that don't obtain more generous IPv6 prefixes than /32s can at least start with /64s assigned to customers. o RIRs should allocate at least /28s to ISPs that have several IPv4 prefixes and plan to deploy 6rd. o These ISPs should return these prefixes if, for any reason, they become more generous than needed. Regards, RD > > Not that I don't want to give out the space if needed, but I'm trying to understand the reasoning behind it. I find 'too complicated' a tough argument to swallow given that the current and working IPv4 setup in an environment like this is already way more complicated. > > Best, > > Remco > > -----Original Message----- > From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of R?mi Despr?s > Sent: zaterdag 28 november 2009 9:50 > To: Mikael Abrahamsson > Cc: address-policy-wg at ripe.net > Subject: Re: [address-policy-wg] IPv6 allocations for 6RD > > > Le 27 nov. 2009 ? 19:36, Mikael Abrahamsson a ?crit : > >> On Fri, 27 Nov 2009, R?mi Despr?s wrote: >> >>> No hard feelings, but I felt this needed to be said. >> >> There is nothing wrong with 6RD in principle, it's when people map the entire IPv4 space into IPv6 blindly and then use a small fraction of it that it becomes wasteful. > > Right (that's the use of 6rd which can create problems, not it's design or its implementation in gateways and home gateways). > >> I don't have a problem with ISPs will millions of subscribers getting a /24, I have a problem when "every" mom and pop ISP with an AS number is getting a /24 because they want to run 6RD. >> >> As long as the policy incurs that you need to have a certain amount of customers to warrant running 6RD using all of IPv4 space and thus needing /24 or /28, otherwise you'd better map a smaller part of it and then you'll be able to fit it just fine into your /32 most likely. > > /28 for any ISP having several IPv4 prefixes and committed to deploy 6rd would be IMHO a good choice. > In practice, /60s to customer sites is quite sufficient, at least in the short term. > (Note that mom and pop ISPs, presumably having each only one IPv4 prefix, would remain with /32s.) > > Then, going up to /24 for ISPs that deploy 6rd with at least 4 IPv4 prefixes, as you propose in another mail, would not be necessary, but could be a useful option. > > Regards, > RD > > > > > 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 Mon Nov 30 17:05:06 2009 From: gert at space.net (Gert Doering) Date: Mon, 30 Nov 2009 17:05:06 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <82k4x89z9b.fsf@mid.bfk.de> References: <28E139F46D45AF49A31950F88C49745804488407@E03MVZ2-UKDY.domain1.systemhost.net> <82k4x89z9b.fsf@mid.bfk.de> Message-ID: <20091130160506.GF32226@Space.Net> Hi, On Mon, Nov 30, 2009 at 08:45:52AM +0000, Florian Weimer wrote: > Ahem, future innovation with IPv6 (whatever that is, beyound disabling > insecure protocol features) needs to take VSLM into account. It's > also likely that the requirement that all unicast addresses most be > within at least a /64 will be eventually overturned because those bits > could be used in a more useful fashion. This is well out of scope for any address policy discussion going on today. When and if the IETF decides that non-/64-subnets are a desirable feature, it makes sense to discuss the consequences on address policy here - before that, it's a waste of bits. Please let's be focussed on the question at hand - which side do we want to err to? - be very conservative in giving out IPv6 address space, risking that IPv6 will just never take off - for fear of running out of space "if we happen to very radically move the boundary by 8 bits multiple times" - be very liberal in giving out IPv6 address space, risking that we run out of FP001 sooner than expected, and that we will have to do a more restrictive policy later on - but doing our best to actually get IPv6 out and deployed Whatever we decide, history will tell us that we have been wrong in our predictions... Given the original question: as far as I understood the question, the RIPE NCC IPRAs consider the request to be inside the boundaries permitted by policy, if a bit larger than "typical". So we don't really need a formal policy change here, just guidance to the IPRAs "this is a good thing, give them the address space" or "this is not a good thing, refuse!". 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 florian at frotzler.priv.at Mon Nov 30 17:43:51 2009 From: florian at frotzler.priv.at (Florian Frotzler) Date: Mon, 30 Nov 2009 17:43:51 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <20091130160506.GF32226@Space.Net> References: <28E139F46D45AF49A31950F88C49745804488407@E03MVZ2-UKDY.domain1.systemhost.net> <82k4x89z9b.fsf@mid.bfk.de> <20091130160506.GF32226@Space.Net> Message-ID: <966645c70911300843v2d8b14dbnc21e31e169b7d38a@mail.gmail.com> -> this is a good thing, give them the address space <- Managing various SP prefix is a burden for large operators or might even be a show-stopper for 6RD rollout. Cheers, Florian 2009/11/30 Gert Doering : > Hi, > > On Mon, Nov 30, 2009 at 08:45:52AM +0000, Florian Weimer wrote: >> Ahem, future innovation with IPv6 (whatever that is, beyound disabling >> insecure protocol features) needs to take VSLM into account. ?It's >> also likely that the requirement that all unicast addresses most be >> within at least a /64 will be eventually overturned because those bits >> could be used in a more useful fashion. > > This is well out of scope for any address policy discussion going on today. > > When and if the IETF decides that non-/64-subnets are a desirable feature, > it makes sense to discuss the consequences on address policy here - before > that, it's a waste of bits. > > Please let's be focussed on the question at hand - which side do we want > to err to? > > ?- be very conservative in giving out IPv6 address space, risking that > ? ?IPv6 will just never take off - for fear of running out of space > ? ?"if we happen to very radically move the boundary by 8 bits multiple > ? ?times" > > ?- be very liberal in giving out IPv6 address space, risking that we run > ? ?out of FP001 sooner than expected, and that we will have to do a more > ? ?restrictive policy later on - but doing our best to actually get IPv6 > ? ?out and deployed > > Whatever we decide, history will tell us that we have been wrong in > our predictions... > > Given the original question: as far as I understood the question, the > RIPE NCC IPRAs consider the request to be inside the boundaries permitted > by policy, if a bit larger than "typical". ?So we don't really need a > formal policy change here, just guidance to the IPRAs "this is a good > thing, give them the address space" or "this is not a good thing, refuse!". > > 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 lorenzo at google.com Mon Nov 30 18:35:46 2009 From: lorenzo at google.com (Lorenzo Colitti) Date: Mon, 30 Nov 2009 09:35:46 -0800 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: References: <4B0E5FC9.60202@cisco.com> Message-ID: 2009/11/26 Lutz Donnerhacke : > I still reading this draft and try hard to find the benefit over announcing > more specific routes in 2002::/16. Other networks might not accept more specifics of 2002::/16 because they don't want to replicate the IPv4 routing table into the IPv6 routing table. From michael.dillon at bt.com Mon Nov 30 22:15:35 2009 From: michael.dillon at bt.com (michael.dillon at bt.com) Date: Mon, 30 Nov 2009 21:15:35 -0000 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <0F5D57A3-7258-43F7-B1B6-A99FEDBBAD9C@free.fr> Message-ID: <28E139F46D45AF49A31950F88C497458044FE07F@E03MVZ2-UKDY.domain1.systemhost.net> > - Since RIRs allocate /32s and recommend to assign /48s to > customers, each ISP having more than 64K customers should get > at least a /28. With such a /28, any ISP that has several > IPv4 prefixes can deploy 6rd with /60s assigned to all its > customers (typically more than 64K). Wait a minute. If a /28 allocation is enough to assign /60 blocks, then by giving the ISP 4 more subnetting bits, i.e. a /24 allocation, they should be able to give /56 assignments to all their customers. That is the way to do this properly. > - A /60 per customer site is largely enough to start using > IPv6, even for sophisticated users that configure several > LANs in their sites. That's not the point. A /60 assignment is wrong. If software developers and equipment vendors get the idea that /60 is normal, then they will embed that assumption in their products and it will make the transition from 6RD to native v6 more difficult. There is no need to make customer assignments smaller than /56. > - For an ISPs that initially gets only as /32 and has several > IPv4 prefixes, assigning /64s to its customers is much better > than no IPv6 at all (as Free has demonstrated, and because > most sites don't support several LANs anyway). No, assigning /64s is far worse because their people will not be properly trained, and when the word gets out, nobody will want to work there because it will be a black mark on their CV. It is better to go back to RIPE, explain the situation, and get a /24 or /21. > o ISPs that don't obtain more generous IPv6 prefixes than > /32s can at least start with /64s assigned to customers. This is called compounding your mistakes. Do not do this. > o RIRs should allocate at least /28s to ISPs that have > several IPv4 prefixes and plan to deploy 6rd. Wrong. RIRs should evaluate the size of allocation needed to properly deploy 6RD using /56 assignments for customers, and then allocate a block big enough to handle this deployment. > o These ISPs should return these prefixes if, for any reason, > they become more generous than needed. That has always been part of the RIR rules. And that is a major reason why people should be given huge allocations to deploy 6RD, if they have decided that 6RD is the best way to go. We do not want ISPs to get locked into 6RD because of bad architectural decisions, so we must ensure that they have enough address space to assign /56 or /48 to all customer sites. --Michael Dillon From marcoh at marcoh.net Mon Nov 30 22:20:33 2009 From: marcoh at marcoh.net (Marco Hogewoning) Date: Mon, 30 Nov 2009 22:20:33 +0100 Subject: [address-policy-wg] IPv6 allocations for 6RD In-Reply-To: <28E139F46D45AF49A31950F88C497458044FE07F@E03MVZ2-UKDY.domain1.systemhost.net> References: <28E139F46D45AF49A31950F88C497458044FE07F@E03MVZ2-UKDY.domain1.systemhost.net> Message-ID: <0B6F9CD2-47E7-41CC-BCA0-5FAFB83FEC43@marcoh.net> > That's not the point. A /60 assignment is wrong. If software > developers and equipment vendors get the idea that /60 is > normal, then they will embed that assumption in their products > and it will make the transition from 6RD to native v6 more > difficult. You keep repeating this but which document or standard says /60 is wrong ? > There is no need to make customer assignments smaller > than /56. But why ? I can imagine /60 is enough for Joe the plumber even if sensor networks would take off... MarcoH