Certified IPv6 Network Engineer (CNE6) - Level 2

IPv6 Refresher

Copyright 2011 National Advanced IPv6 (NAv6) Center, Universiti Sains Malaysia (USM)

Disclaimer
We wish to inform that this CNE6 course materials and its content is solely for the purpose of CNE6 examination and it shall not be made available to any other parties without our written consent. All material in this course material is, unless otherwise stated, the property of National Advanced IPv6 Centre (NAv6) and protected by Copyright Law. Reproduction or retransmission of the materials, in whole or in part, in any manner, without the prior written consent of NAv6, is a violation of copyright law.

Contents
Addressing architecture Packet structure and header formats Header extensions ICMPv6 Neighbor discovery Autoconfiguration Transition Mechanisms

Copyright 2010 NAv6, Universiti Sains Malaysia

IPv6 Address Architecture

Addresses similar to IPv4
IPv6 addresses identify interfaces (not nodes) Hierarchical, topological addresses Forwarding based on best match

Some extra flexibility provided

eg, anycast, auto-configuration Local node and link addresses available Easier address change supported

Copyright 2010 NAv6, Universiti Sains Malaysia

IPv6 Address Types

UNICAST
Identifies a single interface Packet sent to a unicast address is delivered to the interface identified by that address

ANYCAST
Identifies a set of interfaces (typically on different nodes) Packet sent to an anycast address is delivered to one of the interfaces identified by that address (normally the nearest)

MULTICAST
Identifies a set of interfaces (typically on different nodes) Packet sent to a multicast address is delivered to all interfaces identified by that address

IPv6 has no broadcast address

Copyright 2010 NAv6, Universiti Sains Malaysia

IPv6 Address Representation

128 bit length (16 octets) Represented as 8 * 16-bit pieces in hexadecimal, separated by colons ":" For prefixes: IPv6-address/length Multiple 16-bit fields of zeros can be compacted by using a double-colon "::" Compaction only used once per address Low order 32 bits can use v4 format d.d.d.d

Copyright 2010 NAv6, Universiti Sains Malaysia

Address Abbreviation Examples

IPv6 Addresses: CDFE:910A:2356:5709:8475:1024:3911:2021 2080:0000:0000:0000:0090:7AEB:1000:123A 1800:0000:0000:7AEF:0000:0000:1072:4310 1800:0000:0000:7AEF:0000:0000:16.114.67.16 Compacted IPv6 Address:
2080::90:7AEB:1000:123A 2080::90:7AEB:1000:123A 1800::7AEF:0:0:1072:4310 1800:0:0:7AEF::1072:4310 1800::7AEF::1072:4310 Legal compaction Legal compaction Legal compaction Legal compaction Illegal compaction

Copyright 2010 NAv6, Universiti Sains Malaysia

Address Abbreviation Examples

2001 : 0DB8 : 0000 : 000B : 02AA : 0000 : 0000 : 005A
Rules to follow: 1. Preceding zeros for each 16 bit field can be omitted

2001 : DB8 : 0000 : B : 2AA : 0000 : 0000 : 5A 2. Consecutive fields of all zeros can be compressed using :: 2001 : DB8 : : B : 2AA : : 5A 3. Consecutive fields of all zeros can be compressed using :: (But can only be used once) 2001 : DB8 : 0 : B : 2AA : : 5A

Copyright 2010 NAv6, Universiti Sains Malaysia

Address Types
High order bits define IPv6 address type Current IPv6 prefix allocation
Special format addresses (0000::/8) (unspecified and loopback addresses) Link-local unicast addresses (FE800::/10) Site-local unicast addresses (FEC0::/10) Multicast addresses (FF00::/8) Aggregatable global unicast addresses (other) Anycast addresses are allocated from unicast space

Copyright 2010 NAv6, Universiti Sains Malaysia

Address Scope

Copyright 2010 NAv6, Universiti Sains Malaysia

IPv6 Address Explained

Copyright 2010 NAv6, Universiti Sains Malaysia

Rev. Multicast Address Format

First 3 bits set to 0 Last bit defines address type: 0000 = Permanent (or well-known) 0001 = Locally assigned (or transient)

Rev. Solicited Node Mcast. Add.

IPv6 Solicited Node Address Calculation

Copyright 2010 NAv6, Universiti Sains Malaysia

Required IPv6 Addresses for Host

