Subject: Re: [radext] #71: Section 2.3 and 3.3

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

#71: Section 2.3 and 3.3

Changes (by wdec@…):

  * status:  new => assigned

Comment:

 New description reads:

  An IPv6 Route Information option, defined in [RFC4191] is intended to
    be used to inform a host connected to the NAS that a specific route
    is reachable via the NAS.  This is particularly desirable in cases
    where the RG or host are multi-homed to different NASes as shown in
    Figure 1.

    This document specifies the RADIUS attribute that allows the AAA
    system to provision the announcement by the NAS of a specific Route
    Information Option to an accessing host.  The NAS may advertise this
    route using the method defined in [RFC4191] or using other equivalent
    methods.

    The distinction and separation between this attribute and the Framed-
    IPv6-Route attribute defined in [RFC3633] is needed due to the need
    to have the information carried by this attribute advertised to an
    attaching client.

-- 
---------------------------------------+------------------------------------
 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/71#comment:1>
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:23:25 -0000

#71: Section 2.3 and 3.3

Comment(by bernard_aboba@…):

 It seems to me that we want to enable use of routes in advertisements as
 well as in routing protocols, and possibly both at once.  RFC 3162 defines
 Framed-IPv6-Route, and the intent there was to enable inclusion in router
 advertisements, as well as potential redistribution in IGPs, depending on
 the value of Framed-Routing.  The question is how it was implemented.

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

---

From: "radext issue tracker" <[email-masked]>
Date: Mon, 28 Mar 2011 16:03:35 -0000

#71: Section 2.3 and 3.3

Comment(by wdec@…):

 Well, but it seems that there is a key distintiction between the routes
 that are advertised *to* the client by the NAS as being reachable via the
 NAS vs those that are installed to point to the client. Using one
 attribute, eg Framed-IPv6-Route, for both appears to be more than an
 implementation question. It's about the intended semantics IMO.

 How about this as new text?

         be used to inform a host connected to the NAS that a specific
 route
         is reachable via the NAS. This is particularly desirable in cases
         where the RG or host are multi-homed to different NASes as shown
 in
         Figure 1.

         This document specifies the RADIUS attribute that allows the AAA
         system to provision the announcement by the NAS to an accessing
 host. The NAS may advertise this route using the method defined in
 [RFC4191] or using other equivalent
         methods.

         The distinction and separation between this attribute and the
 Framed-
         IPv6-Route attribute defined in [RFC3633] is needed due to the
 need
         to have the information carried by this attribute advertised to an
         attaching client.

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