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

From: "Benoit Lourdelet (blourdel)" <[email-masked]>
Date: Fri, 14 Nov 2008 11:14:39 +0100

Bernard,

Inline after BL>>

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Monday, November 10, 2008 5:36 AM
To: Benoit Lourdelet (blourdel); [email-masked]
Subject: RE: Review of draft-lourdelet-radext-rfc3162bis-01.txt

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. 

BL>> I will publish rev 03 with that addition.

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? 

BL>> there is no intend to add a RADIUS attribute per DHCP option. The
new attributes are aimed at addressing deployment needs and partially
restoring parity with IPv4 attributes (standard or proprietary).

BL>> A possible option is to remove all DHCP references in the document.
That is one way to solve the problem.
The other way is to describe use of the RFc3162bis option in a DHCP
context, but as there are many DHCP deployment scenarii, restricting to
a particular set in RFC3162bis may be a problem.
The generic character of RFC3162 allowed the use of the attribute in a
DHCP context without major problem.

BL>> What we could probably do is to clarify  the use of
Framed-IPv6-Prefix to an actual prefix, not an IPv6 address.

Regards

Benoit

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

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

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