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

[Masanobu Kawashima <[e-mail]>]

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.


>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. 

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.


>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]
>~~~~~~~~~~~~~~~

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
>below? :-)
>~~~~~~~~~~~~
>...
>   This 464XLAT architecture has two capabilities.  One is a IPv6 ->
>   IPv4 -> IPv6 translation for sharing global IPv4 addresses, another
>~~~~~~~~~

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


>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).

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


>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: [e-mail] [mailto:[e-mail]] 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,
>> 
>> 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
>> 
>> 
>> >> 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
>> >
>> >_______________________________________________
>> >v6ops mailing list
>> >[e-mail]
>> >https://www.ietf.org/mailman/listinfo/v6ops
>> 
>> ========================================
>>  NEC AccessTechnica, Ltd.
>>  Product Development Department
>>  Masanobu Kawashima
>>  [e-mail]
>>  http://www.necat.co.jp/
>> ========================================
>> 
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops

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