HON95-wiki/it/network/ipv6.md

---

title: IPv6 Theory breadcrumbs:

• title: IT
• title: Network --- {% include header.md %}

Advantages over IPv4

• Designed based on experience with the strengths and limitations of IPv4 and other protocols.
• IPv4 is becoming obsolete.
  • An investment in IPv4-only is an investment in EOL technology.
  • Certain services may only be available over IPv6 in the future.
  • IPv4 will be provided as a service in the future, making it less performant than native IPv6.
  • Since you'll need it some day, it's better to get familiar with it early.
  • While still needed for the full internet, internal networks may be IPv6-only.
• Larger address space.
  • Simpler and more structured address plans.
  • All subnets are /64 regardless of the number of hosts/interfaces.
  • Extra information can be embedded in the address.
• No need for NAT.
  • Restores end-to-end princible.
  • Better peer-to-peer support.
• Simpler design and operation.
• Improved protocols like ICMPv6, NDP, MLD and DHCPv6.
  • New features.
  • Security features.
• Native support for IPsec.
• Stateless address autoconfiguration (SLAAC) reduces administrative overhead for simple networks.
• Improved QoS.
• Improved multicast.
• Removed broadcast.
• Interfaces can have multiple addresses.
  • Link-local address.
  • Addresses from multiple prefixes from different routers.
  • Internal addresses in addition to global addresses.
• More efficient routing due to better address aggregation.
• More efficient packet processing:
  • No fragmentation in routers.
  • Streamlined fixed-length header with extension headers.
  • No checksum.

Addressing

• 128 bit addresses.
• No broadcast.
• Anycast.
  • Shared unicast address.
  • Subnet-router anycast address.
• Multicast:
  • Some scopes:
    • 1: Interface-local.
    • 2: Link-local.
    • 5: Site-local.
    • E: Global.
  • Some well-known addresses:
    • ff02::1: All nodes.
    • ff02::2: All routers.
    • ff02:6a: All snoopers.
    • ff02::1:ff00/24: Solicited node.
• Solicited-node multicast address.
  • Solicited-node prefix plus last 64 bits of an IPv6 address.
• Interface addresses:
  • Addresses are assigned to interfaces, not hosts.
  • Interfaces may have multiple addresses.
  • All interfaces have a link-scoped address.
• Permanent and temporary address types.
• Address assignment:
  • Static.
  • Stateless address autoconfiguration (SLAAC).
  • Stateless DHCP.
  • Stateful DHCP.
• SLAAC interface addresses:
  • EUI-64 (permanent): Deterministically based on the MAC address.
  • Privacy extensions (temporary): In addition to the permanent. Preferred for sending.
• The unspecified address: ::
• The loopback address: ::1
• The first and last addresses in a subnet are not reserved and can be assigned to hosts, unlike IPv4.
• Neighbor cache.
  • States:
    • Incomplete.
    • Reachable.
    • Stale.
    • Delay.
    • Probe.
• Destination cache.
• Address states:
  • Tenative: Waits for DAD to finish.
  • Preferred: Can be used.
  • Deprecated: About to expire. Can be used for existing connections but not new ones.
  • Valid: Preferred or deprecated.
  • Invalid: Expired valid.
  • Optimistic: Like tenative but for Optimistic DAD. Can be used.

Address Ranges

|Prefix|Description| |-|-| |::/32|IPv4-compatible IPv6 address (deprecated)| |::ffff/32|IPv4-mapped IPv6 address| |100::/64|Discard-only| |64:ff9b::/96|IPv4-IPv6 translation| |2000::/3|Global unicast address (GUA)| |2001::/32|Teredo| |2001:db8::/32|Documentation (non-routable)| |2002::/16|6to4| |fc00::/7|Unique local address (ULA)| |fd00::/8|Locally administered ULA| |fe80::/10|Link-scoped unicast| |ff00::/8|Multicast|

Packet and Transit

• Streamlined header.
  • 40 bytes base.
