<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Background about RFC 3580's VLAN Assignment upon 802.1x Authentication in FAQs</title>
    <link>https://community.extremenetworks.com/t5/faqs/background-about-rfc-3580-s-vlan-assignment-upon-802-1x/m-p/42536#M114</link>
    <description>Article ID: 7312 &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Protocols/Features&lt;/B&gt;&lt;BR /&gt;
Radius&lt;BR /&gt;
Tunnel &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Standards&lt;/B&gt;&lt;BR /&gt;
RFC 3580&lt;BR /&gt;
RFC3580&lt;BR /&gt;
802.1x &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Symptoms&lt;/B&gt;&lt;BR /&gt;
"Tunnel-Type"&lt;BR /&gt;
"Tunnel-Medium-Type"&lt;BR /&gt;
"Tunnel-Private-Group-ID" &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Cause&lt;/B&gt;&lt;BR /&gt;
This article reproduces &lt;I&gt;only&lt;/I&gt; the Abstract and Tunnel Attributes sections of &lt;A href="http://www.ietf.org/rfc/rfc3580.txt" target="_blank" rel="nofollow noreferrer noopener"&gt;RFC3580&lt;/A&gt;, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines". &lt;BR /&gt;
&lt;BR /&gt;
The rationale is to provide background regarding what a growing number of Enterasys products are now supporting: the ability to VLAN-assign a 802.1x Supplicant (user) at the time of Authentication (&lt;A href="http://bit.ly/19LXsqz" target="_blank" rel="nofollow noreferrer noopener"&gt;5532&lt;/A&gt;). This is implemented by means of the following Radius Tunnel Attributes: Tunnel-Type=13 (VLAN), Tunnel-Medium-Type=6 (802), Tunnel-Private-Group-ID=&amp;lt;&lt;I&gt;VlanID&lt;/I&gt;&amp;gt;. &lt;BR /&gt;
&lt;BR /&gt;
Here is a list of these products as of June 14 2006:&lt;UL&gt; 
&lt;LI&gt;Matrix E1, firmware 3.05.09 and higher 
&lt;/LI&gt;&lt;LI&gt;Matrix N-Series (DFE), firmware 5.31.17 and higher 
&lt;/LI&gt;&lt;LI&gt;Matrix V2, firmware 2.5.1.1 and higher 
&lt;/LI&gt;&lt;LI&gt;RBT3K-xG (AP3000), firmware 2.1.1 and higher 
&lt;/LI&gt;&lt;LI&gt;SecureStack C2, firmware 3.02.30 and higher 
&lt;/LI&gt;&lt;LI&gt;SecureStack B2, firmware 1.01.25 and higher 
&lt;/LI&gt;&lt;LI&gt;SecureStack A2, firmware 1.01.20 and higher&lt;/LI&gt;&lt;/UL&gt;
To determine the degree of RFC 3580 support on a given hardware product, see that product's latest firmware release notes. &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Solution&lt;BR /&gt;
&lt;BR /&gt;
&lt;/B&gt;Abstract&lt;BR /&gt;
 &lt;BR /&gt;
   This document provides suggestions on Remote Authentication Dial In&lt;BR /&gt;
   User Service (RADIUS) usage by IEEE 802.1X Authenticators. The&lt;BR /&gt;
   material in this document is also included within a non-normative&lt;BR /&gt;
   Appendix within the IEEE 802.1X specification, and is being&lt;BR /&gt;
   presented as an IETF RFC for informational purposes.&lt;BR /&gt;
 &lt;BR /&gt;
