Subject: Re: [homenet] a modest proposal

From: Brian E Carpenter <[email-masked]>
Date: Wed, 01 Aug 2012 08:48:46 +0100

On 31/07/2012 22:45, Curtis Villamizar wrote:
> In message <[email-masked]>
> Michael Thomas writes:
>  
>> On 07/31/2012 01:00 AM, Brian E Carpenter wrote:
>>> On 31/07/2012 01:20, Michael Thomas wrote:
>>>> On 07/30/2012 05:10 PM, Curtis Villamizar wrote:
>>>>> If you see some advantage that solves the IPv4 address depletion (a
>>>>> big point of the transition to IPv6 exercise), then I've missed it.
>>>>> If so, please point out what I missed.
>>>> No, not at all and not the point. I'm just of the mind that if
>>>> we believe that v6 is really, really ready to go there shouldn't
>>>> be any problem in substituting rfc1918 v4 space with v6 ULA
>>>> space. If that modest change leads to trouble...
>>> Well, it surely requires a DNS64 resolver in the CPE too.
>>>
>> Having embedded DNS functionality in the CPE is sort of a newish
>> requirement, yes? If we think that's inevitable for real homenets,
>> maybe this is a means of moving the ball forward?
>>  
>> Mike
> 
> 
> This requirement is Not at all new.
> 
> Most low endish CPE get a single IPv4 address from the provider, do
> NAT, offer PI addresses on the "home" side, offer themselves as DNS
> resolvers on the home side.  Act as a DNS cache using the
> nameserver(s) offerred by the service provider as forwarders.
> 
> Most home users get the CPE from the provider and the providers like
> having a resolver in the CPE so today this is a business requirement,
> not an IETF requirement.

That's true. My point was that the CPE resolver will have to be upgraded
to support DNS64 for, and *only* for, IPv6-only hosts. How it knows
which hosts are IPv6-only is another mystery.

    Brian

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 1 Aug 2012 10:13:02 +0200 (CEST)

> which hosts are IPv6-only is another mystery.

Indeed, I started a thread about this on v6ops the other day:

<http://www.ietf.org/mail-archive/web/v6ops/current/msg13581.html>

Seems there is no solution to this problem and I'm seem to be having 
trouble getting traction there that this might actually be a real problem 
that needs solving.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 01 Aug 2012 10:44:33 -0400

In message <[email-masked]>
Brian E Carpenter writes:
 
> That's true. My point was that the CPE resolver will have to be
> upgraded to support DNS64 for, and *only* for, IPv6-only hosts. How it
> knows which hosts are IPv6-only is another mystery.
>  
>     Brian

Brian,

I was responding to the question:

> >> requirement, yes?

Having DNS in the CPE is not a new requirement (at least in practice).

Extending the requirement to include DNS64 is new.

> How it knows which hosts are IPv6-only is another mystery.

I'm not if favor of using IPv4 in IPv6 and then having a NAT to turn
the IPv6 addresses into a single IPv4.  I agree with a prior comment
that this is complexity added with no significant gain.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 01 Aug 2012 13:19:21 -0400

In message <[email-masked]>
 
> trouble getting traction there that this might actually be a real problem 

Same answer as one given on that thread.  If a device can support
IPv4, then use NAT4.  If a device can only support IPv6, then the
DNS64 belongs on the IPv6-only device.  To that device all host return
AAAA records, since the A records are translated into ipv4-in-ipv6
space.  The CPE should be dual stack and be capable of both NAT4 and
NAT64 translations to allow reachability into the IPv4 world.  This is
simple.  As pointed out on the thread, a patch has already been
submitted to android and some 3gpp phone already do DNS64.

If the CPE doesn't do NAT64, the packet will wander along some route,
most likely the default route, until it either hits a NAT64 or runs
into a black hole.

Propogating DNS64 translated address can cause severe problems and
therefore should never leak outside the single IPv6 only host that
needs it to get to IPv4 addresses.  DNS64 and NAT64 already exist for
BSD and Linux (bind and pf for BSD, bind and linuxnat64 for linux).

Curtis

---

From: Mark Andrews <[email-masked]>
Date: Thu, 02 Aug 2012 07:54:22 +1000

> BSD and Linux (bind and pf for BSD, bind and linuxnat64 for linux).

DNS64 does not add synthesised addresses to existing AAAA RRsets.
IPv6-only nodes will not be able to connect to dual stack servers
as there is no IPv6 path.

> Curtis
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 2 Aug 2012 07:58:38 +0200 (CEST)

> DNS64 belongs on the IPv6-only device.  To that device all host return

Am I interpreting you correctly in that you're saying that an IPv6 only 
device should have a built in resolver that does DNS64 in case of v6 only 
connectivity?

I can see that this would work, but is that a generally accepted solution? 
On Android, this would mean that dnsmasq would need to gain DNS64 
functionality (and also needs to be able to detect the NAT64 prefix 
somehow).

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Aug 2012 11:29:32 +0100

