IPv6 Address Scopes

 

Unlike IPv4, IPv6 does have a fully developed address scope concept. This is one of the major differences in IPv6. There are actually two sets of scopes – one set for unicast addresses, and a more elaborate set for multicast.

Scopes define the limits within which packets with a given destination address can travel, and in which that address is meaningful. For example, if you sent a packet with a Link-Local source address and a Global destination address to another subnet, in theory it could be delivered to the correct destination, but that node would not be able to reply to the sender using the source address. That Link-Local address is not “meaningful” in the destination subnet (it would be “outside of its scope”). In practice, trying to send such a packet would get you an ICMPv6 error message when it tried to cross the border router (“undeliverable: source address out-of-range”).

IPv6 Unicast Scopes

Unicast addresses have four scopes:

• • • Interface-Local
    • Link-Local
    • Site-Local
    • Global

The original Site-Local addresses were deprecated and replaced with “Unique Local Addresses”, but the scope of these ULAs is still “Site Local”.

IPv6 Interface-Local Scope (Loopback)

In IPv6, like IPv4, there is a real interface-local scope. Unlike IPv4, where any address starting with 127 will work as loopback, except for 127.0.0.0 and 127.255.255.255, in IPv6 there is exactly one address that will work as loopback, which is ::1.  In IPv4 you could actually bind different addresses in 127/8 (e.g. 127.0.0.10 and 127.0.0.11) to different virtual web servers. This is not possible in IPv6. Any transmission with the loopback address as destination can be read by any application that has been bound to the loopback (localhost) address (with the correct port). That application can reply from the loopback address to the sender. None of this involves any physical network interface.

This is different from sending traffic to one of your node’s unicast addresses (e.g. 2001:470:3d:3000::2:1, or fe80::2030:9139:9cd5:ab52). This does actually write information to the physical NIC, which put packets onto the LAN, but typically only your own node will accept that traffic and respond to it. If you are sniffing traffic on your Local Area Connection interface with Wireshark (or on any interface connected to its link), you will see the traffic sent to your node’s unicast addresses, but not traffic sent to the loopback address. Wireshark does not even allow you to specify the loopback “interface” as a source of packets to sniff. It is not a real interface.

Note that if you ping the loopback address, the source address used must also be the loopback address. With ping, you cannot send traffic to the loopback address from any other address. For example, “ping -S 2001:470:3d:3000::2:1 ::1” will fail, but “ping -S ::1 ::1” works (the -S parameter in the Windows ping command allows you to specify the source address).

On the other hand, you can bind a UDP or TCP socket to the loopback address (usually using the name “localhost”), and any socket bound to any other address on that interface can send traffic to it, or receive traffic from it. External nodes cannot communicate with a socket bound to localhost. All interface-local traffic takes place inside the TCP/IP Link Layer.

For example, you could specify the “node address” of SQL Server to be localhost, or specify the IP literal [::1]. You could connect to it from a SQL client application on that node, but not from a SQL client on any other node connected to the same subnet. On the other hand, if you specified the “node address” as one of the unicast addresses assigned to the node (and allowed connections to SQL Server through your host-based firewall), then a SQL Client application on another node connected to the same subnet could connect to your SQL Server. If a SQL client application on another node tried to connect to “localhost” (or ::1), their client would look for a SQL Server running on their node.

In IPv4 sometimes this scope is referred to as “Node-Local” – in IPv6 they make the distinction of calling this “Interface-Local”.

IPv6 Link-Local Scope (fe80::/10)

IPv6 has a fully developed link-local scope. It not just a block of addresses from the global address block (2000::/3) that have been re-purposed (as with IPv4 APIPA), but a distinct, easily recognized (and filtered) block of addresses outside of the global address block. Officially it is the block fe80::/10. In practice, the actual block is fe80::/64. According to RFC 4291, section 2.5.6, the first 10 bits must be followed by 54 bits of zero.

|   10     |
|  bits    |         54 bits         |          64 bits           |
+———-+————————-+—————————-+
|1111111010|           0             |       interface ID         |
+———-+————————-+—————————-+

All IPv6 routers prevent link-local addresses from being forwarded between interfaces. This is not something you need to remember to configure. Since the fe80::/10 block was defined from the start of IPv6, this filter is hard coded into all IPv6 routers. You couldn’t allow this even if you wanted to. In comparison, you need to configure firewall rules or ACLs to block the IPv4 APIPA block (169.254/16) from being forwarded by IPv4 routers, since those used to be regular global IPv4 addresses (recent IPv4 routers may not forward packets with APIPA destinations by default, but this can probably be overridden).

