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

["Rajiv Asati (rajiva)" <[e-mail]>]

Hi Cameron,

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

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.

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

Acked.

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

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


> -----Original Message-----
> From: Cameron Byrne [mailto:[e-mail]]
> Sent: Monday, January 30, 2012 5:50 PM
> To: Rajiv Asati (rajiva)
> Cc: Masanobu Kawashima; IPv6 Operations
> Subject: Re: [v6ops] I-D Action: draft-mawatari-v6ops-464xlat-00.txt
> 
> 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