Incorrect. It's my experience that router manufacturers don't have people sitting around twiddling their thumbs wondering how to spend their precious work hours. The Internet ecosystem is best served by CE routers that have rock-solid "native IPv6" implementations. Given the relatively large quantity of 6rd currently in use to supply IPv6 to customers (around the world), having rock-solid 6rd is also a priority.
Any cycles that router manufacturers spend on development and QA of what you propose, are cycles taken away from coding and QA of the IPv6 functions we really do need. When cycles are taken away from that critical code, the stretched QA resources miss the bugs that the stretched developers introduce both in the code we do need, and in the code for this new function. Which leaves the ISP's stretched help desk resources supporting customers who not only have buggy native IPv6 and 6rd in their CE routers, but also the IPv4-only customers who now have buggy code for this new proposed functionality. Which would have the end result of taking resources away from IPv6 deployments and development. Which would slow down IPv6 deployment. Adding moving parts, potentially breaking things that aren't broken (while providing no discernible-to-the-average-user functionality), and stretching already-stretched resources is not a way to speed up IPv6 deployment. Rather, it's a very good way to slow it down. Barbara > If we believe that ipv6 is ready to go for mass deployment, why do we > not pressure home router vendors to default to sending router advertisements > with ULA addresses that, if necessary, get NAT'd at the border just like > 192.168 space does today. > > I mean, nothing bad would happen, right? > Correct.
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
