Hi, I'm catching up an old thread.
On 2011/08/13, at 21:48, Philip Homburg wrote: > 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. Philip, thank you for great considerations. I agree that the above corner case is the only situation where the broken IPv4 connectivity does some harm. I can imagine another case where IPv6 connection falling back to IPv4. However, when a connection falls back, it takes tens of seconds, so it is bad enough regardless of the existence of broken IPv4 connectivity. So, I think this is trivial. Ray, do you think 3484-bis should treat this issue of RFC1918 address scope ? -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
