seminar ipv6

8/7/2019 Seminar IPv6

http://slidepdf.com/reader/full/seminar-ipv6 1/16

1 © 2005 IPv6 Protocol Tutorial – China Summit 2005 / Bob Hinden

IPv6 Protocol

Tutorial

Bob Hinden

(as told by Charles E. Perkins)

{bob.hinden,charles.perkins}@nokia.com


TUTORIAL OUTLINE

• Introduction

• IPv6 Protocol• Addressing

• Flow Label

• Extension Headers

• Packet Size Issues

• Routing• ICMP / Neighbor Discovery


WHY IPv6

• The Internet has been a great Success!

– Success creates problems

• IPv4 is running out of Global IP Addresses

– Addresses are currently being rationed

• Network Address Translation (NAT) has extended the life of

IPv4, but:

– Breaks Internet End-to-End model

– Inhibits new applications

– Doesn’t create any new global addresses• Or fix inequities in current allocation systems


IPv6 PROTOCOL




IPv6 HEADER FORMAT

Payload Length

Version Flow Label

Next Header Hop Limit

Source Address

Destination Address

Class

4040

bytesbytes

32 bits32 bits


IPv6 & IPv4 HEADERS

Ver.

Time toLive

Source Address

Total LengthType of Service

Hdr Len

IdentificationFragment

Offset

Flg

ProtocolHeader

Checksum

Destination Address

Options...

Ver.TrafficClass

Source Address

Payload LengthNext

Header

Hop

Limit

Destination Address

Hdr Len

IdentificationFragment

Offset

Flg

Header Checksum

Options...

shaded fields have no equivalent in the

other version

IPv6 header is twice as long (40 bytes) asIPv4 header without options (20 bytes)

Flow LabelFlow Label


HEADER CHANGES

• Revised – Addresses increased 32 bits -> 128 bits – Time to Live -> Hop Limit – Protocol -> Next Header – Type of Service -> Traffic Class

• Streamlined – Fragmentation fields moved out of base header – IP options moved out of base header – Header Checksum eliminated – Header Length field eliminated – Length field excludes IPv6 header – Alignment changed from 32 to 64 bits

• Extended – Flow Label field added


ADDRESSING




WHY 128-bit ADDRESSES?

• Some wanted fixed-length, 64-bit addresses

– Easily good for 1012 sites, 1015 nodes, at .0001 allocation

efficiency (3 orders of mag. more than IPng requirement) – Minimizes growth of per-packet header overhead

– Efficient for software processing

• Some wanted variable-length, up to 160 bits

– Compatible with OSI NSAP addressing plans

– Big enough for auto-configuration using IEEE 802 addresses

– Could start with addresses shorter than 64 bits & grow later

• Settled on fixed-length, 128-bit addresses – (340,282,366,920,938,463,463,374,607,431,768,211,456)


TEXT REPRESENTATIONOF ADDRESSES

“Preferred” form: 1080:0:FF:0:8:800:200C:417A

Compressed form: FF01:0:0:0:0:0:0:43

becomes FF01::43

IPv4-embedded: 0:0:0:0:0:FFFF:13.1.68.3

or ::FFFF:13.1.68.3


TEXT REPRESENTATION OFADDRESSES (cont.)

Address prefix: 2002:43c:476b::/48

(note: no masks in IPv6!)

Zone qualifiers: FE80::800:200C:417A%3

URLs: http://[3FFE::1:800:200C:417A]:8000

(square-bracket convention also used anywhere else

there’s a conflict with address syntax)


BASIC ADDRESS TYPES

Unicast:for one-to-one

communication

Multicast:for one-to-many

communication

Anycast:

for one-to-nearestcommunication

M

M

M

U

A

A

A




ADDRESS TYPE PREFIXES

• An Address’s type is determined by its leading bits:

type binary prefixUnspecified 0000…….0000 (128 bits)

Loopback 0000…….0001 (128 bits)

Multicast 11111111 (8 bits)

Unicast / Anycast everything else

• The unspecified address indicates the absence of an address

• The loopback address is a special-case unicast address

• Anycast addresses are indistinguishable from unicast

– (but, see RFC 2526)


IPv6 ADDRESS SPACELAYOUT

GlobalUnicast

8ths

Reserved*

1024ths

