# Using Case Sensitive IPv6 Addressing on a Palo Alto

IPv6 brings us enough addresses until the end of the world. Really? Well… No. There was an interesting talk at RIPE77 called “The Art of Running Out of IPv6 Addresses” by Benedikt Stockebrand that concludes that we will run out of IPv6 addresses some day.

Luckily Palo Alto Networks has already added one feature to expand the IPv6 address space by making them case sensitive. That is: you can now differentiate between upper and lower case values “a..f” and “A..F”. Instead of 16 different hexadecimal values you now have 22 which increases the IPv6 space from $2^{128}$ to about $2^{142}$. Here is how it works on the Palo Alto Networks firewall:

# Load Balancing NTP via F5 BIG-IP LTM

As you hopefully already know, you should use at least three different NTP servers to get your time. However, there might be situations in which you can configure only one single NTP server, either via static IP addresses or via an FQDN. To overcome this single point of failure you can use an external load balancing server such as F5 LTM (in HA of course) to forward your NTP queries to one of many NTP servers. Here are some hints:

# NTP Server via GPS on a Raspberry Pi

This post shows how to use a GPS receiver with a Raspberry Pi to build a stratum 1 NTP server. I am showing how to solder and use the GPS module (especially with its PPS pin) and listing all Linux commands to set up and check the receiver and its NTP part, which is IPv6-only in my case. Some more hints to increase the performance of the server round things off. In summary this is a nice “do it yourself” project with a working stratum 1 NTP server at really low costs. Great. However, keep in mind that you should not rely on such projects in enterprise environments that are more focused on reliability and availability (which is not the case on self soldered modules and many config file edits).

# NTP Server via DCF77 on a Raspberry Pi

In this tutorial I will show how to set up a Raspberry Pi with a DCF77 receiver as an NTP server. Since the external radio clock via DCF77 is a stratum 0 source, the NTP server itself is stratum 1. I am showing how to connect the DCF77 module and I am listing all relevant commands as a step by step guide to install the NTP things. With this tutorial you will be able to operate your own stratum 1 NTP server. Nice DIY project. ;) However, keep in mind that you should only use it on a private playground and not on an enterprise network that should consist of high reliable NTP servers rather than DIY Raspberry Pis. Anyway, let’s go:

# Packet Capture: Network Time Protocol (NTP)

What’s the first step in a networker’s life if he wants to work with an unknown protocol: he captures and wiresharks it. ;) Following is a downloadable pcap in which I am showing the most common NTP packets such as basic client-server messages, as well as control and authenticated packets. I am also showing how to analyze the delta time with Wireshark, that is: how long an NTP server needs to respond to a request.

I got an email where someone asked whether I know how to change the link-local IPv6 addresses on a FortiGate similar to any other network/firewall devices. He could not find anything about this on the Fortinet documentation nor on Google.

Well, I could not find anything either. What’s up? It’s not new to me that you cannot really configure IPv6 on the FortiGate GUI, but even on the CLI I couldn’t find anything about changing this link-local IPv6 address from the default EUI-64 based one to a manually assigned one. Hence I opened a ticket at Fortinet. It turned out that you cannot *change* this address at all, but that you must *add* another LL address which will be used for the router advertisements (RA) after a reboot (!) of the firewall. Stupid design!

# SharkFest’18 Europe: Crash Course: IPv6 and Network Protocols

I did a session at SharkFest’18 Europe in Vienna with the title of “Crash Course: IPv6 and Network Protocols“. Since the presentation slides + audio were recorded you can listen to the talk, too. Here are some notes about the motivation for this session as well as feedback from the attendees.

# My CCNP TSHOOT Lab: The Overall Picture

