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/address-policy-wg@ripe.net/
[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:45:28 CET 2009
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. 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 ? 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 ]