RE: Review of draft-ietf-radext-vlan-02.txt

["Congdon, Paul T (ProCurve)" <paul.congdon@hp.com>]

> 
> BTW, I just thought of another issue.  If not careful, it is 
> quite possible for the administrator to cause considerable 
> chaos with these attributes.  
> For example, it would be possible to configure multiple 
> untagged Egress-VLANIDs or Egress-VLAN-Name attributes, 
> effectively connecting multiple broadcast domains together.
> 
> I am thinking that it should only be possible to send at most 
> a single Untagged Egress-VLANID, or Egress-VLAN-Name 
> attribute in an Access-Accept, which makes me wonder whether 
> there shouldn't be two separate attributes for 
> Tagged-Egress-VLANID/Name (0+) and Untagged-Egress-VLANID/Name (0-1).
> 

I don't think you can or should define this type of restriction.  It is
completely valid behavior to allow multiple untagged VLANs on egress in
a standard 802.1Q bridge.  There are certain features (e.g. private
VLANs) that would like to have this type of configuration enabled.  When
'ingress filters' are enabled, this is prohibited, so there are ways to
avoid the concern you have without forcing the use of Radius to be
incompatible with the 802.1Q standard.

Paul

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