Re: [Softwires] [dhcwg] Is tunnelling DHCP multicast messages in 6rd unicast tunnel to BR acceptable for DHCP redundancy?//re: About draft-guo-softwire-6rd-ipv6-config-00

Xu Xiaohu <xuxh@huawei.com> Thu, 19 August 2010 05:25 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 AEB303A6834; Wed, 18 Aug 2010 22:25:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.322
X-Spam-Level: **
X-Spam-Status: No, score=2.322 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_CHARSET_FARAWAY=2.45, 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 FARB4NqV7YE5; Wed, 18 Aug 2010 22:25:12 -0700 (PDT)
Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 0AD0B3A682A; Wed, 18 Aug 2010 22:25:12 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L7D00IXHWEO0U@szxga05-in.huawei.com>; Thu, 19 Aug 2010 13:25:36 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L7D00DT1WENRG@szxga05-in.huawei.com>; Thu, 19 Aug 2010 13:25:36 +0800 (CST)
Received: from x41208c ([10.110.98.38]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L7D006RKWENZX@szxml06-in.huawei.com>; Thu, 19 Aug 2010 13:25:35 +0800 (CST)
Date: Thu, 19 Aug 2010 13:27:27 +0800
From: Xu Xiaohu <xuxh@huawei.com>
In-reply-to: <0101460A-E139-46D3-A0EA-70EB9A8CFABF@nominum.com>
To: 'Ted Lemon' <Ted.Lemon@nominum.com>
Message-id: <002c01cb3f5f$365ae280$26626e0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="gb2312"
Content-transfer-encoding: quoted-printable
Thread-index: Acs71E9QaMyAuzHuTIWjKFbfMRrWugDezgAw
Cc: softwires@ietf.org, dhcwg@ietf.org
Subject: Re: [Softwires] [dhcwg] Is tunnelling DHCP multicast messages in 6rd unicast tunnel to BR acceptable for DHCP redundancy?//re: 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: Thu, 19 Aug 2010 05:25:13 -0000

> -----邮件原件-----
> 发件人: Ted Lemon [mailto:Ted.Lemon@nominum.com]
> 发送时间: 2010年8月15日 1:15
> 收件人: Xu Xiaohu
> 抄送: 'Ole Troan'; softwires@ietf.org; dhcwg@ietf.org
> 主题: Re: [dhcwg] Is tunnelling DHCP multicast messages in 6rd unicast
tunnel
> to BR acceptable for DHCP redundancy?//re: [Softwires] About
> draft-guo-softwire-6rd-ipv6-config-00
> 
> On Aug 8, 2010, at 11:59 PM, Xu Xiaohu wrote:
> > In addition, in case that the DHCP
> > server/relay on a given BR is unavailable due to some reason (e.g., no
> > available address in the pool) but the other functions of it (e.g., the
> > anycast route for it) are still available, once the DHCP message is
tunneled
> > to that BR, the DHCP service is unavailable any more. That's to say,
it's
> > hard to achieve the high availability for DHCP servers/relay agents
since
> > the DHCP information-request can not be relayed to other DHCP
> > servers/relays.
> 
> I don't see the problem here.   If you want redundancy, you should
configure
> each BR to relay to more than one DHCP server.   This would be the default
anyway,
> according to RFC3315 section 20, which requires the relay to multicast if
not
> otherwise configured.

Yes. However, the question is:  in most cases, should the unicast or the
multicast be preferred by the relay agents to relay the DHCP request message
if both of them are available? 

With multicast, many DHCP authentication mechanisms will not be available
any more, e.g., IPsec mechanism for securing the messages exchanged between
servers and relay agents, and CGA usage for DHCP server authentication. By
the way, is the 6rd domain deemed as a secure network for DHCP message
exchange?

I admit that the DHCP relay agent on the CPE could relay the
information-request message to ALL_SERVERS_OR_RELAY-AGENT_ADDRESS in a 6rd
tunnel towards a 6rd BR, However, is it actually an optimal choice? 

Best wishes,
Xiaohu

> > 2) The CPE as a DHCP relay agent sends the DHCP-relay-forward message to
one
> > of the learnt DHCP server (unicast) addresses. Since 6rd can support
unicast
> > flexible, the DHCP server can be located either on/behind any BR or
behind
> a
> > 6rd CPE which is owned by the 6rd SP.
> 
> This is completely contrary to the recommendations in RFC3315, which
require
> the client to multicast, and require any relays to multicast by default.
> Trying to relay DHCPv6 traffic over an IPv4 transport seems needlessly
> complicated.   You have the tunnel--why not use it?