Re: draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and draft-itojun-v6ops-v4mapped-harmful-01.txt

[Mauro Tortonesi <mtortonesi@ing.unife.it>]

On Sun, 14 Sep 2003, Pekka Savola wrote:

> On Sat, 13 Sep 2003, Francis Dupont wrote:
> >  In your previous mail you wrote:
> >    On Fri, 12 Sep 2003, Francis Dupont wrote:
> >    >  In your previous mail you wrote:
> >    >
> >    >    Francis, could you clarify how your local credo translates to how you'd
> >    >    like to, for example, port applications to IPv6?
> >    >
> >    > => I replace all AF_INET by AF_INET6, gethostbyname() by getaddrinfo(),
> >    > gethostbyaddr() by getnameinfo(), etc. I use one socket at the
> >    > server side because I consider there is only one IP, in the API it
> >    > becomes IPv6 with IPv4 space injected (in the math meaning) into
> >    > the IPv6 space as IPv4-mapped IPv6 addresses.
> >
> >    What about client apps -- do you set up AI_MAPPED flag when doing
> >    getaddrinfo?
> >
> > => AI_MAPPED? I believe you mean AI_V4MAPPED, it doesn't really matter
> > for a client, i.e., you can use AF_UNSPEC or AI_V4MAPPED|AI_ALL.
> > The important flag is AI_ADDRCONFIG (we have some IPv6 only boxes here).
>
> AI_ADDRCONFIG could be useful, I guess, if it was properly defined and
> implemented.

this is a very interesting topic, IMHO.

to support AI_ADDRCONFIG, USAGI project's libinet6 simply checks if the
system supports ipv4 or ipv6 by trying to create an AF_INET or AF_INET6
datagram socket. this is wrong, IMVHO, as the resolver should test for
ipv4 or ipv6 connectivity (e.g. by looking at the routing table) and not
for ipv4 or ipv6 support in the stack.

i don't know what's kame behaviour, but from what i've seen in:

http://orange.kame.net/dev/cvsweb.cgi/kame/kame/lib/libinet6/Attic/getaddrinfo.c?rev=1.2

it seems the KAME project's libinet6 does not support AI_ADDRCONFIG.
itojun, am i wrong?


BTW: i have included in cc YOSHIFUJI Hideaki, which is one of the core
     developers of the USAGI project, as i think that this discussion
     could be of some interest for him.


> > I still don't want to reopen this endless discussion, so I don't answer
> > to the rest of the message in the list.
>
> Well, then don't open the "mapped addresses or not" discussion, but I at
> least would like to hear how the applications which previously assumed
> IPv4 addresses and do things with them (consider sendmail and RBL+) see
> the mapped addresses.. and how you propose to fix (or document) that.
>
> The discussion will have to be had anyway.  As it stands the application
> transition document is *NOT* going to revisit the "deprecate" vs
> "not-deprecate" the mapped addresses discussion.  However, it aims to give
> guindance how to implement the application transition with or without
> mapped addresses (as the app writer sees best) the best way possible (the
> best way with mapped addresses is still unclear, I think!).

i am very interested in producing a specification for a "best practice"
approach to handle ipv4-mapped addresses. maybe it would be nice to
include it in draft-shin.


-- 
Aequam memento rebus in arduis servare mentem...

Mauro Tortonesi                 mtortonesi@ing.unife.it
                                mauro@deepspace6.net
                                mauro@ferrara.linux.it
Deep Space 6 - IPv6 with Linux  http://www.deepspace6.net
Ferrara Linux User Group        http://www.ferrara.linux.it