Subject: [BEHAVE] draft-cao-behave-dsdns64-00

From: Andrew Sullivan <[email-masked]>
Date: Fri, 12 Feb 2010 14:51:41 -0500

Dear colleagues,

I just read draft-cao-behave-dsdns64-00.  I confess that I am completely mystified by it.

The central point of the draft appears to be that the DNS64 should
handle A queries normally.

There is no explanation of how that would even possibly work.  The
DNS64 works by synthesizing AAAA out of A records.  It _can't_ return
an A record because it will return the AAAA first.

If that assumption is violated, actually, the entire DNS64 project is
doomed as near as I can tell.

Have I missed something?

Best regards,

A

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

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 12 Feb 2010 12:27:50 -0800

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Andrew Sullivan
> Sent: Friday, February 12, 2010 11:52 AM
> To: [email-masked]
> Subject: [BEHAVE] draft-cao-behave-dsdns64-00
> 
> Dear colleagues,
> 

It should work if the policy table IPv6/IPv4 preference is inverted
from the default.  That is, the host's RFC3484 policy table could be
changed to prefer IPv4.  

That would have significant implications, though:  if a server
is dual-stacked, the dual-stack client will always use IPv4.  That
IPv4 traffic is likely to be NATted (due to impending IPv4 
exhaustion and the need for the ISP to conserve IPv4 addresses),
which will harm the user's experience if they need more TCP
ports than available on the NAT.  Some applications need a lot
of TCP ports, as we know -- the canonical example is Google Maps
but there are other applications that also use a lot of TCP
ports.  To avoid the poor user experience of running out of 
TCP ports on the NAT, the content provider has an incentive to
enable IPv6.  However, if the dual-stack client continues to
prefer IPv4, the IPv6 path isn't used, and the user experience
continues to be poor.  With such an address preference, the 
user experience only improves when the A record is no longer
in the DNS.  That also means thousands, or millions, of 
clients would suddenly switch from using IPv4 to using IPv6
which would be a difficult adjustment for the content provider.

-d

> Best regards,
> 
> A
> 
> -- 
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 12 Feb 2010 13:07:56 -0800

>> completely mystified by it.

I don't agree with the premise of the draft -- that traffic going via
a NAT64 is entirely bad.  In some environments maybe it is bad, but in
my environment 99% of the mobile phone / device traffic goes via NAT44
today.  NAT64 and NAT44 are very similar in function and cost to the
service provider.  If the flow goes via NAT44 or NAT64 it does not
matter to me, either way the user can access the content they want and
the service provider has to support / scale  "state" in the network
for that session(s).  If the user receives a natural AAAA record, i
have less NAT state since a natural (non-DNS64 synthesized) record
will bypass the NAT64 completely, thus saving me money since i don't
have to grow the NAT capacity for any native IPv6 content (keep in
mind Google and Youtube are the largest content sources in the USA ..
and they service native IPv6)

So, using today's model, if all my users were IPv6-only with NAT64
instead of IPv4 with NAT44, i would have much less cost in the network
since native AAAA flows would not go via the NAT.

> from the default.  That is, the host's RFC3484 policy table could be

And this is exactly what we DO NOT want to happen.  Since it means
that only IPv6-only systems will go to IPv6 content, thus perpetuating
the "chicken and egg" problem to new unforeseen levels of stale-mate.

> but there are other applications that also use a lot of TCP

This is a very important point and a powerful trend with AJAX
webpages, here is the citation for NTT's work on this topic of MANY
MANY session consuming a great deal of NAT resources.

http://www.nttv6.jp/~miyakawa/IETF72/IETF-IAB-TECH-PLENARY-NTT-miyakawa.pdf

> in the DNS.  That also means thousands, or millions, of

Right, this leads to the proverbial flag-day that the IETF said would
never exists, because it will also invariably partition portions of
the Internet on the flag day

---

From: Mark Andrews <[email-masked]>
Date: Sat, 13 Feb 2010 11:13:16 +1100

> doomed as near as I can tell.

DNS64 synthesizes AAAA from A when there is no natural AAAA.

DNS64 does NOT affect A queries.  This is covered in "5.3.3. Other records"

	"All other RRs MUST be returned unchanged."

I see no wording equivalent to "Block A queries" in DNS64.

