Prefix Delegation Discussion

["Bernard Aboba" <bernard_aboba@hotmail.com>]

To kick off the review of draft-salowey-radext-delegated-prefix-01.txt, I 
thought I would post my (admittedly imperfect) understanding of what the 
problem is, why this document is necessary, and what (if anything) is wrong 
with RFC 3162.

RFC 3633 describes the basic scenario for use of prefix delegation:

  The model of operation for prefix delegation is as follows.  A
  delegating router is provided IPv6 prefixes to be delegated to
  requesting routers.  Examples of ways in which the delegating router
  may be provided these prefixes are given in Section 12.2.  A
  requesting router requests prefix(es) from the delegating router, as
  described in Section 12.1.  The delegating router chooses prefix(es)
  for delegation, and responds with prefix(es) to the requesting
  router.  The requesting router is then responsible for the delegated
  prefix(es).  For example, the requesting router might assign a subnet
  from a delegated prefix to one of its interfaces, and begin sending
  router advertisements for the prefix on that link.

  Each prefix has an associated valid and preferred lifetime, which
  constitutes an agreement about the length of time over which the
  requesting router is allowed to use the prefix.  A requesting router
  can request an extension of the lifetimes on a delegated prefix and
  is required to terminate the use of a delegated prefix if the valid
  lifetime of the prefix expires.

  This prefix delegation mechanism would be appropriate for use by an
  ISP to delegate a prefix to a subscriber, where the delegated prefix
  would possibly be subnetted and assigned to the links within the
  subscriber's network.

The use of RADIUS is described in Section 11.2:

  The  mechanism through which the delegating router selects prefix(es) for
  delegation is not specified in this document.  Examples of ways in
  which the delegating router might select prefix(es) for a requesting
  router include: static assignment based on subscription to an ISP;
  dynamic assignment from a pool of available prefixes; selection based
  on an external authority such as a RADIUS server using the Framed-
  IPv6-Prefix option as described in RFC 3162 [5].

Ralph's presentation from IETF 64 is located here:
http://www.drizzle.com/~aboba/IETF64/radext/ietf64_radext_Delegation.pdf

As I understand it, the issue occurs when an ISP desires to support Prefix 
Delegation at the same time that it would like to assign a prefix for the 
link between the NAS and CPE.  In this situation, the sematics of 
Framed-IPv6-Prefix are unclear:  what prefixes are to be used for 
delegation, and which one is to be used for the link?

Here is what RFC 3162 says about Framed-IPv6-Prefix:

     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.

In this case the user is the CPE.  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 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 Value field is four octets.

      0      None
      1      Send routing packets
      2      Listen for routing packets
      3      Send and Listen

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.

In my opinion, this is somewhat too broad, because it is not  clear to me 
what a NAS should do with a prefix of greater granularity than /64.  For 
example, what if Framed-IPv6-Prefix contains a /128? Does this imply that 
the NAS should be assigning an IPv6 address to the CPE?  I think the answer 
to that is no, because RFC 3162 already defines a Framed-IPv6-Identifier 
attribute to handle the Identifier portion.

In any case, it appears to me that the statement that "Framed-IPv6-Prefix is 
intended for assignment to the link between NAS and CPE" is only true if a 
/64 prefix is assigned.  When a larger prefix is sent, the intent was to 
provide the entire prefix to the CPE, enabling the CPE to assign 
sub-prefixes if it wished to do so.



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>