This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] IPv6 allocations for 6RD
- Previous message (by thread): [address-policy-wg] IPv6 allocations for 6RD
- Next message (by thread): [address-policy-wg] IPv6 allocations for 6RD
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Mikael Abrahamsson
swmike at swm.pp.se
Fri Nov 27 22:17:08 CET 2009
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
- Previous message (by thread): [address-policy-wg] IPv6 allocations for 6RD
- Next message (by thread): [address-policy-wg] IPv6 allocations for 6RD
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]