European IP Testbed (Implementation Phase)

droppercauseNetworking and Communications

Oct 28, 2013 (3 years and 7 months ago)

368 views









Project P803
-
PF

European IP Testbed (Implementation Phase)

Deliverable 3

Test and evaluation of IPv6






Suggested readers:



Managers interested in IPv6 network deployment



Parties interested in IP projects







For full publication








August 19
99




1999 EU
RESCOM Participants in Project P803
-
PF

EURESCOM PARTICIPANTS in Project P803
-
PF are:




Deutsche Telekom AG



eircom



FINNET Group (Not participating in Task 3)



France Télécom (Not participating in Task 3)



MATÁV Hungarian Telecommunications Company Ltd.



Tele Danmark A/S



TELECOM ITALIA S.p.a.



Te
lekom Austria










This document contains material which is the copyright of certain EURESCOM
PARTICIPANTS, and may not be reproduced or copied without permission.

All PARTICIPANTS have agreed to full publication of this document.

The commercial use o
f any information contained in this document may require a
license from the proprietor of that information.

Neither the PARTICIPANTS nor EURESCOM warrant that the information contained
in the report is capable of use, or that use of the information is free

from risk, and
accept no liability for loss or damage suffered by any person using this information.

This document has been approved by EURESCOM Board of Governors for
distribution to all EURESCOM Shareholders.


Deliverable 3

Test and evaluation of IPv6



1999 EURESCOM Par
ticipants in Project P803
-
PF

page
i

(xi)

Preface

(Prepared by the EURESCOM Permanen
t Staff)

The Implementation Phase of the P803 Project initially had the ambition to construct
an international testbed, consisting of broadband connections between the different
participating shareholders. The structure and the use of the proposed testbed

were to
be clarified by the Project [34].

However, as the Project progressed:



A lot of time was needed for the development of test tools and test methodologies
in advance of actually performing the tests. This was largely done in the
individual sharehold
er labs



Many of the tests were interoperability
-
related rather than performance
-
related
because a European
-
wide high
-
performance broadband network was not available
to the Project



Access to cheap connectivity throughout Europe is not generally available no
w
that JAMES no longer exists. Instead, connectivity needs to be bought at
commercial prices

The result is that no European
-
wide testbed currently exists, but the Project has still
managed to produce relevant results. For the success of future work in th
is area,
broadband connectivity between the participants is absolutely necessary and industry
involvement would be desirable (as has been the case in some other EURESCOM
Projects).

Eight Shareholders took part in the Implementation Phase of P803. The Proj
ect
Leader was Paul Duggan, Eircom.

One of the Tasks in the P803 Project focused on IPv6. This Deliverable 3 is the
results of this Task.

Within the Deliverables, the reader may encounter the following EURESCOM
Shareholder codes:



AF


FINNET Group

(Finlan
d)



AU

Telekom Austria AG

(Austria)



DK

Tele Danmark A/S

(Denmark)



DT

Deutsche Telekom AG

(Germany)



FT


France Télécom

(France)



HT

MATÁV Hungarian Telecommunications Company Ltd.

(Hungary)



IT


TELECOM ITALIA S.p.a.

(Italy)



TI


Eircom

(Ireland)

Furth
er project information can be obtained at the following website:

www.eurescom.de/Public/Projects/P800
-
series/P803/P803.htm

Test and evaluation of IPv6

Deliverable 3

page
ii

(xi)



1999 EURESCOM Participants in Project P803
-
PF


Deliverable 3

Test and evaluation of IPv6



1999 EURESCOM Par
ticipants in Project P803
-
PF

page
iii

(xi)

Executive Summary

The rapid growth of the Internet has revealed many limitations in the systems and
protocols making up the Intern
et. The increasing number of users has resulted in
higher demands on services, bandwidth and address space. A new internetworking
protocol, IPv6 has been developed by the IETF to tackle some of these problems.

IPv6 offers many advantages over the existin
g IPv4 solution, particularly in the areas
of addressing scope and address hierarchy. It also offers a larger range of capabilities
than IPv4 for address autoconfiguration and discovery. The use of extension headers
for routing, encryption and multicasti
ng means that IPv6 could provide a more
efficient network layer solution than in the current Internet.

A pan
-
European testbed was constructed, using the 6bone, to evaluate IPv6
functionality and platform capabilities. Individual tests were carried out in
the area of
interoperability with existing IPv4 solutions and on the IPv6 protocol itself. Tests
were performed both locally and between partners in order to investigate the basic
addressing capabilities provided in IPv6 and also to evaluate support for r
outing,
mobility and security.

Because of the draft state of the standards and the missing implementations, not all
features have been tested, but the current state looks very promising. The most useful
features seem to be the improved addressing hierarch
y, routing efficiency and address
autoconfiguration.

To make IPv6 available to home users, it needs to be implemented on more common
platforms like Windows95/98 and Windows NT. When this is done, most applications
will only need minor changes to support I
Pv6. End users are still not aware of IPv6.
They want more bandwidth, better QoS, “Always On” functionality, etc. IPv6 has the
potential to be the protocol to satisfy customer needs.

However, the adoption of IPv6 is not a simple decision. Obviously, IS
Ps will only
implement IPv6 if there are customers or if IPv6 can be shown to increase the ISP’s
efficiency, i.e., they can see an actual or future financial benefit. Are users currently
asking for IPv6? No, because there are not enough applications. Wh
y are there no
applications? Because users are not asking for them and because there are no native
IPv6 networks. This argument can be continued in a circular manner. What is
required, in fact, is high quality network equipment (such as routers, etc), I
Pv6 stacks
and applications for the common operating systems, educated users and ISPs willing
to offer IPv6 services. Ideally, the IPv6 Forum should bring together all the interested
parties to enable IPv6 to happen. Ultimately, the decision whether or n
ot to adopt
IPv6 resides with the ISPs

Test and evaluation of IPv6

Deliverable 3

page
iv

(xi)



1999 EURESCOM Participants in Project P803
-
PF

List of Authors

Simon Elbaz,


Deutsche Telekom AG

Yann
-
Olivier Lorcy,


Deutsche Telekom AG

Michael Barry,


Eircom

Una Logan,


Eircom

Jan Anderson,


Tele Danmark A/S

Per Randrup Nielsen,


Tele Danmark A/S

Massim
o Magliocca,


TELECOM ITALIA S.p.a.

Gerhard Schmied,


Telekom Austria AG

Günther Körbler,


Telekom Austria AG

Manfred Pamsl,


Telekom Austria AG

Michael Blaschitz,


Telekom Austria AG

Deliverable 3

Test and evaluation of IPv6



1999 EURESCOM Par
ticipants in Project P803
-
PF

page
v

(xi)

Table of Contents

Preface

................................
................................
................................
...................

i

Executive Summary

................................
................................
..............................

iii

List of Authors
................................
................................
................................
......

iv

Table of Contents

................................
................................
................................
...

v

Abbreviations

................................
................................
................................
......
viii

Definit
ions
................................
................................
................................
.............

x

1

Introduction

................................
................................
................................
....

1

1.1

Structure of this Deliverable

................................
................................
...

2

2

Heterogeneous IPv4/IPv6 Networks

................................
................................
.

3

2.1

Migration Scenarios and Interworkin
g

................................
....................

3

2.1.1

Dual IP Layer

................................
................................
............

3

2.1.2

Configured Tunnelling of IPv6 over IPv4

................................
....

4

2.1.3

Automatic Tunnelling of IPv6 over IPv4

................................
.....

5

2.1.4

Network A
ddress Translation


Protocol Translation (NAT
-
PT)

................................
................................
...........................

5

2.2

DNS Extensions to Support IPv6

................................
............................

6

2.2.1

Format of IPv6 Resource Records.

................................
..............

7

2.2.2

Proposed Changes to Resource
Records

................................
......

7

2.2.3

Advantages of the IPv6 DNS

................................
......................

9

3

Protocol
-
Related IPv6 Issues
................................
................................
..........

11

3.1

IPv6 Addressing Scheme
................................
................................
......

11

3.1.1

Advantages of IPv6 Ad
dressing

................................
................

12

3.1.2

Reduction in Routing Table Entries
................................
...........

12

3.1.3

Advantages of Reduction in Routing Table Entries
.....................

13

3.1.4

