Re: [radext] Publication request for RADIUS attributes for IPv6 Access Networks; draft-ietf-radext-ipv6-access-11

[Leaf yeh <[e-mail]>]

Jouni - There is definitely no harm including those all (well, expect packet size).


Understood.


I am trying to find more text in the RFCs associated with RADIUS for your reference.

a. Section 5.44 of RFC2865

<quote>
   Request   Accept   Reject   Challenge   #    Attribute
...
   0         0+       0        0           22   Framed-Route
...
</quote>


b. Section 5.13 of RFC2866

<quote>
   The following table provides a guide to which attributes may be found
   in Accounting-Request packets.  No attributes should be found in
   Accounting-Response packets except Proxy-State and possibly Vendor-
   Specific.
...
#     Attribute
0+    Framed-Route
...
</quote>


c. Section 5.19 of RFC2869

<quote>
   Acct-Input-Gigawords, Acct-Output-
   Gigawords, Event-Timestamp, and NAS-Port-Id may have 0-1 instances in
   an Accounting-Request packet ... The other attributes added in this
   document must not be present in an Accounting-Request.

Request  Accept  Reject  Challenge   #    Attribute
...
0        0-1     0       0           88   Framed-Pool


d. section 3 of RFC3162

<quote>
   Request Accept Reject Challenge Accounting  #  Attribute
                                   Request
...
   0       0+     0      0         0+         99  Framed-IPv6-Route
   0       0-1    0      0         0-1       100  Framed-IPv6-Pool
</quote>


I don't really understand why Framed-Route (22) and Framed-IPv6-Route (99) could be included in Accounting-Request before. The above text shows Framed-Route (22) and Framed-IPv6-Route (99) can't be included into Access-Request.


Best Regards,
Leaf



-----Original Message-----
From: jouni korhonen [mailto:[e-mail]] 
Sent: Monday, August 13, 2012 10:33 PM
To: Leaf yeh
Cc: Wojciech Dec (wdec); Benoit Claise (bclaise); [e-mail]
Subject: Re: [radext] Publication request for RADIUS attributes for IPv6 Access Networks; draft-ietf-radext-ipv6-access-11


On Aug 13, 2012, at 12:24 PM, Leaf yeh wrote:

>> DNS-Server-IPv6-Address
>> Delegated-IPv6-Prefix-Pool
>> Stateful-IPv6-Address-Pool
>> Route-IPv6-Information
> 
> Woj - These were specifically asked previously to be included as options in the accounting message.
> 
> I believe it is useless to include 'DNS-Server-IPv6-Address' & 'Route-IPv6-Information' into the Accounting-Request message. I believe it is more useful to include 'Delegated-IPv6-Prefix (123)' instead of 'Delegated-IPv6-Prefix-Pool', and 'Frame-IPv6-Address' instead of 'Stateful-IPv6-Address-Pool' in the Accounting-Request message, just because they are the user-specified attributes.

There is definitely no harm including those all (well, expect packet size). And since
they are 0+ an implementation does not need to send those based on e.g. the local policy.

- Jouni

