Subject: Re: 6rd attribute compromise?

From: Jiangsheng <[email-masked]>
Date: Tue, 12 Apr 2011 03:25:30 +0000

Hi, Alan and Peter,

Sorry for the late reply.

The format design of this 6rd attribute was to be the same with 6rd DHCPv4 Option, please see section 7.1.1 of RFC 5969.

However, if this is not compatible with RADIUS, we would like to accept any suggestion from RADEXT WG. So, the first question is whether our current 6rd attr design is NOT acceptable by RADIUS.

If the answer is NO, Peter's suggestion looks good for us except why a Reserved byte.

The second choice could be we limit 6rdBRIPv4Address to be only 1 instance. Then we have a fixed length attribute. But this need to enable grouping multiple attributes module, which seems RADIUS protocol does not support currently.

We do not understand Alan's third approach. Could Alan explain a little bit more, "An alternative approach would be to publish a "new data types" RFC,
containing just TLV and 64-bit integer data types." And how this relevant to our 6rd attribute?

Best regards,

Sheng & Dayong

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Alan DeKok <[email-masked]>
Date: Tue, 12 Apr 2011 07:43:36 +0200

> The format design of this 6rd attribute was to be the same with 6rd DHCPv4 Option, please see section 7.1.1 of RFC 5969.

  Please see RFC 6158, Section 3.2.4.  If you are transporting a
pre-defined data type in RADIUS, then don't re-define it in RADIUS.
Instead, just say "this attribute has the format as described in RFC
5969 Section 7.1.1"

> However, if this is not compatible with RADIUS, we would like to accept any suggestion from RADEXT WG. So, the first question is whether our current 6rd attr design is NOT acceptable by RADIUS.

  It does not follow the guidelines set down in RFC 6158.

> If the answer is NO, Peter's suggestion looks good for us except why a Reserved byte.

  I think using TLVs for this attribute would be a good choice, but not
necessarily better than referring to a pre-existing data format.

> containing just TLV and 64-bit integer data types." And how this relevant to our 6rd attribute?

  You could use the new data types in the document, rather than
inventing a data type which is incompatible with existing RADIUS practice.

  Alan DeKok.

---

From: Jiangsheng <[email-masked]>
Date: Tue, 12 Apr 2011 06:47:17 +0000

Hi, Alan,

Thanks for your reply. It is much clearer now.

After carefully read RFC 6158, we don't think the attribute can be referred to a pre-existing data format because this attribute should be parsed by the Radius server. In 6rd scenarios, it is the Radius server who manages the user configuration information. Therefore, this 6rd attribute can NOT "be treated as opaque data by the RADIUS server."

So, it leaves TLVs the best choice.

As the below, I slightly modified Peter's proposal by removing the Reserved byte.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Type     |    Length     | SubType (1)   | SubLen (3)    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4MaskLen   | SubType (2)   | SubLen (19)   |  6rdPrefixLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                 6rdPrefix                                     |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType (3)   |  SubLen (6)   |       6rdBRIPv4Address        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        6rdBRIPv4Address       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Any further comments? Peter, do you have any particular reasons to add the Reserved byte back?

Sheng

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Alan DeKok
> Sent: Tuesday, April 12, 2011 1:44 PM
> To: Jiangsheng
> Cc: Peter Deacon; radiusext
> Subject: Re: 6rd attribute compromise?
> 
> Jiangsheng wrote:
> > The format design of this 6rd attribute was to be the same with 6rd
> DHCPv4 Option, please see section 7.1.1 of RFC 5969.
> 
> > However, if this is not compatible with RADIUS, we would like to
> accept any suggestion from RADEXT WG. So, the first question is whether
> our current 6rd attr design is NOT acceptable by RADIUS.
> 
> > We do not understand Alan's third approach. Could Alan explain a
> little bit more, "An alternative approach would be to publish a "new
> data types" RFC,

---

From: Peter Deacon <[email-masked]>
Date: Mon, 11 Apr 2011 23:50:33 -0700 (Pacific Daylight Time)

> However, if this is not compatible with RADIUS, we would like to accept 
> any suggestion from RADEXT WG. So, the first question is whether our 
> current 6rd attr design is NOT acceptable by RADIUS.

> If the answer is NO, Peter's suggestion looks good for us except why a 

Hi Jiangsheng, just included reserved /w ascii example to be a closer 
match to the existing attribute format for prefix (RFC 3162 2.3)

regards,
Peter

---

From: Alan DeKok <[email-masked]>
Date: Tue, 12 Apr 2011 09:00:17 +0200

> match to the existing attribute format for prefix (RFC 3162 2.3)

  I agree with Peter here.  Leaving the reserved byte in place allows
many RADIUS servers to use these new attributes with only a dictionary
update.

  Deleting the reserved byte means that the IPv6 prefix for 6rd has a
different format than for all other IPv6 prefix attributes.

  Alan DeKok.

---

From: Jiangsheng <[email-masked]>
Date: Tue, 12 Apr 2011 07:19:26 +0000

OK, I will put the reserved byte back.

I will wait another two or three days in case there are other comments, then update a new version with the new TLVs. After that, softwire chair will probably launch the WGLC on both softwire and radext wg mail list. :)

Many thanks,

Sheng

> Sent: Tuesday, April 12, 2011 3:00 PM
> To: Peter Deacon
> Cc: Jiangsheng; radiusext