IPv6 examples using invalid internal addresses

[timriker]

trafficstars

Template files

• ipv6-in-vnet/azuredeploy.json
• ipv6-in-vnet-StdLB/azuredeploy.json
• ipv6-in-vnet-vmss/azuredeploy.json

Documentation Examples:

https://docs.microsoft.com/bs-latn-ba/azure/virtual-network/ipv6-configure-template-json https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-ipv4-ipv6-dual-stack-powershell https://docs.microsoft.com/bs-latn-ba/azure/virtual-network/ipv6-add-to-existing-vnet-cli

Issue Details

These use the IPv6 address space:

ace:cab:deca::/48

ipv6 addresses for internal networks which appear to be reserved addresses.

https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml

Internal networks should use Unique Local address space:

fc00::/7

All templates and training materials should be updated to avoid using reserved address space. Azure internal networks are not routable so Unique Local address space seems appropriate.

fcce:cab:deca::/48 would work. Not sure where the current invalid ipv6 space came from. It would be better to to generate a unique Global ID which might then allow different groups to route traffic eventually. Perhaps suggest internal space based on some part of the UUID of the VNET?

https://tools.ietf.org/html/rfc4193

If the examples move to Unique Local Addresses, the deployed OS will prefer IPv4 over IPv6 for getaddressinfo() as in RFC-6724 (was RFC-3484)

https://tools.ietf.org/html/rfc6724

On Ubuntu, this means editing /etc/gai.conf where I uncommented this lines:

label ::1/128       0
label ::/0          1
label 2002::/16     2
label ::/96         3
label ::ffff:0:0/96 4
label fec0::/10     5

[denisbrodbeck]

I agree, Admins/Devs should be made aware, that they should use a ULA (Unique Local Address) space, when assigning ipv6 address space to their virtual networks. Emphasis on unique.

Here's what RFC 4193 says:

3.2.1. Locally Assigned Global IDs

Locally assigned Global IDs MUST be generated with a pseudo-random algorithm consistent with [RANDOM]. Section 3.2.2 describes a suggested algorithm. It is important that all sites generating Global IDs use a functionally similar algorithm to ensure there is a high probability of uniqueness.

The use of a pseudo-random algorithm to generate Global IDs in the locally assigned prefix gives an assurance that any network numbered using such a prefix is highly unlikely to have that address space clash with any other network that has another locally assigned prefix allocated to it. This is a particularly useful property when considering a number of scenarios including networks that merge, overlapping VPN address space, or hosts mobile between such networks.

This tool creates random ULAs: https://cd34.com/rfc4193/

[jlaundry]

FYI, as of November 2020 the Azure team had this on a backlog somewhere: https://github.com/MicrosoftDocs/azure-docs/pull/46099