> 
> 
> Best Regards,
> Leaf
> 
> 
> -----Original Message-----
> From: Wojciech Dec (wdec) [mailto:[e-mail]] 
> Sent: Friday, August 10, 2012 10:50 PM
> To: Leaf yeh; jouni korhonen
> Cc: Benoit Claise (bclaise); [e-mail]
> Subject: Re: [radext] Publication request for RADIUS attributes for IPv6 Access Networks; draft-ietf-radext-ipv6-access-11
> 
> 
> 
> On 05/08/2012 22:05, "Leaf yeh" <[e-mail]> wrote:
> 
>> Quick questions on this draft:
>> 
>> a. question on the occurrence of attributes in the accounting-request
>> message
>> 
>> <quote > The following table provides a guide to which attributes may be
>> found
>> in which kinds of packets, and in what quantity. ...
>> Request Accept Reject Challenge Accounting    #  Attribute
>>                          Request
>> 0+      0+     0      0         0+      TBA1  Framed-IPv6-Address
>> 0+      0+     0      0         0+      TBA2  DNS-Server-IPv6-Address
>> 0+      0+     0      0         0+      TBA3  Route-IPv6-Information
>> 0+      0+     0      0         0+      TBA4  Delegated-IPv6-Prefix-Pool
>> 0+      0+     0      0         0+      TBA5  Stateful-IPv6-Address-Pool
>> </quote>
>> 
>> 
>> I guess 0+ will never be false for every attribute in every kind of
>> radius message. But I doubt whether it is necessary to let the following
>> attributes: 
>> 
>> DNS-Server-IPv6-Address
>> Delegated-IPv6-Prefix-Pool
>> Stateful-IPv6-Address-Pool
> 
> These were specifically asked previously to be included as options in the
> accounting message.
> 
>> 
>> or 
>> 
>> Route-IPv6-Information
>> 
>> into the message of accounting-request, for the attributes of
>> DNS-Server-IPv6-Address, Delegated-IPv6-Prefix-Pool and
>> Stateful-IPv6-Address-Pool are not for the specified-user requested for
>> accounting, and Route-IPv6-Information might have no relation with the
>> accounting.
> 
> Given that it is optional, no harm really in having it there.
> 
>> 
>> 
>> b. comparison question between IPv6 and IPv4 access
>> 
>> We defined the attribute of DNS-Server-IPv6-Address for IPv6 access, but
>> never defined DNS-Server-IPv4-Address before for IPv4 access. Do we need
>> one more attribute for DNS-Server-IPv4-Address?
> 
> Yes, perhaps, but that would be for an IPv4 draft.
> 
>> 
>> 
>> Supposed both of the attributes could help the operator to configure the
>> DNS addresses for users at their centralized back-stage OSS system, but
>> in general speaking, both of them are not user-specified attribute.
> 
> Well, they are service related, and users are bound to services. Either
> way, it needs to be passed down in the user access response.
> 
> Regards,
> Woj..
> 
>> 
>> 
>> Best Regards,
>> Leaf
>> 
>> 
>> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf
>> Of jouni korhonen
>> Sent: Saturday, August 04, 2012 4:34 AM
>> To: [e-mail]
>> Cc: Benoit Claise; [e-mail]
>> Subject: [radext] Publication request for RADIUS attributes for IPv6
>> Access Networks; draft-ietf-radext-ipv6-access-11
>> 
>> Dear Secretary,
>> 
>> This is a request for publication of draft-ietf-radext-ipv6-access-11 as
>> a standards track RFC.
>> 
>> - Jouni
>> 
>> -------------------------------------------------------
>> 
>> (1) What type of RFC is being requested (BCP, Proposed Standard,
>> Internet Standard, Informational, Experimental, or Historic)?  Why
>> is this the proper type of RFC?  Is this type of RFC indicated in the
>> title page header?
>> 
>> 	RADIUS attributes for IPv6 Access Networks is to be published
>> 	as a Standards Track RFC, which is indicated in the I-D's
>> 	cover page Intended Status field.
>> 
>> 	The RADIUS attributes defined in this I-D are needed for the
>> 	emerging IPv6 deployments across multiple types of network
>> 	architectures.
>> 
>> (2) The IESG approval announcement includes a Document Announcement
>> Write-Up. Please provide such a Document Announcement Write-Up. Recent
>> examples can be found in the "Action" announcements for approved
>> documents. The approval announcement contains the following sections:
>> 
>> Technical Summary
>> 
>> 	The I-D defines additional attributes for various IPv6
>> 	access network deployments (be that fixes or mobile network).
>> 	The attributes complement already existing set of IPv6 attributes
>> 	defined in e.g., RFC3162 and RFC4818. Furthermore, the I-D clarifies
>> 	the use of some existing IPv6 related attributes and the relationship
>> 	of those to the newly defined attributes.
>> 
>> 
>> Working Group Summary
>> 
>> 	The I-D has been discussed extensively in the RADEXT WG and has
>>       reached the overall working group consensus. There was a lengthy
>>       discussion regarding the Route-IPv6-Information attribute format
>>       and whether it should also contain the rest of the RFC4191 Route
>>       Information Option field in addition to the prefix. The WG
>>       reached a consensus that the other values are local to router
>>       configuration and not retrieved from the RADIUS server.
>> 
>> Document Quality
>> 
>>       There is specific interest from the Broadband Forum to incorporate
>>       the attributes defined in this specification into their respective
>>       IPv6 standards.
>> 
>>       AAA Doctors have not reviewed the document yet. There is no need
>>       for MIB or other doctorate review.
>> 
>>       Once the document goes to IETF LC, a review from V6OPS should be
>>       requested.
>> 
>> Personnel
>> 
>> Who is the Document Shepherd? Who is the Responsible Area
>> Director?
>> 
>>      Jouni Korhonen ([e-mail]) is the document
>>      shepherd.
>> 
>> (3) Briefly describe the review of this document that was performed by
>> the Document Shepherd.  If this version of the document is not ready
>> for publication, please explain why the document is being forwarded to
>> the IESG.
>> 
>>      The document shepherd has reviewed the document after it has
>>      concluded the WGLC. The document shepherd thinks the document
>>      is ready for publication and there is no reason to delay the
>>      publication anymore, since the attributes defined in this
>>      document are needed by the industry.
>> 
>> (4) Does the document Shepherd have any concerns about the depth or
>> breadth of the reviews that have been performed?
>> 
>>      No.
>> 
>> (5) Do portions of the document need review from a particular or from
>> broader perspective, e.g., security, operational complexity, AAA, DNS,
>> DHCP, XML, or internationalization? If so, describe the review that
>> took place.
>> 
>>      The document should be reviewed by V6OPS once it goes to
>>      IETF LC.
>> 
>> (6) Describe any specific concerns or issues that the Document Shepherd
>> has with this document that the Responsible Area Director and/or the
>> IESG should be aware of? For example, perhaps he or she is uncomfortable
>> with certain parts of the document, or has concerns whether there really
>> is a need for it. In any event, if the WG has discussed those issues and
>> has indicated that it still wishes to advance the document, detail those
>> concerns here.
>> 
>>      The document shepherd has no specific concerns.
>> 
>> (7) Has each author confirmed that any and all appropriate IPR
>> disclosures required for full conformance with the provisions of BCP 78
>> and BCP 79 have already been filed. If not, explain why.
>> 
>>       No IPRs have been declared.
>> 
>> (8) Has an IPR disclosure been filed that references this document?
>> If so, summarize any WG discussion and conclusion regarding the IPR
>> disclosures.
>> 
>>       No IPRs have been declared.
>> 
>> (9) How solid is the WG consensus behind this document? Does it
>> represent the strong concurrence of a few individuals, with others
>> being silent, or does the WG as a whole understand and agree with it?
>> 
>>       The WG consensus is solid and does not represent only the
>>       opinion of few individuals.
>> 
>> (10) Has anyone threatened an appeal or otherwise indicated extreme
>> discontent? If so, please summarise the areas of conflict in separate
>> email messages to the Responsible Area Director. (It should be in a
>> separate email because this questionnaire is publicly available.)
>> 
>>       No.
>> 
>> (11) Identify any ID nits the Document Shepherd has found in this
>> document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
>> Checklist). Boilerplate checks are not enough; this check needs to be
>> thorough.
>> 
>>       The document passes IDnits.
>> 
>> (12) Describe how the document meets any required formal review
>> criteria, such as the MIB Doctor, media type, and URI type reviews.
>> 
>>       The document does not define MIBs, media types, URIs etc.
>>       The data types used in the document comply with RFC6158.
>> 
>> (13) Have all references within this document been identified as
>> either normative or informative?
>> 
>>       Yes.
>> 
>> (14) Are there normative references to documents that are not ready for
>> advancement or are otherwise in an unclear state? If such normative
>> references exist, what is the plan for their completion?
>> 
>>       No.
>> 
>> (15) Are there downward normative references references (see RFC 3967)?
>> If so, list these downward references to support the Area Director in the
>> Last Call procedure.
>> 
>>       No.
>> 
>> (16) Will publication of this document change the status of any
>> existing RFCs? Are those RFCs listed on the title page header, listed
>> in the abstract, and discussed in the introduction? If the RFCs are not
>> listed in the Abstract and Introduction, explain why, and point to the
>> part of the document where the relationship of this document to the
>> other RFCs is discussed. If this information is not in the document,
>> explain why the WG considers it unnecessary.
>> 
>>       No.
>> 
>> (17) Describe the Document Shepherd's review of the IANA considerations
>> section, especially with regard to its consistency with the body of the
>> document. Confirm that all protocol extensions that the document makes
>> are associated with the appropriate reservations in IANA registries.
>> Confirm that any referenced IANA registries have been clearly
>> identified. Confirm that newly created IANA registries include a
>> detailed specification of the initial contents for the registry, that
>> allocations procedures for future registrations are defined, and a
>> reasonable name for the new registry has been suggested (see RFC 5226).
>> 
>>      The document only requests for five new RADIUS attribute types
>>      from an existing IANA registry.
>> 
>> (18) List any new IANA registries that require Expert Review for future
>> allocations. Provide any public guidance that the IESG would find
>> useful in selecting the IANA Experts for these new registries.
>> 
>>       None.
>> 
>> (19) Describe reviews and automated checks performed by the Document
>> Shepherd to validate sections of the document written in a formal
>> language, such as XML code, BNF rules, MIB definitions, etc.
>> 
>>       Checked with IDnits and verified against RFC6158 RADIUS
>>       design guidelines.
>> 
>> _______________________________________________
>> radext mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/radext
>> _______________________________________________
>> radext mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/radext
>