Re: [radext] #2: comments on draft-ietf-radext-ipv6-access-01

["radext issue tracker" <trac@tools.ietf.org>]

#2: comments on draft-ietf-radext-ipv6-access-01
-------------------------------------+--------------------------------------
 Reporter:  msmith@â                 |       Owner:  wdec@â        
     Type:  defect                   |      Status:  assigned      
 Priority:  major                    |   Milestone:  milestone1    
Component:  ipv6-access              |     Version:  1.0           
 Severity:  In WG Last Call          |    Keywords:                
-------------------------------------+--------------------------------------
Changes (by wdec@â):

  * status:  new => assigned


Comment:

 Sorry for not replying earlier, just came across this ticket...

 There are actually a number of issues pointed out, which I'll address one
 by one:

 1. Deployment Scenarios
 Partially accepted: Propose changing RG host to RG or host. In practically
 all deployments, the RG looks/talks like a host on its WAN interface, so
 the distinction is subtle (and one that continues to be discussed over).
 In terms of the diagram and terminology, while it may be BBF specific,
 there really is no other open standard architecture to refer to. So
 instead of coining new phrases, or adding options like AN or eQAM or
 Switch, etc, leaving things as they are would seem best.

 2. The existing use of prefix with IID is, as you also note, not very
 pretty. Furthermore it is specific to PPP (IPCPv6). In cases where say
 DHCPv6 is desired to be used for assigning the address, instead of
 splitting up the address between the two existing attributes, the new one
 can be used with a neater effect.

 3. Domain name
 This is a good point, but one that appears to be more general than IPv6
 attributes. I know of VSAs for the domain name, for precisely the purpose
 you give, and it's likely to be applicable to both v4 and v6. Do you see
 need for split domains?

 4. Adding a dhcp server address.
 This is an interesting proposal, but perhaps a bit too specific in terms
 of the set-up where it could be applicable. One of the drivers for this
 draft has been that some operators intend to use Radius to pass some of
 the key attributes to an embedded dhcpv6 server. In the scenario you
 describe, the NAS would effectively either use DHCPv6 to get some config
 for itself, or be a proxy for the client. One gets the impression that
 both of these mechanisms may need to be explored further with dhcpv6
 folks...

 5. What would be your proposal for encoding this without using a complex
 attribute? In some of the past draft iterations, we had pretty much all
 parameters allowed, but this was deemed to contravene existing radius
 practices, so we simplified to the bare minimum.
 Side note: I think that a route preference could very well be a default
 setting which does not need to be exposed via Radius.

 6. Yes, that's fine. We'll try to add it to the draft, unless someone
 objects.

 Thanks,
 Woj.

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


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