[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 ]
Marco Hogewoning
marcoh at marcoh.net
Wed Dec 2 10:57:55 CET 2009
On 2 dec 2009, at 10:52, Florian Frotzler wrote: > 2009/12/2 Marco Hogewoning <marcoh at 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
- 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 ]