Reserved

MulticastReservedLink-Local

Unicast

* Part of the first reserved 8th of space is allocated to various special-purpose

addresses, currently including the Unspecified, Loopback, and ,

IPv4-embedded; altogether consuming ~128th of total space.


GENERAL FORMAT OFUNICAST ADDRESSES

Global Routing Prefix Interface IDSubnet ID

n bits m bits 128-n-m bits

• Unicast addresses are hierarchical, just like IPv4

• Global routing prefix is itself hierarchically structured

• Subnet is usually the same as a link, but:

– May have more than one subnet ID for the same link


INTERFACE ID FIELD

Global Routing Prefix Interface IDSubnet ID

n bits m bits 128-n-m bits

• Interface ID is equivalent to the “host field”

in an IPv4 address (but more accurately named)

• If leading bits of address = 000 (binary),

Interface ID may be any width

else:

Interface ID is 64 bits wide




CONFIGURING INTERFACE IDs

• There are several choices for configuring the interface ID

of an address:

– Manual configuration (of interface ID or whole addr) – DHCPv6 (configures whole address) [RFC 3315]

– Automatic derivation from 48-bit IEEE 802 address

or 64-bit IEEE EUI-64 address [RFC 2462]

– Pseudo-random generation (for client privacy) [RFC 3041]

• Latter two choices enable “serverless” or “stateless”

autoconfiguration, when combined with high-order part of the

address learned via Router Advertisements


GLOBAL UNICAST ADDRESSES

sitetopology

(16 bits)

interfaceidentifier

(64 bits)

publictopology

(45 bits)

Interface IDSubnetGlobal Routing Prefix001

• Only 1/8th of total space (binary 001 prefix) used initially

• Global routing prefix is hierarchically structured, using

CIDR-type allocation and routing

• Current agreed default Registry policy is for every

subscriber site (e.g., corporate site, campus, residence, etc.)

to be assigned a 48-bit prefix

=> 16 bits of subnet space


WHY FIXED-LENGTH,16-bit SUBNET FIELD?

• Fixed length minimizes subscriber hassles when changing

service providers or when multi-homing• 16-bits is enough for all but the largest subscribers

• Standard size eliminates need for most subscribers to

provide address space justifications and projections to ISPs

(for more rationale, see RFC 3177, IAB / IESG Recommendations on

IPv6 Address Allocations to Sites)

• Is remaining 45 bits enough to address all subscribers??


HD RATIO (RFC-3194)

• Measures “pain level” of a given level of utilization of a

hierarchical address space, on a scale of 0 to 1

• HD = log ( number of addressed objects ) /

log ( total number of addresses)• Historical analysis of IPv4, US phone numbers, French

phone numbers, DECnet IV, etc. shows remarkable

consistency:

HD = 0.80 manageable ( 51M for 32-bit space)

HD = 0.85 painful (154M for 32-bit space)

HD = 0.87 practical limit (240M for 32-bit space)

• Note: The exact HD value used is under discussion.Currently 0.80 used in RIR allocations, might be changed

to higher value (e.g., 0.87).




HD RATIO APPLIED TO 45-bitADDRESS SPACE

• 45-bit space for sites holds 35 trillion numbers

– 35 trillion /48 prefixes (not total addresses)

• Achievable utilization, according to HD ratio:HD = 0.80 manageable = 70 billion

HD = 0.85 painful = 330 billion

HD = 0.87 practical limit = 610 billion

• Current world population is 6.1 billion, projected to peak at 9 to

12 billion in about 2070

• This is still using only 1/8th of total IPv6 address space;

majority of space is being kept in reserve in case these

projections miss the mark


TLA / NLA TERMINOLOGY

site

topology

(16 bits)

interface

identifier

(64 bits)

public

topology

(45 bits)

• TLA = Top-Level Aggregator

NLA* = Next-Level Aggregator(s)

• This structure is defined in earlier IPv6 Address

Architecture RFCs and registry policy documents, but has been dropped in more recent revisions

• Regional internet registries (RIRs) are responsible for

structure/allocation of the 45-bit global routing part

interface IDsubnetNLA*TLA001


NON-GLOBAL IPv6 ADDRESSES

• IPv6 includes non-global addresses, similar to IPv4 private

addresses (“net 10”, etc.)• A topological region within which such non-global addresses