Reduction in Routing Table Entries using the 6
Bone

..................

13

3.1.5

IPv6 Address Autoconfiguration

................................
...............

15

3.2

IPv6 Multicast/Anycast Scheme

................................
...........................

16

3.2.1

IPv6 Multicast

................................
................................
.........

16

3.2.2

IPv6 Anycast

................................
................................
...........

17

3.3

IPv6 Routing Scheme

................................
................................
..........

17

3.3.1

Features of IPv6 Routing

................................
..........................

17

3.3.2

Inter
-
Domain Routing Protocols

................................
...............

20

3.3.3

Intra
-
Domain Routing Protocols

................................
...............

21

3.4

IPv6 Mobility Scheme

................................
................................
.........

21

3.4.1

Mobility in IPv4

................................
................................
......

21

3.4.2

Advantages of IPv6 Mobility

................................
....................

24

3.5

IPv6 Traffic Flows
................................
................................
...............

26

3.5.1

Flow Label Header Field

................................
..........................

26

3.5.2

Flow Handling

................................
................................
.........

26

3.5.3

IPv6 Traffic Class Field
................................
............................

27

3.5.4

Advantages of IPv6 Traffic Flows

................................
.............

27

3.6

IPv6 Security and Authentication
................................
..........................

27

3.6.1

IPsec Protocols

................................
................................
........

28

3.6.2

Encryption Modes
................................
................................
....

29

3.6.3

Applications of IPv6 Security

................................
...................

31

Test and evaluation of IPv6

Deliverable 3

page
vi

(xi)



1999 EURESCOM Participants in Project P803
-
PF

4

Test Scenarios and Tools

................................
................................
...............

33

4.1

Testing Tools
................................
................................
.......................

33

5

Conclusions

................................
................................
................................
..

35

References

................................
................................
................................
...........

37

Appendix A: Test Cases for Dual IP Layer
................................
.............................

39

A.1

Results of Dual IP Layer Tests
................................
..............................

39

Appendix B: Test Cases for Tunnelling of IPv6 over IPv4
................................
.......

40

B.1

Router
-
Router Tunnelling
................................
................................
.....

40

B.2

Host
-
Router
Tunnelling
................................
................................
........

40

B.3

Host
-
Host Tunnelling

................................
................................
...........

41

B.4

Router
-
Host Tunnelling
................................
................................
........

41

B.5

Automatic Tunnelling of IPv6 over IPv4

................................
...............

42

B.6

Results of Tun
nelling of IPv6 over IPv4 Tests

................................
.......

42

Appendix C: Test Cases for NAT
-
PT
................................
................................
.....

43

C.1

Results of NAT
-
PT Tests

................................
................................
.....

44

Appendix D: Test Cases for IPv6 Address Autoconfiguration
................................
..

47

D.1

Address Autoconfiguration Test Case
................................
....................

47

D.1.1

Results of Address Autoconfiguration Tests
...............................

47

D.2

Single Link Communications Test Case

................................
................

47

D.2.1

Results of Single Link Communications Tests
............................

47

D.3

Duplicate Address Detection Test Case

................................
.................

47

D.3.1

Results of Duplicate Address Detection Tests

............................

48

D.4

Renumberi
ng Test Case
................................
................................
........

48

D.4.1

Results of Renumbering Tests

................................
...................

48

D.5

Test Case for Changing End
-
Point Addresses During Open
Connection

................................
................................
..........................

48

D.5.1

Results of

C
hanging End
-
Point Add
resses during Open
Connection Tests
................................
................................
......

49

Appendix E: Test Cases for Inter
-
Domain Routing Protocols

................................
..

51

E.1

Results of Inter
-
Domain Routing Protocol Tests

................................
....

52

Appendix F:
Test Cases for Intra
-
Domain Routing Protocols
................................
...

56

F.1

Results of Intra
-
Domain Routing Protocol Tests

................................
....

56

Appendix G: Test Cases for Mobile IPv6

................................
...............................

58

G.1

Binding Updates,
Binding Acknowledgements and Binding Cache

.........

58

G.2

Authentic Messages from the Mobile Host

................................
............

58

G.3

Tests using Mobile IPv6 for Linux

................................
........................

58

G.3.1

Local Mobility Test Case
................................
..........................

59

G.3.2

6bone Mobility Test Case 1

................................
......................

60

G.3.3

6bone Mobility Test Case 2

................................
......................

61

Appendix H: Tests Cases for IPv6 Security

................................
............................

63

H.1

Results for I
Pv6 Security Tests

................................
.............................

64

Appendix I: Other Test Cases

................................
................................
................

65

I.1

NAT
-
PT using Applications based over TCP

................................
.........

65

I.2

Changing End Point Addresses during Open Connection: Output
Generating by ‘ifconfig’ Commands over Host A
................................
...

66

I.3

BGP4+: Additional Information Available at each pTLA Site

.................

67

Deliverable 3

Test and evaluation of IPv6



1999 EURESCOM Par
ticipants in Project P803
-
PF

page
vii

(xi)

I.4

BGP4+: Output of ‘traceroute’ Command Executed in the End
-
to
-
End Inter
-
Domain
Test Case
................................
................................
.

68

I.5

IRIPv6: Routing Updated Messages Exchanged between Telebit
Router during Intra
-
Domain Test Case

................................
..................

69

I.6

IPv6 Multicast Test Case
................................
................................
......

70

I.7

IPv6 Anycast T
est Case

................................
................................
.......

71

I.8

IPv6 Routing Test Case
................................
................................
........

72

I.8.1

Loose Source Routing Header
................................
...................

72

I.9

IPv6 Traffic Flows Test Case

................................
...............................

73

I.9.1

Flow Label

................................
................................
..............

73



Test and evaluation of IPv6

Deliverable 3

page
viii

(xi)



1999 EURESCOM Participants in Project P803
-
PF

Abbreviations

AH

Authentication Header

ALG

Application Layer Gateway

ARP

Address Resolution Protocol

AS

Autonomous System

BGP

Border Gateway Protocol

CIDR

Classless Inter
-
Domain Routing

DES
-
CBC

Data Encryption Standar
d
-

Cipher Block Chaining

DNS

Domain Name Service

DVMRP

Distance Vector Multicast Routing Protocol

EGP

Exterior Gateway Protocol

EIGRP

Enhanced Interior Gateway Routing Protocol

ESP

Encapsulating Security Payload

FA

Foreign Agent

HA

Home Agent

IDRP

Inter Domain Routing protocol

IETF

Internet Engineering Task Force

IGP

Interior Gateway Protocol

IPv4/6

Internet Protocol Version 4/6

ICMP

Internet Control Message Parameter

ISAKMP

Internet Security Association and Key Management Protocol

ISP

Inter
net Service Provider

MD5

Message Digest 5

MH

Mobile Host

MLD

Multicast Listener Discovery

MOSPF

Multicast Open Shortest Path First

NAT
-
PT

Network Address Translation
-
Protocol Translation

NAPT
-
PT

Network Address Port Translation
-
Protocol Translation

NLA

Next Level Aggregate

OSPF

Open Shortest Path First

PCMCIA

Personal Computer Memory Card International Association

ping

Packet Internet or Inter
-
Network Groper

QoS

Quality of Service

RIP

Routing Information Protocol

SPI

Security Parameter Index

Deliverable 3

Test and evaluation of IPv6



1999 EURESCOM Par
ticipants in Project P803
-
PF

page
ix

(xi)

R
SA

Rivest
-
Shamir
-
Adleman

TCP/IP

Transmission Control Protocol/Internet Protocol

TLA

Top Level Aggregators

TLA ID

Top Level Aggregate IDentifier

TTL

Time To Live

UDP

User Datagram Protocol


Test and evaluation of IPv6

Deliverable 3

page
x

(xi)



1999 EURESCOM Participants in Project P803
-
PF

Definitions

A record:
The Resource Record type used by the D
NS to map a domain name to an
IPv4 address.

AAAA record:

A new Resource Record type used to map a domain name to a 128 bit
IPv6 address. Since a special host can possess several IPv6 addresses it must have one
AAAA record for each of his IPv6 addresses.

I
Pv6/IPv4 node:

A host or router that implements both IPv6 and IPv4.