A host is required to recognize the following addresses: Link-local address for each interface All assigned unicast addresses Loopback address All-nodes multicast addresses Solicited-node multicast address for each of its assigned unicast and anycast addresses Multicast addresses of all other groups to which the host belongs

Copyright 2010 NAv6, Universiti Sains Malaysia

Required IPv6 Addresses for Routers

In addition to the host address requirements a router is required to recognize the following addresses: Subnet-router anycast address for each of its routing interfaces All other anycast addresses configured on the router All-routers multicast address Multicast addresses of all other groups to which the router belongs

Copyright 2010 NAv6, Universiti Sains Malaysia

Required IPv6 Addresses for Routers

Copyright 2010 NAv6, Universiti Sains Malaysia

Contents
Addressing architecture Packet structure and header formats Header extensions ICMPv6 Neighbor discovery Autoconfiguration IPv6 routing protocols

Copyright 2010 NAv6, Universiti Sains Malaysia

IPv4 vs. IPv6 headers

Contents
Addressing architecture Packet structure and header formats Header extensions ICMPv6 Neighbor discovery Autoconfiguration Transition Mechanisms

Copyright 2010 NAv6, Universiti Sains Malaysia

Benefit of Extension Heards

IPv4 options drawbacks IPv4 options required special treatment in routers Options had negative impact on forwarding performance Therefore rarely used Benefits of IPv6 extension headers Extension headers are external to IPv6 header Routers do not look at these options except for Hop-by-hop options No negative impact on routers forwarding performance Easy to extend with new headers and option

Available Options
Processed by hop-by-hop
Must be processed by every node on the packets path Must always appear immediately after IPv6 header Two Hop-by-hop options already defined:
1. 2. Router alert option Jumbo payload option

Processed by destination
Meant to carry information intended to be examined by the destination node Only options currently defined are padding options to fill out header on a 64-bit boundary if (future) options require it

How Extension Headers Work

Before chaining Extension Headers

After Extension Headers in IPv6 Packets

Extension Header Processing

Extension headers are NOT examined or processed by any node along a packets delivery path ONLY hop-by-hop extension header is processed by every node along a packet's delivery path (including source and destination) Hop-by-hop header (if present) must immediately follow IPv6 header Extension headers are processed strictly in order they appear in the packet

Extension Header Processing

Forwarding IPv6 Packets with the Hop-by-Hop Extension Header

Forwarding IPv6 Packets with Extension Headers other than Hop-by-Hop in the Absence of ACLs

Extension Header Order

RFC 2460 recommends following order: 1. IPv6 header 2. Hop-by-hop options header 3. Destination options header 4. Routing header 5. Fragment header 6. Authentication header 7. ESP header 8. Destination options header 9. Upper-layer header

Extension Header Codes

Sample: routing Header

Next header value: 43 Provides "source-routing" functionality
Next Header: Contains the protocol number of the next header after the Routing header. Used to link headers together as described above. Header Extension Length: The length of the Routing header in 8-byte units, not including the first 8 bytes of the header. For a Routing Type of 0, this value is thus two times the number addresses embedded in the header. Routing Type: This field allows multiple routing types to be defined; at present, the only value used is 0.

Segments Left: Specifies the number of explicitly-named nodes remaining in the route until the destination. Reserved: Not used; set to zeroes. Addresses: A set of IPv6 addresses that specify the route to be used.

Sample: Fragment Header

Next header value: 44 Used to provide datagram fragmentation
Next Header: Contains the protocol number of the next header after the Fragment header. Used to link headers together as described above. Reserved: Not used; set to zeroes. Fragment Offset: Specifies the offset, or position, in the overall message where the data in this fragment goes. It is specified in units of 8 bytes (64 bits) and used in a manner very similar to the field of the same name in the IPv4 header. (Res) Reserved: Not used; set to zeroes. More Fragments Flag: Same as the flag of the same name in the IPv4 headerwhen set to 0, indicates the last fragment in a message; when set to 1, indicates that more fragments are yet to come in the fragmented message. Identification: Same as the field of the same name in the IPv4 header, but expanded to 32 bits. It contains a specific value that is common to each of the fragments belonging to a particular message, to ensure that pieces from different fragmented messages are not mixed together.