are used is called a zone

• Zones come in different sizes, called scopes

(e.g., link-local, site-local,…)

• Unlike in IPv4, a non-global address zone is also part of the

global addressable region (the “global zone”)=> an interface may have both global and non-global

addresses


ADDRESSES ZONES ANDSCOPES

The Global InternetSite

Site

Site

• •

• • •

Link

Link

Link • • •

• • •

Link

Link

Link • • •

• • •

Link

Link

Link • • •

• • •

Each oval is a different zone; different colors indicate different scopes




PROPERTIES OF ZONES ANDSCOPES

• Zones of the same scope do not overlap, e.g., two sites

cannot overlap (i.e., cannot have any links in common)

• Zones of smaller scope nest completely within zones of

larger scope

• Zones of same scope can reuse addresses of that scope

(e.g., the same link-local address can occur in more than

one link)


PROPERTIES OF ZONES ANDSCOPES (cont.)

• The scope of an address is encoded in the address itself, but the

zone of an address is not

– That’s why the “%zone-id” qualifier is needed, in the text

representation of addresses

– For a non-global address received in a packet, its zone is

determined based on what interface it arrived on

• Packets with a source or destination address of a given scope

are kept within a zone of that scope

– (enforced by zone-boundary routers)

• Zone boundaries always cut through nodes,not links or interfaces


ZONE BOUNDARIES

Link Link

Link

Global


• Link-local unicast addresses are meaningful only in a

single link zone, and may be re-used on other links

• Site-local unicast addresses are meaningful only in a single

site zone, and may be re-used in other sites

NON-GLOBAL UNICASTADDRESSES

Interface ID01111111010

Subnet ID Interface ID1111111011

10 bits 54 bits 64 bits

10 bits 54 bits 64 bits




SITE-LOCAL ADDRESSDEPRECATION

• IPv6 Site-Local addresses have two serious of problems:

– Ambiguous prefix (like IPv4 Net 10.)

– Site scope boundary not well defined and hard to enforce

• The problems add considerable complexity to

– Routers enforcing site boundaries

– Multi-home hosts (with interfaces in different sites)

– Applications that need to select and exchange addresses

• IETF decided to Deprecate Site-Local addresses

– RFC3879 “Deprecating Site Local Addresses”

• Unique Local IPv6 Unicast Addresses developed to replace Site-

Local Addresses (approved by IESG)

– <draft-ietf-ipv6-unique-local-addr-09.txt>


UNIQUE LOCAL ADDRESSES (ULA)

Interface IDPrefix Subnet IDL Global ID

• Prefix FC00::/7

• L Set to 1 to indicate locally assignedSet to 0 for future definition

• Global ID 40-bit Global identifier computed locally using pseudo-random algorithm

• Subnet ID 16-bit Subnet identifier

• Interface ID 64-bit Subnet identifier

7 bits 16 bits 64 bits1 40 bits


ULA CHARACTERISTICS

• Globally unique prefix (with high probability of uniqueness)

• Well known prefix to allow for easy filtering at site boundaries

• Allows sites to be combined or privately interconnected without

creating any address conflicts or requiring renumbering of interfaces using these prefixes

• Internet Service Provider independent and can be used for communications inside of a site without having any permanentor intermittent Internet connectivity

• If accidentally leaked outside of a site via routing or DNS, thereis no conflict with any other addresses

• In practice, applications may treat these addresses like globalscoped addresses


ADVANTAGES

• Use inside of a site for local communication

– Prefix computed locally by site

– Good for sites with limited or no outside connectivity

• Useful for inter-site Virtual Private Networks (VPNs)

• Sites can be merged without renumbering their local addresses

• Sites can change providers without having to change local

addresses

• Well known prefix makes it straight forward to create default

filtering rules

• No serious consequences if addresses leaked outside of a site




MULTICAST ADDRESSES

Flags Scope

4 112 bits8

Group ID11111111

4

• Low-order flag indicates permanent / transient group; three

other flags reserved

• Scope field:1 - interface-local (for multicast loopback)2 - link-local (same as unicast link-local)3 - subnet-local4 - admin-local

5 - site-local8 - organization-localB - community-localE - global (same as unicast global)(all other values reserved)


