• Keine Ergebnisse gefunden

IPv4 and IPv6functions

N/A
N/A
Protected

Academic year: 2022

Aktie "IPv4 and IPv6functions"

Copied!
50
0
0

Wird geladen.... (Jetzt Volltext ansehen)

Volltext

(1)

schmidt@informatik.

haw-hamburg.de

IPv6

Next Generation Internet Protocol

• The limits of IPv4 – IPv6 Highlights

• Addressing

• IPv6 Packet formats

• Routing, QoS

• Further aspects

• Migration scenarios

(2)

schmidt@informatik.

haw-hamburg.de

The Limits of IPv4

• Basic design about 30 years old - Packet format, ... outdated

- Hardware development of networks overran IP algorithms

• Address space exhausted

- ‚Regular‘ Internet growth runs out of addresses

- New kinds of Internet devices (mobile telephones, intelligent devices,...) need new quantities of addresses

- Caused by address bottle-neck: NAT-ALGs

• Support of new services tedious to implement

(3)

schmidt@informatik.

haw-hamburg.de

IP

IP

IP

IP

The Internet Idea

One Internet-Layer with global addresses

• Simple, application independent, transparent

• Stateless, application independent gateways

(4)

schmidt@informatik.

haw-hamburg.de

NAT-ALG

IP

NAT-ALG

NAT-ALG

The Internet Today

NAT Application-Layer Gateways

• No global addressing

• Statefull gateways for selected applications

(5)

schmidt@informatik.

haw-hamburg.de

IP Service Problems

• Address configuration: Static

• Backbone Routing: Little address structures

• Security: IP over IP tunnelling

• Multicasting: Routing too complex

• Anycasting: Application specific solutions

• QoS: No flow support

• Mobile: inefficient re-routing

(6)

schmidt@informatik.

haw-hamburg.de

IP Routing: CIDR

• Static subnet masks in IPv4 (classes) lead to two main problems:

Class B exhaustion & explosion of R-T

• Internet backbone routers need methods for aggregation, to limit routing tables:

– Classless Interdomain Routing (CIDR) – Variable Length Subnet Masks (VLSM)

• Approach:

– Allocation of coherent blocks of net addresses – Aggregation through ‚Supernetting‘ addresses

(7)

schmidt@informatik.

haw-hamburg.de

Route Aggregation via VLSM

11.0.0.0/8

11.2.0.0/16 11.3.0.0/16 .

. .

11.252.0.0/16 11.254.0.0/16

Router A

11.1.0.0/16

11.1.1.0/24 11.1.2.0/24 .

. .

11.1.252.0/24 11.1.254.0/24

Router B

11.253.32.0/19 11.253.64.0/19 .

. .

11.253.160.0/19 11.253.192.0/19

11.1.253.0/24

11.1.253.32/27 11.1.253.64/27 11.1.253.96/27 11.1.253.128/27 11.1.253.160/27 11.1.253.192/27

Router D

11.253.0.0/16 Router C

Internet

Bekanntgegebener Weg zu Subnetzen durch Aggregation

11.253.0.0/16 Router C

(8)

schmidt@informatik.

haw-hamburg.de

Why IPng?

Why don‘t continue with IPv4 + additional services?

• IPng tackles the Internet scaling problem

• IPng brings new Services and openness for further development

• IPng is a well matured architectural evolution of IP

• IPng brings a carefully designed transition concept

IPng is a large step, obsoleting many smaller, tedious transitions

to keep the Internet going!

(9)

schmidt@informatik.

haw-hamburg.de

IPv6: Important Markets

• Asia

• Mobile telephone business

• Home device manufacturer

• VoIP/VCoIP manufacturer

• Game industry

• Service provider

• Academic world

(10)

schmidt@informatik.

haw-hamburg.de

IPv6 Innovations

Addressing and routing

- Elimination of address bottle-neck: 128 Bit addresses - Address hierarchy can simplify backbone routing

- Several addresses per interface

• Simple administration

- Autoconfiguration of interfaces without DHCPv6 - Floating net masks, renumbering via prefix change

• Security: IPSec

– Security header extension for authentication, integrity and encryption

(11)

schmidt@informatik.

haw-hamburg.de

IPv6 Innovations(2)

• Protocol configuration