A IPv6 only host / application will only make AAAA queries as part
of normal host resolution.  Note a IPv4 client can ask for AAAA
queries and a IPv6 client can ask for A queries that are unrelated
to making network connection attempts from the client.

A dual stack host / applicaion will make both AAAA and A queries
and provided it has been taught about the DNS64 prefix will
de-preference any synthesized addresses.  Even if it hasn't been
taught the worst that will happen is that the traffic takes a
non-optimal path through the NAT64.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 15 Feb 2010 10:05:44 -0500

> DNS64 does NOT affect A queries.  This is covered in "5.3.3. Other records"

Right.

> I see no wording equivalent to "Block A queries" in DNS64.

Exactly.  But DNS64 relies implicitly on the premise that clients will
ask for AAAA first.  If they don't, then the end host gets an A record
and it never uses the NAT64.  See others' remarks on why that's a bad
idea in a dual-stack environment.

> and provided it has been taught about the DNS64 prefix will

The "provided it has been taught" condition is unreasonable.  We're
trying to arrange things so that clients don't need to be taught about
all this, because from the POV of deploying having to upgrade every
client is a non-starter.

> non-optimal path through the NAT64.

That's exactly my point, too.

A

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

---

From: Mark Andrews <[email-masked]>
Date: Tue, 16 Feb 2010 09:42:35 +1100

In message <[email-masked]>, Andrew Sullivan writes:
> ask for AAAA first.

No it doesn't.  I relies on the premise that IPv6 only clients will ask
for AAAA records to initiate connections. 

> If they don't, then the end host gets an A record

If they have a IPv4 path then using A's is not a issue.  If they
don't have a IPv4 path and don't ask for AAAA then they are broken.
It's not the job of the nameserver to fix broken applications.

> all this, because from the POV of deploying having to upgrade every

It's not upgrading.  It's configuring.  It does not come close to
the point of being a non-starter.  My many years old boxes can be
configured to do this now.  It would be nice if there was automated
methods of passing this configuration information around and it's
really needed as the default rules are a heap of ~!#~ and the only
way to get sensible rules to all the boxes is to have a provisioning
system as each site is unique and this is without throwing DNS64 into
the mix.
 
> That's exactly my point, too.

And it won't hurt 99.9% of the traffic.  Very little traffic cares
whether it is going from IPv6 to IPv4.  For most applications that
do and you are dual stacked you can force the application to choose
the transport anyway.

This is "perfect" getting in the way of "good enough".

Mark

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 16 Feb 2010 09:00:39 -0500

> for AAAA records to initiate connections. 

It's interesting to me that you and I have different ideas of what the
underlying assumption is.  I really have been relying on the
assumption that v6-desiring clients will ask for AAAA records first.
It's my understanding that implementers have been encouraged to ask
for AAAA first, modulo certain conditions, and I have also been under
the impression that this behaviour is widespread.  Are you suggesting
otherwise?

> methods of passing this configuration information around and it's

So how is "install automated methods of passing the configuration
information around" not "upgrade the boxes"?  It might not be the
resolver that needs upgrading, but you still need to touch the client
system, or it won't know how to get the automatic configuration.  No?

A

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

---

From: Mark Andrews <[email-masked]>
Date: Wed, 17 Feb 2010 01:52:45 +1100

> the impression that this behaviour is widespread.  Are you suggesting

Dual stack will ask for both.  getaddrinfo() will sort non-mapped
AAAA records to the start of the list, using default sorting rules,
but will return both to the application.  Single stack will ask for
the appropriate record for the stack.
 
> system, or it won't know how to get the automatic configuration.  No?

It will work without being touched.   It will work *better* if it
is touched or upgraded to support automated methods of passing
configuration around.

It's a show stopper if it will NOT work without being touched.  This
is not the case however.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 16 Feb 2010 14:13:15 -0500

> the appropriate record for the stack.

Ah, I see where we're missing each other.  I think the idea that we're
going to have many applications properly sensitive to this is
optimistic at best.

> is touched or upgraded to support automated methods of passing

Ok.  Note that that does not seem to be the goal of the I-D we started
talking about, however.  It's pretty hard to tell to tell from the
sketchy draft as it stands, but it seems to be aiming at supporting
unmodified dual-stack hosts behind a NAT64+DNS64, and doing that
without having them use the NAT when they could use native v4 transit.
At least, that's the only sense I can make of it.  Otherwise, there's
no need for a draft: dual-stack hosts behind a NAT64 will just use the
NAT, and who cares; applications that do care can behave how they need
to do.