IPv6 Link-Local addresses are really like any other unicast address, except for being limited to the local link, and all having the same address prefix of fe80::/64. You can create and delete Link-Local addresses, just like IPv6 unicast addresses in other scopes. You can create, delete or edit them using the Advanced dialog in the Microsoft GUI network configuration tools ( with the netsh command line tool). You can also do so with the Sixscape SixConf application (which is basically a fancy GUI front end to the Windows netsh command).

One unique aspect of IPv6 Link-Local addresses is that every IPv6 interface will autonomously generate a unique Link-Local address immediately upon power-up. Actually, the autonomously generated Link-Local address does not appear in the Microsoft network configuration GUI tool, so you can’t edit or delete it with that tool (you can with NetConf). All Link-Local addresses assigned to the node are listed in ipconfig output (with Zone ID), including the autonomously generated address:

Link-local IPv6 Address . . . . . : fe80::2:1%11(Preferred)
Link-local IPv6 Address . . . . . : fe80::2030:9139:9cd5:ab52%11(Preferred)

In the above, the Link-Local address fe80::2:1 was added using the Advanced dialog of the Microsoft GUI network configuration tool.

If you do delete or modify the autonomously generated Link-Local address, various events (like disabling and re-enabling the interface) may cause a new one to be generated. If there  is no Link-Local address on a node, the Neighbor Discovery mechanisms cannot work (like Router Discovery, Address Resolution or SLAAC), since they all use Link-Local addresses.

IPv6 Site-Local Scope (Deprecated)

The Site-Local scope is similar to the Link-Local scope, except that it can include multiple links (subnets), connected together with one or more routers into an internet. However, there is a limit (however poorly defined) as to what collection of subnets constitutes a “site”. This means that packets sent to Site-Local addresses must be able to cross some (“internal”) routers, but not other (“border”) routers. Unlike with Link-Local scope, there is no way to hard code the necessary rules into the routers. Whether a router is “internal” or “border” depends on where it is located, and somebody’s definition of what constitutes a “site”. Appropriate port blocking or ACL rules must be administratively configured on the border routers to keep the Site-Local addresses from being forwarded outside of the “site”.

With Link-Local addresses there is no possible way for a Link-Local address from my subnet to get into some other link (subnet) where it might conflict with a valid Link-Local address there. The Link-Local address fe80::1 in subnet A cannot conflict with Link-Local address fe80::1 in subnet B. With Site-Local addresses, since packets with Site-Local destinations can cross some routers, conflicts like this can happen, especially when you link together subnets that were originally separated, using VPNs.

Orignially, in RFC 2460, IPv6 defined simple Site-Local addresses similar to the Link-Local addresses, but using the prefix fec0::/10. They had the same basic syntax, except that their prefix was fec0::. They also allowed used of bits 10-63 as a 54-bit Subnet ID.

|   10     |
|  bits    |         54 bits         |         64 bits            |
+———-+————————-+—————————-+
|1111111011|        subnet ID        |       interface ID         |
+———-+————————-+—————————-+

Like IPv6 Link-Local addresses, these were not globally unique. With Link-Local addresses, that does not matter. With Site-Local, this can be a problem (e.g. when merging the network of an acquired company into the acuiring company’s network, or when linking formerly separate subnets with VPNs).

Say I have two sites that are not currently directly connected, and the Site Local address fec0::2:1 exists in both of them. There is no problem with that so long as they are not joined. If I jpin those two sites into a single large site (using VPNs), those addresses are now in conflict. There is no problem with the any Link-Local addresses, so long as I don’t merge subnets into a larger subnet (this is not generall done). There might be a lot of conflicts in the resulting combined site.

ULAs were introduced to solve this problem in RFC 4193, “Unique Local IPv6 Unicast Addresses”, October 2005. They changed the prefix to fc00::/7 and added a 40 bit global ID starting in bit 8. Following this is the usual 16-bit Subnet ID, and 64-bit Interface Identifier. Bit 8 is used to indicate whether the Global ID is ad-hoc (1) or assigned by someone such as IANA (0).

| 7 bits |1|  40 bits   |  16 bits  |          64 bits           |
+——–+-+————+———–+—————————-+
| Prefix |L| Global ID  | Subnet ID |        Interface ID        |
+——–+-+————+———–+—————————-+

The 40-bit Global ID is chosen to be globally unique, the organization that owns the Global ID insures that the Subnet ID is unique for each subnet, and the Interface Identifier is automatically unique within subnet. Therefore, the complete 128 bit ULA is globally unique as well. So long as the organization doesn’t accidentally use the same Subnet ID in two separate sites, when sites are combined into a super site, there will not be any conflicts.

There is still some ambiguity about what constitutes a site, so that is left up to the network designer. However, once those boundaries are decided, it is not difficult to configure firewall rules or router ACLs to limit the scope of packets using a particular ULA to the desired locations. Simply allow packets with addresses from the ULA block to cross internal routers, and be blocked by the border routers. The ULA syntax makes such rule creation fairly simple. You should never allow ULAs to route directly onto the Internet backbone (although it is OK for them to cross the IPv6 backbone inside of VPNs).