IPv4
-
only node
: A host or router that implements only IPv4. An IPv4
-
only node does
not understand IPv6. The installed base of IPv4 hosts and routers existing before the
transition begins

are IPv4
-
only nodes.

IPv4 node:

Any host or router that implements IPv4. IPv6/IPv4 and IPv4
-
only nodes
are both IPv4 nodes.

IPv6
-
only node:

A host or router that implements only IPv6, and does not implement
IPv4.

IPv6 node:

Any host or router that implem
ents IPv6. IPv6/IPv4 and IPv6
-
only nodes
are both IPv6 nodes.

IPv4
-
only operation:

An IPv6/IPv4 node with its IPv4 stack enabled and its IPv6
stack disabled.

IPv6
-
only operation:

An IPv6/IPv4 node with its IPv6 stack enabled and its IPv4
stack disabled.

I
Pv6/IPv4 operation:

An IPv6/IPv4 node with both stacks enabled.

IPv4
-
compatible IPv6 address:

An IPv6 address bearing the high
-
order 96
-
bit prefix
0:0:0:0:0:0, and an IPv4 address in the low
-
order 32
-
bits. IPv4
-
compatible addresses
are used by IPv6/IPv4 n
odes, which perform automatic tunnelling.

IPv6
-
native address:

The remainder of the IPv6 address space. An IPv6 address that
bears a prefix other than 0:0:0:0:0:0.

IPv6
-
over
-
IPv4 tunnelling:

The technique of encapsulating IPv6 packets within IPv4
so that
they can be carried across IPv4 routing infrastructures.

Configured tunnelling:

IPv6
-
over
-
IPv4 tunnelling where the IPv4 tunnel end
-
point
address is determined by configuration information on the encapsulating node.

Automatic tunnelling:

IPv6
-
over
-
IPv4 tun
nelling where the IPv4 tunnel end
-
point
address is determined from the IPv4 address embedded in the IPv4
-
compatible
destination address of the IPv6 packet being tunnelled.

Session initiation packet:

This is the first packet of an IP session. Only the firs
t
packet of a TCP session can be identified in a deterministic way, with the presence of
SYN bit and absence of ACK bit in TCP header. There is no deterministic way to
recognise the start of a UDP or any non
-
TCP session.

Network Address Translation (NAT):

A method by which IP addresses are mapped
from one realm to another, providing transparent routing to hosts.

Protocol Translation (PT):

Translation of an IPv4 packet into a semantically
equivalent IPv6 packet and vice versa.

Deliverable 3

Test and evaluation of IPv6



1999 EURESCOM Par
ticipants in Project P803
-
PF

page
xi

(xi)

Application Layer Gateway (ALG
):

An application specific agent that allows an
IPv6 host to communicate with an IPv4 host and vice versa. Some applications carry
network addresses in the payload. NAT
-
PT is application independent (with the
notable exception of FTP) and does not snoop
the payload to fix IP addresses in the
payload. ALG is an alternative to NAT
-
PT for such applications.

Authentication:

The property of knowing that the data received is the same as the
data that was sent and that the claimed sender is in fact the actual s
ender.

Confidentiality:

The property of communicating such that the intended recipients
know what was being sent but unintended parties cannot determine what was sent.

Encryption:

A mechanism commonly used to provide confidentiality.

Integrity:

The propert
y of ensuring that data is transmitted from source to destination
without undetected alteration.

Non
-
repudiation:

The property of a receiver being able to prove that the sender of
some data did in fact send the data even though the sender might later desir
e to deny
ever having sent that data.

Data Encryption Standard
-

Cipher Block Chaining (DES
-
CBC):

Encryption
algorithm used to assure the data communication privacy in Ipv6

Security Association:

The set of security information relating to a given network
c
onnection or set of connections

Security Parameter Index (SPI):

An unstructured opaque index, which is used in
conjunction with the Destination Address to identify a particular Security Association.



Deliverable 3

Test and evaluation of IPv6



1999 EURESCOM Participants in Project P803
-
PF

page
1

(73)

1

Introduction

The current Internet serves what could
be called the computer market, which has been
the driver of the growth of the Internet. Its focus is to connect computers together in
the large business, government, and university education markets. This market has
been growing at an exponential rate, d
oubling approximately every 12 months. The
computers, which are used at the end
-
points of Internet communications, range from
PC’s to Supercomputers. Most are attached to Local Area Networks (LANs) and the
vast majority are not mobile.

The computer marke
t will not drive the next phase of growth. New growth markets
for the Internet will fall into several areas including:



Telecommunications



Nomadic personal computing



Networked Entertainment



Domestic Device Control

Each of these has the characteristic that
they are extremely large and are likely to be
deployed in parallel, leading to a scenario where every telecommunications device
(fixed and mobile), network element, television and domestic device has its own IP
address. They also bring with them a new set

of requirements, which were not as
evident in the early stages of Internet deployment. As well as the basic need for an
internet protocol which can support large scale routing and addressing, these markets
also require a protocol which imposes a low over
head and supports security, auto
configuration and mobility as a basic element.

IP version 6 (IPv6) is a new version of the Internet Protocol designed as the successor
to the current IP version 4 (IPv4). The changes from IPv4 to IPv6 fall primarily into
t
he following categories:



Expanded Addressing Capabilities
: IPv6 increases the IP address size from 32
bits to 128 bits, to support more levels of addressing hierarchy, a much greater
number of addressable nodes, and simpler auto
-
configuration of addresses.

The
scalability of multicast routing is improved by adding a “scope” field to multicast
addresses. A new type of address called an “anycast address” is defined and is
used to send a packet to any one of a group of nodes.



Header Format Simplification
: So
me IPv4 header fields have been dropped or
made optional, to reduce the common
-
case processing cost of packet handling
and to limit the bandwidth cost of the IPv6 header.



Improved Support for Extensions and Options
: Changes in the way IP header
options are

encoded allows for more efficient forwarding, less stringent limits on
the length of options, and greater flexibility for introducing new options in the
future.



Flow Labelling Capability
: A new capability is added to enable the labelling of
packets belong
ing to particular traffic “flows” for which the sender requests
special handling, such as non
-
default quality of service or “real
-
time” service.



Authentication and Privacy Capabilities
: Extensions to support authentication,
data integrity, and (optional) d
ata confidentiality are specified for IPv6

Test and evaluation of IPv6

Deliverable 3

page
2

(73)



1999 EURESCOM Participants in Project P803
-
PF

1.1

Structure of this Deliverable

This Deliverable presents the evaluation of IPv6 carried out in EURESCOM Project
P803. It includes test results and provides conclusions on relevant IPv6 issues, which
need to be

considered when deploying IPv6 networks.

Chapter 2 describes migration and interworking strategies for the adoption of IPv6 in
today’s Internet. It describes how dual IP stacks and tunnelling mechanisms can be
used to introduce IPv6 nodes into the IPv4 I
nternet. This chapter also examines the
changes that need to be made to the Internet naming hierarchy in order to facilitate
IPv6 addressing.

Chapter 3 introduces many of the key mechanisms of IPv6. The features and
advantages of each mechanism are descr
ibed. (The appendices contain detailed test
scenarios and results for many of the described mechanisms.)

Chapter 4 presents the testing environment and tools used in the evaluation of IPv6 in
the project.

Chapter 5 presents some conclusions on the scope,
capabilities and deployment of
IPv6 in the Internet.

Deliverable 3

Test and evaluation of IPv6



1999 EURESCOM Participants in Project P803
-
PF

page
3

(73)

2

Heterogeneous IPv4/IPv6 Networks

The rollout of IPv6 into the Internet will be a long and gradual process and so
machines, which use IPv6, must be able to coexist and interoperate with existing sites
and Ipv4 equipment. A number of strategies and techniques have been proposed in
the areas of architecture and addressing to ease the transition from an IPv4
-
based
Internet to an IPv6
-
based Internet

This chapter describes different migration and interworki
ng strategies for the
transition from IPv4 to IPv6 using dual stacks and tunnelling. It also describe some
extensions to the Domain Name Service (DNS) needed to support IPv6 addressing

2.1

Migration Scenarios and Interworking