– Slim header for fast processing – Optional extension headers – Fixed format for all headers – No header checksum

– No fragmentation in routers

• Improved multicast, anycast, QoS and mobile services

• Transition and coexistence concept IPv4 ↔ IPv6

(12)

schmidt@informatik.

haw-hamburg.de

IPng History

• IETF WG IPng began to work in the early 90er

• Winter 1992: 7 proposals for development of IP

– CNAT, IP Encaps, Nimrod, Simple CLNP, PIP, SIP, TP/IX

• Autumn 1993: several mergers lead to

– ‚Simple Internet Protocol Plus‘ (SIPP) and ‚Common Architecture for the Internet‘

CATNIP

• July 1994: IPng Area Director recommend roadmap (RFC 1752) on basis of SIPP (Steve Deering)

• Dec. 1995: S. Deering, R. Hinden, „Internet Protocol,

Version 6 (IPv6) Specification“ (RFC 1883, now RFC 2460)

• Sub-TLAs available (RIPE-NCC, APNIC, ARIN) since 1999

(13)

schmidt@informatik.

haw-hamburg.de

IPv6 Standardisation

Key components in standard track:

Specification (RFC2460) Neighbour Discovery (RFC2461) ICMPv6 (RFC2463) IPv6 Addresses (RFC2373/4/5)

RIP (RFC2080) BGP (RFC2545)

IGMPv6 (RFC2710) OSPF (RFC2740)

Router Alert (RFC2711) Jumbograms (RFC2675) Auto configuration (RFC2462) ….

• IPv6 over:PPP (RFC2023) Ethernet (RFC2464) FDDI (RFC2467) Token Ring (RFC2470) NBMA(RFC2491) ATM (RFC2492)

Frame Relay (RFC2590) ARCnet (RFC2549)

• Diverse in preparation: Flow labeling, MIPv6, 3G, Routing adv.

(14)

schmidt@informatik.

haw-hamburg.de

IPv6 Implementations

• Most IP stack manufacturer have implementations (in different phases)

Supported Products: 3Com, Epilogue, Ericsson, IBM, Hitachi, KAME, Nortel, Sun, Cisco, Compaq, FreeBSD, HP, Juniper, Linux, Microsoft, Enterasys, Alcatel,

Novell, …

• Active cooperation at test events:

Inter Operability Lab at Univ. of New Hamshire

(15)

schmidt@informatik.

haw-hamburg.de

Addressing

• IPv6 addresses are 128-bit long and variably built

• Address architecture: RFC 3513 (April ´03, Hinden & Deering)

• Automatic address configuration

• Global address hierarchy from top level allocation to the interface-ID designated

• Aggregation-based allocation to simplify the global routing (possible)

• 3 Bit format prefix (FP) initially used for identification of address type

(16)

schmidt@informatik.

haw-hamburg.de

Notation of IPv6 Addresses

• Standard Form: 8 x 16 bit Hexadecimal

Example: 1080:0:FF:0:8:800:200C:417A

• Short form: sequences of nulls replaced by ::

Example: FF01:0:0:0:0:0:0:43 → FF01::43

• IPv4 compatible addresses:

Example: 0:0:0:0:0:0:13.1.68.3 → ::13.1.68.3

• CIDR notation for prefixes:

Example: 1080:645:FF::/48

(17)

schmidt@informatik.

haw-hamburg.de

Address Types

Type Binary Prefix

• Unicast (one-to-one)

– global all not specified elsewhere

– site-local 1111 1110 11 (FEC0::/10)

– link-local 1111 1110 10 (FE80::/10)

– compatible (IPv4, a.a.) 0000...0 (96 zero bits)

– Loop back 0000..1 ::1/128

• Multicast (one-to-many) 1111 1111 (FF00::/8)

• Anycast (one-to-nearest) of Unicast Prefixes

• No broadcast addresses (only multicast)!

(18)

schmidt@informatik.

haw-hamburg.de

Global Unicast Addresses (RFC 3513)

n bits m bits 128–m–n bits Subnet

ID Interface Identifier Global Routing

Prefix

• All fields have variable length and are not ‚self-explanatory ‘ (as of CIDR)

• All global unicast addresses, which do not begin with 000 (binary), carry a 64 bit interface ID, this means m + n = 64

