network policy server dynamic vlan assignment

Networking | Cloud | DevOps | IaC

IEEE 802.1X Authentication and Dynamic VLAN Assignment with NPS Radius Server

IEEE 802.1X Authentication and Dynamic VLAN Assignment with NPS Radius Server is an important element to networking in the real world. User location cannot be predicted as they may be at and out of a desk and up and about should they need to do so. Tying them to a local VLAN may only be helpful if they are bound to desks in those locations, although the most ideal outcome, it is not the most practical.

It is only wise to incorporate IEEE 802.1X Authentication and Dynamic VLAN Assignment with NPS Radius Server in areas where you expect different teams to come to. Meeting rooms could for a moment have the accounting group or the development group meeting there and based on the intelligent and dynamic vlan assignmnet with 802.1x authentication, users port-access are defined their appropriate vlans for their respective access to resources on the network.

How to Provision 802.1 X Authentication Step By Step With Dynamic VLAN Assignment With Windows Radius Server For 802.1x Clients.

A typical configuration for a system under IEEE 802.1x Authentication control is shown in the following figure.

In this scenario, “Lady Smith” wishes to use services offered by servers on the LAN behind the switch. There are multiple VLANs with resources available based on user vlan membership. Her laptop computer is connected to a port on the Aruba 2920 Edge Switch that has 802.1x port authentication control enabled.

The laptop computer must therefore act in a supplicant role. Message exchanges take place between the supplicant and the authenticator which is the Aruba 2920 Switch, and the authenticator passes the supplicant’s credentials which is her (Windows Active Directory User Account Credentials) to the authentication server for verification. The NPS Server which is the authentication server then informs the authenticator whether or not the authentication attempt succeeded, at which point “Lady Smith” is either granted or denied access to the LAN behind the switch.

Setup Structure for IEEE 802.1X Authentication and Dynamic VLAN Assignment with NPS Radius Server

• Supplicant: Laptop running Microsoft Windows 10 or Windows 7
• Authenticator: HP Aruba 2920 Edge Switch
• Authentication Server: Microsoft NPS (Network Policy Server) running on Windows Server 2012 R2.
• User Database : Active Directory

For Windows Infrastructure

Create NPS Server – Add Role on Windows Server 2012 R2

• Create DHCP Scopes for VLANS

Create RADIUS Client on NAC using Network Policy Server

• Create Network Policies
• Configure a Network Policy for VLANs
• Start Wired Auto-Config Service
• Enable Network Authentication

Create the DHCP Scopes for VLAN100 and VLAN200 Groups

• Development Group Scope – VLAN 100

SVI: ip address 172.16.80.254 255.255.255.0 Scope Subnet: 172.16.80.1/24

• Accounting Group Scope – VLAN 200

SVI:ip address 172.16.70.254 255.255.255.0 Scope Subnet: 172.16.70.0/24

Secret Key: secret12

Add Edge Switch Management IP as the RADIUS Client

The Shared Secret Key: secret12 will be used in the Switch Configuration.

Create Network Policy Settings for Accounting Group for VLAN 200

Configuration Example

Here’s an example of how you might consider when configuring Microsoft NPS Server to assign users to a VLAN based on their user group, using NPS for the authentication and authorization of users. This configuration has worked flawlessly on the HP Aruba 2920 Switch. The key to getting this to work is the use of a RADIUS element called: ‘Tunnel-PVT-Group-ID’. This is a RADIUS attribute that may be passed back to the authenticator (i.e. the Aruba 2920 Switch) by the authentication server (i.e. Microsoft NPS Server) when a successful authentication has been achieved. There are a few other elements which need to accompany it, but this is the key element, as it specifies the VLAN number that the user should be assigned to.

The other elements that need to be returned by the NPS Server are as follows:

• Tunnel-PVT-Group-ID: 200
• Service-Type: Framed
• Tunnel-Type: VLAN
• Tunnel-Medium-Type: 802

For Client Infrastructure

On the Supplicant, Windows 7 or 10 configure the following steps on the Ethernet Adapter to enable IEEE 802.1X Authentication

For Network Infrastructure

Connect Server Infrastructure to VLAN 400

Create VLAN for Accounting Group

Create VLAN for Development Group

Create AAA Configuration on Switch for Radius Authentication

Download the Switch Configuration:

Test the IEEE 802.1X Authentication and Dynamic VLAN Assignment with NPS Radius Server

Verify Port-Access with the following user groups – VLAN 100 and VLAN 200

Think of what other clever things you can do from the information below;

Breakdown of Commands for RADIUS Authentication

Verification Commands

Thanks for reading. Please share your thoughts in the comment box below;

Published in Configuring , Design , Installing and Configuring , Networking , Security and Switching

• 802.1 x authentication step by step aruba
• 802.1 x authentication step by step cisco
• 802.1 x wireless authentication step by step
• 802.1x authentication process
• 802.1x authentication windows 10
• 802.1x authentication windows server 2012
• 802.1x certificate authentication
• assignment wlc
• cisco dot1x
• cisco ise dynamic vlan
• cisco ise dynamic vlan assignment wlc
• cisco wireless radius attributes
• configuration example
• dynamic vlan assignment cisco 2960 dynamic vlan configuration in packet tracer
• dynamic vlan assignment with windows radius server
• dynamic vlan cisco
• dynamic vlan ruckus
• meraki dynamic vlan assignment
• nps mac authentication wired
• nps policy for mac-based authentication
• radius multiple vlans
• vlan radius server
• vlan steering
• vmps server

Search This Blog

Microsoft nps as a radius server for wifi networks: dynamic vlan assignment.

• Service-Type: Framed
• Tunnel-Type: VLAN
• Tunnel-Medium-Type: 802
• Tunnel -PVT-Group-ID: <VLAN Number>

• School Wireless - Staff  (to assigned members of the staff AD group to VLAN 10)
• School Wireless - Students  (to assign members of the students AD group to VLAN 20)

Popular posts from this blog

The 5ghz “problem” for wi-fi networks: dfs.

Microsoft NPS as a RADIUS Server for WiFi Networks: SSID Filtering

What Are Sticky Clients?

Network Guys

Share your knowledge!

How to use 802.1x/mac-auth and dynamic VLAN assignment

Hello guys! Today I want to show you how to secure your edge-switches with 802.1x and mac-authentication fallback in combination with HPE comware-based switches. The 802.1x protocol is used for network access control. For devices like printers, cameras, etc. we will use mac-authentication as a fallback. We will also use dynamic VLAN assignment for the connected ports.

Our radius server will be Microsoft NPS. You can activate this role on the Windows server:

After the installation, open the NPS console and register the radius server in your Active Directory:

add your switches or your management network as a radius-client:

the shared secret will be used in the switch configuration. In created two groups within my test environment:

• “ VLAN2-802.1x ” containing computer accounts
• “ VLAN3-MAC-Auth ” containing user accounts (username+password = mac-address of the device)

So we will now configure two network policies for our network access control:

I also configured a NAS Identifier so no other device can use the radius server. The clients will use their computer certificate so you will need a running internal certification authority. Choose PEAP only as the authentication method:

the next step is for our dynamic VLAN assignment. Dot1x devices are bound to VLAN 2:

the final dot1x configuration in the NPS:

the second network policy is for the mac-based authentication:

Comware switches are sending MAC-Auth-requests via PAP (maybe you know how to change it to CHAP):

final MAC auth profile:

for now we have built up our authentication server. Now let’s go to the switch configuration. You have global configuration parameters and parameters for each interface. The best way is to use interface-range command to be safe at your configuration. Users who cant authenticate, will be forced to VLAN 999 (quarantine VLAN with no gateway). Here are the global parameters with explanations inline:

now we will configure the interfaces: Added 2 entries

the last part is to configure all windows clients to send 802.1x auth data to the cable network. I’ve done this via a global group policy. You can find the settings under Computer Configuration / Policies / Windows Settings / Security Settings / Wired Network (IEEE 802.3) Policies:

So how does a working 802.1x-auth looks like?

%Jan 3 01:59:59:531 2013 edge-switch-01 DOT1X/6/DOT1X_LOGIN_SUCC: -IfName=GigabitEthernet1/0/10-MACAddr=0023-2415-42a3-AccessVLANID=1- AuthorizationVLANID=2 -Username= host/PC123.mycompany.local ; User passed 802.1X authentication and came online.

Successful Mac-Authentication of a printer:

%Jan 3 01:31:28:782 2013 de-pad-l19-edg01 MACA/6/MACA_LOGIN_SUCC: -IfName=GigabitEthernet1/0/9-MACAddr=0017-c82d-e9bf-AccessVLANID=1- AuthorizationVLANID=3 -Username= 0017c82de9bf -UsernameFormat=MAC address; User passed MAC authentication and came online.

