In Part 2 we did the initial ISATAP configuration for our Cisco router. Here we’ll show the config we use on our Windows clients and server.
netsh interface isatap set router 203.0.113.30 netsh interface isatap set state enabled
Normally I tell system admins to never hard-code IP addresses into their application; always use DNS names! In fact, by default the Microsoft ISATAP stack will try to connect to the ISATAP router at isatap.enterprise-domain.local (the “enterprise-domain.local” is the suffix used by the client, usually sent via DHCP.) Windows will also try to learn the ISATAP router address by employing Link-Local Multicast Name Resolution (LLMNR) [RFC4795] to resolve the name “isatap”.
I think this is different. This is programming the network infrastructure to be configured in a particular deterministic way. We wouldn’t configure our default gateway with a FQDN. We don’t configure our BGP peers with a FQDN. This is the same thing and here I use the raw IP address.
We can inspect the config with the following.
Windows PowerShell Copyright (C) 2013 Microsoft Corporation. All rights reserved. PS C:Windowssystem32> netsh interface isatap show state ISATAP State : enabled PS C:Windowssystem32> netsh interface isatap show router Router Name : 203.0.113.30 Use Relay : default Resolution Interval : default
We now find ourselves with the config show in the diagram.
All these addresses are auto-generated with a link-local prefix of FE80::5EFE/96. The last 32-bits is the IPv4 address of the device. The IPv4 network acts as the link layer for our new ISATAP IPv6 network. You could say, using the current popular terms, ISATAP is the overlay and IPv4 is the underlay.
If a workstation wants to send an IPv6 packet to the server at FE80::5EFE:C633:6419 it simply decodes the last 32-bits into the IPv4 address needed to deliver the packet. This is why the ISATAP address is sometimes printed FE80::5EFE:198.51.100.25 for easy readability. We use 198.51.100.25 in the underlay to get to our destination FE80::5EFE:C633:6419.
Keep in mind, the link layer (IPv4) does not support broadcasts. So our ISATAP network is a Non-Broadcast Multiple Access (NBMA) network. This is why an ISATAP node can’t perform a neighbor discovery (ND) broadcast to find the link-layer address of its peer; it deduces the link-layer address from the lower 32-bits of the IPv6 address. It also can’t perform ND for the default router, which is why we statically program it into the host.
We can now route packets around our subnet using the lower 32-bits to find our link-layer address—no ND needed. We can also know our default gateway through static configuration. None of this does us any good if we’re stuck on FE80::5EFE/96 without a Global Unicast Address. Part 4 will fill in the missing piece.