Subject: [BEHAVE] DNS64 detecting dual stack clients

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Nov 2011 15:13:52 +1300

Maybe this has been discussed before, but it seems to me that a DNS64 can
figure out which clients are dual stack and act accordingly.

* The DNS64 runs on a box which is dual stacked. In fact, it will contain
a straight dual-stack DNS server as well as a DNS64. They schmooze.

* The box has an ARP cache and an ND cache.

* Whenever a new host appears in the ARP cache, the box checks the MAC address
against the ND cache, and vice versa.

* If there is a match, the host concerned is tagged as dual-stack and
DNS64 synthesis is bypassed for all future queries.

* Add some timeout/refresh logic to keep the information current.

* The worst case is that one query is given a synthetic DNS64 response
before the ARP entry is matched.

Regards
   Brian Carpenter

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 8 Nov 2011 22:30:03 -0500

This is not to pick on Brian.  But he provides the occasion.

> figure out which clients are dual stack and act accordingly.

What is the "act accordingly" that is the right thing here?

<rant> 

I am sick unto death of suggestions to make DNS64+NAT64 work more
reliably.  It is a nasty, 80% solution hack.  I cannot speak for
anyone else involved with it, but to me it was _always_ supposed to be
a nasty hack -- useful as a kind of field bandage for the most
egregious problems caused by the fact that there was no real IPv4-IPv6
upgrade path.  We live in a world with no more IPv4 network addresses
and little IPv6 penetration; and also one where "the Internet", for
many people, means "what I get in my browser."  I have taken as my
motto a sort of Homer Simpson one: "Aim low."  If we can mostly fix
things most of the time for the most common case, it's useful.  It's
still a nasty hack, but it's useful for now.

</rant>

In my opinion, "act accordingly" is to get out one of those
muzzle-loading-cannon-on-scissors that is so popular in Warner Bros
cartoons, and shoot it at the network administrator who configured
some poor slob's computer with a dual stack and a NAT64.

Any other case -- like solving the case where I somehow accidentally
stumble onto a NAT64 network with an unmolested IPv4 connection that
nobody knows about -- sounds to me like an optimization that shouldn't
be considered.  If the complaint is, "Yes, but then people will use
NAT when they don't have to," I express my doubts.  An infinitesimally
small number of people use unmolested, NAT-free IPv4 today.  Those
people already know how to cope with IPv6 and how to avoid sludge like
NAT64.  Everybody else just has a crappy choice of NATs to make.

If the argument is instead that we can make protocols with embedded
IPv4 literals in them work marginally better this way, then I suggest
the additional complications are not worth making for protocols that
are wrong in their conception to begin with.

Please, let us not fix something that is broken exactly as much as it
ought to be.  The pig is wearing enough lipstick.  We should put away
the cosmetics now.

A
-- 
Andrew Sullivan
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Nov 2011 16:40:32 +1300

Andrew,

I should have started with a problem statement. The administrator
has to deal with a network with some dual stack hosts and some
IPv6-only hosts, only has the blunt instruments of DHCPv6 or RFC 6106
to tell the hosts about DNS servers, and doesn't know which
hosts are which.

Yes, it's a kludge on a kludge. It might just be preferable to the one
I've been arguing with Dan about (draft-wing-behave-dhcpv6-reconfigure),
but it's still a kludge.

   Brian

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 8 Nov 2011 22:51:51 -0500

> to tell the hosts about DNS servers, and doesn't know which

How did the network administrator build such a preposterous network,
though?  This sounds like an excellent example of the fellow who goes
to the doctor complaining about the pain caused when he hits himself
in the face.

The dual-stack people should simply be provisioned separately.  "Don't
do that" seems to me to be to be a perfectly legitimate response to
this kind of problem, and I don't understand why the request to fix it
keeps coming back.  I mean, I get why: people are lazy and cheap.  But
some things can't reasonably be accommodated without causing pain to
everyone else.  Significantly complicating DNS64 -- interactions with
the arp cache?  really? -- just so someone can save a few bucks on his
provisioning infrastructure sounds to me like a bad deal, unless I'm
the guy saving the bucks.

But I'll shut up now until I've done a proper job reading the argument
between you and Dan, since I confess I've mostly been looking the
other way.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Stephan Lagerholm" <[email-masked]>
Date: Tue, 8 Nov 2011 21:00:20 -0700

Tue 11/8/2011 8:14 PM Brian Carpenter wrote:
> Maybe this has been discussed before, but it seems to me that a DNS64
> can figure out which clients are dual stack and act accordingly.
> 
> * The DNS64 runs on a box which is dual stacked. In fact, it will
> contain a straight dual-stack DNS server as well as a DNS64. They
schmooze.
> * Whenever a new host appears in the ARP cache, the box checks the MAC
> address against the ND cache, and vice versa.

That would only work if the client and the DNS server both are on the
same L2 segment. 

/Stephan

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Nov 2011 08:53:47 +1300

