Transcript Overview of IPv6

An overview of IPv6
Burt Crépeault :: [email protected]
www.iitelecom.com
1
IIT
© IITelecom,
2004
© Institut international des télécommunications inc., 2004
Overview of IPv6
Session objectives
At the end of this session, the participants should be able to:


2
IIT
© IITelecom,
2004
Explain the main changes introduced in IP version 6 compared to
IP version 4
Name the characteristics of the IP version 6 protocol
Session content
IPv6 overview



3
IIT
© IITelecom,
2004
Shortage of IPv4 addresses
Size problem with routing tables
IPv6 solutions and advantages:
–
Simplified configuration
–
Improved security
–
QoS and real-time services
–
Mobility mechanisms
–
Multimedia and multicast
Shortage of IP version 4 addresses

The addressing plan for IP version 4 defines 240 million usable
addresses, with only half currently assigned, because of:
–
–



unequal distribution
failure to return unused addresses
North America uses 70% of all public addresses while it only represents
10% of world population.
Asia holds 65% of the world population but only holds 15% of all public
addresses.
Many countries cannot get connected to the Internet. Some examples:
–
–
China obtained a class B address to connect 60,000 schools. In North
America, a class B is usually given to a single university.
Entire countries in Europe, Africa and Asia were only assigned a class C.
Internet service providers (ISP) must use private IP addresses in these
countries.

4
IIT
© IITelecom,
2004
Shortage of IP version 4 addresses
250
240
230
220
210
200
190
180
170
160
150
140
130
120
110
100
90
80
70
60
50
40
30
20
10
0
Allocation (0 or 1)
IANA IPv4 Address Allocation (2002-03)
Space (/8 unit)
* 69% of IP space assigned as of 2002-03
Source : IANA
5
IIT
© IITelecom,
2004
Addresses over 240 are
experimental (Class E).
Shortage of IP version 4 addresses
High-speed Internet:


More users are abandoning their PPP connection for a high-speed,
always-on Cable or xDSL service
2 Mbps UMTS and 11 Mbps WLAN
–
Each user needs a public address.
Increase in applications requiring a unique, globally routable IP
address :



6
IIT
© IITelecom,
2004
VOIP
Videoconference
Internet games
Shortage of IP version 4 addresses
Other communication technologies now (or may soon) require a
permanent Internet connection:




Over 500 million cellular phones
Over 900 million standard telephones
Hundreds of millions of televisions and radio sets
Industrial equipment
–

Various Internet Appliances
–
–
–
7
IIT
© IITelecom,
2004
Sensors and telemetry
Portable music players
Alarm systems
Etc…
Shortage of IP version 4 addresses
Overcome the shortage?

It is currently impossible to obtain an IP address for every individual.
Temporary solution:

Network Address Translation (NAT) :
–
8
IIT
© IITelecom,
2004
Converts a private address to a public address.
NAT shortcomings

Prevents deployment of new applications and services
–




Compromises performance, robustness and security
Increases complexity and makes local area network administration more
difficult
Need for public addresses continues to grow, despite increased use of
NAT
Breaks the end-to-end model:
–


9
IIT
© IITelecom,
2004
Doesn’t work in point-to-point applications where a station is “called” by
another (i.e. IP telephony)
Requires addition of Application Level Gateways (ALG), which are
considerably slower than pure IP routing
–

Every NAT in a path must be updated in order for the applications to work
properly.
Routers are fast, NAT+ALG are slow.
Requires that the network “remembers” the state of its connections
Makes rerouting more difficult
Routing tables: size problem
How to address the problem of exploding routing tables on the
Internet?

Too many class C addresses creates a size problem in the Internet
backbone routing tables
Temporary solution:

Classless Inter-Domain Routing (CIDR) :
–
–
–
–

CIDR allows an extension in the life of IP version 4.
Replaces the class A/B/C concept with an IP prefix
Reduces routing tables size
Allows regrouping of consecutive addresses into blocs (supernetting)
BGP 4 supports CIDR.
Permanent solution:


10
IIT
© IITelecom,
2004
Implement a hierarchical routing scheme on the Internet backbone
Not available with IP version 4
IPv6 solutions and advantages

Simplified configuration

Improved security

QoS and real-time services

Mobility mechanism

Multimedia and multicast
11
IIT
© IITelecom,
2004
Simplified configuration
IP version 6 allows host nodes to be configured according to
two modes:


Stateful (through a DHCP server)
Stateless (without DHCP)
The stateless mode is very simple:



12
IIT
© IITelecom,
2004
A host node on a network can assign itself an IPv6 address or derive it
from information received from a router.
If no router is present, host nodes on a LAN can still communicate to
each other using their link-local address without manual intervention!
The same mechanism is applied to find the node’s default gateway
Simplified configuration
Neighbour Discovery:



13
IIT
© IITelecom,
2004
IP version 6 includes a protocol to discover its neighbours (Neighbour
Discovery) based on ICMPv6.
This protocol replaces ARP and the ICMPv4 Router Discovery and
ICMPv4 Redirect messages.
Detecting absent nodes (Dead Peer Detection) is much more effective in
IPv6 than with ARP
Improved security
Shortcomings of Network Address Translation (NAT):


IPSec impossible from end-to-end
Will often require usage of a Proxy.
IPSec is built in IP version 6:


14
IIT
© IITelecom,
2004
This standard will enable interoperability between different IP version 6
implementations
It will also enable end-to-end security
QoS and real-time services
Shortcoming of Network Address Translation (NAT):

Protocols used by real-time applications require bi-directional
communication
–
RTP et RTCP used with VOIP and videoconference
The TOS field in IP version 4 is not implemented in the same
manner by the equipment manufacturers.

This makes it impossible to have an acceptable end-to-end QoS on
public or multi-vendor networks
In IP version 6:


15
IIT
© IITelecom,
2004
Standardized new fields in the header will make it possible to determine
the type of traffic and the priority assigned to it
Interactions between QoS and IPSec is managed in IP version 6, even
when data is encrypted
QoS and real-time services
IP version 6 is a much simpler protocol with regards to QoS:


The header is of fixed length
There is no fragmentation on the network
Allows a much better scalability than in IPv4:

Many QoS features of IPv4 were built as after-thoughts
Service identification based on TCP/UDP port number is still
possible when data is encrypted:

Not the case with IPv4
IP version 6 interacts very well with MPLS
16
IIT
© IITelecom,
2004
Mobility mechanism
How can an IP host node move from one network to another?



First solution : Mobile IPv4
IETF RFC 2002 : IP Mobility Support (IPv4)
Allows a node to use two IP addresses:
–
–

Creation of three new functional entities :
–
–
–
17
IIT
© IITelecom,
2004
A permanent home address
A temporary care-of address (CoA)
Mobile Node – MN
Home Agent – HA
Foreign Agent – FA
Mobility mechanism
When connected locally
18
IIT
© IITelecom,
2004
Mobility mechanism
Movement detection
19
IIT
© IITelecom,
2004
Mobility mechanism
Agent Discovery in IPv4
20
IIT
© IITelecom,
2004
Mobility mechanism
Mobile routing in IPv4 (using tunnelling)
21
IIT
© IITelecom,
2004
Mobility mechanism
Shortcomings of Mobile IPv4:




Triangular routing
The Mobile IP protocol requires additional resources (addresses,
bandwidth)
Tunnelling makes it difficult to support QoS
Requires fixed/public IP address (rather than dynamic/private)
Possible solution for triangular routing : MobileIPv4 Routing
Optimisation

IETF draft – not yet an RFC for now
Suggestion


Inform correspondent nodes (CN) of the mobile node’s care-of address and
open tunnel between MN and CN
Problem :
–
CN must be updated to support:
Binding cache
Security associations (SA) with HA and MN


22
IIT
© IITelecom,
2004
Mobile IP in IPv6
Mobile IP is natively supported by IPv6, including a few
improvements:




No Foreign Agent needed
Routing optimisation is built-in
Has automatic processes to acquire CoA
No input filters required
Mobile IPv6 strengths:

“Binding Update” et “Binding Ack” messages
–



23
IIT
© IITelecom,
2004
“Destination” header option allows exchange of location information
Use of “Binding Request” from the CN to the HA for location information
Use of IPv6 header eliminates triangular routing
The HA can tunnel the initial IP packets with an IPv6-in-IPv6
encapsulation
Multimedia
Shortcoming of Network Address Translation (NAT):

Many applications do not work (multimedia, Internet gaming)
There is a sharp inclination towards peer-to-peer applications




24
IIT
© IITelecom,
2004
Napster
MSN Messenger, ICQ
Internet games
VoIP
Multicast



IPv4 benefits from work done in IPv6 Multicast
Multicast Listener Discovery (MLD) and IGMPv2 now evolving in parallel
Advantages exclusive to IPv6 :
–
–
25
IIT
© IITelecom,
2004
Every IPv6 implementation MUST support multicast
It is easy to assign multicast addresses due to the enormous IPv6
addressing space
Questions?
?
26
IIT
© IITelecom,
2004
An overview of IPv6
Burt Crépeault :: [email protected]
www.iitelecom.com
27
IIT
© IITelecom,
2004
© Institut international des télécommunications inc., 2004
References
RFC 2460
Internet Protocol, Version 6 (IPv6) Specification.
December 1998.
(Status: DRAFT STANDARD)
RFC 3513
Internet Protocol Version 6 (IPv6) Addressing Architecture.
April 2003.
(Status: PROPOSED STANDARD)
An IPv6 Aggregatable Global Unicast Address Format.
July 1998.
(Status: PROPOSED STANDARD)
RFC 2374
IPv6 Multicast Address Assignments. July 1998.
(Status: INFORMATIONAL)
RFC 2464
Transmission of IPv6 Packets over Ethernet Networks.
December 1998. (Obsoletes RFC1972)
(Status: PROPOSED STANDARD)
www.ietf.org
28
IIT
RFC 2375
© IITelecom,
2004
References
RFC 2463
RFC 2461
RFC 2462
IPv6 Stateless Address Autoconfiguration.
December 1998.
(Status: DRAFT STANDARD)
RFC 2894
Router Renumbering for IPv6.
August 2000.
(Status: PROPOSED STANDARD)
Privacy Extensions for Stateless Address Autoconfiguration in IPv6.
January 2001.
(Status: PROPOSED STANDARD)
RFC 3041
www.ietf.org
29
IIT
Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification.
December 1998.
(Status: DRAFT STANDARD)
Neighbor Discovery for IP Version 6 (IPv6).
December 1998. (Obsoletes RFC1970)
(Status: DRAFT STANDARD)
© IITelecom,
2004
References
RFC 1886
RFC 2874
RFC 3152
Delegation of IP6.ARPA. August 2001.
(Updates RFC2874, RFC2772, RFC2766, RFC2553, RFC1886) (Also BCP0049)
(Status: BEST CURRENT PRACTICE)
RFC 2553
Basic Socket Interface Extensions for IPv6. March 1999.
(Obsoletes RFC2133) (Obsoleted by RFC3493) (Updated by RFC3152)
(Status: INFORMATIONAL)
Network Address Translation - Protocol Translation (NAT-PT). February 2000.
(Updated by RFC3152)
(Status: PROPOSED STANDARD)
RFC 2766
RFC 3226
RFC 3363
DNSSEC and IPv6 A6 aware server/resolver message size requirements.
December 2001.
(Updates RFC2535, RFC2874)
(Status: PROPOSED STANDARD)
Representing Internet Protocol version 6 (IPv6) Addresses in the Domain Name
System (DNS). August 2002.
(Updates RFC2673, RFC2874)
(Status: INFORMATIONAL)
www.ietf.org
30
IIT
DNS Extensions to support IP version 6. December 1995.
(Updated by RFC2874, RFC3152)
(Status: PROPOSED STANDARD)
DNS Extensions to Support IPv6 Address Aggregation and Renumbering.
July 2000. (Updated by RFC3152, RFC3226, RFC3363, RFC3364)
(Status: EXPERIMENTAL)
© IITelecom,
2004
References
RFC 3364
RFC 2772
Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6
(IPv6). August 2002.
(Updates RFC2673, RFC2874)
(Status: INFORMATIONAL)
6Bone Backbone Routing Guidelines. February 2000.
(Obsoletes RFC2546) (Updated by RFC3152)
(Status: INFORMATIONAL)
www.ietf.org
31
IIT
© IITelecom,
2004
References
RIPng for IPv6, G. Malkin, R. Minnear, IETF, 1997-01-01,
http://www.normos.org/ietf/rfc/rfc2080.txt
RFC2545
Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing, P.
Marques, F. Dupont, IETF, 1999-03-01, http://www.normos.org/ietf/rfc/rfc2545.txt
RFC2740
OSPF for IPv6, R. Coltun, D. Ferguson, J. Moy, IETF, 1999-12-01,
http://www.normos.org/ietf/rfc/rfc2740.txt
RFC2858
Multiprotocol Extensions for BGP-4, T. Bates, Y. Rekhter, R. Chandra, D. Katz,
IETF, 2000-06-01, http://www.normos.org/ietf/rfc/rfc2858.txt
draft-ietf-isisipv6-xx.txt
Routing IPv6 with IS-IS
draft-parentmultiprotocolrpsl-xx.txt
RPSL extensions for IPv6 and Multicast Routing Policies, F. Parent
www.ietf.org
32
IIT
RFC2080
© IITelecom,
2004
References
RFC 2529
Transmission of IPv6 over IPv4 Domains without Explicit Tunnels.
March 1999.
(Status: PROPOSED STANDARD)
RFC 2893
Transition Mechanisms for IPv6 Hosts and Routers.
August 2000.
(Status: PROPOSED STANDARD)
RFC 2766
Network Address Translation - Protocol Translation (NAT-PT).
February 2000.
(Status: PROPOSED STANDARD)
Delegation of IP6.ARPA.
August 2001.
(Status: BEST CURRENT PRACTICE)
RFC 3152
Dual Stack Hosts using the « Bump-In-the-Stack » Technique (BIS).
February 2000.
(Status: INFORMATIONAL)
RFC 3053
IPv6 Tunnel Broker
January 2001.
(Status: INFORMATIONAL)
www.ietf.org
33
IIT
RFC 2767
© IITelecom,
2004
References
RFC 3056
Connection of IPv6 Domains via IPv4 Clouds.
February 2001.
(Status: PROPOSED STANDARD)
RFC 3068
An Anycast Prefix for 6to4 Relay Routers.
June 2001.
(Status: PROPOSED STANDARD)
RFC 2765
Stateless IP/ICMP Translation Algorithm (SIIT).
February 2000.
(Status: PROPOSED STANDARD)
RFC 2767
Dual Stack Hosts using the « Bump-In-the-Stack » Technique (BIS).
February 2000.
(Status: INFORMATIONAL)
RFC 3338
Dual Stack Hosts Using « Bump-in-the-API » (BIA).
October 2002.
(Status: EXPERIMENTAL)
An IPv6-to-IPv4 Transport Relay Translator.
June 2001.
(Status: INFORMATIONAL)
RFC 3142
RFC 1928
34
IIT
© IITelecom,
2004
SOCKS Protocol Version 5.
March 1996.
(Status: PROPOSED STANDARD)
www.ietf.org
References
RFC3068
An Anycast Prefix for 6to4 Relay Routers, C. Huitema, IETF, 2001-06-01,
http://www.normos.org/ietf/rfc/rfc3068.txt
www.ietf.org
35
IIT
© IITelecom,
2004