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

From: <[email-masked]>
Date: Wed, 10 Jul 2013 05:45:00 -0700 (PDT)

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.

---

From: "cb.list6" <[email-masked]>
Date: Sun, 21 Jul 2013 16:58:05 -0700

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,  <[email-masked]> wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Erik Nygren <[email-masked]>
Date: Tue, 23 Jul 2013 18:53:17 -0400

Should we consider reversing the octets, such as is done for inaddr.arpa?
There might be cases where being able to delegate off or subzone some
prefixes could be useful?  For example, 10.2.0.192.TLD rather than
192.0.2.10.TLD ?

We should also consider the HTTP security considerations for the cases
where someone puts one of the names into a URL.  For example, consider
http://192.0.2.10.TLD/ to an origin that sets a cookie on the domain
"*.10.TLD".  There are likely already plenty of ways to do the same thing
out there, so this may not be a major issue.

        Erik

Sent from my mobile device
On Jul 10, 2013 8:45 AM, <[email-masked]> 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.

---

From: 中村 修 <[email-masked]>
Date: Wed, 24 Jul 2013 11:04:38 +0900

Erik,
Thank you for comments !

We discussed about reverse notation internally. 
But  we could not find reasonable meaning  of reverse notation for this purpose. 
For example, inaddr.arapa, reverse host entry should be maintained by IP address delegated organization.	
So reverse notation is much for IP address delegation.
In our proposed method, conversion of  literal IP address with TLD to IPv6 address with NAT prefix done by
local DNS64. So there is not reason for reverse notation.

			Osamu
    
On 2013/07/24, at 7:53, Erik Nygren <[email-masked]> wrote:

> Should we consider reversing the octets, such as is done for inaddr.arpa?  There might be cases where being able to delegate off or subzone some prefixes could be useful?  For example, 10.2.0.192.TLD rather than 192.0.2.10.TLD ?
> 
> We should also consider the HTTP security considerations for the cases where someone puts one of the names into a URL.  For example, consider http://192.0.2.10.TLD/ to an origin that sets a cookie on the domain "*.10.TLD".  There are likely already plenty of ways to do the same thing out there, so this may not be a major issue.
> 
>         Erik
>

---

From: Dan Wing <[email-masked]>
Date: Thu, 25 Jul 2013 17:15:00 -0700

> will not work as intended.

A similar problem occurs with HTTPS when the client validates the certificate.  I have never seen a certificate that used an IPv4 address in the subjectAltName, but I am told they do exist within enterprise networks.

-d