How it works
In this example, the packet is sent from Mobile Node A to Mobile Node B over the route optimized path [RFC3775], hence the use of the Routing EH (43) and the Destination Options EH (60). It is sent over a path that has an Maximum Transmission Unit (MTU) smaller than that of Mobile Nodes (MNs) access link, hence the use of the Fragmentation EH (44).

How it works

Contents
Addressing architecture Packet structure and header formats Header extensions ICMPv6 Neighbor discovery Autoconfiguration Transition Mechanisms

Copyright 2010 NAv6, Universiti Sains Malaysia

Neighbor Discovery
Tell

Ask question

Advertisement Router Neighbor (IPv6 Node)

Router Node

Solicitation
Node Node

ARP

ICMP Router Discovery

IGMP

Router Advertisement (RA)

A B C

D C A

RS RA

Router Advertisement (RA)

Default GW-List A

D C A

B
RA

Router Advertisement (RA)

RA Format

RA Options

Type 1 ICMPv6 Source Link-Layer Address Option Format

Type 5 ICMPv6 MTU Option Format

Type 3 ICMPv6 Prefix Information Option Format

Neighbor Solicitation (NS)

Neighbor solicitation (NS) option formats

Type 1 ICMPv6 Source Link-Layer Address Option Format

Neighbor Solicitation (NS)

NS Format

NS Option

Type 2 ICMPv6 Target Link-Layer Address Option Format

Redirect
Default GW-List A B C
Sent data to Host 3 using Default GW "A" ICMP Redirect to Router B

D C A

Path used with Default Gateway "A" Redirect traffic via Router B

Host 3

Contents
Addressing architecture Packet structure and header formats Header extensions ICMPv6 Neighbor discovery Autoconfiguration IPv6 routing protocols

Copyright 2010 NAv6, Universiti Sains Malaysia

Duplicate Address Detection

Must be performed by all nodes Performed before assigning a unicast address to an interface Performed on interface initialization Not performed for anycast addresses Link must be multicast capable New address is called "tentative" as long as duplicate address detection takes place

Duplicate Address Detection

1. Interface joins all-nodes multicast group 2. Interface joins solicited-node multicast group 3. Node sends (one) NS with
Target address = tentative IP address Source address = unspecified (::) Destination address = tentative solicited-node address

Duplicate Address Detection

If address already exists, the particular node sends a NA reply with
Target address = tentative IP address Destination address = tentative solicited-node address

If soliciting node receives NA reply with target address set to the tentative IP address, the address must be duplicate

IPv6 Address State

Contents
Addressing architecture Packet structure and header formats Header extensions ICMPv6 Neighbor discovery Autoconfiguration Transition Mechanisms

Copyright 2010 NAv6, Universiti Sains Malaysia

Transition Mechanisms
Myriad proposals
Coexistence
Dual IP stacks
All network devices run both IPv4 and IPv6 stacks

Dual IP layers
TCP/UDP layer is shared

"Bump In the Stack" (BIS)

IPv6 modules in IPv4 implementations

Tunneling
Configured tunnels Automatic tunnels 6 to 4 tunnels 6 over 4 tunnels

Translation
SIIT Stateless IP/ICMP Translator NAT-Protocol Translation (NAT-PT)

Translation
Multiple forms of translation: Between semantically identical protocols
Not applicable in this case (nor most)

Semantic Dual-Stack (SIIT, RFC 2765)

Application needs to be dual stack No meaningful gain over pure dual-stack

NAT-PT
Same packet translation as SIIT Different semantics (see following slides)

NAT-PT
Network Address TranslationProtocol Translation (NAT-PT) employs a stateful IPv4/IPv6 header translation.
NAT-PT uses a pool of IPv4 addresses for assignment to the IPv6 nodes on a dynamic basis No changes are required to existing hosts because all the NAT-PT translations are performed at the network-based NAT-PT device

NAT-PT
Semantically similar to (v4-to-v4) NAT v6-only hosts need to connect to v4 world DNS servers dynamically assign addresses from pool of global IPv4 addresses IP headers and addresses in applications are translated at NAT boxes NAT box must maintain state
Address mappings, TCP sequence number change, Data Unit ID, reassembly, etc..

NAT-PT
Translation for any one session must take place at the same NAT-PT router
Restricted topology NAT-PT is, like NAT, local to a domain This makes routing straightforward

Security is limited (end to end cant be translated, also no secure DNS) NAPT-PT extends maps TCP/UDP port #s (multiple v6 sessions use one v4 address)

