Subject: RE: RADEXT WG consensus call on "IPv6 Attributes for DHCP Networks"

From: "Benoit Lourdelet (blourdel)" <[email-masked]>
Date: Thu, 13 Nov 2008 12:41:11 +0100

Ralph,

The problem I have with this approach is that giving more though to it,
I thing that

IPv6-DNS attribute could be used in the RFC5006 context. So it is not
DHCP use only.

IPv6-address could be used in a SLAC context for validation of the
advertised address by the gateway.

So it turns that none of the attributes are DHCP specific.

Regards

Benoit

-----Original Message-----
From: Ralph Droms (rdroms) 
Sent: Wednesday, November 12, 2008 2:15 AM
To: [email-masked]
Cc: Ralph Droms (rdroms); Bernard Aboba; Benoit Lourdelet (blourdel)
Subject: Re: RADEXT WG consensus call on "IPv6 Attributes for DHCP
Networks"

I support accepting "IPv6 Attributes for DHCP Networks" as a RADEXT WG
work item.  There is a need for these attributes to support certain
IPv6 deployment models.

I support handling "IPv6 Attributes for DHCP Networks" as a separate
work item.  I am concerned that bundling the attributes into a revision
of RFC 3162 would incur too much delay.

- Ralph

On Oct 28, 2008, at Oct 28, 2008,2:00 AM, Bernard Aboba wrote:

> At IETF 72, the RADEXT WG was polled on the following questions:
>
> 1) whether to accept "IPv6 Attributes for DHCP Networks"
> (http://www.ietf.org/internet-drafts/draft-lourdelet-radext-ipv6-dhcp-
> 00.txt
> )
> as a RADEXT WG work item;
>
> 2) whether to handle this as a standalone work item or bundle it into 
> a revision of RFC 3162 (RFC 3162bis).
>
> This is a RADEXT WG consensus call, in order to confirm the "sense of 
> the room" at IETF 72 with respect to these two items.
>
> The RADEXT WG Consensus call will last until November 12, 2008.    
> Please send your
> opinions on these two questions to the RADEXT WG mailing list 
> ([email-masked] ).
>
>
>

--
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: Sat, 15 Nov 2008 14:25:14 -0800

I'd suggest that the issue of whether the document should revise RFC 3162 is somewhat
separate from whether it only relates to DHCPv6 or not. As Ralph points out, revising RFC 3162 involves considerably more work.  For example,
it would be necessary to address the issues brought up in RFC 5080 Section 2.11. 
Also, there are existing deployments of RFC 3162, so backward compatibility issues need
to be taken into account.  So if your desire is to get this work done quickly, an
RFC 3162 revision is best avoided unless it's nessary. 
 
In your original submission (draft-lourdelet-radext-ipv6-dhcp-00) there was a normative 
reference to RFC 3162, contained in the following paragraph:
 
   This attributes offers an entire IPv6 address to the DHCPv6 Server in   contrast to Interface-id [RFC3162] that offers only 64 bits.  Even   concatenated with Framed-IPv6 prefix [RFC3162] to make a 128 bit IPv6   address, this does not address scenarios where there is a need to   offer multiple addresses or off-link IPv6 addresses that are not part   of the prefix stored in the Framed-IPv6-Prefix attribute.  Storing   the IPv6 address in the subscriber RADIUS profile is particularly   useful as the Service Provider will know in advance the customers   uplink IPv6 address, hence facilitating management or security policy   implementation.
Based on this, it would appear that the major issue relating to RFC 3162
is the potential usage of Framed-IPv6-Prefix to assign an entire IPv6
address (e.g. use of a /128 prefix).   RFC 5080 already addresses this
to some extent in Section 2.11:
 
   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.
In essence, RFC 5080 states that Framed-IPv6-Prefix is not to be used
for IPv6 address assignment, which is the point you make in your document. 
 
