Hi, [...]
The current global routing table for IPv6 is 5-6k (give or take) implementing this policy (as currently structured) would see that grow to around 20k (just with v4 -> v6 requirements) in a vert short space of time, now I don't know about your network but slow gradual growth is okay as you can budget for replacing and upgrading a normal cycle. A sudden spike like this is likely to cause two things to happen, first it'll trip over a raft of memory bugs that vendors haven't found yet because they didn't think the v6 table would grow so quickly and secondly it'll put those people with less available capital off deploying v6 as their hardware won't be up to scratch.
I am happy to be convinced that I'm wrong and this won't be a problem *but* I'm still not convinced that this change is the best approach to solving "the problem" maybe the authors could pitch in with their problem statement so we can see what the actual problem is in the first place.
why do you expect a "sudden spike"? You know, IPv6 adoption is painfully slow. And actually, that's one of the points why some (most?) support the proposal, to speed that up! So, i'm a little confused now why this is bad. I don't know if this few (yes, it's "few" for me) more IPv6 prefixes will cause any problems at all, or if bugs are trigged, no one knows. We'll have to see, or someone might want to write a paper about it indeed :-) And why should THIS be a money issue? If you don't plan for 20k IPv6 prefixes when buying new border routers nowadays, what the hell are you doing? And what "border-router-grade" hardware doesn't support this few prefixes? I'm FAR more concerned about IPv4 table growth/deaggregation after exhaustion... -- Mit freundlichen Grüßen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect