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

From: Mauro Tortonesi <[email-masked]>
Date: Thu, 11 Sep 2003 14:35:00 +0200 (CEST)

what happened to draft-cmetz-v6ops-v4mapped-api-harmful-00.txt and
draft-itojun-v6ops-v4mapped-harmful-01.txt?

why isn't the ipv4-mapped problem addressed in
draft-shin-v6ops-application-transition-01.txt?

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

Mauro Tortonesi                 [email-masked]
                                [email-masked]
                                [email-masked]
Deep Space 6 - IPv6 with Linux  http://www.deepspace6.net
Ferrara Linux User Group        http://www.ferrara.linux.it

---

From: Francis Dupont <[email-masked]>
Date: Thu, 11 Sep 2003 15:41:33 +0200

In your previous mail you wrote:

=> they don't get a consensus and their authors are a bit late
to refresh them (or they had not enough time, or they lost interest).

=> this is different: IPv4-mapped IPv6 addresses on the wire have far
more opponents than IPv4-mapped IPv6 addresses in the API.
For instance I am against the first and strongly in favor of the second,
i.e., I dislike SIIT and our local credo is "IPv6 is not a new protocol,
IPv6 is a new version of the Internet Protocol".

Regards

[email-masked]

---

From: Fred Templin <[email-masked]>
Date: Thu, 11 Sep 2003 10:50:03 -0700

>more opponents than IPv4-mapped IPv6 addresses in the API.

I have never seen the "IPv4-mapped IPv6 addresses on the wire"
argument raised in relation to ISATAP, but since ISATAP
addresses also embed an IPv4 address in the interface identifier
I assume that some may see this as a concern.

For the record, if the site is not concerned about exposing L2
addresses to the outside it can certainly deploy ISATAP such
that nodes use ISATAP addresses as the IPv6 source address in
packets they send (e.g., by configuring the ISATAP router(s)
to send RAs with the L and A bits set in prefix options so that
nodes will naturally autoconfigure ISATAP addresses). But,
this is not the only option; indeed, there are at least two ways
in which sites can be configured such that nodes configure
non-ISATAP addresses and use them as the IPv6 source
addresses in packets they send:

  1) A site can configure its ISATAP router(s) to send RAs
    with the M/O bits set (or, to not send RAs at all) so that nodes
    naturally invoke stateful address autoconfiguration (RFC 2462,
    section 5.5). Each ISATAP node receives a non-ISATAP IPv6
    address delegation (V6) from the router/server for use as the
    IPv6 source address in packets it sends. The ISATAP router
    records a route mapping V6 to the node's link-local ISATAP
    address (LL) for each address it delegates so that return
    traffic is tunnled to the correct L2 address.

    No ISATAP addresses are sent over the wire.

  2) A site can configure its ISATAP router(s) to send RAs with
    the L bit not set and the A bit set in prefix options so that nodes
    naturally invoke stateless address autoconfiguration (RFC 2462,
    section 5.5). Each ISATAP node autoconfigures a non-ISATAP
    IPv6 address (V6) and assigns it to a  loopback interface. The
    node will additionally send an RA back to the ISATAP router
    with a prefix option containing V6 and with the L and A bits
    not set. The ISATAP router records a route mapping V6->LL
    so that return traffic is tunnled to the correct L2 address.

    Again, no ISATAP addresses are sent over  the wire.

There are other options for assigning non-ISATAP addresses
to nodes in an ISATAP site (e.g., manual configuration). But,
it should be clear that sites not wishing to expose their L2
addresses to the outside when using ISATAP have several
options at their disposal. For more information, please refer
to the latest ISATAP draft at:

    http://isatap.com

Fred
[email-masked]

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Fri, 12 Sep 2003 05:17:45 +0900 (JST)

> draft-itojun-v6ops-v4mapped-harmful-01.txt?

	we'll update those document eventually.  we're too busy with random
	things, but our opinion has not changed yet (so we need to submit a
	new veresion).

itojun

---

From: Pekka Savola <[email-masked]>
Date: Fri, 12 Sep 2003 11:34:07 +0300 (EEST)

> IPv6 is a new version of the Internet Protocol".

Francis, could you clarify how your local credo translates to how you'd 
like to, for example, port applications to IPv6?

We're in the process of updating 
draft-shin-v6ops-application-transition-02.txt, and it seems like there 
are about half a dozen (at least) ways to create IPv6 applications.  The 
different scenarios are quite complex.  Most of it seems to come from the 
different ways how the mapped addresses could be used.

