Subject: [BEHAVE] Catalog of IPv4 literals

From: Cameron Byrne <[email-masked]>
Date: Sun, 25 Jul 2010 09:09:19 -0700

Sorry for the duplicate post, but this is very relevant to our
understanding of NAT64 and DNS64

=======

Folks,

It has been suggest several times to me that IPv4 literals be
cataloged in a central location so that those working to develop
IPv6-only networks and services can know the impact of IPv4 addresses
that are hard-coded into content and protocols.  So, i created this
Google Groups http://groups.google.com/group/ipv4literals and provided
an example template for reporting found IPv4 literals.  Right now, the
threat of IPv4 literals on IPv6-only networks is small from the
network operator perspective, it is not a blocking issue.  But, for
the content owners who knowingly or unknowingly have IPv4 literals as
part of their service, this is major breakage.  That said, they have a
right to know how their service will break so that they can accept the
risk of having their content unavailable on major networks or work to
use DNS names that will function correctly.  Extra bonus points if
they resolve this issue of inter-operating with IPv6-only networks by
producing native IPv6 content!

In my own efforts, i have found content owners very happy to receive
this proactive notification.  Explicitly, myspace and Yahoo! have been
very good partners in finding and resolving issues of this nature and
removing IPv4 literals from their production services.  Also, over the
course of my work I have seen Hulu.com independently move to using DNS
names.  The issue is most commonly found with streaming services on
the Internet, especially ones involving CDNs.

Best regards,

Cameron

---

From: Matthew Kaufman <[email-masked]>
Date: Sun, 25 Jul 2010 14:17:08 -0700

> the Internet, especially ones involving CDNs.
Are you aware that this misses millions of not-looked-up-in-DNS IPv4 
literal addresses in use by protocols like BitTorrect, Adobe's RTMFP in 
Flash Player, and Skype's proprietary protocol (to name a handful I 
happen to know about)?

"Removing IPv4 literals from their production services" is not feasible 
for these types of systems, and so a plan which does NAT64 by mucking 
with DNS isn't acceptable.

(Nor will it function end-to-end with DNSSEC)

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Sun, 25 Jul 2010 14:20:10 -0700

Matthew Kaufman wrote:
> literal addresses in use by protocols like BitTorrect, Adobe's RTMFP 
> in Flash Player, and Skype's proprietary protocol (to name a handful I 
> happen to know about)?
>
> "Removing IPv4 literals from their production services" is not 
> feasible for these types of systems, and so a plan which does NAT64 by 
> mucking with DNS isn't acceptable.
>
And your suggestion to generate a packet capture demonstrating the issue 
will fail with both RTMFP and Skype, for sure, as both are encrypted at 
that point.

Even STUN and ICE obfuscate (though in a well-known way) the IPv4 
addresses literals they use so that NAT boxes won't try to helpfully 
edit them , which is *another* case which will fail (sending an IPv4 
candidate learned from STUN via ICE will not function in a DNS-reliant 
NAT64 environment).

Matthew Kaufman

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 Jul 2010 09:49:35 +1200

On 2010-07-26 09:20, Matthew Kaufman wrote:
...
> candidate learned from STUN via ICE will not function in a DNS-reliant

These are some of the reasons that I'm quite disappointed that the
applications community hasn't taken the bait offered by
draft-carpenter-referral-ps-00.txt and its predecessors
draft-carpenter-grobj-reqts-00.txt, draft-carpenter-behave-referral-object-01.

The failure to recognise that referrals via binary IP addresses
is a *broken* solution, in the present and future Internet,
is pretty serious IMHO. And it is almost orthogonal to
the much simpler observation that address literals in URLs
should be avoided; NAT64 is only one of the reasons for that.

    Brian

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 25 Jul 2010 18:25:25 -0400

> (Nor will it function end-to-end with DNSSEC)

DNS64 already includes some hints for where the DNSSEC work has to be
done, and how.  I note, however, that completing that work is not
actually in the candidate charter for the WG.  Given that the root is
already signed, that could be a bad thing: I suspect someone will have
to take up this work.  (I know this wasn't your primary point, but it
seemed worth pointing out in passing.)

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 25 Jul 2010 15:45:11 -0700

On Sun, Jul 25, 2010 at 2:17 PM, Matthew Kaufman <[email-masked]> wrote:
> Are you aware that this misses millions of not-looked-up-in-DNS IPv4 literal
> addresses in use by protocols like BitTorrect, Adobe's RTMFP in Flash
> Player, and Skype's proprietary protocol (to name a handful I happen to know
> about)?
>
> "Removing IPv4 literals from their production services" is not feasible for
> these types of systems, and so a plan which does NAT64 by mucking with DNS
> isn't acceptable.