Given this, it would appear to me that your original submission does not
have a normative dependency on an RFC 3162 revision.  Of course, if
you're willing to sign up for the extra work required to complete such
a revision, your efforts would be appreciated. 

 EMAILING FOR THE GREATER GOODJoin me> Subject: RE: RADEXT WG consensus call on "IPv6 Attributes for DHCP Networks"> Date: Thu, 13 Nov 2008 12:41:11 +0100> From: [email-masked]> To: [email-masked]; [email-masked]> CC: [email-masked]> > Ralph,> > The problem I have with this approach is that giving more though to it,> I thing that> > IPv6-DNS attribute could be used in the RFC5006 context. So it is not> DHCP use only.> > IPv6-address could be used in a SLAC context for validation of the> advertised address by the gateway.> > So it turns that none of the attributes are DHCP specific.> > Regards> > Benoit> > > -----Original Message-----> From: Ralph Droms (rdroms) > Sent: Wednesday, November 12, 2008 2:15 AM> To: [email-masked]> Cc: Ralph Droms (rdroms); Bernard Aboba; Benoit Lourdelet (blourdel)> Subject: Re: RADEXT WG consensus call on "IPv6 Attributes for DHCP> Networks"> > I support accepting "IPv6 Attributes for DHCP Networks" as a RADEXT WG> work item. There is a need for these attributes to support certain> IPv6 deployment models.> > I support handling "IPv6 Attributes for DHCP Networks" as a separate> work item. I am concerned that bundling the attributes into a revision> of RFC 3162 would incur too much delay.> > - Ralph> > On Oct 28, 2008, at Oct 28, 2008,2:00 AM, Bernard Aboba wrote:> > > At IETF 72, the RADEXT WG was polled on the following questions:> >> > 1) whether to accept "IPv6 Attributes for DHCP Networks"> > (http://www.ietf.org/internet-drafts/draft-lourdelet-radext-ipv6-dhcp-> > 00.txt> > )> > as a RADEXT WG work item;> >> > 2) whether to handle this as a standalone work item or bundle it into > > a revision of RFC 3162 (RFC 3162bis).> >> > This is a RADEXT WG consensus call, in order to confirm the "sense of > > the room" at IETF 72 with respect to these two items.> >> > The RADEXT WG Consensus call will last until November 12, 2008. > > Please send your> > opinions on these two questions to the RADEXT WG mailing list > > ([email-masked] ).> >> >> >>

---

From: "Benoit Lourdelet (blourdel)" <[email-masked]>
Date: Mon, 17 Nov 2008 09:49:24 +0100

Bernard,

RFC 5080 Section 2.11 comment about  Framed-IPv6-Prefix is a fair point
that would require more thought 
 in revising RFC3162.
 
I have no problem going the "separate document" route and re-publish a
revision including additional attributes only as I did in my first
revision of the document.
 
Let me add that in the presentation for Tuesday WG meeting.
 
regards
 
Benoit

________________________________

From: Bernard Aboba [mailto:[email-masked]] 
Sent: Saturday, November 15, 2008 11:25 PM
To: Benoit Lourdelet (blourdel); Ralph Droms (rdroms);
[email-masked]
Subject: RE: RADEXT WG consensus call on "IPv6 Attributes for DHCP
Networks"

I'd suggest that the issue of whether the document should revise RFC
3162 is somewhat
separate from whether it only relates to DHCPv6 or not. 

As Ralph points out, revising RFC 3162 involves considerably more work.
For example,
it would be necessary to address the issues brought up in RFC 5080
Section 2.11. 
Also, there are existing deployments of RFC 3162, so backward
compatibility issues need
to be taken into account.  So if your desire is to get this work done
quickly, an
RFC 3162 revision is best avoided unless it's nessary. 
 
In your original submission (draft-lourdelet-radext-ipv6-dhcp-00) there
was a normative 
reference to RFC 3162, contained in the following paragraph:
 
   This attributes offers an entire IPv6 address to the DHCPv6 Server in
   contrast to Interface-id [RFC3162] that offers only 64 bits.  Even
   concatenated with Framed-IPv6 prefix [RFC3162] to make a 128 bit IPv6
   address, this does not address scenarios where there is a need to
   offer multiple addresses or off-link IPv6 addresses that are not part
   of the prefix stored in the Framed-IPv6-Prefix attribute.  Storing
   the IPv6 address in the subscriber RADIUS profile is particularly
   useful as the Service Provider will know in advance the customers
   uplink IPv6 address, hence facilitating management or security policy
   implementation.

   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.

In essence, RFC 5080 states that Framed-IPv6-Prefix is not to be used
for IPv6 address assignment, which is the point you make in your
document. 

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

> Subject: RE: RADEXT WG consensus call on "IPv6 Attributes for DHCP
Networks"
> Date: Thu, 13 Nov 2008 12:41:11 +0100
> From: [email-masked]
> To: [email-masked]; [email-masked]
> CC: [email-masked]
> 
> Ralph,
>