Seminar IPv6

TUTORIAL OUTLINE
IPv6 Protocol • Introduction

• IPv6 Protocol
Tutorial • Addressing
• Flow Label
• Extension Headers
• Packet Size Issues
Bob Hinden
• Routing
(as told by Charles E. Perkins)
• ICMP / Neighbor Discovery
{bob.hinden,charles.perkins}@nokia.com
1 © 2005 IPv6 Protocol Tutorial – China Summit 2005 / Bob Hinden 2 © 2005 IPv6 Protocol Tutorial – China Summit 2005 / Bob Hinden
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: IPv6 PROTOCOL
– Breaks Internet End-to-End model
– Inhibits new applications
– Doesn’t create any new global addresses
• Or fix inequities in current allocation systems
IPv6 & IPv4 HEADERS
IPv6 HEADER FORMAT
Ver. Traffic
Class Flow Label Hdr Type of
Ver. Len Service Total Length
Payload Length Next Hop Identification Flg Fragment

Version Class Flow Label Header Limit Offset
Payload Length Next Header Hop Limit Time to Protocol Header
Live Checksum
Source Address
Source Address
Source Address Destination Address
40 Options...
bytes
shaded fields have no equivalent in the

Destination Address other version
Destination Address
IPv6 header is twice as long (40 bytes) as
IPv4 header without options (20 bytes)
32 bits
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
ADDRESSING
– Header Length field eliminated
– Length field excludes IPv6 header
– Alignment changed from 32 to 64 bits
• Extended
– Flow Label field added
WHY 128-bit ADDRESSES? TEXT REPRESENTATION
• Some wanted fixed-length, 64-bit addresses OF ADDRESSES
– Easily good for 1012 sites, 1015 nodes, at .0001 allocation
efficiency (3 orders of mag. more than IPng requirement) “Preferred” form: 1080:0:FF:0:8:800:200C:417A
– Minimizes growth of per-packet header overhead
– Efficient for software processing
Compressed form: FF01:0:0:0:0:0:0:43
• Some wanted variable-length, up to 160 bits
becomes FF01::43
– 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 IPv4-embedded: 0:0:0:0:0:FFFF:13.1.68.3
• Settled on fixed-length, 128-bit addresses or ::FFFF:13.1.68.3
– (340,282,366,920,938,463,463,374,607,431,768,211,456)
TEXT REPRESENTATION OF
BASIC ADDRESS TYPES
ADDRESSES (cont.)
Unicast:
Address prefix: 2002:43c:476b::/48 for one-to-one U
(note: no masks in IPv6!) communication
M
Zone qualifiers: FE80::800:200C:417A%3 Multicast: M

for one-to-many
M
communication
URLs: http://[3FFE::1:800:200C:417A]:8000
A
(square-bracket convention also used anywhere else Anycast:
A
there’s a conflict with address syntax) for one-to-nearest
communication A
ADDRESS TYPE PREFIXES IPv6 ADDRESS SPACE
• An Address’s type is determined by its leading bits: LAYOUT
type binary prefix Global
Reserved* Reserved
Unspecified 0000…….0000 (128 bits) Unicast
Loopback 0000…….0001 (128 bits) 8ths
Multicast 11111111 (8 bits)

Unicast / Anycast everything else
Link-Local
Reserved Multicast
• The unspecified address indicates the absence of an address Unicast
1024ths
• The loopback address is a special-case unicast address
* Part of the first reserved 8th of space is allocated to various special-purpose
• Anycast addresses are indistinguishable from unicast addresses, currently including the Unspecified, Loopback, and ,
IPv4-embedded; altogether consuming ~128th of total space.
– (but, see RFC 2526)
GENERAL FORMAT OF INTERFACE ID FIELD

UNICAST ADDRESSES
Global Routing Prefix Subnet ID Interface ID Global Routing Prefix Subnet ID Interface ID
n bits m bits 128-n-m bits n bits m bits 128-n-m bits
• Interface ID is equivalent to the “host field”

