Child pages
  • IPv6 Planning
Skip to end of metadata
Go to start of metadata

Security Note

Please note that it is the responsibility of Network Admin, System Admin and all users to uphold security policy when implementing any new network, service or application placed on University space.

Types of Addresses

Public Addresses

Penn State's publicly routable prefix is 2610:8::/32. TNS currently assigns units one or more /64 subnets, e.g. 2610:8:XXXX:YYYY::/64.

TNS has posted details on their IPv6 addressing plan on this page.

Private Addresses

IPv4 provides a range of addresses which are not publicly routable, the so-called RFC 1918 addresses (e.g. 10/8, 172.16/12, 192.168/16). IPv6 provides a similar capability with Unique Local Addresses (RFC 4193). In IPv4, these three address ranges are reused by multiple organization. In IPv6, each organization has its own unique prefix for non-routable address space. Penn State's ULA prefix is FD0B:7CDB:AEFD::/48.

ULAs are routed inside the Penn State Integrated Backbone, but they are not routed on the public Internet.

Please note that the use of Unique Local Addresses does not imply the use of NAT. To date, there is no NAT specification for IPv6. The IETF is working on guidelines for IPv6 NAT, but this specification is still in draft form.

Site-local Addresses (deprecated)

The predecessor to ULAs were called site-local addresses (RFC 3513). There were problems with the specification, and they were deprecated in 2004 by RFC 3879. TNS will not assign units site-local addresses.

Unique Local Addresses (ULA)

A unique local address (ULA) is an IPv6 address in the block fc00::/7, defined in RFC 4193. It is the IPv6 counterpart of the IPv4 private address. Unique local addresses are available for use in private networks, e.g. inside a single site or organization, or spanning a limited number of sites or organizations. They are not routable in the global IPv6 Internet.

TNS will assign ULA prefixes to customers as requested.

Multicast Addresses

See this page.

Link-local addresses are non-routable addresses. They are used to perform the IPv6 equivalent of ARP in IPv4. All IPv6 nodes are required to have a link-local address (RFC 4191, section 2.8).

Note, that link-locals are different than ULAs. ULAs are routed inside Penn State. Link-local addresses cannot be routed at all.

Per RFC 4291, link-local addresses start with fe80::/64. Typically, link-local addresses are configured automatically by the host's operating system. Link-local addresses should never be nameserved (RFC 4472, section 2.1).

IPv4 also has link-local addresses, 169.254/16. Their use is described in RFC 3927.


The IPv6 loopback address is ::1. This corresponds to in IPv4.

Note that some OSes also configure a link-local loopback address (fe80::1).

Address Configuration Methods

Static Addressing

Static addressing is useful for non-mobile machines. Static IPv6 configuration is typically similar to IPv4: An administrator will specify a full IPv6 host address, netmask and default router address. For end-user networks, the netmask is required to be /64.

See this page for configuration details for common operating systems.


  1. Consistent addressing makes name-serving easier.
  2. Consistent addressing makes it easier to comply with University Policy AD20 COMPUTER AND NETWORK SECURITY.
  3. Statically configured routers help protect against rogue Router Advertisements.


  1. The burden placed on the network administrator for manually updating and maintaining intricate knowledge of the topography of the network.


IPv6 provides for two forms of automatic configuration. With stateless autoconfiguration, nodes assign themselves a routable address. With DHCPv6, a central service assign nodes addresses.

Stateless Autoconfiguration

In stateless autoconfiguration (RFC 4862), a host self-configures an IPv6 address based on router advertisements. The address is divided into a network prefix and an interface identifier. Usually, each of these is 64-bits. The interface id is generated by the host. It can be based on the interface's MAC address or can be a randomly generated number. There are provisions to prevent multiple hosts on a LAN from configuring the same address.


  1. End-user machines do not have to be configured manually.


  1. Slightly more bandwidth use than static addresses since a host has to check if its candidate address is in use.
  2. An attacker can launch a DOS attack by preventing a host from configuring an address.
  3. The host could have a different IPv6 address every time it connects to the network.
  4. An auto-configured address is not likely to be nameserved, unless Dynamic DNS is used.