The key to a successful IPv6
transition will be to maintain compatibility with the large
number of installed IPv4 hosts and routers. The IPng Transition (ngtrans) working
group of the Internet Engineering Task Force (IETF) has its overall goal in assisting in
and promoting the transi
tion to IPv6. It is defining a set of mechanisms that IPv6
hosts and routers may implement in order to be compatible with IPv4 hosts and routers
([2], [3]). The specified mechanisms include:



Dual IP Layer (also known as Dual Stack):

A technique for provi
ding complete
support for both Internet protocols, (IPv4 and IPv6) in hosts and routers (see
section 2.1.1).



Tunnelling of IPv6 over IPv4:

This mechanism is used when IPv6 packets must
be sent over an IPv4
-
only network (see section 2.1.2). There are two d
ifferent
types of tunnelling:



Configured Tunnelling,

which has to be used when the tunnel end
-
point is
a router and therefore, its IPv4 address cannot be derived from the IPv6
destination address.



Automatic Tunnelling,

which can be used when the tunnel end
-
point is
equal to the destination of an IPv6 packet. If a special IPv6 addressing
scheme, called IPv4
-
compatible addresses, is used, the IPv4 addresses of the
tunnel end
-
point can be derived from the IPv6 destination address (see
section 2.1.3).



Network
Address Translation


Protocol Translation:
A mechanism providing
an end
-
to
-
end solution to allow IPv6
-
only hosts to communicate with IPv4
-
only
hosts (see section 2.1.4).

Depending on the actual situation and prerequisites, several different migration
scen
arios using different IPv4/IPv6 transition techniques are possible.

2.1.1

Dual IP Layer

All hosts, that are required to communicate with both IPv4 devices and IPv6 devices
during the migration period, are equipped with dual IP layers (i.e., full IPv4 and
IPv6
implementations), and are therefore part of the IPv4 and IPv6 address space. These
Ipv4/Ipv6 nodes are capable of exchanging both IPv4 and IPv6 packets and so can
directly interoperate with IPv4
-
only and IPv6
-
only nodes.

Test and evaluation of IPv6

Deliverable 3

page
4

(73)



1999 EURESCOM Participants in Project P803
-
PF

If the according application
may be accessed via some sort of “proxy” software, these
nodes, equipped with such a software, may even work as a gateway between IPv4
-
only clients and IPv6
-
only servers and vice versa. Typical candidates for such a
configuration are for example WWW
-
appli
cations, FTP
-
applications, “socksified”
clients and all other applications, that are relying on connection
-
oriented data transport
without close relation to the underlying network connection. For IPv6 communication
across network segment boundaries, all r
outers involved in the data exchange must
support IPv6.

(See Appendix A for test cases.)

2.1.2

Configured Tunnelling of IPv6 over IPv4

While deploying IPv6, it will take a long time to build up the IPv6 routing
infrastructure. So there will be always some

IPv6 nodes that are separated by routers
not capable of routing native IPv6 traffic. Tunnelling of IPv6 over IPv4 provides a
technique to utilise the existing IPv4 infrastructure to carry IPv6 traffic. Ipv6/Ipv4
hosts and routers can tunnel IPv6 datagra
ms over regions only supporting IPv4 traffic
by encapsulating them into IPv4 packets. Depending on the tunnel source and
destination, tunnelling can occur in four different ways:



Router
-
to
-
Router:

IPv6/IPv4 routers interconnected by an IPv4 infrastructure

can tunnel IPv6 packets between themselves. In this case, the tunnel spans one
segment of the end
-
to
-
end path that the IPv6 packet takes.



Host
-
to
-
Router:

IPv6/IPv4 hosts can tunnel IPv6 packets to an intermediary
IPv6/IPv4 router that is reachable via an

IPv4 infrastructure. This type of tunnel
spans the first segment of the packet’s end
-
to
-
end path.



Host
-
to
-
Host:
IPv6/IPv4 hosts that are interconnected by an IPv4 infrastructure
can tunnel IPv6 packets between themselves. In this case, the tunnel spans
the
entire end
-
to
-
end path that the packet takes.



Router
-
to
-
Host:

IPv6/IPv4 routers can tunnel IPv6 packets to their final
destination IPv6/IPv4 host. This tunnel spans only the last segment of the end
-
to
-
end path.

In the first two cases mentioned above (
Router
-
to
-
Router and Host
-
to
-
Router), the
tunnel end
-
point is an intermediary router, which has to decapsulate the IPv6 packets
and forward it to its final destination. When tunnelling to a router, the end
-
point of the
tunnel is different from the destina
tion address of the IPv6 packet, so the IPv4 address
of the tunnel end
-
point can not be determined from the destination address in the IPv6
packet in any way, even when using IPv4
-
compatible addressing. In this case, so
-
called “configured tunnelling” must

be used; i.e., the tunnel’s source and destination
must be configured explicitly.

In the last two cases (Host
-
to
-
Host and Router
-
to
-
Host), the destination of the IPv6
packet and the tunnel end
-
point are the same node. So if using a special IPv6
addressin
g scheme, “IPv4 compatible IPv6 addresses”, the IPv4 address of the tunnel
end
-
point can be derived from the IPv6 destination address. There is no need for
explicitly defining the end
-
point of the tunnel; such tunnels can be built up
automatically on a “a
s
-
needed” basis. But it should be considered that most of the
advantages of IPv6 addressing (hierarchical addressing, much larger address space)
are lost, when using this technique.

(See Appendix B for test cases.)

Deliverable 3

Test and evaluation of IPv6



1999 EURESCOM Participants in Project P803
-
PF

page
5

(73)

2.1.3

Automatic Tunnelling of IPv6 over
IPv4

Automatic Tunnelling relies on IPv4
-
compatible IPv6 addresses. The decision on
when to tunnel is made by an IPv6/IPv4 host, which has a packet to send across an
IPv4
-
routed network area. Automatic Tunnelling can not be used to reach IPv6
-
only
addres
ses because they can not be addressed using IPv4. Packets from IPv6/IPv4
nodes to IPv4
-
mapped addresses are not tunnelled because they refer to IPv4
-
only
nodes. In this case the packages are sent using IPv4.

Automatic Tunnelling may be either host
-
to
-
hos
t, or it may be router
-
to
-
host. A
source host will send an IPv6 packet to an IPv6 router if possible, but that router may
not be able to do the same, and will have to perform automatic tunnelling to the
destination host itself. Because of the preference
for the use of IPv6 routers rather
than tunnelling, the tunnel will always be as “short” as possible.

However, the tunnel will always extend all of the way to the destination host. Because
IPv6 uses the same hop
-
by
-
hop routing paradigm, a host cannot dete
rmine if the
packet will eventually emerge into an IPv6
-
complete area before it reaches the
destination host. In order to use a tunnel, which does not extend all of the way to the
recipient, configured tunnelling must be used.

The mechanism used for autom
atic tunnelling is very simple. The encapsulating IPv4
datagram uses the low
-
order 32 bits of the IPv6 source and destination addresses to
create the equivalent IPv4 addresses and sets the protocol number to 41 (IPv6). The
receiving node’s network interf
ace layer identifies the incoming packets (or packets if
the IPv4 datagram was fragmented) as belonging to IPv4 and passes them upwards to
the IPv4 part of the dual IPv6/IPv4 internetwork layer. The IPv4 layer then receives
the datagram in the normal way,

re
-
assembling fragments if necessary, notes the
protocol number of 41, then removes the IPv4 header and passes the original IPv6
packet ‘sideways’ to the IPv6 part of the internetwork layer. The IPv6 code then
processes the original packet as normal. Si
nce the destination IPv6 address in the
packet is the IPv6 address of the node (an IPv4
-
compatible IPv6 address matching the
IPv4 address used in the encapsulating IPv4 datagram), the packet is at its final
destination. IPv6 then processes any extension h
eaders as normal and then passes the
packet’s remaining payload to the next protocol listed in the last IPv6 header.

(See Appendix B for test cases.)

2.1.4

Network Address Translation


Protocol Translation (NAT
-
PT)

Network Address Translation


Protocol T
ranslation (NAT
-
PT) is a transition method,
which allows communication between IPv4
-
only hosts and IPv6
-
only hosts without
requiring any changes on the end nodes. An NAT
-
PT
-
capable router is installed on
IPv4/IPv6 boundaries and uses a pool of IPv4 addres
ses for assignment to IPv6 hosts
on a dynamic basis as sessions are initiated across these boundaries. These assigned
addresses are in turn used to transparently replace the original addresses used by IPv6
end nodes and vice versa. This requires NAT
-
PT t
o track the sessions it supports and
mandates that inbound and outbound datagrams pertaining to a session traverse
through the same NAT
-
PT router.