• Extension headers:
  • Hop-by-hop options header.
  • Routing header.
  • Fragment header.
  • Destination options header.
  • Authentication header.
  • Encapsulating security payload header.
• No checksum.
• Fragmentation.
  • Routers don't fragment.
  • Path MTU discovery.
  • Not allowed for some NDP messages.
  • The first fragment must contain all headers.

Protocols

Neighbor Discovery (ND)

• Uses ICMPv6.
• Link-layer address resolution.
• Neighbor unreachability detection (NUD).
• Duplicate IP address detection (DAD).
  • Determines if the address is unique before it can be used.
  • Opportunistic DAD allows using the address before DAD finishes.
• Redirect.
• Router advertisements.
  • SLAAC.
• Neighbor advertisements.
• Uses a hop limit of 255 and received request with lower hop limits are ignored.
• Suggests using IPsec for ND messages.
• Identification of ND messages:
  • All-zero to all-routers: SLAAC.
  • All-zero to solicited-node: DAD.
  • Unicast to solicited-node: Link-layer address resolution.
  • Unicast to unicast: Unreachability detection.
• Inverse neighbor discovery (IND).
• Secure neighbor discovery (SEND):
  • Router authentication.
  • Cryptographically generated address (CGA).
  • Some security options.
• NDP is vulnerable to the same attacks as for ARP and DHCP.
  • First hop security mechanisms for NDP include ICMP guard.
  • IPsec and SEND may also prevent certain attacks.

Multicast Listener Discovery (MLD)

• Uses ICMPv6.
• For registration of multicast listeners within a subnet.
• Handled by IGMP in IPv4.
• Version 1:
  • Based on IGMPv2.
  • Any-source multicast (ASM).
• Version 2:
  • Based on IGMPv3.
  • Source-specific multicast (SSM).
• PIM can be used for routing.
• MLD snooping can be used by switches.
• Multicast router discovery (MRD):
  • Based on MLD.
  • For discovery of multicast routers.

Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

• Relies on routing advertisements.
• Stateless or stateful.
• Reconfiguration message send by server to indicate changes (lacking in DHCPv4).
• DHCP Unique Identifier (DUID).
• Identity Association (IA).
  • One per interface.
  • Contains IPv6 addresses plus timers.
• Clients must perform DAD after being allocated an address by the server.
• Rapid commit option (only two messages).
• Renew and rebind.
• Prefix delegation with prefix exclusion.
• IPsec can be used.
• E.g. Android currently does not support DHCPv6, only SLAAC.
  • To help with traceability, Netflow or periodic NDP cache scans with SNMP can be used.

Domain Name System (DNS)

• A6 and AAAA type records.
• Dual stack hosts need two entries.
• IP6.ARPA. Originally IP6.INT.
• Dual stack clients query for both a A and an AAAA record for each domain name to resolve.
• The transport used is independent of the record type being queried for.
• Native IPv6 is generally preferred over IPv4.
• DNS whitelisting: Only respond with AAAA records to ISPs with good IPv6 performance.
• Happy eyeballs:
  • Clients will attempt to connect using both IPv4 and IPv6 and use the faster one.
  • IPv6 is preferred.
  • Different implementations exist.
• Name space fragmentation:
  • Every name server from the root (for a certain domain name) must be accessable by the resolver.
  • IPv4 should always be supported.

Routing Protocols Summary

• Using one shared instance VS two instances (ships in the night).
• RIPng:
  • Limited diameter.
  • Long routing loop convergence (count to infinity).
  • Too simple metric.
• OSPFv3:
  • Only for IPv6, IPv4 must still use OSPFv2.
  • Differences from OSPFv2:
    • Routes to links, not subnets.
    • Uses link-local addresses for neighbors.
    • Multiple instances per link.
    • Removal of addressing semantics. IPv6 addresses are not present in OSPF headers.
    • Flooding scope.
    • Authentication.
• IS-IS:
  • Single instance for both IPv4 and IPv6.