During the last few weeks I published a couple of blogposts concerning routing protocols such as BGP, OSPFv3, and EIGRP. (Use the “Cisco Router” tag on my blog to list all of them.) They are all part of my current Cisco lab that I am using for my CCNP TSHOOT exam preparation. While I depicted only the details of the routing protocols in those blogposts, I am showing my overall lab with all of its Cisco IOS configs here. Just to have the complete picture. There are a couple of not-yet-blogged configs such as VRRP, GLBP, NTP authentication, embedded event manager (EEM), or route-maps and distribute/prefix lists though.

# EIGRP Capture

And again: Here comes a pcapng capture taken for the dynamic routing protocol EIGRP. If you want to dig into EIGRP messages, download the trace file and browse around it with Wireshark. Since I used both Internet Protocols (IPv6 and legacy IP), MD5 authentication, route redistribution, etc., you can find many different messages in it.

# Dual-Stack EIGRP Lab

Yet another routing protocol I played with in my lab. ;) This time: EIGRP, Enhanced Interior Gateway Routing Protocol, the proprietary distance-vector routing protocol developed by Cisco, which is now public available (RFC 7868). However, no third-party products in here but only Cisco routers. I am using named EIGRP for both Internet Protocols, IPv6 and legacy IP, along with MD5 authentication and redistribution from OSPF.

# OSPFv3 with IPsec Authentication

Here comes a small lab consisting of three Cisco routers in which I used OSPFv3 for IPv6 with IPsec authentication. I am listing the configuration commands and some show commands. Furthermore, I am publishing a pcapng file so that you can have a look at it with Wireshark by yourself.

# MP-BGP Capture

For those who are interested in analyzing basic BGP messages: I have a trace file for you. ;) It consists of two session establishments as I cleared the complete BGP session on two involved routers for it. Refer to my previous blogpost for details about the lab, that is: MP-BGP with IPv6 and legacy IP, neighboring via both protocols as well, with and without password. The involved routers were 2x Cisco routers, one Palo Alto Networks firewall, and one Fortinet FortiGate firewall.

# Basic MP-BGP Lab: Cisco Router, Palo Alto, Fortinet

While playing around in my lab learning BGP I configured iBGP with Multiprotocol Extensions (exchanging routing information for IPv6 and legacy IP) between two Cisco routers, a Palo Alto Networks firewall, and a Fortinet FortiGate firewall. Following are all configuration steps from their GUI (Palo) as well as their CLIs (Cisco, Fortinet). It’s just a “basic” lab because I did not configure any possible parameter such as local preference or MED but left almost all to its defaults, except neighboring from loopbacks, password authentication and next-hop-self.

# 2001:db8::/32 in the Wild

If you have ever read some docs or RFCs about IPv6 you should be quite familiar with the 2001:db8::/32 “IPv6 Address Prefix Reserved for Documentation”, RFC 3849. This RFC clearly states how you should handle addresses within this range: “This assignment implies that IPv6 network operators should add this address prefix to the list of non-routeable IPv6 address space, and if packet filters are deployed, then this address prefix should be added to packet filters.”

I was interested whether those addresses are actually used in the Internet. For this purpose I analyzed my firewall logs for 6 months to get an idea. Though it was not that much, I actually got a couple of connections inbound and outbound (!) sourced or destined to those reserved IPv6 addresses.

# IPv6 Interface ID Structure

While there are many approaches on how to structure your IPv6 prefix into /64 subnets (blogposts, books, talks) there are only a few hints what you can do with the other 64 bits of the addresses, namely the IPv6 interface identifier or IID. To my mind you can put some (but not too much) logic into those IIDs to a) have some structure for your addresses that b) helps you identifying those addresses when seeing them in logs or anywhere else. Hence it is easier for you to remember the IPv6 address behind a name (forward DNS) as well as the host when seeing the address (reverse DNS).

This post just shows the approach I am using in my lab. You might find it useful or you might disagree completely. Anyhow, feel free to comment your experiences or solutions for that. :D I am wondering why there isn’t much discussion about these IIDs at all. Maybe for some good reasons I am not seeing yet?