Curs_ipv6
This document was uploaded by user and they confirmed that they have the permission to share it. If you are author or own the copyright of this book, please report to us by using this DMCA report form. Report DMCA
Overview
Download & View Curs_ipv6 as PDF for free.
More details
- Words: 5,118
- Pages: 120
Loading documents preview...
Introduction to IPv6
Outline
Protocol Background Technology Highlights Enhanced Capabilities Transition Issues Next Steps
Background
Why a New IP?
1991 – ALE WG studied projections about address consumption rate showed exhaustion by 2008.
Bake-off in mid-1994 selected approach of a new protocol over multiple layers of encapsulation.
What Ever Happened to IPv5? 0
IP (deprecated) IP IP IP IPv4 ST
March 1977 version
1 January 1978 version (deprecated) 2 February 1978 version A (deprecated) 3 February 1978 version B (deprecated) 4 September 1981 version (current widespread) 5 Stream Transport (not a new IP, little use) 6 IPv6 December 1998 version (formerly SIP, SIPP) 7 CATNIP IPng evaluation (formerly TP/IX; deprecated) 8 Pip IPng evaluation (deprecated) 9 TUBA IPng evaluation (deprecated) 10-15 unassigned
What about technologies & efforts to slow the consumption rate?
Dial-access / PPP / DHCP
Strict allocation policies
Reduced allocation rates by policy of ‗current-need‘ vs. previous policy based on ‗projected-maximum-size‘.
CIDR
Provides temporary allocation aligned with actual endpoint use.
Aligns routing table size with needs-based address allocation policy. Additional enforced aggregation actually lowered routing table growth rate to linear for a few years.
NAT
Hides many nodes behind limited set of public addresses.
What did intense conservation efforts of the last 5 years buy us?
Actual allocation history
1981 – IPv4 protocol published 1985 ~ 1/16 total space 1990 ~ 1/8 total space 1995 ~ 1/4 total space 2000 ~ 1/2 total space
The lifetime-extending efforts & technologies delivered the ability to absorb the dramatic growth in consumer demand during the late 90‘s. In short they bought – TIME –
Would increased use of NATs be adequate?
NAT enforces a ‗client-server‘ application model where the server has topological constraints.
NO!
They won‘t work for peer-to-peer or devices that are ―called‖ by others (e.g., IP phones) They inhibit deployment of new applications and services, because all NATs in the path have to be upgraded BEFORE the application can be deployed.
NAT compromises the performance, robustness, and security of the Internet. NAT increases complexity and reduces manageability of the local network. Public address consumption is still rising even with current NAT deployments.
What were the goals of a new IP design?
Expectation of a resurgence of ―always-on‖ technologies
xDSL, cable, Ethernet-to-the-home, Cell-phones, etc.
Expectation of new users with multiple devices.
China, India, etc. as new growth Consumer appliances as network devices
(1015 endpoints)
Expectation of millions of new networks.
Expanded competition and structured delegation.
(1012 sites)
Return to an End-to-End Architecture New Technologies/Applications for Home Users ‘Always-on’—Cable, DSL, Ethernet@home, Wireless,…
Always-on Devices Need an Address When You Call Them
Global Addressing Realm
Why is a larger address space needed?
Overall Internet is still growing its user base
:
~550 million users by 2005
Users expanding their connected device count
~320 million users in 2000
405 million mobile phones in 2000, over 1 billion by 2005 UMTS Release 5 is Internet Mobility, ~ 300M new Internet connected
~1 Billion cars in 2010 15% likely to use GPS and locality based Yellow Page services
Billions of new Internet appliances for Home users Always-On ; Consumer simplicity required
Emerging population/geopolitical & economic drivers
MIT, Xerox, & Apple each have more address space than all of China Moving to an e-Economy requires Global Internet accessibility
Why Was 128 Bits Chosen as the IPv6 Address Size? Proposals for fixed-length, 64-bit addresses
Accommodates 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 on current CPU hardware
Proposals for variable-length, up to 160 bits
Compatible with deployed OSI NSAP addressing plans Accommodates auto-configuration using IEEE 802 addresses Sufficient structure for projected number of service providers
Settled on fixed-length, 128-bit addresses
(340,282,366,920,938,463,463,374,607,431,768,211,456 in all!)
Benefits of 128 bit Addresses
Room for many levels of structured hierarchy and routing aggregation Easy address auto-configuration Easier address management and delegation than IPv4 Ability to deploy end-to-end IPsec (NATs removed as unnecessary)
Incidental Benefits of New Deployment
Chance to eliminate some complexity in IP header
Chance to upgrade functionality
improve per-hop processing
multicast, QoS, mobility
Chance to include new features
binding updates
Summary of Main IPv6 Benefits
Expanded addressing capabilities Structured hierarchy to manage routing table growth Serverless autoconfiguration and reconfiguration Streamlined header format and flow identification Improved support for options / extensions
IPv6 Advanced Features
Source address selection Mobility - More efficient and robust mechanisms Security - Built-in, strong IP-layer encryption and authentication Quality of Service Privacy Extensions for Stateless Address Autoconfiguration (RFC 3041)
IPv6 Markets
Home Networking
Gaming (10B$ market)
Sony, Sega, Nintendo, Microsoft
Mobile devices Consumer PC Consumer Devices
Set-top box/Cable/xDSL/Ether@Home Residential Voice over IP gateway
Sony (Mar/01 - …energetically introducing IPv6 technology into hardware products …)
Enterprise PC Service Providers
Regional ISP, Carriers, Mobile ISP, and Greenfield ISP‘s
IPv6 Markets
Academic NRN:
Geographies & Politics:
Internet-II (Abilene, vBNS+), Canarie*3, Renater-II, Surfnet, DFN, CERNET,… 6REN/6TAP Prime Minister of Japan called for IPv6 (taxes reduction) EEC summit PR advertised IPv6 as the way to go for Europe China Vice minister of MII deploying IPv6 with the intent to take a leadership position and create a market force
Wireless (PDA, Mobile, Car,...):
Multiple phases before deployment RFP -> Integration -> trial -> commercial Requires ‗client devices‘, eg. IPv6 handset ?
Outline
Protocol Background Technology Highlights Enhanced Capabilities Transition Issues Next Steps
A new Header
The IPv6 Header 40 Octets, 8 fields 0
4 Version
12 Class
16
24
31
Flow Label
Payload Length
Next Header
128 bit Source Address
128 bit Destination Address
Hop Limit
The IPv4 Header 20 octets + options : 13 fields, including 3 flag bits 0
4 Ver
8 IHL
16 Service Type
Identifier Time to Live
24 Total Length Flags
Protocol
Fragment Offset Header Checksum
32 bit Source Address 32 bit Destination Address Options and Padding
shaded fields are absent from IPv6 header
31
Summary of Header Changes between IPv4 & IPv6 Streamlined
Revised
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 Time to Live Hop Limit Protocol Next Header Precedence & TOS Traffic Class Addresses increased 32 bits 128 bits
Extended
Flow Label field added
Extension Headers IPv6 header
TCP header + data
next header = TCP
IPv6 header
Routing header
TCP header + data
next header = Routing
next header = TCP
IPv6 header
Routing header
Fragment header
next header = Routing
next header = Fragment
next header = TCP
fragment of TCP header + data
Extension Headers (cont.)
Generally processed only by node identified in IPv6 Destination Address field => much lower overhead than IPv4 options processing
Eliminated IPv4‘s 40-byte limit on options
exception: Hop-by-Hop Options header in IPv6, 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
Fragment Header Next Header
Reserved Fragment Offset Original Packet Identifier
00M
though discouraged, can use IPv6 Fragment header to support upper layers that do not (yet) do path MTU discovery IPv6 frag. & reasm. is an end-to-end function; routers do not fragment packets en-route if too big—they send ICMP ―packet too big‖ instead
Routing Header
Routing
Same ―longest-prefix match‖ routing as IPv4 CIDR Straightforward changes to existing IPv4 routing protocols to handle bigger addresses
unicast: OSPF, RIP-II, IS-IS, BGP4+, … multicast: MOSPF, PIM, …
Use of Routing header with anycast addresses allows routing packets through particular regions
e.g., for provider selection, policy, performance, etc.
Routing Header Next Header
Hdr Ext Len Routing Type Reserved
Address[0]
Address[1] • • •
Segments Left
Example of Using the Routing Header S
A
B
D
Addressing
Some Terminology node router host link
neighbors interface address
a protocol module that implements IPv6 a node that forwards IPv6 packets not explicitly addressed to itself any node that is not a router a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IPv6 nodes attached to the same link a node‘s attachment to a link an IPv6-layer identifier for an interface or a set of interfaces
Text Representation of 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-compatible: 0:0:0:0:0:0:13.1.68.3 or ::13.1.68.3
IPv6 - Addressing Model
Addresses are assigned to interfaces No change from IPv4 Model
Interface ‘expected’ to have multiple addresses
Addresses have scope Link Local Site Local
Global
Global
Addresses have lifetime Valid and Preferred lifetime
Site-Local
Link-Local
Types of IPv6 Addresses
Unicast
Multicast
Address of a set of interfaces Delivery to all interfaces in the set
Anycast
Address of a single interface Delivery to single interface
Address of a set of interfaces Delivery to a single interface in the set
No more broadcast addresses
Interface Address set
Loopback
Link local Site local Auto-configured 6to4
(if IPv4 public is address available)
Auto-configured IPv4 compatible
(only assigned to a single virtual interface per node)
(operationally discouraged)
Solicited node Multicast All node multicast Global anonymous Global published
Source Address Selection Rules
Rule 1: Prefer same address Rule 2: Prefer appropriate scope
Rule 3: Avoid deprecated addresses Rule 4: Prefer home addresses Rule 5: Prefer outgoing interface Rule 6: Prefer matching label from policy table
Native IPv6 source > native IPv6 destination 6to4 source > 6to4 destination IPv4-compatible source > IPv4-compatible destination IPv4-mapped source> IPv4-mapped destination
Local policy may override
Smallest matching scope
Rule 7: Prefer temporary addresses Rule 8: Use longest matching prefix
Destination Address Selection Rules
Rule 1: Avoid unusable destinations Rule 2: Prefer matching scope Rule 3: Avoid dst with matching deprecated src address Rule 4: Prefer home addresses Rule 5: Prefer matching label from policy table
Native IPv6 source > native IPv6 destination 6to4 source > 6to4 destination IPv4-compatible source > IPv4-compatible destination IPv4-mapped source> IPv4-mapped destination
Local policy may override
Rule 6: Prefer higher precedence Rule 7: Prefer smaller scope Rule 8: Use longest matching prefix Rule 9: Order returned by DNS
Address Type Prefixes Address type IPv4-compatible global unicast link-local unicast site-local unicast multicast
Binary prefix 0000...0 (96 zero bits) 001 1111 1110 10 1111 1110 11 1111 1111
all other prefixes reserved (approx. 7/8ths of total) anycast addresses allocated from unicast prefixes
Global Unicast Addresses 001
TLA
NLA* public topology (45 bits)
SLA* site topology (16 bits)
interface ID interface identifier (64 bits)
TLA = Top-Level Aggregator NLA* = Next-Level Aggregator(s) SLA* = Site-Level Aggregator(s) all subfields variable-length, non-self-encoding (like CIDR) TLAs may be assigned to providers or exchanges
Link-Local & Site-Local Unicast Addresses Link-local addresses for use during auto-configuration and when no routers are present: 0
1111111010
interface ID
Site-local addresses for independence from changes of TLA / NLA*: 1111111011
0
SLA*
interface ID
Interface IDs Lowest-order 64-bit field of unicast address may be assigned in several different ways:
auto-configured from a 64-bit EUI-64, or expanded from a 48-bit MAC address (e.g., Ethernet address) auto-generated pseudo-random number (to address privacy concerns) assigned via DHCP manually configured possibly other methods in the future
Some Special-Purpose Unicast Addresses
The unspecified address, used as a placeholder when no address is available: 0:0:0:0:0:0:0:0
The loopback address, for sending packets to self: 0:0:0:0:0:0:0:1
Multicast Address Format FP (8bits)
Flags (4bits)
Scope (4bits)
RESERVED (80bits)
Group ID (32bits)
11111111
000T
Lcl/Sit/Gbl
MUST be 0
Locally administered
flag field
scope field:
low-order bit indicates permanent/transient group (three other flags reserved) 1 - node local 2 - link-local 5 - site-local (all other values reserved)
8 - organization-local B - community-local E - global
map IPv6 multicast addresses directly into low order 32 bits of the IEEE 802 MAC
Multicast Address Format Unicast-Prefix based
FP (8bits)
Flags (4bits)
Scope (4bits)
reserved (8bits)
plen (8bits)
Network Prefix (64bits)
Group ID (32bits)
11111111
00PT
Lcl/Sit/Gbl
MUST be 0
Locally administered
Unicast prefix
Auto configured
P = 1 indicates a multicast address that is assigned based on the network prefix plen indicates the actual length of the network prefix Source-specific multicast addresses is accomplished by setting
P=1 plen = 0 network prefix = 0
draft-ietf-ipngwg-uni-based-mcast-01.txt
Outline
Protocol Background Technology Highlights Enhanced Capabilities Transition Issues Next Steps
Security
IPv6 Security
All implementations required to support authentication and encryption headers (―IPsec‖) Authentication separate from encryption for use in situations where encryption is prohibited or prohibitively expensive Key distribution protocols are under development (independent of IP v4/v6) Support for manual key configuration required
Authentication Header Next Header
Hdr Ext Len
Reserved
Security Parameters Index (SPI) Sequence Number Authentication Data
Destination Address + SPI identifies security association state (key, lifetime, algorithm, etc.) Provides authentication and data integrity for all fields of IPv6 packet that do not change en-route Default algorithm is Keyed MD5
Encapsulating Security Payload (ESP) Security Parameters Index (SPI) Sequence Number
Payload
Padding
Padding Length
Authentication Data
Next Header
Quality of Service
IP Quality of Service Approaches Two basic approaches developed by IETF: ―Integrated Service‖ (int-serv)
fine-grain (per-flow), quantitative promises (e.g., x bits per second), uses RSVP signaling
―Differentiated Service‖ (diff-serv)
coarse-grain (per-class), qualitative promises (e.g., higher priority), no explicit signaling
IPv6 Support for Int-Serv 20-bit Flow Label field to identify specific flows needing special QoS
each source chooses its own Flow Label values; routers use Source Addr + Flow Label to identify distinct flows Flow Label value of 0 used when no special QoS requested (the common case today) this part of IPv6 is not standardized yet, and may well change semantics in the future
IPv6 Support for Diff-Serv 8-bit Traffic Class field to identify specific classes of packets needing special QoS
same as new definition of IPv4 Type-ofService byte may be initialized by source or by router enroute; may be rewritten by routers enroute traffic Class value of 0 used when no special QoS requested (the common case today)
Compromise
Signaled diff-serv (RFC 2998)
uses RSVP for signaling with course-grained qualitative aggregate markings allows for policy control without requiring per-router state overhead
Mobility
IPv6 Mobility
Mobile hosts have one or more home address
A Host will acquire a foreign address when it discovers it is in a foreign subnet (i.e., not its home subnet)
relatively stable; associated with host name in DNS
uses auto-configuration to get the address registers the foreign address with a home agent, i.e, a router on its home subnet
Packets sent to the mobile‘s home address(es) are intercepted by home agent and forwarded to the foreign address, using encapsulation Mobile IPv6 hosts will send binding-updates to correspondent to remove home agent from flow
Mobile IP (v4 version) mobile host
correspondent host
foreign agent
home agent
home location of mobile host
Mobile IP (v4 version) mobile host
correspondent host
foreign agent
home agent
home location of mobile host
Mobile IP (v4 version) mobile host
correspondent host
foreign agent
home agent
home location of mobile host
Mobile IP (v4 version) mobile host
correspondent host
foreign agent
home agent
home location of mobile host
Mobile IP (v6 version) mobile host
correspondent host
home agent
home location of mobile host
Mobile IP (v6 version) mobile host
correspondent host
home agent
home location of mobile host
Mobile IP (v6 version) mobile host
correspondent host
home agent
home location of mobile host
Mobile IP (v6 version) mobile host
correspondent host
home agent
home location of mobile host
Mobile IP (v6 version) mobile host
correspondent host
home agent
home location of mobile host
IPv6 Routing
RIPng
RIPv2, supports split-horizon with poisoned reverse RFC2080
BGP4+ Overview
Added IPv6 address-family Added IPv6 transport Runs within the same process - only one AS supported All generic BGP functionality works as for IPv4 Added functionality to route-maps and prefix-lists
IPv6 routing
OSPF & ISIS updated for IPv6
Outline
Protocol Background Technology Highlights Enhanced Capabilities Transition Issues Next Steps
Porting Issues
Effects on higher layers
Changes TCP/UDP checksum ―pseudo-header‖ Affects anything that reads/writes/stores/passes IP addresses (just about every higher protocol) Packet lifetime no longer limited by IP layer (it never was, anyway!) Bigger IP header must be taken into account when computing max payload sizes New DNS record type: AAAA and (new) A6 …
Sockets API Changes
Name to Address Translation Functions Address Conversion Functions Address Data Structures Wildcard Addresses Constant Additions Core Sockets Functions Socket Options New Macros
Core Sockets Functions
Core APIs Use
IPv6 Family and Address Structures socket() Uses PF_INET6
Functions that pass addresses bind() connect() sendmsg() sendto()
Functions that return addresses accept() recvfrom() recvmsg() getpeername()
getsockname()
Name to Address Translation getaddrinfo()
Pass in nodename and/or servicename string Can Be Address and/or Port
Optional Hints for Family, Type and Protocol
Pointer to Linked List of addrinfo structures Returned
Flags – AI_PASSIVE, AI_CANNONNAME, AI_NUMERICHOST, AI_NUMERICSERV, AI_V4MAPPED, AI_ALL, AI_ADDRCONFIG Multiple Addresses to Choose From
freeaddrinfo()
struct addrinfo { int ai_flags; int ai_family; int getaddrinfo( int ai_socktype; IN const char FAR * nodename, int ai_protocol; IN const char FAR * servname, size_t ai_addrlen; IN const struct addrinfo FAR * hints, char *ai_canonname; OUT struct addrinfo FAR * FAR * res struct sockaddr *ai_addr; ); struct addrinfo *ai_next; };
Address to Name Translation getnameinfo()
Pass in address (v4 or v6) and port
Size Indicated by salen Also Size for Name and Service buffers (NI_MAXHOST, NI_MAXSERV)
Flags
NI_NOFQDN NI_NUMERICHOST NI_NAMEREQD NI_NUMERICSERV NI_DGRAM
int getnameinfo( IN const struct sockaddr FAR * sa, IN socklen_t salen, OUT char FAR * host, IN size_t hostlen, OUT char FAR * serv, IN size_t servlen, IN int flags );
Porting Environments
Node Types
Application Types
IPv4-only IPv6-only IPv6/IPv4
IPv6-unaware IPv6-capable IPv6-required
IPv4 Mapped Addresses
Porting Issues
Running on ANY System
Including IPv4-only
Address Size Issues
New IPv6 APIs for IPv4/IPv6
Ordering of API Calls
User Interface Issues
Higher Layer Protocol Changes
Specific things to look for
Storing IP address in 4 bytes of an array.
Use of explicit dotted decimal format in UI.
Obsolete / New:
AF_INET
replaced by
AF_INET6
SOCKADDR_IN
replaced by
SOCKADDR_STORAGE
IPPROTO_IP
replaced by
IPPROTO_IPV6
IP_MULTICAST_LOOP replaced by SIO_MULTIPOINT_LOOPBACK
gethostbyname
replaced by
getaddrinfo
gethostbyaddr
replaced by
getnameinfo
IPv6 literal addresses in URL‘s From RFC 2732 Literal IPv6 Address Format in URL's Syntax To use a literal IPv6 address in a URL, the literal address should be enclosed in "[" and "]" characters. For example the following literal IPv6 addresses: FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 3ffe:2a00:100:7031::1 ::192.9.5.5 2010:836B:4179::836B:4179
would be represented as in the following example URLs: http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html http://[3ffe:2a00:100:7031::1] http://[::192.9.5.5]/ipng http://[2010:836B:4179::836B:4179]
Other Issues
Renumbering & Mobility routinely result in changing IP Addresses –
Use Names and Resolve, Don‘t Cache
Multihomed Servers
More Common with IPv6
Try All Addresses Returned
Using New IPv6 Functionality
Porting Steps -Summary
Use IPv4/IPv6 Protocol/Address Family
Fix Address Structures in6_addr sockaddr_in6 sockaddr_storage
to allocate storage
Fix Wildcard Address Use in6addr_any,
IN6ADDR_ANY_INIT in6addr_loopback, IN6ADDR_LOOPBACK_INIT
Use IPv6 Socket Options IPPROTO_IPV6,
Options as Needed
Use getaddrinfo() For
Address Resolution
IPv4 - IPv6 Co-Existence / Transition
IPv6 Timeline (A pragmatic projection) 2000
2001
2002
2003
2004
Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
2005
2006
2007
Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
• Early adopter • Application porting <= Duration 3+ years
=>
• ISP adoption <= Duration 3+ years => • Consumer adoption
<=
Duration 5+ years =>
• Enterprise adoption <= Duration 3+ years =>
Deployments
IPv6 deployments will occur piecewise from the edge.
Core infrastructure only moving when significant customer usage demands it.
Platforms and products that are updated first need to address the lack of ubiquity. Whenever possible, devices and applications should be capable of both IPv4 & IPv6, to minimize the delays and potential failures inherent in translation points.
Impediments to IPv6 deployment
Applications Applications Applications
Move to the new APIs NOW
Transition / Co-Existence Techniques A wide range of techniques have been identified and implemented, basically falling into three categories:
(1) dual-stack techniques, to allow IPv4 and IPv6 to co-exist in the same devices and networks
(2) tunneling techniques, to avoid order dependencies when upgrading hosts, routers, or regions
(3) translation techniques, to allow IPv6-only devices to communicate with IPv4-only devices
Expect all of these to be used, in combination
Dual-Stack Approach
When adding IPv6 to a system, do not delete IPv4
this multi-protocol approach is familiar and well-understood (e.g., for AppleTalk, IPX, etc.) note: in most cases, IPv6 will be bundled with new OS releases, not an extra-cost add-on
Applications (or libraries) choose IP version to use
when initiating, based on DNS response: Prefer
scope match first, when equal IPv6 over IPv4
when responding, based on version of initiating packet
This allows indefinite co-existence of IPv4 and IPv6, and gradual app-by-app upgrades to IPv6 usage
Tunnels to Get Through IPv6-Ignorant Routers
Encapsulate IPv6 packets inside IPv4 packets (or MPLS frames) Many methods exist for establishing tunnels:
manual configuration ―tunnel brokers‖ (using web-based service to create a tunnel) automatic (depricated, using IPv4 as low 32bits of IPv6) ―6-over-4‖ (intra-domain, using IPv4 multicast as virtual LAN) ―6-to-4‖ (inter-domain, using IPv4 addr as IPv6 site prefix)
Can view this as:
IPv6 using IPv4 as a virtual NBMA link-layer, or an IPv6 VPN (virtual public network), over the IPv4 Internet
Translation
May prefer to use IPv6-IPv4 protocol translation for:
new kinds of Internet devices (e.g., cell phones, cars, appliances) benefits of shedding IPv4 stack (e.g., serverless autoconfig)
This is a simple extension to NAT techniques, to translate header format as well as addresses
IPv6 nodes behind a translator get full IPv6 functionality when talking to other IPv6 nodes located anywhere they get the normal (i.e., degraded) NAT functionality when talking to IPv4 devices drawback : minimal gain over IPv4/IPv4 NAT approach
Tunnels
6to4 Configured Automatic
6to4 tunnels FP (3bits)
TLA (13bits)
IPv4 Address (32bits)
SLA ID (16bits)
Interface ID (64bits)
001
0x0002
ISP assigned
Locally administered
Auto configured
2002:8243:1::/48 2002:947A:1::/48
IPv4
IPv6
IPv6 148.122.0.1
130.67.0.1
11.0.0.1 6to4 prefix is 2002::/16 + IPv4 address. 2002:a.b.c.d::/48
IPv6 Internet 6to4 relay 2002:B00:1::1 Announces 2002::/16 to the IPv6 Internet
6to4 tunnels II Pros
Cons
Minimal configuration
All issues that NMBA networks have.
Only site border router needs to know about 6to4
Requires relay router to reach native IPv6 Internet
Works without adjacent native IPv6 routers
Has to use 6to4 addresses, not native.
NB: there is a draft describing how to use IPv4 anycast to reach the relay router. (This is already supported, by our implementation...)
Configured tunnels 3ffe:c00:2::/48 3ffe:c00:1::/48
IPv4
IPv6
IPv6 130.67.0.1
-------------------------------------|IPv4 header|IPv6 header IPv6 payload| -------------------------------------IPv4 protocol type = 41
148.122.0.1
Configured tunnels II Pros
Cons
As point to point links
Has to be configured and managed
Multicast
Inefficient traffic patterns
Real addresses
No keepalive mechanism, interface is always up
Automatic tunnels 0
IPv4 Address (32bits)
Defined
ISP assigned
148.122.0.1 ::148.122.0.1
130.67.0.1 ::130.67.0.1
IPv6
Connects dual stacked nodes Quite obsolete
IPv4
IPv6
IPv6 Internet
Automatic tunnels II Pros
Cons
Obsolete
Difficult to reach the native IPv6 Internet, without injecting IPv4 routing information in the IPv6 routing table
Useful for some other mechanisms, like BGP tunnels
Has to use IPv4 compatible addresses
Tunneling issues
IPv4 fragmentation needs to be reconstructed at tunnel endpoint. No translation of Path MTU messages between IPv4 & IPv6. Translating IPv4 ICMP messages and pass back to IPv6 originator. May result in an inefficient topology.
Tunneling issues II
Tunnel interface is always up. Use routing protocol to determine link failures. Be careful with using the same IPv4 source address for several tunneling mechanisms. Demultiplexing incoming packets is difficult.
Deployment scenarios
Many ways to deliver IPv6 services to End Users
Service Providers and Enterprises may have different deployment needs IPv6 over IPv4 tunnels Dedicated Data Link layers for native IPv6
Most important is End to End IPv6 traffic forwarding
no impact on IPv4 traffic & revenues
Dual stack Networks
IPv6 over MPLS or IPv4-IPv6 Dual Stack Routers
Media - Interface Identifier
IEEE interfaces - EUI-64 MAC-address: 0050.a218.0c38 Interface ID: 250:A2FF:FE18:C38 P2P links (HDLC, PPP) Interface ID: 50:A218:C00:D 48 bits from the first MAC address in the box + 16 bit interface index. U/L bit off IPv4 tunnels Interface ID: ::a.b.c.d
Outline
Protocol Background Technology Highlights Enhanced Capabilities Transition Issues Next Steps
Current Status
Standards
core IPv6 specifications are IETF Draft Standards => well-tested & stable
other important specs are further behind on the standards track, but in good shape
IPv6 base spec, ICMPv6, Neighbor Discovery, PMTU Discovery, IPv6-over-Ethernet, IPv6-over-PPP,...
mobile IPv6, header compression, A6 DNS support,... for up-to-date status: playground.sun.com/ipng
UMTS R5 cellular wireless standards mandate IPv6
Implementations
Most IP stack vendors have an implementation at some stage of completeness
some are shipping supported product today, e.g., 3Com, *BSD(KAME), Cisco, Epilogue, Ericsson/Telebit, IBM, Hitachi, NEC, Nortel, Sun, Trumpet others have beta releases now, supported products soon, e.g., Compaq, HP, Linux community, Microsoft others rumored to be implementing, but status unkown (to me), e.g., Apple, Bull, Juniper, Mentat, Novell, SGI (see playground.sun.com/ipng for most recent status reports)
Good attendance at frequent testing events
IPv6 Addresses Bootstrap phase
Where to get address space?
Real IPv6 address space now allocated by APNIC, ARIN and RIPE NCC APNIC ARIN RIPE NCC 6Bone
2001:0200::/23 2001:0400::/23 2001:0600::/23 3FFE::/16
Have a look at www.cisco.com/ipv6 for further information
IPv6 Address Space Current Allocations
APNIC (whois.apnic.net)
CONNECT-AU-19990916 2001:210::/35 WIDE-JP-19990813 2001:200::/35
SONYTELECOM-JPNIC-JP-20001207 2001:298::/35 TTNET-JPNIC-JP-20001208 2001:2A0::/35 CCCN-JPNIC-JP-20001228 2001:02A8::/35 IMNET-JPNIC-JP-20000314 2001:0248::/35
NUS-SG-19990827 2001:208::/35 KIX-KR-19991006 2001:220::/35
KORNET-KRNIC-KR-20010102 2001:02B0::/35
ETRI-KRNIC-KR-19991124 2001:230::/35
NTT-JP-19990922 2001:218::/35
ESNET-V6 2001:0400::/35 ARIN-001 2001:0400::/23 VBNS-IPV6 2001:0408::/35 CANET3-IPV6 2001:0410::/35 VRIO-IPV6-0 2001:0418::/35 CISCO-IPV6-1 2001:0420::/35 QWEST-IPV6-1 2001:0428::/35 DEFENSENET 2001:0430::/35 ABOVENET-IPV6 2001:0438::/35 SPRINT-V6 2001:0440::/35 UNAM-IPV6 2001:0448::/35 GBLX-V6 2001:0450::/35
HINET-TW-20000208 2001:238::/35 IIJ-JPNIC-JP-20000308 2001:240::/35 CERNET-CN-20000426 2001:250::/35 INFOWEB-JPNIC-JP-2000502 2001:258::/35 JENS-JP-19991027 2001:228::/35 BIGLOBE-JPNIC-JP-20000719 2001:260::/35 6DION-JPNIC-JP-20000829 2001:268::/35
DACOM-BORANET-20000908 2001:270::/35 ODN-JPNIC-JP-20000915 2001:278::/35 KOLNET-KRNIC-KR-20000927 2001:280::/35 HANANET-KRNIC-KR-20001030 2001:290::/35 TANET-TWNIC-TW-20001006 2001:288::/35
ARIN (whois.arin.net)
January 5th, 2001
IPv6 Address Space Current Allocations
RIPE (whois.ripe.net)
EU-EUNET-20000403 2001:0670::/35
UK-BT-19990903 2001:0618::/35
DE-IPF-20000426 2001:0678::/35
CH-SWITCH-19990903 2001:0620::/35
DE-NACAMAR-20000403 2001:0668::/35
AT-ACONET-19990920 2001:0628::/35
DE-XLINK-20000510 2001:0680::/35
UK-JANET-19991019 2001:0630::/35 DE-DFN-19991102 2001:0638::/35 NL-SURFNET-19990819 2001:0610::/35
DE-ECRC-19991223 2001:0650::/35 FR-TELECOM-20000623 2001:0688::/35 PT-RCCN-20000623 2001:0690::/35 SE-SWIPNET-20000828 2001:0698::/35
RU-FREENET-19991115 2001:0640::/35 GR-GRNET-19991208 2001:0648::/35 EU-UUNET-19990810 2001:0600::/35 DE-TRMD-20000317 2001:0658::/35 FR-RENATER-20000321 2001:0660::/35
PL-ICM-20000905 2001:06A0::/35 DE-SPACE-19990812 2001:0608::/35 BE-BELNET-20001101 2001:06A8::/35 SE-SUNET-20001218 2001:06B0::/35 IT-CSELT-20001221 2001:06B8::/35 SE-TELIANET-20010102 2001:06C0::/35
Deployment
experimental infrastructure: the 6bone
production infrastructure in support of education and research: the 6ren
for testing and debugging IPv6 protocols and operations (see www.6bone.net)
CAIRN, Canarie, CERNET, Chunahwa Telecom, Dante, ESnet, Internet 2, IPFNET, NTT, Renater, Singren, Sprint, SURFnet, vBNS, WIDE (see www.6ren.net, www.6tap.net)
commercial infrastructure
a few ISPs (IIJ, NTT, SURFnet, Trumpet,…) have announced commercial IPv6 service or service trials
Deployment (cont.)
IPv6 address allocation
6bone procedure for test address space regional IP address registries (APNIC, ARIN, RIPE-NCC) for production address space
deployment advocacy (a.k.a. marketing)
IPv6 Forum: www.ipv6forum.com
Much Still To Do though IPv6 today has all the functional capability of IPv4, implementations are not as advanced (e.g., with respect to performance, multicast support, compactness, instrumentation, etc.) deployment has only just begun much work to be done moving application, middleware, and management software to IPv6 much training work to be done (application developers, network administrators, sales staff,…) many of the advanced features of IPv6 still need specification, implementation, and deployment work
Recent IPv6 ―Hot Topics‖ in the IETF
multihoming / address selection address allocation DNS discovery 3GPP usage of IPv6 anycast addressing scoped address architecture flow-label semantics API issues
enhanced router-to-host info site renumbering procedures temp. addresses for privacy inter-domain multicast routing address propagation and AAA issues of different access scenarios
(always-on, dial-up, mobile,…)
and, of course, transition / co-existence / interoperability with IPv4
(flow label, traffic class, PMTU discovery, scoping,…)
Note: this indicates vitality, not incompleteness, of IPv6!
Next Steps
For More Information
http://www.ietf.org/html.charters/ipngwgcharter.html http://www.ietf.org/html.charters/ngtranscharter.html http://playground.sun.com/ipv6/ http://www.6bone.net/ngtrans/
For More Information
http://www.6bone.net http://www.ipv6forum.com http://www.ipv6.org http://www.cisco.com/ipv6/ http://www.microsoft.com/windows2000/librar y/howitworks/communications/networkbasics/ IPv6.asp
For More Information
BGP4+ References
RFC2858 Multiprotocol extension to BGP RFC2545 BGP MP for IPv6 RFC2842 Capability negotiation
RIPng RFC2080
Other Sources of Information
Books
IPv6, The New Internet Protocol by Christian Huitema (Prentice Hall) Internetworking IPv6 with Cisco Routers by Silvano Gai (McGraw-Hill) and many more... (14 hits at Amazon.com)
Questions?
2213 1313_06_2000_c2
© 2000, Cisco Systems, Inc.
119
Cisco Systems
Outline
Protocol Background Technology Highlights Enhanced Capabilities Transition Issues Next Steps
Background
Why a New IP?
1991 – ALE WG studied projections about address consumption rate showed exhaustion by 2008.
Bake-off in mid-1994 selected approach of a new protocol over multiple layers of encapsulation.
What Ever Happened to IPv5? 0
IP (deprecated) IP IP IP IPv4 ST
March 1977 version
1 January 1978 version (deprecated) 2 February 1978 version A (deprecated) 3 February 1978 version B (deprecated) 4 September 1981 version (current widespread) 5 Stream Transport (not a new IP, little use) 6 IPv6 December 1998 version (formerly SIP, SIPP) 7 CATNIP IPng evaluation (formerly TP/IX; deprecated) 8 Pip IPng evaluation (deprecated) 9 TUBA IPng evaluation (deprecated) 10-15 unassigned
What about technologies & efforts to slow the consumption rate?
Dial-access / PPP / DHCP
Strict allocation policies
Reduced allocation rates by policy of ‗current-need‘ vs. previous policy based on ‗projected-maximum-size‘.
CIDR
Provides temporary allocation aligned with actual endpoint use.
Aligns routing table size with needs-based address allocation policy. Additional enforced aggregation actually lowered routing table growth rate to linear for a few years.
NAT
Hides many nodes behind limited set of public addresses.
What did intense conservation efforts of the last 5 years buy us?
Actual allocation history
1981 – IPv4 protocol published 1985 ~ 1/16 total space 1990 ~ 1/8 total space 1995 ~ 1/4 total space 2000 ~ 1/2 total space
The lifetime-extending efforts & technologies delivered the ability to absorb the dramatic growth in consumer demand during the late 90‘s. In short they bought – TIME –
Would increased use of NATs be adequate?
NAT enforces a ‗client-server‘ application model where the server has topological constraints.
NO!
They won‘t work for peer-to-peer or devices that are ―called‖ by others (e.g., IP phones) They inhibit deployment of new applications and services, because all NATs in the path have to be upgraded BEFORE the application can be deployed.
NAT compromises the performance, robustness, and security of the Internet. NAT increases complexity and reduces manageability of the local network. Public address consumption is still rising even with current NAT deployments.
What were the goals of a new IP design?
Expectation of a resurgence of ―always-on‖ technologies
xDSL, cable, Ethernet-to-the-home, Cell-phones, etc.
Expectation of new users with multiple devices.
China, India, etc. as new growth Consumer appliances as network devices
(1015 endpoints)
Expectation of millions of new networks.
Expanded competition and structured delegation.
(1012 sites)
Return to an End-to-End Architecture New Technologies/Applications for Home Users ‘Always-on’—Cable, DSL, Ethernet@home, Wireless,…
Always-on Devices Need an Address When You Call Them
Global Addressing Realm
Why is a larger address space needed?
Overall Internet is still growing its user base
:
~550 million users by 2005
Users expanding their connected device count
~320 million users in 2000
405 million mobile phones in 2000, over 1 billion by 2005 UMTS Release 5 is Internet Mobility, ~ 300M new Internet connected
~1 Billion cars in 2010 15% likely to use GPS and locality based Yellow Page services
Billions of new Internet appliances for Home users Always-On ; Consumer simplicity required
Emerging population/geopolitical & economic drivers
MIT, Xerox, & Apple each have more address space than all of China Moving to an e-Economy requires Global Internet accessibility
Why Was 128 Bits Chosen as the IPv6 Address Size? Proposals for fixed-length, 64-bit addresses
Accommodates 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 on current CPU hardware
Proposals for variable-length, up to 160 bits
Compatible with deployed OSI NSAP addressing plans Accommodates auto-configuration using IEEE 802 addresses Sufficient structure for projected number of service providers
Settled on fixed-length, 128-bit addresses
(340,282,366,920,938,463,463,374,607,431,768,211,456 in all!)
Benefits of 128 bit Addresses
Room for many levels of structured hierarchy and routing aggregation Easy address auto-configuration Easier address management and delegation than IPv4 Ability to deploy end-to-end IPsec (NATs removed as unnecessary)
Incidental Benefits of New Deployment
Chance to eliminate some complexity in IP header
Chance to upgrade functionality
improve per-hop processing
multicast, QoS, mobility
Chance to include new features
binding updates
Summary of Main IPv6 Benefits
Expanded addressing capabilities Structured hierarchy to manage routing table growth Serverless autoconfiguration and reconfiguration Streamlined header format and flow identification Improved support for options / extensions
IPv6 Advanced Features
Source address selection Mobility - More efficient and robust mechanisms Security - Built-in, strong IP-layer encryption and authentication Quality of Service Privacy Extensions for Stateless Address Autoconfiguration (RFC 3041)
IPv6 Markets
Home Networking
Gaming (10B$ market)
Sony, Sega, Nintendo, Microsoft
Mobile devices Consumer PC Consumer Devices
Set-top box/Cable/xDSL/Ether@Home Residential Voice over IP gateway
Sony (Mar/01 - …energetically introducing IPv6 technology into hardware products …)
Enterprise PC Service Providers
Regional ISP, Carriers, Mobile ISP, and Greenfield ISP‘s
IPv6 Markets
Academic NRN:
Geographies & Politics:
Internet-II (Abilene, vBNS+), Canarie*3, Renater-II, Surfnet, DFN, CERNET,… 6REN/6TAP Prime Minister of Japan called for IPv6 (taxes reduction) EEC summit PR advertised IPv6 as the way to go for Europe China Vice minister of MII deploying IPv6 with the intent to take a leadership position and create a market force
Wireless (PDA, Mobile, Car,...):
Multiple phases before deployment RFP -> Integration -> trial -> commercial Requires ‗client devices‘, eg. IPv6 handset ?
Outline
Protocol Background Technology Highlights Enhanced Capabilities Transition Issues Next Steps
A new Header
The IPv6 Header 40 Octets, 8 fields 0
4 Version
12 Class
16
24
31
Flow Label
Payload Length
Next Header
128 bit Source Address
128 bit Destination Address
Hop Limit
The IPv4 Header 20 octets + options : 13 fields, including 3 flag bits 0
4 Ver
8 IHL
16 Service Type
Identifier Time to Live
24 Total Length Flags
Protocol
Fragment Offset Header Checksum
32 bit Source Address 32 bit Destination Address Options and Padding
shaded fields are absent from IPv6 header
31
Summary of Header Changes between IPv4 & IPv6 Streamlined
Revised
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 Time to Live Hop Limit Protocol Next Header Precedence & TOS Traffic Class Addresses increased 32 bits 128 bits
Extended
Flow Label field added
Extension Headers IPv6 header
TCP header + data
next header = TCP
IPv6 header
Routing header
TCP header + data
next header = Routing
next header = TCP
IPv6 header
Routing header
Fragment header
next header = Routing
next header = Fragment
next header = TCP
fragment of TCP header + data
Extension Headers (cont.)
Generally processed only by node identified in IPv6 Destination Address field => much lower overhead than IPv4 options processing
Eliminated IPv4‘s 40-byte limit on options
exception: Hop-by-Hop Options header in IPv6, 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
Fragment Header Next Header
Reserved Fragment Offset Original Packet Identifier
00M
though discouraged, can use IPv6 Fragment header to support upper layers that do not (yet) do path MTU discovery IPv6 frag. & reasm. is an end-to-end function; routers do not fragment packets en-route if too big—they send ICMP ―packet too big‖ instead
Routing Header
Routing
Same ―longest-prefix match‖ routing as IPv4 CIDR Straightforward changes to existing IPv4 routing protocols to handle bigger addresses
unicast: OSPF, RIP-II, IS-IS, BGP4+, … multicast: MOSPF, PIM, …
Use of Routing header with anycast addresses allows routing packets through particular regions
e.g., for provider selection, policy, performance, etc.
Routing Header Next Header
Hdr Ext Len Routing Type Reserved
Address[0]
Address[1] • • •
Segments Left
Example of Using the Routing Header S
A
B
D
Addressing
Some Terminology node router host link
neighbors interface address
a protocol module that implements IPv6 a node that forwards IPv6 packets not explicitly addressed to itself any node that is not a router a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IPv6 nodes attached to the same link a node‘s attachment to a link an IPv6-layer identifier for an interface or a set of interfaces
Text Representation of 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-compatible: 0:0:0:0:0:0:13.1.68.3 or ::13.1.68.3
IPv6 - Addressing Model
Addresses are assigned to interfaces No change from IPv4 Model
Interface ‘expected’ to have multiple addresses
Addresses have scope Link Local Site Local
Global
Global
Addresses have lifetime Valid and Preferred lifetime
Site-Local
Link-Local
Types of IPv6 Addresses
Unicast
Multicast
Address of a set of interfaces Delivery to all interfaces in the set
Anycast
Address of a single interface Delivery to single interface
Address of a set of interfaces Delivery to a single interface in the set
No more broadcast addresses
Interface Address set
Loopback
Link local Site local Auto-configured 6to4
(if IPv4 public is address available)
Auto-configured IPv4 compatible
(only assigned to a single virtual interface per node)
(operationally discouraged)
Solicited node Multicast All node multicast Global anonymous Global published
Source Address Selection Rules
Rule 1: Prefer same address Rule 2: Prefer appropriate scope
Rule 3: Avoid deprecated addresses Rule 4: Prefer home addresses Rule 5: Prefer outgoing interface Rule 6: Prefer matching label from policy table
Native IPv6 source > native IPv6 destination 6to4 source > 6to4 destination IPv4-compatible source > IPv4-compatible destination IPv4-mapped source> IPv4-mapped destination
Local policy may override
Smallest matching scope
Rule 7: Prefer temporary addresses Rule 8: Use longest matching prefix
Destination Address Selection Rules
Rule 1: Avoid unusable destinations Rule 2: Prefer matching scope Rule 3: Avoid dst with matching deprecated src address Rule 4: Prefer home addresses Rule 5: Prefer matching label from policy table
Native IPv6 source > native IPv6 destination 6to4 source > 6to4 destination IPv4-compatible source > IPv4-compatible destination IPv4-mapped source> IPv4-mapped destination
Local policy may override
Rule 6: Prefer higher precedence Rule 7: Prefer smaller scope Rule 8: Use longest matching prefix Rule 9: Order returned by DNS
Address Type Prefixes Address type IPv4-compatible global unicast link-local unicast site-local unicast multicast
Binary prefix 0000...0 (96 zero bits) 001 1111 1110 10 1111 1110 11 1111 1111
all other prefixes reserved (approx. 7/8ths of total) anycast addresses allocated from unicast prefixes
Global Unicast Addresses 001
TLA
NLA* public topology (45 bits)
SLA* site topology (16 bits)
interface ID interface identifier (64 bits)
TLA = Top-Level Aggregator NLA* = Next-Level Aggregator(s) SLA* = Site-Level Aggregator(s) all subfields variable-length, non-self-encoding (like CIDR) TLAs may be assigned to providers or exchanges
Link-Local & Site-Local Unicast Addresses Link-local addresses for use during auto-configuration and when no routers are present: 0
1111111010
interface ID
Site-local addresses for independence from changes of TLA / NLA*: 1111111011
0
SLA*
interface ID
Interface IDs Lowest-order 64-bit field of unicast address may be assigned in several different ways:
auto-configured from a 64-bit EUI-64, or expanded from a 48-bit MAC address (e.g., Ethernet address) auto-generated pseudo-random number (to address privacy concerns) assigned via DHCP manually configured possibly other methods in the future
Some Special-Purpose Unicast Addresses
The unspecified address, used as a placeholder when no address is available: 0:0:0:0:0:0:0:0
The loopback address, for sending packets to self: 0:0:0:0:0:0:0:1
Multicast Address Format FP (8bits)
Flags (4bits)
Scope (4bits)
RESERVED (80bits)
Group ID (32bits)
11111111
000T
Lcl/Sit/Gbl
MUST be 0
Locally administered
flag field
scope field:
low-order bit indicates permanent/transient group (three other flags reserved) 1 - node local 2 - link-local 5 - site-local (all other values reserved)
8 - organization-local B - community-local E - global
map IPv6 multicast addresses directly into low order 32 bits of the IEEE 802 MAC
Multicast Address Format Unicast-Prefix based
FP (8bits)
Flags (4bits)
Scope (4bits)
reserved (8bits)
plen (8bits)
Network Prefix (64bits)
Group ID (32bits)
11111111
00PT
Lcl/Sit/Gbl
MUST be 0
Locally administered
Unicast prefix
Auto configured
P = 1 indicates a multicast address that is assigned based on the network prefix plen indicates the actual length of the network prefix Source-specific multicast addresses is accomplished by setting
P=1 plen = 0 network prefix = 0
draft-ietf-ipngwg-uni-based-mcast-01.txt
Outline
Protocol Background Technology Highlights Enhanced Capabilities Transition Issues Next Steps
Security
IPv6 Security
All implementations required to support authentication and encryption headers (―IPsec‖) Authentication separate from encryption for use in situations where encryption is prohibited or prohibitively expensive Key distribution protocols are under development (independent of IP v4/v6) Support for manual key configuration required
Authentication Header Next Header
Hdr Ext Len
Reserved
Security Parameters Index (SPI) Sequence Number Authentication Data
Destination Address + SPI identifies security association state (key, lifetime, algorithm, etc.) Provides authentication and data integrity for all fields of IPv6 packet that do not change en-route Default algorithm is Keyed MD5
Encapsulating Security Payload (ESP) Security Parameters Index (SPI) Sequence Number
Payload
Padding
Padding Length
Authentication Data
Next Header
Quality of Service
IP Quality of Service Approaches Two basic approaches developed by IETF: ―Integrated Service‖ (int-serv)
fine-grain (per-flow), quantitative promises (e.g., x bits per second), uses RSVP signaling
―Differentiated Service‖ (diff-serv)
coarse-grain (per-class), qualitative promises (e.g., higher priority), no explicit signaling
IPv6 Support for Int-Serv 20-bit Flow Label field to identify specific flows needing special QoS
each source chooses its own Flow Label values; routers use Source Addr + Flow Label to identify distinct flows Flow Label value of 0 used when no special QoS requested (the common case today) this part of IPv6 is not standardized yet, and may well change semantics in the future
IPv6 Support for Diff-Serv 8-bit Traffic Class field to identify specific classes of packets needing special QoS
same as new definition of IPv4 Type-ofService byte may be initialized by source or by router enroute; may be rewritten by routers enroute traffic Class value of 0 used when no special QoS requested (the common case today)
Compromise
Signaled diff-serv (RFC 2998)
uses RSVP for signaling with course-grained qualitative aggregate markings allows for policy control without requiring per-router state overhead
Mobility
IPv6 Mobility
Mobile hosts have one or more home address
A Host will acquire a foreign address when it discovers it is in a foreign subnet (i.e., not its home subnet)
relatively stable; associated with host name in DNS
uses auto-configuration to get the address registers the foreign address with a home agent, i.e, a router on its home subnet
Packets sent to the mobile‘s home address(es) are intercepted by home agent and forwarded to the foreign address, using encapsulation Mobile IPv6 hosts will send binding-updates to correspondent to remove home agent from flow
Mobile IP (v4 version) mobile host
correspondent host
foreign agent
home agent
home location of mobile host
Mobile IP (v4 version) mobile host
correspondent host
foreign agent
home agent
home location of mobile host
Mobile IP (v4 version) mobile host
correspondent host
foreign agent
home agent
home location of mobile host
Mobile IP (v4 version) mobile host
correspondent host
foreign agent
home agent
home location of mobile host
Mobile IP (v6 version) mobile host
correspondent host
home agent
home location of mobile host
Mobile IP (v6 version) mobile host
correspondent host
home agent
home location of mobile host
Mobile IP (v6 version) mobile host
correspondent host
home agent
home location of mobile host
Mobile IP (v6 version) mobile host
correspondent host
home agent
home location of mobile host
Mobile IP (v6 version) mobile host
correspondent host
home agent
home location of mobile host
IPv6 Routing
RIPng
RIPv2, supports split-horizon with poisoned reverse RFC2080
BGP4+ Overview
Added IPv6 address-family Added IPv6 transport Runs within the same process - only one AS supported All generic BGP functionality works as for IPv4 Added functionality to route-maps and prefix-lists
IPv6 routing
OSPF & ISIS updated for IPv6
Outline
Protocol Background Technology Highlights Enhanced Capabilities Transition Issues Next Steps
Porting Issues
Effects on higher layers
Changes TCP/UDP checksum ―pseudo-header‖ Affects anything that reads/writes/stores/passes IP addresses (just about every higher protocol) Packet lifetime no longer limited by IP layer (it never was, anyway!) Bigger IP header must be taken into account when computing max payload sizes New DNS record type: AAAA and (new) A6 …
Sockets API Changes
Name to Address Translation Functions Address Conversion Functions Address Data Structures Wildcard Addresses Constant Additions Core Sockets Functions Socket Options New Macros
Core Sockets Functions
Core APIs Use
IPv6 Family and Address Structures socket() Uses PF_INET6
Functions that pass addresses bind() connect() sendmsg() sendto()
Functions that return addresses accept() recvfrom() recvmsg() getpeername()
getsockname()
Name to Address Translation getaddrinfo()
Pass in nodename and/or servicename string Can Be Address and/or Port
Optional Hints for Family, Type and Protocol
Pointer to Linked List of addrinfo structures Returned
Flags – AI_PASSIVE, AI_CANNONNAME, AI_NUMERICHOST, AI_NUMERICSERV, AI_V4MAPPED, AI_ALL, AI_ADDRCONFIG Multiple Addresses to Choose From
freeaddrinfo()
struct addrinfo { int ai_flags; int ai_family; int getaddrinfo( int ai_socktype; IN const char FAR * nodename, int ai_protocol; IN const char FAR * servname, size_t ai_addrlen; IN const struct addrinfo FAR * hints, char *ai_canonname; OUT struct addrinfo FAR * FAR * res struct sockaddr *ai_addr; ); struct addrinfo *ai_next; };
Address to Name Translation getnameinfo()
Pass in address (v4 or v6) and port
Size Indicated by salen Also Size for Name and Service buffers (NI_MAXHOST, NI_MAXSERV)
Flags
NI_NOFQDN NI_NUMERICHOST NI_NAMEREQD NI_NUMERICSERV NI_DGRAM
int getnameinfo( IN const struct sockaddr FAR * sa, IN socklen_t salen, OUT char FAR * host, IN size_t hostlen, OUT char FAR * serv, IN size_t servlen, IN int flags );
Porting Environments
Node Types
Application Types
IPv4-only IPv6-only IPv6/IPv4
IPv6-unaware IPv6-capable IPv6-required
IPv4 Mapped Addresses
Porting Issues
Running on ANY System
Including IPv4-only
Address Size Issues
New IPv6 APIs for IPv4/IPv6
Ordering of API Calls
User Interface Issues
Higher Layer Protocol Changes
Specific things to look for
Storing IP address in 4 bytes of an array.
Use of explicit dotted decimal format in UI.
Obsolete / New:
AF_INET
replaced by
AF_INET6
SOCKADDR_IN
replaced by
SOCKADDR_STORAGE
IPPROTO_IP
replaced by
IPPROTO_IPV6
IP_MULTICAST_LOOP replaced by SIO_MULTIPOINT_LOOPBACK
gethostbyname
replaced by
getaddrinfo
gethostbyaddr
replaced by
getnameinfo
IPv6 literal addresses in URL‘s From RFC 2732 Literal IPv6 Address Format in URL's Syntax To use a literal IPv6 address in a URL, the literal address should be enclosed in "[" and "]" characters. For example the following literal IPv6 addresses: FEDC:BA98:7654:3210:FEDC:BA98:7654:3210 3ffe:2a00:100:7031::1 ::192.9.5.5 2010:836B:4179::836B:4179
would be represented as in the following example URLs: http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html http://[3ffe:2a00:100:7031::1] http://[::192.9.5.5]/ipng http://[2010:836B:4179::836B:4179]
Other Issues
Renumbering & Mobility routinely result in changing IP Addresses –
Use Names and Resolve, Don‘t Cache
Multihomed Servers
More Common with IPv6
Try All Addresses Returned
Using New IPv6 Functionality
Porting Steps -Summary
Use IPv4/IPv6 Protocol/Address Family
Fix Address Structures in6_addr sockaddr_in6 sockaddr_storage
to allocate storage
Fix Wildcard Address Use in6addr_any,
IN6ADDR_ANY_INIT in6addr_loopback, IN6ADDR_LOOPBACK_INIT
Use IPv6 Socket Options IPPROTO_IPV6,
Options as Needed
Use getaddrinfo() For
Address Resolution
IPv4 - IPv6 Co-Existence / Transition
IPv6 Timeline (A pragmatic projection) 2000
2001
2002
2003
2004
Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
2005
2006
2007
Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
• Early adopter • Application porting <= Duration 3+ years
=>
• ISP adoption <= Duration 3+ years => • Consumer adoption
<=
Duration 5+ years =>
• Enterprise adoption <= Duration 3+ years =>
Deployments
IPv6 deployments will occur piecewise from the edge.
Core infrastructure only moving when significant customer usage demands it.
Platforms and products that are updated first need to address the lack of ubiquity. Whenever possible, devices and applications should be capable of both IPv4 & IPv6, to minimize the delays and potential failures inherent in translation points.
Impediments to IPv6 deployment
Applications Applications Applications
Move to the new APIs NOW
Transition / Co-Existence Techniques A wide range of techniques have been identified and implemented, basically falling into three categories:
(1) dual-stack techniques, to allow IPv4 and IPv6 to co-exist in the same devices and networks
(2) tunneling techniques, to avoid order dependencies when upgrading hosts, routers, or regions
(3) translation techniques, to allow IPv6-only devices to communicate with IPv4-only devices
Expect all of these to be used, in combination
Dual-Stack Approach
When adding IPv6 to a system, do not delete IPv4
this multi-protocol approach is familiar and well-understood (e.g., for AppleTalk, IPX, etc.) note: in most cases, IPv6 will be bundled with new OS releases, not an extra-cost add-on
Applications (or libraries) choose IP version to use
when initiating, based on DNS response: Prefer
scope match first, when equal IPv6 over IPv4
when responding, based on version of initiating packet
This allows indefinite co-existence of IPv4 and IPv6, and gradual app-by-app upgrades to IPv6 usage
Tunnels to Get Through IPv6-Ignorant Routers
Encapsulate IPv6 packets inside IPv4 packets (or MPLS frames) Many methods exist for establishing tunnels:
manual configuration ―tunnel brokers‖ (using web-based service to create a tunnel) automatic (depricated, using IPv4 as low 32bits of IPv6) ―6-over-4‖ (intra-domain, using IPv4 multicast as virtual LAN) ―6-to-4‖ (inter-domain, using IPv4 addr as IPv6 site prefix)
Can view this as:
IPv6 using IPv4 as a virtual NBMA link-layer, or an IPv6 VPN (virtual public network), over the IPv4 Internet
Translation
May prefer to use IPv6-IPv4 protocol translation for:
new kinds of Internet devices (e.g., cell phones, cars, appliances) benefits of shedding IPv4 stack (e.g., serverless autoconfig)
This is a simple extension to NAT techniques, to translate header format as well as addresses
IPv6 nodes behind a translator get full IPv6 functionality when talking to other IPv6 nodes located anywhere they get the normal (i.e., degraded) NAT functionality when talking to IPv4 devices drawback : minimal gain over IPv4/IPv4 NAT approach
Tunnels
6to4 Configured Automatic
6to4 tunnels FP (3bits)
TLA (13bits)
IPv4 Address (32bits)
SLA ID (16bits)
Interface ID (64bits)
001
0x0002
ISP assigned
Locally administered
Auto configured
2002:8243:1::/48 2002:947A:1::/48
IPv4
IPv6
IPv6 148.122.0.1
130.67.0.1
11.0.0.1 6to4 prefix is 2002::/16 + IPv4 address. 2002:a.b.c.d::/48
IPv6 Internet 6to4 relay 2002:B00:1::1 Announces 2002::/16 to the IPv6 Internet
6to4 tunnels II Pros
Cons
Minimal configuration
All issues that NMBA networks have.
Only site border router needs to know about 6to4
Requires relay router to reach native IPv6 Internet
Works without adjacent native IPv6 routers
Has to use 6to4 addresses, not native.
NB: there is a draft describing how to use IPv4 anycast to reach the relay router. (This is already supported, by our implementation...)
Configured tunnels 3ffe:c00:2::/48 3ffe:c00:1::/48
IPv4
IPv6
IPv6 130.67.0.1
-------------------------------------|IPv4 header|IPv6 header IPv6 payload| -------------------------------------IPv4 protocol type = 41
148.122.0.1
Configured tunnels II Pros
Cons
As point to point links
Has to be configured and managed
Multicast
Inefficient traffic patterns
Real addresses
No keepalive mechanism, interface is always up
Automatic tunnels 0
IPv4 Address (32bits)
Defined
ISP assigned
148.122.0.1 ::148.122.0.1
130.67.0.1 ::130.67.0.1
IPv6
Connects dual stacked nodes Quite obsolete
IPv4
IPv6
IPv6 Internet
Automatic tunnels II Pros
Cons
Obsolete
Difficult to reach the native IPv6 Internet, without injecting IPv4 routing information in the IPv6 routing table
Useful for some other mechanisms, like BGP tunnels
Has to use IPv4 compatible addresses
Tunneling issues
IPv4 fragmentation needs to be reconstructed at tunnel endpoint. No translation of Path MTU messages between IPv4 & IPv6. Translating IPv4 ICMP messages and pass back to IPv6 originator. May result in an inefficient topology.
Tunneling issues II
Tunnel interface is always up. Use routing protocol to determine link failures. Be careful with using the same IPv4 source address for several tunneling mechanisms. Demultiplexing incoming packets is difficult.
Deployment scenarios
Many ways to deliver IPv6 services to End Users
Service Providers and Enterprises may have different deployment needs IPv6 over IPv4 tunnels Dedicated Data Link layers for native IPv6
Most important is End to End IPv6 traffic forwarding
no impact on IPv4 traffic & revenues
Dual stack Networks
IPv6 over MPLS or IPv4-IPv6 Dual Stack Routers
Media - Interface Identifier
IEEE interfaces - EUI-64 MAC-address: 0050.a218.0c38 Interface ID: 250:A2FF:FE18:C38 P2P links (HDLC, PPP) Interface ID: 50:A218:C00:D 48 bits from the first MAC address in the box + 16 bit interface index. U/L bit off IPv4 tunnels Interface ID: ::a.b.c.d
Outline
Protocol Background Technology Highlights Enhanced Capabilities Transition Issues Next Steps
Current Status
Standards
core IPv6 specifications are IETF Draft Standards => well-tested & stable
other important specs are further behind on the standards track, but in good shape
IPv6 base spec, ICMPv6, Neighbor Discovery, PMTU Discovery, IPv6-over-Ethernet, IPv6-over-PPP,...
mobile IPv6, header compression, A6 DNS support,... for up-to-date status: playground.sun.com/ipng
UMTS R5 cellular wireless standards mandate IPv6
Implementations
Most IP stack vendors have an implementation at some stage of completeness
some are shipping supported product today, e.g., 3Com, *BSD(KAME), Cisco, Epilogue, Ericsson/Telebit, IBM, Hitachi, NEC, Nortel, Sun, Trumpet others have beta releases now, supported products soon, e.g., Compaq, HP, Linux community, Microsoft others rumored to be implementing, but status unkown (to me), e.g., Apple, Bull, Juniper, Mentat, Novell, SGI (see playground.sun.com/ipng for most recent status reports)
Good attendance at frequent testing events
IPv6 Addresses Bootstrap phase
Where to get address space?
Real IPv6 address space now allocated by APNIC, ARIN and RIPE NCC APNIC ARIN RIPE NCC 6Bone
2001:0200::/23 2001:0400::/23 2001:0600::/23 3FFE::/16
Have a look at www.cisco.com/ipv6 for further information
IPv6 Address Space Current Allocations
APNIC (whois.apnic.net)
CONNECT-AU-19990916 2001:210::/35 WIDE-JP-19990813 2001:200::/35
SONYTELECOM-JPNIC-JP-20001207 2001:298::/35 TTNET-JPNIC-JP-20001208 2001:2A0::/35 CCCN-JPNIC-JP-20001228 2001:02A8::/35 IMNET-JPNIC-JP-20000314 2001:0248::/35
NUS-SG-19990827 2001:208::/35 KIX-KR-19991006 2001:220::/35
KORNET-KRNIC-KR-20010102 2001:02B0::/35
ETRI-KRNIC-KR-19991124 2001:230::/35
NTT-JP-19990922 2001:218::/35
ESNET-V6 2001:0400::/35 ARIN-001 2001:0400::/23 VBNS-IPV6 2001:0408::/35 CANET3-IPV6 2001:0410::/35 VRIO-IPV6-0 2001:0418::/35 CISCO-IPV6-1 2001:0420::/35 QWEST-IPV6-1 2001:0428::/35 DEFENSENET 2001:0430::/35 ABOVENET-IPV6 2001:0438::/35 SPRINT-V6 2001:0440::/35 UNAM-IPV6 2001:0448::/35 GBLX-V6 2001:0450::/35
HINET-TW-20000208 2001:238::/35 IIJ-JPNIC-JP-20000308 2001:240::/35 CERNET-CN-20000426 2001:250::/35 INFOWEB-JPNIC-JP-2000502 2001:258::/35 JENS-JP-19991027 2001:228::/35 BIGLOBE-JPNIC-JP-20000719 2001:260::/35 6DION-JPNIC-JP-20000829 2001:268::/35
DACOM-BORANET-20000908 2001:270::/35 ODN-JPNIC-JP-20000915 2001:278::/35 KOLNET-KRNIC-KR-20000927 2001:280::/35 HANANET-KRNIC-KR-20001030 2001:290::/35 TANET-TWNIC-TW-20001006 2001:288::/35
ARIN (whois.arin.net)
January 5th, 2001
IPv6 Address Space Current Allocations
RIPE (whois.ripe.net)
EU-EUNET-20000403 2001:0670::/35
UK-BT-19990903 2001:0618::/35
DE-IPF-20000426 2001:0678::/35
CH-SWITCH-19990903 2001:0620::/35
DE-NACAMAR-20000403 2001:0668::/35
AT-ACONET-19990920 2001:0628::/35
DE-XLINK-20000510 2001:0680::/35
UK-JANET-19991019 2001:0630::/35 DE-DFN-19991102 2001:0638::/35 NL-SURFNET-19990819 2001:0610::/35
DE-ECRC-19991223 2001:0650::/35 FR-TELECOM-20000623 2001:0688::/35 PT-RCCN-20000623 2001:0690::/35 SE-SWIPNET-20000828 2001:0698::/35
RU-FREENET-19991115 2001:0640::/35 GR-GRNET-19991208 2001:0648::/35 EU-UUNET-19990810 2001:0600::/35 DE-TRMD-20000317 2001:0658::/35 FR-RENATER-20000321 2001:0660::/35
PL-ICM-20000905 2001:06A0::/35 DE-SPACE-19990812 2001:0608::/35 BE-BELNET-20001101 2001:06A8::/35 SE-SUNET-20001218 2001:06B0::/35 IT-CSELT-20001221 2001:06B8::/35 SE-TELIANET-20010102 2001:06C0::/35
Deployment
experimental infrastructure: the 6bone
production infrastructure in support of education and research: the 6ren
for testing and debugging IPv6 protocols and operations (see www.6bone.net)
CAIRN, Canarie, CERNET, Chunahwa Telecom, Dante, ESnet, Internet 2, IPFNET, NTT, Renater, Singren, Sprint, SURFnet, vBNS, WIDE (see www.6ren.net, www.6tap.net)
commercial infrastructure
a few ISPs (IIJ, NTT, SURFnet, Trumpet,…) have announced commercial IPv6 service or service trials
Deployment (cont.)
IPv6 address allocation
6bone procedure for test address space regional IP address registries (APNIC, ARIN, RIPE-NCC) for production address space
deployment advocacy (a.k.a. marketing)
IPv6 Forum: www.ipv6forum.com
Much Still To Do though IPv6 today has all the functional capability of IPv4, implementations are not as advanced (e.g., with respect to performance, multicast support, compactness, instrumentation, etc.) deployment has only just begun much work to be done moving application, middleware, and management software to IPv6 much training work to be done (application developers, network administrators, sales staff,…) many of the advanced features of IPv6 still need specification, implementation, and deployment work
Recent IPv6 ―Hot Topics‖ in the IETF
multihoming / address selection address allocation DNS discovery 3GPP usage of IPv6 anycast addressing scoped address architecture flow-label semantics API issues
enhanced router-to-host info site renumbering procedures temp. addresses for privacy inter-domain multicast routing address propagation and AAA issues of different access scenarios
(always-on, dial-up, mobile,…)
and, of course, transition / co-existence / interoperability with IPv4
(flow label, traffic class, PMTU discovery, scoping,…)
Note: this indicates vitality, not incompleteness, of IPv6!
Next Steps
For More Information
http://www.ietf.org/html.charters/ipngwgcharter.html http://www.ietf.org/html.charters/ngtranscharter.html http://playground.sun.com/ipv6/ http://www.6bone.net/ngtrans/
For More Information
http://www.6bone.net http://www.ipv6forum.com http://www.ipv6.org http://www.cisco.com/ipv6/ http://www.microsoft.com/windows2000/librar y/howitworks/communications/networkbasics/ IPv6.asp
For More Information
BGP4+ References
RFC2858 Multiprotocol extension to BGP RFC2545 BGP MP for IPv6 RFC2842 Capability negotiation
RIPng RFC2080
Other Sources of Information
Books
IPv6, The New Internet Protocol by Christian Huitema (Prentice Hall) Internetworking IPv6 with Cisco Routers by Silvano Gai (McGraw-Hill) and many more... (14 hits at Amazon.com)
Questions?
2213 1313_06_2000_c2
© 2000, Cisco Systems, Inc.
119
Cisco Systems
More Documents from "Sameh Ahmed Hassan"
Curs_ipv6
February 2021 1
Lada 2107 Spare Parts Catalog
March 2021 0
Championship Street Fighting
February 2021 0
Term Iv - Electives (email Id's)
February 2021 0
