NAS-Port-Type and sub-types?

[Bernard Aboba <bernard_aboba@hotmail.com>]

As a result of the IANA allocation request for a NAS-Port-Type for XPON (which was approved, based on the RADEXT mailing list discussion), we got some feedback from IEEE 802, enclosed below. 
 
Some questions raised by the feedback include:
 
a. What is a NAS-Port-Type anyway?  My understanding is that this attribute is mostly used to enable the RADIUS server to execute link-specific policy (e.g. If NAS-Port-Type="IEEE 802.11" Then Profile = "" So my answer is that it represents link type information that a RADIUS server administrator will find useful. 
 
b. What is the appropriate granularity for NAS-Port-Type?  In some cases, values are more granular than a link type (e.g. 3 values for ISDN), in others a single value applies to multiple link technologies (e.g. Wireless -- Other).
 
c. How should we handle new IEEE 802 technologies going forward?  IEEE 802 is not only creating new link technologies (e.g. IEEE 802.16, 802.20, etc.) they are also developing new authentication schemes within those technologies (e.g. IEEE 802.11r, IEEE 802.1af, etc.).   So how does a NAS indicate that an Access-Request is for IEEE 802.11s or IEEE 802.11r rather than just IEEE 802.11, or IEEE 802.1af, rather than IEEE 802.3/IEEE 802.1X-2004?  Allocating a NAS-Port-Type value does not seem like a good fit for that kind of differentiation. 
 
> -----Original Message-----
> From: Glen Kramer [mailto:glen.kramer@teknovus.com] 
> Sent: Wednesday, June 13, 2007 5:04 PM
> To: Pat Thaler
> Cc: Congdon, Paul T (ProCurve); Grow, Bob; David Law; Steve Carlson;
> Wael Diab
> Subject: RE: [802.1 - 2683] FW: [IANA #85318] request a new
> NAS-Port-Type for XPON
> 
> Pat,
> 
> Is this a formal liaison request? .3av focuses on PHY and I am not sure
> we have the right expertise in our group to answer this. I think MacSec
> may be a better place to get a meaningful response.
> 
> Unofficially, I asked an engineer in my company for his opinion. Here it
> is:
> 
> ***
> This field isn't really a functional part of the protocol. It's just
> management information. In a RADIUS access request, there is a "port
> type" field that says "I'm a DSL port" or "I'm a cable port" or "I'm a
> PON port". This has nothing to do with the actual authentication, and
> I'm not even sure why a RADIUS server would care in the first place.
> But given that there's a list of 34 possible port types, it makes sense
> to add one (or more) for PON. 
> 
> It may be that people will want to distinguish various types of PON.
> There's a bunch of ADSL port types (DMT, CAP, etc) in addition to a
> generic xDSL port type. But we can start with xPON and see if people
> really want to know that it's specifically EPON or GEPON or whatever.
> 
> It's not clear what the NAS port number would be. The protocol defines
> a port value as a 32-bit field. This isn't big enough for a MAC
> address. But since the logical links are virtual and dynamically
> assigned, it doesn't make lots of sense to me to report a link as either
> "link index 12" or "LLID 13". Those values will just be different after
> the next reset; so, there's nothing useful you can provision or check on
> the server side; so, it doesn't really matter what the value is, so
> there's no point in having a value in the first place. (Note that there
> is a NAS-Port-Type of "virtual", which is intended for virtual ports
> multiplexed over some transport medium. Perhaps it's enough to realize
> that port type "xPON" means that the port number won't have lasting
> value.)
> ***
> 
> Let me know, if anything is required from .3av in this regard.
> 
> Glen
 
> From: EffenbergerFrank 73695 [mailto:feffenberger@huawei.com]
> Sent: Wednesday, June 13, 2007 11:23 AM
> To: Linda Dunbar
> Subject: Re: FW: [802.1 - 2683] FW: [IANA #85318] request a new
> NAS-Port-Type for XPON
> 
> If I look up the currently defined list of values for NAS-port-type, I
> find:
> 
> Values for RADIUS Attribute 61, NAS-Port-Type [RFC2865]:
> 
> 0 Async
> 1 Sync
> 2 ISDN Sync
> 3 ISDN Async V.120
> 4 ISDN Async V.110
> 5 Virtual
> 6 PIAFS
> 7 HDLC Clear Channel
> 8 X.25
> 9 X.75
> 10 G.3 Fax
> 11 SDSL - Symmetric DSL
> 12 ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase
> Modulation
> 13 ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone
> 14 IDSL - ISDN Digital Subscriber Line
> 15 Ethernet
> 16 xDSL - Digital Subscriber Line of unknown type
> 17 Cable
> 18 Wireless - Other
> 19 Wireless - IEEE 802.11
> 20 Token-Ring [RFC3580]
> 21 FDDI [RFC3580]
> 22 Wireless - CDMA2000 [McCann]
> 23 Wireless - UMTS [McCann]
> 24 Wireless - 1X-EV [McCann]
> 25 IAPP [IEEE 802.11f][Kerry]
> 26 FTTP - Fiber to the Premises [Nyce]
> 27 Wireless - IEEE 802.16 [IEEE 802.16]
> 28 Wireless - IEEE 802.20 [IEEE 802.20]
> 29 Wireless - IEEE 802.22 [IEEE 802.22] 
> 30 PPPoA - PPP over ATM [RFC4603]
> 31 PPPoEoA - PPP over Ethernet over ATM [RFC4603]
> 32 PPPoEoE - PPP over Ethernet over Ethernet [RFC4603]
> 33 PPPoEoVLAN - PPP over Ethernet over VLAN [RFC4603]
> 34 PPPoEoQinQ - PPP over Ethernet over IEEE 802.1QinQ [RFC4603]
> 
> Bottom-line - it appears that they have been handing out these values
> with very little care for doing a clean job. I'm not sure what use this
> information is even put to... 
> 
> You might mention that observation, and ask for some more clarification.
> 
> 
> Sincerely,
> Frank E.