Re: [v6ops] new draft: draft-osamu-v6ops-ipv4-literal-in-url

I thought this was a pretty interesting draft from the 464XLAT
perspective, so i made a Chrome browser extension implementation,
described here https://sites.google.com/site/tmoipv6/home

I believe this I-D has a bug that must be noted.  Changing the URL
(swapping the DNS name or adding in a Pref64) frequently breaks the
connections since the application is aware of the name it expects, and
connecting correctly to the correct IP address is not sufficient, the
name must also be the same in many cases.

For example, many websites use the Apache VirtualHost concept
http://httpd.apache.org/docs/current/vhosts/examples.html

If the FQDN / URL /  service name is changed, then the VirtualHost
will not work as intended.

For example, there is a diagnostic website http://dual.tlund.se/

Going to the IPv4 literal address displays the same result as going to
the FQDN, i presume the admin of the box has configured VirtualHost
for each of the defined diagnostic methods.

But, going to the ipv4 translated address does not work, it displays a
different page that likely does not match a VirtualHost
http://[2001:67c:27e4:641::c10f:e4c3]/... but it is certainly the same
server with the same ipv4 address.

That said, in many cases, this function will work, like providing
ipv6-only access to ipv4-literal using internet radio stations like
http://radio.djbillman.com/  (blocking access to this radio station is
actually a feature of ipv6, but if you choose to disable that feature
at your own risk ....)

Cameron

On Wed, Jul 10, 2013 at 5:45 AM,  <fred@cisco.com> wrote:
>
> A new draft has been posted, at http://tools.ietf.org/html/draft-osamu-v6ops-ipv4-literal-in-url. Please take a look at it and comment.
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops