Download IP Version 6

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts

Distributed firewall wikipedia , lookup

Airborne Networking wikipedia , lookup

Dynamic Host Configuration Protocol wikipedia , lookup

CAN bus wikipedia , lookup

SIP extensions for the IP Multimedia Subsystem wikipedia , lookup

Asynchronous Transfer Mode wikipedia , lookup

RapidIO wikipedia , lookup

Point-to-Point Protocol over Ethernet wikipedia , lookup

TCP congestion control wikipedia , lookup

IEEE 1355 wikipedia , lookup

Computer network wikipedia , lookup

Net bias wikipedia , lookup

AppleTalk wikipedia , lookup

Multiprotocol Label Switching wikipedia , lookup

Internet protocol suite wikipedia , lookup

IEEE 802.1aq wikipedia , lookup

Deep packet inspection wikipedia , lookup

Wake-on-LAN wikipedia , lookup

I²C wikipedia , lookup

Recursive InterNetwork Architecture (RINA) wikipedia , lookup

Cracking of wireless networks wikipedia , lookup

Zero-configuration networking wikipedia , lookup

Transcript
IP Version 6
Sources:
IPng Overview presented at July 25, 1994 Internet Engineering Task Force
meeting.
Peterson and Davie, Computer Networks: A Systems Approach, 4e
Tanenbaum, Computer Networks, 4e
http://arstechnica.com/articles/paedia/IPv6.ars, "Everything you need to
know about IPv6" by Iljitsch van Beijnum (2007)
IPv4 Issues
• We’re running out of IP address space
• Internet growth rate is likely to continue to
increase
• IP options mechanism is inadequate
• IP doesn’t support “nomadic computing”
(i.e. Mobile IP is clunky)
• New routing functionality needed for
commercial Internet Provider environment
• Type of Service support is not adequate
IPv4 Address space
• We're running out of class B addresses
• Subnetting helps (better use of existing
class B blocks)
• CIDR helps (makes class C addresses
more useful)
• Do all IP addresses need to be unique?
Network Address Translation (NAT)
• Quick-and-dirty – disliked by purists
• Within a local network, "private" IP
addresses assigned which may be in use
elsewhere
• OK for internal routing
• Packets leaving the local network go
through address translation.
Private addresses
• 10.0.0.0 – 10.255.255.255/8 (16,777,216
hosts)
• 172.16.0.0 – 172.31.255.255/12
(1,048,576 hosts)
• 192.168.0.0 – 192.168.255.255/16 (65,536
hosts)
These addresses must never appear on the
internet – for "internal" use only
"NAT box" operation
• All packets to external destinations pass
through the NAT box
• NAT box translates an internal source
address (e.g. 10.0.0.1) to "real" IP address
assigned to the company (e.g.
192.60.42.12)
• Can be integrated with router or firewall
• Where are responses sent?
"NAT box" operation
• Most traffic is TCP/UDP. Headers contain
source and destination port numbers.
• NAT appropriates the TCP source port
field, replacing it with an index into a
65,536 entry lookup table
• Table entry contains original (private) IP
address and original source port.
• TCP and IP checksums have to be
recomputed.
"NAT box" operation
Upon receipt of packet addressed to the
NAT box:
• Source port field from TCP/UDP header is
extracted
• Corresponding entry from table is used to
repopulate destination address and port
• Checksums recalculated
NAT problems
• Violates the architectural model (uniqueness of
addresses) of IP
• Institutes a de-facto network layer connection-oriented
service
• NAT box is a single point of failure for all TCP
connections it handles
• Violates layering
• TCP and UDP aren't the only things out there. No other
transport layer protocols work over NAT
• Application layer use transmission of IP addresses fails
(e.g. FTP, IP Telephony apps have this property)
NAT – bottom line
• It's out there
• It works (mostly)
• Temporary fix with no better alternatives
Further reading:
• RFC 3022 – NAT protocol definition
• RFC 2993 – Architectural Implications of
NAT
IPv6 Features
• Expanded addressing capabilities
– 128 bit addresses
– More flexible address hierarchy
• Streamlined header format to decrease router
processing
• Improved option support
• Flow labeling mechanism for Type of Service support
• Interoperates with IPv4; transition can be gradual
• Security support
• Mobile computing support
Header Format
• Version: 6 for
all IPv6 pkts
• Traffic class: for
quality of
service
• Flow label: also
for quality of
service
• PayloadLen:
excludes
header. Units =
bytes
Header Format
• NextHeader:
like IP type
field –
protocol or
option of next
header
Option handling
• v4 options were an unordered collection of
(type, length, value) triples – difficult to
process
• v6 options must appear in a specific order.
• Most of the time, a quick peek at
NextHeader field lets routers determine
whether option processing is required
• Options can be of arbitrary length (v4 limit:
44 bytes)
Header Format
• HopLimit: same
as old TTL
• Addresses: 128
bits, with richer
hierarchical
structure
• Header is
always 40
bytes long
Address features
• Address space is 3.4 x 1038 nodes
• Practically speaking, 8 x 1017 to 2 x 1033
nodes (1564/sq. m of earth's surface at
low end, probably closer to 1500/sq. ft)
• Only 15% of address space is initially
allocated
• No address classes (CIDR model)
Writing IP addresses
• Format is x:x:x:x:x:x:x:x, where each x is a 4digit hex number.
• Contiguous ranges of 0s are compressed:
• 2BBF:0000:0000:0000:0000:0000:0000:AA12:001F can
be abbreviated 2BBF::AA12:001F
• Addresses containing imbedded v4 addresses:
::FFFF:144.161.92.14
– four bytes of 1's indicates node only understands v4
– Otherwise, all 0's except for v4 compatible address.
Addressing types
• Three types of addresses are provided
– Unicast addresses identify a single node.
– Cluster addresses identify a group of nodes
which share a common prefix, such as all
nodes connected to a particular service
provider. At most one of the addresses
belonging to the cluster will receive the
packet.
– Multicast addresses identify a group of nodes
which should all receive the packet.
Unicast Addressing
• Terminology
– subscriber – non-transit AS (stub or multihomed AS)
– provider – transit AS
• direct provider – directly connected to subscribers
• indirect provider – primarily connect other
providers (i.e. backbone nets)
• These classifications are not sharp
Unicast Addressing
• Goal is aggregation to reduce strain on
backbone routers
• Address prefix assigned to direct
providers, who redistribute (longer)
prefixes to subscribers
• Direct provider can advertise single prefix
for all subscribers.
• What happens when a site changes
providers?
Example: Provider-based Unicast
Prefix
010
Provider
ID
n bits
– Provider ID:
Subscriber
ID
m bits
Subnet
ID
p bits
Node
ID
125 - n - m - p bits
Address of an Internet Service
Provider (commercial or institutional).
– Subscriber ID: Identifies a portion of the address
space dedicated to a particular
subscriber.
– Subnet ID:
Identifies a topologically connected
group of nodes within the subscriber’s
network.
– Node ID:
An individual station
Autoconfiguration
• For local use only, there is a reserved prefix.
Tack on the MAC address, you're good to go.
• For globally unique address, use MAC address
as low order bytes, get prefix from router.
• Since most MAC addresses are 48 bit Ethernet
addresses, this works well (one reason why
designers expanded proposed 64 bit addresses
to 128)
Cluster Addresses
• A cluster is a group of stations which share a common
address prefix. Examples: a service provider, a service
subscriber, a subnet...
• Primarily used in routing sequences, this specifies that
the packet should go to the “nearest” router with the
specified cluster prefix.
• A sequence of cluster addresses in a routing option
identifies the “providers” over which the packet should
travel, while allowing the routing mechanism to decide
the best path to those clusters.
Quality of Service Support
The Flow Label in the IPng header is composed of two
fields:
• Traffic class: 4 bit traffic class identifier. Distinguishes
between “flow-controlled” traffic (e.g. TCP) and “nonflow-controlled” (real time) packets. Within each class,
there are 8 priority levels.
• Flow ID: A randomly generated identifier for a sequence
of packets from a particular source to a particular
destination which requires special handling by routers.
• The flow ID is chosen randomly and is used as a hash
key by routers to identify the information regarding the
special handling needed by the flow.
Option handling
• Size of options increased to total packet size.
• Except for special hop-by-hop options, options are only
processed at the destination, decreasing overhead.
• Currently defined extension headers
–
–
–
–
–
Hop-by-hop
Routing
Fragmentation
Authentication and encryption
End-to-end
Routing
• All existing routing algorithms can be used to route IPng packets.
• Several new routing capabilities have been introduced:
– Provider selection (based on policy, performance, cost, etc.)
– Host mobility (route to current location)
– Auto-readdressing (route to new address)
• Most of these capabilities are based on using the Routing option,
which allows sequences of addresses to be included in a packet.
• Typical use is to specify a sequence of cluster addresses to be
“visited” on the way to the destination. (Similar to loose source
routing in IP.)
• Hosts which receive a packet with an address sequence specified
are required to do “route reversal” in any response.
• Even if the whole Internet isn't v6 capable, it can still
work.
(From the Ars Technica article)
Fragmentation
• Fragmentation is a Bad ThingTM because loss of a single fragment
by IP requires retransmission of the entire original datagram.
• All links must support MTU of at least 576 bytes or do their own
fragmentation and reassembly.
• Fragmentation is provided only for backwards compatibility and is
handled as an option. Common header processing no longer
worries about Fragmentation/Reassembly.
• All implementations are required to provided Path-MTU discovery so
that packets can be sized accordingly (and thus avoid
fragmentation).
IPv6 Deployment
• Root DNS zone updated with v6 addresses for about half
of the root DNS servers (2/2008)
– Now v6 systems can communicate without using v4 to do DNS
name lookups
• US Gov: Office of Budget and Management required
IPv6 capability in gov't nets by 6/2008.
• v6 available as an optional install for Windows XP.
Preinstalled in Vista.
• Not supported internally at UR – unless we really need it.
• Adoption from the edges in – many apps are now v6
ready.
• Most of the new v6 functionality has been retrofitted into
v4. (This doesn't actually solve the underlying problem!)