[dhcwg] TRA function draft-ietf-dhc-dhcpv4-over-ipv6
<ian.farrer@telekom.de> Tue, 12 November 2013 09:03 UTC
Return-Path: <ian.farrer@telekom.de>
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 EA9BF11E80ED for <dhcwg@ietfa.amsl.com>; Tue, 12 Nov 2013 01:03:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.482
X-Spam-Level:
X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 HwwK1mSbEB1Y for <dhcwg@ietfa.amsl.com>; Tue, 12 Nov 2013 01:03:45 -0800 (PST)
Received: from tcmail33.telekom.de (tcmail33.telekom.de [80.149.113.247]) by ietfa.amsl.com (Postfix) with ESMTP id 2F64C21E80DB for <dhcwg@ietf.org>; Tue, 12 Nov 2013 01:03:43 -0800 (PST)
Received: from he113472.emea1.cds.t-internal.com ([10.134.93.130]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 12 Nov 2013 10:03:37 +0100
Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([169.254.3.39]) by HE113472.emea1.cds.t-internal.com ([::1]) with mapi; Tue, 12 Nov 2013 10:03:36 +0100
From: ian.farrer@telekom.de
To: draft-ietf-dhc-dhcpv4-over-ipv6@tools.ietf.org
Date: Tue, 12 Nov 2013 10:03:35 +0100
Thread-Topic: TRA function draft-ietf-dhc-dhcpv4-over-ipv6
Thread-Index: Ac7fhhHdwRt2OPvZQGSfMSgxlxpmuQ==
Message-ID: <CEA7AD77.903F6%ian.farrer@telekom.de>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.8.130913
acceptlanguage: en-US, de-DE
Content-Type: multipart/alternative; boundary="_000_CEA7AD77903F6ianfarrertelekomde_"
MIME-Version: 1.0
Cc: dhcwg@ietf.org
Subject: [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 09:03:51 -0000
Hi, 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; 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. 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. 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? Cheers, Ian