• Mechanisms of automatic prefix exchange provided

(19)

schmidt@informatik.

haw-hamburg.de

Previous Unicast Format

Aggregatable Global Unicast Format - RFC2374

F P T L A I D R E S N L A I D S L A I D I n te rface I D

P u b lic S ite

F P 3 B it A d re ss T yp

T L A I D 13 T o p L e v e l A g g re g a to r R E S 8 R e se rv ie rt

N L A I D 2 4 N e x t L e v e l A g g re g a t or S L A I D 16 S ite L e ve l A g g re g a to r

I n te rf a c e I D 6 4 A b g e le ite t a us M A C -A d re ss e

(20)

schmidt@informatik.

haw-hamburg.de

Local Unicast Addresses

• Link-local addresses for use during auto-configuration and in nets without routers:

1111111010 0 Interface ID

• Site-local addresses independent of TLA/NLA:

1111111011 0 SLA Interface ID

(21)

schmidt@informatik.

haw-hamburg.de

Multicast Addresses

11111111 flags scope Group ID

8 4 4 112 bits

• Flag field: lower bit indicates permanent (=0) respectively transient (=1) group, rest is reserved (==0)

• Scope field: 1 - node local 2 - link-local 5 - site-local

8 - organisation local B - community-local

E - global (other values reserved)

(22)

schmidt@informatik.

haw-hamburg.de

Example: FHTW IPv6 Net

• 2001:: /16 - Pre-set prefix

2001:0600:: /23 - Regional registry Europa (RIPE)

2001:0638:: /29 - DFN prefix

2001:0638:0801:: /48 - FHTW net address

2001:0638:0801:0001:: /64 - First FHTW subnet

2001:0638:0801:0001:0000:0000:0000:0001 /128

- First IPv6 computer address at FHTW in 2001

- HAW Hamburg: Infrastructure Dept. ignores IPv6 Addressing of Sub-TLAs (Ripe) according to RFC 2450

(23)

Internet Control Message Protocol (ICMPv6)

schmidt@informatik.

haw-hamburg.de

• RFC 2463 (Conta, Deering)

• Defines two (expandable) message classes:

Informational Messages

• Echo Request (128)

• Echo Reply (129)

Error Messages

• Destination Unreachable (1)

• Packet Too Big (2)

• Time Exceeded (3)

• Parameter Problem (4)

(24)

schmidt@informatik.

haw-hamburg.de

IPv6 Neighbour Discovery

• RFC 2461

• Protocol over ICMPv6

– Combination of IPv4 Protocols (ARP, ICMP,…)

• Autonomous interaction between hosts and routers – Defines 5 ICMPv6 packet types:

• Router Solicitation / Router Advertisements

• Neighbour Solicitation / Neighbour Advertisements

• Redirect

(25)

schmidt@informatik.

haw-hamburg.de

• Defines communication mechanisms for nodes on the same link:

– Router discovery – Prefix discovery

– Parameter discovery, i.e.: link MTU, hop limit,…

– Address auto-configuration

– Address resolution (same function as ARP) – Next-hop determination

– Neighbour unreachable detection (useful for default routers) – Duplicate address detection

– Redirect

IPv6 Neighbour Discovery (2)

(26)

schmidt@informatik.

haw-hamburg.de

Stateless Auto-Configuration

1. Interface assigns a link-local address on activation (e.g. built from a hardware address).

2. Interface sends router solicitation, to omit waiting for router advertisements.

3. Router sends router advertisement (prefix, default gateway, …).

4. The interface creates its global address from prefix and link-local address.

5. For verification of uniqueness a ICMP neighbour solicitation will be sent (Duplicate Address Detection).

(27)

schmidt@informatik.

haw-hamburg.de

Auto-Reconfiguration

• New address-prefixes can be distributed and retreated:

– Coexistence periods between old and new prefixes planned

– Hosts learn prefix-lifecycle and priorities via router advertisements

– Old TCP-connections survive within coexistence periods, new TCP-connections survive prefixchange

• Prefix-distribution via router renumbering protocol

• DNS-Structure (AAAA) does not follow flexibility.

(28)

schmidt@informatik.

haw-hamburg.de

IPv6 Packet Format: Basic Header

16

0 4 12 24 31

