Internet Protocol version 6 laboratory: Difference between revisions
imported>Howard C. Berkowitz (Where to ping in a dynamic environment?) |
mNo edit summary |
||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
{{subpages}} | {{subpages}} | ||
{{TOC | {{TOC|right}} | ||
{{main|Internet Protocol version 6}} | |||
{{seealso|Internet Protocol version 6 deployment}} | |||
To become familiar with IPv6 in the real world, at some point, it is wise to have an '''Internet Protocol version 6 Laboratory'''. This article describes a step-by-step approach to learning the basic concepts, which are defined as the operation of IPv6 by itself, not in a coexistence or IPv4 transition environment. | To become familiar with IPv6 in the real world, at some point, it is wise to have an '''Internet Protocol version 6 Laboratory'''. This article describes a step-by-step approach to learning the basic concepts, which are defined as the operation of IPv6 by itself, not in a coexistence or IPv4 transition environment. | ||
It is quite appropriate, after the basics are under control, to extend the laboratory to involve more advanced topics. At this point, however, the "core" path will start to branch. One basic branch will be determined by whether one's interest is more in IPv6 applications (i.e., client and server operations) or in IPv6 networking; the latter ranges from internal [[routing]], to [[Internet]] or [[virtual private network]] access in a pure IPv6 environment, to the relatively simple point-to-point tunneling of IPv6 through IPv4. | It is quite appropriate, after the basics are under control, to extend the laboratory to involve more advanced topics. At this point, however, the "core" path will start to branch. One basic branch will be determined by whether one's interest is more in IPv6 applications (i.e., client and server operations) or in IPv6 networking; the latter ranges from internal [[routing]], to [[Internet]] or [[virtual private network]] access in a pure IPv6 environment, to the relatively simple point-to-point tunneling of IPv6 through IPv4. | ||
==The beginning== | ==The beginning== | ||
[[Image:Initial setup.png|thumb|left|Initial setup]] | [[Image:Initial setup.png|thumb|400px|left|Initial setup]] | ||
It would be hard to be simpler than one client and one server, and, indeed, that may be slightly too simple, as in the figure, "Basic setup". If things were that simple, the two devices could be connected with a simple [[IEEE 802.3]] crossover cable. | It would be hard to be simpler than one client and one server, and, indeed, that may be slightly too simple, as in the figure, "Basic setup". If things were that simple, the two devices could be connected with a simple [[IEEE 802.3]] crossover cable. | ||
Unfortunately, with direct connected client and server, there is no way to observe and troubleshoot the interaction. Minimally, it is wise to connect the two devices to an internetworking device, such as a bridge (i.e., "layer 2 switch") that has port mirroring capability. Port mirroring allows a computer to receive, monitor and analyze all traffic on a server or client port. | Unfortunately, with direct connected client and server, there is no way to observe and troubleshoot the interaction. Minimally, it is wise to connect the two devices to an internetworking device, such as a bridge (i.e., "layer 2 switch") that has port mirroring capability. Port mirroring allows a computer to receive, monitor and analyze all traffic on a server or client port. Another ''critical'' requirement of that switch is capturing the [[medium access control|MAC addresses]] it sees on a port. | ||
A reality may be that it is not necessarily feasible to set up and administer these first machines with native IPv6. The initial setup, therefore, admits that a dual stack might be needed, for running IPv4 from a system administration machine to second IPv4 [[network interface card]]s (NIC) on the IPv6 hosts. | A reality may be that it is not necessarily feasible to set up and administer these first machines with native IPv6. The initial setup, therefore, admits that a dual stack might be needed, for running IPv4 from a system administration machine to second IPv4 [[network interface card]]s (NIC) on the IPv6 hosts. | ||
Assuming that manual address configuration is supported, connect one application client and one application server, preferably to a L3 switch that has port mirroring. | Assuming that manual address configuration is supported, connect one application client and one application server, preferably to a L3 switch that has port mirroring. | ||
[[Image:First Dynamic Addressing.png|thumb|400px| First dynamic addressing]] | |||
===Testing support=== | ===Testing support=== | ||
To the mirroring jack, and possibly to a second interface on the subnet if there is a separate NIC, connect a | To the mirroring jack, and possibly to a second interface on the subnet if there is a separate NIC, connect a Linux “tools server”, much as one might have in a sinkhole. See the figure, "First Dymamic Addressing". At a minimum, this would be an open-source (or proprietary if they are on hand) [[Protocol analyzer#Wireshark|protocol analyzer]] such as [[Wireshark]] or a [[network intrusion detection system#network intrusion detection system|network intrusion detection system (NIDS)]] such as [[Snort]]. If the hosts support the [[Simple Network Management Protocol]] (SNMP), open source SNMP analyzers are available; see the SNMP article. A support host should run [[syslog]]. | ||
This will let the operations staff gain experience writing out the address formats (at least global and ULA should be tried), observe basic neighbor discovery and ICMPv6 if a protocol analyzer is used, etc. | |||
This will let | |||
===The fundamental question: what do I ping?=== | ===The fundamental question: what do I ping?=== | ||
Even in a DHCPv4 environment, a user support desk that gets a problem report can have real challenges in determining the IP address of the user host, in order to use common tools to test connectivity to it. User IDs in DHCP requests aren't always the answer, unless the organization has some way of knowing what address is associated with which physical machine. | Even in a DHCPv4 environment, a user support desk that gets a problem report can have real challenges in determining the IP address of the user host, in order to use common tools to test connectivity to it. User IDs in DHCP requests aren't always the answer, unless the organization has some way of knowing what address is associated with which physical machine. | ||
| Line 41: | Line 41: | ||
Now, set up a second subnet, with at least another DNS tools server, and connect it to the first using two routers from the main subnet. If these are all interconnected via the same physical box, you must be able to put different preferences on the routes. | Now, set up a second subnet, with at least another DNS tools server, and connect it to the first using two routers from the main subnet. If these are all interconnected via the same physical box, you must be able to put different preferences on the routes. | ||
[[Image:Static routing.png|thumb|left| Static routing]] | [[Image:Static routing.png|thumb|400px|left| Static routing]] | ||
You are now ready to try multiple-subnet anycast. The simplest way to do this would be with additional DNS servers. Adding application servers on one of the "remote" subnets will allow testing application failover, remote address assignment, etc. | You are now ready to try multiple-subnet anycast. The simplest way to do this would be with additional DNS servers. Adding application servers on one of the "remote" subnets will allow testing application failover, remote address assignment, etc. | ||
| Line 54: | Line 54: | ||
[[Open Shortest Path First]], the IPv6 version, is probably the best dynamic interior routing protocol to use here. If you use RIP, you must be able to artificially increase the hop count associated with interfaces. | [[Open Shortest Path First]], the IPv6 version, is probably the best dynamic interior routing protocol to use here. If you use RIP, you must be able to artificially increase the hop count associated with interfaces. | ||
[[Image:Dynamic interior routing.png|thumb| Dynamic interior routing]] | [[Image:Dynamic interior routing.png|thumb|400px| Dynamic interior routing]] | ||
If they are familiar, this is a good time to start out router management tools such as [[RANCID]] and [[Nagios]], if they can work with IPv6. | If they are familiar, this is a good time to start out router management tools such as [[RANCID]] and [[Nagios]], if they can work with IPv6. | ||
| Line 66: | Line 66: | ||
Enable BGP on one router, and connect to a simulated ISP router with, preferably, a minimal user AS or two, with a server or two, on the far side. See the figure "Basic Internet connectivity". | Enable BGP on one router, and connect to a simulated ISP router with, preferably, a minimal user AS or two, with a server or two, on the far side. See the figure "Basic Internet connectivity". | ||
[[Image:Basic Internet connectivity.png|thumb|left| Basic Internet connectivity]] | [[Image:Basic Internet connectivity.png|thumb|left|400px| Basic Internet connectivity]] | ||
Start with [[address registry#Provider-independent IPv6 |provider-independent (PI)]] addressing. If you like, experiment with provider-assigned (PA) routing dynamically learned with the Router Renumbering Protocol. | Start with [[address registry#Provider-independent IPv6 |provider-independent (PI)]] addressing. If you like, experiment with provider-assigned (PA) routing dynamically learned with the Router Renumbering Protocol. | ||
| Line 79: | Line 79: | ||
Next, enable BGP on 2 or more of the existing routers, so you can do multiprotocol iBGP in the "enterprise", and use RFC1998 multihoming to multiple POPs of a single ISP. | Next, enable BGP on 2 or more of the existing routers, so you can do multiprotocol iBGP in the "enterprise", and use RFC1998 multihoming to multiple POPs of a single ISP. | ||
[[Image:Basic Internet multihomed connectivity.png|thumb| Basic Internet multihomed connectivity]] | [[Image:Basic Internet multihomed connectivity.png|thumb|400px| Basic Internet multihomed connectivity]] | ||
If enough router ports are available, have one of the eBGP connections run through a [[Generic Routing Encapsulation]] IPv6 tunnel over IPv4 physical interfaces. | If enough router ports are available, have one of the eBGP connections run through a [[Generic Routing Encapsulation]] IPv6 tunnel over IPv4 physical interfaces. | ||
| Line 86: | Line 86: | ||
Next, enable BGP on 2 or more of the existing routers, and set up at least 2-3 routers simulating ISPs, with, preferably, a minimal user AS or two, with a server or two, on the far side. Start out with basic v6 multihoming with all PI-addressing, but this gives a path to such things as [[shim6]]. | Next, enable BGP on 2 or more of the existing routers, and set up at least 2-3 routers simulating ISPs, with, preferably, a minimal user AS or two, with a server or two, on the far side. Start out with basic v6 multihoming with all PI-addressing, but this gives a path to such things as [[shim6]]. | ||
[[Image:More advanced Internet multihoming.png|thumb|left| More advanced Internet multihoming]] | [[Image:More advanced Internet multihoming.png|thumb|left|400px| More advanced Internet multihoming]] | ||
The complexity of multihoming is specific to the degree of difficulty of your real-world connectivity. It will this is a lab for an enterprise or a service provider.[[Category:Suggestion Bot Tag]] | |||
Latest revision as of 11:00, 2 September 2024
- See also: Internet Protocol version 6 deployment
To become familiar with IPv6 in the real world, at some point, it is wise to have an Internet Protocol version 6 Laboratory. This article describes a step-by-step approach to learning the basic concepts, which are defined as the operation of IPv6 by itself, not in a coexistence or IPv4 transition environment.
It is quite appropriate, after the basics are under control, to extend the laboratory to involve more advanced topics. At this point, however, the "core" path will start to branch. One basic branch will be determined by whether one's interest is more in IPv6 applications (i.e., client and server operations) or in IPv6 networking; the latter ranges from internal routing, to Internet or virtual private network access in a pure IPv6 environment, to the relatively simple point-to-point tunneling of IPv6 through IPv4.
The beginning
It would be hard to be simpler than one client and one server, and, indeed, that may be slightly too simple, as in the figure, "Basic setup". If things were that simple, the two devices could be connected with a simple IEEE 802.3 crossover cable.
Unfortunately, with direct connected client and server, there is no way to observe and troubleshoot the interaction. Minimally, it is wise to connect the two devices to an internetworking device, such as a bridge (i.e., "layer 2 switch") that has port mirroring capability. Port mirroring allows a computer to receive, monitor and analyze all traffic on a server or client port. Another critical requirement of that switch is capturing the MAC addresses it sees on a port.
A reality may be that it is not necessarily feasible to set up and administer these first machines with native IPv6. The initial setup, therefore, admits that a dual stack might be needed, for running IPv4 from a system administration machine to second IPv4 network interface cards (NIC) on the IPv6 hosts.
Assuming that manual address configuration is supported, connect one application client and one application server, preferably to a L3 switch that has port mirroring.
Testing support
To the mirroring jack, and possibly to a second interface on the subnet if there is a separate NIC, connect a Linux “tools server”, much as one might have in a sinkhole. See the figure, "First Dymamic Addressing". At a minimum, this would be an open-source (or proprietary if they are on hand) protocol analyzer such as Wireshark or a network intrusion detection system (NIDS) such as Snort. If the hosts support the Simple Network Management Protocol (SNMP), open source SNMP analyzers are available; see the SNMP article. A support host should run syslog.
This will let the operations staff gain experience writing out the address formats (at least global and ULA should be tried), observe basic neighbor discovery and ICMPv6 if a protocol analyzer is used, etc.
The fundamental question: what do I ping?
Even in a DHCPv4 environment, a user support desk that gets a problem report can have real challenges in determining the IP address of the user host, in order to use common tools to test connectivity to it. User IDs in DHCP requests aren't always the answer, unless the organization has some way of knowing what address is associated with which physical machine.
Dynamic DNS update can help, but there is still the problem of determining the unique identifier of the user. In an enterprise that has a structured wiring plant, one approach is to have each user computer connected to a layer 2 or 3 switch port that will capture the MAC address coming into it from the user. If the ports are identified in a manner that can map to the user (e.g., Campus A, Building 3, Floor 2, Office Q, Desk 77), then one can use SNMP to query the switch to find the MAC address of the attached host. With that information, you can then search the DHCP server log to find the IP assignment, even in the absence of dynamic IP update. Of course, if your user hosts can be preconfigured with an identifier that is unique to a location, this becomes all the better.
A similar approach can apply with DHCPv6, with due regard for converting the MAC address to a 64-bit host identifier. SLAAC, however, is much more challenging, because there is no server log. In such a case, interrogating access switches to find the host MAC address for the physical location, and then computing the IPv6 address, may be the only alternative.
Adding incremental IPv6 capabilities
Next, to the same subnet, add, either to the tools box or one of two new servers, DNSv6 with dynamic update and the appropriate PKI. The lab might start with DHCP and DNS on the same machine, but it would be highly desirable to test dynamic update between DHCPv6 and DNS, across the local network, before teting the harder to reconstruct SLAAC.
Have at least one application server, running the operating system that will run your regular applications.
Anycast is worth investigating. You will need at least two servers, running some application that is either read-only or for which multiple updates will not corrupt the data. In the interest of stability, at first use only a unicast address on same host that runs DHCP, syslog, or other services that are critical to bringing up hosts, and are stateful.
If there are no readily available user applications that are read-only or can tolerat multiple updates of the same data, consider three inexpensive servers, two of which might have only DNS running on them and the other having the critical tools. By doing so, you should be able to disable either DNS host and still get name resolution from the local workstations. Anycast should be investigated further on any other server operating systems that may be used, as well as having the address accessible through different physical subnets; the latter will wait until IPv6 routing is up.
Basic IPv6-only routing
In the discussion below, "routers" may be dedicated two-port IPv6 physical routers, multiple ports on a lesser number of routers, or software simulating a router. These also can one or more layer 3 "switches" with three virtual local area network (VLAN) subnets.
Now, set up a second subnet, with at least another DNS tools server, and connect it to the first using two routers from the main subnet. If these are all interconnected via the same physical box, you must be able to put different preferences on the routes.
You are now ready to try multiple-subnet anycast. The simplest way to do this would be with additional DNS servers. Adding application servers on one of the "remote" subnets will allow testing application failover, remote address assignment, etc.
Putting additional application clients and servers on remote subnets, however, will allow more exploration of failover and load sharing.
More advanced IPv6 interior routing
Add enough additional subnets, which need not have more than a single server or client, so that there can be dynamic, multi-hop V6 routing of various flavors.
Open Shortest Path First, the IPv6 version, is probably the best dynamic interior routing protocol to use here. If you use RIP, you must be able to artificially increase the hop count associated with interfaces.
If they are familiar, this is a good time to start out router management tools such as RANCID and Nagios, if they can work with IPv6.
Initial Internet connectivity
Enable BGP on one router, and connect to a simulated ISP router with, preferably, a minimal user AS or two, with a server or two, on the far side. See the figure "Basic Internet connectivity".
Start with provider-independent (PI) addressing. If you like, experiment with provider-assigned (PA) routing dynamically learned with the Router Renumbering Protocol.
Basic Internet single-ISP multihoming
Next, enable BGP on 2 or more of the existing routers, so you can do multiprotocol iBGP in the "enterprise", and use RFC1998 multihoming to multiple POPs of a single ISP.
If enough router ports are available, have one of the eBGP connections run through a Generic Routing Encapsulation IPv6 tunnel over IPv4 physical interfaces.
More advanced Internet multihoming
Next, enable BGP on 2 or more of the existing routers, and set up at least 2-3 routers simulating ISPs, with, preferably, a minimal user AS or two, with a server or two, on the far side. Start out with basic v6 multihoming with all PI-addressing, but this gives a path to such things as shim6.
The complexity of multihoming is specific to the degree of difficulty of your real-world connectivity. It will this is a lab for an enterprise or a service provider.