When a host in the IPv6 network wants to communicate with a host in the IPv4
network, the DNS server of the I
Pv6 network returns an IPv6 address consisting of a
96
-
bit prefix, that is announced by the NAT
-
PT to the hosts on the IPv6 network, and
the embedded IPv4 address of the host in the IPv4 network. When the first packet of
the session traverses the IPv4/IPv
6 boundary, the NAT
-
PT retrieves one IPv4 address
Test and evaluation of IPv6

Deliverable 3

page
6

(73)



1999 EURESCOM Participants in Project P803
-
PF

from its pool of spare IPv4 addresses, associates it with this session, and performs the
network address and protocol translation (as described in [3]).

When a host in the IPv4 network wants to communicate
with a host in the IPv6
network, the lookup query is redirected by the DNS server of the IPv4 network to the
DNS server on the IPv6 network. A permanent association between the DNS server in
the IPv6 network and one address in the IPv4 address pool on the

NAT
-
PT does this.
When the lookup traverses the NAT
-
PT, the DNS Application Layer Gateway (ALG)
on the NAT
-
PT changes the “A” query to an “AAAA” query and redirects it to the
IPv6 DNS server. In the opposite direction, the DNS response is once again tra
pped
by the DNS ALG on the NAT
-
PT, changed to an “A” lookup, and an IPv4 address
from the pool replaces the IPv6 address in the lookup response.

Network Address Port Translation


Protocol Translation (NAPT
-
PT) is a slightly
different version of NAT
-
PT. I
nstead of using a pool of IPv4 addresses for
assignment to IPv6 hosts, only a single IPv4 address is used, but the TCP/UDP ports
of the IPv6 host are translated to TCP/UDP ports of the registered IPv4 address.

NAT
-
PT is application independent, as far as t
here are no network layer specific data
included in the payload data, as it is for instance in FTP connections. In such a case,
specialised ALG’s have to be used in conjunction with NAT
-
PT.

(See Appendix C for test cases.)

2.2

DNS Extensions to Support IP
v6

The Domain Name System (DNS) is a standard protocol to maintain mappings
between IP addresses and high
-
level machine names in a co
-
ordinated and centralised
way. The mapping of names to addresses require independent co
-
operative systems
called name ser
vers. A name server is a server program that holds a master or a copy
of a name
-
to
-
address mapping database (or otherwise points to a server that does) and
that answers requests from a client server called a name resolver.

With the introduction of 128
-
bit

addresses, IPv6 makes it even more difficult for
network users to be able to identify another network user by means of the IP address
of their network device. Therefore, the use of the DNS becomes even more of a
necessity.

A number of extensions to DNS ar
e specified to support the storage and retrieval of
IPv6 addresses. These were initially defined in [4], which is still a proposed standard
with elective status. However, there is also work in progress on usability
enhancements to this RFC, described in
two Internet Drafts, of the same name [5], [6].

The following DNS extensions are specified in [4] and [5]:



A new resource record type, AAAA which maps the domain name to the IPv6
address



A new domain, which is used to support address
-
to
-
domain name looku
ps



A change to the definition of existing queries, so that they will perform correct
processing on both A and AAAA record types.

[6] defines a resource record type “A6” instead of “AAAA”. This change is primarily
defined to ease network renumbering and m
ulti
-
homing of nodes and interfaces.
Since the latest version of BIND is dated with May 11
th

1998 and [6] is dated with
September 14
th

1998 there is currently no DNS version available which, is conformant
to [6].

Deliverable 3

Test and evaluation of IPv6



1999 EURESCOM Participants in Project P803
-
PF

page
7

(73)

2.2.1

Format of IPv6 Resource Records.

[5]

defines the format of the AAAA record as similar to an A resource record, but with
the 128
-
bit IPv6 address encoded in the data section, and a Type value of 28
(decimal). A special domain, IP6.INT, is defined for inverse (address
-
to
-
host name)
lookups (s
imilar to the in
-
addr.arpa domain used in IPv4). As in IPv4, the address
must be entered in reverse order, but hexadecimal digits are used rather than decimal
notation.

[6] defines a new “A6” resource record with type number 38 (decimal) instead of
“AAAA”

with type number 28 (decimal)as defined in [4] and [5]. The changes are
designed to facilitate network renumbering and multi
-
homing. Domains employing
the A6 record for IPv6 addresses can have automatically
-
generated AAAA records to
ease transition. It

is expected that after a reasonable period, [4] will become historic.

For example, the inverse domain name entry for the IPv6 address

2222:0:1:2:3:4:5678:9abc

is:

c.b.a.9.8.7.6.5.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.2.2.2.2.IP6.INT.
(*)

So, if the abo
ve address relates to the node ND1.test.com, according to [6], we might
expect to see the following entries in the Name Server zone data:

$ORIGIN test.com.

ND1

99999

IN

A6


2222:0:1:2:3:4:5678:9abc

cba98765400030002000100000002222.IP6.INT.
IN

PTR

ND1


Note:

All characters making up the reversed IPv6 address in this PTR entry should be
separated by a period (.) as shown above in (*). These have been omitted in this
example for clarity.

2.2.2

Proposed Changes to Resource Records

The IPv6 addressing sys
tem has been designed to allow for multiple addresses on a
single interface and to facilitate address renumbering (for example, when company
changes one of its service providers). Using the AAAA resource record format
specified in [4] would require a majo
r administrative effort in the event of a
renumbering change.

The work in progress in the current Internet Draft [5] proposes changes to the format
of the A6 resource record to simplify network renumbering. The proposed format of
the data section of the A
6 record is defined as in Figure 1:




Figure 1: Proposed Format of the A6 Record


An example of the proposed format is shown in Figure 2.

Test and evaluation of IPv6

Deliverable 3

page
8

(73)



1999 EURESCOM Participants in Project P803
-
PF


Figure 2: New A6 Resource Record Example

Site X is multi
-
homed to two providers, PROV1
and PROV2. PROV1 gets its transit
services from top
-
level provider TOP1. PROV2 gets its transit service from top
-
level
provider TOP2.



TOP1 has the Top Level Aggregate (TLA ID + format prefix) of 2111. TOP2 has
the TLA of 2122.



TOP1 has assigned the Next

Level Aggregate (NLA) of 00AB to PROV1. TOP2
has assigned the NLA of 00BC to PROV2



PROV1 has assigned the subscriber identifier 00A1 to site X. PROV2 has
assigned the subscriber identifier 00B1 to site X.

Node ND1, at site X, which has the interface t
oken of 10005A123456, is therefore
configured with the following two IP addresses:

2111:00AB:00A1::1000:5A12:3456

2122:00BC:00B1::1000:5A12:3456

Site X is represented by the domain name, “test.com”. Each provider has its own
domain, i.e., “top1.com”, “to
p2.com”, “prov1.com” and “prov2.com”. In each of
these domains an ‘IP6’ sub
-
domain is created that is used to hold prefixes. The node,
ND1 can now be represented by the following entries in the DNS:

ND1.TEST.COM

IN

A6

::1000:5A12:3456

80

IP6.TEST.COM


IP6.TEST.COM

IN

A6

0:0:00A1::

32

IP6.PROV1.COM

IP6.TEST.COM

IN

A6

0:0:00B1::

32

IP6.PROV2.COM

IP6.PROV1.COM

IN

A6

0:00AB::

16

IP6.TOP1.COM

IP6.PROV2.COM

IN

A6

0:00BC::

16

IP6.TOP2.COM

IP6.TOP1.COM

IN

A6

2111::

IP6.TOP2.COM

IN

A6

2222::

Deliverable 3

Test and evaluation of IPv6



1999 EURESCOM Participants in Project P803
-
PF

page
9

(73)

This
format simplifies the job of the DNS administrator considerably and makes
renumbering changes much easier to implement. Say, for example, site X decides to
stop using links from providers PROV1 and PROV2 and invests in a connection direct
from the top
-
lev
el service provider TOP1 (who allocates the Next Level Aggregate
00CD to site X). The only change necessary in the DNS would be for the two
IP6.TEST.COM entries to be replaced with a single entry.

