Last update: May 29, 2005
Lots of people are interested in wireless LAN security nowadays. Given that level of interest, there's a need for accurate information on how the current standards work, what's wrong with them, and the current thinking on how to fix the problems. This page tries to gather relevant papers and standards in a single place.
IEEE 802.1X "network Port Authentication" was designed to scale with Ethernet, adding no per-packet overhead, and bringing the management technology of dialup networks to the wired and wireless LAN worlds. Here are presentations on the current trends in Ethernet network access, both wired and wireless, and an introduction to IEEE 802.1X and its applications.
Ethernet
Everywhere!
Wireless World 2001 and
BAWUG Presentations on IEEE 802.1X
Here's a presentation on how we do authentication for network access and why this is most often handled at layer 2 (PPP, IEEE 802.1X) rather than at layer 1 (802.11) or at layer 3 (Mobile IP) or higher.
BURP BOF presentation at IETF 50
Here is where you can download 802.11 standards: IEEE 802.11 specifications
You've read all about the security problems with WEP. Here are the papers and presentations that lay out the problem.
War Driving Tools
A
summary presentation on WEP security issues (from 802.11 Tgi)
Berkeley WEP Security
Analysis Presentation (PDF)
Bill Arbaugh's paper on
cracking WEP (PDF)
Fluhrer, Mantin and
Shamir's paper on cracking WEP
Jesse Walker's "Unsafe at
any key length" paper
Possible ways of
improving WEP (near impossible)
Recently, there has been interest in wireless LAN performance. This includes work on MAC performance and capacity analysis, as well as interactions with TCP. Here are some presentations and papers on the subject:
PHY performance
Link-level
Measurements from an 802.11b Mesh Network
(Slides)
Link Adaptation Strategy for IEEE 802.11 WLAN via Received Signal Strength
Measurement
Measurements of a Wireless Link in an Industrial Environment
A Short Look at Power Save in 802.11
Characterizing Errors in Wireless LAN
802.11 Measurements
Project
MAC performance
802.11 Traffic
Characterization
Performance in an Ad-hoc Environment
Atheros White Paper on 802.11 performance
Performance
Anomaly of 802.11b (Powerpoint)
Performance Anomaly of
802.11b (PDF)
Resolving 802.11 Performance Anomaly
Capacity
analysis of 802.11
802.11
performance in a multi-hop network
Transport layer performance
Presentation on Transport
use of Layer 2 triggers by Sally Floyd (For IETF 55 TRIGTRAN BOF)
Performance
evaluation of TCP over 802.11
Performance of Reliable
Transport Protocols over 802.11
A number of elements contribute to 802.11 handoff delay including:
As shown by a recent University of Maryland paper, in an "open" network, Probe/Beacon delay is responsible for the majority of the measured delay. However, where Layer 2 authentication is used, authentication delay can also be substantial.
Protocols for communication between lightweight Access Points and WLAN switches are being standardized in the IETF CAPWAP WG. Here are some pointers:
CAPWAP WG mailing list archives
CAPWAP Architecture Taxonomy
CAPWAP Objectives
LWAPP Protocol (IETF Draft, Work in Progress)
Security Analysis of LWAPP
Inter-Access Point Protocol (IAPP) is being standardized by IEEE 802.11F as well as the IETF SEAMOBY WG. IAPP enables seamless, authenticated fast handoff between 802.11 Access Points. Here are some pointers:
IEEE
802.11F
IEEE
802.11 context transfer
Fast
Inter-AP Handoff Using Predictive Authentication Scheme in a Public Wireless
LAN
Proposal for
pre-emptive handoff support in IAPP (from University of Maryland)
SEAMOBY
Candidate Access Router Discovery protocol (IETF Draft, work in
progress)
SEAMOBY
Context Transfer Protocol (IETF Draft, work in progress)
Some suggested additions
to the IEEE 802.11F MIB
The WiFi Alliance (WFA) is now certifying an interim draft of the 802.11 security specification, known as Wi-fi Protected Access (WPA). There are also pre-WPA implementations in the market, some of which have known vulnerabilities. Here are the details of the WPA specification and the known security vulnerabilities:
Details on WPA can be found here:
WPA
Web Site (includes links to the specification)
Microsoft
WPA Support
NDIS WLAN
Objects
Details of WPA security vulnerabilities can be found here:
Issues with Pre-WPA implementationsThe IEEE 802.11i standard was approved in July, 2004. Here are pointers to the specification and its vulnerabilities:
IEEE
802.11i specification (Approved as an IEEE 802.11 Standard)
IEEE 802.11i Overview
NIST Security Workshop
Details of IEEE 802.11i security vulnerabilities can be found here:
One Message Attack on the 4-way HandshakeEAP is the IETF standard for extensible authentication in network access. It is standardized for use within PPP (RFC 2284), wired IEEE 802 networks (IEEE 802.1X), and VPNs (L2TP/IPsec and PIC). Here are pointers to information on the EAP protocol:
EAP (Proposed Standard,
RFC 3748)
EAP
Issues List
EAP
state machine (IETF draft, work in progress)
EAP WG mailing list
archives
How
to develop an EAP method for Windows
EAP methods provide keying material. Here are the documents describing EAP key management.
EAP
Key Management Framework (IETF draft, work in progress)
EAP Key Management Extensions (IETF draft, work in progress)
MPPE Key Derivation (Informational,
RFC3079)
Since EAP is extensible there are lots of proposals for authentication methods that work with it. Only some of these methods meet the requirements for use in wireless authentication; others have known security vulnerabilities. Here are the security requirements for EAP methods as laid out by IEEE 802.11i:
EAP method requirements (Informational, RFC 4017)Here are some of the proposed EAP methods:
EAP-TLS (Experimental, RFC 2716)
RSA
SecurID Token Card (IETF draft, work in progress)
Smartcard
EAP Method (IETF draft, work in progress)
PEAPv2
(IETF draft, work in progress) ; used with: EAP
MS-CHAP-v2 (IETF draft, work in progress)
EAP-FAST
(IETF draft, work in progress)
TLS Session Resumption for EAP-FAST (IETF draft, work in progress)
EAP-SRP
(IETF draft, work in progress)
Presentation
on EAP SRP
EAP
Archie (IETF draft, work in progress)
Presentation
on EAP Archie
EAP-PSK
(IETF draft, work in progress)
EAP-PAX (IETF draft, work in progress)
Here is a summary of the known security vulnerabilities of implemented or proposed EAP methods.
Kerberos is vulnerable to dictionary attacks. Here are the details on the vulnerability:
EAP-GSS (IETF draft, work in progress)Cisco's LEAP protocol is also vulnerable to dictionary attacks, and several LEAP cracking tools are now available. Here are the details on the vulnerability and cracking tools:
ASLEAP cracking toolThe security weaknesses in GSM/GPRS are well known. Recently there have been proposals for reuse of GSM (SIM) and 3G (AKA) security mechanisms in WLAN. Here are pointers to the specifications and papers describing how GSM/GPRS security can be cracked in real time. The attacks can be used against EAP-SIM where a single SIM is used for both WLAN and WWAN authentication:
EAP-SIM
Specification (IETF draft, work in progress)
Security Analysis of
EAP SIM
Instant
Ciphertext-only Cryptanalysis of GSM Encrypted Communication
Other GSM security
analyses
EAP
AKA (IETF draft, work in progress)
3GPP security (AKA)
Authentication protocols supporting cleartext authentication using RADIUS (even within a protected tunnel) are vulnerable to known plaintext attacks. IETF protocols vulnerable to this attack include:
IKEv2
EAP
TTLS (IETF draft, work in progress)
Here are the details of the vulnerability:
HTTP digest over TLS
XAUTH
within IKE
PIC
PANA over
TLS
EAP
TTLS (IETF draft, work in progress)
Microsoft Windows XP SP1
PEAPv0 Implemention
Cisco
PEAPv1 Implementation (IETF draft, work in progress).
Details of the attacks are described in these papers:
The
Compound Authentication Binding Problem (IETF draft, work in progress)
Man-in-the-Middle
Attacks in Tunneled Authentication Protocols (Nokia Research Center)
What's Wrong with PIC?
(Presentation to IETF 55 Credentials Workshop)
IEEE 802.1X is an IEEE standard (approved, June 2001) that enables authentication and key management for IEEE 802 Local Area Networks, including Ethernet, Token Ring, and FDDI. Since the IEEE 802.11 Task Group I security work had only just gotten underway at the time that the IEEE 802.1X standard was approved, 802.1X does not describe how the 802.1X and 802.11 state machines are to be coupled. That task was left to IEEE 802.11 Task Group I.
Since IEEE 802.1X is not a cipher, it is not an alternative to WEP, 3DES, AES, or any other cipher. Since IEEE 802.1X is only focused on authentication and key management, it does not specify how or when security services are to be delivered using the derived keys. However, it can be used to derive authentication and encryption keys for use with any cipher, and can also be used to periodically refresh keys and re-authenticate so as to make sure that the keying material is "fresh".
IEEE 802.1X is not a single authentication method; rather it utilizes Extensible Authentication Protocol (EAP) as its authentication framework. This means that 802.1X-enabled switches and access points can support a wide variety of authentication methods, including certificate-based authentication, smartcards, token cards, one-time passwords, etc. However, the 802.1X specification itself does not specify or mandate any authentication methods. Since switches and access points act as a "pass through" for EAP, new authentication methods can be added without the need to upgrade the switch or access point, by adding software on the host and backend authentication server.
Since IEEE 802.1X doesn't involve encapsulation (unlike PPPOE or VPN) it adds no per-packet overhead and can be implemented on existing switches and access points with no performance impact. This means that IEEE 802.1X can scale from speeds of 11 Mbps (802.11) to 10+ Gbps, and can be enabled on existing switches with a firmware upgrade, without the need to buy new hardware. On hosts, since IEEE 802.1X can be implemented in the NIC driver, support can be enabled by obtaining updating drivers from the NIC vendor; there is no need to install a new operating system.
IEEE 802.1X integrates well with open standards for authentication, authorization and accounting (including RADIUS and LDAP) and so it fits in well with existing infrastructure for managing dialup networks and VPNs. RADIUS servers (including Windows 2000 IAS) that support EAP can be used to manage IEEE 802.1X-based network access.
These specifications describe how IEEE 802.1X works, and how it can be managed via RADIUS and SNMP. Through RADIUS, IEEE 802.1X permits management of authorization on a per-user basis. Per-user services include filtering (layer 2 or layer 3), tunneling, dynamic VLANs, rate limits, etc.
IEEE
802.1X-2004 (Approved as an IEEE 802.1 Standard)
IEEE
802.1X-2004 MIB
IEEE 802.1X-2001 MIB
(IEEE 802 Standard)
IEEE
802.1X-2001 (IEEE 802 Standard)
Some thoughts on diagnosing
problems via the 802.1X MIB
IEEE 802/802.1X Architecture
Issues (Draft, work in progress)
IEEE 802 and IETF communicate regularly relating to IETF dependencies of IEEE 802 working groups. Here is some information relating to the liaison relationship:
IEEE
802/IETF Relationship History
IEEE 802
Archive Access for IETF WGs
Status of IEEE
802.11i/IETF Liaison (for the NIST 802.11 Security Workshop)
IEEE 802.11 Liaison
letter No. 1
IEEE 802.11 Liaison
letter No. 2
Erik Nordmark's
response to Liaison letter No. 2
IEEE 802.11
Draft Liaison letter No. 3 (not sent)
IEEE
802.11/IETF Liason Status Report (March 2003)
IEEE
802.11/IETF Liaison Status Report (May 2003)
IEEE 802.11/IETF Liaison
Status Report (September 2003)
IEEE 802 request for feedback
on IEEE 802.21 PAR (October 2003)
IEEE
802.11/IETF Liaison Status Report (January 2004)
IEEE 802/IETF Liaison
Meeting Summary (January 2004)
IEEE 802.1/IETF Liaison
Meeting Summary (January 2004)
IEEE
802.11/IETF Liaison Meeting Summary (January 2004)
IEEE
802.11/IETF Liaison Status Report (May 2004)
IEEE
802.11/IETF Liaison Status Report (July 2004)
IEEE 802.11/IETF Liaison Status Report (November 2004)
IEEE 802.11/IETF Liaison Status Report (January 2005)
IEEE
802.11/IETF Liaison Status Report (March 2005)
IEEE
802.11/IETF Liaison Status Report (May 2005)
3GPP liaison request to IEEE
802.11 on RADIUS/Diameter Coexistence (September 2003)
IEEE 802.11 Response to 3GPP
liaison request on RADIUS/Diameter Coexistence (September 2003)
IEEE 802.11 Liaison letter
No. 4 (February 2004)
GSMA Request to IETF relating
to RADIUS WLAN Support
WFA Request to IETF relating
to RADIUS WLAN Support
IEEE 802.11 Liaison Letter
relating to Network Discovery
Input to IETF from IEEE 802.11 WIEN (September 2004)
Input to IETF from IEEE 802.11 WIEN (November 2004)
Liaison to IETF from IEEE 802.11 and IEEE 802.21 (May 2005)
Liaison to IETF from
IEEE 802.16 (April 2005)
April 2005 Liaison Report
Minutes of the April 8, 2005 Liaison Conference Call
Liaison to IETF from IEEE 802.16 (May 2005)
RADIUS is a widely deployed protocol for network access authentication, authorization and accounting (AAA). There are many problems with it, including issues with security and transport, yet it is likely that RADIUS will continue to be widely used for many years to come. Why? RADIUS is simple, efficient and easy to implement -- making it possible for RADIUS to fit into the most inexpensive embedded devices.
The issues with transport are most relevant for accounting, in situations where services are billed according to usage. In these situations packet loss = revenue loss! RADIUS runs on UDP, with no defined retransmission or accounting record retension policy, and does not support application-layer acknowledgments or error messages (like "I'm busy, come back later" or "No disk space left"). This makes RADIUS accounting unreliable for usage-based billing services, particularly in inter-domain usage (such as roaming) where there can be substantial packet loss.
As a result, usage-based billing is often done with SNMP today. Although SNMP runs over UDP (a TCP transport mapping has been developed but is not deployed yet), the retry policy and polling interval can be configured on the management station, so that you are not at the mercy of the RADIUS retransmission and retension policy of a particular NAS vendor. To enable SNMP-based accounting for 802.11, as well as RADIUS accounting, we designed the IEEE 802.1X MIB to provide all the information available in RADIUS accounting within the MIB tables. The situation is better for RADIUS authentication and authorization, because if packet loss prevents users from being authenticated, they will typically try to get on again soon afterwards.
In terms of security, RADIUS includes its own application-layer integrity protection and authentication, as well as confidentiality for "hidden attributes". In RFC 2865, RADIUS Access Requests need not be authenticated and integrity protected; the situation was improved somewhat in RFC 2869, which requires that all messages involved in an EAP conversation include authentication and integrity protection via the Message-Authenticator attribute. As noted in the RADIUS security analysis, RADIUS security is particularly poor when dealing with cleartext passsword authentication (PAP). RFC 2865 requires that the RADIUS Response Authenticator be globally and temporally unique, since the stream cipher that RADIUS uses to encrypt User-Password is based on the Response Authenticator, and thus if it were to repeat, the keystream would be compromised. Unfortunately, not all implementations do a good job of ensuring that the Response Authenticator is not repeated.
Since the RADIUS Response Authenticator and Message-Authenticator attributes are both vulnerable to dictionary attack, it's a good idea to make sure your RADIUS shared secret has sufficient entropy and is not the same for multiple NASen. However, in real-life simple shared secrets shared with many NASen (or even all of them!) are common, and so this is probably the most serious RADIUS security vulnerability.
In terms of solutions, the best thing to do is to turn off PAP support on the NAS; that way the User-Password attribute will never be sent. Fortunately, EAP does not support PAP, and so RADIUS usage with IEEE 802.1X is not vulnerable to this particular class of attack. If possible, it is a good idea to use authentication methods that offer protection against an offline dictionary attack. These include EAP TLS (RFC 2716), EAP SRP and PEAP (both still under development), but not EAP GSS with Kerberos V, EAP MD5 or Cisco LEAP.
If the NAS can support IPsec, then the best thing to do is foresake RADIUS application-layer security entirely and just run RADIUS over IPsec ESP with a non-null transform. This is described in RFC 3162. Unfortunately, many embedded systems do not have the horsepower or headroom to run IPsec, so RADIUS/IPsec is not widely used today.
Microsoft RADIUS Attributes
(Informational, RFC 2548)
RADIUS authentication (Proposed
Standard, RFC 2865)
IETF RADIUS
WG Archives
RADIUS
accounting (Informational, RFC 2866)
RADIUS tunneling accounting
attributes (Informational, RFC 2867)
RADIUS tunneling authentication
attributes (Informational, RFC 2868)
RADIUS Extensions (Informational, RFC
2869)
RADIUS for IPv6
(Proposed Standard, RFC 3162)
RADIUS IANA Considerations (Proposed
Standard, RFC 3575)
RADIUS
Dynamic Authorization (Informational, RFC 3576)
RADIUS/EAP (Informational, RFC
3579)
Using RADIUS with
IEEE 802.1X (Informational, RFC 3580)
Additional
RADIUS attributes for IEEE 802.1X (IETF draft, work in progress)
RADIUS
security analysis
Dictionary Attack
Vulnerability
A
presentation on RADIUS security (IEEE 802.11i submission, discusses potential
solutions)
Introduction to
Accounting Management (Informational, RFC 2975, discusses issues with RADIUS
accounting)
Network access
requirements (Informational, RFC 2989, What a AAA protocol really needs to
do)
AAA protocol
evaluation (Informational, RFC 3127, How RADIUS fares against the
requirements)
AAA
Transport Specification (Proposed Standard, RFC 3539)
According to usage within GSM and IETF, "handoff" is movement of a mobile node between Access Points. "Roaming" is the movement of a mobile node between networks. This section provides references to documents on handoff and roaming.
Here are some papers relating to handoff in IEEE 802.1X-enabled networks:
Proactive
Key Distribution using Neighbor Graphs
Context Caching
using Neighor Graphs
Proactive
Key Distribution to Support Secure Roaming (submission to IEEE 802.11 Tgi)
RADIUS
handoff extension (IRTF draft, work in progress)
802.1X
pre-authentication and 802.11 (submission to IEEE 802.11 Tgi, Word
document)
802.1X
pre-authentication and 802.11 (submission to IEEE 802.11 Tgi,
Powerpoint)
Pre-Authenticated
Fast Handoff in a Wireless LAN Based on IEEE 802.1X Model
A
presentation on authenticating 802.11 management frames
Fast
Handoff Issues (IEEE 802.11i draft, work in progress)
PMK Plumbing
for fast roaming
PMK
Caching
PMK
Naming
Here are some papers relating to link-aware routing metrics:
Comparison of
Routing Metrics for Static Multi-Hop Wireless Networks
SrcRR: A High
Throughput Routing Protocol for 802.11 Mesh Networks
Architecture and
Evaluation of the MIT Roofnet Mesh Network
Effects of
Loss Rate on Adhc Wireless Routing
A Radio Aware
Routing Protocol for Wireless Mesh Networks
A High Throughput Path
Metric for Multi-Hop Wireless Routing
Here are some papers relating to handoff between media:
A
Generalized Model for Link Layer Triggers (Submission to IEEE 802.21, work in
progress)
Interactions
of IEEE 802.21 and Upper Layers (Submission to IEEE 802.21, work in
progress)
Trouble
with Triggers (Presentation at IETF 56 ALIAS BOF, work in progress)
Architectural
Implications of Link Indications (IETF draft, work in progress)
At layer 3, support for either handoff or roaming requires that mobile nodes efficiently detect network attachment. IEEE 802.11 does not support network attachment detection very well, and so this is trickier than it might seem at first glance. Here are some links describing the problem:
Detection of
Network Attachment (DNA) Mailing List
DNAv4 Issues Website
Optimistic
DAD (IETF draft, work in progress)
Detection
of Network Attachment for IPv6 (IETF draft BCP, work in progress)
Review of current movement
detection schemes for IPv6
Detection
of Network Attachment for IPv4 (IETF draft, work in progress)
Detection of
Network Attachment and IEEE 802.11 (IEEE 802 Handoff ECSG Presentation, work in
progress)
You've probably heard a lot about the "WHISPR" specification, which is being developed within WECA. Here are the references to open standards which describe how to do roaming and fast handoff within 802.11.
Roaming, defined as the ability to connect to multiple ISPs while maintaining an account with only one, was tackled by the IETF ROAMOPS WG starting in 1996 and solutions based on this architecture are now widely deployed. Since IEEE 802.1X is based on EAP, it is compatible with the ROAMOPS architecture as well as with existing RADIUS servers supporting RFC 2869 encapsulation of EAP in RADIUS.
One of the keys to roaming economics within 802.11 is enabling "shared use" APs. Shared use infrastructure has been widely deployed in dialup network access, allowing multiple ISPs to share the same points of presence. Enabling APs to be shared by multiple wireless ISPs offers to improve efficiency and improve the utilization of deployed APs. Shared use APs are particularly important for wireless because not only does it cost more to deploy multiple APs in the same location, but the limited radio channels in 802.11 makes radio interference a potential problem.
In order to keep the same IP address while roaming, there are approaches at layer 2 as well as layer 3. Mobile IP is the layer 3 approach. Of the layer 2 approaches, one is dynamic VLANs. Another is tunneling. Both are enabled by RADIUS tunneling attributes.
Roaming implementations survey
(Informational, RFC 2194)
Roaming architecture and requirements
(Informational, RFC 2477)
The Network Access Identifier
(Proposed Standard, RFC 2486)
RADIUS Proxies, Policy and Roaming
(Informational, RFC 2607)
Accounting record formats
(Informational, RFC 2924)
Introduction to Accounting Management
(Informational, RFC 2975)
Best Practices
for WISP Roaming (WFA)
RFC
2486bis (IETF Draft, work in progress)
Network
Selection Problem Statement (IETF Draft, work in progress)
Network
Discovery Proposal (IETF Draft, work in progress)
Supporting roaming on a wide scale requires an AP to support more than one
SSID. Here are some papers describing how this can be done:
Virtual
APs (IEEE 802.11i draft, work in progress)
Virtual APs
(Presentation to WFA)
Virtual
AP Definition
You've probably heard "experts" say that "VPN is the answer to WEP security problems." Well, it isn't that simple -- because the next question is "whose VPN?" Almost all IPsec tunnel mode products shipping today are proprietary, interoperability is poor and many of the proprietary extensions have security flaws. Here are the references to the security analyses of VPN protocols as well as to the IETF standards for VPN. Ask your vendors when they plan to implement the IETF standards!
Security analysis of
PPTPv2
Security
analysis of PPTP
Microsoft
point of view on PPTP
Security analysis of XAUTH (shipping
in most IPsec tunnel mode implementations)
Man-in-the-middle
attacks against IPsec VPNs (also SSH, HTTPS, etc.)
Configuration of IPsec tunnel mode
with DHCPv4 (Proposed Standard, RFC 3456)
Securing L2TP with IPsec ( Proposed
Standard, RFC 3193)
Legacy
authentication within IPsec tunnel mode (PIC) (IETF draft, work in
progress)
IPsec-NAT
compatibility requirements (Informational, RFC 3715)
Recently, there has been a lot of interest in the application of certificates to WLAN authentication. Here are some presentations and papers on the subject:
IETF 55 Enrollment Workshop
Certificate-based
roaming (IETF draft, now expired)
Certificate
hierarchy for the WLAN industry (presentation to IEEE 802.11 Tgi)
WLAN certificate extensions (Proposed
Standard, RFC 3770)
Why Certificate OIDs are
needed
PEAPOD
proposal for EAP-based enrollment
The IETF is now looking at a number of new solutions to the problems of mobility, multi-homing and security. Here are some pointers:
Choices
for multi-addressing (IETF Draft, work in progress)
Multiple
Address Service for Transport (MAST) (IETF Draft, work in progress)
Multihoming
using 64-bit crypto-based IDs (IETF Draft, work in progress)
Multihoming
without IP identifiers (IETF Draft, work in progress)
End-host
Mobility and Multi-Homing with HIP (IETF Draft, work in progress)
HIP
architecture (IETF Draft, work in progress)
HIP
Specification (IETF Draft, work in progress)
Homeless
Mobile IPv6 (IETF Draft, work in progress)
To knit the stations together into a coherent network, they can either act as bridges (layer 2 approach) or routers (layer 3 approach, MANET). The issue with bridging has been convergence times -- 802.11D spanning tree doesn't converge fast enough to be viable in an adhoc network where hosts are constantly moving, associating and disassociating with each other. IEEE work in progress on "rapid spanning tree convergence" promises to change that. This could enable adhoc networks with dozens or even hundreds of users that could stretch over a substantial geographic distance. Here are some pointers:
Stealth
Attacks on Adhoc Networks
IPv4
linklocal addressing (Proposed Standard, RFC 3927)
IPv6
linklocal addressing (Proposed Standard, RFC 2462)
Link
Local Multicast Name Resolution (LLMNR), (IETF draft, work in progress)
LLMNR
Issues List
DHCP Domain
Search option (Proposed Standard, RFC 3397)