Subject: Review of draft-lourdelet-radext-rfc3162bis-01.txt

From: Bernard Aboba <[email-masked]>
Date: Tue, 28 Oct 2008 21:07:14 -0700

Review of draft-lourdelet-radext-rfc3162bis-01.txt
 
This document represents the folding of the attributes described indraft-lourdelet-radext-ipv6-dhcp-00.txt with RFC 3162.  Currently,the RFC 3162 has been brought over to this document verbatim; only Sections 3.7 (defining the IPv6-Address attribute) and Section 3.8 (defining the IPv6-DNS-Server-Address attribute)have changed. 
 
As discussed at IETF 73, several points of confusion have arisenwith respect to RFC 3162, and one of the reasons to producean RFC 3162bis would be to clarify those issues.  One of theissues, whether Framed-IPv6-Prefix could be used with DHCP Prefix delegation, was addressed in RFC 4818 (the answer is no). 
 
Another issue relates to whether the Framed-IPv6-Prefix attributecan be used with a prefix length greater than a /64 (e.g. /128). RFC 5080, Section 2.11 discusses this, though strangely it does not update RFC 3162.  As noted in this section (see below), while thisusage is feasible, it is not entirely clear what a typical NAS would do on receiving a Framed-IPv6-Prefix Attribute with a /128prefix, since the typical practice is to announce the prefix usingRouter Advertisement.  
 
Given this, as well as the approach in RFC 4818, it would appearthat the easiest way to distinguish RFC 3162 from RFC 4818 anddraft-lourdelet-radext-ipv6-dhcp is that each of these documentsaddresses a different set of scenarios.  RFC 3162 was largely focused on stateless address autoconfiguration (largely focusedon PPP); RFC 4818 is about prefix delegation; draft-lourdelet-radext-ipv6-dhcp is about stateful addressing and configuration via DHCPv6.  
 
However, in merging draft-lourdelet-radext-ipv6-dhcp with RFC 3162, some of the explanatory information has been removed.  This makes
it difficult to understand that the new attributes relate to stateful
address assignment via DHCPv6.  
 
For example, Section 3.7 introduces the IPv6-Address attribute.  However, only some of the original text from draft-lourdelet-radext-ipv6-dhcp-00 is included to explainthe usage of the attribute.  
 
>From the IETF 73 discussion, my understanding is that the purpose of this attribute is for the RADIUS server to assign one or more IPv6 addresses to a NAS which is acting as a DHCPv6 server, and will subsequently assign those addresses to a user acting as a DHCPv6 client.  Onequestion that arose during IETF 73 was how address assignmentwould relate to the authentication process.  
 
For example, draft-lourdelet-radius-ipv6-dhcp includes the following diagram:
 
    Router/Host (DHCPv6 Client)  Router (DHCPv6 Server)  RADIUS Server       |                           |                                |       |--Solicit(Address)-------->|                                |       |                           |-----Request------------------->|       |                           |<---------Accept(IPv6-Address)--|       |<-Advertise(Address)-------|                                |       |---Request(Address)------->|                                |       |<---Reply(Address)---------|                                |
In this diagram, no authentication is present at all, which lead to
considerable discussion (and confusion) at IETF 73.  
 
Similarly, Section 3.8 defines the IPv6-DNS-Server-Address attribute,which is assigned to a NAS acting as a DHCPv6 server, with the goal of providing this DNS server address to the user within the DNS RecursiveName Server Option [RFC3646].  This was illustrated in the followingdiagram from draft-lourdelet-radius-ipv6-dhcp:
 
    Router/Host (DHCPv6 Client)  Router (DHCPv6 Server)    RADIUS Server        |                            |                                |        |--Solicit (DNS)------------>|                                |        |                            |-Request----------------------->|        |                            |<-------Accept(Ipv6-DNS)--------|        |<-Advertise(DNS)------------|                                |        |-Request(DNS)-------------->|                                |        |<--Reply(DNS)---------------|       
Again, some context would be helpful. 
 
Overall, if the goal is to clarify issues from RFC 3162bis as well as
to add new DHCPv6-related attributes, then it seems that additional
work is required such as integration of the clarifications from RFC 5080,
and explanation of the DHCPv6 usage scenarios. 
Text from RFC 5080:
"2.11.  Framed-IPv6-Prefix
 
   [RFC3162] Section 2.3 says:
      This Attribute indicates an IPv6 prefix (and corresponding route)      to be configured for the user.  It MAY be used in Access-Accept      packets, and can appear multiple times.  It MAY be used in an      Access-Request packet as a hint by the NAS to the server that it      would prefer these prefix(es), but the server is not required to      honor the hint.  Since it is assumed that the NAS will plumb a      route corresponding to the prefix, it is not necessary for the      server to also send a Framed-IPv6-Route attribute for the same      prefix.
 
   An Internet Service Provider (ISP) may desire to support Prefix   Delegation [RFC4818] at the same time that it would like to assign a   prefix for the link between the NAS and the user.  The intent of the   paragraph was to enable the NAS to advertise the prefix (such as via   a Router Advertisement).  If the Framed-Routing attribute is used, it   is also possible that the prefix would be advertised in a routing   protocol such as Routing Information Protocol Next Generation   (RIPNG).  RFC 2865 Section 5.10 describes the purpose of Framed-   Routing:
 
      This Attribute indicates the routing method for the user, when the      user is a router to a network.  It is only used in Access-Accept      packets.
 
   The description of the Prefix-Length field in RFC 3162 indicates   excessively wide latitude:
 
      The length of the prefix, in bits.  At least 0 and no larger than      128.
 
   This length appears too broad, because it is not clear what a NAS   should do with a prefix of greater granularity than /64.  For   example, the Framed-IPv6-Prefix may contain a /128.  This does not   imply that the NAS should assign an IPv6 address to the end user,   because RFC 3162 already defines a Framed-IPv6-Identifier attribute   to handle the Identifier portion.
 
   It appears that the Framed-IPv6-Prefix is used for the link between   the NAS and Customer Premises Equipment (CPE) only if a /64 prefix is   assigned.  When a /64 or larger prefix is sent, the intent is for the   NAS to send a routing advertisement containing the information   present in the Framed-IPv6-Prefix attribute.
 
   The CPE may also require a delegated prefix for its own use, if it is   decrementing the Hop Limit field of IP headers.  In that case, it   should be delegated a prefix by the NAS via the Delegated-IPv6-Prefix   attribute [RFC4818].  If the CPE is not decrementing Hop Limit, it   does not require a delegated prefix."

 EMAILING FOR THE GREATER GOODJoin me