• EIGRP.
• BGP-4:
  • Uses implicit support for protocols other than IPv4 (multiprotocol NLRI).
  • BGP-4 routers still require (local) IPv4 addresses because of the BGP identifier.

Transition Technologies

• Dual-stack:
  • The best option for clients.
  • Requires running two separate protocol stacks, which may be extra operationally expensive.
• Tunneling:
  • Should use source address verification and ingress filtering.
  • May bypass firewalls.
  • Manual or automatic.
  • Loopback encapsulation and routing-loop nested encapsulation. Partially avoided using the encapsulation limit option.
• Translation:
  • Stateless or stateful.
  • May use the well-known prefix 64:ff9b::/96.
  • May need to (re)calculate checksums both at multiple layers.
  • Differing features (e.g. fragmentation and extension headers) may break.
  • While NAT44 is required in IPv4 to counteract address depletion, NAT66 is not recommended for IPv6.

Tunneling Mechanisms

• 6to4:
  • Deprecated.
  • Only 6to4 routers/gateways need to be 6to4 aware.
• IPv6 Rapid Deployment (6rd):
  • Widely used.
  • Based on 6to4.
  • Uses the ISPs own IPv6 range for customers.
  • Stateless.
  • Changing the customer IPv4 address also changes the IPv6 prefix.
• Intra-Site AUtomatic Tunnel Adressing Protocol (ISATAP):
  • Must be supported by all nodes in the network.
• Teredo:
  • May traverse NAT.
  • Vulnerable if not configured properly.
  • Should generally be avoided.
  • May be enabled by default on some OSes. Disable it if not explicitly needed.
• Tunnel brokers:
  • E.g. Hurricane Electrics and SixXS.
  • Requires a public IPv4 address.
• MPLS.
• Locator ID Separation Protocol (LISP):
  • General architecture not purely designed for IPv6 support.
  • Separates IP addresses into two namespaces: Endpoint identifiers (EIDs) and routing locators (RLOCs).
• Generic Routing Encapsulation (GRE):
  • Manual.
  • Can't traverse NAT.
• Proto 41 forwarding:
  • Allows nodes behind NAT to connect to tunnel servers on the internet.
• SSH.

Tanslation Mechanisms

• NAT44 (IPv4 only).
• Carrier grade NAT (CGN) aka NAT444 (IPv4 only).
• NAT464:
  • IPv6-only between the customer edge and the privider network.
  • Uses NAT46 and NAT64 at the two sides.
• DS-lite:
  • IPv6-only between customer edge and CGN.
  • IPv4 traffic is tunneled, not translated.
  • Uses a DS-Lite basic bridging broadband element (B4) within or directly connected to the CPE.
  • Uses a DS-Lite address family translation router (AFTR) within the provider network.
  • The B4 creates a tunnel to the AFTR.
  • The AFTR also functions as a NAT44.
  • There is a DHCPv6 option for DS-Lite.
  • Uses the range 192.0.0.0/29, where 192.0.0.1 is used by the AFTR and 192.0.0.2 is used by the B4.
• Stateless NAT64:
  • Appropriate for IPv4-only servers so they can be reached by IPv6 clients.
  • Uses prefix 64:ff9b::/96 or a custom prefix.
  • 1:1 mapping between IPv4 and IPv6 addresses.
  • Sessions can be initiated from both sides.
• Stateful NAT64 and DNS64:
  • Appropriate for IPv6-only edge networks to connect to the IPv4 internet.
  • Uses prefix 64:ff9b::/96 or a custom prefix.
  • 1:N mapping between IPv4 and IPv6 addresses.
  • Sessions can generally only be initiated from the IPv6 side.
  • No changes are required in the IPv6 client in order to support it.
  • If the DNS64 server does not find an AAAA record, it synthesizes a AAAA record within the NAT64 prefix.
  • Limitations:
    • All clients must be configured to use the the DNS64 server (e.g. through DHCP).
    • Synthesized AAAA records break DNSSEC.
    • Connections can't be initiated from the IPv4 side (like NAT masquerading).
    • Some applications don't support IPv6 or may have IPv4 literals hardcoded.
    • Users may attempt to enter IPv4 literals instead of using the DNS64 server.