I am only trying to fix that which can be fixed, if it cannot be fixed
(BitTorrent ...), then it is ultimately that application's issue to
work within the boundaries of what can be supported within a NAT64 and
DNS64 environment, or accept not working in parts of the IPv6-only
internet.  NAT64 and DNS64 never intended to solve all thing, and
consequently it is a good framework to incent IPv6 adoption across the
Internet where e2e can be restored.

On today's Internet, there are many things that can work with
DNS64/NAT64 but do not work because IPv4 literals are used.  I have
solved many of these issues already on major web sites by working
cooperatively with major content owners and web site admins, my goal
here is to expand that work and make it more general.

In my experience doing this work, having an IPv6-only network behind a
NAT64 / DNS64 can reveal the IPv4 literals in packet captures by
configuring a host with a dummy IPv4 interface.  All communications
should go via IPv6 if the DNS64 is used on the host.  But, if an IPv4
literal is used, the packet capture will show the host attempting to
transmit IPv4 packets via its dummy ipv4 interface and failing.

Regards,

Cameron

---

From: Christian Huitema <[email-masked]>
Date: Sun, 25 Jul 2010 23:08:54 +0000

> The failure to recognise that referrals via binary IP addresses is a *broken* solution, 
> in the present and future Internet, is pretty serious IMHO. And it is almost orthogonal
>  to the much simpler observation that address literals in URLs should be avoided; 
> NAT64 is only one of the reasons for that.

Solutions like STUN, ICE, and TURN emerged from practical needs. These tools were designed for the Internet we have, not the Internet we wish we had. I fully expect that if NAT64 starts being deployed in significant numbers, STUN and ICE will evolve to enable connectivity through NAT64. Similarly, if the default firewalling advocated in RFC 4864 starts impeding peer-to-peer applications, I expect that ICE will evolve and take care of that.

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 Jul 2010 14:24:23 +1200

Christian,

> Solutions like STUN, ICE, and TURN emerged from practical needs. These tools were designed for the Internet we have, not the Internet we wish we had. I fully expect that if NAT64 starts being deplo…

Certainly, some form of Super ICE would be a candidate for solving the
generic referrals problem. My gripe is that the apps community doesn't
seem to recognise that there *is* a generic problem.

    Brian

---

From: Christian Huitema <[email-masked]>
Date: Mon, 26 Jul 2010 03:54:36 +0000

> Certainly, some form of Super ICE would be a candidate for solving 
> the generic referrals problem. My gripe is that the apps community 
> doesn't seem to recognise that there *is* a generic problem.

ICE is pretty close to what we need. Note that we already have end-to-end identifiers built in the P2P applications -- SIP URL, unique ID of torrents, etc. There is little reason to add another set of identifiers at the network level.

Of course, to make it really work, we would need to forget TCP, or rather run TCP on top of UDP, so it can traverse NAT and firewalls without requiring a relay. Kind of what Teredo does...

-- Christian Huitema

---

From: Matthew Kaufman <[email-masked]>
Date: Sun, 25 Jul 2010 21:20:29 -0700

Christian Huitema wrote:
> Solutions like STUN, ICE, and TURN emerged from practical needs. These tools were designed for the Internet we have, not the Internet we wish we had.
Agreed. As did the other ways applications have evolved to pass 
addresses around for things like peer-to-peer overlay networks.
>  I fully expect that if NAT64 starts being deployed in significant numbers, STUN and ICE will evolve to enable connectivity through NAT64.
Either that or 1) problems like this will force NAT64 to evolve in a 
different direction or B) problems like this will force carriers to 
ignore NAT64 and figure out an alternative.

Given where we are in this process, it seems like "1" might be the 
better choice.

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Sun, 25 Jul 2010 21:29:32 -0700

>>> NAT64 is only one of the reasons for that.
*DNS itself* is an example of referrals via binary IP addresses. The 
problem we face here is that DNS is not the *only* example, and so 
tweaking its behavior is not sufficient to enable NAT64. (Plus the 
aforementioned DNSSEC implications of "tweaking its behavior").
> seem to recognise that there *is* a generic problem.
The apps community:
1) Had to solve this several times in parallel before it was realized 
that the problem was shared
2) Often treats their way of solving the problem as part of the "secret 
sauce" which makes them better than the competition
3) Often has the same problem that draft-carpenter-referral-ps alludes 
to regarding the tension between things in the middle wanting to 
see/modify the referrals and security considerations. (Note for instance 
that if one followed section 5 "referral information should be 
transmitted through authenticated and encryopted channels" of that draft 
then section 4.4 requirement 3 breaks, and that's the very requirement 
which would be required for something like a NAT64 middlebox to replace 
IPv4 referrals with translated IPv6 literals)

Matthew Kaufman

---

