Archives for category: ipv6

Making long story about checking the IPv6 PMTU short, here is how you can check the Path MTU for a certain IPv6 destination in the cache:

ip -6 route get <address>


netstat -f inet6 -narlW | grep <address>

matjaz@macbook:~$ netstat -narWl -f inet6 | grep 2001:x:e813:
2001:x:e813:a00::d25      fe80::222:56ff:feba:21bf%en1    UGHW3Ii
         0        8   1400      en1   1378

sysctl -o net.inet.tcp.hostcache.list
(many thanks to Rui Paulo for this hint)

root@FreeBSD:~ # ping6 -m -s 5000 2001:xxxx:e813:a00::d25
PING6(5048=40+8+5000 bytes) 2001:xxxx:e811:b00:20c:29ff:fe78:31fb --> 2001:xxxx:e813:a00::d25
5008 bytes from 2001:xxxx:e813:a00::d25, icmp_seq=0 hlim=63 time=1.088 ms
5008 bytes from 2001:xxxx:e813:a00::d25, icmp_seq=1 hlim=63 time=0.903 ms
5008 bytes from 2001:xxxx:e813:a00::d25, icmp_seq=2 hlim=63 time=0.985 ms
--- 2001:xxxx:e813:a00::d25 ping6 statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 0.903/0.992/1.088/0.076 ms

root@FreeBSD:~ # sysctl -o net.inet.tcp.hostcache.list
2001:xxxx:e813:a00::d25  1400        0      0ms      0ms         0        0        0        0   11    1 3600

netsh interface ipv6 show destinationcache



IPv6 ULAs have a global scope, so when it comes to a default address selection in IPv6, longest prefix match criteria is used to chose a proper source IPv6 address to speak with the remote site within the same (global) scope.

I’ve discussed scopes and zones in one of my recent posts. I’ve mentioned IPv6 ULA in that context which was somehow misleading and well spotted in a comment by Roger Wilco, saying “Strictly speaking, ULA have global scope, and so the scope and zone math shouldn’t be required to be able to explain why an IPv6 host can want to speak with a remote globally routed address from a local ULA.” Absolutely true! Read the rest of this entry »

To SLAAC or not to SLAAC – what will it be? I might vote for SLAAC, slightly modified and used with IPv6 First Hop Security (FHS) with built-in monitoring.

Looking for a perfect solution for local IPv6 addressing which is stable, secure and private enough as well as easy to monitor? Read the rest of this entry »

When it comes to ULA, IPv6 gurus get nervous. Some hear NAT, and NAT is the most disgusting word in IPv6 vocabulary.

Well, ULA is not to be NAT-ed (look for Ivan’s ipSpace posts about ULA for more know-how), it can be used in a much smarter way – it can provide an internal connectivity in case when a site gets isolated from its basic networking services like DHCPv6, for example. Yes, these things can happen. Read the rest of this entry »

IPv6 is well designed. The model of scopes and zones along with the zone isolation principle is based on solid mathematical standards and can provide straight answers to tricky questions regarding packets with mixed source and destination address scopes. Can a packet with a link-local or ULA address reach the global destination? There is no doubt about that, at least not in IPv6 theory.

Ivan Pepelnjak was discussing the usage of ULA (Unique Local Addresses) recently in one of his blog post at ipSpace. He says: “If the destination IPv6 address is a global IPv6 address and the source host has an ULA address but no global IPv6 address, it tries to use the ULA source IPv6 address (and might reach the destination or not).”. To understand why this can actually work, it is necessary to have some insight about scopes and zone in IPv6, and the basic rules that dictate the packet forwarding within the scope zone. Read the rest of this entry »

ping6 can be a useful tool in troubleshooting MTU-related issues. Being IPv6 network operators we must known how it actually works with IPv6 in relation to fragmentation. Take you time and inspect the ping behaviour on your system and find a way how to examine your IPv6 destination cache. The know-how you will gain might come handy sometimes.

Troubleshooting MTU-related issues is a common task in IP network operations, IPv6 being no exception. A simple tool like ping is often used to discover MTU on the path between two hosts. When it comes to IPv6, fragmentation no longer happens in the network but only at the hosts. Hence, host (a sender) must be informed about the MTU for a certain destination. This is, of course, done by the routers on the path, which use ICMPv6 packet-too-big messages to inform the sender that packet is too big to dispatch. Hopefully these messages, which include the reduced MTU value, are received by the sender. This allows the sender to store the reduced MTU values in its IPv6 destination cache for a certain period of time. Read the rest of this entry »

Have you ever questioned yourself what happens when an IPv6 host wants to send a packet to a certain destination with a link-layer address unknown. In IPv4, finding a proper link-layer address for a certain IPv4 address is done by ARP. However, in IPv6, ARP is replaced by IPv6 Neighbour Discovery, ND for short. Instead of an ARP cache an IPv6 host maintains a Neighbour Cache (NC) with IP-to-link-layer address mappings. Each NC entry has a well-defined state, namely INCOMPLETE, REACHABLE, STALE, DELAY and PROBE. A host is capable of sending packets to a destination in all states except INCOMPLETE or when there is no corresponding NC entry. In INCOMPLETE state the data packets are queued pending completion of address resolution. Please, refer to RFC 4861 for more details. Read the rest of this entry »

No need to sacrifice a great protocol due to some privacy issues, better improve it!

IPv6 hosts can use IPv6 Stateless Address Autoconfiguration (SLAAC) to label themselves with one or more IPv6 addresses. These are composed of a network prefix advertised by a local router, and some kind of interface identifier. There are many security and privacy implications if such an identifier is globally unique — addresses with embedded hardware address being a perfect example. On the other hand these kind of addresses are stable, allowing for a higher degree of network control and manageability.
Users privacy can be significantly improved if the interface identifier is random and changes frequently. Such mechanisms, like Privacy Extensions for SLAAC (RFC 4941), can bring a nightmare to many network administrators.

DHCPv6 to the rescue!
Read the rest of this entry »

NAT is dead, long live NAT64! Well, just not for too long, OK?

It seems that implementation of some kind of IPv6 Transition Mechanisms is inevitable. IPv4 address space shortage will force many to use the networking evil – NAT. Stateful NAT64, accompanied by DNS64, looks very promising for well-behaved TCP/UDP services. The beauty of the beast comes from the fact that this type of transition technology is designed to fade away as native IPv6 is being fully deployed. Finally, it can be simply shutdown and decommissioned when most of the old IPv4-only servers are gone. Read the rest of this entry »

OSPF is used in numerous networks, it is well documented, well-known and widely tested in many scenarios. When IPv6 came along, good old OSPF which was used for IPv4 (OSPFv2), got a younger brother – OSPFv3. Many networks now run both protocols, one for IPv4 and the other for IPv6. This is getting more and more ridiculous, because OSPFv3 can be used to route IPv4 also.

See how this can be done with Cisco IOS and Juniper JUNOS. Read the rest of this entry »