On 02/08/2012 06:58, Mikael Abrahamsson wrote:
> device should have a built in resolver that does DNS64 in case of v6
> only connectivity?
> 
> I can see that this would work, but is that a generally accepted
> solution? On Android, this would mean that dnsmasq would need to gain
> DNS64 functionality (and also needs to be able to detect the NAT64
> prefix somehow).

That is one of the models discussed in BEHAVE, of course, and it deals
neatly with the DNSSEC conundrum for DNS64. But the normal model is
the one that Curtis doesn't like. NAT64/DNS64 plays better when
the client network is truly IPv6-only; with mixed hosts, you really need
to provision dual stack hosts with a normal DNS server, and the IPv6-only
hosts with a DNS64.

    Brian

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 07 Aug 2012 11:35:13 -0400

In message <[email-masked]>
 
> functionality (and also needs to be able to detect the NAT64 prefix 

Re "and also needs to be able to detect the NAT64 prefix somehow":

Asking DNS to resolve nat64prefix might be a solution.  It might find
nat64prefix.sitelocal or nat64prefix.<something-in-search-path>.  If
so, then as long as it is on an IPv6 capable subnet (moot point if it
is an IPv6 only host on a IPv4 only subnet) and can reach the
nat64prefix, then it can reach the IPv4 world.  This would work for
mobile devices even without site local nat64 support as long as it
knew where to find a remote nat64 gateway.  OTOH preventing abuse of a
remotely accessible nat64 gateway advertised in DNS would be a
challenge.

I don't think adding DNS64 to dnsmasq would be all that difficult.  It
is mostly translating A records into AAAA records unless I am missing
something that is hard to do.

Putting the DNS64 on the host would allow a mix of v6-only hosts and
IPv4 only hosts and DS hosts on a DS network.  On a v6-only subnet, v6
and DS hosts could operate with access to v4 only if they did DNS64.
The option to put DNS64 in a gateway also exists, but would be a
negative on a DS subnet if it were to accommodate a lone v6 only host
(for example, a cellphone on the WiFi in a home or a hotspot running
mostly v4 at this time).

The problem with putting DNS64 at a gateway is that it breaks all of
the v4 only devices (which are still plentiful).

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 07 Aug 2012 11:48:59 -0400

In message <[email-masked]>

Brian,

What you suggest might be accomplished by having DHCP4 return a
different nameserver than DHCP6.  At the very least the same
nameserver (same copy of bind or whatever on a DS machine) could
respond differently if the private side query arrives via IPv4 than if
it arrives via IPv6.  Worst case is DS machines make use of NAT64 when
they could have used IPv4.

[aside: Bind has views, but I don't know if the view support would
allow this.  It seems like it would.  It would be nice if this were
doable today with no changes.  ie: existance proof]

Curtis

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 07 Aug 2012 19:11:14 +0100

> they could have used IPv4.

Right, but that is something that people in BEHAVE thought was the worst
thing since unsliced bread.

   Brian

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 08 Aug 2012 11:19:35 -0400

In message <[email-masked]>

Brian,

NAT4 or NAT64 are both stateful with state per connection.  Things
with state per connection don't scale well.  But we may be stuck due
to the continued use of IPv4 and the depletion of IPv4 addresses.

We have already reached a point where providers are running NAT4 to
reduce the use of addresses in their infrastructure.  When the CPE
also runs NAT4 some things break.  If the providers run native IPv6
only and do NAT64 rather than DS and NAT4 it might be no worse for the
provider and reduce the number of NATs before reaching a globally
routable address down to one.

For that reason I thing BEHAVE is correct in thinking that DNS64 and
NAT64 at a gateway is a better choice.

OTOH - For the home network today, there are still IPv4 only devices.
For example, I look at my home and see a TV streaming device that make
no pretense of understanding IPv6, a SIP phone base station that has
minimally functioning IPv6 but can't function without IPv4, and a
bunch of computers (which run FreeBSD and are happy being DS).
Haven't checked the fridge.  I'm not a gadget guy.

As long as many customers, probably the vast majority, have one or
more IPv4 only devices, it is infeasible for a provider to deploy
NAT64, DNS64 and offer IPv6 only.  BEHAVE preference or not, it won't
work today.  Maybe in a decade but we don't have that much time.

Curtis

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 9 Aug 2012 07:32:22 +0200 (CEST)

On Wed, 8 Aug 2012, Curtis Villamizar wrote:

> As long as many customers, probably the vast majority, have one or more 
> IPv4 only devices, it is infeasible for a provider to deploy NAT64, 
> DNS64 and offer IPv6 only.  BEHAVE preference or not, it won't work 
> today.  Maybe in a decade but we don't have that much time.

What was said in BEHAVE (afaik), was that using a DNS64 resolver for a 
dual stacked machine is considered harmful.