• Unicast addresses are hierarchical, just like IPv4 in an IPv4 address (but more accurately named)
• Global routing prefix is itself hierarchically structured • If leading bits of address = 000 (binary),
• Subnet is usually the same as a link, but: Interface ID may be any width
– May have more than one subnet ID for the same link else:
Interface ID is 64 bits wide
CONFIGURING INTERFACE IDs GLOBAL UNICAST ADDRESSES
• There are several choices for configuring the interface ID
001 Global Routing Prefix Subnet Interface ID
of an address:
– Manual configuration (of interface ID or whole addr) public site interface
– DHCPv6 (configures whole address) [RFC 3315] topology topology identifier
(45 bits) (16 bits) (64 bits)
– Automatic derivation from 48-bit IEEE 802 address
or 64-bit IEEE EUI-64 address [RFC 2462]
• Only 1/8th of total space (binary 001 prefix) used initially
– Pseudo-random generation (for client privacy) [RFC 3041]
• Global routing prefix is hierarchically structured, using
• Latter two choices enable “serverless” or “stateless”
CIDR-type allocation and routing
autoconfiguration, when combined with high-order part of the
address learned via Router Advertisements • 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, HD RATIO (RFC-3194)

16-bit SUBNET FIELD?
• Measures “pain level” of a given level of utilization of a
hierarchical address space, on a scale of 0 to 1
• Fixed length minimizes subscriber hassles when changing • HD = log ( number of addressed objects ) /
service providers or when multi-homing log ( total number of addresses)
• 16-bits is enough for all but the largest subscribers • Historical analysis of IPv4, US phone numbers, French
phone numbers, DECnet IV, etc. shows remarkable
• Standard size eliminates need for most subscribers to
consistency:
provide address space justifications and projections to ISPs
HD = 0.80 manageable ( 51M for 32-bit space)
(for more rationale, see RFC 3177, IAB / IESG Recommendations on HD = 0.85 painful (154M for 32-bit space)
IPv6 Address Allocations to Sites)
HD = 0.87 practical limit (240M for 32-bit space)
• Is remaining 45 bits enough to address all subscribers?? • 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-bit
ADDRESS SPACE TLA / NLA TERMINOLOGY
• 45-bit space for sites holds 35 trillion numbers
– 35 trillion /48 prefixes (not total addresses)
001 TLA NLA* subnet interface ID
• Achievable utilization, according to HD ratio:
HD = 0.80 manageable = 70 billion public site interface
topology topology identifier
HD = 0.85 painful = 330 billion (45 bits) (16 bits) (64 bits)
HD = 0.87 practical limit = 610 billion
• TLA = Top-Level Aggregator
• Current world population is 6.1 billion, projected to peak at 9 to
NLA* = Next-Level Aggregator(s)
12 billion in about 2070
• This structure is defined in earlier IPv6 Address
• This is still using only 1/8th of total IPv6 address space;
Architecture RFCs and registry policy documents,
majority of space is being kept in reserve in case these
but has been dropped in more recent revisions
projections miss the mark
• Regional internet registries (RIRs) are responsible for
structure/allocation of the 45-bit global routing part
ADDRESSES ZONES AND

NON-GLOBAL IPv6 ADDRESSES SCOPES
Link •••
• IPv6 includes non-global addresses, similar to IPv4 private
Link Site •••
addresses (“net 10”, etc.)
Link •••
• A topological region within which such non-global addresses Link •••
are used is called a zone
Link Site The Global Internet
• Zones come in different sizes, called scopes Link •••
(e.g., link-local, site-local,…) Link •••
• Unlike in IPv4, a non-global address zone is also part of the Link Site •••
global addressable region (the “global zone”) Link •••
=> an interface may have both global and non-global
addresses Each oval is a different zone; different colors indicate different scopes
PROPERTIES OF ZONES AND PROPERTIES OF ZONES AND
SCOPES SCOPES (cont.)
• The scope of an address is encoded in the address itself, but the
zone of an address is not
• Zones of the same scope do not overlap, e.g., two sites – That’s why the “%zone-id” qualifier is needed, in the text
cannot overlap (i.e., cannot have any links in common) representation of addresses
• Zones of smaller scope nest completely within zones of – For a non-global address received in a packet, its zone is
larger scope determined based on what interface it arrived on
• Zones of same scope can reuse addresses of that scope • Packets with a source or destination address of a given scope
(e.g., the same link-local address can occur in more than are kept within a zone of that scope
one link) – (enforced by zone-boundary routers)
• Zone boundaries always cut through nodes,
not links or interfaces
NON-GLOBAL UNICAST
ZONE BOUNDARIES
ADDRESSES
• Link-local unicast addresses are meaningful only in a
single link zone, and may be re-used on other links
1111111010 0 Interface ID
10 bits 54 bits 64 bits