Could you try to clarify?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Mauro Tortonesi <[email-masked]>
Date: Fri, 12 Sep 2003 11:33:56 +0200 (CEST)

> IPv6 is a new version of the Internet Protocol".

instead, i think that i have far more arguments against usage of
ipv4-mapped addresses on the api than on the wire (nowadays many unix oses
have a very useful configuration option for dropping ipv6 packets with
ipv4-mapped addresses).

first of all, they are a __nightmare__ for portability. and i think that
this is such a valid argument by itself that we should deprecate
ipv4-mapped addresses on the api immediately.

then my credo as a developer is "ipv6 is a brand new protocol", because
AF_INET6 sockets have many options that are not applicable to ipv4
connections, and writing applications that make use of the ipv4-mapped
catch-all approach will be a great problem for developers (that will find
themselves writing __a lot__ of checks/workarounds for special cases and
will become crazy during the testing/debugging process).

moreover, i think that the ipv4-mapped catch-all approach in the
development of ipv6-enabled apps may eventually become an obstacle for
widespread adoption of production quality ipv6-enabled software (since it
makes more difficult the use of the advanced ipv6 capabilities) and may
lead the life of ipv4 to be longer than what all of us expect or desire.

so, i think that treating an ipv4 connection as an ipv6 connection to a
ipv4-mapped endpoint is not only a bad development preactice but also
semantically wrong.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 12 Sep 2003 13:11:42 +0200

> ipv4-mapped endpoint is not only a bad development preactice but also

Ack - I fully agree with your view of the situation.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 12 Sep 2003 13:19:08 +0200

On vrijdag, sep 12, 2003, at 11:33 Europe/Amsterdam, Mauro Tortonesi 

> will become crazy during the testing/debugging process).

So what's the alternative? Ripping mapped addresses out of current 
implementations doesn't make sense for many reasons. The only question 
is whether you should/want to use them. If you want to do stuff with 
IPv6 that you can't do with IPv4, you'll have to do a lot of checking 
regardless of how you do it.

If you feel using the IPv6 socket API for IPv6 and the IPv4 socket API 
for IPv4 makes more sense, then by all means, do it that way. But for 
simple applications I think it's a huge plus to be able to talk to the 
network in a unified way without having to spend time and effort on 
making the IPv4/IPv6 distinction. Obviously this means you can't do any 
IPv6-specific stuff.

> makes more difficult the use of the advanced ipv6 capabilities)

I don't agree. Just tell the stack you don't want to talk IPv4.

Also, in the document I read it seems half or more of the trouble comes 
from mixing IPv4 and IPv6 calls. So don't do that.

I'm sure that from the vantage point of someone who writes large and 
complex applications things look different, but as someone who only 
writes simple stuff, I really appreciate having the mapping approach 
available.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 12 Sep 2003 13:48:22 +0200

On Fri, Sep 12, 2003 at 01:19:08PM +0200, Iljitsch van Beijnum wrote:

> But for simple applications I think it's a huge plus to be able to talk 
> to the network in a unified way without having to spend time and effort 
> on making the IPv4/IPv6 distinction.

I do not know where you make the distinction between a simple
application and a complex one. My experience is that the behaviour
of mapped addresses seems to be different from box to box and the
real pain I had was _portability_ and not the complexity of the
application. And this portability pain was in my case much bigger 
than writing proper code that can handle IPv4/IPv6 addresses
natively.

/js

---

From: Francis Dupont <[email-masked]>
Date: Fri, 12 Sep 2003 13:53:11 +0200

I have never seen the "IPv4-mapped IPv6 addresses on the wire"
   argument raised in relation to ISATAP,

=> ISATAP doesn't use them and the issue is *only* for IPv4-mapped
IPv6 addresses, not any other IPv6 addresses with embedded IPv4.

   but since ISATAP
   
=> your assumption is wrong.

Thanks

---

From: Mauro Tortonesi <[email-masked]>
Date: Fri, 12 Sep 2003 14:11:49 +0200 (CEST)

On Fri, 12 Sep 2003, Iljitsch van Beijnum wrote:

> implementations doesn't make sense for many reasons.

sure, but we could deprecate usage of ipv4-mapped addresses.

> The only question is whether you should/want to use them. If you want
> to do stuff with IPv6 that you can't do with IPv4, you'll have to do a
> lot of checking regardless of how you do it.

