Review of draft-salowey-radext-delegated-prefix-01.txt

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

Some comments on draft-salowey-radext-delegated-prefix-01, based my 
(possibly imperfect) understanding of the scenario.  Overall, I think the 
document is ok, but it may need some tweaking with respect to its 
description of the functionality of the existing Framed-IPv6-Prefix 
attribute.

 This is different from the usage of Framed-IPv6-
  Prefix attribute in which the prefix remains in control of the
  Network Access Server (NAS).  The prefix in the Framed-IPv6-Prefix
  attribute can be assigned to a link to which the NAS is attached, and
  may subsequently be advertised through Router Advertisement messages
  [3].

At the time RFC 3162 was written, I believe that intent was for the prefix 
described in Framed-IPv6-Prefix to be advertised by the NAS in Router 
Advertisement messages.   However, I am not clear that this necessarily 
implies that the prefix is solely for use on the link to which the NAS is 
attached.  For example, if a /48 is assigned, wouldn't it be possible for 
the NAS to advertise the /48 via Router Advertisement and for the CPE to 
parcel out /64s to its interfaces?  Given that interpretation, I don't think 
it is necessarily true that "the prefix remains in control of the NAS".

      Prefix-Length

           The length of the prefix, in bits.  At least 0 and no larger  
than 128.

This sentence, echoing RFC 3162 may introduce some of the same issues. Is it 
really the intent to enable prefixes more granular than a /64?   What is the 
inplication for prefix delegation if a /128 is assigned?



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