Re: [dhcwg] TRA function draft-ietf-dhc-dhcpv4-over-ipv6
Qi Sun <sunqi.csnet.thu@gmail.com> Tue, 12 November 2013 13:48 UTC
Return-Path: <sunqi.csnet.thu@gmail.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0ED211E8140 for <dhcwg@ietfa.amsl.com>; Tue, 12 Nov 2013 05:48:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.488
X-Spam-Level:
X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 72+3xlmLA1wS for <dhcwg@ietfa.amsl.com>; Tue, 12 Nov 2013 05:48:28 -0800 (PST)
Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id DC59611E8143 for <dhcwg@ietf.org>; Tue, 12 Nov 2013 05:48:27 -0800 (PST)
Received: by mail-pd0-f176.google.com with SMTP id r10so1561089pdi.21 for <dhcwg@ietf.org>; Tue, 12 Nov 2013 05:48:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=vw9efNxC0LlGWtkSsvLf/HCAKYiTL6Lb1crJDBPCuoA=; b=dV8Kw2wq6qVINHUH5c6xTtIH+rFc5zOHJvpwqoH9T7QPAc0tZ3lxTrBHqk8M3OCTjB QhC/SLhWxFIxrIjr7YNMUqNOaOb7YxVRPsWT+CPHK1ZmvTUrV9GVUxDloJ5PlgDXmYba BO5qfubvE+NBwzYYRGYNjlylN0ZLUAOIo/dlzzS3CbPQodovIgMR4vtUBzrDk7NEyprG d/MbulGFbDbU4c/7cWBJdeuV0WgBy9Dffugq8uBKmKPh3Xz23k366Mfin6sIL/M28Jgj odAcR4mgNp0dnw5SsO8ldY8+3QcoxZlUYwWwLILn4RJq6+qd21O77DI70/WhB7GJshy6 s4tw==
X-Received: by 10.68.219.102 with SMTP id pn6mr8478947pbc.153.1384264105156; Tue, 12 Nov 2013 05:48:25 -0800 (PST)
Received: from [192.168.199.122] ([166.111.68.231]) by mx.google.com with ESMTPSA id i6sm37699833pbc.1.2013.11.12.05.48.21 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Nov 2013 05:48:24 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: multipart/alternative; boundary="Apple-Mail-20-82487001"
From: Qi Sun <sunqi.csnet.thu@gmail.com>
In-Reply-To: <CEA7AD77.903F6%ian.farrer@telekom.de>
Date: Tue, 12 Nov 2013 21:48:16 +0800
Message-Id: <0AE894AB-B356-4561-B030-4EEC7DD5BE67@gmail.com>
References: <CEA7AD77.903F6%ian.farrer@telekom.de>
To: ian.farrer@telekom.de
X-Mailer: Apple Mail (2.1085)
Cc: dhcwg@ietf.org, draft-ietf-dhc-dhcpv4-over-ipv6@tools.ietf.org
Subject: Re: [dhcwg] TRA function draft-ietf-dhc-dhcpv4-over-ipv6
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Nov 2013 13:48:28 -0000
Hi Ian, This text confuses me a little. Please see inline. On 2013-11-12, at 下午5:03, <ian.farrer@telekom.de> <ian.farrer@telekom.de> wrote: > I was just updating the v4-configuration draft after Vancouver and one thing that stands out is the following paragraph in the description of DHCPv4 over IPv6: > > It is worth noting that there is no technical reason for using relay > encapsulation for DHCPv4o6; [Qi] What do you mean by "relay encapsulation"? Do you mean the TRA transfers the response from a unmodified DHCPv4 server into an IPv6 packet? Or do you refer to I-D.ietf-dhc-dhcpv4-relay-encapsulation, which is referenced in DHCPv4 over IPv6. > this approach was taken because the > authors of the draft originally imagined that it might be used to > provide configuration information for an unmodified DHCPv4 client. [Qi] This seems talking about CRA that relays IPv4 messages to TRA or TSV. > However, this turns out not to be a viable approach: in order for > this to work, there would have to be IPv4 routing on the local link > to which the client is connected. In that case, there's no need for > DHCPv4o6. [Qi] I didn't quite get it. Could you please elaborate? > > Given that this is the case, there is no technical reason why > DHCPv4o6 can't simply use the IPv6 transport directly, without any > relay encapsulation. This would greatly simplify the specification > and the implementation, and would still address the requirements > stated in this document. > As the DHCPv6oIPv6 draft is still being updated (now with an intended Informational status), can we align these two – either by proving that the TRA is necessary (so the text can be removed from the v4-conf draft) or by removing the TRA from the DHCPv4oIPv6 draft? [Qi] What does the above text in v4-conf draft talk about, CRA or TRA? Best Regards, Qi > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg