Re: Review of draft-ietf-radext-fixes-01.txt

[Alan DeKok <aland@nitros9.org>]

Bernard Aboba wrote:
> Section 2.6
> 
>   Where a NAS offers multiple services, confusion may result with
>   respect to interpretation of a Disconnect-Request [RFC3576].  In
>   order to prevent confusion a RADIUS Server SHOULD identify the
>   session that it desires to terminate as specifically as possible.
>   For example, an Acct-Session-Id attribute SHOULD be included in
>   Disconnect-Request and CoA-Request packets, rather than just the
>   User-Name attribute.
>
> I think this material might better belong in RFC 3576bis.

  I have no objections.  We should therefore remove references to RFC
3576 from the document, as that paragraph contains the only textual
reference to that document.

...
> You might include a reference to the RADIUS Prefix Delegation document
> (now in the RFC Editor Queue).

  OK.

>   It appears that the Framed-IPv6-Prefix is used for the link between
>   the NAS and CPE only if a /64 prefix is assigned.  When a 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.
> 
> Even if a /64 prefix is assigned, I think that the NAS is expected
> to send an RA to the CPE, no?  Otherwise I'm not sure how the CPE
> could learn the prefix.

  I believe so, yes.

> The other issue is how the CPE obtains a prefix to use for its own
> network, in the case that the CPE is decrementing TTL.  Prefix
> Delegation is the mechanism created for that purpose.  If the CPE
> is acting as a Bridge or ND-Proxy, then it does not need to request
> that a prefix be delegated.  It might make sense to say a few words
> about this.

  I will add a sentence about this.

  Alan DeKok.



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