yes, but they're always less than the checks you would do if you were
also supporting ipv4-mapped addresses.

> making the IPv4/IPv6 distinction. Obviously this means you can't do any

this could be a plus only for for very simple apps where the developers
don't care for portability or robustness.

> I don't agree. Just tell the stack you don't want to talk IPv4.

not all the stacks support IPv6_V6ONLY, yet.

> from mixing IPv4 and IPv6 calls. So don't do that.

actually, this is not true. in fact, half or more of the trouble comes
from the fact that nearly every stack has a different bind(2) behaviour.

---

From: Mauro Tortonesi <[email-masked]>
Date: Fri, 12 Sep 2003 14:42:38 +0200 (CEST)

> than writing proper code that can handle IPv4/IPv6 addresses

yes. please take a look at my oftpd ipv6 port:

http://cvs.deepspace6.net/view/oftpd/

especially src/ftp_listener.c and src/af_portability.c. i think that at
the moment this is the only way to properly handle ipv4_mapped addresses
(and, in general, both ipv6 and ipv4 connectivity) on both systems with
IPv6_V6ONLY support and systems with no IPv6_V6ONLY support.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 12 Sep 2003 15:11:01 +0200

=> 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.

   We're in the process of updating 
   draft-shin-v6ops-application-transition-02.txt, and it seems like there 
   are about half a dozen (at least) ways to create IPv6 applications.

=> there are two ways:
 - consider that the two stacks are disjoined: the code is duplicated,
   there is a version for IPv6 and a version for IPv4.
 - consider that there is only one IP and use only the IPv6 representation
   of any IP address.

   The 
   
=> in fact the issue is more to use or not to use them.

=> there is a zillion of messages about this in the archives...

Thanks

PS: a new idea: list a "to be v6fied application of the month" in order
to get IPv6 support in all common applications... I propose to begin
with OpenSSL which has no IPv6 support mainly because we didn't shout
down enough louder to get it (:-).

---

From: Francis Dupont <[email-masked]>
Date: Fri, 12 Sep 2003 15:20:03 +0200

...
   
=> we obviously disagree nearly as much as possible. So don't expect
to reach any consensus about the two mentioned drafts...

Regards

PS: I do *not* want to reopen the discussion about IPv4-mapped IPv6 draft.

---

From: Mauro Tortonesi <[email-masked]>
Date: Fri, 12 Sep 2003 15:30:19 +0200 (CEST)

> down enough louder to get it (:-).

if you are looking for a list of IPv6-enabled apps, you can start here:

http://www.deepspace6.net/docs/ipv6_status_page_apps.html

---

From: Francis Dupont <[email-masked]>
Date: Fri, 12 Sep 2003 15:42:26 +0200

=> no, what I am looking for is a list of not yet IPv6-enabled apps,
i.e., apps which are not in your list, which have no IPv6 support
but we'd like to see in your list.

Regards

PS: I've transfered the idea to the [email-masked] list.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 12 Sep 2003 19:20:52 +0200

On vrijdag, sep 12, 2003, at 14:11 Europe/Amsterdam, Mauro Tortonesi 

> sure, but we could deprecate usage of ipv4-mapped addresses.

First of all, how does this make a difference in the world?

Second: you don't make the case for "harmful", only for "of little 
use". There is no need to go through all kinds of trouble to warn 
people something is hard to use.

> don't care for portability or robustness.

If you want to be able to write portable applications, why don't you 
talk to the OS builders?

---

From: Pekka Savola <[email-masked]>
Date: Fri, 12 Sep 2003 20:39:45 +0300 (EEST)

> the IPv6 space as IPv4-mapped IPv6 addresses.

What about client apps -- do you set up AI_MAPPED flag when doing 
getaddrinfo?

When you log into a dual-stack system with SSH using IPv4, would you 
prefer the application would print that you connected from an IPv4 
address, instead of the mapped address?  How about programs which make 
lookups based on your address (e.g. sendmail doing RBL-like checks) -- 
should all the applications convert the mapped addresses to IPv4 
addresses?  Should there be a function for it?  Or should the kernel lie 
to the apps about it?

There are other very difficult problems with mapped addresses, I've seen..
 
>  - consider that there is only one IP and use only the IPv6 representation

I don't know whether you're talking about different ways to build
dual-stack implementation, or how to build dual-stack applications.  If
the latter, your two ways seem to be wrong.  There does not need to be any
code duplication at all, using getaddrinfo loops.
 
