IETF Logo Mail Archive

[Softwires] Comments on draft-hu-softwire-multicast-radius-ext

"Hao Wang"<wangh13@mails.tsinghua.edu.cn> Wed, 24 September 2014 04:49 UTC

Return-Path: <wangh13@mails.tsinghua.edu.cn>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E8B1A8A7D for <softwires@ietfa.amsl.com>; Tue, 23 Sep 2014 21:49:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.014
X-Spam-Level:
X-Spam-Status: No, score=0.014 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FROM_MISSP_XPRIO=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPAZJ1Tf018z for <softwires@ietfa.amsl.com>; Tue, 23 Sep 2014 21:49:17 -0700 (PDT)
Received: from tsinghua.edu.cn (smtp01.tsinghua.edu.cn [166.111.204.30]) by ietfa.amsl.com (Postfix) with ESMTP id 26F7C1A8A7B for <softwires@ietf.org>; Tue, 23 Sep 2014 21:49:16 -0700 (PDT)
Received: from wangh13pc (unknown [166.111.68.231]) by app4 (Coremail) with SMTP id DcxvpgAHCtlHTSJURxnmAA--.3513S2; Wed, 24 Sep 2014 12:49:11 +0800 (CST)
From: Hao Wang <wangh13@mails.tsinghua.edu.cn>
To: softwires <softwires@ietf.org>
Date: Wed, 24 Sep 2014 12:46:22 +0800
Message-Id: <DM__140924124403_33955036124@mails.tsinghua.edu.cn>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_14092412462194281306451_002"
X-Priority: 3
X-Mailer: DreamMail 4.6.9.2
X-CM-TRANSID: DcxvpgAHCtlHTSJURxnmAA--.3513S2
X-Coremail-Antispam: 1UD129KBjvdXoWruFy3GF4ftrWxWF1kXF4xZwb_yoWkXrg_ur 42gF97JF4qvF4akanxtanay393Cw15Ar47Jw1rt3Z3t345Z39ru392va97Xay3Xw42qwn8 CasrWFsxCw13WjkaLaAFLSUrUUUUbb8apTn2vfkv8UJUUUU8Yxn0WfASr-VFAUDa7-sFnT 9fnUUIcSsGvfJTRUUUbzxYjsxI4VW5JwAYFVCjjxCrM7AC8VAFwI0_Jr0_Gr1l1xkIjI8I 6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFVAK0II2c7xJM2 8EF7xvwVC0I7IYx2IY67AKxVW7JVWDJwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVW8Jr0_ Cr1UM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s 0DM2vYz4IE04k24VAvwVAKI4IrM2AIxVAIcxkEcVAq07x20xvEncxIr21lYx0E2Ix0cI8I cVAFwI0_Jrv_JF1lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjc xG0xvY0x0EwIxGrwACY4xI67k04243AVAKzVAKj4xxM4xvF2IEb7IF0Fy26I8I3I1lc2xS Y4AK67AK6r45MxAIw28IcxkI7VAKI48JMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7 xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUXVWUAwCIc40Y0x0EwIxGrwCI42IY6xII jxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw2 0EY4v20xvaj40_Zr0_Wr1UMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7Cj xVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7xUUeiHUUUUUU==
X-CM-SenderInfo: pzdqwxyrt6zthlovh3pvlqwxlxdovvfxof0/
Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/25eRKzNZw85EFs48ovXCVzTqXdk
Cc: draft-hu-softwire-multicast-radius-ext <draft-hu-softwire-multicast-radius-ext@tools.ietf.org>
Subject: [Softwires] Comments on draft-hu-softwire-multicast-radius-ext
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 24 Sep 2014 04:49:20 -0000

Dear *,

I've read this document and think it provides a good method by using AAA-server and radius to store and provision v6-prefix in IPv6 multicast scenario. Some comments on this draft:

Section 1:
  * The name of new DHCPv6 option has turned into 'OPTION_V6_PREFIX64' in the latest [I-D.ietf-softwire-multicast-prefix-option].

Section 3:
  * What does it mean by 'based on the sending client'?
  * If mB4 using DHCPv6 Solicit just for lease query, instead of IP address, the access request will always be send to AAA-server? AAA-server receives any access request from NAS will always be send Multicast-Prefixes-64 attribute back to NAS?
  * In Lightweight 4over6 scenario, lwB4 ([I-D.ietf-softwire-lw4over6]) as the client of DHCPv6 and DCHPv4o6 to request it's IPv6 & IPv4 address respectively. How the AAA-server to mantain the binding relationships with these two DHCP servers which as the part of NAS.

Section 4.1:
  * The priority of Multicast-Prefixes-64 in Access-Accept message is higher than pre-provisioned?

Best Regards,
Hao Wang


Hao Wang，wangh13@mails.tsinghua.edu.cn
2014/9/24

v2.34.0 | Report a Bug | By Email | System Status