I tried to draw a flow chart which shows the authentication process, I hope it’s ok for you :)

Do you have questions? Feel free to write them into the comments and I will try to answer.

Have a nice and sunny day!

/edit: If you can’t see success and failure events, follow this instruction:  NPS / Radius Server is not logging

/edit 2018-05-14: I corrected the global and interface configuration, we had problems with the old configuration

12 Responses

Thanks for this, I need to setup dynamic VLAN assignment in the near future but for Juniper equipment.

This at least gives me a good starting point, thanks for the write up.

Many thanks for the perfect tutorial on How to use 802.1x/Mac-Auth and dynamic VLAN assignment. Many of us can take help from it. Really nice.

Nice write-up. This was a great starting point for configuring the base for dynamic polices. Thanks!

hi Mike, how ‘s about hybrid port with voice-vlan? does it work?

thanks Tung Duong

we had several problems with this config, currently we are investigating hyprid ports with “port security” command. I will update this post if we have prooved this version.

Can you tell me why I would do this over conventional static VLANs? What are the benefits radius dynamic VLANs?

we have customers which want to divide the network for clients, printers and “special devices”. So you have different group/radius-policies to directly place the devices in the right VLAN. Dynamic VLAN is only a bonus feature which you can use. Of course, you can use only the 802.1x and Mac authentication for security purpose.

I’m on the desktop side of things, so apologies if I use any incorrect terminology here.

Our Infrastructure team are looking at introducing 8021x in our schools. They have a test setup where all 8021x devices pick up a data centre VLAN regardless of which building they’re in – eg 10.100.50.

Each building WIRED has its own unique IP – SchoolA=10.120, SchoolB = 10.130 and so on.

I’ve asked if the 8021x setup can be where 8021x devices in SchoolA will get 10.120.50; SchoolB will get 10.130.50

This would allow us to easily determine which building LaptopA actually is, in the same way as we can with our wired desktops. It also saves on SCCM boundary issues causing applications/updates to be pulled over the WAN rather than the LAN.

It’s been suggested that this may not be possible. Could someone confirm this?

Thanks in advance.

Hello! This is of course possible!

My idea (with examples):

SchoolA=10.120 (Location: Chicago) SchoolB=10.130 (Location: Dallas)

So at Chicago you will have VLAN 333, every device is getting an IP address with 10.120.x.x. At Dallas every device in VLAN 333 is getting an IP address with 10.130.x.x. So the VLAN ID “333” is the same at every school but the DHCP scope and default gateway has it’s own address. So the device is getting the VLAN 333 at every location but another IP address. It’s very simple.

It’s not working if all schools are connected via Layer2 so VLAN333 can’t be a “standalone VLAN” at each geographical location.

Ask me any questions, I will try to help you.

• Pingback: 802.1x, MAC-Authentication and VLAN assignment at ProCurve/aruba Switches – Network Guy
• Pingback: Port Auth, Dynamic VLAN and Radius | samuelnotes
• Pingback: HPE Comware problem with mac authentication and printer - Network Guy

Leave a Reply Cancel reply

Click on the button to load the content from jetpack.wordpress.com.

Load content

This site uses Akismet to reduce spam. Learn how your comment data is processed .

Certificates

Post Categories

Post archives, recent posts.

• Sophos UTM 9.712-13 HA update problem 14. November 2022
• Sophos UTM 9.712-12 update released 24. August 2022
• Aruba OS Switch automatic vlan assignment for aruba APs 5. May 2022
• Sophos UTM 9.711-5 update released 22. April 2022
• Sophos UTM 9.710-1 update released 20. March 2022

Recent Comments

• Sophos Ssl Vpn Client Anmeldung - Login and Portal on Auto-Logon with Sophos SSL VPN Client (OpenVPN)
• Russell on Install Sophos UTM from USB Stick
• arno on Problems with incoming mails
• GigaTech IT on Installing Realtek Driver on ESXi 6.7
• Sophos User Portal Login Ssl Vpn - Online Login on Auto-Logon with Sophos SSL VPN Client (OpenVPN)

Franky’s Web  Website from my friend Frank. News and Tricks about Microsoft products, primarly Exchange Server

Copyright by networkguy.de

Imprint · Privacy Policy

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Configure Network Policies

• 5 contributors

Applies to: Windows Server 2022, Windows Server 2019, Windows Server 2016

You can use this topic to configure network policies in NPS.

Add a Network Policy

Network Policy Server (NPS) uses network policies and the dial-in properties of user accounts to determine whether a connection request is authorized to connect to the network.

You can use this procedure to configure a new network policy in either the NPS console or the Remote Access console.

Performing authorization

When NPS performs the authorization of a connection request, it compares the request with each network policy in the ordered list of policies, starting with the first policy, and then moving down the list of configured policies. If NPS finds a policy whose conditions match the connection request, NPS uses the matching policy and the dial-in properties of the user account to perform authorization. If the dial-in properties of the user account are configured to grant access or control access through network policy and the connection request is authorized, NPS applies the settings that are configured in the network policy to the connection.

If NPS does not find a network policy that matches the connection request, the connection request is rejected unless the dial-in properties on the user account are set to grant access.

If the dial-in properties of the user account are set to deny access, the connection request is rejected by NPS.

Key settings

When you use the New Network Policy wizard to create a network policy, the value that you specify in Network connection method is used to automatically configure the Policy Type condition:

• If you keep the default value of Unspecified , the network policy that you create is evaluated by NPS for all network connection types that are using any kind of network access server (NAS).
• If you specify a network connection method, NPS evaluates the network policy only if the connection request originates from the type of network access server that you specify.

On the Access Permission page, you must select Access granted if you want the policy to allow users to connect to your network. If you want the policy to prevent users from connecting to your network, select Access denied .

If you want access permission to be determined by user account dial-in properties in Active Directory® Domain Services (AD DS), you can select the Access is determined by User Dial-in properties check box.

Membership in Domain Admins , or equivalent, is the minimum required to complete this procedure.

To add a network policy

Open the NPS console, and then double-click Policies .

In the console tree, right-click Network Policies , and click New . The New Network Policy wizard opens.

Use the New Network Policy wizard to create a policy.

Create Network Policies for Dial-Up or VPN with a Wizard

You can use this procedure to create the connection request policies and network policies required to deploy either dial-up servers or virtual private network (VPN) servers as Remote Authentication Dial-In User Service (RADIUS) clients to the NPS RADIUS server.

Client computers, such as laptop computers and other computers running client operating systems, are not RADIUS clients. RADIUS clients are network access servers — such as wireless access points, 802.1X authenticating switches, virtual private network (VPN) servers, and dial-up servers — because these devices use the RADIUS protocol to communicate with RADIUS servers such as NPSs.

This procedure explains how to open the New Dial-up or Virtual Private Network Connections wizard in NPS.

After you run the wizard, the following policies are created:

• One connection request policy
• One network policy

You can run the New Dial-up or Virtual Private Network Connections wizard every time you need to create new policies for dial-up servers and VPN servers.

Running the New Dial-up or Virtual Private Network Connections wizard is not the only step required to deploy dial-up or VPN servers as RADIUS clients to the NPS. Both network access methods require that you deploy additional hardware and software components.

To create policies for dial-up or VPN with a wizard

Open the NPS console. If it is not already selected, click NPS (Local) . If you want to create policies on a remote NPS, select the server.

In Getting Started and Standard Configuration , select RADIUS server for Dial-Up or VPN Connections . The text and links under the text change to reflect your selection.

Click Configure VPN or Dial-Up with a wizard . The New Dial-up or Virtual Private Network Connections wizard opens.

Follow the instructions in the wizard to complete creation of your new policies.

Create Network Policies for 802.1X Wired or Wireless with a Wizard

You can use this procedure to create the connection request policy and network policy that are required to deploy either 802.1X authenticating switches or 802.1X wireless access points as Remote Authentication Dial-In User Service (RADIUS) clients to the NPS RADIUS server.

This procedure explains how to start the New IEEE 802.1X Secure Wired and Wireless Connections wizard in NPS.

You can run the New IEEE 802.1X Secure Wired and Wireless Connections wizard every time you need to create new policies for 802.1X access.

Running the New IEEE 802.1X Secure Wired and Wireless Connections wizard is not the only step required to deploy 802.1X authenticating switches and wireless access points as RADIUS clients to the NPS. Both network access methods require that you deploy additional hardware and software components.

To create policies for 802.1X wired or wireless with a wizard

On the NPS, in Server Manager, click Tools , and then click Network Policy Server . The NPS console opens.

If it is not already selected, click NPS (Local) . If you want to create policies on a remote NPS, select the server.