How NAT-PT works

Tunneling
Configured tunnels
Connects IPv6 hosts or networks over an existing IPv4 infrastructure Generally used between sites exchanging traffic regularly Static tunnels configured on point-to-point basis Examples: CCC, MPLS, GRE, IP-IP, IPSec

Automatic tunnels
Tunnel is created then removed after use Requires IPv4 compatible addresses

6 to 4 dynamically established
Desirable as no explicit tunnel configuration required

6 over 4 - dynamically established

Assumes IPv4 transit network is multicast enabled

Tunnel broker
IPv6 hosts request v6 tunnel; obtain script to build tunnel

How Tunneling Works

Automatic Tunneling Using Compatible IPv4 Address

::/96 is set aside for IPv4-compatible addresses

6to4

2002:IPV4ADDR:SubnetID::/64

How 6to4 Works

ISATAP
Allow hosts that are multiple IPv4 hops away from an IPv6 router to participate in the IPv6 network by automatically tunneling IPv6 packets over IPv4

Teredo
provides address assignment & host-to-host automatic tunneling for unicast IPv6 traffic when IPv6/IPv4 hosts are located behind NATs

Types of NAT

Sample Teredo topology

Teredo Addressing
TheTeredo prefix is 2001::/32. The Teredo server IPv4 address is the public IPv4 address. The flag field indicates the type of NAT used by the Teredo client. The last two fields are the obscured mapped external IPv4 address and port of the Teredo client.

Sample Teredo Communication

Sample Teredo Communication

1. 2. 3. 4. client sends an IPv6 echo request via its Teredo server. Teredo servers are expected to relay these requests. Teredo server relays the echo request to the IPv6-only host. IPv6-only host sends an IPv6 echo reply with the Teredo client address as destination. The IPv6 infrastructure will route this packet to the nearestTeredo relay based on 2001::/32 routes. The Teredo relay will tunnel the echo reply to the Teredo client
1. 2. cone NAT, the packet will be forwarded to the Teredo client restricted cone NAT, this packet would be discarded, and additional procedures, involving bubble packets

5. Client determines relay IPv4 address from the received packet send packets to the IPv6-only host via the Teredo relay. 6. The relay extracts the IPv6 packet and forwards to the IPonly host. Future communications can follow this same path.

Tunneling Method Comparison

Dual-Stack, the basics

Routers & DNS are updated to support dual stack (v4 and v6) Hosts are then updated gradually to be dual
Use v6 if policy and both ends support it Otherwise use v4 DNS used to determine capability of other end Tunneling may be used with this approach Eventually v4 is phased out

This is included in RFC 2893 Transition Mechanisms for IPv6 Hosts and Routers (originally
proposed in RFC 1347)

Lessen Learned from past transitions

KEEP TRANSITION SIMPLE Limit scope and interaction of mechanisms Beware of semantic interdependence Make sure normal humans can fully understand the interactions and implications of all mechanisms Transition/Migration is THE hard part
Ensuring existing products do IPv6 well Keeping transition mechanisms under control

Key to successful transition

No "Flag Day" transitions!
Last Internet transition was 1983 (NCP TCP)

Maintain full IPv4/IPv6 dual access Minimize transition dependencies

Don't upgrade node X before node Y

Must be incremental Must be easy for end user

Transition from IPv4 to dual stack must not break anything

Example: Site Migration

1. Upgrade applications to be v4/v6 independent 2. Install transition mechanisms at domain edge (Tunnels, Translators) 3. Upgrade routing for native IPv6 4. Upgrade DNS to support IPv6 5. Upgrade hosts to dual stack 6. Convert hosts to IPv6-only (much later)

Example: DS Server Transition

Client-server model is common
Clients talk to servers Servers talk to other servers

Install dual-stack Routers and servers

(Including DNS, Email, and WWW servers) Communications between servers can use IPv4 or IPv6

Single-protocol clients contact servers using either protocol (v4 or v6)

Transition Security Risks

Many transition technologies may open security risks such as DoS attacks Automated interactions open security holes Details arent fully understood
Packet and route filters, DOS protection needs to be extended to transition techniques Authentication is needed where applicable Translation and authentication may be at odds

Prepared by Adil Hidayat adil@nav6.usm.my

Copyright 2011 National Advanced IPv6 (NAv6) Center, Universiti Sains Malaysia