one notable advantage of possessing expertise in IPv6 is the inherent distinction it maintains from IPv4, as they are entirely separate protocols.

take a moment to contemplate this concept. pay close attention to the notion of IPv6 being entirely separate protocol. in case of doubt, read this over again, but slower.

alternatively, consider adopting a thoughtful expression or jotting down this information for future reference, particularly for occasions when you find yourself engaged in a C-level panel discussion.

concrete impact illustrated by a practical example

a recent incident occurred a few hours ago that highlights the tangible implications.

in this scenario, we have a modest network where a Cisco 800 series router is responsible for delivering basic internet connectivity to a small home environment. the router incorporates simple Quality of Service (QoS) config and features a stateful firewall (ZBFW, Zone-Based Firewall). everything was functioning seamlessly until the Ambitious Administrator (myself, managing the router remotely) decided to perform some “fine-tuning” on the security mechanism by adjusting the configured Access Control List (ACL) attached to the internal interface.

as customary, I usually employ an ACL similar to the one outlined below for environments potentially accommodating 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
!

a common tactic employed by malware involves exploiting well-known ports such as 53, 80, and 443. however, a significant amount of poorly coded or malicious software tries to manipulate other ports—often ones that are not conventionally used—for the purpose of establishing outbound connectivity.

this gives rise to a pivotal (as some may say) concept within the realm of security filtering and hardening, which emphasizes the importance of rigorously scrutinizing traffic permitted to initiate outbound sessions.

in line with this philosophy, while in the process of introducing two new WLAN Access Points, I made the decision to augment the security measures. In the above-mentioned Access Control List (ACL), I decided to incorporate a supplementary set of rules. these rules are positioned immediately before the permit entry and follow the sequence of Access Control Entries (ACEs) detailed below:

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

as I was doing some adjustments, I anticipated a confirmation of the installation of two fresh Access Points connected to router directly. ordinarily, they attempt to acquire an IPv4 address using their default configurations. however, this time, both APs faltered in this endeavor—a predictable outcome, given that the majority of APs rely on DHCP to secure an IPv4 address.

even before remote users could voice their concerns about an underlying issue, I discerned an anomaly. while the APs were undoubtedly connected, I was unable to observe any 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

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

IPv6 FTW!

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.