In Getting Started and Standard Configuration , select RADIUS server for 802.1X Wireless or Wired Connections . The text and links under the text change to reflect your selection.

Click Configure 802.1X using a wizard . The New IEEE 802.1X Secure Wired and Wireless Connections wizard opens.

Configure NPS to Ignore User Account Dial-in Properties

Use this procedure to configure an NPS network policy to ignore the dial-in properties of user accounts in Active Directory during the authorization process. User accounts in Active Directory Users and Computers have dial-in properties that NPS evaluates during the authorization process unless the Network Access Permission property of the user account is set to Control access through NPS Network Policy .

There are two circumstances where you might want to configure NPS to ignore the dial-in properties of user accounts in Active Directory:

When you want to simplify NPS authorization by using network policy, but not all of your user accounts have the Network Access Permission property set to Control access through NPS Network Policy . For example, some user accounts might have the Network Access Permission property of the user account set to Deny access or Allow access .

When other dial-in properties of user accounts are not applicable to the connection type that is configured in the network policy. For example, properties other than the Network Access Permission setting are applicable only to dial-in or VPN connections, but the network policy you are creating is for wireless or authenticating switch connections.

You can use this procedure to configure NPS to ignore user account dial-in properties. If a connection request matches the network policy where this check box is selected, NPS does not use the dial-in properties of the user account to determine whether the user or computer is authorized to access the network; only the settings in the network policy are used to determine authorization.

Membership in Administrators , or equivalent, is the minimum required to complete this procedure.

Double-click Policies , click Network Policies , and then in the details pane double-click the policy that you want to configure.

In the policy Properties dialog box, on the Overview tab, in Access Permission , select the Ignore user account dial-in properties check box, and then click OK .

To configure NPS to ignore user account dial-in properties

Configure nps for vlans.

By using VLAN-aware network access servers and NPS in Windows Server 2016, you can provide groups of users with access only to the network resources that are appropriate for their security permissions. For example, you can provide visitors with wireless access to the Internet without allowing them access to your organization network.

In addition, VLANs allow you to logically group network resources that exist in different physical locations or on different physical subnets. For example, members of your sales department and their network resources, such as client computers, servers, and printers, might be located in several different buildings at your organization, but you can place all of these resources on one VLAN that uses the same IP address range. The VLAN then functions, from the end-user perspective, as a single subnet.

You can also use VLANs when you want to segregate a network between different groups of users. After you have determined how you want to define your groups, you can create security groups in the Active Directory Users and Computers snap-in, and then add members to the groups.

Configure a Network Policy for VLANs

You can use this procedure to configure a network policy that assigns users to a VLAN. When you use VLAN-aware network hardware, such as routers, switches, and access controllers, you can configure network policy to instruct the access servers to place members of specific Active Directory groups on specific VLANs. This ability to group network resources logically with VLANs provides flexibility when designing and implementing network solutions.

When you configure the settings of an NPS network policy for use with VLANs, you must configure the attributes Tunnel-Medium-Type , Tunnel-Pvt-Group-ID , Tunnel-Type , and Tunnel-Tag .

This procedure is provided as a guideline; your network configuration might require different settings than those described below.

To configure a network policy for VLANs

In the policy Properties dialog box, click the Settings tab.

In policy Properties , in Settings , in RADIUS Attributes , ensure that Standard is selected.

In the details pane, in Attributes , the Service-Type attribute is configured with a default value of Framed . By default, for policies with access methods of VPN and dial-up, the Framed-Protocol attribute is configured with a value of PPP . To specify additional connection attributes required for VLANs, click Add . The Add Standard RADIUS Attribute dialog box opens.

In Add Standard RADIUS Attribute , in Attributes, scroll down to and add the following attributes:

Tunnel-Medium-Type . Select a value appropriate to the previous selections you have made for the policy. For example, if the network policy you are configuring is a wireless policy, select Value: 802 (Includes all 802 media plus Ethernet canonical format) .

Tunnel-Pvt-Group-ID . Enter the integer that represents the VLAN number to which group members will be assigned.

Tunnel-Type . Select Virtual LANs (VLAN) .

In Add Standard RADIUS Attribute , click Close .

If your network access server (NAS) requires use of the Tunnel-Tag attribute, use the following steps to add the Tunnel-Tag attribute to the network policy. If your NAS documentation does not mention this attribute, do not add it to the policy. If required, add the attributes as follows:

In policy Properties , in Settings , in RADIUS Attributes , click Vendor Specific .

In the details pane, click Add . The Add Vendor Specific Attribute dialog box opens.

In Attributes , scroll down to and select Tunnel-Tag , and then click Add . The Attribute Information dialog box opens.

In Attribute value , type the value that you obtained from your hardware documentation.

Configure the EAP Payload Size

In some cases, routers or firewalls drop packets because they are configured to discard packets that require fragmentation.

When you deploy NPS with network policies that use the Extensible Authentication Protocol (EAP) with Transport Layer Security (TLS), or EAP-TLS, as an authentication method, the default maximum transmission unit (MTU) that NPS uses for EAP payloads is 1500 bytes.

This maximum size for the EAP payload can create RADIUS messages that require fragmentation by a router or firewall between the NPS and a RADIUS client. If this is the case, a router or firewall positioned between the RADIUS client and the NPS might silently discard some fragments, resulting in authentication failure and the inability of the access client to connect to the network.

Use the following procedure to lower the maximum size that NPS uses for EAP payloads by adjusting the Framed-MTU attribute in a network policy to a value no greater than 1344.

To configure the Framed-MTU attribute

In Settings , in RADIUS Attributes , click Standard . In the details pane, click Add . The Add Standard RADIUS Attribute dialog box opens.

In Attributes , scroll down to and click Framed-MTU , and then click Add . The Attribute Information dialog box opens.

In Attribute Value , type a value equal to or less than 1344 . Click OK , click Close , and then click OK .

For more information about network policies, see Network Policies .

For examples of pattern-matching syntax to specify network policy attributes, see Use Regular Expressions in NPS .

For more information about NPS, see Network Policy Server (NPS) .

Was this page helpful?

Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback .

Submit and view feedback for

Additional resources

Meraki Community

• Community Platform Help
• Contact Community Team
• Meraki Documentation
• Meraki DevNet Developer Hub
• Meraki System Status
• Technical Forums

802.1X /w Dynamic VLAN Assignment

• Subscribe to RSS Feed
• Mark Topic as New
• Mark Topic as Read
• Float this Topic for Current User
• Printer Friendly Page

• Mark as New
• Report Inappropriate Content
• All forum topics
• Previous Topic

• New July 8: Points Contest: Week 1 Roundup
• July 1: Recognizing the June 2024 Members of the Month
• July 1: The annual points contest is BACK and better than ever!
• Interfaces 232
• Layer 2 250
• Layer 3 181
• Community guidelines
• Cisco privacy
• Khoros privacy
• Terms of service

• PORTNOX CLOUD Unified Access Control Any Device. Any Data. Anywhere.

Zero Trust Network Access Control

• Cloud-native RADIUS Stand up Portnox’s cloud-native RADIUS is minutes.
• Passwordless authentication Leverage certificates for passwordless network authentication.
• Risk posture assessment Monitor the potential risk of every connected device.
• Compliance enforcement Automate device remediation & stay compliant 24/7.
• Explore Pricing

Zero Trust Conditional Access

• How does it work? Discover how to better secure your apps with Portnox.
• Passwordless authentication Bolster application access by going passwordless.
• 24/7 risk monitoring Ensure only trusted devices gain access to your apps.
• Automated remediation Automate device-based compliance enforcement.

Zero Trust Infrastructure Administration

• How does it work? Explore cloud-native TACACS+ from Portnox.
• Admin authentication Get started with simple, secure admin authentication.
• Access policy enforcement Make sure not just anyone can tinker with your infrastructure.
• Granular accounting Keep auditors at bay with cloud-native TACACS+.

Unified Zero Trust Security

• How does it work? Learn the ins and outs of the Portnox Cloud.
• Cloud-native RADIUS authentication Spin up our cloud-native RADIUS server in minutes.
• Passwordless application security Bolster application access by going passwordless.
• Zero trust network access control See and control access for every device across your network.
• Network device administration Keep auditors at bay with cloud-native TACACS+.

• Authentication
• Access Control
• Risk Monitoring
• Remediation
• IoT Security
• Guest Access

Applications

Infrastructure.

• Authorization

Integrations

• Case Studies
• Infographics
• Product Briefs
• White Papers
• Cloud Documentation

Compliance Center

Regulations, cybersecurity center.

• What is 802.1X? What are the benefits of NAC? How does zero trust work? Why go passwordless? What is IoT profiling? Explore All »
• Reseller Program
• Managed Services
• Become a Partner
• Register a Deal
• Get Started

