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.

practical effects on practical example

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
 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.

internet gateway with services

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:
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

where’s my IPv4?!

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

…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


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.