Privacy Addresses

Privacy addresses (RFC 4941) are a extension to the stateless autoconfiguration process. They are designed to provide some degree of anonymity. Note that a privacy address is different from a private address. A privacy address is an address whose interface identifier is structured in such a way as to help to conceal the user's identity. A private address is an address which cannot be routed on the public Internet.

There was concern in the IETF that auto-configured addresses could expose an individual's privacy, since auto-configured addresses typically contain the user's MAC address. However, the benefits of privacy addresses are debatable.

Privacy addresses are disabled by default on most OSes. They are enabled by default on Windows Vista. See this page for instructions on enabling/disabling them on common operating systems.


  1. Could enhance privacy for end-users.


  1. Makes compliance with AD20 difficult.
  2. Due to their random and frequently changing nature, privacy addresses are difficult to nameserve, except if Dynamic DNS is enabled.


Dynamic Host Configuration Protocol version 6 (RFC 3315) can be used to obtain IPv6 addresses, configuration data, or both. DHCPv6 is a separate protocol from DHCP. DHCPv6 can only be used to obtain IPv6 addresses, and DHCP can only be used to obtain IPv4 addresses. It is possible to run DHCP and DHCPv6 in parallel. Further, DHCPv6 may be used in parallel with stateless auto-configuration.

For information on current DHCPv6 implementations, see this page.

Stateful DHCPv6

In this mode, DHCPv6 provides a routable address to a node. A node will solicit DHCPv6 servers, which will respond with an advertisement. The client node will then select a DHCPv6 server and request an address.


  1. Enables clients to learn networking configuration details automatically.


  1. Not supported on all platforms.

Stateless DHCPv6

DHCPv6 can also be run in a stateless mode (RFC 3736). In this mode, the DHCPv6 server does not assign addresses to clients. It only provides configuration information, such as recursive DNS servers, DNS search domains, NTP servers, etc. DHCPv6 stateless can be used to augment stateless autoconfiguration.

If stateless DHCPv6 is used, clients must obtain routable IPv6 addresses through some other means, such as static assignment or stateless auto-configuration.

Stateless DHCPv6 is sometimes referred to as "DHCPv6-lite".


  1. Enables clients to learn networking configuration details automatically.


  1. Not supported on all platforms.

Combined DHCPv6

It is possible to use both stateful and stateless DHCPv6.

Address Configuration Selection

Whether a client uses stateless autoconfiguration, DHCPv6, or both is controlled centrally by the network administrator. IPv6 routers multicast Router Advertisement packets. These packets are used by clients to populate their routing tables and to configure addresses.

Router Advertisements contain three address configuration flags: A, M, and O. The A flag toggles stateless autoconfiguration. M indicates whether or not stateful DHCPv6 should be used. The O flag controls stateless DHCPv6. Clients are expected to automatically take appropriate actions to configure themselves based on these flags (for example, if the M flag is set, a client should automatically start its DHCPv6 client).

Here is an annotated packet capture showing an IPv6 Router Advertisement. In this example, the network uses stateless autoconfiguration.
(click on the image to see the full-size version)
One, two or three of these flags may be set. Every combination of these flags is legal. To quote RFC 4862, section 4, "[i]t should be noted that a host may use both stateless address autoconfiguration and DHCPv6 simultaneously."
To disable stateless autoconfiguration, one must change the Router Advertisement's Prefix Information option, to not set the A flag (see RFC 4861, section 4.6.2). This will disable stateless autoconfiguration for the advertised prefix. This is described in RFC 4862, section 5.5.3.
It is not possible to disable Privacy Addresses by adjusting the Router Advertisement flags. Privacy Addresses must be disabled using Windows' Group Policy or through local configuration on each machine.