Network Access Control , Network Security

Segmenting your network with dynamic vlan.

What is Dynamic VLAN?

VLANs (Virtual Local Area Networks) enable segmentation of the main organizational network. In practice, VLANs allow network administrators to keep devices and network resources separated despite being connected to the same physical network.

Dynamic VLAN assignment separates and isolates devices into different network segments based on the device or user authorization and their characteristics. The flow of traffic between those VLANs is governed by a firewall or another routing device which can then enforce specific network access rules.

Why Use Dynamic VLANs?

Segmenting the network is a security best practice, and in some cases is even a regulatory requirement – such as with PCI. Network segmentation is a measure that improves the effectiveness of all the current investments in other security tools, and can by itself help to prevent significant damage to critical organizational data across the network after a company has been breached.

Automating VLAN assignments and eliminating the need for manual intervention has historically been a challenge for network security teams. Today, automatic VLAN assignment is best implemented by the use of a RADIUS service, which functions as follows:

• A device connects to one of several the network access layers: wired ethernet switch or WiFi SSID
• The network access layer sends a request to the RADIUS server with the user’s credentials or certificates (using 802.1X)
• The RADIUS server sends a reply which contains attributes that provide the switch or access point with information on the device VLAN, result in properly VLAN assignment

Common Dynamic VLAN Assignment Use Cases

Network and security administrator most commonly encounter these use cases for dynamic VLAN assignment:

• The Sales & Marketing department does not need access to R&D resources, while R&D should not have access to the Finance Department resources. Using dynamic VLANs, each department will be placed in the correct VLAN with the required access.
• Devices that fail to authenticate due to wrong credentials or incorrect/expired certificate will be placed in a quarantine VLAN with internet access only.
• IP Phones using a dedicated voice VLAN and should be placed on that VLAN upon successful authentication.
• MAC bypass for devices that do not support 802.1X should be placed in their own dedicated VLAN.
• Devices that fail posture assessment (such as those without updated AntiVirus) should be placed in a quarantine VLAN with limited access.
• Employees connecting to one single WiFi SSID and get different access (VLANs) based on their authentication repository LDAP groups.

Dynamic VLAN Assignment with Portnox CLEAR

As mentioned earlier, the implementation of dynamic VLAN assignment has often been challenging for organizations since additional servers were needed on-site at the datacenter. This forced network teams to manage redundancies, complex configurations, and on-going maintenance.

To paint a clearer picture of this headache, consider this:

Take the case of connecting a new department, branch, or merely onboarding a lot of new employees at once…this can cause a surge in demand, which will in turn cause the whole network to “shutdown,” thus not accepting anyone who tries to connect.

Portnox CLEAR  is a network access control solution, deployed as a cloud service, that provides all the mentioned use cases and more. CLEAR simplifies the implementation process of dynamic VLAN assignment. CLEAR allows you to easily set-up a cloud RADIUS server in a single click, and integrate with various authentication repositories like on-premise Active Directory, Azure AD, GSuite, OKTA. Plus, you can enforce your own unique access control policy to dynamically assign users to their respective VLANs.

In addition to VLAN assignment based on credentials authorization, CLEAR also allows you to implement dynamic VLAN assignment based on risk violation. This means that even devices that have authenticated successfully to the wired or wireless network can be dynamically moved to a dedicated VLAN if they fall out of compliance.

In the diagram above:

• PCs are dynamically assigned to the VLAN based on their credentials/certificate.
• IP Phones are assigned to the VOIP VLAN.
• Printers are assigned to the printers VLAN.
• Guests devices assigned to the internet-only access/quarantine VLAN.

How it Works – Setting up Dynamic VLAN Assignment in Portnox CLEAR:

1. enable cloud radius.

In the CLEAR portal, create your one-click cloud RADIUS server: Go to  Settings > Services > CLEAR RADIUS Service , and add your RADIUS service instance:

And point your network equipment: wired switches and/or wireless controllers to work with these CLEAR Radius service details.

2. Creating an Access Control Policy – Dynamic VLAN Assignment:

In Policies > Access Control Policies , add or edit your existing access control policy, select the required access layer and add the correct VLAN ID or VLAN name for each event you want to create dynamic VLAN assignment for: successful authentication, authentication violation, risk assessment, blocked by admin. Then, map the access control policy to the relevant groups and users.

Related Reading

The Origin of the Word “Wi-Fi”: A Dive into Tech Etymology

Agent vs Agentless: Navigating Security Posture Assessments 

The Evolution of the 802.1X Standard: A Journey Through Time

Try portnox cloud for free today.

Gain access to all of Portnox's powerful zero trust access control free capabilities for 30 days!

Privacy Overview

Microsoft NPS as a RADIUS Server for WiFi Networks: Dynamic VLAN Assignment

Configuration Example Here’s an example of how to configure NPS to assign users to a VLAN based on their user group, using NPS for the authentication and authorization of users. The key to getting this to work is the use of a RADIUS element called: ‘Tunnel-PVT-Group-ID’.  This is a RADIUS attribute that may be passed back to the authenticator (i.e. the WLC or AP) by the authentication server (i.e.NPS) when a successful authentication has been achieved. There are a few other elements which need to accompany it, but this is the key element, as it specifies the VLAN number that the user should be assigned to. The other elements that need to be returned by NPS are:

• Service-Type: Framed
• Tunnel-Type: VLAN
• Tunnel-Medium-Type: 802
• Tunnel-PVT-Group-ID: <VLAN Number>

We’ll have  a look at how we specify each of these attributes in an NPS policy.  For our example, we’ll assign all ‘staff’ users to VLAN 10 and all ‘student’ users to VLAN 20.  Here is an overview of what the network might look like (this is obviously very simplified, but gives an overview of the type of thing that might be achieved):

VLAN 10 has an ACL (access control list) that allows users on this VLAN to access all systems across the school network. The ACL would generally be configured on the layer 3 switch or router that interconnects the school VLANs) VLAN 20 has an ACL which only allow access to the learning system VLAN and the Internet related services. By studying the example above, you can see that if we can control a users VLAN assignment, based on their AD group membership, we can ensure that they only receive the network access to which they are entitled (purely via their AD group membership). Also, note that this is all being done on a single SSID (“School” in this case). Now we’ll take a look at how we achieve this using NPS. NPS Configuration To configure NPS to provide the VLAN assignments outlined above, we will create 2 policies within NPS:

• School Wireless – Staff  (to assigned members of the staff AD group to VLAN 10)
• School Wireless – Students  (to assign members of the students AD group to VLAN 20)

The screen-shots below outline the configuration required. Here is the policy summary screen within NPS. Note that when configuring multiple policies, the order of the policies is important. Policies are assessed top-down, so make sure the policies that need to be hit are enabled and above any disabled polices.

Staff Policy 1. Create the policy and enable it:

2. Add the NAS type and AD group membership conditions (must be members of the staff group):

3. Select and configure an EAP type (note this may be PEAP or EAP-TLS – we’ve shown PEAP just as an example)

4. Configure the settings for this policy to assign any users which match this policy to VLAN 10:

Students Policy 1. Create the policy and enable it:

2. Add the NAS type and AD group membership conditions: (must be members of the students group to match this policy)

4. Configure the settings for this policy to assign any users which match this policy to VLAN 20:

Once NPS has been configured with policies similar to those shown above, users can be dynamically assigned to an appropriate VLAN based on their AD group membership.  As we’ve already discussed, this provides great benefits in reducing additional overheads associated with multiple SSIDs on a WiFi network. In addition, it simplifies user wireless management by allowing all users to be configured with a single wireless client profile, with their access being configured via Microsoft AD. One caveat to note when trying to use this technique is that all users must be using the same security mechanisms to join the SSID. For instance, all users must be using 802.1x (EAP) – you can’t have a mix of PSK & 802.1x authenticated devices on the same SSID. Generally, they should also be using the same WPA version (i.e. WPA or WPA2).

Related Articles

How to use openpath mobile pass (avigilon alta), integrate your existing network policy server (nps) infrastructure with azure ad multi-factor authentication, how to find out who the user profile disk belongs to terminal server rds, how to sign up and use chatgpt, sage 50 payroll – change database path, generate a report of all passwords for all cameras on your milestone xprotect vms., leave a reply cancel reply.

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

Power by IT Capture

Stack Exchange Network

Stack Exchange network consists of 183 Q&A communities including Stack Overflow , the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

Questions tagged [dynamic-vlan-assignment]

The dynamic-vlan-assignment tag has no usage guidance.

• Learn more…
• Unanswered (my tags)

NPS Dynamic VLAN Catch-All

• windows-server-2019
• dynamic-vlan-assignment

