Re: [Softwires] 6rd RADIUS attribute - grouped attributes

Stefan Winter <> Thu, 22 December 2011 07:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 78BB011E80CB for <>; Wed, 21 Dec 2011 23:37:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CSN37dBISyhV for <>; Wed, 21 Dec 2011 23:37:22 -0800 (PST)
Received: from ( [IPv6:2001:a18:1::62]) by (Postfix) with ESMTP id E6E1A11E80CA for <>; Wed, 21 Dec 2011 23:37:21 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 9215D10A08; Thu, 22 Dec 2011 08:37:20 +0100 (CET)
Received: from [IPv6:2001:a18:1:8:3427:d2f8:b1a4:57de] (unknown [IPv6:2001:a18:1:8:3427:d2f8:b1a4:57de]) by (Postfix) with ESMTPS id 7F13C10A01; Thu, 22 Dec 2011 08:37:20 +0100 (CET)
Message-ID: <>
Date: Thu, 22 Dec 2011 08:39:05 +0100
From: Stefan Winter <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: Peter Deacon <>
References: <> <> <> <> <> <alpine.WNT.2.00.1112200950300.2472@SMURF> <> <alpine.WNT.2.00.1112201948210.2472@SMURF> <> <alpine.WNT.2.00.1112210204010.2472@SMURF> <> <alpine.WNT.2.00.1112210807180.2472@SMURF>
In-Reply-To: <alpine.WNT.2.00.1112210807180.2472@SMURF>
X-Enigmail-Version: 1.3.4
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enig8738D1EEF24D7ECB9E560788"
X-Virus-Scanned: ClamAV
Cc:, Alan DeKok <>, GuoDayong <>
Subject: Re: [Softwires] 6rd RADIUS attribute - grouped attributes
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: softwires wg discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 22 Dec 2011 07:37:22 -0000


>> 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

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".


Stefan Winter

Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473