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:bernard_aboba@hotmail.com]
Sent: Saturday, November 15, 2008 11:25 PM
To: Benoit Lourdelet (blourdel); Ralph Droms (rdroms); radiusext@ops.ietf.org
Subject: RE: RADEXT WG consensus call on "IPv6 Attributes for DHCP Networks"
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.
Join me |
> Subject: RE: RADEXT WG consensus call on "IPv6 Attributes for DHCP Networks"
> Date: Thu, 13 Nov 2008 12:41:11 +0100
> From: blourdel@cisco.com
> To: rdroms@cisco.com; radiusext@ops.ietf.org
> CC: bernard_aboba@hotmail.com
>
> 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: radiusext@ops.ietf.org
> 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
> > (radiusext@ops.ietf.org ).
> >
> >
> >
>