From: Matthew Kaufman <[email-masked]>
Date: Sun, 25 Jul 2010 22:24:34 -0700

Here's where I personally think we are at this point:

We have tried and failed (twice, by my count) to define a magic IPv6 
prefix that refers to IPv4 addresses that hosts or translators can use 
to do the right thing in environments like this (IPv6-only networks, no 
dual-stack).

Now we're trying to define *another* magic IPv6 prefix that refers to 
IPv4 addresses, only this time we haven't decided if it is a fixed 
choice or must be learned via a discovery mechanism.

And now it is too late to do the right thing (have the hosts do the work 
of sending IPv4 packets over IPv6 if there's no IPv4 interface 
available) and want to put that work on the application authors.

And we think that we can simultaneously solve the problem of both the 
magic prefix itself *and* discovery of that prefix by the application by 
tweaking DNS replies to that class of applications which look up their 
IPv4 addresses in DNS but which also know how to do IPv6.

The open questions I have are:
1. Given that the root is already signed and we are moving towards 
DNSSEC, why is a host supposed to trust a NAT64+DNS device when it 
performs the substitution?
2. Do we really understand what happens when IPv4+IPv6 applications 
think they are talking IPv6 but are really talking to an IPv4 host? 
(FTP64 is the obvious one, but there's probably more... consider the 
case of Java applets that might talk to legacy IPv4 things and new 
upgraded IPv6 things for a start on how widespread this problem might be)
3. For those applications which must be modified to work at all in this 
environment (because they get their IPv4 addresses from somewhere other 
than DNS), presuming it actually is deployed by IT departments and/or 
carriers, how much work are we going to ask them to do? (In other words, 
are we going to give them a very easy (but naive) task like "this is the 
new single magic prefix you must add to your candidate address list", a 
harder task like "look up a special DNS name to discover whether or not 
you might need to add a prefix and more candidate addresses", or an 
impossible task like "do something which the host OS can do but which 
unprivileged apps cannot access, like sniff at RA messages, to learn the 
prefix you must add")
4. How long do we think it will be before the legacy applications are 
upgraded in sufficient quantity that deployment of NAT64 like this 
wouldn't break important (to the customer/user) things?
5. Given all of the above, and that app writers have learned to deal 
with NAT44 already, why is any of this a better solution than enabling 
your host IPv4 stack, carrying IPv4 traffic on the wire to the NAT 
device point, and doing "carrier grade" NAT44?

Matthew Kaufman

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 26 Jul 2010 03:31:20 -0400

> performs the substitution?

There are two possibilities.  One is that you have a secure connection
to the DNS server, and you don't do validation in the end host
(validation is done in the DNS64 then).  Alternatively, if you're
going to do validation in the end, then you also need to do DNS64.  I
think the DNS64 document explains this; if you don't, it'd be really
really good to know that now (since the DNS64 draft is past IETF LC).
In any case, in order to do DNSSEC in the host behind DNS64, the host
has to know how to do DNS64 itself.  Which means it has to learn the
prefix.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 26 Jul 2010 14:58:26 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Matthew Kaufman
> Sent: Sunday, July 25, 2010 11:17 PM
> To: Cameron Byrne
> Cc: [email-masked]
> Subject: Re: [BEHAVE] Catalog of IPv4 literals
> 
> Cameron Byrne wrote:

To clarify, the NAT64 does not touch any aspect of DNS; that combined
functionality existed in NAT-PT but is split with BEHAVE's approach.
With BEHAVE's approach, DNS64 does the AAAA synthesis and is separate
from NAT64, and there isn't a protocol between them and DNS64 and
NAT64 can be implemented in separate devices.

> (Nor will it function end-to-end with DNSSEC)

Regarding end to end DNSSEC, it can work in conjunction with DNS64. 
To work, it requires the host be able to do its own synthesis
of the IPv6 address.  This is described in item #3 of
http://tools.ietf.org/html/draft-ietf-behave-dns64-10#section-5.5

(DNS64's operation with DNSSEC came up during my NAT Tutorial
presentation on Sunday.  So I want to make sure this is clear on
the mailing list.)

-d

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 26 Jul 2010 07:06:15 -0700

On Sun, Jul 25, 2010 at 10:24 PM, Matthew Kaufman <[email-masked]> wrote:
> We have tried and failed (twice, by my count) to define a magic IPv6 prefix
> that refers to IPv4 addresses that hosts or translators can use to do the
> right thing in environments like this (IPv6-only networks, no dual-stack).
>
> Now we're trying to define *another* magic IPv6 prefix that refers to IPv4
> addresses, only this time we haven't decided if it is a fixed choice or must
> be learned via a discovery mechanism.
>
> And now it is too late to do the right thing (have the hosts do the work of
> sending IPv4 packets over IPv6 if there's no IPv4 interface available) and
> want to put that work on the application authors.
>
> And we think that we can simultaneously solve the problem of both the magic
> prefix itself *and* discovery of that prefix by the application by tweaking
> DNS replies to that class of applications which look up their IPv4 addresses
> in DNS but which also know how to do IPv6.
>
> 1. Given that the root is already signed and we are moving towards DNSSEC,
> why is a host supposed to trust a NAT64+DNS device when it performs the
> substitution?
> 2. Do we really understand what happens when IPv4+IPv6 applications think
> they are talking IPv6 but are really talking to an IPv4 host? (FTP64 is the
> obvious one, but there's probably more... consider the case of Java applets
> that might talk to legacy IPv4 things and new upgraded IPv6 things for a
> start on how widespread this problem might be)
> environment (because they get their IPv4 addresses from somewhere other than
> DNS), presuming it actually is deployed by IT departments and/or carriers,
> how much work are we going to ask them to do? (In other words, are we going
> to give them a very easy (but naive) task like "this is the new single magic
> prefix you must add to your candidate address list", a harder task like
> "look up a special DNS name to discover whether or not you might need to add
> a prefix and more candidate addresses", or an impossible task like "do
> something which the host OS can do but which unprivileged apps cannot
> access, like sniff at RA messages, to learn the prefix you must add")
> upgraded in sufficient quantity that deployment of NAT64 like this wouldn't
> break important (to the customer/user) things?

For mobile, the wait is over.  Applications built against common
mobile platform SDKs are generally ready to go now.  My experience
running a beta program of IPv6-only Symbian and Maemo phones for the
past 5 months has proven this well.  To be blunt, 90+% of the traffic
on my network is web and email, and most 3rd party applications just
use those standard protocols in standard ways... they just call the
web browser. Jari Arkko at Ericsson has a similar experience, see
slide 5 where he says some mobile platforms can reach 100%
functionality today with NAT64/DNS64
https://sites.google.com/site/ipv6implementors/2010/agenda/11_Arkko_goog_nat64exp.pdf

> 5. Given all of the above, and that app writers have learned to deal with
> NAT44 already, why is any of this a better solution than enabling your host
> IPv4 stack, carrying IPv4 traffic on the wire to the NAT device point, and
> doing "carrier grade" NAT44?

Doing CGN today at very large scale, it's not fun.  There is no end to
the growth of traffic or the higher level growth in sessions per user.
 NAT64 is a path to "sunsetting" the middle box that is NATxy.   It
does not start right away, but eventually NATxy leaves my network if I
am on a NATxy path.  Additionally, on average per user, my users that
are ipv6-only on NAT64 consume at least 40% less NAT state than my
NAT44 user simply because in aggregate, 40+% of my users traffic goes
to Google and Facebook, and they have IPv6 native today (mostly).

I notice none of your scenarios involve IPv6 end to end, which is the
end-state goal.  I know it is banned to be optimistic about IPv6
adoption, but 2010 has certainly been a watershed of IPv6 activity.
Personally, i think all the pain point you bring up are solved by
IPv6, no?  So if there is sufficient pain in IPv4 (referrals, nats,
apps, networks, ICE, STUN ...), perhaps IPv6 starts looking like a
macro-level solution that is worthwhile.

Cameron

>
> Matthew Kaufman
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Jul 2010 11:02:26 +1200

On 2010-07-26 17:24, Matthew Kaufman wrote:
...

> available) and want to put that work on the application authors.

Opinions may vary about whether that's the right thing, but it isn't
responsive to the problem of IPv6-only devices (devices with no IPv4
code whatever inside them).

I don't see why it's too late, since this scenario lies firmly in the
future, except for artificial tests. The authors of
draft-cui-softwire-host-4over6, draft-zheng-pnat-dual-v6addr, and
draft-huang-behave-bih, for example, don't seem to think it's too late.

      Brian

---

From: bo zhou <[email-masked]>
Date: Wed, 28 Jul 2010 11:04:55 +0200

> [bo] Do not forget ALG issue, which also cause operator big headache when
try to introduce IPv4 literals based app. to the customers.

-- 
Regards,

Bo Zhou
China Mobile

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 28 Jul 2010 19:11:13 +0200

> Behalf Of bo zhou
> Sent: Wednesday, July 28, 2010 11:05 AM
> To: Cameron Byrne
> Cc: [email-masked]; [email-masked]
> Subject: Re: [BEHAVE] NAT64 recap was Re: Catalog of IPv4 literals
> 
> 
> 
> [bo] Do not forget ALG issue, which also cause operator big headache
> when try to introduce IPv4 literals based app. to the customers.

http://tools.ietf.org/html/draft-wing-v6ops-v6app-v4server

-d