Global
Link • Site-local unicast addresses are meaningful only in a single
site zone, and may be re-used in other sites
Link Link 1111111011 Subnet ID Interface ID
10 bits 54 bits 64 bits
SITE-LOCAL ADDRESS
UNIQUE LOCAL ADDRESSES (ULA)
DEPRECATION
• IPv6 Site-Local addresses have two serious of problems: Prefix L Global ID Subnet ID Interface ID
– Ambiguous prefix (like IPv4 Net 10.)
– Site scope boundary not well defined and hard to enforce 7 bits 1 40 bits 16 bits 64 bits
• The problems add considerable complexity to
– Routers enforcing site boundaries • Prefix FC00::/7
– Multi-home hosts (with interfaces in different sites)
• L Set to 1 to indicate locally assigned
– Applications that need to select and exchange addresses Set to 0 for future definition
• IETF decided to Deprecate Site-Local addresses • Global ID 40-bit Global identifier computed locally using
– RFC3879 “Deprecating Site Local Addresses” pseudo-random algorithm
• Unique Local IPv6 Unicast Addresses developed to replace Site- • Subnet ID 16-bit Subnet identifier
Local Addresses (approved by IESG)
• Interface ID 64-bit Subnet identifier
– <draft-ietf-ipv6-unique-local-addr-09.txt>
ULA CHARACTERISTICS ADVANTAGES

• Globally unique prefix (with high probability of uniqueness) • Use inside of a site for local communication
• Well known prefix to allow for easy filtering at site boundaries – Prefix computed locally by site
– Good for sites with limited or no outside connectivity
• Allows sites to be combined or privately interconnected without
creating any address conflicts or requiring renumbering of • Useful for inter-site Virtual Private Networks (VPNs)
interfaces using these prefixes
• Sites can be merged without renumbering their local addresses
• Internet Service Provider independent and can be used for
communications inside of a site without having any permanent • Sites can change providers without having to change local
or intermittent Internet connectivity addresses
• If accidentally leaked outside of a site via routing or DNS, there • Well known prefix makes it straight forward to create default
is no conflict with any other addresses filtering rules
• In practice, applications may treat these addresses like global • No serious consequences if addresses leaked outside of a site
scoped addresses
MULTICAST ADDRESSES IPv6 NODES WILL USUALLY
11111111 Flags Scope Group ID HAVE MANY ADDRESSES PER
8 4 4 112 bits INTERFACE
• Low-order flag indicates permanent / transient group; three • Link-Local
other flags reserved
• Unique Local Addresses
• Scope field:
1 - interface-local (for multicast loopback) • Auto-configured 6to4 (if IPv4 public is address available)
2 - link-local (same as unicast link-local)
3 - subnet-local • Solicited-Node Multicast
4 - admin-local
5 - site-local • All-Nodes Multicast
8 - organization-local • Global anonymous
B - community-local
E - global (same as unicast global) • Global published
(all other values reserved)
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
FLOW LABEL – 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 source
desires to label as a flow
• Packet in a specific flow identified by
– Flow Label
– Source Address EXTENSION
HEADERS
– Destination Address
• Flow Label set by source node must be delivered unchanged to
the 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
EXTENSION HEADERS EXTENSION HEADERS (cont.)

