Archives for the month of: January, 2014

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:

Linux
ip -6 route get <address>

linux-ipv6-dcache

OS X
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

FreeBSD
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
^C
--- 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
net.inet.tcp.hostcache.list:
IP address        MTU  SSTRESH      RTT   RTTVAR BANDWIDTH     CWND SENDPIPE RECVPIPE HITS  UPD  EXP
2001:xxxx:e813:a00::d25  1400        0      0ms      0ms         0        0        0        0   11    1 3600

Windows
netsh interface ipv6 show destinationcache

win7-ipv6-dcache

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 »

Juniper Junos OS is full of useful tricks. Here is one of them…

Apply-path is a really cool feature in Junos OS. With the apply-path statement you can expand a prefix list to include all prefixes pointed to by a defined path. This give you the ability to create dynamic prefix lists thus facilitates many configuration tasks like firewall filters and policy statements. 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 »

A very simple and lightweight ping/traceroute-capable host for your GNS3 LAB. Nice to have!

I’ve been using GN3/Dynamips occasionally to verify ideas in IP routing implemented with Cisco IOS. Whenever I needed to simulate a host within my setups I’ve used routers with IP routing disabled. However, this is a total waste of CPU which is rather valuable resource in a laptop-based GNS3 environment like mine. A simple and very lightweight PC simulator called VPCS comes very handy in situations where ping and traceroute are all you basically need to test your design and network behaviour. Read the rest of this entry »