Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-07.txt

Leaf yeh <leaf.y.yeh@huawei.com> Fri, 11 May 2012 10:48 UTC

Return-Path: <leaf.y.yeh@huawei.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D7621F85E5 for <radext@ietfa.amsl.com>; Fri, 11 May 2012 03:48:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.567
X-Spam-Level:
X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599]
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 ykc0260eG8yd for <radext@ietfa.amsl.com>; Fri, 11 May 2012 03:48:10 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id BAAE221F8570 for <radext@ietf.org>; Fri, 11 May 2012 03:48:10 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AFV12054; Fri, 11 May 2012 06:48:10 -0400 (EDT)
Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 11 May 2012 03:44:27 -0700
Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 11 May 2012 03:44:25 -0700
Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.168]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Fri, 11 May 2012 18:44:23 +0800
From: Leaf yeh <leaf.y.yeh@huawei.com>
To: jouni korhonen <jouni.nospam@gmail.com>, "radext@ietf.org" <radext@ietf.org>
Thread-Topic: I-D Action: draft-ietf-radext-ipv6-access-07.txt
Thread-Index: AQHNLFneQkQleKjX90CL1w6gppUCXZbETbjA
Date: Fri, 11 May 2012 10:44:22 +0000
Message-ID: <E1CE3E6E6D4E1C438B0ADC9FFFA345EA262E291F@SZXEML510-MBS.china.huawei.com>
References: <20120507120127.8643.10103.idtracker@ietfa.amsl.com> <ED4F3B64-7CD2-49FA-A012-8BA4C87CDFF0@gmail.com>
In-Reply-To: <ED4F3B64-7CD2-49FA-A012-8BA4C87CDFF0@gmail.com>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.70.39.132]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Wojciech Dec <wdec@cisco.com>
Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-07.txt
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 May 2012 10:48:11 -0000

I'd really like to see the advancing of this document, because I have a draft (http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-radius-opt/), which has turned to be draft-ietf, has referred to the attributes defined in this draft.

Comments for discussion on this draft:

1. Abstract

<quote> The attributes, which are
used for authorization and accounting, enable assignment of a host
IPv6 address and IPv6 DNS server address via DHCPv6; ... </quote>

Per the section 1 & 2.2, DNS-Server-IPv6-Address is not only used by DHCPv6, but also by RA. Right?


2. Introduction
<quote> Assignment of an IPv6 DNS server address, via DHCPv6 or [RFC5006]. </quote>
2.2  Recursive DNS Servers
<quote>The IPv6 address of a DNS server can also
be conveyed to the host using ICMPv6 with Router Advertisements, via
the experimental [RFC5006] option. </quote>

RFC5006 has obsoleted by RFC6106.


3. Deployment Scenarios

<quote>...Figure 1. It
is composed of a IP Routing Residential Gateway (RG) or host, a Layer
2 Access-Node (e.g. a DSLAM), one or more IP Network Access Servers
(NASes), and an AAA server. The RG or host can be expected to be
multi homed to one or more NASes. </quote>

I can't find multiple NASes in the Fig. 1.

<quote>...Figure 1</quote>

Can the denotation of AN be replaced by (Layer-2 broadband) Access Network and we don't mention (DSL) and (Ethernet) in Fig.1?


2.1 IPv6 Address Assignment

<quote>DHCPv6 [RFC3315] provides a mechanism to assign one or more or non-temporary
IPv6 addresses to hosts. </quote>

Typo - 1 more 'or' in the above sentence.


2.4  Delegated IPv6 Prefix Pool

<quote>Since DHCPv6 Prefix Delegation can conceivably be used on the same
network as SLAAC, it is possible for the Delegated-IPv6-Prefix-Pool
and Framed-IPv6-Pool attributes to be included within the same
packet. To avoid ambiguity in this scenario, use of the Delegated-
IPv6-Prefix-Pool attribute should be restricted to authorization and
accounting of prefix pools used in DHCPv6 Prefix Delegation and the
Framed-IPv6-Pool attribute should be used for authorization and
accounting of prefix pools used in SLAAC. </quote>

I am still not sure why we can't use 2x Framed-Pool (88 defined in RFC2869) attributes for this case? One Framed-Pool (88) is for DHCPv6, the other Framed-Pool (88) is for SLAAC.

I quote the description of 'Framed-Pool' in RFC2869 here, 'This Attribute contains the name of an assigned address pool that
SHOULD be used to assign an address for the user. If a NAS does
not support multiple address pools, the NAS should ignore this
Attribute. Address pools are usually used for IP addresses, but
can be used for other protocols if the NAS supports pools for
those protocols.'


2.5  Stateful IPv6 address Pool

I still have not got the reason why we can't use 'Frame-Pool' instead of this new attribute.


Best Regards,
Leaf


-----Original Message-----
From: jouni korhonen [mailto:jouni.nospam@gmail.com] 
Sent: Monday, May 07, 2012 10:01 PM
To: radext@ietf.org
Cc: Leaf yeh; Wojciech Dec
Subject: Re: I-D Action: draft-ietf-radext-ipv6-access-07.txt

Folks,

The I-D has been revised to reflect the comments regarding the 
attribute format and the example broadband network scenario.
Everybody happy with the changes in Sections 2, 2.3 and 3.3 ?

- Jouni & Mauricio


On May 7, 2012, at 3:01 PM, internet-drafts@ietf.org wrote:

> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF.
> 
> 	Title           : RADIUS attributes for IPv6 Access Networks
> 	Author(s)       : Benoit Lourdelet
>                          Wojciech Dec
>                          Behcet Sarikaya
>                          Glen Zorn
>                          David Miles
> 	Filename        : draft-ietf-radext-ipv6-access-07.txt
> 	Pages           : 14
> 	Date            : 2012-05-07
> 
>   This document specifies additional IPv6 RADIUS attributes useful in
>   residential broadband network deployments.  The attributes, which are
>   used for authorization and accounting, enable assignment of a host
>   IPv6 address and IPv6 DNS server address via DHCPv6; assignment of an
>   IPv6 route announced via router advertisement; assignment of a named
>   IPv6 delegated prefix pool; and assignment of a named IPv6 pool for
>   host DHCPv6 addressing.
>