• XLAT464:
  • Uses stateful translation in the core and statekess translaton at the edge.
  • Uses a customer-side translator (CLAT) which translated between 1:1 private IPv4 addresses and global IPv6 addresses.
  • Uses a provider-side translator (PLAT) which translates between N:1 global IPv6 addresses and global IPv4 addresses.
  • The NAT64 prefix can be aquired by querying the configured DNS server for ipv4only.arpa.
  • It does not support inbound IPv4 connections or peer-to-peer.
  • Implemented in Android.
• MAP.
• NPTv6 (IPv6 only):
  • Statelessly translated between two equal-length IPv6 prefixes.
  • Provides address independence: The internal network does not need to be renumbered when the public/external IPv6 prefix changes.
  • May be used for multihoming.
  • Does not need to rewrite port numbers in packets, but may break e.g. IPssec.
  • May require split DNS since the external and internal addresses differ.
• NAT66 (IPv6 only):
  • Like NAT44, including all its problems.
  • Stateful.

Address Planning and Implementation

• It should support both IPv4 and IPv6.
• IPv6 should be native.
• IPv4 may be provided through dual stack or as a service using translation or tunneling mechanisms.
  • IPv4 may can be tunneled both over internal core networks and through the internet edge.
  • If tunneling is appropriate, use 6rd, tunnel brokering or proto 41 forwarding, not ISATAP, 6to4 or Teredo. Prefer stateless.
  • Try to avoid NAT.
• For ISPs, native IPv6 with CGN for IPv4 is appropriate since IPv6 is proprotised and will offload IPv4.
• Internal addresses:
  • Should be IPv6-only.
  • May use either GUAs or ULAs.
  • Interfaces with ULAs which need internet access may:
    • Be assigned a GUA in addition to the ULA.
    • Use NPTv6 to translate the ULA prefix to a GUA prefix.
  • NAT66 is not required for ULAs and should not be used.
  • ULAs provide global address independence.
  • ULAs without NPTv6 provide an extra layer of protection for systems that should not be accessible externally.
• Sites should get a prefix long enough for multiple subnets.
  • Typically around 48.
  • Find out how much space you need before requesting it.
  • If you didn't get enough, ask for more.
• All subnets should be /64.
  • Event point-to-point links.
  • Does not focus on address conservation.
  • Does not require any VLSM.
  • Required by SLAAC and many other mechanisms and protocols.
• Topology aggregation VS policy/service aggregation.
• Suggested information to include in the prefix:
  • Region.
  • Location.
  • Service type.
  • Application.
  • Subnet.
  • VLAN ID (12 bits) (if the address plan is closely tied to the VLAN plan).
• Use provisioning tools (IPAM).
• Don't mirror the IPv4 address plan with all of its legacy problems.
• Plan both for now and for the future.
• Try to subnet on nibble boundaries since a nibble is one hex digit.
• GUA VS ULA.
• SLAAC VS DHCP.
  • Android does not support SLAAC.
  • DHCP provides more accountability.
• Implement appropriate first-hop security mechanisms, such as ICMP guard and DHCPv6 guard.
• Consider blocking certain multicast addresses, especially with site scope, to prevent attackers from identifying certain important resources on the network.
• Deploy both perimeter and host-based firewalls.
• Consider identity-based firewalls.
• Implement IPv6 in existing IPv4-only networks step by step. Either in phase with equipment lifecycles or as part of a needed redesign.
• Make sure Teredo is disabled on all clients not explicitly needing it.
• GUAs should use the privacy option to prevent tracking. This includes ULAs using NPTv6.
• PI space (provider independent) can be aquired to prevent network renumbering.
• Consider multihoming:
  • Redundancy and load balancing.
  • Potentally lower costs if the ISPs offer different prices for different services.
  • IPv6 supports native multihoming since interfaces can be assigned multiple prefixes from different routers.

{% include footer.md %}