--- Comment #26 from Philippe Verdy <verd...@wanadoo.fr> 2011-03-05 00:51:16
Note: if the canonical IPv6 address format (with its colons) causes so much
compatibility problems to fix, why not converting it to a DNS compatible
address format in the .arpa domain ?
This provides an immediate fix as this special IPv6 domain resolves immediately
all fully specified IPv6 addresses in this domain, without needing any request
or prior registration to any DNS server (this is resolved locally, without
needing any status response from a DNS server, as the only acceptable AAAA
response from a DNS server, if successfull, can ONLY be the same IPv6 address,
and everything else must be marked as an incorrect bogous response, for obvious
You only need to perform a DNS request if the domain name specified in the
special ipv6 .arpa is only partly specified (i.e. missing one or more digits).
IP resolver libaries can also validate the format of names in this special ipv6
.arpa domain. They are also doing this local resolution for obvious performance
reasons. A true DNS request is only needed to request something else than a
AAAA record (for example an ANY request, or the request for the highly
recommanded, but still optional, associated CNAME).
We don't really need this CNAME to forward requests from a webserver to a slave
PHP or FastCGI process or from a caching proxy to a webserver running in a
firewalled local network (like on Wikiemdia sites).
Can this be tested on BIND, or in the Windows, OSX, Linux, and Unix IP
resolvers, i.e. through the socket/Winsock API gethostbyname("(...).arpa"), to
see if they really need to perform a DNS request to resolve those IPv6
addresses fully specified in this special ipb6 .arpa domain ? If it works, it
could help solve immediately some integration problems with various softwares
that need an update to support the brackets in hostnames build from the
canonical IPv6 address format (or any one of its abbreviated formats using "::"
and stripping any other leading zeroes)?
Can we enumerate all the integration problems that need to be fixed (by various
developer teams, not necessarily synchronized between each others). Of course,
bug tickets must be extensively opened to all these teams. Wikimedia sites are
large enough and deployed worldwide, that it could boost all other teams to
corect their own softwares.
This ticket is really slow, it has not moved since more than 2 years. Don't
blame too much the ISPs of not pushing IPv6 for now to all users. This is a
chicken and egg problem : everyone must advance as soon as possible in this
area, without waiting for others to fix their own bugs/limitations.
Like it or not, the world is going to use mobile networks increasingly, and the
number of IP-enabled devices for each user is exploding worldwide. On mobile
internet, IPv6 is already widely deployed (sometimes without any support for
IPv4, or with extremely severe protocol restrictions, allowing only access to
cachable shared contents through HTTP proxies, and very slow connection on
SSL/TLS, or not allowing the usage of SSL/TLS for something else than
identification, or small commercial transactions through HTTP form data POST
requests limited in volume for both the data sent and in the reply, and string
limitations in the number of those requests forwarded by users with HTTPS over
their proxies !).
This means that HTTPS will not work for interacting in Wikis (this is already a
problem for social networks, and that's why most mobile networks have
integrated their own proprietary support platforms for supporting Facebook,
Twitter, or MSN, and sometimes even require additional subscriptions in their
data plans, plus a compatible terminal, whose firmware has been specially
tweaked to allow the interaction).
There's no alternative other than full IPv6 support as soon as possible.
Otherwise there's the huge risk of fragmentation of the Internet as an unified
open and interoperable network (these risks are already measurable today,
interoperability is already decreasing, with lots of black holes onthe Internet
and sever access restrictions, much less dependant of political decisions, but
a lot influenced by very bad commercial practices, and lazyness from commercial
services to change their technical platform, or to invest in its evolutions).
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.
Wikibugs-l mailing list