2.2.3

Advantages of the IPv6 DNS

DNS for IPv6 is an extens
ion of DNS for IPv4 in that it offers support for IPv6’s
larger address space. The changes are designed to be compatible with existing
applications. The existing support for IPv4 addresses is retained. The latest Internet
draft, DNS Extensions to Suppor
t IP Version 6 [6], proposes a replacement for the
specification in RFC 1886 and a departure from current implementation practices.
The changes are designed to facilitate network renumbering and multi
-
homing.
Domains employing the A6 record for IPv6 addr
esses can have automatically
-
generated AAAA records which should significantly ease the transition to IPv6.

Test and evaluation of IPv6

Deliverable 3

page
10

(73)



1999 EURESCOM Participants in Project P803
-
PF


Deliverable 3

Test and evaluation of IPv6



1999 EURESCOM Participants in Project P803
-
PF

page
11

(73)

3

Protocol
-
Related IPv6 Issues

IPv6 is being developed by the IETF to address the shortcomings of IPv4, to enable
scaleable IP services and to me
et some of the future growth demands. The areas
identified in P803 for IPv6 testing are Address Autoconfiguration, Mobility, Routing,
Addressing, Traffic Flows and Multicast/Anycast Addressing. This chapter aims to
analyse these topics. Suitable test ca
ses for each topic have been provided in the
appendices.

3.1

IPv6 Addressing Scheme

IPv6 addresses are 128
-
bit identifiers for interfaces and sets of interfaces. There are
three types of addresses:



Unicast

addresses identify a single interface



Anycast

add
resses identify a set of interfaces such that a packet sent to an
anycast address will be delivered to only one member of the set



Multicast

addresses identify a group of interfaces, such that a packet sent to a
multicast address is delivered to all of the
interfaces in the group

IPv6 addresses of all types are assigned to interfaces, not nodes, as in the case of
IPV4. Since each interface belongs to a single node, any of that node’s interfaces’
addresses may be used as an identifier for the node. The pref
erred way of writing an
IPv6 address is a group of eight 16
-
bit pieces represented in hexadecimal. Some
examples are:

FEDC:2A5F:709C:216:AEBC:97:3154:3D12

1030:2A9C:0:0:0:500:200C:3A4

The addressing scheme for IPv6 is known as “Aggregatable Global Unicast

Address
Hierarchy”.

The IETF has adopted an aggregation
-
based hierarchy because it
combines the advantages of provider and geographic allocation approaches. Provider
allocation divides the hierarchy along lines of large service providers, regardless of
their location. Geographic allocation divides the hierarchy strictly on the basis of the
location of providers/subscribers. Aggregation
-
based allocation is based on the
today’s existence of a limited number of high
-
level exchange points, where large long
-
haul service providers and telecommunications networks interconnect. The use of
these exchange points to divide the IPv6 address hierarchy has a geographical
component because exchanges are distributed around the globe. The reason for the
provider orien
tation is because all large providers are represented at one or more
exchange points. This is used throughout the 6Bone, a network overlaid on top of
portions of the physical IPv4
-
based Internet to support routing of IPv6 packets, since
that function has
not yet been integrated into many production routers. This is a test
network, which allows the IPv6 protocol features to be fully tested, and
implementations checked for interoperability.

From the top of this hierarchy, blocks of addresses map to Top Leve
l Aggregators
(TLA). These TLAs are essentially the public transit points (exchanges) where long
-
haul providers and network operators establish peer connections. TLAs allocate
blocks of addresses to Next Level Aggregators (NLA), which represent large
pro
viders and global corporate networks. When an NLA is a provider, it further
allocates its addresses to its subscribers. Routing is efficient because NLAs that are
Test and evaluation of IPv6

Deliverable 3

page
12

(73)



1999 EURESCOM Participants in Project P803
-
PF

under the same TLA will have addresses with a common TLA prefix. Subscribers
with the same

provider have IP addresses with an NLA common prefix.

3.1.1

Advantages of IPv6 Addressing

The primary reason for developing IPv6 was to address the shortcomings of IPv4’s
32
-
bit addressing arrangement, which was wastefully allocated. IPv6’s 128
-
bit
addr
essing increases the available address space, enabling significantly more
addressable nodes. IPv6 provides a highly scalable address space allowing a flexible
and efficient global routing hierarchy. Aggregation
-
based allocation allows for
efficient route

aggregation where a single routing table entry can route traffic to many
individual addresses. Combining the expanded addressing scheme with routing based
on this hierarchical addressing scheme for IPv6 should allow sustained growth for the
Internet for
the foreseeable future. The fact that IPv6 addresses of all types are
assigned to interfaces and not nodes as in IPV4 enables more addressable nodes. IPv6
addressing improves over IPv4 in that it offers an advanced hierarchical address space,
allowing a
more efficient routing architecture.

3.1.2

Reduction in Routing Table Entries

This is essential in the design of a protocol expected to route packets on the future
Internet. If IPv4 routing is considered as a starting point, then it can be seen that
rout
ing tables of current Internet routers are increasing in size dramatically as shown
in Figure 3. In fact, if CIDR (Classless Inter
-
Domain Routing) is not used, every
single network must be announced by an entry in routing tables. The introduction of
CIDR

[5] allows a block of networks with contiguous addresses (for example, the
195.1.4.0, the 195.1.5.0, the 195.1.6.0 and the 195.1.7.0) to be announced as a unique
entry by specifying how many bits must be considered as significant. (In our example
195.1.4
.0/22, that is each network with the first 22 bits equal to 195.1.4.0.)

Figure 3 Number of Address Prefixes announced inside the Internet Backbone

Deliverable 3

Test and evaluation of IPv6



1999 EURESCOM Participants in Project P803
-
PF

page
13

(73)

The only real problem with CIDR is with managing changes in address or Internet
Servi
ce Provider (ISP). Because CIDR doles out address space in large chunks to
ISPs and not to the end networks directly, a change of ISP results in a change in all the
addresses on all computers on the network. This is comparable to changing a phone
number
when you move to a new city. Because phone numbers are tied to local
exchanges, it is not possible to have the same number in Milan as in Turin. (There are
methods that network administrators can use to circumvent this limitation but it
requires a little

more overhead and foresight on the administrator’s part.)

Even if all the ISPs in the world moved over to CIDR, the Internet would still run out
of address space. IPv6 will increase this address space by expanding bit size from 32
to 128 and use a hierar
chical routing scheme. This will allow for more rational
assignment of addresses. CIDR blocks could be aggregated on the basis of
geographical location or ISP assignment, which enables routers to determine where a
network is located by its address.

With
IPv6, when an organisation changes ISP it must still change addresses. However
the autoconfiguration mechanism supported by IPv6 means that it would not be
necessary to update the individual addresses of every computer in the network.

3.1.3

Advantages of
Reduction in Routing Table Entries

To improve routing efficiency inside the Internet, it is necessary

to reduce the
size of the addressing table inside its core level (currently exceeding 60,000 entries
[27]) to a more manageable level.

At the core of the
Internet, in the networks that compose the so
-
called “default
-
free
zone”, the routing table will need to have one entry per “exchange point” that is used
to join a set of secondary providers. According to the new IPv6 Aggregatable Global
Unicast Address F
ormat [28], the size of a Top Level Aggregation Identifier (TLA ID)
is 13 bits, allowing for 8192 TLA IDs. This size is sufficiently large because we do
not expect that there will be more than 8192 exchange points and long
-
haul or
“backbone” providers; th
is number is not too large so it should not pose any particular
problems.

3.1.4

Reduction in Routing Table Entries using the 6Bone

At the end of 1998, a world
-
wide IPv6 testing and pre
-
production deployment
network, called the 6Bone, had already reached o
ver 300 sites and networks in over 45
countries. The 6Bone is structured as a three
-
level hierarchical network with
backbone nodes, transit nodes and leaf nodes (see Figure 4). IPv6 routing inside the
backbone is based on the BGP4+ protocol. Transit nod
es connect to one or more
backbone nodes and provide transit service for leaf sites.

Test and evaluation of IPv6

Deliverable 3

page
14

(73)



1999 EURESCOM Participants in Project P803
-
PF


Figure 4: Logical Structure of the 6Bone Network