Yealink phones fail to get IP once assigned voice VLAN via DHCP (Mikrotik)

How does VLAN subnetting work on IPv6?

DHCPS - single mac whitelist, multiple subnets

OpenWRT Dynamic VLAN

• freeradius2

dynamic VLANs on cheap Access Point after switch

802.1x dynamic vlan assignment not assigning vlan.

Open vSwitch double VLAN tagging is ignored

• kvm-virtualization
• linux-networking
• openvswitch

Cisco switch VLANing based on MAC address

VLAN configuration

Assign VLAN per user credentials on VPN connections

How do I setup dynamic VLAN assignment on an autonomous Cisco 1142n?

• access-point

Vlan Management Policy Server ( VMPS) Configuration and Management

• cisco-catalyst

Dynamic VLANs with FreeRadius, OpenLDAP & Cisco WLC

How do I dynamically hand out dhcp and automatically put specific pc's on a specified vlan?

• network-design

• Featured on Meta
• Upcoming initiatives on Stack Overflow and across the Stack Exchange network...
• We spent a sprint addressing your requests — here’s how it went

Related Tags

Hot network questions.

• Mathematical Induction over two numbers
• Intelligence vs Wisdom in D&D
• Decomposing the homology of a finite-index subgroup into isotypic components
• Can I set QGIS to summarize icons above a certain scale and display only the number of icons in an area?
• Rolling median of all K-length ranges
• I want to pick my flight route. I can either get 2 round trip tickets (SRC<->MID, MID<->DST) or 3rd party booking (SRC<->DST). Which is more reliable?
• The rear wheel from my new Road Bike vibrates strongly
• Interesting structure: ".....ever go to do... ! --- "If you ever go to sell this place, let me know."
• MOSFET Datasheet Confusion
• How to turn a sum into an integral?
• How are GameManagers created in Unity?
• Why does Macbeth well deserve his name?
• DNS Stopped resolving on upgrade to Ubuntu 23.10 and Ubuntu 24.04
• Coincidence between coefficients of tanh(tan(x/2)) and Chow ring computations?
• Alternatives to iterrow loops in python pandas dataframes
• How does \if:w work?
• How can I get the value of the f(1/2) is 11/4 not 2.75 when I use \pgfmathprintnumber\pgfmathresult?
• What is wrong with samsara and dukkha from the perspective of advaita philosophy?
• Is it a security issue to expose PII on any publically accessible URL?
• Generate filesystem usage report using Awk
• Citation hunting: Floer on spectral sequences
• Is the variance of the mean of a set of possibly dependent random variables less than the average of their respective variances?
• How can I search File Explorer for files only (i.e. exclude folders) in Windows 10?
• Time integration of first-order ODE with higher-order information

You are using an outdated browser. Please upgrade your browser to improve your experience.

Your browser does not support JavaScript. Please turn it on for the best experience.

Configuration Guide on Dynamic VLAN with the VLAN Assignment function of RADIUS

OC200 , OC300 , Omada Software Controller , Omada Cloud-Based Controller

Recent updates may have expanded access to feature(s) discussed in this FAQ. Visit your product's support page, select the correct hardware version for your device and check either the Datasheet or the firmware section for the latest improvements added to your product.

With the VLAN Assignment feature of RADIUS, the Omada SDN solution can put clients authenticated by different accounts to the corresponding VLANs. In this way, clients will obtain IP addresses from different VLANs, and you don't have to create many SSIDs bound with different VLANs for wireless networks, or bind the PVIDs of the switch ports to specific VLANs for wired networks.

To achieve the above features, you will need the Omada SDN Controller, EAP for wireless assignment, JetStream Switch for wired assignment, and an external RADIUS server. In this article, we will share the configuration guide for below network topology.

Step 1. Set up the RADIUS server.

Here we run a FreeRADIUS ® server on a Linux server. For more information on installation and configuration, please refer to the official website: https://freeradius.org/

First, edit the “ clients.conf ” file, set the client IP address as “192.168.0.0/24” and the password as “tplink”.

Next, edit the “ users ” file, create two accounts “test10” and “test20” in VLAN10 and VLAN20, respectively.

You may also edit the “ eap.conf ” to modify the EAP type for WPA-Enterprise. After configuration, run the RADIUS server to listen for access requests.

Step 2. Create the RADIUS profile.

Go to Authentication --- RADIUS Profile, create a new profile bound with the RADIUS server, and check “Enable VLAN Assignment for Wireless Network” to assign VLANs for wireless clients.

Step 3. Create more VLAN for VLAN assignments.

Assuming all Omada devices have been adopted by the controller, go to Settings --- Wired Networks --- LAN, and create two interfaces with VLAN10 and VLAN20.

Step 4. VLAN assignment for wireless networks.

Go to Settings – Wireless Networks, and create a new SSID with WPA-Enterprise as below. For differences between WPA-Personal and WPA-Enterprise, please refer to FAQ500 .

When connecting your client to the SSID, you will be asked to choose the authentication type of WPA-Enterprise, and enter the account username and password. After successfully authenticating with account “test10”, the client will obtain an IP address from VLAN10, while with account “test20”, it will get that from VLAN20.

Step 5. VLAN assignment for wired networks.

Go to Authentication --- 802.1X and enable the feature, select Authentication Type as “Port Based”, enable “VLAN Assignment” and check the Ports to be authenticated according to your requirements.

Not to click the ports twice to enable MAB for them.

Then go to Wired Networks --- LAN --- Profile, create a new port profile, add VLAN10 and VLAN20 to untagged networks, and make sure the 802.1X Control mode is Auto.

Then Go to Devices, click your switch, go to Ports, check the authentication ports, and batch edit to change the port profile to the one created just now.

For 802.1X authentication, you may need to run TP-Link 802.1X Client Software (click here to download) for authentication. Please refer to FAQ787 and Step 3. For detailed guidance.

Is this faq useful?

Your feedback helps improve this site.

What’s your concern with this article?

• Dissatisfied with product
• Too Complicated
• Confusing Title
• Does not apply to me

We'd love to get your feedback, please let us know how we can improve this content.

We appreciate your feedback. Click here to contact TP-Link technical support.

Recommend Products

Omada Cloud-Based Controller

Omada Software Controller

Omada Hardware Controller

TP-Link Community

Still need help? Search for answers, ask questions, and get help from TP-Link experts and other users around the world.

Visit the Community >

From Russia?

Get products, events and services for your region.

We have updated our Policies. Read Privacy Policy and Terms of Use here. This website uses cookies to improve website navigation, analyze online activities and have the best possible user experience on our website. You can object to the use of cookies at any time. You can find more information in our privacy policy .

Basic Cookies

These cookies are necessary for the website to function and cannot be deactivated in your systems.

accepted_local_switcher, tp_privacy_base, tp_privacy_marketing, tp_smb-select-product_scence, tp_smb-select-product_scenceSimple, tp_smb-select-product_userChoice, tp_smb-select-product_userChoiceSimple, tp_smb-select-product_userInfo, tp_smb-select-product_userInfoSimple, tp_top-banner, tp_popup-bottom, tp_popup-center, tp_popup-right-middle, tp_popup-right-bottom, tp_productCategoryType

__livechat, __lc2_cid, __lc2_cst, __lc_cid, __lc_cst, CASID

id, VISITOR_INFO1_LIVE, LOGIN_INFO, SIDCC, SAPISID, APISID, SSID, SID, YSC, __Secure-1PSID, __Secure-1PAPISID, __Secure-1PSIDCC, __Secure-3PSID, __Secure-3PAPISID, __Secure-3PSIDCC, 1P_JAR, AEC, NID, OTZ

Analysis and Marketing Cookies

Analysis cookies enable us to analyze your activities on our website in order to improve and adapt the functionality of our website.

The marketing cookies can be set through our website by our advertising partners in order to create a profile of your interests and to show you relevant advertisements on other websites.

Google Analytics & Google Tag Manager

_gid, _ga_<container-id>, _ga, _gat_gtag_<container-id>

Google Ads & DoubleClick

test_cookie, _gcl_au

cebsp_, _ce.s, _ce.clock_data, _ce.clock_event, cebs

OptanonConsent, _sctr, _cs_s, _hjFirstSeen, _hjAbsoluteSessionInProgress, _hjSessionUser_14, _fbp, ajs_anonymous_id, _hjSessionUser_<hotjar-id>, _uetsid, _schn, _uetvid, NEXT_LOCALE, _hjSession_14, _hjid, _cs_c, _scid, _hjAbsoluteSessionInProgress, _cs_id, _gcl_au, _ga, _gid, _hjIncludedInPageviewSample, _hjSession_<hotjar-id>, _hjIncludedInSessionSample_<hotjar-id>