IPv6 NODES WILL USUALLYHAVE MANY ADDRESSES PER

INTERFACE

• Link-Local

• Unique Local Addresses

• Auto-configured 6to4 (if IPv4 public is address available)

• Solicited-Node Multicast

• All-Nodes Multicast• Global anonymous

• Global published


FLOW LABEL


IPv6 FLOW LABEL

• Flow Label used to label the packets in a flow

– Defined as a 20-bit field in the IPv6 header

• IP flows usually defined as 5-tuple

– Source and Destination addresses – Source and Destination ports

– Transport protocol type

• These fields may be encrypted or hard to find after a chain of

option headers

• Flow Label provides makes it easy to identify the flow that

packet is part of

– Useful for a range of applications (load balancing, QOS,multi-path routing, etc.)




FLOW LABEL DEFINITION

• A flow is a sequence of packets sent from a particular source to a particular unicast, anycast, or multicast destination that the sourcedesires to label as a flow

• Packet in a specific flow identified by – Flow Label – Source Address – Destination Address

• Flow Label set by source node must be delivered unchanged tothe destination node

• Flow label field values – Zero indicates packet not part of a flow – Non-zero indicates packet has been labeled

• RFC3697 “IPv6 Flow label Specification” defines rules and usage


EXTENSIONHEADERS


EXTENSION HEADERS

IPv6 Header

Next Header =

TCP

TCP Header + Data

Security Header

Next Header =TCP

IPv6 Header

Next Header =Security

TCP Header + Data

Fragment Header

Next Header =

TCP

Routing Header

Next Header =

Fragment

IPv6 Header

Next Header =

Routing

Fragment of TCP

Header + Data


EXTENSION HEADERS (cont.)

• Processed only by node identified in IPv6 Destination Address

field

– Much lower overhead than IPv4 options

– Exception: Hop-by-Hop Options header

• Eliminated IPv4’s 40-octet limit on options

– Limit is total packet size, or Path MTU in some cases

• Currently defined extension headers:

– Hop-by-Hop Options, Routing, Fragment, Authentication,

Encryption, Destination Options, Mobility Header




HOP-BY-HOP OPTIONS HEADER &DESTINATION OPTIONS HEADER

• Are containers for variable-length options:

Next Header Hdr Ext Len

Options

Option Type Option Data Len Option Data


OPTION TYPE ENCODING

AIU C Option ID

• AIU — Action If Unrecognized:

00 — Skip over option

01 — Discard packet

10 — Discard packet & send ICMP Unrecognized Type

to source

11 — Discard packet & send ICMP Unrecognized Type

to source only if destination was not multicast

• C — Set if Option Data changes en-route

(Hop-by-Hop Options only)


0

1 N-2 N-2 Zero octets…

Pad1

PadN

<— Special case: No Length or Data fields

• Two Padding Options:

• Used to align options so multi-octet data fields fall on

natural boundaries

• Used to pad out containing header to an integer multiple of

8 octets

OPTION ALIGNMENT ANDPADDING


EXTENSION HEADERS vs.OPTIONS

• Action taken on an unrecognized extension header is the

same as unrecognized option with AIU = 11 (i.e., discard

packet and, if not multicast, send ICMP error message)

– If this action not OK, must use an option

– If this action OK, have choice of option or separate