IPv6 addressing inside the 6Bone is based on the IPv6 Aggregatable Global Unicast
Address Format and it matches the hie
rarchical topology described above. Backbone
nodes play the role of experimental Top Level Aggregators (pTLAs, pseudo Top
Level Aggregators) and they are responsible for assigning IPv6 addresses to non
-
backbone sites in such a way as to create an addressi
ng hierarchy capable of
guaranteeing aggregation of routing information.

According to this model, every pTLA plays the role of experimental top level ISP and
has to assign chunks of its addressing space to directly connected transit and leaf sites
without
breaking aggregation inside the 6Bone backbone. This means that every
pTLA must not advertise prefixes longer than 24 to other pTLAs unless special
peering agreements are implemented. In this way, all the customers of a single pTLA
are routed through its

network; outside the network is sufficient to enter a line per
pTLA in the routing table solving the routing table explosion inside backbone routers.

All project participants have gained experience in reduction of table entries inside
6bone. In fact, by
using a tool called ASpath
-
tree, developed by CSELT, it has been
possible to investigate about all routing table entries present today inside the 6Bone
backbone giving emphasis on the impact that the unaggregatable prefixes have for
them.

Figure 5 shows th
e number of prefixes routes announced in the 6bone compared with
all pTLA prefixes, i.e., the ideal number of entries inside backbone routers; as
represented there is a strong correlation between them but there is a gap between the
real behaviour and the i
deal behaviour, probably due to some partner which break the
aggregation without particular agreements.


Deliverable 3

Test and evaluation of IPv6



1999 EURESCOM Participants in Project P803
-
PF

page
15

(73)


Figure 5: All Routes announced in 6bone

3.1.5

IPv6 Address Autoconfiguration

The Address Autoconfiguration process is defin
ed by the IETF. It includes creating a
link
-
local address and verifying its uniqueness on a link. It also determines what
information should be autoconfigured (addresses, other information, or both), and in
the case of addresses, whether they should be o
btained through the stateless
mechanism, the stateful mechanism, or both.

The Stateless mechanism allows a host to generate its own addresses using both
locally available information and information advertised by routers. Routers advertise
prefixes that i
dentify the subnets associated with a link, while hosts generate an
“interface identifier” that uniquely identifies an interface on a subnet. Combining the
two forms an address. In the absence of routers, a host can only generate link
-
local
addresses, wh
ich allows communication among nodes in the link. On the other hand,
the Stateful mechanism allows hosts to obtain interface addresses and/or configuration
information and parameters from a server.

Stateless and Stateful Autoconfiguration can be used simu
ltaneously. Stateless
Autoconfiguration can be used when it is not required to have the exact addresses that
hosts use, just as long as they are unique and properly routable. Stateful
Autoconfiguration can be used when a site needs exact address requirem
ents.

A link
-
local address is formed by pretending the well
-
known link
-
local prefix FE80::0
(of appropriate length) to the interface identifier. In contrast, site
-
local and global
addresses are formed by appending an interface identifier to a prefix of ap
propriate
length for the particular case.

3.1.5.1

Features of IPv6 Address Autoconfiguration



Auto assigning of Link Local addresses



Auto assigning of Global Addresses, based on router advertisement



Duplicate address detection



Automatic address renumbering

Test and evaluation of IPv6

Deliverable 3

page
16

(73)



1999 EURESCOM Participants in Project P803
-
PF

3.1.5.2

Advantages of IPv6 Address Autoconfiguration

The Address Autoconfiguration mechanism in IPv6 improves over IPv4 in that it
reduces the amount of set
-
up and configuration that goes into hosts. Small sites
attached to a single link will not need a

server or router to communicate (will use site
-
local or link
-
local addresses). More importantly, Address Autoconfiguration removes
state information from hosts so that if something like a change in default router or IP
Address is needed, it can be perfor
med without user intervention. Finally, Address
Autoconfiguration will allow efficient renumbering of a site’s machines.

(See Appendix D for test cases.)

3.2

IPv6 Multicast/Anycast Scheme

3.2.1

IPv6 Multicast

Network layer multicasting techniques are used

by internetworks to transmit a stream
of video, audio, news, financial, or other timely data to a group of functionally
-
related
but dispersed endstations. Multicast addresses identify a group of devices, such that a
packet sent to a multicast address is
delivered to all of the devices in the group. A
multicast network can automatically replicate its server’s packets and route them to
each subscriber in the multicast group using an efficient path. Routers use multicast
protocols such as DVMRP (Distance V
ector Multicast Routing Protocol) and MOSPF
(Multicast Open Shortest Path First) to dynamically converge a packet distribution
”tree” that connects all members of a group with the multicast server. Tools and an
experimental network, the Mbone exist for mu
lticast testing for both IPv4 and IPv6.
The Mbone overlays the existing IPv4
-
based Internet. It functions as an experimental
system, acting as a testbed for multicast application and protocol design and
refinement. A more limited amount of multicast app
lications exist for IPv6 compared
to IPv4, e.g., a multicast web browser [7] and multicast conferencing applications
RAT (audio conferencing) and SDR (announcing conferencing sessions).

3.2.1.1

IPv6 Multicast Scope Identifier

The scalability of multicast
routing is improved by adding a “scope” field to multicast
addresses. With IPv6 multicast, there are multiple scopes supported. The 4
-
bit
multicast scope value is used to limit the scope of the multicast group. The values
range from 0 to 9 with values r
epresenting Node
-
local scope, Link
-
local scope, Site
-
local scope, Organisation
-
local scope with values yet to be assigned. Multicast routers
must be able to control the propagation of scoped packets, based on these
administratively configured boundaries.

Multicast testing within groups can be
performed for all the various scope identifiers supported. The performance impact on
routing protocols is also important. Routers implementing scoped address support will
be forced to perform an additional check in

the main forwarding path to determine if
the source address is scoped. This will add overhead to the processing of every packet
flowing through the router and also there will be some storage overhead for the scope
identifiers. If scoped addresses are go
ing to be realised, this performance impact
should be acceptable.

3.2.1.2

IPv6 Multicast Listener Discovery

The purpose of Multicast Listener Discovery (MLD) is to enable each IPv6 router to
discover the presence of multicast listeners (that is, nodes wis
hing to receive multicast
Deliverable 3

Test and evaluation of IPv6



1999 EURESCOM Participants in Project P803
-
PF

page
17

(73)

packets) on its directly attached links, and to discover specifically which multicast
addresses are of interest to those neighbouring nodes. This information is then
provided to whichever multicast routing protocol is being used
by the router, in order
to ensure that multicast packets

are delivered to all links where there are interested
receivers.

3.2.1.3

Advantages of IPv6 Multicast

IPv6 extends IPv4’s multicasting capabilities by defining a very large multicast
address space a
nd a scope identifier that is used to limit the degree to which multicast
routing information is propagated throughout an enterprise. Multicasting is an
important feature of IPv6, and it actually replaces the IPv4 broadcast feature by
supporting both func
tions.

(See Appendix I for test cases.)

3.2.2

IPv6 Anycast

Anycast services are a new feature of IPv6, not found in IPv4. Two or more interfaces
on an arbitrary number of nodes are designated as an anycast group. A packet
addressed to the group’s anycast

address is delivered to only one of the interfaces in
the group, typically the “nearest”, based on the distance calculated by the routing
protocol in use. This is in contrast with multicast services, which deliver packets to all
members of the multicast
group. Nodes in an anycast group are specially configured
to recognise anycast addresses.

3.2.2.1

Advantages of IPv6 Anycast

Anycasting is a new service, and its applications have not been envisaged fully.
Initially, it is recommended that anycast addre
sses be limited to intermediate nodes.
This would allow, for example, an enterprise to use a single anycast address to
forward packets to a number of different routers on its ISPs backbone. If all of a
provider’s routers have the same anycast address, tr
affic from the enterprise will have
several redundant access points to the Internet. And if one of the backbone routers
goes down, the next nearest device will automatically receive the traffic.

(See Appendix I for test cases.)

3.3

IPv6 Routing Scheme

3.3
.1

Features of IPv6 Routing