3.31. Tunnel Attributes&lt;BR /&gt;
 &lt;BR /&gt;
   Reference [RFC2868] defines RADIUS tunnel attributes used for&lt;BR /&gt;
   authentication and authorization, and [RFC2867] defines tunnel&lt;BR /&gt;
   attributes used for accounting. Where the IEEE 802.1X Authenticator&lt;BR /&gt;
   supports tunneling, a compulsory tunnel may be set up for the&lt;BR /&gt;
   Supplicant as a result of the authentication.&lt;BR /&gt;
 &lt;BR /&gt;
   In particular, it may be desirable to allow a port to be placed&lt;BR /&gt;
   into a particular Virtual LAN (VLAN), defined in [IEEE8021Q], based&lt;BR /&gt;
   on the result of the authentication. This can be used, for example,&lt;BR /&gt;
   to allow a wireless host to remain on the same VLAN as it moves&lt;BR /&gt;
   within a campus network.&lt;BR /&gt;
 &lt;BR /&gt;
   The RADIUS server typically indicates the desired VLAN by including&lt;BR /&gt;
   tunnel attributes within the Access-Accept. However, the IEEE&lt;BR /&gt;
   802.1X Authenticator may also provide a hint as to the VLAN to be&lt;BR /&gt;
   assigned to the Supplicant by including Tunnel attributes within&lt;BR /&gt;
   the Access-Request.&lt;BR /&gt;
 &lt;BR /&gt;
   For use in VLAN assignment, the following tunnel attributes are&lt;BR /&gt;
   used:&lt;BR /&gt;
 &lt;BR /&gt;
   Tunnel-Type=VLAN (13)&lt;BR /&gt;
   Tunnel-Medium-Type=802&lt;BR /&gt;
   Tunnel-Private-Group-ID=VLANID&lt;BR /&gt;
 &lt;BR /&gt;
   Note that the VLANID is 12-bits, taking a value between 1 and 4094,&lt;BR /&gt;
   inclusive. Since the Tunnel-Private-Group-ID is of type String as&lt;BR /&gt;
   defined in [RFC2868], for use with IEEE 802.1X, the VLANID integer&lt;BR /&gt;
   value is encoded as a string.&lt;BR /&gt;
 &lt;BR /&gt;
   When Tunnel attributes are sent, it is necessary to fill in the Tag&lt;BR /&gt;
   field. As noted in [RFC2868], section 3.1:&lt;BR /&gt;
 &lt;BR /&gt;
      The Tag field is one octet in length and is intended to &lt;BR /&gt;
      provide a means of grouping attributes in the same packet&lt;BR /&gt;
      which refer to the same tunnel. Valid values for this field&lt;BR /&gt;
      are 0x01 through 0x1F, inclusive. If the Tag field is unused,&lt;BR /&gt;
      it MUST be zero (0x00).&lt;BR /&gt;
 &lt;BR /&gt;
   For use with Tunnel-Client-Endpoint, Tunnel-Server-Endpoint,&lt;BR /&gt;
   Tunnel-Private-Group-ID, Tunnel-Assignment-ID, Tunnel-Client-Auth-&lt;BR /&gt;
   ID or Tunnel-Server-Auth-ID attributes (but not Tunnel-Type,&lt;BR /&gt;
   Tunnel-Medium-Type, Tunnel-Password, or Tunnel-Preference), a tag&lt;BR /&gt;
   field of greater than 0x1F is interpreted as the first octet of the&lt;BR /&gt;
   following field.&lt;BR /&gt;
 &lt;BR /&gt;
   Unless alternative tunnel types are provided, (e.g. for IEEE 802.1X&lt;BR /&gt;
   Authenticators that may support tunneling but not VLANs), it is&lt;BR /&gt;
   only necessary for tunnel attributes to specify a single tunnel. As&lt;BR /&gt;
   a result, where it is only desired to specify the VLANID, the tag&lt;BR /&gt;
   field SHOULD be set to zero (0x00) in all tunnel attributes. Where&lt;BR /&gt;
   alternative tunnel types are to be provided, tag values between&lt;BR /&gt;
   0x01 and 0x1F SHOULD be chosen.&lt;BR /&gt;
 &lt;BR /&gt;
 See also: &lt;A href="http://www.ietf.org/rfc/rfc2868.txt" target="_blank" rel="nofollow noreferrer noopener"&gt;RFC2868&lt;/A&gt; and &lt;A href="http://www.ietf.org/rfc/rfc2867.txt" target="_blank" rel="nofollow noreferrer noopener"&gt;RFC2867&lt;/A&gt;.&lt;BR /&gt;</description>
    <pubDate>Fri, 22 Nov 2013 08:32:00 GMT</pubDate>
    <dc:creator>FAQ_User</dc:creator>
    <dc:date>2013-11-22T08:32:00Z</dc:date>
    <item>
      <title>Background about RFC 3580's VLAN Assignment upon 802.1x Authentication</title>
      <link>https://community.extremenetworks.com/t5/faqs/background-about-rfc-3580-s-vlan-assignment-upon-802-1x/m-p/42536#M114</link>
      <description>Article ID: 7312 &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Protocols/Features&lt;/B&gt;&lt;BR /&gt;
