Back on April 9 through the 11th was the North American IPv6 Summit in Denver, CO. I presented on "Advanced IPv6 design and deployment items for
enterprise networks that are Microsoft technology focused" and my presentation is now posted up on the site.
In addition to presenting I also had the opportunity to build out the Cisco wireless network that was used for the conference. It was an interesting experience due to the fact that the wireless was dual stacked and we made SSID's available for each of the carriers brought in for the conference. To top it off, we also made IPv6 only SSID's for each of the carriers allowing conference attendees the chance to test out what IPv6 only connectivity was like. Of course the other SSID's were dual stacked.
The Cisco Wireless LAN Controller required the newest software release of 7.2.103 in order to properly support IPv6. After a few early bumps (and reboots) everything worked as expected and we had several hundred folks up and running on wireless for the duration of the conference. Some interesting IPv6 deployment caveats came out from doing this work. First, due to older Mac OSX and Linux clients not having a DHCP client in the OS it meant that we ended up having to run both DHCPv6 and SLAAC on the same network. Effectively were had to set the A, M and O flags all at the same time. This meant that Windows 7 client machines ended up with three global unicast IPv6 addresses and their link local addresses. One from DHCPv6, one from a the privacy address that is dynamically built (instead of EUI-64) and a temporary address built for the random privacy address to do outbound sessions. Mac OSX and Linux clients built out SLAAC EUI-64 addresses as expected but were unable to obtain DNS information unless they ran a DHCPv6 client as we did not have RFC 6106 set up at all.
Overall, it was functional, but far from perfect. Given we had less then 8 hours to turn the whole thing up I was not disappointed because we had a working network built by a diverse group of engineers who all came together in one day. I would consider that a pretty impressive feat.
- Ed
Howfunky...a place with useless technical content!
Showing posts with label Wireless. Show all posts
Showing posts with label Wireless. Show all posts
Thursday, May 31, 2012
Monday, February 15, 2010
Why you should consider building your entire network assuming guestnet access
I believe for many SMB and enterprise networks it makes sense to evaluate what you are providing to you staff, how you are providing it and why. With the recent shift to wireless and cloud services it is time to reevaluate that again.
With wireless becoming an expected service at all enterprise location and for some SMB's the only access it makes sense to be able to authenticate who the user is prior to granting them access to the network. With 802.1x it is possible to do this with an open standard that has cross vendor support. Having this basic functionality in place allows for the possibility of providing guestnet services automatically (self provisioned or pre-defined.)
The next logical question is, should you be authenticating on wired ports also to provide the exact same services with the same posture and guestnet ability. I would argue a case for this and from a posture and security standpoint say that if you are doing it for wireless but not wired your wireless is more secure than you wired implementation. Would love to hear thoughts on that one.
By mixing cloud services (host mail, wiki or portal access, file storage) with guestnet and authenticated access you can provide services to your end users regardless of network topology assuming the network is providing Internet access.
To add to the benefit, you can do remediation and fix machines that don't meet certain posture profiles if you wish to go that far. That means utilizing a more robust solution like Microsoft NAP or Cisco NAC or using a solution that can leverage both like Avenda.
With all this available today it makes sense to plan the whole network infrastructure such that guestnet and authenticated network access is done everywhere. There might be exceptions, your data center core, dmz, storage and edge networks may not require the same services but should likely have port security at a minimum as you are unlikely to be moving servers or network devices around once an initial deployment is done.
Some food for thought in the network design area, maybe some design changes are in order?
- Ed
With wireless becoming an expected service at all enterprise location and for some SMB's the only access it makes sense to be able to authenticate who the user is prior to granting them access to the network. With 802.1x it is possible to do this with an open standard that has cross vendor support. Having this basic functionality in place allows for the possibility of providing guestnet services automatically (self provisioned or pre-defined.)
The next logical question is, should you be authenticating on wired ports also to provide the exact same services with the same posture and guestnet ability. I would argue a case for this and from a posture and security standpoint say that if you are doing it for wireless but not wired your wireless is more secure than you wired implementation. Would love to hear thoughts on that one.
By mixing cloud services (host mail, wiki or portal access, file storage) with guestnet and authenticated access you can provide services to your end users regardless of network topology assuming the network is providing Internet access.
To add to the benefit, you can do remediation and fix machines that don't meet certain posture profiles if you wish to go that far. That means utilizing a more robust solution like Microsoft NAP or Cisco NAC or using a solution that can leverage both like Avenda.
With all this available today it makes sense to plan the whole network infrastructure such that guestnet and authenticated network access is done everywhere. There might be exceptions, your data center core, dmz, storage and edge networks may not require the same services but should likely have port security at a minimum as you are unlikely to be moving servers or network devices around once an initial deployment is done.
Some food for thought in the network design area, maybe some design changes are in order?
- Ed
Subscribe to:
Posts (Atom)