Re: [v6ops] I-D Action: draft-mawatari-v6ops-464xlat-00.txt
Cameron Byrne <cb.list6@gmail.com> Mon, 30 January 2012 23:06 UTC
Return-Path: <cb.list6@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63C0E11E80D1 for <v6ops@ietfa.amsl.com>; Mon, 30 Jan 2012 15:06:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.172
X-Spam-Level:
X-Spam-Status: No, score=-3.172 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncRjrXdEaJKX for <v6ops@ietfa.amsl.com>; Mon, 30 Jan 2012 15:06:05 -0800 (PST)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC5121F875B for <v6ops@ietf.org>; Mon, 30 Jan 2012 15:06:05 -0800 (PST)
Received: by pbdy7 with SMTP id y7so80707pbd.31 for <v6ops@ietf.org>; Mon, 30 Jan 2012 15:06:05 -0800 (PST)
Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.68.222.103 as permitted sender) client-ip=10.68.222.103;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.68.222.103 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com
Received: from mr.google.com ([10.68.222.103]) by 10.68.222.103 with SMTP id ql7mr56193855pbc.53.1327964765071 (num_hops = 1); Mon, 30 Jan 2012 15:06:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=X5tG2Wq2YQoLhCwbtgOBVcep6VncO6kTe8jLD5jUFOo=; b=hCO4d2wXzjUUVHqE6/4zPjnG3LrYdR3DRiccGdQn/ePo/ggM79AaJF0M/Qnlg0RKG0 sQuzF/ELJIPh+/Q3ZlYu1XbHD1zUYsgnpNqXiIx2TTr4k5zht7qMyBszmvaa3Q6tUpwL PQXqQBOzC2u+Q7oCQWse1UxKhU9+nd6cvor5s=
MIME-Version: 1.0
Received: by 10.68.222.103 with SMTP id ql7mr46085515pbc.53.1327964764944; Mon, 30 Jan 2012 15:06:04 -0800 (PST)
Received: by 10.143.78.7 with HTTP; Mon, 30 Jan 2012 15:06:04 -0800 (PST)
In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C073C6425@XMB-RCD-111.cisco.com>
References: <067E6CE33034954AAC05C9EC85E2577C073C54B4@XMB-RCD-111.cisco.com> <20120127103118kawashimam@mail.jp.nec.com> <067E6CE33034954AAC05C9EC85E2577C073C63FC@XMB-RCD-111.cisco.com> <CAD6AjGTi15JA=_3sXqr57Fng_6gqZn2tLmy8nF8AFB+-ZqVQQA@mail.gmail.com> <067E6CE33034954AAC05C9EC85E2577C073C6425@XMB-RCD-111.cisco.com>
Date: Mon, 30 Jan 2012 15:06:04 -0800
Message-ID: <CAD6AjGTVQjDqGCgdJYBzCh9J=4yfikO4WdAHrB9HPCrhtsQ9MQ@mail.gmail.com>
From: Cameron Byrne <cb.list6@gmail.com>
To: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: IPv6 Operations <v6ops@ietf.org>
Subject: Re: [v6ops] I-D Action: draft-mawatari-v6ops-464xlat-00.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Jan 2012 23:06:06 -0000
On Mon, Jan 30, 2012 at 2:59 PM, Rajiv Asati (rajiva) <rajiva@cisco.com> wrote: > 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. > Yes, a main goal is to decouple edge network growth from IPv4 availability and scale. >> 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)? > 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 > Cheers, > Rajiv > > >> -----Original Message----- >> From: Cameron Byrne [mailto:cb.list6@gmail.com] >> 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) <rajiva@cisco.com> >> 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:kawashimam@vx.jp.nec.com] >> >> 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: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] 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 >> >> >> >v6ops@ietf.org >> >> >> >https://www.ietf.org/mailman/listinfo/v6ops >> >> >> >> >> >> ======================================== >> >> >> NEC AccessTechnica, Ltd. >> >> >> Product Development Department >> >> >> Masanobu Kawashima >> >> >> kawashimam@vx.jp.nec.com >> >> >> http://www.necat.co.jp/ >> >> >> ======================================== >> >> >> >> >> >> _______________________________________________ >> >> >> v6ops mailing list >> >> >> v6ops@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/v6ops >> >> >> >> ======================================== >> >> NEC AccessTechnica, Ltd. >> >> Product Development Department >> >> Masanobu Kawashima >> >> kawashimam@vx.jp.nec.com >> >> http://www.necat.co.jp/ >> >> ======================================== >> > >> > _______________________________________________ >> > v6ops mailing list >> > v6ops@ietf.org >> > https://www.ietf.org/mailman/listinfo/v6ops
- Re: [v6ops] I-D Action: draft-mawatari-v6ops-464x… Brian E Carpenter
- Re: [v6ops] I-D Action: draft-mawatari-v6ops-464x… Masanobu Kawashima
- Re: [v6ops] I-D Action: draft-mawatari-v6ops-464x… Brian E Carpenter
- Re: [v6ops] I-D Action: draft-mawatari-v6ops-464x… Masanobu Kawashima
- Re: [v6ops] I-D Action: draft-mawatari-v6ops-464x… Rajiv Asati (rajiva)
- Re: [v6ops] I-D Action: draft-mawatari-v6ops-464x… Masanobu Kawashima
- Re: [v6ops] I-D Action: draft-mawatari-v6ops-464x… Rajiv Asati (rajiva)
- Re: [v6ops] I-D Action: draft-mawatari-v6ops-464x… Cameron Byrne
- Re: [v6ops] I-D Action: draft-mawatari-v6ops-464x… Rajiv Asati (rajiva)
- Re: [v6ops] I-D Action: draft-mawatari-v6ops-464x… Cameron Byrne