one of the benefits of having (and master) IPv6 is the fact, that it’s completely separate protocol from IPv4.
please take a moment to think about it now. take special care about completely separate protocol. in case of doubt, read this again but slower.
you can also make smart face or write it down and use next time you’re on some kind of C-level panel.
this just happened, couple of hours ago.
there’s small network, with Cisco 800 series router providing simple internet access for small home. there’s simple QoS, stateful firewall (ZBFW). everything worked correctly until Ambitious Administrator (that’s me, managing the router remotely) decides to “tune up a bit” security mechanism configured and ACL attached to internal interface. “traditionally” I use ACL similar to one below for any environments that can potentially contain Windows based devices:
! interface Vlan10 description LAN interface ip address 192.168.0.1 255.255.255.0 ip verify unicast source reachable-via rx ip access-group acl-lan-fw in ! ip access-list extended acl-lan-fw deny tcp any any range 135 139 deny udp any any range 135 139 deny tcp any range 135 139 any deny udp any range 135 139 any deny tcp any any eq 445 deny udp any any eq 445 deny tcp any eq 445 any deny udp any eq 445 any permit ip any any !
while most of the malware anyway uses ports 53, 80 and 443, there is ton of badly written or malicious software that “tries” to exploit other, typically not used ports to enable outbound connectivity.
so there’s whole concept in security filtering/hardening world, to also filter strictly traffic allowed to create outbound sessions.
so, while deploying two new WLAN Access Points there, I decided also to configure set of additional rules, that in the above ACL just before
permit entry, use following sequence of ACEs:
[...] deny tcp any any range 0 0 deny udp any any range 0 19 deny tcp any any range 26 52 deny udp any any range 26 52 deny tcp any any range 54 79 deny udp any any range 54 79 [...]
do you see the problem? I completely missed it initially.
of course, as that’s the only router in couple of kilometers radius, apart from security services it provides DHCP service for local network - dynamic IPv4 addressing service. DHCP is a protocol that unfortunately for me, uses ports 67 and 68.
I was doing some adjustments and waiting to get a confirmation that installation of two new Access Points based on Cisco autonomous IOS were installed, connected directly to router. they try to get IPv4 address in default configuration and both of them failed to do so this time (no suprises here, most of the APs try to get IPv4 address via DHCP). even before remote users were able to say that’s something is wrong, I noticed while the APs are connected, I can’t see IPv4 addresses assigned to them.
because both APs were connected directly, I could check the addresses over CDP:
rtr#sh cdp neighbors detail ------------------------- Device ID: ap1.remote.home Entry address(es): IPv6 address: FE80::DB53:44FF:FE5A:C948 (link-local) Platform: cisco AIR-SAP3702I-E-K9, Capabilities: Trans-Bridge Source-Route-Bridge IGMP Interface: GigabitEthernet5, Port ID (outgoing port): GigabitEthernet0 Holdtime : 157 sec Version : Cisco IOS Software, C3700 Software (AP3G2-K9W7-M), Version 15.3(3)JPK1, RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2021 by Cisco Systems, Inc. Compiled Tue 30-Mar-21 12:05 by prod_rel_team advertisement version: 2 Duplex: full Power drawn: 15.400 Watts Power request id: 18976, Power management id: 0 Power request levels are:16800 15400 13000 0 0
that looked oddly but as I couldn’t really ask users to fire up console and do any kind of serious debugging, it was almost “OK, so lets cry for a moment, and then ask them to send me the APs back”. fortunately, default Cisco IOS configuration contains following part:
! interface BVI1 ip address dhcp client-id GigabitEthernet0 ipv6 address dhcp ipv6 address autoconfig ipv6 enable !
thanks to that, AP is trying to acquire address using two protocols independently - IPv4 and IPv6. so if you were quick, you did spot IPv6 address assigned above in the CDP output:
rtr#sh cdp neighbors detail [...] IPv6 address: FE80::DB53:44FF:FE5A:C948 (link-local) [...]
at that moment, router didn’t have even IPv6 tunnel configured, but it was easy just to enable IPv6 autoconfiguration on the router inside interface to be able to reach out to APs over IPv6:
rtr#conf t rtr(config)#interface vlan 10 rtr(config-if)#ipv6 enable rtr(config-if)#^Z
…over at link-local address:
rtr#telnet FE80::DB53:44FF:FE5A:C948 /source-interface vlan 10 Trying FE80::DB53:44FF:FE5A:C948 ... Open User Access Verification Username: login Password: password ap1.remote.home>
only at that point I realized, that if IPv6 works and IPv4 doesn’t hand out addresses, likely something is filtered along the way… and fixed my ACL.
AP (and users) could get IPv4 addresses and start to use internet connectivity. because local ISP doesn’t provide IPv6 yet, I configured also IPv6 tunnel with help of Hurricane Electric service.
one way or another - enable IPv6, play with different features and of course make sure to secure/firewall this protocol as well. bots looking for services do that today also with IPv6, so while with IPv4 NAT may seem as a good protection (but it isn’t), you should take care of your network hygiene.