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

[Cameron Byrne <[e-mail]>]

Hi Rajiv,

On Mon, Jan 30, 2012 at 2:26 PM, Rajiv Asati (rajiva) <[e-mail]> wrote:
> 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.
>

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?

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

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

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

ACK

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

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

Thanks again for the useful review and insightful questions.

CB

> Cheers,
> Rajiv
>
>> -----Original Message-----
>> From: Masanobu Kawashima [mailto:[e-mail]]
>> 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,
>>
>> 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/
>> ========================================
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops