Internet DRAFT - draft-gilbert-ipngwg-enterprise-ipv6
draft-gilbert-ipngwg-enterprise-ipv6
INTERNET DRAFT Paul Gilbert, Cisco Systems
Expires October 2002
Implementing IPv6 Networks in the Enterprise
<draft-gilbert-ipngwg-enterprise-ipv6-00>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC2026].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
This document is not meant to be a primer on IPv6 [IPv6] or supply any
technical information about the protocol, it is meant to give network
engineers a place to start and to get ideas as to what to prepare for
when thinking about implementing IPv6, and also some changes that need
to be made when thinking about the addressing schema.
IPv6 brings some useful features that will help in making the
transition as painless as possible, things like auto-configuration and
renumbering. Particularly useful is the fact that both IPv4 and IPv6
can run concurrently on the network, on the same router interface and
on the same PC. This affords an evolutionary approach rather that a
revolutionary introduction of IPv6 technology.
For the purpose of this document the terms router and layer3 switch are
used interchangeably
1. Introduction.
2. Forwarding.
3. Forwarding Performance.
4. The WAN and the LAN.
5. Investment Protection
6. Headers.
7. Performance Testing.
8. Router Implementations.
9. Features and Functionalities.
9.1 Packet Filtering
9.2 IPSEC
9.3 Quality of service
9.4 Multicast
9.5 Urpf
10. Statistics
11. Basic Requirements.
12. Router Memory.
13. Management.
14. IPv6 Addressing.
14.1 Address Types
14.2 Address Schema
14.3 Address Configuration
14.4 Node Addressing
14.5 Router Addressing
14.6 IPv4compatible IPv6 address
14.7 Address Renumbering
14.8 Privacy Extensions for Stateless Address Autoconfiguration
in IPv6
15. ICMPv6
16. Path MTU Discovery
17. Neighbor Discovery
18. Multicast Listener Discovery
19. Tunneling
20. DNS
21. Operation Requirements.
22. The Lab.
23. References.
24. Authors name and address.
1. Introduction.
Implementing IPv6 typically involves the consideration of both software
and hardware, and in some cases both simultaneously. On some routers
you may need to upgrade both software and hardware to support the
protocol. As with every new application/protocol it is recommended
that you first implement in a lab of some kind. If that's not possible
then at least a non-critical part of the network should be selected.
This document attempts to outline some of the issues that enterprise
customers should aware of when looking to implement IPv6. It will
examine the differences that one will encounter and considers both
hardware and software.
2. Forwarding.
The forwarding of IPv6 packets from a router's point of view involves
nothing more than a longer lookup and possibly the processing of some
extension headers. The longer lookup is due to the fact that an IPv4
address is 32 bytes and an IPv6 address is 128 bytes.
There are 2 possible ways to forward IPv6 packets through a router, in
software, which is normally slow and processor intensive, or through
hardware, which is fast and is normally done with specialized ASICs or
Network Processors. There is also the notion of both, where the routes
and forwarding tables are calculated in software, these tables are then
downloaded locally to the linecards. It is here at these linecards
where the packets will either be forwarded by hardware or software.
There are 3 possible scenarios that a vendor could do to in order to
support IPv6 forwarding.
* Forward IPv6 in the software path on existing platforms. * Forward
IPv6 in the hardware path without any modifications to the hardware. *
Build new hardware to incorporate IPv6 forwarding
3. Forwarding Performance.
It is important to note that if the router today cannot forward IPv4
packets at wire rate is it most unlikely due to the longer lookups
required for IPv6 that they will be able to, without modification
forward IPv6 packets at wire rate.
If the interface can today, forward IPv4 packets at wire rate, and you
enable IPv6 forwarding on that same interface, which it can also
forward at wire rate, then the interface should still be wire rate for
the sum of both IPv4 and IPv6.
So this begs the question, is it important today to look only at
equipment that can forward IPv6 packets at wire rate.
Experience tells us that in reality most enterprise routers are more
than able to fill the pipes available to them, and if congestion is
experienced then you can try to deploy QOS and things like compression
or can you upgrade to a faster pipe.
If you did need to upgrade to a faster pipe then you would want the
existing router to be able to support those speeds, or if it didn't a
router with more performance and faster interfaces needs to be looked
at.
4. The WAN and the LAN.
In the enterprise there are really 2 types of routers, those that
service the LAN and those that service the WAN.
In the LAN the packet forwarding requirements are normally higher than
in the WAN, the routers used here normally are built with high speed
ASICs and can forward packets at a very high rate. Also you can always
add bandwidth cheaply, by means of another fiber run and some form of
channeling protocol.
In the WAN it is slightly different, most routers are almost always
faster than the pipe that they have to fill, and therefore features are
a little more important than how fast the router performs. There are
of course routers on the market that can achieve wire rate forwarding
at OC192 rates over multiple ports. These routers sit on the high end
of the scale and are required to fill each and every pipe. They are
normally found in the Service Provider arena, but may start to find
their way into Enterprises as the port speeds that are available
increase and the cost of bandwidth gets cheaper.
Currently adding bandwidth in the WAN is expensive, and therefore other
methods maybe looked at before spending money on increasing it, such as
compression and QOS.
Hopefully all of the fiber that providers are laying will eventually
drive the cost of bandwidth down allowing cheaper high-speed access.
5. Investment Protection.
Enterprises want to be able to upgrade the routers to have faster
backplanes, switching fabrics and linecards and they also want the
routers to have a lifetime of somewhere between 3-5 years. Enterprise
customers are pretty smart with regards to as to what to expect in
terms of investment protection. It would be wrong to expect a router
that terminated a whole bunch of ds-0s to now support an OC192
interface.
All this being said, it might be reasonable to assume -
* IPv4 traffic will still be the majority of the traffic for a long
period of time. * IPv6 traffic will initially be a small percentage of
the overall traffic volumes and grow as the number of applications and
users start deploying it. * As applications are written to leverage
the benefits of IPv6 the level of IPv6 traffic will increase quickly.
It would seem that if the current router could support IPv6 in the
"slow path" without requiring any hardware upgrades and if the router
did have on it's roadmap plans to support IPv6 with some hardware
modifications, such as a linecard or forwarding engine swap then this
would be acceptable to most enterprises.
It would seem reasonable to expect that if IPv6 takes hold over the
next year or two (2002-2004), then the routers deployed in the
enterprise today will be expected to forward both IPv4 and IPv6
traffic.
Of course the other scenario would be a new purchase outright, if this
were the case and the router in question did IPv4 at wire rate then it
would reasonable to expect the same performance for IPv6.
6. Headers.
The IPv4 header is 20 bytes and the IPv6 header is 40 bytes, in IPv6
all fields are 64 byte aligned, in IPv4 that is not the case because of
the options field. Because of the 64 byte alignment it maybe easier to
develop ASICs that can forward IPv6 as the routers will know exactly
where the bit boundaries are. Most vendors will use the same set of
ASICs to forward both IPv4 and IPv6 traffic so it will be interesting
to see how this pans out. The true test of exactly what the
differences will be should show up in the latency of actually
forwarding the packets.
7. Performance Testing.
One interesting note here is how vendors test the performance of their
routers, some use small packets because it suits them to do so, and
some use large packets for the very same reason. When testing IPv4 a
good weatherspoon is (IMIX) which stands for Internet Mix, e.g. a
sample of all the traffic on the Internet over a period of time. So
this testing involves packets of various sizes.
This is all well and good for IPv4 but as of yet there is no official
IMIX for IPv6 packets, but it would be expected to be IPv4 IMIX plus 20
bytes extra for the larger IPv6 header.
Another important aspect of hardware forwarding is what happens to
performance as features are turned on. It's fine purchasing a system
that forwards IPv6 at wire rate, but when you turn on a feature, such
as packet filtering that performance degenerates significantly. So
performance should be evaluated as both pure throughput as well as with
features and functionalities enabled.
8. Router Implementations.
With most router vendors you will either purchase the router with
software already installed on it that supports IPv6 or you will
install/upgrade you existing router to a newer version of software that
supports IPv6. Ideally you would want -
* The router to be able to run IPv4 with IPv6 concurrently. * Each
router interface should be able to run both IPv4 and IPv6
concurrently. * IPv4 routing should be independent of the IPv6 routing
and vice versa. * Configuration changes to one should not affect the
other.
9. Features and Functionalities.
When enterprises start to look at vendor support for IPv6 they will
need to look at the features and functionalities offered and make a
decision as to what is important to them and the network. It would
seem appropriate that the features and functionalities that are used
now by the company in it's current implementation of IPv4, will also be
required to be supported under IPv6.
In some cases this will be so, in others it will not. As happened with
IPv4 everything will not be delivered at once, this is due to a couple
of reasons -
* Time to market for router vendors, they need to get code out as a
check off item for RFP's and such. * Code for early adopters. * New
features and Functionalities will be added as requested by the end
users and as standards are developed. * As demand grows each vendor
will offer their own specialized versions of code that contain their
own particular value add. * As experience is gained, code is hardened
and customized.
9.1 Packet Filtering.
The focus here is security in the form of what a router can and cannot
do in terms of allowing or disallowing packets.
The Router needs to be programmed as to what packets are to be
processed and what packets should be dropped. To do this a router is
configured with a set of rules. These rules contain a list of
interesting addresses and an action if a packet string is matched.
These actions include drop, forward or perform the next lookup.
This set of rules could focus just on the source IP address of a host,
it could contain both a source and destination IP address, and also
possibly look deeper into the packet and care about things such as IP
socket numbers, port numbers next headers etc. You need to understand
what your requirements are and then ensure that the vendor can support
those requirements.
9.2 IPSEC.
IPSEC is a mandatory element of IPv6 and all implementations must offer
it. This enables end-to-end security. In IPv6 there are extension
headers, these replace the options field in IPv4. There are 2
extension headers that are used with IPSEC; they are the Authentication
Header (AH) and the Encapsulated Security Header (ESP).
The Authentication Header provides data authentication, data integrity
and anti-replay protection for the entire IPv6 packet.
The Encapsulated Security Header is used to provide confidentiality,
data origin authentication, connectionless integrity, an anti-replay
service (a form of partial sequence integrity), and limited traffic
flow confidentiality.
9.3 Quality of Service.
IPv6 brings no more functionality to QOS than IPv4. Both use an 8-
Bit field that could represent a DSCP value or a IP Precedence
value.
If the router supports QOS for IPv4, then the support for QOS for IPv6
should be no different.
Processes like queuing, policing, shaping, congestion management,
congestion control, signaling, and packet fragmentation, for low speed
links, should be transparent to the protocol. If they are supported
for IPv4 then they should be supported for IPv6.
Some interesting questions could be,
* Do packets for both IPv4 and IPv6 share queues? * Are the queues
configurable? * How do you differentiate between these queues? * Can
you configure different polices for each queue? * Is fragmentation
supported for low speed links?
It may be possible, if the vendor's implementation supports it to
define separate QOS policies for IPv4 and IPv6, and in some cases
even have different structures for each protocol, such as there own
set of queues.
9.4 Multicast
The defacto standard for multicast routing today is Protocol
Independent Multicast(PIM). PIM is covered in many RFC's that will not
be discussed in detail here.
At some point multicast may be a requirement in your network, if it
already isn't. There aren't a lot of IPv6 networks out there today, so
it goes without saying that there aren't a lot of IPv6 multicast
networks out there.
The forwarding of multicast packets is a lot more involved than the
forwarding of unicast or broadcast packets. Multicast packets need to
be replicated to a group of receivers, from a source via some kind of
distribution tree. Routers also need to keep a state of all receivers
and sources and to what interfaces it needs to forward interesting
packets. What would be important here is whether the replication is
done on the router using software or hardware and the amount of state a
router can hold.
Multicast packet replication tends to be highly processor intensive and
therefore must be handled by hardware to ensure that performance is not
negatively impacted.
If testing a vendor's implementation is a requirement then one should
test how the multicast would look in your network. Some vendor's
implementations performance will differ. Some may work well with a few
sources and lots of receivers; some may work well with lots of sources
and lots of receivers. The testing should not only look at packets per
second but also the amount of state that can be maintained in the
routers.
The enterprise as a whole, have been very slow to adopt multicast as a
technology that provides any real dollar benefit. Some corporations
are using it to provide training and distance learning.
IPv6 multicast includes additional fields: scope and flag. The flag
indicates if the multicast address is transient, (temporary) or if it
is a multicast address that has been permanently assigned by IANA. The
scope field indicates the scope of where the multicast traffic is
intended to go, eg link local, site local, global etc etc.
The basic requirements would seem to be the support of the PIM
protocol. PIM comes in many flavors - sparse mode, dense mode and
sparse/dense mode. There are also newer protocols that are being
developed, eg Source Specific multicast and Bi-Directional PIM.
What Multicast technology you deploy should depend on your particular
needs, do you have a few sources and lots of receivers, or 1 source and
lots of receivers, or is every node both a source and a receiver.
Enterprises should evaluate their multicast needs and then ensure that
the vendor supports the technology chosen.
9.5 Unicast Reverse Path Forwarding
Unicast Reverse Path Forwarding (Urpf) is key to stopping DDOS
attacks, the router examines all packets received at ingress on a
given interface to ensure that the source address and source
interface appear in the routing table and match the interface on
which the packet was received. There are at least 2 types of Urpf -
* strict - which checks that the IP address exists in the routing table
is reachable.
* loose or exist - Checks only to see if the address exists in the
routing table.
If Urpf was supported for IPv4 then it should be supported for
IPv6. It should be performed in hardware not software so as not too
negatively effect performance.
10. Statistics
Statistics gathering is important to a lot of enterprises. Data
captured can be used for charge back and billing purposes. Most router
vendors support some form of packet capture and sampling, this data is
then sent to a collection device for analysis.
Collecting statistics should not differ from Ipv4 to IPv6. IPv6 in
theory could need more space that IPv4 due to the size of the address,
eg 20 bytes versus 40 bytes, most of the analysis done on these packets
uses the header.
There are many tools out there today that collect and analyze
statistics gleaned from routers, most of these tools used are built
upon IPv4. Until these tools catch up and support IPv6 that they will
use IPv4 as a transport for IPv6 information.
11. Basic Requirements.
Some of the basic requirements that an IPv6 router should support could
be -
* Routing Protocols, both IGP's and EGP's * Multicast Routing *
Security in the form of ACL's * QOS * Management in the form of MIB's *
Management Tools such as Telnet, ping, traceroute etc etc * Syslog and
debugging tools * Network statistics gathering
A good tool to use for protocol compatibility is the configuration file
of the router. Look at each feature that you have turned on for IPv4
and check to see it is supported for IPv6. Obviously some of the
features may not be critical, in that case it should as least be on the
vendors roadmap
12. Router Memory
Bearing in mind that you are considering running at least one other
routing protocol on your routers it may be wise to ensure that you have
enough memory in the routers to do this.
At least two things need to be considered, do you have enough memory to
store the new software image that contains the new code and do you also
have enough memory to run the code.
As you begin to turn on features that enable IPv6 you will start to use
more memory, eg you may now have 2 routing tables that need to be
stored in memory, one for Ipv4 and one for IPv6.
Depending on the routers deployed you may need to upgrade memory on the
processors, and in a distributed system you may need to upgrade memory
on the linecards.
As noted in the hardware section, before you turn features on you
should know if those features are switched in hardware or software, and
will turning those features on effect IPv4 forwarding at all.
13. Management
The pro-active management of any network is key. Most enterprises have
multiple management tools in place. These tools could include things
that report on alerts, statistics, errors, utilization and so on.
Network Management tools could be supplied by the vendor or they could
be purchased from a third party.
The management of devices on the network, again should not differ.
Support for SNMP MIB's would be critical. Without support for this, it
would be extremely hard to gather any useful data from the routers.
Until network management software for native IPv6 is available it is
possible that IPv6 management and statistical information could be
collected from routers, but the transport for this collection would be
IPv4.
The drawback is that some vendors will not release this type of
functionality day one.
14. IPv6 Addressing
IPv6 addressing has some major differences relative to IPv4 and this
will have an effect on network engineering and management.
An IPv4 address is 32 bits; an IPv6 address is 128 bits. The text
representation of IPv6 address prefixes is similar to the way IPv4
addresses prefixes are written in CIDR [CIDR] notation. An IPv6
address prefix is represented by the notation:
IPv6-address/prefix-length
The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the
Hexadecimal values of the eight 16-bit pieces of the address.
Examples:
FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
1080:0:0:0:8:800:200C:417A
IPv6 addressing introduces the notion of an address scope. The scope
of the address refers to the boundaries as to where the packet can
travel. The packet could have a local scope only, which would mean a
router would not forward this packet, only nodes on this particular
link could see this packet. A site local scope means that the packet
can be routed within this network. This network typically will belong
to and administered by a single corporation. A global scope is an
address that is universally routable.
This memo is concerned mostly with the addressing of Routers and End
Stations. It is not intended to give a detailed explanation of IPv6
addressing, for a detailed discussion please refer to [ADDR] and
[RFC2373].
14.1 Address Types.
In IPv6 addresses are assigned to interfaces not nodes. All interfaces
are required to have at least 1 link-local address, and in general case
will have multiple addresses (unlike IPv4 where a single address per
interface is most common). These addresses will not only be for the
different scopes (see below) but there is also a high likelihood of
multiple addresses of global scope.
In IPv6 there are 3 kinds of addresses - Unicast, Multicast and
Anycast. Unicast needs no explanation; Multicast was dealt with in an
earlier paragraph, which leaves anycast. An anycast address is an
address shared by a number of nodes (normally routers). A shared
anycast address is injected at different points in the routing fabric
by nodes providing a common service (like DNS, default route, or tunnel
termination). This address is syntactically no different from an IPv6
unicast address and it's up to the IP routing protocol to find the best
path.
There is no notion of broadcast in IPv6, the functions that normally
used broadcast in IPv4 to communicate now use multicast in IPv6.
14.2 Address schema.
Within the IPv6 address are 3 scopes of addresses - Link Local, Site
Local and Global. Link Local means only nodes on this link, similar to
a local subnet; routers do not forward link local packets. Site Local
would mean within this site or corporation. Site Local addresses are
routable and this is what would be used within an enterprise network. A
Global address is one that is routable in the Internet, eg a registered
address.
A link local address begins with a format prefix of FE80::/10 A site
local address begins with a format prefix of FEC0::/10 A multicast
address begins with a format prefix of FF00::/8
14.3 Address Configuration.
All interfaces are required to have a link local address, which can be
derived from the interface identifier. A link local address allows a
node to communicate with other nodes on the same link. This part of
the address accounts for the low order 64 bits and nodes may have more
than 1 link local address. The interface identifier is in turn
appended to a prefix to form a 128-bit IPv6 address.
Today most Ethernet MAC addresses are 48 bits, 24 bits for the company
ID and 24 bits for the Extension ID, they have no meaning as far as IP
address is concerned. Recently the IEEE changed this and expanded the
Extension ID to 40 bits. This provides for addresses that are 64 bits
long, this is called the EUI-64 [EUI64]. To make existing MAC addresses
compatible 16 bits are inserted between the company id and the
extension id, These bits are represented in hex as "FFFE" or 1111 1111
1111 1110 in binary.
The site local address is used for communication within a site;
normally that site would be the enterprise.
The global address is required for communication outside the
enterprise.
The site local and global addresses can be assigned automatically,
dynamically or statically. Stateless autoconfiguration applies to site
local and global addresses that are constructed automatically by the
end node. Stateless addressing normally involves a router, which
supplies the host with a site local and global address. This process
can happen two ways -
Hosts can request a router to supply network address information to it,
or the router at certain intervals will multicast this information via
Router Advertisements. A router could supply -
* One or more prefixes that are used on the link, thus enabling
auto-configuration * The life time of the prefix * Flags that indicate
the kind of auto-configuration that can be done by hosts * The default
router
Stateful addressing applies to site local and global addresses that are
obtained via a database, like DHCP or manually.
14.4 Node Addressing.
The points below are taken directly from
<draft-ieft-ipngwg-addr-arch-v3-07>
A node on an IPv6 network is required to have the following addresses
enabled
* Link-Local address for each interface * Any additional unicast and
anycast addresses that have been configured for the node's interfaces
(manually or automatically) * The loopback address * The all-nodes
multicast addresses * The solicited-node multicast address for each of
its unicast and anycast addresses * Multicast address of all other
groups to which the node belongs
14.5 Router Addressing.
A router is required to recognize all addresses that a host is required
to recognize, plus the following addresses as identifying itself:
* The Subnet-Router anycast addresses for all interfaces for which it
is configured to act as a router * All other Anycast addresses with
which the router has been configured * The All-Routers multicast
addresses
14.6 IPv4-compatible IPv6 address.
There exists an IPv6 address that is made up of the IPv4 address. The
first 96 bits of this address are 0's. The low order 32 bits contain
the IPv4 address. The format of a IPv4 compatible IPv6 address is
0:0:0:0:0:0:A.B.C.D The entire 128 bits is used as the IPv6 address of
a node, and the low order 32 bits is used as the IPv4 address of the
node.
14.7 Address Renumbering.
IPv6 brings a nice feature that will help when changing service
providers. If nodes are configured to get their site local and global
addresses from the router eg - stateless autoconfiguration, then those
advertisements that the routers use's to give the addresses can be
configured to advertise a new prefix. The prefix from the new service
provider is added to the router announcements, nodes will then use the
new and the old prefix on the link. Any nodes requesting addresses
will get the new prefix, nodes that already had a prefix will continue
to use the old prefix.
You can also configure a lifetime on the prefixes, both old and new.
Once the lifetime of a prefix has expired, the routers no longer
advertise it. Nodes will update their prefix once the one that they are
using has expired.
14.8 Privacy Extensions for Stateless Address Autoconfiguration in
IPv6.
IPv6 addresses can be formed using the interface identifier and the
prefix; once this address is formed it is pretty static. Even if the
global and site local addresses change, the interface identifier could
still be the same.
If the interface identifier were static it would be easy for someone to
gather information from the source, even if the global and site local
addresses changed.
[PRIVACY] talks about some extension headers that can change the
global-scope address over a period of time, this includes the interface
identifier.
Changing the interface identifier would make it harder for
eavesdroppers and information collectors to identify sources when
different addresses are used in different transactions that actually
corresponded to the same node.
15. ICMPv6.
ICMPv6 [ICMPv6] is similar to ICMPv4. It provides for diagnostics
(ping), problem reporting (redirects) and MTU discovery [RFC-1981].
ICMP generates error messages such as destination unreachable and also
discovery messages like ICMP echo and reply. ICMP is also used in
neighbor discovery [IPv6-DIS] and the Multicast Listener Discovery
(MLD).
With IPv4 ICMP can be used to attack networks, therefore most
enterprises filter this protocol at a firewall. IPv6 could also be
used to spawn these attacks, but it does have the ability to use IPSEC
and create a security association between two parties. This service
should help decrease the possibility of a successful ICMP based
attack.
16. Path MTU Discovery.
The minimum link MTU in IPv4 is 68 octets; in IPv6 it is 1280 octets.
MTU path discovery is used to ensure that each node in the data path
supports the minimum MTU size. Fragmentation is handled by the end
nodes in IPv6 not the routers.
17. Neighbor Discovery [IPv6-DIS].
The Neighbor Discovery is part of the ICMPv6 protocol suite. It is
used to
* Determine the link-layer address of a neighbor on the same link. *
Find routers * Keep track of neighbors * Uses multicast not broadcast
18. Multicast Listener Discovery.
MLD is based upon and works similar to IGMPv2. It is used by IPv6
routers to discover multicast listeners eg - nodes on the network that
Want to receive multicast from a group on that link. MLD is based upon
IGMPv2 messages.
19. Tunneling.
There will be a transition period, whereas enterprises will need to
support both IPv4 and IPv6 in their networks, and possibly will not
have end-to-end IPv6 connectivity, but rather IPv6 at the edges with
IPv4 in the core or maybe islands of IPv6 that need connecting and
these may need to transverse an IPv4 network at some point. This maybe
because of local policy, or because the Service Provider does not yet
provide a native IPv6 service. These IPv6 networks or nodes could be
connected using IPv4 as a transport; the IPv6 packet will be
encapsulated within an IPv4 packet. At each end of these tunnels will
be an IPv6 address and an IPv4 address. There are two modes of
tunnels, automatic and manual.
The type of tunnel used, automatic or manual could depend on the use of
the tunnel. Tunnels that are likely to be static and not change are a
good fit for manual configuration, whereas tunnels that are changing or
are temporary would be a good fit for automatic. When using automatic
tunnels the tunnel end points are automatically determined by using
IPv4 compatible IPv6 addresses.
Tunnels could exist between -
* Router-to-Router
* Host-to-Router
* Host-to-Host
* Router-to-Host
Tunneling Technologies -
* IPv6 Manually configured tunnel.
* IPv6 over IPv4 GRE tunnel.
* Tunnel Broker [RFC3053].
* Automatic IPv4-compatible tunnel [NGTRANS] and [ADDR].
* Automatic 6to4 tunnel [RFC3056].
* ISATAP tunnels [ISATAP]
* 6over4 tunnels [RFC2529].
This memo does not get into details regarding any of the possible
tunneling techniques see [NGTRANS] and [RFC2893].
20. DNS.
IPv6 DNS performs the same purpose as IPv4 DNS: It maps IP addresses to
names and vica versa.
IPv6 bring a new DNS record type known as AAAA (pronounced quad A),
IPv4 record types are known as A, IPv6 addresses are 4 times the size
of IPv4 hence "AAAA". The records look like -
www.abc.test AAAA 2001:450:0:0:0:ce20::1 www.abc.test IN AAAA
2001:450:0:0:0:ce20::1
Nodes and Routers that support both IPv4 and IPv6 must be capable of
resolving both A and AAAA record types.
There is also another method of resolving IPv6 addresses to names,
which uses record types called A6. This method defines changes to the
Domain Name System to support renumberable and aggregatable IPv6
addressing. The idea here is to make it easier for Enterprises and
Service Providers to change DNS entries quickly and efficiently. The
idea is that the prefix of the IPv6 network address will be maintained
by the Service Providers DNS server. Therefore any change on the
enterprise's part requires only a change to the DNS prefix entry.
21. Operational Requirements.
If IPv6 is going to put into a production network then people will need
to know -
* The changes in the addressing schema * The automation of the
addressing * The scope of the addressing * The new protocols that
enable automatic addressing, address
resolution, error reporting and mtu discovery
* How to configure it * How to manage it * How to Troubleshoot it
The above points indicate that this could be achieved either by a CLI
or by a management interface. It would depend on the individuals and
possibly company policy as to which was used. Also if an existing
router was being used then the learning curve would probably just
entail some new commands, if however a new router was purchased it
could mean the need to learn a whole new command set.
The commands most commonly used on a router are -
* Commands that control how the router functions, they either add
or take away functionality.
* Commands that glean information from the router, eg - shows the
contents of the routing tables.
* Commands that help investigate a problem or abnormality, eg -
pings, debugging or traceroute.
All routers come with a set of manuals, these manuals are either on
soft copy, a CD or hard copy. These manuals should be updated and
carry the command set used for IPv6. Following a logical path the
command set available for IPv6 should really be no different than the
command set for IPv4, all except for the features that are new in
IPv6.
It would seem that to enable basic IPv6 functionality on a router you
would turn on IPv6 routing globally on the router and then on each
interface that you required IPv6 routing you would need an address
configured. The next step would be to enable a routing protocol and
provide this protocol some address information.
This is very similar as to what is required for basic IPv4 routing
today, the extra work needed for IPv6 could be just a few extra
characters.
22. Lab Requirements.
One of the main goals of the lab will be not only to test hardware and
software but it could also be used to train operations staff. These
people are the ones responsible for the day-to-day running of the
network, and because you are introducing a new protocol, then training
these people should be a top priority.
A lab should be built to resemble the live network, this way if the
test scripts are well written and the results recorded accurately and
analyzed accordingly, then when putting IPv6 into a live network it
should not produce any big surprises.
Note that along with testing the newer IPv6 applications and networking
you should alongside this also have the regular IPv4 applications
running, that way you can ensure that one does not effect the other.
What could a lab contain -
* The exact hardware used in the live network * The exact interfaces
used in the live network * The software that is expected to be used on
the production routers * Production applications * Testing Equipment *
A repository for configurations and screen dumps
Every enterprise's test plan will be very different and will depend on
there own requirements. Some will be concerned about functionalities,
some performance and others interoperability. It would be unwise to
try to cover all points that would be deemed important here.
The points listed below focus on basic operation of the protocol and
not performance or interoperability, as those would be very specialized
to the particular environment. The points below are also very
generic.
A test plan could include -
* Once the network is setup and stable, copy all of the configurations
of the routers to a tftp server. These will be useful to use as a
baseline.
* Throughout the testing use the CLI to collect information that will
be useful to operations staff, the idea here is to familiarize people
as to what the routing tables, ARP tables, traceroutes, debugs and so
on look like. It would also be useful to save these screen dumps to a
hard drive.
* Connectivity Testing - once the lab is setup, a routing protocol
chosen and the appropriate configuration applied, the next logical step
would be to test connectivity, eg is the routing protocol working as
expected. Not only should the routes be formed correctly but also
updates should take place at regular intervals.
* Convergence - When the network is stable and predictable fail a link
and watch the routing protocols converge. Did it work as expected?
Again capture screen dumps before and after.
* Test management tools such as pings, traceroutes and debugs.
* Multicast testing if appropriate.
* Testing of the appropriate applications.
The results and usefulness of those results will only be as good as the
test plan and data recorded.
If in the lab something does not work as expected or advertised then
further analyses is required. All too often important events are
overlooked or put down to a glitch. You can bet that if this glitch
did effect the operation of the network in the lab, that when you go
live, it will at some point come back to bite you.
23. REFERENCES
Normative References
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version
6, (IPv6) Specification", RFC 2460, December 1998.
[CIDR] Fuller, V., Li, T., Yu, J., Varadhan, K., "Classless
Inter-
Domain Routing (CIDR): An Address Assignment and
Aggregation Strategy", RFC1519, September 1993.
[RFC-1981] McCann, J., Mogul, J. and S. Deering, "Path MTU
Discovery for IP version 6", RFC 1981, August 1996.
[RFC2373] R. Hinden, S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[RFC-2893] R. Gilligan and E. Nordmark, "Transition Mechanisms for
IPv6 Hosts
and Routers", RFC2893, August 2000
[RFC2529] B. Carpenter, C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC2529, March 1999.
[RFC-2874] M. Crawford, C. Huitema, DNS Extensions to Support IPv6
Address
Aggregation and Renumbering, RFC2874, July 2000
[RFC3053] A. Durand, P. Fasano, I. Guardini, D. Lento,
"IPv6 Tunnel Broker", RFC3053, February 2001
[RFC3056] B. Carpenter, K Moore,
"Connection of IPv6 Domains via IPv4 Clouds", RFC3056,
February 2001
[ICMPv6] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 2463, December 1998.
[IPv6-DISC] Narten, T., Nordmark, E. and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[ADDRCONF] Thomson, S. and T. Narten, "IPv6 Address
Autoconfiguration", RFC 2462, December 1998.
[ADDR] Hinden, R and S. Deering
"<draft-ietf-ipngwg-addr-arch-v3-07.txt>"
November 20th 2001.
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
Registration Authority",
http://standards.ieee.org/db/oui/tutorials/EUI64.html,
March 1997.
[PRIVACY] Narten, T., R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[NGTRANS] W. Biemolt M. Kaat, T. Larder, H. Steenman, R. van der Pol,
G. Tsirtsis, A Durand, K. Yamamoto, Y. Sekiya, D. Finkerson,
A. Hazeltine. An overview of the introduction of IPv6 in the
Internet
<draft-ietf-ngtrans-introduction-to-IPv6-transition-07.txt>
[ISATAP] F. Templin, T Gleeson, M. Talwar, D. Thaler
Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)
<draft-ietf-ngtrans-isatap-03
Expires October 2002
24. Authors name and address.
Paul Gilbert
Cisco Systems, Inc.
1 Penn Plaza, 5th floor
New York, NY 10119
Phone: 212-714-4334
Email: pgilbert@cisco.com