V E R S IO N T R A FF IC C LA S S F LO W LA BE L

PA Y LO A D LE N G T H N E X T H E A D ER H O P LI M IT

S O U RC E A D D R E S S

D ES T IN A T IO N A D D R E S S

V E R S I O N 4 B i t I n t e r n e t P r o t o c o l V e r s i o n n u m b e r = 6 T R A F F I C C L A S S 8 B i t T y p e - o f - S e r v i c e s

F L O W L A B E L 2 0 B i t

P A Y L O A D L E N G H T 1 6 B i t O k t e t t a n z a h l d e s P a k e t e s o h n e I P v 6 - H e a d e r N E X T H E A D E R 8 B i t T y p e d e s " e n c a p s u l a t e d p r o t o c o l "

H O P L I M I T 8 B i t T T L - Z ä h l e r w i r d d e k r e m e n t i e r t j e R o u t e r S O U R C E A D D R E S S 1 2 8 B i t A d r e s s e d e s A u s g a n g s k n o t e n ( 1 2 8 B i t s )

D E S T I N A T I O N A D R E S S 1 2 8 B i t A d r e s s e d e s A u s g a n g s k n o t e n ( 1 2 8 B i t s ) Q o s - I n f o r m a t i o n e n f ü r R o u t e r v e r a r b e i t u n g

(29)

schmidt@informatik.

haw-hamburg.de

1 4 8 16 19 24 32

Version Servicetypen Paketlänge

Identifikation D F

M

F Fragmenabstand Lebenszeit Transport Kopfprüfsumme

Senderadresse Empfängeradresse

Füllzeichen Optionen

IP-Protocolkopf

Länge

IPv4 Header

(30)

schmidt@informatik.

haw-hamburg.de

Header Changes of IPv4

• Addressing grows from 32 to 128 Bit

• Fragmenting will be deleted from basis header

• IP Options will be deleted from basis header

• Header Checksum drop out

• Header length field drop out

• Flow Label newly included

• Time to Live → Hop Limit

• Protocol → Next Header

• Service types → Traffic Class

• Length field describes data without header

• Alignment increases from 32 to 64 Bit

(31)

schmidt@informatik.

haw-hamburg.de

IPv6 Packet Format: Option Headers

• Extended option mechanisms: Each header references a possible successive header or data, e.g.:

I P v 6 h e a d e r N H : r o u t i n g

I P v 6 h e a d e r N H : r o u t i n g

f r a g m e n t h e a d e r N H : T C P

T C P h e a d e r d a t a r o u t i n g h e a d e r

N H : f r a g m e n t

• Option headers have no length limit (IPv4:

40 Octets), Padding to 8 Octets

• Option headers will be processed only by hosts, not by routers.

Exeption: Hop-by-Hop Option Header

(32)

schmidt@informatik.

haw-hamburg.de

Basic Option Headers

Routing

Advanced routing information (source routing)

• Fragmentation

Fragmentation / defragmentation information

• Authentication

Security information: authentication and integrity

• Encapsulation

‚Tunnelling‘, i.g. for confidential data

• Hop-by-Hop Option

Dedicated options to be processed by every router

• Destination Option

Information for the destination host (header extension)

(33)

schmidt@informatik.

haw-hamburg.de

Order of Headers

The processing order of the headers will be arranged by the sender according to the following recommendation :

1. IPv6

2. Hop-by-Hop Option 3. Destination Option (1) 4. Routing / Encapsulation 5. Fragmentation

6. Authentication

7. Destination Option (2) 8. Upper Layer

(34)

schmidt@informatik.

haw-hamburg.de

Fragmentation

• IPv6 avoids the expensive fragmentation process on routers. The sender hast to fragment, if necessary.

• Sender should execute path-MTU discovery.

• Routers answer with ICMP „Packet too big“.

• IPv6 Fragmentation Header can be used to support upper layers without dynamically executing MTU-Discovery.

Next Header Fragment Offset 0 0 M

Original Packet Identifier Reserved

(35)

schmidt@informatik.

haw-hamburg.de

Packet Tunnelling of IPv6

• RFC 2473 (Conta, Deering)

• Mainly used for explicit routing path control

• Defines (statefull) ‚ends‘:

- Tunnel Entry-Point - Tunnel Exit-Point

