Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt-sent again

From: Leaf yeh <[email-masked]>
Date: Fri, 16 Mar 2012 06:05:32 +0000

IMHO, the following are only for the technical discussion:

Section 2.1 of RFC6158 only defined 9 data types, which are

1.  32-bits unsigned integer
2.  Enumerated (32-bit unsigned integer)
3.  IPv4 address (32-bit/4-octet)
4.  Time (32-bit unsigned integer in second)
5.  IPv6 address (128-bit/16-octet)
6.  Interface-ID (64-bit/8-octet)
7.  IPv6 prefix (variable length per the field of 'prefix-length' defined in RFC3162)
8.  String (<= 253-octet)
9.  UTF-8 Text (<= 253-octet)

Section 6.1 of draft-ietf-radext-radius-extensions-04 recommended to add 3 new basic data types, which are

10.  EVS (Extended Vendor Specific)
11.  TLV (Type-Length-Value)
12.  Interger64 (64-bits)

Section 6.3 of draft-ietf-radext-radius-extensions-04 provided the guidelines for Complex Data Type, which sounds as follows:

<quote>Does the attribute:
* define a complex type which can be represented via TLVs?
If so, this data type MUST be represented via TLVs.</quote>

But section 6.4 of draft-ietf-radext-radius-extensions-04 provided the guidelines for the new types, which are as follows:

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

There might be 2 alternatives for the attribute re-design of 'Route-IPv6-Information' if we want to comply with RFC6158 and draft-ietf-radext-radius-extensions.

Design-a. I suggest TLV can be used in any RADIUS attribute including those in the unassigned standard space after the publication of draft-ietf-radext-radius-extensions (Remote Authentication Dial In User Service (RADIUS) Protocol Extensions).

Design-b. It needs 3 new attributes in the traditional flat mode to carry the information in the fields of Route Information Option defined in RFC4191. They might be: 1 for the IPv6 Prefix (variable length); 1 for the Route Lifetime (32-bit) and 1 for Route Preference (32-bit).

Design-b might be the simplest way now if we remind there is RFC6158 and forget there is draft-ietf-radext-radius-extensions.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sanchez, Mauricio (HP Networking)
Sent: Wednesday, March 14, 2012 1:09 AM
To: Wojciech Dec; [email-masked]
Cc: Bernard Aboba; [email-masked]
Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt

RADEXT, like any good IETF WG, has a colorful history and sometimes a bit
schizophrenic, as this particular case can attest to.  I think we can all
agree that the ipv6 attributed noted below is of a complex type and in
conflict with RFC6158 mandate to not continue to promulgate such complex
types. However, RFC6158 also includes a significant amount of leeway.  I
think we have two options before us:

(1) Per RFC6158's mandate include a small statement justifying the complex
attribute as it stands now.  Statement would be similar in spirit to what
appendix B in RFC6158 does for other complex attributes

(2) Recast the design of attribute into a new form that reduces its
complexity (i.e. Look to follow RFC6158 more closely).

If we agree these are the two options before us, we can do consensus check
on which approach the WG would like to take.

-MS

---

From: Leaf yeh <[email-masked]>
Date: Fri, 16 Mar 2012 06:05:32 +0000

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sanchez, Mauricio (HP Networking)
Sent: Wednesday, March 14, 2012 1:09 AM
To: Wojciech Dec; [email-masked]
Cc: Bernard Aboba; [email-masked]
Subject: Re: [radext] I-D Action: draft-ietf-radext-ipv6-access-06.txt

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