Radius&lt;BR /&gt;
Tunnel &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Standards&lt;/B&gt;&lt;BR /&gt;
RFC 3580&lt;BR /&gt;
RFC3580&lt;BR /&gt;
802.1x &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Symptoms&lt;/B&gt;&lt;BR /&gt;
"Tunnel-Type"&lt;BR /&gt;
"Tunnel-Medium-Type"&lt;BR /&gt;
"Tunnel-Private-Group-ID" &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Cause&lt;/B&gt;&lt;BR /&gt;
This article reproduces &lt;I&gt;only&lt;/I&gt; the Abstract and Tunnel Attributes sections of &lt;A href="http://www.ietf.org/rfc/rfc3580.txt" target="_blank" rel="nofollow noreferrer noopener"&gt;RFC3580&lt;/A&gt;, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines". &lt;BR /&gt;
&lt;BR /&gt;
The rationale is to provide background regarding what a growing number of Enterasys products are now supporting: the ability to VLAN-assign a 802.1x Supplicant (user) at the time of Authentication (&lt;A href="http://bit.ly/19LXsqz" target="_blank" rel="nofollow noreferrer noopener"&gt;5532&lt;/A&gt;). This is implemented by means of the following Radius Tunnel Attributes: Tunnel-Type=13 (VLAN), Tunnel-Medium-Type=6 (802), Tunnel-Private-Group-ID=&amp;lt;&lt;I&gt;VlanID&lt;/I&gt;&amp;gt;. &lt;BR /&gt;
&lt;BR /&gt;
Here is a list of these products as of June 14 2006:&lt;UL&gt; 
&lt;LI&gt;Matrix E1, firmware 3.05.09 and higher 
&lt;/LI&gt;&lt;LI&gt;Matrix N-Series (DFE), firmware 5.31.17 and higher 
&lt;/LI&gt;&lt;LI&gt;Matrix V2, firmware 2.5.1.1 and higher 
&lt;/LI&gt;&lt;LI&gt;RBT3K-xG (AP3000), firmware 2.1.1 and higher 
&lt;/LI&gt;&lt;LI&gt;SecureStack C2, firmware 3.02.30 and higher 
&lt;/LI&gt;&lt;LI&gt;SecureStack B2, firmware 1.01.25 and higher 
&lt;/LI&gt;&lt;LI&gt;SecureStack A2, firmware 1.01.20 and higher&lt;/LI&gt;&lt;/UL&gt;
To determine the degree of RFC 3580 support on a given hardware product, see that product's latest firmware release notes. &lt;BR /&gt;
&lt;BR /&gt;
&lt;B&gt;Solution&lt;BR /&gt;
&lt;BR /&gt;
&lt;/B&gt;Abstract&lt;BR /&gt;
 &lt;BR /&gt;
   This document provides suggestions on Remote Authentication Dial In&lt;BR /&gt;
   User Service (RADIUS) usage by IEEE 802.1X Authenticators. The&lt;BR /&gt;
   material in this document is also included within a non-normative&lt;BR /&gt;
   Appendix within the IEEE 802.1X specification, and is being&lt;BR /&gt;
   presented as an IETF RFC for informational purposes.&lt;BR /&gt;
 &lt;BR /&gt;