TNS will assign units a /64. Units should not attempt to subnet this further. The IPv6 addressing RFCs require end-user subnets to have a 64-bit subnet mask. The IETF has documented many issues with non-64-bit masks.

If a unit wishes to have multiple subnets (for example, one for production servers, one for test servers, one for workstations, etc), the IB contact(s) should request multiple subnets from TNS. Penn State's IPv6 allocation from ARIN allows us to provision 4 billion subnets.

Layer 2 Security Considerations

Since address configuration is controlled by the routers, it is important that networks are protected against unauthorized machines posing as routers. These machines could simply be misconfigured desktops or an attacker. Network administrators should use layer 2 filtering on their switches to prevent unauthorized ports from transmitting Router Advertisement messages. Similar protections should be used to prevent rogue DHCPv6 Advertisement messages.

This draft RFC has more details on methods for combatting rogue Router Advertisements.

For more information, please see the IPv6 Security page.

Reserved Addresses

Several addresses on each subnet are reserved:

Interface Identifier Range



Subnet Router Anycast (RFC 4291)


Reserved Subnet Anycast (RFC 2526)


Mobile IPv6 Home Agents Anycast (RFC 2526)


Reserved Subnet Anycast (RFC 2526)

See this document for more details.

Additionally, RFC 5156 lists several special-use IPv6 addresses, many of which require special handling.


There are several standards for tunneling IPv6 over IPv4. Since ITS provides native IPv6 connectivity on the Integrated Backbone, units should not need to establish tunnels.


6to4 requires a routable IPv4 address (e.g., it does not work behind NAT). It uses IP Protocol 41.

See this page.

Firewall administrators may wish to block IP protocol 41 (note: protocol, not port!).


TBA. See wikipedia.


Teredo is an open-standard IPv6 tunneling protocol developed by Microsoft. The Miredo project provides an open-source implementation for Linux, Mac OS X and *BSD. According to Microsoft, Teredo was designed for home networks. Microsoft does not recommend using Teredo in an enterprise environment. Teredo is standardized by the IETF in RFC 4380.

Unlike 6to4, Teredo works behind NAT. On Windows, users must "opt-in" specific applications to use Teredo. If a Vista machine is joined to Active Directory, Teredo is disabled by default.

Teredo is supported in several versions of Windows:

  • Windows Vista (enabled by default but might be active or inactive based on the computer's configuration)
  • Windows XP with SP2 and later (enabled by default)
  • Windows XP with SP1 and the Advanced Networking Pack for Windows XP (enabled by default)
  • Windows Server 2008 (disabled by default)
  • Windows Server 2003 with Service Pack 1 and later (disabled by default)

To disable Teredo, run the following as an Administrator:

netsh interface teredo set state disabled

See this article at Microsoft for more on disabling Teredo.

Vista will not issue AAAA DNS queries if the only IPv6 address it has is a Teredo address.

See wikipedia.

To block Teredo on a firewall, administrators can block UDP port 3544. This blocks Teredo's control channel, preventing clients from establishing tunnels.


Not frequently used. See wikipedia.


Not frequently used. See wikipedia.

Other considerations

Network administrators may wish to familiarize themselves with the following documents:

RFC 4864 - Local Network Protection for IPv6

RFC 5157 - IPv6 Implications for Network Scanning

draft-ietf-6man-ipv6-subnet-model-00 - IPv6 Subnet Model: the Relationship between Links and Subnet Prefixes

draft-ietf-v6ops-addcon-08 - IPv6 Unicast Address Assignment Considerations


See this page.

Security considerations

Please see this page.


The University Library has added several IPv6 books to its Safari subscription:

Understanding IPv6
Second Edition
Microsoft Press

IPv6 Security
Cisco Press

IPv6 Essentials
Second Edition

Deploying IPv6 Networks
Cisco Press

Global IPv6 Strategies: From Business Analysis to Operational Planning
Cisco Press