• Processed only by node identified in IPv6 Destination Address
field
IPv6 Header TCP Header + Data – Much lower overhead than IPv4 options
Next Header = – Exception: Hop-by-Hop Options header
TCP
• Eliminated IPv4’s 40-octet limit on options
IPv6 Header Security Header TCP Header + Data – Limit is total packet size, or Path MTU in some cases
Next Header = Next Header = • Currently defined extension headers:
Security TCP
– Hop-by-Hop Options, Routing, Fragment, Authentication,
Encryption, Destination Options, Mobility Header
IPv6 Header Routing Header Fragment Header Fragment of TCP
Header + Data
Next Header = Next Header = Next Header =
Routing Fragment TCP
HOP-BY-HOP OPTIONS HEADER & OPTION TYPE ENCODING
DESTINATION OPTIONS HEADER
AIU C Option ID
• Are containers for variable-length options:
Next Header Hdr Ext Len • AIU — Action If Unrecognized:

00 — Skip over option
Options 01 — Discard packet
10 — Discard packet & send ICMP Unrecognized Type
to source
11 — Discard packet & send ICMP Unrecognized Type
Option Type Option Data Len Option Data to source only if destination was not multicast
• C — Set if Option Data changes en-route
(Hop-by-Hop Options only)
OPTION ALIGNMENT AND EXTENSION HEADERS vs.