If you were going to modify the end points to deal with this
condition, why not teach them about v4 _and_ v6, teach them to do
their own resolution, and teach them to prefer native v6 when
available and native v4 when available, preferring native v6 over all
things.  This is not hard to teach an end host; but we've been
operating on the assumption that the end hosts are too numerous and
cumbersome to upgrade. 

A

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Feb 2010 08:58:46 +1300

> going to have many applications properly sensitive to this is

It's certainly optimistic today. Hopefully the apps community will
slowly get better at this as they confront dual-stack or IPv6-only
in the wild, but for many years we will see a variety of app
behaviours even on a single host. An interesting case would be an app
that only knows about gethostbyname() running on a dual stack host
whose DNS server is a DNS64. We can't say that's not our problem.

    Brian

---

From: Mark Andrews <[email-masked]>
Date: Wed, 17 Feb 2010 09:49:38 +1100

> going to have many applications properly sensitive to this is

The point of NAT64+DNS64 was to allow IPv6 aware applications reach
IPv4 only services on the presumption that this will work for most
applications.  This was driven by the assumption that there will
be IPv6 only networks in the future and that the servers on the
Internet won't be upgraded to support IPv6 soon enough for these
networks.  All the clients need NAT64+DNS64 (or some other bridging
solution while the world catches up) in this senario.

The someone said what happens if a DNS64 is deployed where it is
not strictly needed.  The answer to that is non optimal traffic
flows and some applications breaking that wouldn't if DNS64 is not
deployed.

It was then asked if this can fixed and the answer is yes but it
requires some configuration to be performed and it would be better
if this could be automated.

> NAT, and who cares; applications that do care can behave how they need

draft-cao-behave-dsdns64-00 addresses a perceived issue which as
far as I can tell does not exist.  Dual stack client will ask for
A records and there is nothing in DNS64 to say don't answer these
queries.

That being said there will be operators that will want nameservers
to block A responses.  We have operators that want nameservers to
block AAAA responses unless the queries are made over IPv6 today.
This is mainly due to applications that are not multi-home aware
despite it been a RFC1123 host requirement for 20+ years.  A
multi-home aware application will try all addresses so it works
when one path is broken.

---

From: Hui Deng <[email-masked]>
Date: Wed, 17 Feb 2010 16:09:56 +0800

if we could prefer NAT64 than NAT44, it really benefit for IPv6,
IETF should prefer IPv6 friend solution other than IPv4 friend solution

I also don't think that assigning unlimited IPv4 address to UE and
encouraging them continue to use NAT44 is not a good way to go, when
will IPv6 come?

if we prefer 6 to 4, than I believe NAT64 could also be used for dual
stack connection.

thanks

-Hui

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 17 Feb 2010 09:18:20 -0800