extension header (may depend on alignment, ease of

parsing, # octets required,…)




PACKET SIZEISSUES


MINIMUM MTU

• Definitions:

– Link MTU A link’s maximum transmission unit,

i.e., the max IP packet size that can be

transmitted over the link

– Path MTU The minimum MTU of all the links in a

path between a source and a destination

• Minimum link MTU for IPv6 is 1280 octets

(versus 68 octets for IPv4)

• Links with MTU < 1280

– link-specific fragmentation and reassembly must be used


PATH MTU DISCOVERY

• Implementations are expected to perform Path MTU discovery

to send packets bigger than 1280 octets:

– For each dest., start by assuming MTU of first-hop link

– If a packet reaches a link in which it cannot fit, will invoke

ICMP “packet too big” message to source, reporting thelink’s MTU; MTU is cached by source for specific

destination

– Occasionally discard cached MTU to detect possible

increase

• Minimal implementation can omit Path MTU discovery as long

as all packets kept < 1280 octets

– Useful for Boot ROM implementation


FRAGMENT HEADER

Original Packet Identifier

Fragment OffsetNext Header (Reserved) 0 0 M

• Though discouraged, can use IPv6 Fragment header to

support upper layers that do not (yet) do Path MTU discovery

• Fragmentation & Reassembly is an end-to-end function;

• Routers do not fragment packets en-route if too big

– They send ICMP “packet too big” instead




MAXIMUM PACKET SIZE

• Base IPv6 header supports payloads of up to 65,535 octets

(not including 40 octet IPv6 header)

• Bigger payloads can be carried by setting IPv6 Payload

Length field to zero, and adding the “Jumbogram” hop-by-

hop option:

• Cannot use Fragment header with jumbograms

Option Type=194 Opt Data Len=4

Payload Length


ROUTING


IPv6 ROUTING

• Longest-Prefix Match Routing

– Same as IPv4 CIDR Routing

• Extensions to Existing IPv4 Routing Protocols

– Unicast: RIPv2, OSPF, ISIS, BGP, ... – Multicast: PIM, MOSPF, ...

• Support for Policy Routing by use of Routing Header with

Anycast Addresses

– Provider selection, Policy, Performance, ….


ROUTING HEADER

Address[1]

Loose/Strict Bit Mask

Address[0]

Next Header Hdr Ext Len Routing Type Segments Left

••

•

Reserved




ICMP / NEIGHBOR DISCOVERY


ICMP ERROR MESSAGES[RFC 2463]

• Common format

(Code and Parameter are type-specific)

Parameter

ChecksumType Code

As much of invoking packetas will fit without the ICMP packet

exceeding 576 octets


ICMP ERROR MESSAGE TYPES

• Destination unreachable

– No route

– Administratively prohibited

– Beyond scope of source address (new)

– Address unreachable

– Port unreachable

– Source address failed ingress/egress policy (new)

– Reject route to destination (new)

• Packet too big

• Time exceeded

• Parameter problem

– Erroneous header field

– Unrecognized next header type – Unrecognized option


ICMP INFORMATIONALMESSAGES

• Echo Request & Reply (same as IPv4)

• Group Membership Query, Report, Reduction:

ChecksumType Code

Multicast Address

ReservedMaximum Response Delay




NEIGHBOR DISCOVERY• ICMP message types:

– Router solicitation

– Router advertisement

– Neighbor solicitation – Neighbor advertisement

– Redirect

• Functions performed:

– Router discovery

– Prefix discovery

– Autoconfiguration of address & other Parameters

– Duplicate address detection (DAD) – Neighbor unreachability detection (NUD)

– Link-layer address resolution

– First-hop redirect


ROUTER ADVERTISEMENTS

• Periodically multicast by router to all-nodes multicast address

(link scope)

• Contents: – “I am a router” (implied) – list of:

– Lifetime as default (1 sec – 18 hr) »prefix

– “Get addresses from DHCP” flag » prefix length

– “Get other stuff from DHCP” flag » valid lifetime

– Router’s link-layer address » preferred lifetime

– Link MTU » on-link flag

– Suggested hop limit » autoconfig OK flag

• Not sent frequently enough for unreachability detection


OTHER NEIGHBOR DISCOVERYMESSAGES

• Router Solicitations

– Sent only at host start-up, to solicit immediate Router

Advertisement

– Sent to all-routers multicast address (link scope)

• Neighbor Solicitations

– For address resolution: sent to “solicited node” multicast address

– For unreachability detection: sent to neighbor’s unicast address

• Neighbor Advertisements

– For address resolution: sent to unicast address of solicitor

– For link-layer address change: sent to all-nodes multicast address

– Usable for proxy responses (detectable) – includes router/host flag


“PLUG-AND-PLAY”AUTOCONFIGURATION

• Hosts automatically learn subnet prefix from router

advertisements; fabricate own address by adding local unique

ID (e.g., Ethernet address)

• New subnet prefixes can be added, and old ones deleted, to

cause automatic renumbering

• Automatic address construction can be overridden by DHCP

service, for more local control




SUMMARY

• IPv6 is a New Version of IP

• Solves Current Critical Growth Problems

• Compatible with IPv4

• Improves IP in Many Areas

• Builds a Strong Base for the Future Growth

seminar ipv6

Documents