• State variables contain MTU, Traffic Class, Flow Label

• Fragmentation may be necessary at tunnel entry point

New Header Ext. Hds. Original Packet (incl. Header)

(36)

schmidt@informatik.

haw-hamburg.de

MTU Handling

• The minimal Link-MTU for IPv6 is 1280 Bytes (versus 68 Bytes for IPv4).

• Path-MTU discovery necessary only for packets > 1280 Bytes.

• Minimal IP implementation can live without path-MTU discovery and without fragmentation (Packets ≤ 1280 Bytes).

• Upper Layer (TCP): MSS = MTU – 60.

• A Hop-by-Hop Option supports the execution of ‚Jumbograms‘ with sizes up to 2³² Octets Payload.

(37)

schmidt@informatik.

haw-hamburg.de

IPv6 Routing

• Using CIDR „longest prefix match“/ largest mask to go for.

• Hierarchical addressing is key issue for a scalable Routing

• Dynamical routing protocols from IPv4 updated:

Unicast: OSPF, RIP-II, BGP4+,...

Multicast: MOSPF, PIM, ...

• Can send packets through predefined regions by using routing headers and anycast addresses

e.g. for provider choices, performance optimisation, etc.

(38)

schmidt@informatik.

haw-hamburg.de

IPv6 & QoS

Priority: Traffic Class Feld (8 Bit) break down in two classes:

• Flow controlled traffic (0 - 7)

0 Not specified 4 Bulk (i.g. ftp, http) 1 ‚Feeder‘ (i.g. netnews) 5 (Reserved)

2 Unnoticed (i.g. email) 6 Interactive (i.g. telnet, X11) 3 (Reserved) 7 Internet control (i.g. rip)

• Traffic without flow control (Realtime, Constant Bitrate, ...)

Priority from 8 to 15 (ascending)

(39)

schmidt@informatik.

haw-hamburg.de

Flow Labels

24-bit Flow Labels can be uses by senders to mark associated packets.

• RFC 3697 – Use at present still experimental

• Goal: accelerated, uniform handling of packet streams through routers

• Flow label: Random per Flow

• Header information consistent per flow (router caching)

• Defines router states: 120 s lifecycle

(40)

schmidt@informatik.

haw-hamburg.de

More to IPv6

Domain Name System, closed disscussion

– A-Record → AAAA - Record versus

– A-Record → [A6 - Record (storage of address parts)]

• SNMP: in review, SNMP(v4) can manage IPv6 interfaces

• IPsec is mandatory part of IPv6

• Secure Neighbour Discovery (Send)

• IPv6 over 3GPP

• Mobile IPv6

(41)

schmidt@informatik.

haw-hamburg.de

IPv4 → IPv6 Porting

• Source and binary code compatibility for existent application: ‘all goes on’

• Address data structure:

New for IPv6

• Name-to-address translation:

New functions to support IPv6 and IPv4

• Address converting functions:

New functions to support IPv6 and IPv4

• DNS resolver:

Gives IPv6 or IPv4 address or both back

(42)

schmidt@informatik.

haw-hamburg.de

IPv4 → IPv6 Porting:

API Changes

Address conversion functions

inet_aton() inet_addr() inet_ntoa() AF_INET in_addr

sockaddr_in

inet_pton() inet_ntop()

getipnodebyname() getipnodebyaddr getnameinfo() * getaddrinfo() * AF_INET6 in6_addr

sockaddr_in6

IPv4 IPv6

Data structures

Name-to-address functions

IPv4 and IPv6 functions

gethostbyname() gethostbyaddr()

* POSIX protocol independant functions

(43)

schmidt@informatik.

haw-hamburg.de

IPv6 Ported Services (as of 2004)

For all services in open source area native IPv6-Support is offered, few only per patch – particularly through the KAME-Project

• SMTP: native: Sendmail, Exim - Patch: qmail, Postx

• HTTP: native: Apache 2.x (, PHP4) - Patch: Apache 1.3.x

• HTTP-Proxy: Patch: squid 1.x, Internet Junkbuster, wwwoe

• DNS (Transport): nativ: BIND9

• FTP: native: BSD-ftp - Patch: wu-ftpd, proftpd

• SSH: native: OpenSSH

• POP3: native: Courier-popd - Patch: qpopper