3.31. Tunnel Attributes&lt;BR /&gt;
 &lt;BR /&gt;
   Reference [RFC2868] defines RADIUS tunnel attributes used for&lt;BR /&gt;
   authentication and authorization, and [RFC2867] defines tunnel&lt;BR /&gt;
   attributes used for accounting. Where the IEEE 802.1X Authenticator&lt;BR /&gt;
   supports tunneling, a compulsory tunnel may be set up for the&lt;BR /&gt;
   Supplicant as a result of the authentication.&lt;BR /&gt;
 &lt;BR /&gt;
   In particular, it may be desirable to allow a port to be placed&lt;BR /&gt;
   into a particular Virtual LAN (VLAN), defined in [IEEE8021Q], based&lt;BR /&gt;
   on the result of the authentication. This can be used, for example,&lt;BR /&gt;
   to allow a wireless host to remain on the same VLAN as it moves&lt;BR /&gt;
   within a campus network.&lt;BR /&gt;
 &lt;BR /&gt;
   The RADIUS server typically indicates the desired VLAN by including&lt;BR /&gt;
   tunnel attributes within the Access-Accept. However, the IEEE&lt;BR /&gt;
   802.1X Authenticator may also provide a hint as to the VLAN to be&lt;BR /&gt;
   assigned to the Supplicant by including Tunnel attributes within&lt;BR /&gt;
   the Access-Request.&lt;BR /&gt;
 &lt;BR /&gt;
   For use in VLAN assignment, the following tunnel attributes are&lt;BR /&gt;
   used:&lt;BR /&gt;
 &lt;BR /&gt;
   Tunnel-Type=VLAN (13)&lt;BR /&gt;
   Tunnel-Medium-Type=802&lt;BR /&gt;
   Tunnel-Private-Group-ID=VLANID&lt;BR /&gt;
 &lt;BR /&gt;
   Note that the VLANID is 12-bits, taking a value between 1 and 4094,&lt;BR /&gt;
   inclusive. Since the Tunnel-Private-Group-ID is of type String as&lt;BR /&gt;
   defined in [RFC2868], for use with IEEE 802.1X, the VLANID integer&lt;BR /&gt;
   value is encoded as a string.&lt;BR /&gt;
 &lt;BR /&gt;
   When Tunnel attributes are sent, it is necessary to fill in the Tag&lt;BR /&gt;
   field. As noted in [RFC2868], section 3.1:&lt;BR /&gt;
 &lt;BR /&gt;
      The Tag field is one octet in length and is intended to &lt;BR /&gt;
      provide a means of grouping attributes in the same packet&lt;BR /&gt;
      which refer to the same tunnel. Valid values for this field&lt;BR /&gt;
      are 0x01 through 0x1F, inclusive. If the Tag field is unused,&lt;BR /&gt;
      it MUST be zero (0x00).&lt;BR /&gt;
 &lt;BR /&gt;
   For use with Tunnel-Client-Endpoint, Tunnel-Server-Endpoint,&lt;BR /&gt;
   Tunnel-Private-Group-ID, Tunnel-Assignment-ID, Tunnel-Client-Auth-&lt;BR /&gt;
   ID or Tunnel-Server-Auth-ID attributes (but not Tunnel-Type,&lt;BR /&gt;
   Tunnel-Medium-Type, Tunnel-Password, or Tunnel-Preference), a tag&lt;BR /&gt;
   field of greater than 0x1F is interpreted as the first octet of the&lt;BR /&gt;
   following field.&lt;BR /&gt;
 &lt;BR /&gt;
   Unless alternative tunnel types are provided, (e.g. for IEEE 802.1X&lt;BR /&gt;
   Authenticators that may support tunneling but not VLANs), it is&lt;BR /&gt;
   only necessary for tunnel attributes to specify a single tunnel. As&lt;BR /&gt;
   a result, where it is only desired to specify the VLANID, the tag&lt;BR /&gt;
   field SHOULD be set to zero (0x00) in all tunnel attributes. Where&lt;BR /&gt;
   alternative tunnel types are to be provided, tag values between&lt;BR /&gt;
   0x01 and 0x1F SHOULD be chosen.&lt;BR /&gt;
 &lt;BR /&gt;
 See also: &lt;A href="http://www.ietf.org/rfc/rfc2868.txt" target="_blank" rel="nofollow noreferrer noopener"&gt;RFC2868&lt;/A&gt; and &lt;A href="http://www.ietf.org/rfc/rfc2867.txt" target="_blank" rel="nofollow noreferrer noopener"&gt;RFC2867&lt;/A&gt;.&lt;BR /&gt;</description>
      <pubDate>Fri, 22 Nov 2013 08:32:00 GMT</pubDate>
      <guid>https://community.extremenetworks.com/t5/faqs/background-about-rfc-3580-s-vlan-assignment-upon-802-1x/m-p/42536#M114</guid>
      <dc:creator>FAQ_User</dc:creator>
      <dc:date>2013-11-22T08:32:00Z</dc:date>
    </item>
  </channel>
</rss>