> [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Tuesday, February 16, 2010 11:59 AM
> To: Andrew Sullivan
> Cc: [email-masked]
> Subject: Re: [BEHAVE] draft-cao-behave-dsdns64-00
> 

What is your feeling of 
http://tools.ietf.org/html/draft-wing-behave-dns64-config-02#section-3.1
to resolve that situation.  Or the other 5 mechanisms described in
that draft.

-d

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Feb 2010 14:20:24 +1300

Hi Dan,

> to resolve that situation.  Or the other 5 mechanisms described in

My understanding is that operating systems vary quite a bit in
their treatment of IPv4-mapped addresses. So I fear/suspect that
it will be hard to get consistent behaviour with that particular
mechanism. But in general, I think we need to discuss the alternatives
in your draft and choose one or two as Least Bad Current Practices,
so to speak.

   Brian

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 21 Feb 2010 09:32:38 -0800

Hui,

I don't understand.  Are you proposing changes to draft-cao-behave-dsdns64, or
discussing something else?

-d

> From: Hui Deng [mailto:[email-masked]] 
> Sent: Wednesday, February 17, 2010 12:10 AM
> To: Cameron Byrne
> Cc: Dan Wing; Andrew Sullivan; [email-masked]

---

From: Hui Deng <[email-masked]>
Date: Mon, 22 Feb 2010 10:21:23 +0800

Dan,

I guess that I used two No in that sentence, that is not correct.

what I mean is that I would like to support NAT64 is prior to NAT44,
secondly, if NAT64 could be used in dual stack network, that's also good.

thanks

-Hui

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 21 Feb 2010 22:51:48 -0800

> Sent: Sunday, February 21, 2010 6:21 PM
> To: Dan Wing
> Cc: Cameron Byrne; Andrew Sullivan; [email-masked]

Sorry, I still do not understand.  

Earlier in this email thread, Andrew, Cameron, and I pointed out that
draft-cao-behave-dsdns64-00 does not fully describe its solution.  I look
forward to a more complete description so I can understand the proposal.

-d

---

From: Zhen Cao <[email-masked]>
Date: Tue, 23 Feb 2010 18:54:10 +0800

> forward to a more complete description so I can understand the proposal.

In draft-wing-behave-dns64-config-01, section 3.4, there introduces a
solution based on host modification to avoid traversal of NAT64.  If
the DNS64 cannot support type "A" request, this feature cannot be
supported?  Actually my draft-cao-behave-dsdns64-00 would like to
clarify this issue in a simple and tentative way.

Thanks,
Cao Zhen

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 23 Feb 2010 07:32:49 -0800

> From: Zhen Cao [mailto:[email-masked]] 
> Sent: Tuesday, February 23, 2010 2:54 AM
> To: Dan Wing
> Cc: Hui Deng; Andrew Sullivan; Cameron Byrne; [email-masked]
> solution based on host modification to avoid traversal of NAT64. 

Yes, modification of the dual-stack host's RFC3484 table, so that
the IPv6/IPv4 translator is preferred least.  Example is in
http://tools.ietf.org/html/draft-wing-behave-dns64-config-02#section-3.4.3

> If the DNS64 cannot support type "A" request, this feature cannot be
> supported? 

Correct, the DNS64 needs to handle A requests.  

But draft-ietf-behave-dns64 does not change the DNS64's behavior of A requests
or A responses, as stated in
http://tools.ietf.org/html/draft-ietf-behave-dns64-06#section-5.3.3 where it
reads:

  "5.3.3. Other records

   If the DNS64 is in recursive resolver mode, then considerations
   outlined in [I-D.ietf-dnsop-default-local-zones] may be relevant.

   All other RRs MUST be returned unchanged."

> Actually my draft-cao-behave-dsdns64-00 would like to

Looking forward to it.

-d

---

From: Zhen Cao <[email-masked]>
Date: Tue, 23 Feb 2010 23:58:53 +0800

I thought normally DNS64 did not treat "A" query request. I think most
implementations do not implement that.

Thanks,
Zhen

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 23 Feb 2010 11:03:49 -0500

> implementations do not implement that.

Where did you get that idea?  If you query a DNS64 for an A record,
you'll get it back.

What DNS64 does is deal with A records specially if and only if it
tried to get a AAAA and didn't.  That's unrelated to what it does if
it tries to get A for other reasons.

A

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

---

From: Simon Perreault <[email-masked]>
Date: Tue, 23 Feb 2010 11:12:23 -0500

> implementations do not implement that.

Well, our three implementations do.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: Zhen Cao <[email-masked]>
Date: Wed, 24 Feb 2010 00:17:06 +0800

Hi, Simon,

I might misunderstand a previous discussion with you. You were
actually saying that DNS64 does not specify the behavior of A query
request.

Thanks,
Zhen
On Wed, Feb 24, 2010 at 12:12 AM, Simon Perreault

---

From: Simon Perreault <[email-masked]>
Date: Tue, 23 Feb 2010 11:29:03 -0500

> actually saying that DNS64 does not specify the behavior of A query

Yes, that's what I said. I made a mistake, but I also think you 
misunderstood.

My mistake: In mathematical terms, I thought that the DNS64 function 
only had AAAA queries as its domain. It turns out that there is a 
sentence in the spec that extends the domain to include A queries, and 
defines the DNS64 function on them to be identical to the usual DNS 
function.

But it doesn't matter. I my mind, DNS64 doesn't touch A queries as they 
are handled by normal DNS. That's probably influenced by the 
implementations that I worked on, since that's how the code does it. 
Only AAAA queries will actually reach the DNS64 code. So our DNS64 code 
doesn't know how to handle A queries. It's not defined.

I did not imply that any of this needed to be specified or that 
implementations needed to do anything differently.

Simon