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

Peter Deacon <> Thu, 22 December 2011 12:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E03921F8B59 for <>; Thu, 22 Dec 2011 04:07:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yEzomPgLUm+V for <>; Thu, 22 Dec 2011 04:07:50 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6F8B321F8B4E for <>; Thu, 22 Dec 2011 04:07:50 -0800 (PST)
Received: from SMURF (unverified []) by (Rockliffe SMTPRA 7.0.6) with ESMTP id <>; Thu, 22 Dec 2011 04:07:49 -0800
Date: Thu, 22 Dec 2011 04:07:45 -0800
From: Peter Deacon <>
To: Stefan Winter <>
In-Reply-To: <>
Message-ID: <alpine.WNT.2.00.1112220026080.2472@SMURF>
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> <>
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:, 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 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