[dhcwg] DHCP-based Solutions in the "Analysis of IPv6 Tunnel End-point Discovery Mechamisms"
Soohong Daniel Park <soohong.park@samsung.com> Tue, 15 June 2004 05:11 UTC
Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08569; Tue, 15 Jun 2004 01:11:56 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba60D-0005Gz-7M; Tue, 15 Jun 2004 00:56:53 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ba5oP-0001cz-Qw for dhcwg@megatron.ietf.org; Tue, 15 Jun 2004 00:44:41 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07276 for <dhcwg@ietf.org>; Tue, 15 Jun 2004 00:44:38 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1Ba5oN-0001uB-Qa for dhcwg@ietf.org; Tue, 15 Jun 2004 00:44:39 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ba5nW-0001bm-00 for dhcwg@ietf.org; Tue, 15 Jun 2004 00:43:47 -0400
Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1Ba5mh-00010g-00 for dhcwg@ietf.org; Tue, 15 Jun 2004 00:42:55 -0400
Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HZC003012EOEZ@mailout1.samsung.com> for dhcwg@ietf.org; Tue, 15 Jun 2004 13:42:24 +0900 (KST)
Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HZC00CWA2ENW3@mailout1.samsung.com> for dhcwg@ietf.org; Tue, 15 Jun 2004 13:42:23 +0900 (KST)
Received: from LocalHost ([168.219.202.103]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HZC00C4C2EN7R@mmp2.samsung.com> for dhcwg@ietf.org; Tue, 15 Jun 2004 13:42:23 +0900 (KST)
Date: Tue, 15 Jun 2004 13:43:07 +0900
From: Soohong Daniel Park <soohong.park@samsung.com>
To: Dhcwg <dhcwg@ietf.org>
Message-id: <EDELKJDGPGNIPOAOHMNPGELCFLAA.soohong.park@samsung.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Content-type: text/plain; charset="ks_c_5601-1987"
Content-transfer-encoding: 7bit
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
Subject: [dhcwg] DHCP-based Solutions in the "Analysis of IPv6 Tunnel End-point Discovery Mechamisms"
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: 7bit
Hi all, I am not sure how may guys read below draft which was proposed in the v6ops WG to analyze IPv6 TEP Discovery mechanism. This draft cited one draft and wrote several drawbacks. I already proposed this cited draft (03 version currently). http://www.ietf.org/internet-drafts/draft-daniel-dhc-ipv6in4-opt-03.txt I'd like to reflect DHC's comments/feedbacks on the revision as 04. Please let me know your view on this. =================== Subject:Analysis of IPv6 Tunnel End-point Discovery Mechamisms http://www.ietf.org/internet-drafts/draft-palet-v6ops-tun-auto-disc-01.txt 3.4 DHCP-based Solutions In most situations, the users receive the IPv4 information by means of an IPv4 DHCP server. Consequently, one of the parameters to be provided by the DHCP server could be the tunnel end-point address, e.g., as described in [12]. This approach has several drawbacks: o It requires upgrading the DHCP client/server implementations to support this feature. o It is restricted to the local ISP. That is, it will not be effective if the local ISP doesn't provide this parameter. This could be also be an advantage considering that the this would only support the tunnels provided by the local ISP, which would probably be of good quality. o It will not work if DHCP client is not used. DHCP is omitted especially in many dial-up scenarios, where only PPP is used; DHCP is not used in some (advanced) xDSL setups which use static routing. Also, some managed networks do not use DHCP. Still, in many cases, DHCP is used between a customer and the ISP. o If a router is providing local DHCP information (e.g., an ADSL router), the tunnel end-point information would have to be automatically proxied to the "local DHCP", or manually configured on the router to propagate to the hosts in the case that the router is not activating the tunnel itself. o It requires manual configuration/update of the ISP's DHCP servers when there are changes to the tunnel end-points, similar to updating DNS, NTP, etc. servers. - Daniel (Soohong Daniel Park) - Mobile Platform Lab. Samsung Electronics. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] DHCP-based Solutions in the "Analysis of … Soohong Daniel Park