Curs IPv6 PDF
Curs IPv6 PDF
Outline
Protocol Background Technology Highlights Enhanced Capabilities Transition Issues Next Steps
Background
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.
IP (deprecated) IP IP IP IPv4 ST
Reduced allocation rates by policy of current-need vs. previous policy based on projected-maximum-size.
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.
CIDR
NAT
What did intense conservation efforts of the last 5 years buy us?
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 90s. In short they bought TIME
NO!
NAT enforces a client-server application model where the server has topological constraints.
They wont 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.
xDSL, cable, Ethernet-to-the-home, Cell-phones, etc. China, India, etc. as new growth Consumer appliances as network devices
(1015 endpoints)
(1012 sites)
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
Compatible with deployed OSI NSAP addressing plans Accommodates auto-configuration using IEEE 802 addresses Sufficient structure for projected number of service providers
(340,282,366,920,938,463,463,374,607,431,768,211,456 in all!)
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)
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
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
IPv6 Markets
Academic NRN:
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
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
Payload Length
4
IHL
16
Service Type Flags
24
Total Length Fragment Offset Header Checksum
31
Identifier
Time to Live
Protocol
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
Revised
Extended
Extension Headers
IPv6 header next header = TCP TCP header + data
Generally processed only by node identified in IPv6 Destination Address field => much lower overhead than IPv4 options processing
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 bigthey 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
Use of Routing header with anycast addresses allows routing packets through particular regions
Routing Header
Next Header Hdr Ext Len Routing Type Reserved Segments Left
Address[0]
Address[1]
Addressing
Some Terminology
node router
host link
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 nodes attachment to a link an IPv6-layer identifier for an interface or a set of interfaces
or ::13.1.68.3
Global
Site-Local
Link-Local
Global
Unicast
Multicast
Anycast
Loopback
(operationally discouraged)
Solicited node Multicast All node multicast Global anonymous Global published
Native IPv6 source > native IPv6 destination 6to4 source > 6to4 destination IPv4-compatible source > IPv4-compatible destination IPv4-mapped source> IPv4-mapped destination
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
Rule 6: Prefer higher precedence Rule 7: Prefer smaller scope Rule 8: Use longest matching prefix Rule 9: Order returned by DNS
Native IPv6 source > native IPv6 destination 6to4 source > 6to4 destination IPv4-compatible source > IPv4-compatible destination IPv4-mapped source> IPv4-mapped destination
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
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
interface ID
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
flag field
scope field:
map IPv6 multicast addresses directly into low order 32 bits of the IEEE 802 MAC
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
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 Sequence Number Reserved Security Parameters Index (SPI)
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
Payload
Padding
Padding Length
Next Header
Authentication Data
Quality of Service
fine-grain (per-flow), quantitative promises (e.g., x bits per second), uses RSVP signaling
coarse-grain (per-class), qualitative promises (e.g., higher priority), no explicit signaling
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
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
uses RSVP for signaling with course-grained qualitative aggregate markings allows for policy control without requiring per-router state overhead
Mobility
IPv6 Mobility
A Host will acquire a foreign address when it discovers it is in a foreign subnet (i.e., not its home subnet)
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 mobiles 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
correspondent host
foreign agent
home agent
correspondent host
foreign agent
home agent
correspondent host
foreign agent
home agent
correspondent host
foreign agent
home agent
correspondent host
home agent
correspondent host
home agent
correspondent host
home agent
correspondent host
home agent
correspondent host
home agent
IPv6 Routing
RIPng
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
Outline
Protocol Background Technology Highlights Enhanced Capabilities Transition Issues Next Steps
Porting Issues
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
Name to Address Translation Functions Address Conversion Functions Address Data Structures Wildcard Addresses Constant Additions Core Sockets Functions Socket Options New Macros
Core APIs
Use
sendmsg()
sendto()
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; };
Size Indicated by salen Also Size for Name and Service buffers (NI_MAXHOST, NI_MAXSERV)
NI_NOFQDN NI_NUMERICHOST NI_NAMEREQD NI_NUMERICSERV NI_DGRAM
Flags
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
Porting Issues
Including IPv4-only
Storing IP address in 4 bytes of an array. Use of explicit dotted decimal format in UI.
Obsolete / New:
gethostbyaddr
replaced by
getnameinfo
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
Multihomed Servers
to allocate storage
Options as Needed
Use getaddrinfo()
For
Address Resolution
IPv6 Timeline
(A pragmatic projection)
2000 2001 2002 2003 2004 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
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
ISP adoption <= Duration 3+ years => Consumer adoption <= Duration 5+ years =>
Deployments
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.
(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
Dual-Stack Approach
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 when initiating, based on DNS response:
Prefer
This allows indefinite co-existence of IPv4 and IPv6, and gradual app-by-app upgrades to IPv6 usage
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) IPv6 using IPv4 as a virtual NBMA link-layer, or an IPv6 VPN (virtual public network), over the IPv4 Internet
Translation
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 tunnels
FP (3bits) 001 TLA (13bits) 0x0002 IPv4 Address (32bits) ISP assigned SLA ID (16bits) Locally administered Interface ID (64bits) Auto configured
2002:8243:1::/48 2002:947A:1::/48
IPv6
130.67.0.1
IPv4
148.122.0.1
IPv6
11.0.0.1
6to4 prefix is 2002::/16 + IPv4 address. 2002:a.b.c.d::/48 IPv6 Internet
6to4 tunnels II
Pros
Minimal configuration Only site border router needs to know about 6to4 Works without adjacent native IPv6 routers
Cons
All issues that NMBA networks have. Requires relay router to reach native IPv6 Internet 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
130.67.0.1 148.122.0.1
IPv6
Configured tunnels II
Pros
As point to point links Multicast Real addresses
Cons
Has to be configured and managed Inefficient traffic patterns No keepalive mechanism, interface is always up
Automatic tunnels
0
Defined
IPv4 Address (32bits)
ISP assigned
130.67.0.1 ::130.67.0.1
148.122.0.1 ::148.122.0.1
IPv6
IPv4
IPv6
IPv6 Internet
Automatic tunnels II
Pros
Obsolete
Cons
Difficult to reach the native IPv6 Internet, without injecting IPv4 routing information in the IPv6 routing table
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
Service Providers and Enterprises may have different deployment needs IPv6 over IPv4 tunnels Dedicated Data Link layers for native IPv6
no impact on IPv4 traffic & revenues IPv6 over MPLS or IPv4-IPv6 Dual Stack Routers
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
IPv6 base spec, ICMPv6, Neighbor Discovery, PMTU Discovery, IPv6-over-Ethernet, IPv6-over-PPP,...
other important specs are further behind on the standards track, but in good shape
mobile IPv6, header compression, A6 DNS support,... for up-to-date status: playground.sun.com/ipng
Implementations
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)
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
APNIC (whois.apnic.net)
CONNECT-AU-19990916 2001:210::/35
WIDE-JP-19990813 2001:200::/35 NUS-SG-19990827 2001:208::/35 KIX-KR-19991006 2001:220::/35 ETRI-KRNIC-KR-19991124 2001:230::/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 KORNET-KRNIC-KR-20010102 2001:02B0::/35
ARIN (whois.arin.net)
NTT-JP-19990922 2001:218::/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
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
RIPE (whois.ripe.net)
EU-EUNET-20000403 2001:0670::/35
UK-BT-19990903 2001:0618::/35 CH-SWITCH-19990903 2001:0620::/35 AT-ACONET-19990920 2001:0628::/35 UK-JANET-19991019 2001:0630::/35 DE-DFN-19991102 2001:0638::/35 NL-SURFNET-19990819 2001:0610::/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
DE-IPF-20000426 2001:0678::/35
DE-NACAMAR-20000403 2001:0668::/35 DE-XLINK-20000510 2001:0680::/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 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
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.)
6bone procedure for test address space regional IP address registries (APNIC, ARIN, RIPE-NCC) for production address space
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
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
Next Steps
BGP4+ References
RFC2858 Multiprotocol extension to BGP RFC2545 BGP MP for IPv6 RFC2842 Capability negotiation
RIPng RFC2080
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
119
Cisco Systems