Routing in IPv6 is more efficient than IPv4, which should achieve better performance
for the Internet. Several factors contribute to this efficient routing. The mechanisms
of routing in IPv6 are similar to IPv4 routing under C
IDR. Even though CIDR uses
address prefixes for route aggregation in IPv4, legacy IPv4 address assignments that
originated before CIDR cannot be summarised. Also, lack of uniformity in the current
hierarchical system, together with limitations on availab
le addresses, reduces
performance, makes routing more complex and requires more routing information to
be stored in backbone routers. The expanded address space and hierarchical nature of
the IPv6 addressing scheme allows backbone routers to efficiently d
etermine how
packets are to be routed through the backbone.

Test and evaluation of IPv6

Deliverable 3

page
18

(73)



1999 EURESCOM Participants in Project P803
-
PF

IPv6 provides a number of different address types: Unicast, Anycast and Multicast.
Messages are routed towards unicast address in the normal way, but as outlined above,
this is more efficient in
IPv6 than in IPv4. Anycast addresses identify a set of
interfaces such that a packet sent to an anycast address will be delivered to only one
member of the set, reducing traffic. Multicast addresses identify a group of interfaces,
such that a packet sent

to a multicast address is delivered to all of the interfaces in the
group. The new scope identifier with multicast for IPv6 limits the degree to which
multicast routing information is sent around the enterprise network.

Improved support for header extens
ions and options allows for more efficient
forwarding. With IPv4, most options are stored in the header and routers read and
process every option. With IPv6, routers read and process only relevant information,
which speeds the overall transport time.



The

IPv6 flow
-
label header, in which streams of flows can be identified in this
header, allows for more efficient routing than IPv4 because it eliminates the need
for routers to examine all of the header’s options in order to identify a flow.



The IPv6 source
routing extension header is an improvement of the source
routing function supported currently by IPv4. It is an extension header and
therefore does not have to be examined by every node along the path from a
source to a destination. This optional header
allows a source node to specify a
list of IP addresses that dictate what path a packet will cross.



The introduction of a new type of fragmentation header in IPv6 also enables
routing to be more efficient. The fragmentation header in IPv4 has the ability t
o
fragment packets at any point in the path, depending on the transmission
capabilities of the links involved. IPv6 uses end
-
to
-
end
fragmentation/reassembly, which is executed only by IPv6 source and destination
nodes. IPv6’s fragmentation method allows
a more streamlined packet and better
router performance for the majority of cases where fragmentation is not required.
Also, IPv6 has a larger minimum MTU (Maximum Transfer Unit) than IPv4.

With its greatly enlarged payload length field, IPv6 can carry “j
umbogram” messages,
potentially much larger than the IPv4 maximum of 64k octets. All of IPv4’s routing
algorithms (Open Shortest Path First (OSPF), Routing Information Protocol (RIP),
Inter Domain Routing Protocol (IDRP), etc.) with added extensions can u
sed to route
IPv6.

3.3.1.1

Source Routing Header

The Source Routing Header allows a source node to specify a list of IP addresses that
a packet will be routed through before it reaches its destination address. This is an
important feature of IPv6, enabli
ng provider selection and providing enhanced
security, by allowing the nodes a packet travels through to be specified.

For a sending node to have control over each packet’s route, the Source Routing
Header [14], must be of Type 0, which contains a 24
-
bit f
ield, indicating how
intermediate nodes may forward a packet to the next address in the routing header.
Each bit in the 24
-
bit field indicates whether the next corresponding destination
address must be a neighbour of the preceding address (1 = strict, mus
t be a neighbour;
0 = loose, need not be a neighbour).

When Type 0 routing headers are used, the initial IPv6 header contains the destination
addresses of the first router in the source route, not the final destination address. At
Deliverable 3

Test and evaluation of IPv6



1999 EURESCOM Participants in Project P803
-
PF

page
19

(73)

each hop, the intermedia
te node replaces this destination address with the address of
the next routing node and the “segments left” field is decremented.

When routing headers are used for “strict” forwarding, a packet visits only routers
listed in the routing header. In Figure 6
, every router (e.g., Router 1,2,3 and 4) from
Host A to Host B must be visited if specified in the Source Routing Header. This is a
useful feature when security and traffic control require that packets take a rigidly
defined path.


Figure 6: Source Routing


3.3.1.1.1

Fragmentation Header

The Fragmentation Header in IPv4 has the ability to fragment packets at any point in
the path, depending on the transmission capabilities of the links involved. In contrast,
IPv6 uses end
-
to
-
end
fragmentation/reassembly, which is executed only by IPv6
source and destination nodes. Packet fragmentation is not permitted in intermediate
IPv6 nodes. As with the Source Routing Header, the fact that the Fragmentation
Header is an extension header incr
eases router performance because the field does not
have to be examined at every hop between the source and destination nodes.

The IPv6 Fragmentation Header contains fields that identify a group of fragments as a
packet and assigns them sequence numbers.
Because IPv6 routers do not fragment
packets between end nodes, the responsibility for sending the correct size packet lies
with the source node, which needs to determine the MTU of the links in the end
-
to
-
end path.

3.3.1.1.2

Fragmentation for Larger Paylo
ads

If higher level applications are using larger payloads, the source node can make use of
the IPv6 Fragmentation Extension Header to divide large packets into smaller units for
network transmission. The IPv6 destination node will reassemble these fragm
ents in a
manner that is transparent to upper layer protocols and applications.

End nodes performing fragmentation can determine the smallest MTU of a path with
the MTU path discovery process. Typically, with this technique, the source node
sends out a pa
cket with an MTU as large as the local interface can handle. If this
MTU is too large for some link along the path, an appropriate ICMP (Internet Control
Message Parameter) message will be sent back to the source. This message will
Test and evaluation of IPv6

Deliverable 3

page
20

(73)



1999 EURESCOM Participants in Project P803
-
PF

contain a packet
-
too
-
b
ig indicator and the MTU of the affected link. The source can
then adjust the packet size downward (fragment) and retransmit another packet. This
process is repeated until a packet gets all the way to the destination node. The
discovered MTU is then use
d for fragmentation purposes. Although source
-
based
fragmentation is fully supported in IPv6, it is recommended that network applications
adjust packet size to accommodate the smallest MTU of the path. This will avoid the
overhead associated with fragmen
tation/reassembly on source and destination nodes
.

3.3.1.2

Advantages of IPv6 Routing

The uniformity of the IPv6 hierarchical addressing scheme, the number of address
types, the introduction of extension headers, (Flow Label Header, Source Routing
Header a
nd Fragmentation Header) all contribute to make the ability to forward
packets from a source to destination very efficient in IPv6.

(See Appendix I for test cases.)

3.3.2

Inter
-
Domain Routing Protocols

The building block of the IPv4 Internet is the Autonom
ous System (AS), a collection
of subnetworks managed by a single entity. Autonomous Systems use Exterior
Gateway Protocols (EGP) to exchange reachability information and to describe the
destinations for which they relay packets. One example of such a pro
tocol is the
Border Gateway Protocol 4 (BGP
-
4) [20]. This is a “path vector protocol” that allows
border routers, linking two adjacent AS, to announce paths. A path is described by a
set of attributes, notably the list of AS that it crosses and the list
of network prefixes
that it reaches. Monitoring all transit systems is a sure way to detect loops, because a
border router can easily refuse to consider a path that already passes through its own
AS.

Two proposals to extend BGP
-
4 to handle IPv6 are curren
tly available:



BGP4+ [21] is an EGP designed by Cisco; it is an extension to BGP
-
4 to enable it
to carry routing information for multiple Network Layer protocols (e.g., IPv6,
IPX, etc.). Various prototypical implementations are available (Cisco, Telebit,
Digital, Merit, etc.)



BGP5 [22] is an EGP designed by Bay Networks; it introduces newer extensions
to BGP
-
4 to improve the protocol and to make it suitable for bigger networks.
The only available implementation is the one realised by Bay Networks.

3.3.2.1

Advantages of Inter
-
domain Routing Protocols

Backbone routers in the transit networks of Internet providers must maintain complete
address tables for the entire Internet. As a result, providers must continuously upgrade
their configurations to cope with

the growth of the Internet. The new IPv6
Aggregatable Global Unicast Address Format reduces the routing table size inside
backbone routers as it assumes that some address hierarchy is introduced and that an
inter
-
domain routing technology that takes adva
ntage of this hierarchy is deployed.