You’ve learned about addresses, configuration, security, and routing. Now it’s time to get your hands dirty and build a working IPv6 network. Don’t worry, this isn’t a PhD dissertation — it’s a fun, step-by-step sandbox where you’ll see IPv6 come alive.

Whether you’re a student, hobbyist, or networking professional, this chapter will help you spin up your own mini IPv6 lab in no time.

What You’ll Need

Hardware (or Virtual Setup):

• A computer or laptop (Windows, macOS, or Linux)
• Optional: a second device for testing (another laptop, VM, Raspberry Pi)
• VirtualBox, VMware, or WSL for virtual lab environments

Software Tools:

• Packet Tracer (great for Cisco-style simulation)
• Wireshark (for packet analysis)
• Ping, Traceroute, and ip or ifconfig commands
• A router (real or simulated) that supports IPv6

Optional:

• Access to an ISP that supports IPv6
• Tunnel broker (like Hurricane Electric) if your ISP doesn’t

Lab Objective

You will:

• Enable IPv6 on your devices
• Set static and dynamic IPv6 addresses
• Test local and global connectivity
• Observe Neighbor Discovery Protocol
• Capture and inspect IPv6 packets

Step-by-Step: Your First IPv6 Lab

Step 1: Enable IPv6

• Most systems have it on by default.
• Confirm with:ip a (Linux) ifconfig (macOS) ipconfig /all (Windows)

Step 2: Configure Static IPv6 Addresses

Assign each device a unique address in the same subnet:

Device 1: 2001:db8:1::1/64
Device 2: 2001:db8:1::2/64
Gateway:  2001:db8:1::ffff/64

Use /64 as the subnet prefix length.

Step 3: Test Connectivity

• Use ping6 or ping -6:ping6 2001:db8:1::2
• Try traceroute6 or tracert -6 to see the route.

Step 4: Observe NDP in Action

• Use Wireshark to capture RA, RS, NS, and NA messages.
• Filter for icmpv6 to see IPv6-specific discovery traffic.

Step 5: Add DHCPv6 or SLAAC

• Simulate a router sending RAs.
• Use radvd (Linux) or router config in Packet Tracer.
• Watch your host self-configure via SLAAC.

Step 6: Connect to the World

• If you have IPv6 Internet:ping6 ipv6.google.com
• If not, set up a tunnel with Hurricane Electric:
  • Sign up for a free tunnel
  • Configure interface and routing

Tips for a Successful Lab

Real-World Benefit

Doing this lab proves to yourself and others that you understand IPv6 — not just in theory, but in practice. It also prepares you for interviews, certifications, or troubleshooting live networks.

Coming Up Next

Now that you’ve built an IPv6 network, we’ll finish our course by exploring real-world IPv6 adoption: who’s using it, who’s dragging their feet, and what’s coming next.

Quick Quiz: Check Your Knowledge!

1. What is the prefix length commonly used for an IPv6 subnet?
   • a) /32
   • b) /48
   • c) /64
2. Which tool is used to capture and analyze IPv6 traffic?
   • a) Ping
   • b) Wireshark
   • c) Curl
3. True or False: IPv6 and IPv4 can run at the same time on the same device.
4. Bonus: Name one command you can use to view your current IPv6 address.

📚 Answer Key: Chapter 8 Quiz

1. Which protocol is designed to help secure Neighbor Discovery?
✅ Answer: b) SeND

2. True or False: IPv6 automatically encrypts all traffic using IPsec.
❌ Answer: False

3. What is a common threat involving fake Router Advertisements?
✅ Answer: b) Rogue RA Attack

4. Bonus: IPv6 security advantage?
✅ Sample Answer: IPsec support is built-in and standardized.

The post Mastering IPv6: A Complete Guide – Chapter 9: Build Your First IPv6 Lab — From Zero to Dual Stack Hero appeared first on IPv6.net.

The post Architecting Azure (I)IoT Solutions @ IoT Saturday 2019 appeared first on IPv6.net.

A client asked me to do this configuration because they did not have the resources to it themselves. No problem. I have been working with LoRa and Kerlinks for a while now doing a consultancy job for another client (a big telco). They did not want to connect the Kerlink to their local network for security reasons. They wanted to add their gateway to TheThingsNetwork.org (TTN), a global open crowdsourced Internet of Things data network that started in The Netherlands. Reading the forums, I noticed that many trying to do the same have run into issues. The documentation is sometimes incomplete and scattered so it takes a bit of effort to get it to work.

IoT lab at the home office
[the_ad id=”956129″]

The task at hand:

Configure a Kerlink IoT station to use its GPRS/3G modem as its uplink path and connect it to TheThingsNetwork.org. The SIM provided was a PukData M2M SIM which uses the KPN mobile network in The Netherlands.
Normally, the Kerlink will use its  ethernet (eth0) uplink as its default path. The basic idea here is that, if configured correctly, an autoconnect mechanism will trigger the GPRS bearer, establishes a PPP connection and set a default route and DNS.
I had already installed the TTN firmware with the polypacket forwarder on the Kerlink and got it to work using the ethernet uplink. I used a LoRaMote to check if packets actually showed up in the TTN api. For the next step, I basically followed the GPRS/3G guide on the TTN Wiki  which boils down to:

• Set the GPRS options to match your SIM and telco’s APN settings (i.e. APN name, pincode, username and password).
• Configure auto connect in the knet monitor.
• Set the bearers priority.
• Because no username/password is set for this APN, and empty username/password fields trigger a bug, I also installed the patched GPRS init script.

 
[the_ad id=”956129″]

I ran into a couple of things so these considerations may be useful:

• If your SIM comes with a pin code (usually 0000), set it with ‘GPRSPIN=<your pin here>’.
• If your APN username and password are to be left empty, replace the GPRS init script with the patched version as mentioned at the bottom of the guide.
• Carefully choose your ip_link address in /knet/knetd.xml depending on your requirements. This address is pinged periodically to determine if the GPRS auto connect needs to be activated. In my case I wanted one that is only reachable over the GPRS APN (e.g. for KPN use their DNS server: 194.151.228.34) to force it to bring up the ppp0 interface whenever possible. If you’re using GPRS as a backup path this should be different (I guess an address only reachable via eth0 but make sure the PPP session is terminated as soon as the primary path becomes available again). Use tcpdump (e.g. tcpdump -i ppp0 -n -v port 1700 or icmp) to check if it is pinging the correct address and if status updates are sent.
• I chose not to use peerdns (GPRSDNS=no) because the default DNS servers are not restored in case of a GPRS connection failure, thus breaking eth0 as a fallback path. I used the Google public DNS servers in stead as they work on both paths. This could also be fixed in /etc/ppp/ip-down.
• Remember that your default gateway will be set to the ppp0 interface whenever that interface comes up. You may want to be able to connect through eth0 for maintenance…
• The (poly) packet forwarder needs to be restarted whenever there is an interface change to make sure it binds to the right source address. If it isn’t you will see packets going out the ppp0 interface with the eth0 source address (or vice versa). I added ‘/usr/bin/killall poly_pkt_fwd’ to /etc/ppp/ip-up and /etc/ppp/ip-down.
• The firewall is not enabled by default. Make sure to edit /etc/init.d/firewall to your needs and turn it on in /etc/sysconfig/network (FIREWALL=yes). Don’t forget IPv6 although dropbear for instance does not listen on a v6 socket.

Tests to do to make sure it all works:

• Check if the gateway is still active (is sending status updates) and node messages are received in the TTN API after unplugging the ethernet uplink cable. If you’re using an ethernet power injector, make sure to unplug the cable going into the injector rather than the one going out to the Kerlink. Duh! 😉 Remember that you can’t log in to the gateway anymore, assuming access to the GPRS/3G address is blocked.
• Plug the ethernet cable back in and see if you can log in again. Then check if updates/messages are still being sent over the ppp0 interface using tcpdump.
• Power cycle the Kerlink while leaving the ethernet uplink cable unplugged. This will make sure the Kerlink will boot successfully in stand-alone mode, which was the whole purpose of this exercise.

[the_ad id=”956129″]

Configuration:

/etc/sysconfig/network:

 # Selector operator APN
 GPRSAPN=internet.access.nl
 # Enter pin code if activated
 GPRSPIN=0000
 # Update /etc/resolv.conf to get dns facilities
 GPRSDNS=no
 # PAP authentication
 GPRSUSER=
 GPRSPASSWORD=
 # Bearers priority order
 BEARERS_PRIORITY="ppp0,eth0,eth1"

/knet/knetd.xml:

<!-- ############## connection parameters ############## -->
<!-- nb of second to retry to connect to server if connection failed-->
<CONNECT retry_timeout="10" />
<!-- port nunmber for local application kms connection -->
<CONNECT kms_port="35035" />
<CONNECT auto_connection="YES" />
<!-- frequency of connection monitoring -ping- (in seconds) -->
<CONNECT link_timeout="30"/>
<!-- DNS servers will be pinged if commented or deleted. Some operators can block the ping on there DNS servers -->
<CONNECT ip_link="194.151.228.34"/>

Questions?

Don’t hesitate to leave a comment below or send a message.

The post How to configure the Kerlink IoT Station for GPRS/3G uplink connectivity appeared first on IPv6.net.

The post OSPF IPV6 (Darija) appeared first on IPv6.net.

The post 8.2.5.5 Lab – Configuring IPv6 Addresses on Network Devices appeared first on IPv6.net.

The post HELP! I need to understand IPv6! appeared first on IPv6.net.

The post IPv4/IPv6 fragmentation, TTL concepts & verification CCNP 300-101 (V-72) appeared first on IPv6.net.

The post IPv6 brewed coffee demo from Nordic Semiconductor appeared first on IPv6.net.

The post IPv6 subnetting appeared first on IPv6.net.

The post 7.4.3.5 Lab – Configuring Basic EIGRP for IPv6 appeared first on IPv6.net.