Brett Neely
IP Next Generation
To boldly go where no
network has gone
before ...
Internet Protocol: The
Next Generation
Internet Protocol - The Next
Generation (IPng)
• Idea for the name taken from Star Trek
• Officially known as IPv6 (Internet Protocol version 6)
• Will be the successor to IPv4
• 4 + 1 = 6? Versions goofed up: Version 5 assigned to the ST
protocol. When IETF first started planning a successor
to IPv4, a document incorrectly listed the current
version as 6. So, they started working on version 7
before version 6.
• To escape the confusion of version numbers, the project
was given the name “IP - The Next Generation”
• Specifications for IPv6 were presented at the Toronto IETF
meeting, July 1994
What to do?
The Internet address space as specified by IPv4 is currently
filling up quickly.
Options:
• Limit the total size of the Internet
• Disrupt the network by changing the technology
Birth of IPv6
• IETF started working on the problem of limited address space
in late 1990
• By February 1992, four separate proposals for an update to
IPv4 were being worked on
• IETF formed IPng area in late 1993
• An IPng working group BOF was held at July, 1994 Toronto
IETF meeting
• The selected proposal for IPv6 is known as SIPP (Simple
Internet Protocol Plus)
• SIPP originally had 64 bit IP addresses, which was later
expanded to 128 bits
Why IPv6?
• Running out of address space - expand size of
Internet addresses
• Router tables grow at a rate 1.5 times the growth of
computer memory technology - change routing methods
to keep router tables manageable. IPv6 allows the
creation of network hierarchies which will improve
routing.
• Quality of Service: IPv6 has “quality of service” options.
Certain Internet traffic flows can be “labeled” for
special handling - useful for realtime audio and video.
(example: RealAudio) Realtime transmissions need
consistent throughput to provide regular service.
How IPv6?
• A simple, flexible transition from IPv4 - Internet hosts can
upgrade to IPv6 one at a time and not goof up the
network. It would be impossible to get everyone to
switch at the same time.
• It is possible that IPv4 and IPv6 will coexist on the Internet for
several years
• Hosts keep existing IP addresses when they switch from
IPv4 to IPv6
• Most parts of the existing Internet will not have to be
renumbered - Routers may be renumbered
IPv6 Security
• The current Internet has many security problems, lacks security
technology beneath the application layer
• IPv6 includes extensions which support authentication,
integrity, and confidentiality (Friday’s lecture)
• These extensions appear as additional headers inside the IP
packet
• Support for these extensions is REQUIRED in all
implementations of IPv6
Revise Standards
• Many of the IETF standards are affected by IPv6
• At least 27 of 51 full Internet standards must be revised for
IPv6
• This includes any standard which mentions “32-bit IP
addresses” even if the address is not used otherwise
The 6Bone
• The 6Bone = The IPv6 internet backbone
• Experimental network for IPv6, not connected to the
Internet
• Became operational around July 1996
• Around 40-50 hosts in 32 countries
• Used to “assist in evolution and deployment of IPv6”
• Web page: http://www.6bone.net
• The web page has network statistics, including daily
ping tests for all hosts (tests connection reliability)
• The 6Bone project is in the process of becoming an
IETF workgroup
IPng Web Sites
• http://www.ietf.org/html.charters/ipngwg-charter.html
• http://playground.sun.com/pub/ipng/html/ipng-main.html
IPng Mailing List
• To subscribe:
Send email to: majordomo@sunroof.eng.sun.com
In message body: subscribe ipng
• Mailing list archive:
ftp://playground.sun.com/pub/ipng/mail-archive/
Internet Draft
• Router Renumbering for IPv6
• Filename: draft-ietf-ipngwg-router-renum-03.txt
• March 12 1998
• Expires in September 1998
Internet Draft: Router
Renumbering
• Dynamic router configuration
• Combination of IPv6 Neighbor Discovery and Address
Autoconfiguration features
• All implementations MUST include the authentication
algorithm (HMAC-MD5) specified in RFC 2104. Other
authentication algorithms can optionally be supported.
• All Router Renumbering commands are authenticated
Internet Draft: Router
Renumbering
• Two types of RR messages: Commands and Replies
• Commands are sent TO a router
• Replies are sent FROM a router
Internet Draft: Router
Renumbering
• Processing RR commands has three steps:
• Header check
• Authentication check
• Command execution
RFC 1884
• IPv6 Addressing Architecture
• December 1995
RFC 1884: IPv6 Addressing
• Addresses are 128 bits (IPv4 addresses are 32 bits)
• Three types of addresses: Unicast, Anycast, Multicast
• Unicast: An address for a single interface (Example: your
computer is assigned one IP address when you dial in
with PPP)
• Multicast: An address for a set of interfaces. Packets sent to
Multicast addresses are delivered to all hosts
• Anycast: (New) An address for a set of interfaces. Packets sent
to Anycast addresses are delivered to one host (the
“nearest” one)
RFC 1884: IPv6 Addressing
• 128 bit addresses
• Written in 16-bit hexadecimal fields, separated by
colons. Example: 4F03:689:0:0:0:C301:5:8
• IPv6 addresses as URLs - Colons are used to specify the port
number. For a web page address, the current proposal is
to use: http://[4F03:689:0:0:0:C301:5:8]:81
(port number outside of square brackets)
• Square bracket method used in web browsers ONLY,
not in HTML “code”.
RFC 1884: IPv6 Address
Space
• How many addresses are possible with 128 bit addresses?
• 340,282,366,920,938,463,463,374,607,431,768,211,456
• 665,570,793,348,866,943,898,599 addresses per square meter
of the surface of the planet Earth
RFC 1884: The Unspecified
Address
• 0:0:0:0:0:0:0:0
• May never be assigned to any interface
• Useful: A host sends it in IP packets as the source address
before it learns what its true address really is
(Autoconfiguration)
• May not be used as a destination address
RFC 1884: The Loopback
Address
• 0:0:0:0:0:0:0:1
• May never be assigned
• May not be used as a source address
41st IETF Meeting
• Held in Los Angeles, CA, USA
• March 29 - April 3, 1998
IPng at the 41st IETF
• Meeting times/dates:
• Monday, March 30, 7:30-10:00pm
• Tuesday, March 31, 3:45-4:45pm
• Thursday, April 2, 9:00-11:30am
• Some of the topics to be discussed:
• Document Status
• Router Renumbering
• Mobile IPv6 Status
• Multicast Listener Discovery Protocol
• ICMP Name Lookups
The End