[Softwires] About draft-guo-softwire-6rd-ipv6-config-00
xuxiaohu 41208 <xuxh@huawei.com> Fri, 30 July 2010 09:49 UTC
Return-Path: <xuxh@huawei.com>
X-Original-To: softwires@core3.amsl.com
Delivered-To: softwires@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3DAE03A6859 for <softwires@core3.amsl.com>; Fri, 30 Jul 2010 02:49:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.045
X-Spam-Level: *
X-Spam-Status: No, score=1.045 tagged_above=-999 required=5 tests=[AWL=1.540, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8OCbzeiHThC for <softwires@core3.amsl.com>; Fri, 30 Jul 2010 02:49:10 -0700 (PDT)
Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 337FF3A6ACE for <softwires@ietf.org>; Fri, 30 Jul 2010 02:49:05 -0700 (PDT)
Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L6D00BQ975RN8@szxga02-in.huawei.com> for softwires@ietf.org; Fri, 30 Jul 2010 17:46:40 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L6D000GE75RFB@szxga02-in.huawei.com> for softwires@ietf.org; Fri, 30 Jul 2010 17:46:39 +0800 (CST)
Received: from [172.24.1.3] (Forwarded-For: [130.129.20.89]) by szxmc04-in.huawei.com (mshttpd); Fri, 30 Jul 2010 17:46:39 +0800
Date: Fri, 30 Jul 2010 17:46:39 +0800
From: xuxiaohu 41208 <xuxh@huawei.com>
To: softwires@ietf.org
Message-id: <fb96b0764d6e.4d6efb96b076@huawei.com>
MIME-version: 1.0
X-Mailer: iPlanet Messenger Express 5.2 HotFix 2.14 (built Aug 8 2006)
Content-type: text/plain; charset="us-ascii"
Content-language: zh-CN
Content-transfer-encoding: 7bit
Content-disposition: inline
X-Accept-Language: zh-CN
Priority: normal
Subject: [Softwires] About draft-guo-softwire-6rd-ipv6-config-00
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Jul 2010 09:49:12 -0000
Hi all, First, as stated in the DHCPv6 specification [RFC3315], "...The client MUST use a link-local address assigned to the interface for which it is requesting configuration information as the source address in the header of the IP datagram." Since the link-local address can not travel through the 6rd domain, the CPE SHOULD act as a DHCPv6 relay agent. I think nobody will argue against this conclusion. Second, as I mentioned during the presentation, relaying DHCP request messages to All_DHCP_Servers multicast address by CPEs is not optimal in 6rd scenario. Note that here what I said is "not optimal", rather than "not possible". The CPE as a relay agent, could be upgraded to relay information-request DHCPv6 messages (multicast) towards the 6rd BRs. However, with this approach, the DHCPv6 servers would have to be located in the IPv6 Interne t, rather than in a 6rd site which is owned by the 6rd SP. In addition, this usage will result in more traffic burden on the 6rd BRs. Hence, we propose that the CPE as a DHCP relay agent, SHOULD know at least one DHCPv6 server address. Xiaohu