[email protected] wrote: > >> yes, I believe IPv4 mapped address (RFC2553 section 3.7) behavior is > >> poorly documented, complicates both kernel and user code, leads to > >> insecure user code, and should be deprecated. yes, I dislike it. > >> I have been vocal about this in IETF because I believe the issue is > >> serious. > >What's the ipng wg position on it? Could we translate this discussion there? > > > >In the meantime the USAGI patch that i sent would let linux in the same > >position that FBSD and BSD/OS 4, and IMHO a lot better than what we have > >now, would you davem/alexey apply it or at least tell us your opinion about > >this issue? > > we had a kind of small group ("design team") discussion for updating > RFC2553 to 2553bis-xx, regarding to this issue. there are a lot of > guys from OS vendors. basically i failed to convince the editor of > 2553bis-xx; the discussion went to the wrong direction (IMHO). I > tried to convince that the discussion should focus on security and > application portability/reusability, however, the discussion went to > "how to keep my kernel unchanged and be conformant" direction. > > the result is on 2553bis-03, and that is: > - AF_INET6 socket will get IPv4 traffic (as being from IPv4 mapped > address), by default > - the above behavior can be turned off/on by IPV6_V6ONLY setsockopt > (new feature) > - bind(2) ordering constraint and conflict logic is not documented. > > IMHO, the first bullet is rather unfortunate, if we could convince > that the default value is "unspecified, vendor specific", > we could make netbsd/openbsd behavior "2553bis-03 conformant".
Well, I'm not unhappy with the first bullet, as that keeps all my existing v6 code working the way it was designed to, that is...bind an AF_INET6 socket, and get AF_INET support for free. I _do_ understand that this makes things much more complicated inside the stack, but I can see why it was decided this way. D
