Subject: Re: [v6ops] I-D Action: draft-mawatari-v6ops-464xlat-00.txt

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Jan 2012 14:44:11 +1300

> 7.4.  DNS Proxy Implementation
> 
>    If a router implement CLAT function, it performs DNS Proxy for IPv4
>    hosts and IPv6 hosts in end-user network.  

Why is this necessary? As far as I can see, the client could use any
normal DNS server, because the A and AAAA records it needs are completely
standard.

Regards
   Brian Carpenter

---

From: Masanobu Kawashima <[email-masked]>
Date: Wed, 25 Jan 2012 02:21:20 +0900

Hi Brian,

Thank you for your comment.

I take your point. However, a CLAT can only learn the address of an IPv6
DNS recursive server through DHCPv6 (or other way). The CLAT can not easily
discover the address of an IPv4 DNS recursive server, and it has to perform
all DNS resolution over IPv6.

The CLAT can pass this IPv6 address to downstream IPv6 hosts, but not to
downstream IPv4 hosts. As such, the CLAT should implement a DNS proxy.

Regards,
Masanobu

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

========================================
 NEC AccessTechnica, Ltd.               
 Product Development Department         
 Masanobu Kawashima                     
 [email-masked]               
 http://www.necat.co.jp/                
========================================

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Jan 2012 09:21:07 +1300

> downstream IPv4 hosts. As such, the CLAT should implement a DNS proxy.

But it should also be transparent to DNS queries over v4 or v6, if the
client acquires a DNS server address by other means.

Thanks
   Brian

---

From: Masanobu Kawashima <[email-masked]>
Date: Wed, 25 Jan 2012 09:36:42 +0900

Hi Brian,

I agree with you completely.

The CLAT should be a DNS proxy to support IPv4 and IPv6 clients of the
CLAT and ensure that IPv6 end to end is preserved between the CLAT and
the IPv6 DNS sever.

The 464XLAT should also allow for the less optimal IPv4 DNS queries from
clients, which would require 464XLAT translation between the IPv4 hosts
and the IPv4 DNS servers. IPv6 enabled host may also directly query an
IPv6 DNS server.

We will add some clarifying language about this in the next revision.
Thank you for your helpful comments.

Regards,
Masanobu

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 26 Jan 2012 09:50:29 -0600

Masanobu-san,

This is an interesting discussion and proposal. Few Q --

1. How is IPv4 address getting assigned to the host?
2. Could we not use an existing DHCP option to convey DNS server IPv4
address to the CLAT device, which can convey the DNSv4 address the same
way as IPv4 address is conveyed? If we could, then we would not need DNS
proxy function on CLAT. 
3. Section 7.4 requires CLAT device to have router function. What
happens if it is a typical host device (without any router function)?

~~~~~~~~~
7.4. DNS Proxy Implementation
   If a router implement CLAT function, it performs DNS Proxy for IPv4
   hosts and IPv6 hosts in end-user network.  It MUST provide name
   resolution with IPv6 transport.  It does not need DNS64 [RFC6147]
~~~~~~~~~~~~~~~

4.  In section 8, did you mean to say IPv4 -> IPv6 -> IPv4 translation
below? :-)
~~~~~~~~~~~~
...
   This 464XLAT architecture has two capabilities.  One is a IPv6 ->
   IPv4 -> IPv6 translation for sharing global IPv4 addresses, another
~~~~~~~~~
	
5. Section 7.7 (Auto IPv6 Prefix Assignment) could benefit from some
explicit recommendation (since the current text says source v6 prefix
assignment is done via DHCPv6-PD or another method, and destination IPv6
prefix assignment is via some method).
	
Cheers,
Rajiv

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Masanobu Kawashima
> Sent: Tuesday, January 24, 2012 12:21 PM
> To: Brian E Carpenter
> Cc: IPv6 Operations
> Subject: Re: [v6ops] I-D Action: draft-mawatari-v6ops-464xlat-00.txt
> 
> 
> Hi Brian,
>

---

From: Masanobu Kawashima <[email-masked]>
Date: Fri, 27 Jan 2012 10:31:17 +0900

Dear Rajiv,

Thank you for your comments.

>1. How is IPv4 address getting assigned to the host?

The 464XLAT architecture does not have any requirements on how the IPv4
address is assigned. It can be assigned via static or dhcpv4. We should
add some language that the subnet must be defined in the CLAT to better
define the scope of stateless translation.

The CLAT can acts just like other home gateways or mobile hotspots that
assign RFC1918 address (such as 192.168.1.x/24) to clients. There is
nothing special about the CLAT in how it assigns the address to a client.

>way as IPv4 address is conveyed? If we could, then we would not need DNS

The focus of this effort is on an IPv6-only access network. We don't see
an architectural benefit of doing 464XLAT translation for each DNS request.
As stated to Brian, the host may have its own choice of DNS servers,
including IPv4 DNS servers that require 464XLAT, but that is not the design
we would like to promote as the ideal case.

>   resolution with IPv6 transport.  It does not need DNS64 [RFC6147]

The router function can be virtual. This is the case of the Nokia n900 and
Android, which are really just hosts.

>4.  In section 8, did you mean to say IPv4 -> IPv6 -> IPv4 translation