PADDING OPTIONS
• Two Padding Options: • Action taken on an unrecognized extension header is the
same as unrecognized option with AIU = 11 (i.e., discard
Pad1 0 <— Special case: No Length or Data fields packet and, if not multicast, send ICMP error message)
PadN 1 N-2 N-2 Zero octets… – If this action not OK, must use an option
• Used to align options so multi-octet data fields fall on – If this action OK, have choice of option or separate
natural boundaries extension header (may depend on alignment, ease of
parsing, # octets required,…)
• Used to pad out containing header to an integer multiple of
8 octets
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
PACKET SIZE – Path MTU The minimum MTU of all the links in a
path between a source and a destination
ISSUES • 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 FRAGMENT HEADER

• Implementations are expected to perform Path MTU discovery
to send packets bigger than 1280 octets:
Next Header (Reserved) Fragment Offset 00M
– For each dest., start by assuming MTU of first-hop link
Original Packet Identifier
– If a packet reaches a link in which it cannot fit, will invoke
ICMP “packet too big” message to source, reporting the • Though discouraged, can use IPv6 Fragment header to
link’s MTU; MTU is cached by source for specific support upper layers that do not (yet) do Path MTU discovery
destination
– Occasionally discard cached MTU to detect possible • Fragmentation & Reassembly is an end-to-end function;
increase • Routers do not fragment packets en-route if too big
• Minimal implementation can omit Path MTU discovery as long – They send ICMP “packet too big” instead
as all packets kept < 1280 octets
– Useful for Boot ROM implementation
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: ROUTING
Option Type=194 Opt Data Len=4
Payload Length
• Cannot use Fragment header with jumbograms
IPv6 ROUTING ROUTING HEADER

• Longest-Prefix Match Routing Next Header Hdr Ext Len Routing Type Segments Left
– Same as IPv4 CIDR Routing Reserved Loose/Strict Bit Mask
• Extensions to Existing IPv4 Routing Protocols

– Unicast: RIPv2, OSPF, ISIS, BGP, ... Address[0]
– Multicast: PIM, MOSPF, ...
• Support for Policy Routing by use of Routing Header with
Anycast Addresses Address[1]
– Provider selection, Policy, Performance, ….
•
•
•
ICMP ERROR MESSAGES
[RFC 2463]
• Common format
ICMP / NEIGHBOR Type Code

Parameter
Checksum
DISCOVERY As much of invoking packet

as will fit without the ICMP packet
exceeding 576 octets
(Code and Parameter are type-specific)
ICMP ERROR MESSAGE TYPES ICMP INFORMATIONAL

• Destination unreachable
MESSAGES
– No route
– Administratively prohibited
• Echo Request & Reply (same as IPv4)
– Beyond scope of source address (new) • Group Membership Query, Report, Reduction:
– Address unreachable
– Port unreachable
– Source address failed ingress/egress policy (new) Type Code Checksum
– Reject route to destination (new) Maximum Response Delay Reserved
• Packet too big
• Time exceeded Multicast Address
• Parameter problem
– Erroneous header field
– Unrecognized next header type
– Unrecognized option
NEIGHBOR DISCOVERY ROUTER ADVERTISEMENTS
• ICMP message types:
– Router solicitation • Periodically multicast by router to all-nodes multicast address
– Router advertisement (link scope)
– Neighbor solicitation • Contents:
– Neighbor advertisement – “I am a router” (implied) – list of:
– Redirect – Lifetime as default (1 sec – 18 hr) »prefix
• Functions performed: – “Get addresses from DHCP” flag » prefix length
– Router discovery – “Get other stuff from DHCP” flag » valid lifetime
– Prefix discovery – Router’s link-layer address » preferred lifetime
– Autoconfiguration of address & other Parameters – Link MTU » on-link flag
– Duplicate address detection (DAD) – Suggested hop limit » autoconfig OK flag
– Neighbor unreachability detection (NUD) • Not sent frequently enough for unreachability detection
– Link-layer address resolution
– First-hop redirect
OTHER NEIGHBOR DISCOVERY “PLUG-AND-PLAY”

MESSAGES AUTOCONFIGURATION
• Router Solicitations
– Sent only at host start-up, to solicit immediate Router
• Hosts automatically learn subnet prefix from router
Advertisement advertisements; fabricate own address by adding local unique
– Sent to all-routers multicast address (link scope)
ID (e.g., Ethernet address)
• Neighbor Solicitations • New subnet prefixes can be added, and old ones deleted, to
– For address resolution: sent to “solicited node” multicast address
cause automatic renumbering
– For unreachability detection: sent to neighbor’s unicast address • Automatic address construction can be overridden by DHCP
• Neighbor Advertisements service, for more local control
– 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
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
61 © 2005 IPv6 Protocol Tutorial – China Summit 2005 / Bob Hinden

Seminar IPv6

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Seminar IPv6

Загружено:

Авторское право:

Доступные форматы

TUTORIAL OUTLINE

IPv6 Protocol • Introduction

Payload Length Next Hop Identification Flg Fragment

shaded fields have no equivalent in the

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

Loopback 0000…….0001 (128 bits) 8ths

Multicast 11111111 (8 bits)

GENERAL FORMAT OF INTERFACE ID FIELD

n bits m bits 128-n-m bits n bits m bits 128-n-m bits

• Interface ID is equivalent to the “host field”

WHY FIXED-LENGTH, HD RATIO (RFC-3194)

ADDRESSES ZONES AND

10 bits 54 bits 64 bits

Link Link 1111111011 Subnet ID Interface ID

10 bits 54 bits 64 bits

ULA CHARACTERISTICS ADVANTAGES

IPv6 FLOW LABEL

EXTENSION HEADERS EXTENSION HEADERS (cont.)

Next Header Hdr Ext Len • AIU — Action If Unrecognized:

OPTION ALIGNMENT AND EXTENSION HEADERS vs.

ISSUES • Minimum link MTU for IPv6 is 1280 octets

PATH MTU DISCOVERY FRAGMENT HEADER

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

• Cannot use Fragment header with jumbograms

IPv6 ROUTING ROUTING HEADER

• Extensions to Existing IPv4 Routing Protocols

ICMP / NEIGHBOR Type Code

DISCOVERY As much of invoking packet

(Code and Parameter are type-specific)

ICMP ERROR MESSAGE TYPES ICMP INFORMATIONAL

OTHER NEIGHBOR DISCOVERY “PLUG-AND-PLAY”

• IPv6 is a New Version of IP

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

Вам также может понравиться