- 1 What is IPv6
- 1.1 Why Do We Need IPv6?
- 1.2 Main differences from IPv4 to IPv6
- 1.3 When Is It Time for IPv6?
- 1.4 Security with IPv6
- 1.5 Quality of Service
- 1.6 Networking Aspects
- 2 WAN
- 3 LAN
What is IPv6
IPv6 is an evolution of IPv4. The protocol is installed as a software upgrade in most devices and operating systems. If you buy up-to-date hardware and operating systems, IPv6 is usually supported and needs only activation or configuration. Currently available transition mechanisms allow the step-by-step introduction of IPv6 without putting the current IPv4 infrastructure at risk.
Why Do We Need IPv6?
For historic reasons, organizations and government agencies in the United States use approximately 60 percent of the allocatable IPv4 address space. The remaining 40 percent is shared by the rest of the world. Of the 6.4 billion people in the world, approximately 330 million live in North America, 807 million in Europe, and 3.6 billion in Asia. This means that the 5 percent of the world's population living in the United States has 60 percent of the address space allocated. Of the 3.6 billion people living in Asia, approximately 364 million have Internet access, and the growth rate is exponential. This is one explanation of why the deployment of IPv6 in Asia is much more common than in Europe and the United States. (All statistics are based on 2005 numbers.)
An interesting resource site for statistics can be found at: http://www.internetworldstats.com/stats.htm.
Main differences from IPv4 to IPv6
Here is an overview of the main changes:
- Extended address space
- The address format is extended from 32 bits to 128 bits. This provides an IP address for every grain of sand on the planet. In addition, it also allows for hierarchical structuring of the address space in favor of optimized global routing.
- Perhaps the most intriguing new feature of IPv6 is its Stateless autoconfiguration mechanism. When a booting device in the IPv6 world comes up and asks for its network prefix, it can get one or more network prefixes from an IPv6 router on its link. Using this prefix information, it can autoconfigure for one or more valid global IP addresses by using either its MAC identifier or a private random number to build a unique IP address. In the IPv4 world, we have to assign a unique IP address to every device, either by manual configuration or by using DHCP. Stateless autoconfiguration should make the lives of network managers easier and save substantial cost in maintaining IP networks. Furthermore, if we imagine the number of devices we may have in our homes in the future that will need an IP address, this feature becomes indispensable. Imagine reconfiguring your DHCP server at home when you buy a new television! Stateless autoconfiguration also allows for easy connection of mobile devices, such as a mobile phone or handheld, when moving to foreign networks.
- Simplification of header format
- The IPv6 header is much simpler than the IPv4 header and has a fixed length of 40 bytes. This allows for faster processing. It basically accommodates two times 16 bytes for the Source and Destination address and only 8 bytes for general header information.
- Improved support for options and extensions
- IPv4 integrates options in the base header, whereas IPv6 carries options in so-called extension headers , which are inserted only if they're needed. Again, this allows for faster processing of packets. The base specification describes a set of six extension headers, including headers for routing, Mobile IPv6, and quality of service and security.
When Is It Time for IPv6?
If the rest of the world moves to IPv6 while you insist on continuing to use IPv4?, you will exclude yourself from global communication and reachability. This might not be a critical issue today, but times are changing fast these days. The risks if you wait too long include losing potential customers and access to new markets and the inability to use new IPv6-based business applications until you implement it.
There is a golden rule in IT: "Never touch a running system.", and I normally tend to this, but As long as your IPv4 infrastructure runs well and fulfills your needs, there is no reason to change anything. But from now on, whenever you invest in your infrastructure, you should consider IPv6. An investment in the new technology gives it a much longer lifetime and keeps your network state-of-the-art.
These are the main indicators that it may be time for you to consider switching to or integrating IPv6:
- You need to extend or fix your IPv4 network or NAT implementation.
- You are running out of address space.
- You want to prepare your network for applications that are based on advanced features of IPv6.
- You need end-to-end security for a large number of users and you do not have the address space, or you struggle with a NAT implementation.
- You need to replace your hardware or applications that are at the end of their lifecycles. NB. Make sure you buy products that support IPv6, even if you don't enable it right away.
- You want to introduce IPv6 while there is no time pressure.
The following provisions can be taken in order to prepare for IPv6 adequately:
- Build internal knowledge, educate IT staff, and create a test network.
- Include IPv6 in your IT strategy.
- Create integration scenarios based on your network and requirements.
- Put IPv6 support on all of your hardware and software shopping lists. Be specific about which features (RFCs) must be supported.
- Compel your vendors to add IPv6 support to their products.
If you do this, you can determine the right moment for the introduction of IPv6 in your network. You can also assess whether a further investment in your IPv4 infrastructure makes sense or whether introducing IPv6 would be a better way to go.
There will be no "flag day" for IPv6 like there was for the 1983 move from NCP to IPv4. Probably there will be no killer application either, so don't wait for one. IPv6 will slowly and gradually grow into our networks and the Internet. Taking a step-by-step approach to IPv6 may be the most cost-efficient way to integrate it, depending on your requirements. This method does not put your current infrastructure at risk or force you to exchange hardware or software before you are ready, and it allows you to become familiar with the protocol, to experiment, to learn, and to integrate what you've learned into your strategy.
Security with IPv6
The developers of IPv4 did not rack their brains about security. The "Internet" in those early days connected a few trusted networks of some visionary researchers. The individuals who controlled these networks, as well as those who were allowed to use the networked resources, were implicitly trusted to not cause any malicious or destructive behavior. This is the reason why the original IP architecture does not include a security framework that can be used by all applications. If security was needed, it was usually rudimentary authentication/authorization and was included in the application code (e.g., the password for Telnet and FTP). Many years later, IPsec was introduced when IPv4 had already been widely deployed. Therefore, it needed to be retrofitted into existing deployments. Due to many interoperability and performance issues, IPsec is not widely deployed in many IPv4 scenarios. This is in contrast to IPv6, which from the beginning had the notion that fundamental security functionality had to be included in the base protocol in order to be used on any Internet platform. A standards-conforming IPv6 implementation must include IPsec to allow more secured communication once it is appropriately configured. Before we dive into the technical details, I want to talk about some general security concepts and practices.
General Security Concepts
In order to protect data, one has to be aware of the possible threats. People often focus solely on malicious attacks from foreign networks. A comprehensive security concept needs to consider many other aspects. Following is a list of possible points of weakness:
- Insufficient or nonexistent IT security concepts and corresponding provisions
- Nonobservance or insufficient control of IT security provisions
- Usurping of rights (password theft)
- Incorrect use or faulty administration of IT systems
- Abuse of rights
- Weaknesses in software (buffer/heap overflows in conjunction with applications running with superuser rights)
- Manipulation, theft, or destruction of IT devices, software, or data (physical security)
- Network eavesdropping (sniffing wired or wireless networks) or replaying of messages
- Trojan horses, viruses, and worms
- Security attacks such as masquerading, IP spoofing, Denial of Service (DoS) attacks, or man-in-the-middle attacks
- Routing misuse
There are many statistics showing that malicious attacks from the outside are only a smaller fraction of all the possible risks. Many threats come from within the internal network and can in many cases be related to human misconduct or faulty administration. Many of these risks cannot be controlled by technical mechanisms. This is not a guide to an overall security concept; it discusses the technology aspects of security with IPv6.
General Security Practices
Standard security practices involve two "triads" of thought, CIA and AAA.
The CIA triad includes:
- Stored or transmitted information cannot be read or altered by an unauthorized party.
- Any alteration of transmitted or stored information can be detected.
- The information in question is readily accessible to authorized users at all times.
The AAA triad includes:
- Ensuring an individual or group is who they say they are. The act of clarifying a claimed identity. Common forms of authentication include usernames and passwords or ATM card/PIN combinations.
- Ensuring that the authenticated user or group has the proper rights to access the information they are attempting to access. Common implementations include access control lists (ACLs).
- The act of collecting information on resource usage. The log of an HTTP server would be a common form of accounting.
Nonrepudiation is not included in the CIA/AAA Triads. Nonrepudiation means a specified action such as sending, receiving, or deleting of information cannot be denied by any of the parties involved.
These security requirements need to be provided by two basic security elements: encryption (to provide confidentiality) and secure checksums (to provide integrity). Suitable combinations of these two elements may then be used to provide more complex services, such as authenticity and nonrepudiation.
There are two forms of encryption that are commonly used. The first is called "Secret Key Cryptography," also termed symmetric key encryption , which requires the sender and recipient to agree on a shared secret (i.e., a key or password) that is then used to encrypt and decrypt the information exchanged. Common symmetric key algorithms are DES, 3DES, IDEA, RC-4, and AES.
The second is called "Public Key Cryptography," also termed asymmetric encryption . An asymmetric encryption algorithm uses a key pair consisting of a known and distributed public key and an individual private key. When a message is encrypted using the public key and decrypted by the receiver with the corresponding private key, only the intended recipient is capable of seeing the encrypted message. This form of encryption can be used to establish a confidential data exchange. If in addition, the message was also encrypted with the sender's private key and then decrypted by the recipient with a corresponding public key, the security services of data origin authentication and nonrepudiation are added. Common asymmetric key algorithms are RSA and ElGamal.
Secure checksums or hash functions often provide data integrity. A hash function takes input of an arbitrary length and outputs fixed-length code. The fixed-length output is called the message digest, or the hash, of the original input message. These hashes are unique and thereby provide the integrity and authenticity of the message. Common one-way hash functions are MD-5 and SHA-1.
The IPsec standard uses a combination of algorithmic choices based on symmetric and asymmetric cryptography, as well as one-way hash functions. This describes the IPsec framework and the security elements in IPv6 and includes a discussion about special issues to be aware of when securing an IPv6 network.
The following elements are part of the IPsec framework:
- A general description of security requirements and mechanisms at the network layer
- A protocol for encryption (Encapsulating Security Payload, ESP)
- A protocol for authentication (Authentication Header, AH)
- A definition for the use of cryptographic algorithms for encryption and authentication
- A definition of security policies and security associations between communication peers
- Key management
The configuration of IPsec creates a boundary between a protected and an unprotected area. The boundary can be around a single host or a network. The access control rules specified by the administrator determine what happens to packets traversing the boundary. The security requirements are defined by a Security Policy Database (SPD). Generally, each packet is either protected using IPsec security services, discarded, or allowed to bypass IPsec protection, based on the applicable SPD policies identified by the selectors. The selectors are the specific traffic match criteria defined by an administratorfor example, a specific application being transmitted from a subnet to a specific end-host.
RFC 4301 contains a section listing all the changes since RFC 2401. The basic IPsec concepts remain the same. Changes have been made to address new IPsec scenarios, improve performance, and simplify implementation. A new database, the Peer Authorization Database (PAD), has been added and is described later.
Security Associations (SA) are agreements between communication peers. Three elements are part of the agreement: a key, an encryption or authentication mechanism, and additional parameters for the algorithm. SAs are unidirectional, and each separate security service requires an SA. This means that two communication peers who want to encrypt and authenticate a two-way communication need four SAs (one pair for encryption and one pair for authentication). Bidirectional application trafficfor example, a bidirectional Telnet connectionalso requires four SAs at each communication peer. Peer A must protect the traffic it initiates and the return traffic from Peer B. It also requires two additional SAs to ensure that if Peer B initiates a Telnet session, both it and the return traffic for this scenario are protected.
IPsec differentiates two modes of transport:
- Transport mode
- The SA is made between two end nodes and defines the encryption or authentication for the payload of all IP packets for that connection. The IP header is not encrypted.
- Tunnel mode
- The SA is usually made between two security gateways. The whole packet including the original IP header is encrypted or authenticated by encapsulating it in a new header. This is the foundation for a virtual private network (VPN).
Most of the security mechanisms provided by IPsec require the use of cryptographic keys. A separate set of mechanisms has been defined for putting the keys in place. Support for both manual and automated distribution of keys is a requirement. RFC 4301 specifies IKEv2 (described later in this section) as an automated key distribution mechanism. Other mechanisms may be used.
In order to establish a Security Association (SA), the communication peers have to agree on a cryptographic algorithm and negotiate keys. The negotiation of an SA often happens over insecure paths. Internet Key Exchange (IKE) specifies a protocol that allows for the exchange and negotiation of parameters for an SA.
There are three important databases in the IPsec model:
- Security Policy Database (SPD)
- Specifies the policies that determine the disposition of all IP traffic (inbound or outbound) from a host or security gateway. There are three possible processing rules after application of the SPD policies: discard, bypass, or protect.
- Security Association Database (SAD)
- Contains an entry for each SA and the parameters associated with it.
- Peer Authorization Database (PAD)
- Provides a link between an SA management protocol (such as IKE) and the SPD.
The Peer Authorization Database is new with the specification in RFC 4301. Its main functions are to identify the peers or groups of peers authorized to communicate with the IPsec entity, to specify the protocol and method used to authenticate each peer, and to contain the authentication data for each peer.
There is work in progress to ensure that IPsec performance concerns are addressed so that vendors can create sound implementations. This work is part of the Benchmarking Methodology Working Group (BMWG). If you are interested in this work, go to the BMWG at http://www.ietf.org/html.charters/bmwg-charter.html or refer to the drafts: draft-ietf-bmwg-ipsec-term-08.txt and draft-ietf-bmwg-ipsec-meth-01.txt.
Enterprise Security Models for IPv6
End-to-end transparency and security has been lost in many IPv4 networks due to the need to introduce NAT because of the shortage of IPv4 addresses. IPv6 can restore the transparency. However, some people have become used to seeing NAT and private addressing schemes to provide security in enterprise networks by hiding the network topology from the outside. These people may perceive the IPv6 transparency as a threat to their network and may even plan to deploy IPv6 networks with private local addressing schemes and translators only for this reason.
The goal with IPv6 is to restore end-to-end connectivity by using the abundant address space. To secure an IPv6 network, a security concept has to be created and the security mechanisms have to be implemented. NAT should no longer be used with IPv6. If hiding network topology from the outside is a requirement, other mechanisms should be used, such as private addressing (RFC 3041), unique local addresses (ULAs), or untraceable IPv6 addresses. Find a detailed description and discussion of these options in draft-ietf-v6ops-nap-02.txt, "IPv6 Network Architecture Protection" (NAP).
The New Model
In IPv4 networks, the favored model for security is to have perimeter firewalls and integrate NATs. Applying this same approach in an IPv6 network may be a good starting point, but is limiting in the long term. In IPv6 networks, you should aim to design an improved security model that increases the overall security of the network but also facilitates end-to-end communication. IPv6 provides IPsec capability in each node. Relying on one perimeter firewall can be dangerous. An attacker who manages to get behind the firewall will usually find an open unsecured field. The optimal security concept for IPv6 networks will most likely be "defense in depth," a combination of centralized security policy repositories and distribution mechanisms that, in conjunction with trusted hosts, will allow network managers to place more reliance on security mechanisms at the end points and allow end points to influence the behavior of perimeter firewalls. Perimeter firewalls will be responsible for securing the network from general attacks, and the end node will be responsible for securing itself from node-related attacks. The new security policy model for IPv6/IPsec networks must be an identity-based model in order to separate security policy from network IDs. This is crucial for networks that want to allow for automation, autoconfiguration, and mobility without compromising security. This new distributed security model is emerging, and some of the technologies required are still under development, including protocols to allow end nodes to control and inform firewalls. Initial IPv6 deployments probably make use of similar firewall and intrusion detection techniques as used in today's IPv4 networks (with the exception of NATs, which should not be used at all in IPv6 networks). But the final goal to introduce a new type of distributed security concept should be kept in mind as you go along, and the development of these technologies should be followed closely.
There may be two types of managed security models depending on the size of the network to be secured:
- End Node Distributed Firewall Model
- A site security manager server authenticates end nodes on a network and then distributes firewall policies to end-node firewalls. This includes firewall configuration, access policies, IPsec keys, virus protection, etc. No site-level access control is required. Once an end node is authenticated and updated with a security policy, it is solely responsible for its own security.
- Hybrid Distributed Firewall Model
- A site-level security manager server may handle end-node authentication and distribution of firewall policies to both site firewalls and end-node firewalls. Once end nodes are authenticated, they can be granted varying levels of privilege by the security manager. The security manager's set of policies determines who has access to the outside, who has access to each other internally, which types of services and protocols may be run by different nodes, and who gets IPsec keys. The perimeter firewalls do some light access control while distributing the heavy work to the end-node firewalls. Various levels of coordination and control are possible in this model. In a simple version, end-node firewalls may run independently after being given the local firewall rule set by the security management service. In a more tightly managed version for high-security networks, the controller may coordinate between Intrusion Detection Systems (IDS), the site firewall, and end-node firewalls to detect attacks and shut off access to dangerous users inside or outside the corporate network.
One main source of information for the new model is a presentation by David B. Green, given at the North American IPv6 Task Force (NAv6TF) Technologist Seminar in November 2004 at the George Mason University, Washington, D.C. We thank David for the permission to present it in this book.
IPv6 Firewall Filter Rules
When you live in a dual-stack network, you will have two security concepts: one for the IPv4 world and another for the IPv6 world. And the two concepts do not have to match; they have to be designed according to the requirements of each protocol. Your firewalls may support both protocols, having two separate filter sets (one for each protocol), or you may have two boxes, one being the firewall for the IPv4 network and the other being the firewall for your IPv6 network.
Without trying to provide a full-fledged Security and Firewall Guide, here are some ideas for IPv6 security provisions and firewall filters that should be considered:
- Ingress filter at perimeter firewall for internally used addresses.
- Filter unneeded services at the perimeter firewall.
- Deploy host-based firewalls for a defense in depth.
- Critical systems should have static, nonobvious (randomly generated) IPv6 addresses. Consider using static neighbor entries for critical systems (versus letting them participate in ND).
- Hosts for Mobile IPv6 operations should be separate systems (to protect them by separate rules).
- Ensure that end nodes do not forward packets with Routing Extension headers.
- Layer 3 firewalls should never forward link-layer multicast packets.
- Firewalls should support filtering based on Source and Destination address, IPv6 extension headers, and upper-layer protocol information.
- Check your network for external packets that did not enter through your main perimeter firewall as an indication of "backdoor" connections of surreptitious tunneling.
In IPv6 networks, ICMPv6 plays a fundamental role and provides great functionality. Uncontrolled forwarding of ICMP messages also creates security risks. draft-ietf-v6ops-icmpv6-filtering-bcp-01.txt, Best Current Practice for Filtering ICMPv6 Messages in Firewalls, provides recommendations for the configuration of ICMPv6 firewall filtering rules (specifically, allowing the forwarding of messages that are important for the functioning of the network and dropping messages that are potential security risks).
Quality of Service
In the beginning, the Internet was designed to be a simple communications platform, mainly used to support file transfer and email. Over the past 25+ years, it has grown to be a very complex global communications infrastructure with a multitude of applications and services. IPv4 is based on a simple packet switching model, delivering packets with best effort and no guarantee for delivery. TCP adds guaranteed delivery but has no options to control parameters such as delay and jitter or to do bandwidth allocation.
Emerging multimedia services (such as Voice over IP, videoconferencing and live Television) can have significant bandwidth demands and are often very sensitive to timely delivery. The Type of Service Byte (ToS) in the IPv4 header was designed to provide prioritized treatment of certain traffic. However, it was never widely implemented, one reason being that its use would delay the forwarding of packets on routers. As there were almost no real-time services in those days, there was little pressure to find better solutions.
The development of IPv6, combined with the growing demand for real-time servicesand, therefore, Quality of Service (QoS) featureswas an opportunity to look for other solutions. Despite the availability of several different approaches, the topic of QoS is still a matter of research, and there are many ideas under development.
The current IP model treats all packets alike. They are all forwarded with best effort treatment according to the "first-come, first-served" principle. Which path a packet takes through the network depends on the available routers, routing tables, and general network load.
QoS protocols have the task of providing different data streams with priorities and guaranteeing qualities such as bandwidth and delay times. There are currently two main architectures: Integrated Services (IntServ) and Differentiated Services (DiffServ). Both architectures use traffic policies and can be combined to allow for QoS in the LAN as well as in the WAN.
Traffic policies can be used to make the transmission of data dependent on certain criteriafor example, whether there are enough resources available to forward the data according to its QoS requirements. Traffic policies can also monitor data streams and make adjustments or restrictions if necessary. Besides ensuring QoS requirements for delay-sensitive traffic, they can also be used for commercial reasons, such as controlling cost depending on different service levels.
The Integrated Services Architecture (IntServ) is based on the paradigm that bandwidth and all related resources per flow are reserved on an end-to-end basis. This presupposes that routers store information about flows and analyze each packet to determine whether it belongs to a specific flow in order to forward the packet according to the criteria for that specific flow.
RSVP (Resource Reservation Protocol, RFC 2205) is part of the IntServ architecture. RFC 2210, "The Use of RSVP with IETF Integrated Services," describes the use of RSVP with IntServ. RSVP is a signaling protocol used to reserve bandwidth and other QoS resources across an IP network. IntServ combined with RSVP can be complex to implement and, because of its limited scalability, is inadequate to offer a general QoS solution for the global Internet.
To find an updated list of IntServ service and parameter names and their associated values, go to http://www.iana.org/assignments/integ-serv
If you are interested in further reading about RSVP and other QoS signaling protocols, refer to the informational RFC 4094," Analysis of Existing Quality-of-Service Signaling Protocols."
While IntServ offers the capability to allocate bandwidth to different flows, the Differentiated Services (DiffServ) architecture was designed to make a less granular differentiation of classes in order to increase its scalability and usability in large networks and in the Internet.
Differentiated Services is specified in RFCs 2474 and 2475. RFC 2474, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers," specifies the DS field. This is implemented in the ToS field in the IPv4 header and the Traffic Class field in the IPv6 header. The DS field is used by DiffServ routers to determine the QoS forwarding requirements of packets. Communicating nodes can categorize their communication through a so-called Per-Hop Behavior (PHB). Based on the PHB, packets receive specific treatment on DiffServ routers.
A DiffServ (DS) domain is a contiguous group of DS routers that work with a common service policy implemented on all routers. A DS domain is defined by DS boundary routers. The boundary routers classify incoming data streams and ensure that all packets traversing the domain are labeled appropriately and use a Per-Hop Behavior from the set available for the domain. Routers within the domain choose the forwarding rules based on the DiffServ values in packets, which they map to the corresponding PHBs. The Differentiated Services Codepoint (DSCP; refer to Figure 6-1, shown later) value can use either the default mapping (DSCP=0) or an individually configured mapping for the domain. A DS domain usually consists of one network or a set of networks, which constitute an administrative unit.
A DS region is a set of contiguous DS domains. DS regions can ensure DS services for domain spanning paths. The single domains can use individual PHB definitions and PHB-codepoint mappings internally. Between the domains within a region, Traffic Conditioners are responsible for providing correct translation of the different PHBs and mappings. If the policies, PHB groups, and codepoint mappings are the same in all the domains within the region, no Traffic Conditioners are needed.
Packet Classifiers choose packets from a data stream based on information in the packet headers and according to predefined rules. There are two types of classifiers: the Behavior Aggregate Classifier (BA) classifies packets based on the DS field, and the Multi Field Classifier (MF) classifies packets based on either different header fields or a combination of header fields, such as Source or Destination address, DS field, protocol number, source or destination port, or information such as incoming interface.
IP sits between the Data Link layer and the Transport layer. One of the goals in the development of IPv6 was to be able to support as many different physical networks as possible and to require no changes in the Transport layer. This approach is called "IP over Everything." To make IP as independent as possible from the Data Link layer, it needs an interface to this layer, which can be Ethernet, ATM, Token Ring, or any other media. The interface needs to be flexible and must be able to adapt to different requirements. For this purpose, features such as Path MTU discovery and fragmentation have been optimized. For UDP and TCP, it should not matter whether IPv4 or IPv6 is used. Obviously, changes are needed whenever IP addresses are used because of the difference in the address format. All these requirements lead to changes built into the IP layer itself. Multicast has been enhanced, and broadcast will not be used with IPv6.
In this tutorial I'm using a Debian server as a router, with one device eth0 on a LAN with IPv4 address 192.168.1.2. And another eth1 with my public IP address at the time of writing 220.127.116.11.
With IPv6, other systems can connect directly to the Debian system, regardless of the router and NAT. This tutorial will work for Debian systems that are not connected directly to the Internet as well.
To use IPv6, we will configure a tunnel that connects our IPv6 Debian system to IPv6 hardware on the other end (run by a so-called "tunnel broker") and thus to the IPv6 backbone. This tunnel is necessary because most ISPs don't support direct IPv6 connectivity yet, mine included, and it doesn't make sense to route my IPv6 traffic over an IPv4 network because chances are that the next-hop router doesn't know what to do with this kind of traffic.
There are multiple tunnel brokers that give you a tunnel and IPv6 addresses for free (e.g. http://tunnelbroker.net/, http://go6.net/4105/freenet.asp, http://www.sixxs.net/). These tunnel brokers are connected to the IPv6 backbone, and the tunnel connects your Debian system to their IPv6 hardware and therefore to the IPv6 backbone.
Creating A Tunnel
Register with a tunnel broker - I'm using http://tunnelbroker.net/ as they are very fast - you can be up and running in a few minutes.
Login on their web interface and create a tunnel ("Create Regular Tunnel" on the http://tunnelbroker.net/ web site). Fill in the IPv4 endpoint (this is the public IPv4 address of your Debian system - if it is behind a router, this is your router's public IPv4 address) and select a location close to you (these are the locations where the tunnel broker has POPs, i.e., connections to the IPv6 backbone):
Afterwards you will see a screen with the details of your tunnel.
Please write down the Server IPv4 address (18.104.22.168), the Server IPv6 address (2001:470:27:419::1), and the Client IPv6 address (2001:470:27:419::2). We will need them in a moment.
Configuring The Debian System
Log in to your Debian system and take a look at the output of
eth0 Link encap:Ethernet HWaddr 00:16:3e:39:2d:0a inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.254.0 inet6 addr: fe80::216:3eff:fe39:2d0a/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:750872611 errors:0 dropped:0 overruns:0 frame:0 TX packets:729916165 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:588548005153 (548.1 GiB) TX bytes:211623304165 (197.0 GiB) eth1 Link encap:Ethernet HWaddr 00:14:d1:17:fb:b8 inet addr:22.214.171.124 Bcast:126.96.36.199 Mask:255.255.254.0 inet6 addr: fe80::214:d1ff:fe17:fbb8/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:705980121 errors:0 dropped:0 overruns:0 frame:0 TX packets:706099927 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:155295421029 (144.6 GiB) TX bytes:543536672693 (506.2 GiB) Interrupt:22 Base address:0x6000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:267365 errors:0 dropped:0 overruns:0 frame:0 TX packets:267365 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:221328734 (211.0 MiB) TX bytes:221328734 (211.0 MiB)
Nothing special here, but the inet6 addr in the output means that the system is IPv6 capable.
Now we configure our new public IPv6 address and the tunnel as follows:
# Hurricane Electric IPv6 tunnel #------------------------------# auto he-ipv6 iface he-ipv6 inet6 v4tunnel address 2001:470:27:419::2 # Client IPv6 netmask 64 # Client netmask (he.net provide 48 for large networks also) endpoint 188.8.131.52 # Broker endpoint IP local 184.108.40.206 # You ISP-IP gateway 2001:470:27:419::1 # Broker gateway-IPv6 ttl 64 # Time-To-Live (TTL prevents a data packet from circulating indefinitely)
That's it already. Take a look at
eth0 Link encap:Ethernet HWaddr 00:16:3e:39:2d:0a inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.254.0 inet6 addr: fe80::216:3eff:fe39:2d0a/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:22353 errors:0 dropped:0 overruns:0 frame:0 TX packets:22182 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:3394676 (3.2 MiB) TX bytes:3177179 (3.0 MiB) eth1 Link encap:Ethernet HWaddr 00:14:d1:17:fb:b8 inet addr:220.127.116.11 Bcast:18.104.22.168 Mask:255.255.254.0 inet6 addr: fe80::214:d1ff:fe17:fbb8/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:22353 errors:0 dropped:0 overruns:0 frame:0 TX packets:22182 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:3394676 (3.2 MiB) TX bytes:3177179 (3.0 MiB) he-ipv6 Link encap:IPv6-in-IPv4 inet6 addr: 2001:470:27:419::2/64 Scope:Global inet6 addr: fe80::1f19:17e6/128 Scope:Link UP POINTOPOINT RUNNING NOARP MTU:1480 Metric:1 RX packets:22353 errors:0 dropped:0 overruns:0 frame:0 TX packets:22182 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:3394676 (3.2 MiB) TX bytes:3177179 (3.0 MiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:267365 errors:0 dropped:0 overruns:0 frame:0 TX packets:267365 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:221328734 (211.0 MiB) TX bytes:221328734 (211.0 MiB)
Now we can test if we can ping a IPv6 address through the tunnel broker's server:
ping6 -c4 ipv6.google.com
# ping6 -c4 ipv6.google.com PING ipv6.google.com(fx-in-x6a.1e100.net) 56 data bytes 64 bytes from fx-in-x6a.1e100.net: icmp_seq=1 ttl=56 time=77.8 ms 64 bytes from fx-in-x6a.1e100.net: icmp_seq=2 ttl=56 time=77.2 ms 64 bytes from fx-in-x6a.1e100.net: icmp_seq=3 ttl=56 time=77.4 ms 64 bytes from fx-in-x6a.1e100.net: icmp_seq=4 ttl=56 time=77.0 ms --- ipv6.google.com ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3013ms rtt min/avg/max/mdev = 77.055/77.399/77.801/0.338 ms
Ok, pinging other hosts is working fine. Now let's see if our system can be pinged on our public IPv6 address as well. Go to http://www.berkom.blazing.de/tools/ping.cgi and fill in your public IPv6 address. If all goes well, the output should be similar to this one:
TBA when my LAN is converted to run IPv6 and IPv4 at the same time