Yes. It is an error in writing. :-)

>prefix assignment is via some method).

It depends on network operator. Why would more explicit help?
We would like to keep the options flexible so that solution can evolve
with different wireline and wireless network capabilities. But, we agree
dhcpv6-pd is good today. We just do not want to exclude other options
without a reason.

Regards,
Masanobu

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 30 Jan 2012 16:26:10 -0600

Masanobu-San,

1. How could the DHCPv4 be used here for v4 address assignment, since
CLAT enabled device is supposed to have only IPv6? Does it even make
sense to use DHCPv4? Perhaps, specify DHCPv6 (new option, say) usage.

I agree with you to adding some explicit language and requirement on
this very point, since IPv4 address assignment is key. Also, it would be
worth clarifying whether CLAT cares about private IPv4 or public IPv4
assignment or both. I presume the last, suffice to say. 
 
2. Agreed. Having DNS-proxy is reasonable.

3. Agreed. Given that the router function (virtual or not) is mandatory
on the CLAT enabled device (gateway or mobile device) for this proposal
to work, I would urge you to mention that explicitly not only in section
7.4, but also in section 3 where CLAT is defined first.

5. Agreed. It would be better to mention DHCP-PD as the recommended
mechanism, while allowing the other mechanism. I would get rid of the
word 'auto' from the title, btw. While we agree to IA_PD, is there a
need for IA_NA? It would be worth clarifying in that section.

On a basic note, How DNS and HTTP be ever useful for ipv6 prefix
assignment? 

Cheers,
Rajiv	

> From: Masanobu Kawashima [mailto:[email-masked]]
> Sent: Thursday, January 26, 2012 8:31 PM
> To: Rajiv Asati (rajiva)
> Cc: Brian E Carpenter; IPv6 Operations
> Subject: RE: [v6ops] I-D Action: draft-mawatari-v6ops-464xlat-00.txt
> 
> 
> Dear Rajiv,
> 
> >> DNS recursive server through DHCPv6 (or other way). The CLAT can
not
> >easily
> >> The CLAT can pass this IPv6 address to downstream IPv6 hosts, but
not
> >to
> >> >>    If a router implement CLAT function, it performs DNS Proxy
for
> >IPv4

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 30 Jan 2012 14:49:46 -0800

Hi Rajiv,

> sense to use DHCPv4? Perhaps, specify DHCPv6 (new option, say) usage.

The CLAT may be a home gateway or a cell phone.  Facing the WAN ISP
network, the CLAT interface is only IPv6.  Facing the subscriber home
network, the CLAT is dual-stack.  For IPv6 flows, the CLAT is a basic
IPv6 router.  For IPv4 flows, the CLAT is does stateless RFC 6145
translation.

In this way, the CLAT is a DHCPv4 server for IPv4 clients in the home
network. It may also be a DHCPv6 server for subscriber IPv6 clients
and a DHCPv6 client of the ISP network.

Just like a common home router today, the CLAT will assign RFC1918
space to the home client, but instead of doing NAT44 it will do RFC
6145 protocol translation as described in the draft.

Does this answer your question?

> assignment or both. I presume the last, suffice to say.

The 464XLAT draft is focused on transition to an IPv6-only ISP access
network where IPv4 is highly scarce.  So, the explicit assumption is
that RFC1918 IPv4 addresses are used behind the CLAT.

> 2. Agreed. Having DNS-proxy is reasonable.

ACK

> 7.4, but also in section 3 where CLAT is defined first.

ACK

> On a basic note, How DNS and HTTP be ever useful for ipv6 prefix

I having trouble parsing this last question?  Can you explain some more?

Thanks again for the useful review and insightful questions.

CB

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 30 Jan 2012 16:59:03 -0600

Hi Cameron,

> Does this answer your question?

Yes, it does. And thanks for going over the basics.

I gather that CLAT has nothing to do with the public IPv4 address, though PLAT absolutely does.

> that RFC1918 IPv4 addresses are used behind the CLAT.

Acked.

> I having trouble parsing this last question?  Can you explain some more?

Sure. Section 7.7 mentions DNS and HTTP for IPv6 prefix assignment, and I just don't follow that, thinking about DHCP (or even TR-069) being used for prefix assignment. Why should they be used (and how)?

Cheers,
Rajiv

> From: Cameron Byrne [mailto:[email-masked]]
> Sent: Monday, January 30, 2012 5:50 PM
> To: Rajiv Asati (rajiva)
> Cc: Masanobu Kawashima; IPv6 Operations

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 30 Jan 2012 15:06:04 -0800

> I gather that CLAT has nothing to do with the public IPv4 address, though PLAT absolutely does.

Yes, a main goal is to decouple edge network growth from IPv4
availability and scale.

> Sure. Section 7.7 mentions DNS and HTTP for IPv6 prefix assignment, and I just don't follow that, thinking about DHCP (or even TR-069) being used for prefix assignment. Why should they be used (and…

Ah.  I am not sure :)  If it is confusing, it may be best to simplify
that list.  The DNS method might overlap with our explicit mentions of
draft-ietf-behave-nat64-discovery-heuristic

We can simplify this area to avoid confusion.

Thanks again!

Cameron