RFC3927’s title is Dynamic Configuration of IPv4 Link-Local Addresses, and it describes how a host can automatically configure itself with an IPv4 address to communicate with other hosts on the same local link, when no statically configured IP address or DHCP server is available. The IPv4 address space set aside for this is 169.254.0.0/16. Just as RFC1918 defines addresses that can be used for private, routed networks, the addresses in RFC3927 are also private, but even more restricted than those in RFC1918. The addresses from RFC1918 (10/8, 172.16/12 and 192.168/16) will be dropped by any Internet-connected router. The only way to get traffic from a host with an RFC1918 address out on the Internet is through the use of Network Address Translation. On your own network, however, RFC1918 addresses work just as public addresses and can be routed etc. But addresses from RFC3927 will not be routed anywhere, they are what is know as link-local addresses and only facilitate communications on the same link. No router will forward RFC3927 addresses. You can test this yourself by leaving your computer set to receive a dynamic IP from a DHCP server, and then making sure that no DHCP server is available, but that your still have a network link. If your computer is RFC3927 compliant it will configure itself with an address in the 169.254.0.0/16 range. RFC3927 defines rules for how to choose an address and make sure your host can keep it once other hosts connect to the same link as you, but it is beyond this post to recite the RFC. Now let’s look at how RFC3927 pertains to Microsoft Azure.

In fact, it is very straight forward. RFC3927s 169.254.0.0/16 addresses are blocked from use in Azure on:

• Azure Virtual Networks
  Only RFC1918 IPv4 addresses are valid on Azure vNets
• Local network sites
  Both RFC1918 IPv4 addresses and any public IPv4 addresses you may own, unless they are in conflict with already configured network resources in Azure, can be used.
• Gateway subnets
  Technically a part of an Azure address space so the same rules apply as for vNets.
• P2S subnets
  Only RFC1918 IPv4 addresses allowed

The only place in Azure that the RFC3927 addresses are in use is inside S2S VPN tunnels. When you download S2S configuration scripts from the Azure portal you will find references to 169.254.0.0/16. As in this example for the Cisco ISR template:

int tunnel 1
ip address 169.254.0.1 255.255.255.0
  ip tcp adjust-mss 1350
tunnel source <NameOfYourOutsideInterface>
tunnel mode ipsec ipv4
tunnel destination 137.135.242.240
tunnel protection ipsec profile vti

And here on a Windows Server 2012 R2 RRAS server you can see it in the IP properties of the PPP Link adapter:

PPP adapter 23.101.xx.yy:

   Connection-specific DNS Suffix  . :
Description . . . . . . . . . . . : 23.101.xx.yy
Physical Address. . . . . . . . . :
DHCP Enabled. . . . . . . . . . . : No
Autoconfiguration Enabled . . . . : Yes
Autoconfiguration IPv4 Address. . : 169.254.0.35(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . :
DHCPv6 IAID . . . . . . . . . . . : 587208029

So in summary, the only place you will find these addresses in Azure are inside your S2S VPN tunnels. Now you know what those strange addresses are doing there…