In your letter dated Sat, 13 Aug 2011 12:17:29 +0200 you wrote: >I still think there's an issue with the suggested blanket global >treatment of IPv4 RFC1918 addresses. > >Quote draft-ietf-6man-rfc3484-revise-04 "This issue can be fixed by changing t >he >address scope of private IPv4 addresses to global." > >IMVHO I think it is highly likely that over time this assumption will not hold > true: >think end game when IPv6 native only networks are widely deployed and CGN is t >urned off. >At that time there's still probably going to be many (local) NAT boxes >that advertise an IPv4 default route and serve RFC1918 DHCP addresses to clien >ts, >but cannot provide global connectivity. > >So whatever you assume about RFC1918 addresses has a good chance of being inco >rrect >unless you can truly detect/confirm presence of global IPv4 connectivity via N >AT.
Ah, tricky. For destination addresses we have 3 possibilities: v4-only, v6-only, and dual-stack. Obviously, without global IPv4 connectivity, connecting to v4-only destinations is not going to work, no matter what you put in the policy table. Connecting to v6-only destinations doesn't involve v4, so that's not an issue either. For dual stack, connecting over v6 is preferred unless one v6 address is 6to4 or teredo. Given that you are unlikely to have 6to4 or teredo in that kind of environment, that's not going to be the local address. So there is one remaining corner case. If the remote address is 6to4 or teredo, then the policy table will prefer IPv4. I'm not sure it's worth making thing more complex just o handle this corner case. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
