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 »

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 »

Granular, efficient and distributed firewalling based on good old BGP.

BGP can carry many different network-related information, sometimes described as address families or NLRI (Network Layer Reachability Information). One of them is FlowSpec (RFC 5575), which allows BGP to propagate a filter for a specific IPv4 packet flow. A flow, which is defined by an n-tuple, like a combination of source and destination IP address, protocol number and ports, can be discarded, rate-limited, redirected to some analysis or mitigation device etc. BGP is simply used to signal the routers to perform appropriate filtering actions for a certain flow. Read the rest of this entry »

Using Cisco ACLs to match routing prefixes or just to mystify the configuration?

A decade ago route classification or filtering in Cisco IOS was commonly done with the help of access control lists (ACLs). You will still find this method in some (very) old configurations and Cisco trainings (no matter how advanced they are ;-)). I’ve run into this legacy stuff recently and I was forced once again to understand how it works. It is confusing but rather simple.

An entry in the extended IPv4 ACL has the following meaning:

permit|deny ip <network> <wildcard mask of network> <subnet mask> <wildcard mask of subnet mask>

The “source” part of the rule selects the prefixes and the “destination” part selects prefix masks (prefix lengths). 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 »

Rarely used feature, but it might come in handy.

In the following scenario a service provider AS 1 has a customer which is using a private AS 65000 within his network. The customer has just received their own AS number and they are planning to migrate from the private one. Theirs intention is to introduce the new AS gradually and keep the old peerings with the private AS up and running during the migration.
What a customer needs is a feature that will allow a router to replace their own AS number with another one in the eBGP updates.
Read the rest of this entry »