> That would only work if the client and the DNS server both are on the

The same *broadcast* L2 segment, in fact. Agreed - but that seems to be the
unmanaged case where the problem might arise.

On 2011-11-09 16:51, Andrew Sullivan wrote:

> this kind of problem...

As far as I can see, this would not be adequate on an open-access LAN
where hosts are plugged in without warning or planning. In that case,
a random mixture of dual stack and v6-only hosts (not to mention
v4-only hosts) can happen, and the network manager doesn't know
how to provision them. Or it's a homenet and there is no manager.

   Brian

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 9 Nov 2011 15:15:49 -0500

> how to provision them. Or it's a homenet and there is no manager.

Ok.  So they get some extra NAT.  Why is that worth making things much
more complicated, and not just a cost of deploying a NAT?  

It's this latter issue that I don't get.  Yes, NAT64 means that some
things -- even some things that work fine in an IPv4-only world --
stop working or working reliably.  But the kinds of things I keep
hearing as band-aids all sound to me at least as bad as the disease.
For instance, NAT64 + DNS64 is already far too complicated for my
liking.  The proposals I've seen are all additional complications, and
I suspect they won't get deployed because they are just too
complicated.  My initial reaction (as an old operator) to, "We'll just
hook the arp cache to your DNS server, and then you can make
differential decisions based on that," is to weep.

We know that the original vision of DNS64 + NAT64 already doesn't
"just work": it doesn't work for validators on the end point, and it
has never just worked for me on my laptop because Apple doesn't have a
nice way of getting the right DNS servers to me.  Each additional
feature and workaround will have yet another bunch of corner cases
that makes something less reliable than it would have been.  At what
point does this make deploying the so-called workaround itself (NAT64
+ DNS64) so much trouble that it isn't worth it?

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Nov 2011 09:45:54 +1300

Andrew,

You are basically right, and it's a matter of taste and commercial
judgment where to stop with the kludges. The kludge that I proposed
is confined to the DNS64 box; the alternative proposal pollutes DHCPv6
as well, which I like even less.

The correct answer is clearly for all content providers to
offer dual stack service; then the need for NAT64 goes away.
(Hence draft-carpenter-v6ops-icp-guidance.)

Regards
   Brian Carpenter

---

From: Mark Andrews <[email-masked]>
Date: Thu, 10 Nov 2011 09:45:56 +1100

> how to provision them. Or it's a homenet and there is no manager.

Why is the IETF persisting with developing DNS64/NAT64 at all?  It's
a 80% solution when there are alternative solutions that give the
level of connectivity we have today in IPv4, that work with DNSSEC,
that don't corrupt DNS responses, that work with IPv4 literals,
that work with IPv6 only hosts, that work with a network of IPv6-only
and dual stacked machines.  The only advantage DNS64/NAT64 has is
that it doesn't need node/cpe support which meant that it is easier
short term solution when you are forced into deploying IPv6 only.

DNS64/NAT64 should be seen as a stop gap solution on the way to
deploying a more comprehensive solution or as a end stage solution
when 99.999% of the world is IPv6 reachable.  It just sucks as a
general solution for providing IPv4 connectivity.

Move the DNS64 re-writing into the nodes and the whole issues of
which type of DNS server to advertise goes away.  getaddrinfo can
do everything a DNS64 nameserver does.  Add AI_DNS64MAPPED to
getaddrinfo and the application can make a choice about whether it
wants to see DNS64 mapped address or not.  Make AI_DNS64MAPPED part
of the default set of flags.

Applications that don't want mapped addresses can then turn it off
on a per call basis.

	flags = AI_DEFAULT;
#ifdef AI_DNS64MAPPED
	flags &= ~AI_DNS64MAPPED;
#endif

I'm fine with making the end stage work well.  Just stop trying to
do "no changes to the nodes" as it will not work and is a waste of
everbody's time.  DNS64 as we have it is good enough for the stop
gap stage.

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

---

From: jouni korhonen <[email-masked]>
Date: Sat, 12 Nov 2011 10:33:37 +0200

[snip]

> everbody's time.  DNS64 as we have it is good enough for the stop

This was basically the implementation we had (along with EDNS0 option for synthesized pref64 length) in our getaddrinfo() when we experimented with draft-korhonen-edns0-synthesis-flag-02. 

- JOuni

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

---

From: Mark Andrews <[email-masked]>
Date: Sat, 12 Nov 2011 19:55:56 +1100

In message <[email-masked]>, jouni korhonen writes:
> >=20
> >=20
> > 	flags =3D AI_DEFAULT;
> > 	flags &=3D ~AI_DNS64MAPPED;
> > #endif
> >=20
> This was basically the implementation we had (along with EDNS0 option =
> for synthesized pref64 length) in our getaddrinfo() when we experimented =
> with draft-korhonen-edns0-synthesis-flag-02.=20
> 
> - JOuni

And it has the advantage that you can use getaddrinfo for handling
literal IPv4 address.

> >=20
> > --=20