> Folks,
>
> I strongly agree with Bob Hinden. We have been down this path before
> and discussion. IPv4-Mapped addresses are now used on every production
> implementation and in most IPv6 production IP dual stacks. They cannot
> be removed and the industry will not and does not support such a change.
> The APIs are in use now also by Application Providers porting to IPv6.
> There is absolutely no reason to deprecate Mapped-Addresses and such an
> idea is totally unacceptable for all the reasons below and also we
> should not alter our base specification.
>
> Regarding compatible addresses they are harmless but not being used by
> most implementations or deployments, 6to4 is used. But I see not point
> in deprecating that either.
>
> Regards,
> /jim
I agree w/ Jim that they should not be removed. What should
be done is to identify where the different implementations
behave differently and document the correct behaviour.
e.g.
Can in6_pktinfo be used on mapped addresses?
Does :: trump a IPv4 socket bound to a interface address
when the same port is used?
Does :: trump a IPv4 socket bound 0.0.0.0 when the same port
is used?
It is inconsistancies like this make using mapped addresses
hard.
The choice of whether to use mapped addresses should remain w/
the appliacation developer.
Mark
> > -----Original Message-----
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> > Behalf Of Bob Hinden
> > Sent: Tuesday, February 01, 2005 7:27 AM
> > To: IPv6 WG
> > Subject: Re: IPv6 Address Architecture update question
> >
> > Hi,
> >
> > In response to my question about keeping the "IPv6 Addresses
> > with Embedded
> > IPv4 Addresses" (e.g., compatible and mapped) I heard the following:
> >
> > "I think that at least all the BSD's and most Linuxes are using this.
> > They allow binding on :: (IPv6 any) and also accept IPv4
> > connections on the same socket, which are then represented in
> > netstat etc as ::ffff:1.2.3.4.", "IMO the section can be
> > removed and programmers need to be learned the correct thing
> > for which I always very inclined to point people to Eva's
> > excellent document at
> > http://gsyc.escet.urjc.es/~eva/IPv6-web/ipv6.html and/or
> > draft-ietf-v6ops-application-transition-02.txt"
> >
> > "They should not be removed. Implementations already support
> > it, removing would just create confusion. I don't see any
> > harm in keeping it in."
> >
> > "helps with porting applications" and "dropping this section
> > will create confusion and chaos for the already ported applications"
> >
> > "Among other things, this would break the just published full
> > Standard for URIs (RFC 3986).", "I suspect some people have used the
> > ::10.1.2.3 format to carry IPv4 addresses in an IPv6
> > container, simply for convenience. I think this is very
> > convenient and should be available.", " otoh the
> > ::FFFF:10.1.2.3 format seems useless to me."
> >
> > "IPv4-mapped addresses facilitate an important
> > interoperability mechanism in the socket API (RFC 3493,
> > section 3.7).", "the API still needs a way to represent IPv4
> > addresses in a way that preserves compatibility between IPv6
> > and IPv4 hosts. Removal just makes transition all the more
> > time-consuming and difficult for software developers.
> >
> > "rather see clarification of the use of embedded addresses in
> > the document rather than complete removal. Ie. add a
> > statement to the effect of 'Embedded addresses are intended
> > for internal representation only'."
> >
> > "It is clear that the mapped addresses are widely used and
> > useful, and a lot of people have raised their concerns about
> > removing that.", "I suggest just simply removing compatibles."
> >
> > "Removal and formal deprecation would simplify life for
> > software developers.", "We might as well rid developers of
> > the burden of having to cope with mapped-address sockets as
> > well.", "Anyway, in summary, removal would in my opinion
> > actually make transition much easier for software developers,
> > not harder. Don't let the superficial ease of the
> > mapped-address API fool you :)"
> >
> > My take of this is that they should remain in the IPv6
> > address architecture. There is current usage and removing
> > them would break other specifications.
> >
> > Thanks,
> > Bob
> >
> >
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [email protected]
> > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email protected]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
