On 2 dec 2009, at 10:52, Florian Frotzler wrote:
2009/12/2 Marco Hogewoning <marcoh@marcoh.net>:
On 2 dec 2009, at 10:38, Florian Frotzler wrote:
Hi Marco,
I think you're having a bug in your model. The larger prefix for 6RD is needed to stuff the 32 bit v4 addresses into the v6 addresses. The larger prefix does not mean there are more customers or more traffic than with implementing dual stack. So in terms of bandwidth your argument is false. If there are reasons to load balance, they are exactly the same with 6RD as with dual stack.
If there is any bug in whatever model it's 6RD itself which does not permit to use a from of compression to mapp multiple prefixes into a smaller block.
We had this discussion already, don't know why we have to discuss it again, the draft does allow for compression but in operational reality this is a nightmare, as I already stated multiple times.
Yeah and you almost got me convinced, I have a small portion of my network which I know will not do IPv6 native for the next decade. I might deploy 6RD there and since we intend to go for /48 on native, I have to do /48 on 6RD as well, does this entitle me to a /16 ? You seem to keep ignoring the fact that I don't think 'administrative ease' is a valid argument to waste addresses.
Regarding bandwidth, what would happen if you provide your customers with 6RD and all of a sudden youtube advertises a AAAA ? If bandwidth is not an argument, then please explain why people deaggregate ?
You understood me wrong. I will try to explain it differently. If you migrate 1 million customers to IPv6 using 6RD or dual stack, they have native IPv6 in both cases so there will be no difference in traffic. So it just doesn't matter with which technology I bring IPv6 to my customers regarding load balancing (and hence announcing more specifics) requirements. But it does very much matter in terms of $$$ I have to spend to bring IPv6 to my customers.
6RD encapsulation and decapsulation comes for free ? MarcoH