IPv6 Global Scope

The Global scope is essentially the entire world-wide IPv6 Internet. This no longer exists in IPv4 because of NAT44 and private internets. All IPv6 addresses in the block 2000::/3 are global unicast addresses, and are suitable for use in the global scope. In IPv6 there is an essentially unlimited supply of these. Each node that can accept incoming connections from anywhere needs one of these. Generally every IPv6-compliant node in your entire network has one or more global unicast addresses (in IPv6 you can have any number of addresses on a single interface). Unless specifically blocked by firewall rules or router ACLs, these addresses can be reached from any node on the global IPv6 Internet. This is called true End-to-End connectivity, or a “flat” address space. It’s like the IPv4 Internet was before it was splintered into millions of private internets by NAT44.

Just as with IPv4, you should have a border gateway that blocks incoming connections except for specific exceptions, such as HTTP and HTTPS to internal nodes that have web servers on them; SMTP and IMAP to internal nodes that have email servers on them; and SIP/RTP to internal nodes that have IPv6 VoIP clients on them (which could be most of them). For tighter security, you could block all outgoing connections as well, again, except for specific exceptions.

With IPv6 you don’t have to worry about setting up BINAT to internal nodes (or configure proxy arps), just open holes in the firewall (or configure ACLs on a router). NAT does not add any real security. It does complicate setting up and managing the security, and breaks many protocols (like IPsec and SIP). It’s only purpose was to extend the lifetime of the IPv4 address space a few mores years. In the case of IPv6 there is no need to do that.

IPv6 Multicast Scopes

There are more scopes for IPv6 multicast than for IPv6 unicast:

• • • Interface-Local (0x1)
    • Link-Local (0x2)
    • Admin-Local (0x4)
    • Site-Local (0x5)
    • Organization-Local (0x8)
    • Global (0xE)

Each multicast address has a 4-bit scope field that specifies one of the above scope IDs (e.g. 8 for Organization-Local). It also has a 112 bit “group ID” that identifies the multicast group involved.

|   8    |  4 |  4 |                  112 bits                   |
+—— -+—-+—-+———————————————+
|11111111|flgs|scop|                  group ID                   |
+——–+—-+—-+———————————————+

 

As with unicast scopes, it is possible to configure routers to specify what scopes they will allow to pass. For example, if a router is set to pass Site-Local (5), then it will also allow all higher level scopes to pass (in that case, Organization-Local and Global). By configuring your routers, you can define the boundaries of each multicast scope. Only Global should be routed onto the Internet backbone. All the other scopes are internal to your organization.

IPv6 Multicast Interface-Local Scope

Scope ID = 1. This is for multicast connections inside the node (actually in the Link-Layer of the TCP/IP stack). There is no need to configure routers to block Interface-Local multicast packets – these do not travel outside of the node.

IPv6 Multicast Link-Local Scope

Scope ID = 2. This is for multicast connections inside the node (actually in the Link-Layer of the TCP/IP stack). No router will allow Link-Local multicast packets to pass, as they are valid only within the local link. All scopes higher than Link-Local should pass your local link’s gateway router.

IPv6 Multicast Admin-Local Scope

Scope ID = 4. The “admin” scope refers to “the smallest scope that must be administratively configured”, beyond the Local-Link. This could be a departmental group, a floor in a building, a building, etc. It can be anything that you want to limit multicast traffic to, beyond the Local Link. You must configure internal routers at the boundary of that collection of subnets to block anything of “admin” or lower scope, but allow anything of higher scope to pass.

IPv6 Multicast Site-Local Scope

Scope ID = 5. The “site” scope refers to the next level above the Admin scope. Again, it is up to the network architect what constitutes a “site”, but it is larger than the “admin” scope and smaller than the “organization” scope. It might be a group of buildings (a corporate campus), a city, a country, etc. You must configure internal routers at the boundary of that collection of subnets to block anything of “site” or lower scope, but allow anything of higher scope to pass.

IPv6 Multicast Organization-Local Scope

Scope ID = 8. The “organization” scope refers to the next level above the Site scope. It is up to the network architect what constitutes an “organization”, but this is typically all subnets that belong to your organization, possibly multiple sites connected by VPNs. It is larger than the “site” scope, but smaller than “global”. You must configure your organization’s border routers (separating your organization from the Internet) to block anything of “organization” scope or smaller from crossing them, but allow global multicast packets to pass.

IPv6 Multicast Global Scope

Scope ID = 14 (0xE). The “global” scope is the entire world. Your organization’s border routers should allow “global” scope to pass onto the Internet backbone. No router should normally block global multicast packets (at least based on scoping rules).