> From: itojun@xxxxxxxxxx (Jun-ichiro itojun Hagino) > Cc: ietf@xxxxxxxx > > > Not viewed from the socket programmer's point of view. > > Look at how an AF_INET6 socket behaves when given > > an address like ::FFFF:192.0.2.3 > > afaik the behavior is then exactly what you describe. > > Whether the stacks are independent code modules or > > alternate paths through the same code is irrelevant > > to the externally observed behavior. > > see draft-ietf-v6ops-security-overview-06.txt section 2.2. My view is that "::FFFF:192.0.0.2" totally identical with "192.0.0.2" (internally inside the host stack implementation). There will be no functional difference anywhere in API, whichever form is used. I realize, that the above is not easy to achieve using the legacy POSIX socket API, which has has different sized address structures for IPv4 and IPv6. In Symbian OS, there is no such problem. The generic address structure allocation (TInetAddr) can hold both IPv4 and IPv6 address. Thus, the there is only one IP stack, which just happens to do IPv4, when address is IPv4 (either 192.0.0.2 or ::FFFF:192.0.0.2"). Real IPv6 addresses trigger IPv6 processing. Logically stack implements *one* "INET family" (PF_INET) with two possible address families "AF_INET" and "AF_INET6". Applications can be written totally agnostic on whether connection is over IPv4 or IPv6. All sockets are just opened as AF_INET, and the addresses used determine whether IPv4 or IPv6 gets used. On listening "undefined address family" can be used to accept both IPv4 and IPv6 for the same socket (TCP or UDP). Receiving "::FFFF:127.0.0.1" from network is not going to work as an attack, because of "strong model", and 127.0.0.1 is not configured for the real interface (=> destination 127.0.0.1 does not match configured address and gets dropped). _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf