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."
Join me |