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 <sander@steffann.nl>:
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