[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Thu, 11 Sep 2003, Francis Dupont wrote:

>  In your previous mail you wrote:
>
>    why isn't the ipv4-mapped problem addressed in
>    draft-shin-v6ops-application-transition-01.txt?
>
> => 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".

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.

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