Re: (usagi-users 00291) Re: USAGI IPv6 patches
itojun@iijlab.net 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
Reply to: