Subject: Re: [radext] #69: Section 1

From: "radext issue tracker" <[email-masked]>
Date: Mon, 14 Mar 2011 13:36:08 -0000

#69: Section 1

Changes (by wdec@…):

  * status:  new => assigned

Comment:

 Agreed with one caveat. I'm not sure that the framed-ipv6-route was
 intended for use with RIPng. It seems more like being intended to be
 intended for the NAS to install the specified route towards the client,
 which then may be redistributed into some IGP. This is different than
 advertising a route to a client by means of ICMPv6 or DHCPv6.

 Awaiting a response.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:  wdec@…        
     Type:  defect                     |      Status:  assigned      
 Priority:  major                      |   Milestone:  milestone1    
Component:  ipv6-access                |     Version:  1.0           
 Severity:  In WG Last Call            |    Keywords:                
---------------------------------------+------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/69#comment:2>
radext <http://tools.ietf.org/radext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "radext issue tracker" <[email-masked]>
Date: Sat, 26 Mar 2011 06:12:07 -0000

#69: Section 1

Comment(by bernard_aboba@…):

 The RFC 3162 text on Framed-IPv6-Route is included below.  The text is
 analagous to that used to define Framed-Route in RFC 2865, Section 5.22.
 Note that RFC 2865 also defines Framed-Routing (Section 5.10), which
 determines how or if an IGP is used.
 If Framed-Routing = None or Listen, then I wouldn't expect routes to be
 redistributed into an IGP.  The question is what existing implementations
 do with Framed-IPv6-Route and whether this is influenced by the value of
 Framed-Routing.

 2.5.  Framed-IPv6-Route

    Description

       This Attribute provides routing information to be configured for
       the user on the NAS.  It is used in the Access-Accept packet and
       can appear multiple times.

    A summary of the Framed-IPv6-Route Attribute format is shown below.
    The fields are transmitted from left to right.

     0                   1                   2
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
    |     Type      |    Length     |  Text ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

    Type

       99 for Framed-IPv6-Route

    Length

       >=3

    Text

       The Text field is one or more octets, and its contents are
       implementation dependent.  The field is not NUL (hex 00)
       terminated.  It is intended to be human readable and MUST NOT
       affect operation of the protocol.

       For IPv6 routes, it SHOULD contain a destination prefix optionally
       followed by a slash and a decimal length specifier stating how
       many high order bits of the prefix to use.  That is followed by a
       space, a gateway address, a space, and one or more metrics
       (encoded in decimal) separated by spaces.  Prefixes and addresses
       are formatted as described in [16].  For example,
       "2000:0:0:106::/64 2000::106:a00:20ff:fe99:a998 1".

       Whenever the gateway address is the IPv6 unspecified address the
       IP address of the user SHOULD be used as the gateway address.  The
       unspecified address can be expressed in any of the acceptable
       formats described in [16].  For example, "2000:0:0:106::/64 :: 1".

Ticket URL: <https://trac.tools.ietf.org/wg/radext/trac/ticket/69#comment:3>
radext <http://tools.ietf.org/radext/>