> => in fact the issue is more to use or not to use them.

That's correct yes, but the details of "to use them" are also a bit hairy.

> => there is a zillion of messages about this in the archives...

.. with nothing properly written up, I guess.. :-(

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Sat, 13 Sep 2003 06:46:51 +0900 (JST)

> the IPv6 space as IPv4-mapped IPv6 addresses.

	could you tell me why you don't use getaddrinfo(AI_PASSIVE) and obey
	the result?  by doing so your application will be totally address
	family independent (no AF_INET6 hardcoded) and will be future-proven
	(will work with SCTP, DCCP or even IPv8 :-).

itojun

---

From: Francis Dupont <[email-masked]>
Date: Sat, 13 Sep 2003 18:34:12 +0200

=> 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).

I still don't want to reopen this endless discussion, so I don't answer
to the rest of the message in the list.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Sat, 13 Sep 2003 18:42:41 +0200

=> you already know the answer: because I'd like to listen on only a socket.
And this is address family independent (getaddrinfo is not defined for
AF_ISO for instance) and transport protocol independent (it works with
SCTP).

This is my last message about this topic.

Regards

---

From: Pekka Savola <[email-masked]>
Date: Sun, 14 Sep 2003 11:40:30 +0300 (EEST)

> 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.
 
> 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!).

---

From: Mauro Tortonesi <[email-masked]>
Date: Mon, 15 Sep 2003 10:40:43 +0200 (CEST)

> but we'd like to see in your list.

i had understood correctly what you were looking. however, i think that a
list of already IPv6-enabled apps could be of some help in the
compilation of your list of not IPv6-enabled apps.

---

From: Mauro Tortonesi <[email-masked]>
Date: Mon, 15 Sep 2003 10:51:49 +0200 (CEST)

> First of all, how does this make a difference in the world?

believe it or not, there are plenty of developers out there who are trying
to port apps to ipv6 in the correct way. this could be a very important
message for them.

> people something is hard to use.

__complete__ breaking of portability and decuplicated code complexity
are very harmful, IMVHO. especially if you're trying to push the early
adoption of ipv6 by the vendors.

> If you want to be able to write portable applications, why don't you

because this is not an os builders' fault. it's the IETF specification of
IPv4-mapped addresses which is ambiguous.

this said, i cannot but strongly recommend the adoption of (at least one
of) the solutions proposed by draft-cmetz-v6ops-v4mapped-api-harmful-00.txt,
section 2 and 3.

---

From: Mauro Tortonesi <[email-masked]>
Date: Mon, 15 Sep 2003 11:26:48 +0200 (CEST)

> AF_ISO for instance) and transport protocol independent (it works with

i don't think that your approach is really address family independent.

---

From: Mauro Tortonesi <[email-masked]>
Date: Mon, 15 Sep 2003 11:52:06 +0200 (CEST)

> AI_ADDRCONFIG could be useful, I guess, if it was properly defined and

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.

> 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.

---

From: YOSHIFUJI Hideaki / 吉藤英明<[email-masked]>
Date: Mon, 15 Sep 2003 19:10:54 +0900 (JST)

Hello.

> for ipv4 or ipv6 support in the stack.

We never look into routing table, but addresses.
Well, the method to check non-link-local addresses are 
available may be wrong.  
I evetually chenge it to try to explore whole addresses 
on the node using rtnetlink ("routing socket" in BSD term).

> it seems the KAME project's libinet6 does not support AI_ADDRCONFIG.

KAME supports AI_ADDRCONFIG (and USAGI's idea is from KAME's here).
http://orange.kame.net/dev/cvsweb.cgi/kame/kame/kame/libinet6/getaddrinfo.c

BTW, I'm not against IPv4-mapped addresses. :-)

-- 
Hideaki YOSHIFUJI @ USAGI Project <[email-masked]>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA

---

From: Mauro Tortonesi <[email-masked]>
Date: Mon, 15 Sep 2003 12:26:46 +0200 (CEST)

> on the node using rtnetlink ("routing socket" in BSD term).

why don't you check the routing table?

> http://orange.kame.net/dev/cvsweb.cgi/kame/kame/kame/libinet6/getaddrinfo.c

thanks, it seems that i was looking in the wrong place.

> BTW, I'm not against IPv4-mapped addresses. :-)

tu quoque, brute... ;-)