• IMAP: native: Courier

• NFS: *BSD, Solaris - missed: Linux, ...

(44)

schmidt@informatik.

haw-hamburg.de

IPv4 → IPv6 Migration

Many techniques for migration are designed and implemented according to the following approach:

– Dual-Stack techniques, which allow the coexistence of IPv4 and IPv6 for the same devices and nets

– Tunnel, which connect IPv6 regions over IPv4 regions

– Protocol translator, which let IPv6 devices with IPv4 devices speak

During migration the combined use of all this methods likely.

(45)

schmidt@informatik.

haw-hamburg.de DRIVER

IPv4 IPv6 IPv4 IPv6

TCP/UDP

Dual Stack

• On activation of IPv6 the IPv4 can continously being used (multi protocol approach)

• Devices can keep their addresses (IPv4 in IPv6)

• Application / libraries choose the IP version:

– On approach in dependency of DNS answer

– On answering in dependency from received packets

• The Dual stack operation can continue without limits, it allows the step by step porting of applications

(46)

schmidt@informatik.

haw-hamburg.de

Transition by Tunnels

• Embedding of IPv6 packets in IPv4 packets

• Diverse methods to build a tunnel:

Manuel

Tunnel Broker (web based application to build a tunnel) 6-over-4 (intradomain)

6-to-4 (interdomain, IPv4 address as IPv6 site prefix)

• View:

– IPv6 use IPv4 as a virtual link layer – IPv6 VPN over IPv4

(47)

schmidt@informatik.

haw-hamburg.de

IPv6-Tunnels

IPv6 Islands

(48)

schmidt@informatik.

haw-hamburg.de

Protocol Translation

• Simple extension of NAT to translate header formats and addresses

– IPv6 nodes behind translator speaks with full IPv6 functionality – Normal (limited) NAT functionality in contacting IPv4 hosts

• Scenario:

– New ‚domains‘ from Internet devices (telephones, cars, ...) – When the advantages of pure IPv6 configuration should used

(49)

schmidt@informatik.

haw-hamburg.de

Network Address and Protocol Translation (NAT-PT)

NAT-PT

IPv4-only

and Dual-stack-World IPv6-only

World

(50)

schmidt@informatik.

haw-hamburg.de

Bibliography

• Marc Blanchet: Migrating to IPv6, Wiley, 2006.

• Benedikt Stockebrand: IPv6 in Practice, Springer, 2007.

• Pete Loshin: IPv6 – Theory, Protocol and Practice. Elsevier, 2004.

• 6Net Consortium: An IPv6 Deployment Guide, Sept. 2005.

• www.ip6forum.com

• www.6net.org

• playground.sun.com/ipng

• www.cisco.com/ipv6

• www.6bone.net

• www.ietf.org/html.charters/ipngwg-charter.html

Referenzen

ÄHNLICHE DOKUMENTE

o Assigns an IPv6 network to each IPv4 address (taken as prefix). o Allows IPv6 islands to automatically interconnect,

- Tunnel, which connects IPv6 regions over IPv4 regions. - Protocol translator, which let IPv6 devices with IPv4 devices

• IPv6 Fragmentation Header can be used to support upper layers without dynamically executing MTU- Discovery. Next Header Fragment Offset 0

Jedes ans Internet angeschlossenes Endgerät benötigt eine eindeutige Adresse. Statt der MAC-Adresse werden IP-Adressen eingesetzt, da diese eine Strukturierung des

Jedes ans Internet angeschlossenes Endgerät benötigt eine eindeutige Adresse. Statt der MAC-Adresse werden IP-Adressen eingesetzt, da diese eine Strukturierung des

Der Grund hierfür ist, dass der Standby-Switch bei Verwendung von DHCP die Kontrolle über den Stack übernimmt und möglicherweise eine andere IP-Adresse als die IP-Adresse erhält,

Hinweis: Wenn der Befehl tunnel path-mtu-discovery in diesem Szenario nicht auf dem Weiterleitungsrouter konfiguriert und das DF-Bit in den Paketen festgelegt wurde, die über

ifconfig IPv4-, IPv6-, MAC-Adresse anzeigen ip addr show IPv4-, IPv6-, MAC-Adresse anzeigen ip route Routingtabelle