lidc, AnalyticsSyncHistory, UserMatchHistory, bcookie, li_sugr, ln_or

IPv6-Mostly Networks: Deployment and Operations Considerations

This document discusses a deployment scenario called "an IPv6-Mostly network", when IPv6-only and IPv4-enabled endpoints coexist on the same network (network segment, VLAN, SSID etc). ¶

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. ¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/ . ¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." ¶

This Internet-Draft will expire on 8 January 2025. ¶

Copyright Notice

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. ¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( https://trustee.ietf.org/license-info ) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. ¶

Table of Contents

1. introduction.

While most network operators initially deploy IPv6 alongside their existing IPv4 infrastructure, pure IPv6-only networks remain uncommon outside of the mobile carrier space. This dual-stack approach is seen as a necessary transition phase, allowing operators to gain experience with IPv6 while minimizing disruption. ¶

However, dual-stack networks do not address the core problem driving IPv6 adoption: IPv4 address exhaustion. They still require the same amount of IPv4 resources as IPv4-only networks. Even worse, this dual-stack approach has been demonstrated to be a long-term crutch, frequently masking problems that would otherwise be exposed and remedied as normal operational workflows. Many applications still rely on IPv4, creating a chicken-and-egg problem: IPv6-only networks seem impractical with so many incompatible applications, yet applications continue to rely on IPv4 because IPv6-only networks are rare. ¶

The less control a network operator has over devices and applications, the more difficult it is to break IPv4 dependencies and move to IPv6-only. This is particularly challenging in enterprise networks with legacy IPv4-dependent applications and public Wi-Fi networks where operators cannot guarantee device compatibility. ¶

To enable a gradual transition, operators need to identify which devices can function in IPv6-only mode and which cannot. Creating separate network segments for each type introduces complexity and scalability issues – a major hurdle to IPv6-only adoption. ¶

A more desirable approach is to deploy an "IPv6-mostly" network that provides IPv4 on demand. This allows IPv6-capable devices to remain IPv6-only while seamlessly supplying IPv4 to those that require it. An IPv6-mostly network allows Endpoints to operate at the highest level of their network stack evolution, on demand, while still allowing for legacy compatibility. ¶

This document explores the requirements, recommendations, and challenges associated with deploying IPv6-mostly networks in enterprise and public Wi-Fi environments. While the principles discussed may be applicable to other network types, this document's focus remains on these specific use cases. ¶

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [ RFC2119 ] [ RFC8174 ] when, and only when, they appear in all capitals, as shown here. ¶

3. Terminology

This document reuses most of Terminology section from [ RFC8925 ] . ¶

Endpoint: A device connected to a network and considered a host From the operator's perspective. However, some endpoint can also extend the network to other physical or logical systems, thereby assuming routing functions. Examples include: ¶

Corporate laptop: While primarily a host, it might run virtual systems and route traffic to them, extending the network and acting as a router. ¶

Mobile phone with tethering enabled: Acts as a host on the Wi-Fi network, but also as a router for tethered devices, potentially without the operator's knowledge or consent. ¶

Network segment: a link (VLAN, a broadcast domain etc) where hosts share the same IP subnet. ¶

PREF64: (or NAT64 prefix): An IPv6 prefix used for IPv6 address synthesis and for network addresses and protocols translation from IPv6 clients to IPv4 servers, [ RFC6146 ] . ¶

4. Solution Overview

In a nutshell, an IPv6-mostly network is very much similar to a dual-stack one with two additional key elements: ¶

The network provides NAT64 ( [ RFC6146 ] ) functionality ([RFC6146]), enabling IPv6-only clients to communicate with IPv4-only destinations. ¶

The DHCPv4 infrastructure processing DHCPv4 Option 108 as per [ RFC8925 ] . ¶

Upon connecting to an IPv6-mostly network segment, an endpoint configures its IP stack based on its capabilities: ¶

IPv4-Only Endpoint: Acquires an IPv4 address through DHCPv4. ¶

Dual-Stack Endpoint (Not IPv6-Only Capable): Configures IPv6 addresses via Stateless Address Autoconfiguration (SLAAC) and, optionally, DHCPv6. Additionally, it obtains an IPv4 address via DHCPv4 or by other means. ¶

IPv6-only capable endpoint configures its IPv6 addresses and, while performing DHCPv4, includes option 108 ( [ RFC8925 ] ) into the Parameter Request List. The DHCP server returns the option and, as per [ RFC8925 ] , the endpoint forgoes requesting an IPv4 address, remaining in IPv6-only mode. ¶

An IPv6-mostly network segment can support a mix of IPv4-only, dual-stack, and IPv6-only devices. IPv6-only endpoints utilize the network-provided NAT64 along with DNS64 services to reach IPv4-only destinations. ¶

The following sections discussed the various solution elements in more details. ¶

4.1. IPv6-Only Capable Endpoints

The term "IPv6-only capable endpoint" lacks a strict technical definition. It broadly describes a device that can function without native IPv4 connectivity/IPv4 addresses, providing the same user experience. The most common way to achieve this is by implementing a customer-side translator (CLAT) as specified in 464XLAT ( [ RFC6877 ] ). Devices which support CLAT (such as mobile phones) are known to operate without issues in IPv6-only mode. In some cases, however, a network administrator may consider a device IPv6-only capable even without CLAT implementation. For example, if all applications run on the device have been tested and confirmed to operate in NAT64 envinronment without any IPv4 dependencies. ¶

4.2. IPv6-Only and IPv4-enabled Endpoints Coexistence

One effective way to restrict IPv4 addresses solely to devices that require them is to enable support for the IPv6-Only Preferred DHCPv4 option (Option 108, [ RFC8925 ] ) on the network's DHCP infrastructure. Most CLAT-enabled systems also support Option 108. By recognizing this option, the network can configure those devices as IPv6-only, allowing them to use CLAT for providing IPv4 address to the local endpoint's network stack. ¶

Certain devices, such as resource-constrained embedded systems, may operate in IPv6-only mode without CLAT if their communication is limited to IPv6-enabled destinations. Since these systems often lack Option 108 support, administrators may need alternative methods to prevent IPv4 address assignment. One approach is to block IPv4 traffic at the switchport level. This could involve: ¶

Static ACL: Applying a static filter with a "deny ip any any" rule. ¶

Dynamic ACL via RADIUS: If 802.1x authentication is in use, RADIUS can provide an ACL blocking all IPv4 traffic. ¶

Filtering the IPv4 ethertype (0x0800): Some hardware platforms may allow for low level filtering of ethertype 0x0800 preventing IPv4 from passing into or out of a given switchport. ¶

The ACL-based approach has some scalability implications and increases operational complexity, therefore it could only be recommended as a stopgap solution. ¶

4.3. Access to IPv4-only Destinations

4.3.1. nat64.

IPv6-only endpoints require NAT64 to access IPv4-only destinations. Quite often operators choose to combine NAT44 and NAT64 functions. However, if not all internal services are IPv6-enabled, then NAT64 might need to be performed closer to the clients. If IPv4-only internal destinations are using [ RFC1918 ] address space, then the operator MUST NOT use the well-known prefix 64:ff9b::/96 for NAT64 (see section 3.1 of [ RFC6052 ] ). ¶

4.3.2. 464XLAT

Enabling CLAT (Customer-side translator) on endpoints is essential for seamless operation of IPv4-only applications in IPv6-only environments. CLAT provides an [ RFC1918 ] address and IPv4 default route, ensuring functionality even without a native IPv4 address from the network. Without CLAT, IPv4-only applications would fail, negatively impacting user experience and increasing support overhead. ¶

Recommendations for Network Administrators controlling the endpoints: ¶

CLAT + DHCPv4 Option 108: If the network administrator can control endpoint configuration, CLAT SHOULD be enabled on endpoints sending DHCPv4 Option 108. This streamlines the transition. ¶

Option 108 Without CLAT MAY be enabled if the administrator is willing to identify and fixIPv4-only systems/applications, or if all applications are confirmed to work in IPv6-only mode. ¶

4.3.3. Signalling NAT64 Prefix to Hosts

Hosts running 464XLAT need to discover the PREF64 (the IPv6 prefix used by NAT64). The network administrator SHOULD configure the first-hop routers to include PREF64 information in Router Advertisements as per ( [ RFC8781 ] ) even if the network provides DNS64 (so hosts can use DNS64-based prefix discovery, [ RFC7050 ] ). This is required as hosts or individual applications might have custom DNS configuration (or even run a local DNS server) and ignore DNS64 information provided by the network, so they can not use [ RFC7050 ] method to detect PREF64. In the absense of PREF64 information in Router Advertisements such systems would not be able to run CLAT, which would cause connectivity issues for all IPv4-only applications running on the affected device. As such device wouldn't be able to use the network-provided DNS64, access to IPv4-only destination would be impacted as well. At the time of writing all major OSes supporting DHCPv4 option 108 and enabling CLAT automatically also support [ RFC8781 ] . Therefore providing PREF64 information in RAs can reliably mitigate the impact of custom DNS configuration on those systems. ¶

Receiving PREF64 information in RAs also speeds up the CLAT start up time, so an IPv4 address and default route become available for applications much faster. ¶

4.3.4. DNS vs DNS64

Traditionally, DNS64 (with NAT64) is used to enable IPv6-only endpoints to access IPv4-only destinations. However, using DNS64 has a number of drawbacks, such as: ¶

DNSSEC Incompatibility: DNS64 responses fail DNSSEC validation. ¶

Custom Resolvers: Endpoints or applications configured with custom resolvers or running recursive resolvers locally can not benefit from the DNS64 provided by the network. Such systems would need to rely on CLAT or local synthesis instead ( Section 7.3.8 discusses this scenario in more details). ¶

Additional requirements for application: to benefit from DNS64, applications need to be IPv6-enabled, use DNS (do not use IPv4 literals). Many applications do not satisfy those requirements and therefore fail if the endpoint does not have an IPv4 address/native IPv4 connectivity. Existence of such applications is the main reason why transition to IPv6-only must be incremental (via IPv6-mostly phase) and requires the vast majority of endpoints to support CLAT. ¶

Those concerns make DNS64 is suboptimal and undesirtable solution long-term. To eliminate the needs for DNS64, the network shall signal PREF64 to endpoints (see Section 4.3.3 ), and the endpoints need to use the obtained PREF64 for performing local synthesis and for CLAT. It should be noted that not every application can benefit from local synthesis performed by the operating system, as it would require the application to use DNS (not IP literals). Therefore DNS64 is only required to support the following cases: ¶

Systems and applications which perform local synthesis but do not support [ RFC8781 ] for prefix discovery, and can only discover the NAT64 prefix using [ RFC7050 ] . ¶

IPv6-only devices without CLAT (unless those endpoints are guaranteed never to need IPv4-only destinations, e.g. in case of a specialized network segment communicating solely with IPv6-capable destinations). ¶

5. Solution Benefits

5.1. benefits compared to dual-stack.

IPv6-Mostly networks offer significant advantages over traditional dual-stack models where endpoints have both IPv4 and IPv6 addresses: ¶

Drastically Reduced IPv4 Consumption: Dual-stack deployments don't solve the core problem of IPv4 address exhaustion. IPv6-Mostly allows to significantly reduce IPv4 consumption, as well as to reclaim IPv4 space. This reduction depends on endpoint capabilities (DHCPv4 Option 108 and CLAT support). In real-world scenarios, like conference Wi-Fi, 60-70% of endpoints may support IPv6-only operation, potentially allowing 2-4 times smaller IPv4 subnets. ¶

Simplified Operations: Managing dual-stack networks means running two network data planes simultaneously, increasing complexity, costs, and the potential for errors. IPv6-Mostly allows for the controlled phase out IPv4 from many endpoints, streamlining operations and improving overall network reliability at a measured and operator-controlled pace. ¶

Reduced Dependency on DHCPv4: As more devices operate seamlessly in IPv6-only mode, the criticality of DHCPv4 service diminishes significantly. This allows operators to scale down DHCPv4 infrastructure or operate it with less stringent SLOs, optimizing costs and resource allocation. ¶

5.2. Benefits Compared to a Dedicated IPv6-Only Network

Traditional IPv6-only adoption involves separate networks alongside dual-stack ones. IPv6-Mostly offers significant improvements: ¶

Enhanced Scalability: Separate IPv6-only networks double the number of SSIDs in wireless environments, causing channel congestion and degrading performance. IPv6-Mostly doesn't require additional SSIDs. Similarly, it allows IPv4 and IPv6-only devices to coexist on the same wired VLANs, eliminating the need of additional layer2 segments, VLAN IDs, and their respective layer3 configurations. ¶

Operational Simplicity: Managing one network segment for all clients (regardless of IPv4 needs) simplifies operations, improves user experience (no more confusing SSID choices), and reduces support tickets related to mismatched connections. Dynamic VLAN assignment becomes easier without device-specific IPv6 capability tracking. ¶

Optimized IPv4 Consumption: User-selected dual-stack networks often lead to unnecessary IPv4 use, as users often connect IPv6-only capable devices to a dual-stack network. IPv6-Mostly network allocates IPv4 addresses only when devices don't advertise IPv6-only capability (DHCPv4 Option 108). ¶

Improved Problem Visibility: User-selected fallback to dual-stack networks can mask issues with IPv6-only operation, hindering problem reporting and resolution. IPv6-Mostly forces users to work through any issues, improving identification and enabling fixes for smoother long-term transition. ¶

Flexible, Incremental Transition: IPv6-Mostly allows for gradual migration on a per-segment or even on per-device basis. Devices become IPv6-only only when deemed fully compatible with that mode. ¶

6. Incremental Rollout Considerations

Migrating endpoints to IPv6-only fundamentally changes network dynamics by removing the IPv4 safety net. This includes the masking effect of Happy Eyeballs. IPv6 connectivity issues become far more prominent, including those previously hidden within dual-stack environments. Operators should be prepared to discover and troubleshoot issues in both endpoints and network infrastructure, even if the dual-stack network appeared problem-free. ¶

Some rollout considerations are discussed in the following sections. ¶

6.1. Per-Device and Per-Subnet Incremental Rollout

Limited control over endpoint configuration necessitates a per-subnet rollout, incrementally enabling Option 108 processing in DHCP. If endpoint control exists, per-device rollout is possible (at least for OSes with configurable Option 108). Note that some OSes unconditionally enable Option 108 support, becoming IPv6-only the moment it's activated on the server side. The following approach is RECOMMENDED: ¶

DHCP Server-Side Activation: Enable Option 108 processing. Some OSes automatically switch to IPv6-only. Rollback at this stage affects the entire subnet. ¶

Controlled Endpoint Activation: Enable Option 108 on managed endpoints with per-device rollback possible. ¶

6.2. Rollback Approach

For quick rollback, the administrator SHOULD start with a minimal Option 108 value (300 seconds, Section 3.4 of [ RFC8925 ] ) and increase this value as the IPv6-mostly network proves reliable, reducing the likelihood of full-scale rollback. ¶

6.3. Opt-In and Opt-Out Modes

Before user-facing deployment, the administrator SHOULD consider a dedicated IPv6-mostly proof-of-concept network for early adopters. While this temporarily sacrifices some IPv6-mostly benefits ( Section 5.2 ), it provides valuable operational experience and early issue detection. ¶

Opt-In Phase: Invite tech-savvy early adopters to enable Option 108 and report issues. While response rates may be low, dedicated participants provide valuable troubleshooting data. ¶

Opt-Out Phase: Incrementally enable Option 108. Allow selective disabling for problematic endpoints. Disabling Option 108 SHOULD NOT be possible without a problem reports to ensure issue tracking and resolution. ¶

In some scenarios (see Section 7.3.1 ) the administrator MAY keep a dual-stack network as a last resort fallback mechanism but SHOULD prevent usesrs from connecting to it accidentially (e.g. it should be a hidden protected SSID). ¶

7. Operational Considerations

7.1. address assignment policy.

As outlined in Section 6.3 of [ RFC6877 ] , CLAT requires either a dedicated IPv6 prefix or, if unavailable, a dedicated IPv6 address. Currently (2024), all implementations use SLAAC for CLAT address acquisition. Therefore, to enable CLAT functionality within IPv6-mostly network segments, first-hop routers must advertise a Prefix Information Option (PIO) containing a globally routable SLAAC-suitable prefix with the 'Autonomous Address-Configuration' (A) flag set to zero. ¶

7.2. Extension Headers

Being an IPv6-specific concept, IPv6 extension headers are often neglected or even explictly prohibited by security policies in dual-stack networks. The issues caused by blockig extension headers might be masked by the presense of Happy Eyeballs but become highly visible when there is no IPv4 to fallback to. ¶

The network SHOULD permit at least the following extension headers: ¶

Fragment Header (Section 4.5 of [ RFC8200 ] ). Section 7.3.5 discusses the fragmentation in more details. ¶

ESP Header, which is used for IPSec traffic, such as VPN and Wi-Fi Calling. ¶

7.3. Typical Issues

IPv6-mostly networks expose hidden issues by removing the IPv4 safety net. While implementation bugs vary greatly and are beyond the scope of this document, this section focus on common problems caused by configuration, topology, or design choices. It's crucial to note that these issues likely pre-exist in dual-stack networks, but remain unnoticed due to IPv4 fallback. ¶

7.3.1. Hosts with Disabled or Disfunctional IPv6

Historically, tech support often advised disabling IPv6 as a quick workaround, leading to devices with disabled IPv6. Similarly, corporate IT may have disabled or filtered IPv6 under the assumption that it's not widely used. Such endpoints requesting Option 108 will fail to connect in an IPv6-mostly network, as they won't receive IPv4 addresses and IPv6 is disabled. ¶

Administrators controlling endpoints SHOULD ensure those endpoints have IPv6 enabled and operational before transitioning the network to IPv6-mostly mode. This includes verifying protocol enablement as well as validation of any central or discreetly managed host based firewalls that could potentially interfere with proper IPv6 function that may be masked by the presence of IPv4, and therefor exp[osed with its removal. ¶

7.3.2. Network Extension

IPv4's NAT44 allows endpoints to extend connectivity to downstream systems without upstream network awareness or permission. This creates challenges in IPv6-mostly deployments where endpoints lack IPv4 addresses: ¶

Solutions and trade-offs: ¶

Using DHCPv6-PD to allocate prefixes to endpoints ( [ I-D.ietf-v6ops-dhcp-pd-per-device ] ). Provides downstream systems with IPv6 addresses and native connectivity. ¶

Enabling the CLAT function on the endpoint. This scenario is similar to the Wireline Network Architecture described in Section 4.1 of [ RFC6877 ] . The downstream systems would receive IPv4 addresses and their IPv4 traffic would be translated to IPv6 by the endpoint. However this approach leads to the downstream systems using IPv4 only and not benefiting from end2end IPv6 connectivity. To enable IPv6 benefits, combine this with IPv6 Prefix Delegation as discussed above. ¶

Bridging and ND Proxy: The endpoint bridges IPv6 traffic and masks downstream devices behind its MAC address. This can lead to scalability issues ( Section 7.3.3 ) due to the single MAC being mapped to many IPv6 addresses. ¶

7.3.3. Multiple Addresses per Device

Unlike IPv4, where endpoints typically have a single IPv4 address per interface, IPv6 endpoints inherently use multiple addresses: ¶

Link-local address. ¶

Temporary address (common on mobile devices for privacy) ¶

Stable address (for long-term identification) ¶

CLAT address (in IPv6-mostly/IPv6-only networks) ¶

Endpoints with containers, namespaces, or ND proxy functions may have even more addresses. This poses challenges for network infrastructure devices (SAVI switches, wireless access points, etc.) that map MAC addresses to IPv6 addresses, often with limits to prevent resource exhaustion or DoS attacks. When the number of IPs per MAC limit is exceeded, infastructure devices behavior varies across implementations, leading to inconsistent connectivity loss and other unexpected behavior: while some systems drop new addresses, others delete older entries, causing previously functional addresses to lose connectivity. In all those cases Endpoints and applications don't receive explicit signalling about the address becoming unusable. ¶

While allocating prefixes to endpoints via DHCP-PD ( [ I-D.ietf-v6ops-dhcp-pd-per-device ] ) alows to eliminate the issue and corresponding scalability concerns, that solution migth not be supported by all endpoints. The network administrator SHOULD ensure that the deployed network infastructure devices allow sufficient number of IPv6 addresses to be mapped to a client's MAC and SHOULD monitor for events, indicating that the limit has been reached (such as syslog messages, etc). ¶

7.3.4. Host Mobility and Renumbering

Networks employing dynamic VLAN assignment (e.g., based on 802.1x or MAC-based authentication) can cause endpoints to move between VLANs and IPv6 subnets. As client operating systems do not always handle changes in link-layer state (e.g., VLAN changes) correctly, this mobility often leads to inconsistent IP stack behavior on operating systems, resulting in the persistence of old subnet addresses and potential connectivity issues due to incorrect source address selection. [ I-D.link-v6ops-gulla ] provides further analysis and potential solutions. ¶

7.3.5. Fragmentation

As the basic IPv6 header is 20 bytes longer than the IPv4 header, transating from IPv4 to IPv6 can result in packets exceeding the path MTU on the IPv6 side. In that case NAT64 creates IPv6 packets with the Fragment Header (see Section 4 of [ RFC6145 ] for more details. As per [ RFC6145 ] , by default the translator fragments IPv4 packets so that they fit in 1280-byte IPv6 packets. It means that all IPv4 packets larger than 1260 bytes are fragmented (or dropped if the DF bit is set). ¶

Administrators SHOULD maximize the path MTU on the IPv6 side (from the translator to IPv6-only hosts) to minimize fragmentation. NAT64 devices SHOULD be configured to use the actual path MTU on the IPv6 side when fragmenting IPv4 packets. ¶

Another common case of IPv6 fragmentation is the use of protocols like DNS and RADIUS, where the server response needs to be sent as a single UDP datagram. Network security policies MUST allow IPv6 fragments for permitted UDP traffic (e.g., DNS, RADIUS) where single-datagram responses are required. Allowing IPv6 fragments for permitted TCP traffic is RECOMMENDED unless the network infrastructure reliably performs TCP MSS clamping. ¶

7.3.6. Representing IPv6 Addresses by CLAT

Certain CLAT implementations face challenges when translating incoming IPv6 packets with native (non-synthesized) source addresses (e.g. ICMPv6 packets sent by intermediate hops on the path). This lack of standardized translation mechanisms can lead to: ¶

Incomplete Traceroute: Omission of IPv6-only hops between the endpoint and NAT64 translator, hindering troubleshooting. ¶

Path MTU Discovery Issues: Potential disruptions in the PMTU discovery process. ¶

[ I-D.equinox-intarea-icmpext-xlat-source ] proposes a solution for signalling the actual non-synthesized IPv6 source address while translating ICMPv6 error messages. ¶

7.3.7. IPv4-Dependencies in Network Admission Control

Certain layer 2 network devices (e.g., wireless access points, controllers) may enforce a policy where a host's network access is contingent upon successful DHCP IPv4 address assignment or tied to results of DHCP snooping. Consequently, hosts supporting Option 108 may experience network access denial or disconnection, as they are not assigned IPv4 addresses. ¶

7.3.8. Custom DNS Configuration on Endpoints

In IPv6-mostly networks without PREF64 in RAs, hosts rely on DNS64 ( [ RFC7050 ] to discover the NAT64 prefix for CLAT operation. [ RFC8880 ] requires that queries for AAAA resource records of "ipv4only.arpa." MUST be sent to the recursive resolvers provided by the network, not to the resolvers configured manually, local recursive resolvers etc. However some implementations do not comply with [ RFC8880 ] and, when configured with custom DNS resolvers (e.g., public or corporate DNS) may bypass the network-provided DNS64, preventing NAT64 prefix discovery and hindering CLAT functionality. ¶

Where feasible, administrators SHOULD include PREF64 in RAs within IPv6-mostly networks to minimize reliance on DNS64. Administrators need to be aware of the potential for CLAT failures when endpoints use custom resolvers in environments lacking PREF64. ¶

8. Security Considerations

The proposed deployment scenario inherits security considerations of IPv6 (see [ RFC9099 ] ). As IPv6-only device can not fall back to IPv4 if IPv6 connectivity is not available or impacted by a malicious actor. Therefore any attack affecting IPv6 connectivity would have much more drastic outcome, comparing to dual-stack networks. ¶

By signalling a rogue NAT64 prefix to a host, a malicious actor can: ¶

cause a DoS attack, if the network does not provide NAT64 functions (for that prefix or at all); ¶

implement MitM attack by intercepting traffic to the rogue prefix. ¶

To countermeasure this attack vector, the network administrators SHOULD configure the first-hop routers to include PREF64 information in Router Advertisements as per [ RFC8781 ] and ensure that layer 2 security measures such as RA-Guard ( [ RFC6105 ] ) are in place. Section 7 of [ RFC8781 ] discusses this topic in more details. Additionally, [ I-D.link-v6ops-claton ] discusses security implications of enabling CLAT if native IPv4 connectivity is available and recommends disabling CLAT in that case. ¶

Security considerations of using DHCP Option 108 are documented in Section 6 of [ RFC8925 ] . ¶

9. Privacy Considerations

This document does not introduce any privacy considerations. ¶

10. IANA Considerations

This memo does not introduce any requests to IANA. ¶

11. References

11.1. normative references, 11.2. informative references, acknowledgements.

Thanks to Ondrej Caletka, Brian Carpenter, Stuart Cheshire, Lorenzo Colitti, Jordi Palet, Michael Richardson, Matsuzaki Yoshinobu for the discussions, the feedback, and all contribution. ¶

Authors' Addresses