Re: Call for action vs. lost opportunity (Was: Re: Renumbering)

[Markku Savela <[e-mail]>]

> From: [e-mail] (Jun-ichiro itojun Hagino)
> Cc: [e-mail]
> 
> > 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 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf