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

From: "Benoit Lourdelet (blourdel)" <[email-masked]>
Date: Sun, 9 Nov 2008 19:14:12 +0100

Hello,

The DHCP context has been removed on purpose to avoid restricting the
use of the new attributes
 in different context.
IPv6-DNS-Server-Address is a good example as it could be used by DHCPv6
or RA (see RFC5006).
So we certainly should not restrict its use by DHCPv6.

Even IPv6-Address could be used in an autoconfiguration context for
validation of an address included
 in ND messages.

All the above preaches to remove any reference to DHCP as too
restrictive.

A possibility would be to clarify the use of Framed-IPv6-Prefix and
restrict its use to prefix shorter
 or equal to 64.

Regards

Benoit

________________________________

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Bernard Aboba
Sent: Wednesday, October 29, 2008 5:07 AM
To: [email-masked]
Subject: Review of draft-lourdelet-radext-rfc3162bis-01.txt

Review of draft-lourdelet-radext-rfc3162bis-01.txt
 
This document represents the folding of the attributes described in
draft-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 arisen
with respect to RFC 3162, and one of the reasons to produce
an RFC 3162bis would be to clarify those issues.  One of the
issues, 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 attribute
can 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 this
usage is feasible, it is not entirely clear what a typical NAS 
would do on receiving a Framed-IPv6-Prefix Attribute with a /128
prefix, since the typical practice is to announce the prefix using
Router Advertisement.  
 
Given this, as well as the approach in RFC 4818, it would appear
that the easiest way to distinguish RFC 3162 from RFC 4818 and
draft-lourdelet-radext-ipv6-dhcp is that each of these documents
addresses a different set of scenarios.  RFC 3162 was largely 
focused on stateless address autoconfiguration (largely focused
on 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 explain
the 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.  One
question that arose during IETF 73 was how address assignment
would 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
Recursive
Name Server Option [RFC3646].  This was illustrated in the following
diagram 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."

i'm EMAILING FOR THE GREATER GOOD
Join me
<http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood> 	

--
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: "Bernard Aboba" <[email-masked]>
Date: Sun, 9 Nov 2008 20:35:42 -0800

It would be helpful to add RFC 5006 as a reference within Section 3.8
so as to clarify the potential use of the IPv6-DNS-Server-Address
attribute. 

With respect to DHCP support, at IETF 72, questions were raised about
the usage model in this document versus that in RFC 4014.  For example,
in RFC 4014, the RADIUS server speaks to the NAS, which can then act
as a DHCP relay agent in talking to the DHCP server.  In this document,
it appears that the RADIUS server talks directly to the DHCP server.
Is that right?  If so, when does authentication take place?  Is the
intent to allocate other RADIUS attributes corresponding to 
existing DHCPv4/v6 options? 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Benoit Lourdelet (blourdel)
Sent: Sunday, November 09, 2008 10:14 AM
To: Bernard Aboba; [email-masked]
Cc: [email-masked]; Benoit Lourdelet (blourdel)
Subject: RE: Review of draft-lourdelet-radext-rfc3162bis-01.txt

Hello,

Regards

Benoit

 

 

 

 

 

Text from RFC 5080: