摘要
该文档定义了一组Radius属性，用于支持拨号网络中的强制隧道。
1、目的（Motivation）
许多隧道协议的应用，例如L2TP,都包括拨号网络接入。一部分被定义为非强制隧道，例如通过
Internet提供安全接入到企业网：只有用户申请后才被创建。另外一部分是强制隧道：
隧道直接被创建，不用用户的任何动作，也不用用户做任何选择。为了提供这种功能，
需要定义一些用于从RADIUS服务器传送隧道信息到隧道另一端的新的RADIUS属性。
该文档定义了这些属性。有关这些用于L2TP属性的更具体的描述请参考RFC2809。
2、要求规范
Inthisdocument,thekeyWords"MAY","MUST,"MUSTNOT","optional",
"recommended","SHOULD",and"SHOULDNOT",aretobeinterpretedas
describedin[14].
3、属性
下面定义的每个属性有可能在同一个RADIUS报文中被包含多次。在这种情况下，它们各自属性
中Tag域的值必需相同。否则，就不要使用Tag域。
假如RADIUS服务器返回的属性中描述了多条隧道，则隧道的创建者会把它解释成可选择的。
服务器应该在每组隧道属性集合中包含一个Tunnel-Preference属性。 同样，假如客户端
在Access-Request报文中包含了多组隧道属性集合，则所有属于同一隧道的属性的Tag域
的值应该相同，并且每组属性集合应该包含一个带有合适值的Tunnel-Preference属性。
3.1.Tunnel-Type
描述
该属性描述了将被使用的隧道协议（隧道创建者[tunnelinitiator]）或者是已经被使用的
隧道协议（隧道终结者[tunnelterminator]）。该属性可以被包含在Access-Request,
Access-Accept和Accounting-Request报文中。假如该属性是被包含在隧道创建者发送
的Access-Request报文中，则是暗示RADIUS服务器隧道终点（thetunnelend-point)
所能支持的隧道协议；但是，RADIUS服务器可以忽视这个。隧道创建者并不要求实现所有的隧
道类型。假如隧道创建者收到的一个Access-Accept报文中包含了不知道或者是不支持的隧道
类型，则它按照收到一个Access-Reject报文处理。
假如一个隧道终结者发送的Access-Request报文中包含了Tunnel-Type属性，则该属性应该
是表示当前正在使用的隧道协议。这中情况下，假如RADIUS服务器认为该协议没有被授权，
它会返回一个Access-Reject报。假如一个隧道终结者收到包含有一个或者是多个
Tunnel-Type属性的Access-Accept报文，但是其中任何一种类型都没有被使用，则隧道
终结者必需按照收到一个Access-Reject报文处理。
该报文的结构如下：
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TypeLengthTagValue
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value(cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
64
Length
6
Tag
该域长度是一个字节，用于组织属于同一隧道的一组属性，其取值范围从0x01
到0x1f，包括0x01和0x1f。假如没有使用该域，则必需填0。
Value
该域长度是三个字节，用于指定隧道类型，其取值如下：
1Point-to-PointTunnelingProtocol(PPTP)[1]
2LayerTwoForwarding(L2F)[2]
3LayerTwoTunnelingProtocol(L2TP)[3]
4AscendTunnelManagementProtocol(ATMP)[4]
5VirtualTunnelingProtocol(VTP)
6IPAuthenticationHeaderintheTunnel-mode(AH)[5]
7IP-in-IPEncapsulation(IP-IP)[6]
8MinimalIP-in-IPEncapsulation(MIN-IP-IP)[7]
9IPEncapsulatingSecurityPayloadintheTunnel-mode(ESP)[8]
10GenericRouteEncapsulation(GRE)[9]
11BayDialVirtualServices(DVS)
12IP-in-IPTunneling[10]
3.2.Tunnel-Medium-Type
描述
隧道协议（例如L2TP）能运行在多种传输媒体（transportmedium）上，
Tunnel-Medium-Type属性指示创建隧道时用的是哪一种传输媒体。该属性可以
包含在Access-Request或者是Access-Accept报文中。假如它出现在
Access-Request报文中，则用于提示RADIUS服务器隧道终点所支持的
隧道媒体类型。RADIUS服务器也可以忽略这个提示。
该属性的报文结构如下：
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TypeLengthTagValue
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value(cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
65
Length
6
Tag
该域长度是一个字节，用于组织属于同一隧道的一组属性，其取值范围从0x01
到0x1f，包括0x01和0x1f。假如没有使用该域，则必需填0。
Value
该域长度是3个字节，其取值范围在参考文档[14]中的"AddressFamilyNumber"
列表下。下面是关于该列表的一个摘要：
1IPv4(IPversion4)
2IPv6(IPversion6)
3NSAP
4HDLC(8-bitmultidrop)
5BBN1822
6802(includesall802mediaplusEthernet"canonicalformat")
7E.163(POTS)
8E.164(SMDS,FrameRelay,ATM)
9F.69(Telex)
10X.121(X.25,FrameRelay)
11IPX
12Appletalk
13DecnetIV
14BanyanVines
15E.164withNSAPformatsubaddress
3.3.Tunnel-Client-Endpoint
描述
该属性包含了创建端的地址。它可以被包含在Access-Request和Access-Accept报文中，
用于指示要创建隧道的对端的地址。假如Tunnel-Client-Endpoint属性假如出现在
Access-Request报文中，RADIUS服务器可以将它看做一个暗示，但是也可以忽略它。
该属性应该被包含在一个带有Acct-Status-Type属性的Accounting-Request的报文中，
其中，Acct-Status-Type的取值可以是Start或者是Stop。这种情况下，Tunnel-Client-Endpoint
属性要创建隧道的对端地址。Tunnel-Client-Endpoint、Tunnel-Server-Endpoint和
Acct-Tunnel-Connection-ID能提供一种唯一的用于标识隧道的方法，可用于记费和查账。
该属性的报文结构如下：
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TypeLengthTagString...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
66
Length
>=3
Tag
该域长度是一个字节，用于组织属于同一隧道的一组属性，假如该域的值大于0x00，
且小于或者等于0x1F，则被解释成指示该属性所属的隧道。假如该域的值大于0x1F，
则被解释成String域的第一个字节。
String
该域的值的格式决定于Tunnel-Medium-Type属性的取值。
假如Tunnel-Medius-Type的值是IPv4(1),该域可以是隧道客户端机器的完整域名
（FQDN），或者是IP地址（点分十进制形式）。实现要求一定要（MUST）实现点分十进制形式，
建议（SHOULD）也实现FQDN格式。
假如Tunnel-Medius-Type的值是IPv6(2)，该域可以是FQDN格式，或者是用字符串形式表现
的优先的或者是可选的地址〔17〕。实现要求一定要（MUST）支持优先格式的地址，建议（SHOULE）
实现可选格式的或者是FQDN格式的地址。、
假如Tunnel-Medium-Type既不是IPv4，也不是IPv6，该域指出本地RADIUS客户端的关于接口
和媒体特有的地址的配置数据。
3.4.Tunnel-Server-Endpoint
描述
该属性描述的是隧道服务器端的地址。该属性可以被包含在Access-Request报文中。假如希望建立一个
隧道，则在Access-Request报文中一定要包含该属性。假如一个Accounting-Request报文带有值是
Start或者是Stop的Acct-Status-Type的属性，且该报文属于一个隧道会话(tunnelsession)，则
该报文也应该包含Tunnel-Server-Endpoint属性。Tunnel-Client-Endpoint、Tunnel-Server-Endpoint
和Acct-Tunnel-Connection-ID能提供一种唯一的用于标识隧道的方法，可用于记费和查账。
该属性的报文结构如下：
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TypeLengthTagString...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
67
Length
>=3
Tag
该域长度是一个字节，用于组织属于同一隧道的一组属性，假如该域的值大于0x00，
且小于或者等于0x1F，则被解释成指示该属性所属的隧道。假如该域的值大于0x1F，
则被解释成String域的第一个字节。
String
该域的值的格式决定于Tunnel-Medium-Type属性的取值。
假如Tunnel-Medius-Type的值是IPv4(1),该域可以是隧道客户端机器的完整域名
（FQDN），或者是IP地址（点分十进制形式）。实现要求一定要（MUST）实现点分十进制形式，
建议（SHOULD）也实现FQDN格式。
假如Tunnel-Medius-Type的值是IPv6(2)，该域可以是FQDN格式，或者是用字符串形式表现
的优先的或者是可选的地址〔17〕。实现要求一定要（MUST）支持优先格式的地址，建议（SHOULE）
实现可选格式的或者是FQDN格式的地址。、
假如Tunnel-Medium-Type既不是IPv4，也不是IPv6，该域指出本地RADIUS客户端的关于接口
和媒体特有的地址的配置数据。
3.5.Tunnel-Password
描述
该属性包含一个用于到远端服务器上去认证的密码。它可以被包含在Access-Accept报文中。
该属性的报文结构如下：
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TypeLengthTagSalt
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Salt(cont)String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
69
Length
>=5
Tag
该域长度是一个字节，用于组织属于同一隧道的一组属性。其有效值范围从0x01
到0x0f,包含0x01和0x0F。假如该域的值是0x00到0x0F之间，包含0x0F，它
应该被解释成指示该属性所属的隧道，否则，该域被忽略。
Salt
Salt域是两个字节长度，用于确保在一个Access-Accept报文中用于给Tunnel-Password
加密的密钥的唯一性。该域最重要的一位（最左边的）必需被设置（1）。在一个
Access-Accept报文中，每个salt域的内容必需是唯一的。
String
该明文字符串由三个逻辑子域组成：Data-Length子域、Password子域（这两个是必需的），
以及一个可选的Padding子域。Data-Length子域的长度是一个自己，包含Password
子域的长度。Password子域包含实际的隧道密码。假如Data-Length域和Password域的
总长度不是16的整数倍，就在后面添加Padding子域。该域的长度是可变的，从1到15（字节）。
String必需按照如下方式加密，优先传输：
通过连接Data-Length和Password子域，给String域构造一个明文，假如需要的
话，用填充字符给该明文加长到16的整数倍。推荐用ox00作为填充字符。我们
把该明文叫做P。
报共享密钥叫做S，随机产生的128－bit的Request-Authenticator(在对应的
Access-Request报文中)叫做R，Salt域的内容叫做A。将P按照16个字节划分
成p(1),p(2),...p(i)(i=p的长度/16)。把密码块叫做c(1)、c(2)...c(i),
最终的密码叫做C。还需要中间值b(1)、b(2)...c(i)。按照如下方式加密（'+'
表示串联）
b(1)=MD5(S+R+A)c(1)=p(1)xorb(1)C=c(1)
b(2)=MD5(S+c(1))c(2)=p(2)xorb(2)C=C+c(2)
..
..
..
b(i)=MD5(S+c(i-1))c(i)=p(i)xorb(i)C=C+c(i)
最终的密码包括c(1)+c(2)+...+c(i)。
接收端按照相反的过程处理得到明文。
3.6.Tunnel-Private-Group-ID
描述
该属性指示一个特定的隧道会话的group-ID。假如一个隧道创建者能从一个特定
的连接中确定组的结果(thegroupresulting),则该属性可以包含在Access-Request报文中，
假如这个将被创建的隧道会话属于一个特定的私有组，则Access-Accept报文中应该包含
该属性。 使用组可以用来将一个隧道会话和一组特定用户相关联。例如，它会用于通过一个特定的
接口路由一个没有注册的IP地址。假如一个Accounting-Request报文包含Acct-Status-Type
属性（该属性的值是Start或者Stop)，且属于一个隧道会话，则该报文应该包含
Tunnel-Private-Group-ID属性。
该报文的结果如下：
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TypeLengthTagString...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
81
Length
3
Tag
该域长度是一个字节，用于组织属于同一隧道的一组属性，假如该域的值大于0x00，
且小于或者等于0x1F，则被解释成指示该属性所属的隧道。假如该域的值大于0x1F，
则被解释成String域的第一个字节。
String
该域是必需的，代表特定的组。关于它的格式没有特定的限制。
3.7.Tunnel-Assignment-ID
描述
该属性用来将一个将被分配会话的特定隧道告诉隧道创建者。一些隧道协议，象L2TP、
PPTP，答应会话通过相同的隧道在两个相同的隧道终端之间被复用。该属性给RADIUS
提供了一种可以用于通知隧道创建者（e.g.PAC、LAC）将会话分配给可复用隧道还是
专用隧道（aseparatetunnel）的方法。而且，也答应将共享复用隧道的会话分配
给不同的复用隧道。 一个特定的实现可以将不同的特性分配给特定的隧道。例如，不同
的隧道被赋予不同的 QOS参数。这样的隧道可以用来承载单个或者是多个会话。
Tunnel-Assignment-ID属性还答应RADIUS服务器指示一个特定的会话被分配给一个
提供合适等级服务的隧道。希望将来定义的用于隧道的且与QOS相关的RADIUS属性都能
通过该属性给出的ID相关联。同时，任何有关特定ID串的含义留给隧道创建者的本地
配置处理。
该属性可以被包含在Access-Accept报文中。隧道创建者收到该属性后，可以忽视它，
将会话安排到两者之间的任意一个复用或者是专用隧道。假如一个Accounting-Request
报文包含Acct-Status-Type 属性（该属性的值是Start或者Stop)，且属于一个隧道会
话，则该报文应该包含该属性。
假如一个隧道创建者支持Tunnel-Assignment-ID属性，那他需要按照如下的方式将
一个会话分配给隧道：
假如在与一个ID指定的终端之间，该属性和隧道都已经存在，那么这个会话被
分配给该隧道。
假如在与一个ID指定的终端之间，该属性已经存在，但是没有隧道，那么将会为
该会话建立一个隧道，并且一个ID被分配给该隧道。
假如该属性不存在，这该会话被分配到一个未命名的隧道。假如该隧道还没有建立，
那么建立该隧道，并且用于该会话以及后面没有Tunnel-Assignment-ID属性的
会话。一个隧道创建者不能将一个没有Tunnel-Assignment-ID属性的会话分配
给一个命名隧道（例如一个由具有该属性的会话创建的隧道）。
注重不同的终端之间的隧道可能具有相同的ID。
该报文的结构如下：
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TypeLengthTagString...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
82
Length
>=3
Tag
该域长度是一个字节，用于组织属于同一隧道的一组属性，假如该域的值大于0x00，
且小于或者等于0x1F，则被解释成指示该属性所属的隧道。假如该域的值大于0x1F，
则被解释成String域的第一个字节。
String
该域是必需的，代表隧道ID。对于该ID的格式没有任何限制。
3.8.Tunnel-Preference
描述
假如RADIUS服务器返回多组隧道属性，则应当在每组属性中包含该属性，用于指示
分配给每个隧道的相对参数（relativepreference）。例如，假设服务器返回
两条隧道的属性，其中一条隧道是PPTP类型的，另一种是L2TP类型的。假如隧道
创建者只支持其中的一种，那么它就只创建该种类型的隧道。假如这两种类型的隧道
它都支持，那么它根据Tunnel-Preference属性来决定创建哪种类型的隧道。
假如该属性的取值越低，那么其被创建的优先级越高。假如在某个Access-Accept
报文中几个Tunnel-Preference的取值相等，那么隧道的创建者要根据本地的配置
来决定该使用哪组属性来创建隧道。该属性也可以被包含在Access-Request报文中，
用于给服务器一个提示，但是服务器可以忽略这个提示。
该属性的报文结构如下：
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TypeLengthTagValue
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value(cont)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
83
Length
6
Tag
该域长度是一个字节，用于组织属于同一隧道的一组属性，其取值范围从0x01
到0x1f，包括0x01和0x1f。假如没有使用该域，则必需填0。
Value
该属性长度是三个字节，用于指示该属性所属的隧道的优先级，优先级越高，
则该属性的取值越低。0x000000具有最高优先级，0xFFFFFF具有最低优先级。
3.9.Tunnel-Client-Auth-ID
描述
建立隧道时，在认证阶段，该属性代表隧道创建者的名字。Tunnel-Client-Auth-ID
可以作为给服务其一个提示而被包含在Access-Request报文中，假如希望得到
一个不同于缺省的认证名，则该属性必需被包含在Access-Accept报文中。假如
一个Accounting-Request报文包含Acct-Status-Type属性（该属性的值是
Start或者Stop)，且属于一个隧道会话，则该报文应该包含该属性。
该属性的报文结构如下：
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TypeLengthTagString...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
90
Length
>=3
Tag
该域长度是一个字节，用于组织属于同一隧道的一组属性，假如该域的值大于0x00，
且小于或者等于0x1F，则被解释成指示该属性所属的隧道。假如该域的值大于0x1F，
则被解释成String域的第一个字节。
String
该域是必需的。它包含了隧道创建者用于认证的认证名。建议该认证名的格式用UTF-8。
3.10.Tunnel-Server-Auth-ID
描述
建立隧道时，在认证阶段，该属性代表隧道终结者的名字。Tunnel-Client-Auth-ID
可以作为给服务其一个提示而被包含在Access-Request报文中，假如希望得到
一个不同于缺省的认证名，则该属性必需被包含在Access-Accept报文中。假如
一个Accounting-Request报文包含Acct-Status-Type属性（该属性的值是
Start或者Stop)，且属于一个隧道会话，则该报文应该包含该属性。
该报文的结构如下：
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TypeLengthTagString...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
91
Length
>=3
Tag
该域长度是一个字节，用于组织属于同一隧道的一组属性，假如该域的值大于0x00，
且小于或者等于0x1F，则被解释成指示该属性所属的隧道。假如该域的值大于0x1F，
则被解释成String域的第一个字节。
String
该域是必需的。它包含了隧道终结者用于认证的认证名。建议该认证名的格式用UTF-8。
4.属性列表
下面的列表表示了上面的属性能被包含在那些属性中，以及在该报文中能出现的次数。
RequestAcceptRejectChallengeAcct-Request#Attribute
0+0+000-164Tunnel-Type
0+0+000-165Tunnel-Medium-Type
0+0+000-166Tunnel-Client-Endpoint
0+0+000-167Tunnel-Server-Endpoint
00+00069Tunnel-Password
0+0+000-181Tunnel-Private-Group-ID
00+000-182Tunnel-Assignment-ID
0+0+00083Tunnel-Preference
0+0+000-190Tunnel-Client-Auth-ID
0+0+000-191Tunnel-Server-Auth-ID
5.安全因素
Tunnel-Password属性有可能包含一些只有隧道端点才能知道的信息，但是现在用于隐藏该属性的值
的方法会使得中间的RADIUS代理也知道其中的内容。由于这个原因，Tunne-Password属性不应该
被包含在Access-Accept报文中，因为该报文有可能通过一个不可信任的RADIUS代理。另外，
Tunnel-Password属性不应该被返回到一个没有认证的终端；假如对应的Access-Request报文没有
包含一个能被证实的签名属性[15],则Access-Accept报文中就不应该包含Tunnel-Password属性。
隧道协议提供从没有安全保护（如PPTP）到最强的安全保护（如IPSec）等不同的安全等级。但是，
需要注重的是，在强制隧道中，任何安全措施只应用于隧道端点之间的传输。非凡是终端用户不应该依
赖隧道的安全性来保护它们自己的数据。隧道传输的加密保护不能替代点到点之间的安全。
6.IANA考虑事项
该文档定义了一系列有IANA维护的魔术数（magicnumber）。这一节解释了IANA分配这些数字的标准。
下面的每个子节解释了关于在本文档其它地方定义的名字空间的分配原则。
6.1.Tunnel-Type属性值
Tunnel-Type属性的的取值1-12已经在5.1节定义。剩下的值有IANA根据IETF的意见分配[16]。
6.2.Tunnel-Medium-Type属性值
Tunnel-Medium-Type属性的取值1-15已经在5.2定义。剩下的值有IANA根据IETF的意见分配[16]。
7.参考
[1]Hamzeh,K.,Pall,G.,Verthein,W.,Taarud,J.,Little,W.and
G.Zorn,"Point-to-PointTunnelingProtocol(PPTP)",RFC2637,
July1999.
[2]Valencia,A.,Littlewood,M.andT.Kolar,T.,"CiscoLayerTwo
Forwarding(Protocol)'L2F'",RFC2341,May1998.
[3]Townsley,W.,Valencia,A.,Rubens,A.,Pall,G.,Zorn,G.and
B.Palter,"LayerTwoTunnellingProtocol(L2TP)",RFC2661,
August1999.
[4]Hamzeh,K.,"AscendTunnelManagementProtocol-ATMP",RFC
2107,February1997.
[5]Kent,S.andR.Atkinson,"SecurityArchitectureforthe
InternetProtocol",RFC2401,November1998.
[6]Perkins,C.,"IPEncapsulationwithinIP",RFC2003,October
1996.
[7]Perkins,C.,"MinimalEncapsulationwithinIP",RFC2004,
October1996.
[8]Atkinson,R.,"IPEncapsulatingSecurityPayload(ESP)",RFC
1827,August1995.
[9]Hanks,S.,Li,T.,Farinacci,D.andP.Traina,"GenericRouting
Encapsulation(GRE)",RFC1701,October1994.
[10]Simpson,W.,"IPinIPTunneling",RFC1853,October1995.
[11]Zorn,G.andD.Mitton,"RADIUSAccountingModificationsfor
TunnelProtocolSupport",RFC2867,June2000.
[12]Rigney,C.,Willens,S.,Rubens,A.andW.Simpson,"Remote
AuthenticationDialinUserService(RADIUS)",RFC2865,June
2000.
[13]Bradner,S.,"KeywordsforuseinRFCstoIndicateRequirement
Levels",BCP14,RFC2119,March1997.
[14]Reynolds,J.andJ.Postel,"AssignedNumbers",STD2,RFC1700,
October1994.
[15]Rigney,C.,Willats,W.andP.Calhoun,"RADIUSExtensions",RFC
2869,June2000.
[16]Narten,T.andH.Alvestrand,"GuidelinesforwritinganIANA
ConsiderationsSectioninRFCs",BCP26,RFC2434,October1998.
[17]Hinden,R.andS.Deering,"IPVersion6Addressing
Architecture",RFC2373,July1998.
8.Acknowledgements
ThankstoDaveMittonforpointingoutanastycirculardependencyin
theoriginalTunnel-Passwordattributedefinitionand(inno
particularorder)toKoryHamzeh,BertrandBUClin,AndyValencia,
BillWestfield,KrisMichielsen,GurdeepSinghPall,RanAtkinson,
AydinEdguer,andBernardAbobaforusefulinputandreview.
9.Chair'sAddress
TheRADIUSWorkingGroupcanbecontactedviathecurrentchair:
CarlRigney
LivingstonEnterprises
4464WillowRoad
Pleasanton,California94588
Phone:+15104260770
EMail:cdr@livingston.com
10.Authors'Addresses
Questionsaboutthismemocanalsobedirectedto:
GlenZorn
CiscoSystems,Inc.
500108thAvenueN.E.,Suite500
Bellevue,Washington98004
USA
Phone:+14254388218
FAX:+14254381848
EMail:gwz@cisco.com
DoryLeifer
AscendCommunications
1678Broadway
AnnArbor,MI48105
Phone:+17347476152
EMail:leifer@del.com
JohnShriver
IntelCorporation
28CrosbyDrive
Bedford,MA01730
Phone:+17816871329
EMail:John.Shriver@intel.com
AllanRubens
AscendCommunications
1678Broadway
AnnArbor,MI48105
Phone:+13137616025
EMail:acr@del.com
MattHoldrege
ipVerse
223XimenoAve.
LongBeach,CA90803
EMail:matt@ipverse.com
IgnacioGoyret
LucentTechnologies
OneAscendPlaza
1701HarborBayParkway
Alameda,CA94502
Phone:+15107696001
EMail:igoyret@lucent.com
11.FullCopyrightStatement
Copyright(C)TheInternetSociety(2000).AllRightsReserved.
Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseeXPlainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.
Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.
Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.
