Re: [Softwires] 6rd RADIUS attribute - grouped attributes
Peter Deacon <peterd@iea-software.com> Thu, 22 December 2011 12:07 UTC
Return-Path: <peterd@iea-software.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E03921F8B59 for <softwires@ietfa.amsl.com>; Thu, 22 Dec 2011 04:07:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 yEzomPgLUm+V for <softwires@ietfa.amsl.com>; Thu, 22 Dec 2011 04:07:50 -0800 (PST)
Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8B321F8B4E for <softwires@ietf.org>; Thu, 22 Dec 2011 04:07:50 -0800 (PST)
Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id <B0005782065@aspen.internal.iea-software.com>; Thu, 22 Dec 2011 04:07:49 -0800
Date: Thu, 22 Dec 2011 04:07:45 -0800
From: Peter Deacon <peterd@iea-software.com>
To: Stefan Winter <stefan.winter@restena.lu>
In-Reply-To: <4EF2DE99.7050207@restena.lu>
Message-ID: <alpine.WNT.2.00.1112220026080.2472@SMURF>
References: <4EC1BD65.4040205@restena.lu> <4EEB1014.1030307@restena.lu> <5D36713D8A4E7348A7E10DF7437A4B9218583E44@SZXEML506-MBX.china.huawei.com> <4EF047A3.5090906@restena.lu> <4EF08F63.1010600@deployingradius.com> <alpine.WNT.2.00.1112200950300.2472@SMURF> <5D36713D8A4E7348A7E10DF7437A4B9218584374@SZXEML506-MBX.china.huawei.com> <alpine.WNT.2.00.1112201948210.2472@SMURF> <4EF1A65F.9080609@restena.lu> <alpine.WNT.2.00.1112210204010.2472@SMURF> <4EF1E94D.2080006@restena.lu> <alpine.WNT.2.00.1112210807180.2472@SMURF> <4EF2DE99.7050207@restena.lu>
User-Agent: Alpine 2.00 (WNT 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
X-Mailman-Approved-At: Tue, 03 Jan 2012 08:09:36 -0800
Cc: softwires@ietf.org, Alan DeKok <aland@deployingradius.com>, GuoDayong <guodayong@huawei.com>
Subject: Re: [Softwires] 6rd RADIUS attribute - grouped attributes
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 22 Dec 2011 12:07:51 -0000
On Thu, 22 Dec 2011, Stefan Winter wrote: > Hi, >>> Any particular reason why the 6rdPrefixLen and 6rdPrefix are glued into >>> one blob in -04? >> If you ignore the 6rd references it is describing prefix data type >> defined a decade back in RFC3162 2.3 (Framed-IPv6-Prefix). Logically it >> counts as one field. > Framed-IPv6-Prefix and your data type are different. Frames-IPv6-Prefix > is of variable length, and requires to insert only those parts of the > IPv6 address which are relevant for the prefix length. You can pad with > more zeroes if you feel like it, but don't have to. (That in itself is a > rather inconvenient construct, and I like yours more than that one > actually.) Sure, if you opt to always pad with zeroes to the full 128 > bit, even if not necessary, you get the same fixed length as your > datatype requires. > Still, you have introduced a new data type > "almost-but-not-quite-Framed-IPv6-Address". There are a few areas implementors should take care to read the draft carefully. I don't have a better idea. > If you consider it a good idea, then fine - I'm sure you have much more > experience in terms of actual implementations than I do. From a design > point of view, I'd consider a pair of (int,IPv6-Address) cleaner than an > implicit struct. The "belong together" can be expressed in the RFC as > "both of the sub-TLVs have to appear exactly once". A IPv6 prefix describes one thing not a collection of related things belonging together. You can't pull apart a prefix into pieces that mean anything by themselves. By convention a prefix is always expressed as a single field wherever it is entered or displayed (fe80::/16) A prefix does not contain an IP Address. TLVs have no global type space. Elements of generally applicable composite types must be redefined separately within each instance they are used. regards, Peter
- [Softwires] 6rd RADIUS attribute - grouped attrib… Stefan Winter
- Re: [Softwires] 6rd RADIUS attribute - grouped at… Sheng Jiang
- Re: [Softwires] 6rd RADIUS attribute - grouped at… Stefan Winter
- Re: [Softwires] 6rd RADIUS attribute - grouped at… Stefan Winter
- Re: [Softwires] 6rd RADIUS attribute - grouped at… Stefan Winter
- Re: [Softwires] 6rd RADIUS attribute - grouped at… Sheng Jiang
- Re: [Softwires] 6rd RADIUS attribute - grouped at… Stefan Winter
- Re: [Softwires] 6rd RADIUS attribute - grouped at… Peter Deacon
- Re: [Softwires] 6rd RADIUS attribute - grouped at… Peter Deacon
- Re: [Softwires] 6rd RADIUS attribute - grouped at… Peter Deacon