INTERNET DRAFT Paul Gilbert, Cisco Systems Expires October 2002 Implementing IPv6 Networks in the Enterprise 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 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 "" 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 [ISATAP] F. Templin, T Gleeson, M. Talwar, D. Thaler Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)