Subject: [radext] Review of the softwires draft

From: Alan DeKok <[email-masked]>
Date: Mon, 06 Aug 2012 15:42:05 +0200

draft-ietf-softwire-6rd-radius-attrib:

Section 4.1 says:

   Given that RADIUS currently has no
   recommended way of grouping multiple attributes, the below design
   appears to be a reasonable compromise.

  I think that the design is a reasonable compromise.  The RADIUS
extensions document allows TLVs as a RADIUS data type:

http://datatracker.ietf.org/doc/draft-ietf-radext-radius-extensions/

  I'd add a note saying that the subtypes carried by
IPv6-6rd-Configuration can be sent in any order.  There is no need for
them to be sent in-order (1, 2, 3).  But the normal order is RECOMMENDED.

  The IPv4 Mask should be a 32-bit integer.  While its value is limited
to 0..32, RFC 6158 discusses "integer" attributes.  Anything other than
32-bit unsigned integers is a bad idea.

...
6rdBRIPv4Address

         One or more IPv4 addresses of the 6rd Border Relay(s) for a
         given 6rd domain. The maximum RADIUS Attribute length of 255
         octets results in a limit of 58 IPv4 addresses
...

  I disagree strongly with this design.  Instead, the 6rdBRIPv4Address
attribute should be repeated as many times as necessary.  Packing
multiple IPv4 addresses into one attribute is forbidden by RFC 6158.

4.2. Table of attributes

  It may be worth noting that this attribute is allowed (or not) in
CoA-Request.  It should probably be forbidden in Disconnect-Request.

  Alan DeKok.

---

From: Leaf yeh <[email-masked]>
Date: Tue, 7 Aug 2012 09:17:18 +0000

Alan - I think that the design is a reasonable compromise.   The RADIUS extensions document allows TLVs as a RADIUS data type: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-extensions/   I'd add a note saying that the subtypes carried by IPv6-6rd-Configuration can be sent in any order.   There is no need for them to be sent in-order (1, 2, 3).   But the normal order is RECOMMENDED.

I suggested that before, to let the data type of nested-TLV be used for the traditional type space if draft-ietf-radext-radius-extensions is getting publication. Then the multi-field complex-data in IPv6-6rd-Configuration of draft-ietf-softwire-6rd-radius-attrib, and even in the originally-defined attribute, Route-IPv6-Information of draft-ietf-radext-ipv6-access, can be presented in nested-TLV.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan DeKok
Sent: Monday, August 06, 2012 9:42 PM
To: [email-masked]; [email-masked]
Subject: [radext] Review of the softwires draft

Section 4.1 says:

...
6rdBRIPv4Address

4.2. Table of attributes

  Alan DeKok.
_______________________________________________
radext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/radext

---

From: Alan DeKok <[email-masked]>
Date: Tue, 07 Aug 2012 12:18:07 +0200

Leaf yeh wrote:
> I suggested that before, to let the data type of nested-TLV be used for the traditional type space if draft-ietf-radext-radius-extensions is getting publication. 

  The extensions document allows TLVs to be in the standard type space.
 It doesn't say this explicitly, though.  It just doesn't forbid it.

  Alan DeKok.

---

From: Leaf yeh <[email-masked]>
Date: Tue, 7 Aug 2012 10:44:48 +0000

Alan -  The extensions document allows TLVs to be in the standard type space.  It doesn't say this explicitly, though.  It just doesn't forbid it.

draft-ietf-radext-radius-extensions-06.txt : Section 6.4. Guidelines For the New Types : 

<quote>The data type "tlv" SHOULD NOT be used for standard RADIUS
attributes. While its use is NOT RECOMMENDED by [RFC6158], this
specification updates [RFC6158] to permit the "tlv" data type in
attributes using the Extended-Type format.</quote>

That sounds not recommended to do it.

Best Regards,
Leaf

-----Original Message-----
From: Alan DeKok [mailto:[email-masked]] 
Sent: Tuesday, August 07, 2012 6:18 PM
To: Leaf yeh
Cc: [email-masked]
Subject: Re: [radext] Review of the softwires draft

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 07 Aug 2012 12:52:24 +0200

> draft-ietf-radext-radius-extensions-06.txt : Section 6.4. Guidelines For the New Types : 

  As I said, it's not forbidden.  Therefore it's allowed.

  Alan DeKok.