Jorge Martinez de Salinas

If the DNS server isn’t installed on your Linux box, install it with the following command:

yum groupinstall "DNS Name Server"

We need to configure two things. First we need to specify the domains we’re going to resolve in named.conf. We will resolve the labplan.southpark domain.
Our DNS server will support both direct (name->ip) and reverse (ip->name) resolution.

According to APNIC the use of ip6.int is deprecated in favor of ip6.arpa for
reverse resolutions. However, since many programs still use it, we’re going to define
the ip6.int version as well. We need to add the following lines to named.conf:

zone "labplan.southpark" IN {
type master;
file "labplan.southpark.zone";
};
//deprecated
zone "0.0.0.0.0.0.0.0.0.0.0.0.1.c.e.f.ip6.int" {
type master;
file"reverse-fec1_64i.IP6.INT";
};
zone "0.0.0.0.0.0.0.0.0.0.0.0.1.c.e.f.ip6.arpa" {
type master;
file "reverse-fec1_64.IP6.ARPA";
};

Next we have to fill the zone records. The information for direct resolutions is stored on labplan.southpark.zone:

$TTL    86400
@               IN SOA  @       root (
		42              ; serial (d. adams)
		3H              ; refresh
		15M             ; retry
		1W              ; expiry
		1D )            ; minimum
 
          IN NS           ns6.labplan.southpark.
 
 
ns6		 IN      AAAA    fec0::20c:29ff:fe8f:8f16
customer	 IN      AAAA    fec0::20c:29ff:feff:4b37
npserver	 IN      AAAA    fec0::20c:29ff:fe4a:fae0
an		 IN      AAAA    fec0::20c:29ff:feb4:bee2

The PTR records used for reverse resolution are stored on reverse-fec1_64i.IP6.INT (deprecated ip6.int) and reverse-fec1_64.IP6.ARPA (recommended ip6.arpa). This is the ip6.arpa zone (to edit an ip6.int zone just replace arpa with int):

$TTL 3d ; Default TTL 
@       IN SOA 0.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa. root (
                200906170       ; Serial number (YYYYMMdd)
                24h             ; Refresh time
                30m             ; Retry time
                2d              ; Expire time
                3d              ; Default TTL 
)
                                IN     NS     ns6.labplan.southpark.
7.3.b.4.f.f.e.f.f.f.9.2.c.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa.   IN PTR costumer.labplan.southpark.
0.e.a.f.a.4.e.f.f.f.9.2.c.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa.   IN PTR npserver.labplan.southpark.
2.e.e.b.4.b.e.f.f.f.9.2.c.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa.     IN PTR an.labplan.southpark.
6.1.f.8.f.8.e.f.f.f.9.2.c.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa.     IN PTR gw.labplan.southpark.
6.1.f.8.f.8.e.f.f.f.9.2.c.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa.     IN PTR ns6.labplan.southpark.

From this moment on everything should work fine. We can check the name resolution with dig:

# dig @::1 -t AAAA npserver.labplan.southpark
;; QUESTION SECTION:
;npserver.labplan.southpark.    IN      AAAA
 
;; ANSWER SECTION:
npserver.labplan.southpark. 86400 IN    AAAA    fec0::20c:29ff:fe4a:fae0

To check reverse resolution use dig’s -x flag:

#dig @::1 -x fec0::20c:29ff:fe4a:fae0
;; QUESTION SECTION:
;0.e.a.f.a.4.e.f.f.f.9.2.c.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa.INPTR
 
;; ANSWER SECTION:
0.e.a.f.a.4.e.f.f.f.9.2.c.0.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.e.f.ip6.arpa. 259200  IN  PTR  npserver.labplan.southpark.

IPv6 has three types of addresses, which can be categorized by type and scope:

• Unicast addresses. A packet is delivered to one interface.
• Multicast addresses. A packet is delivered to multiple interfaces.
• Anycast addresses. A packet is delivered to the nearest of multiple interfaces (in terms of routing distance).

IPv6 does not use broadcast messages.

Unicast and anycast addresses in IPv6 have the following scopes (for multicast addresses, the scope is built into the address structure):

• Link-local. The scope is the local link (nodes on the same subnet)(FE80::/64).
• Site-local. The scope is the organization (private site addressing)(FEC0::/48).
• Global. The scope is global (IPv6 Internet addresses).

In addition, IPv6 has special addresses such as the loopback address. The scope of a special address depends on the type of special address. Much of the IPv6 address space is unassigned.

One of the most interesting and potentially valuable addressing features imple- mented in IPv6 is a facility to allow devices on an IPv6 to actually configure themselves independently. In IPv4 hosts were originally configured manually. Later, host configuration protocols like DHCP enabled servers to allocate IP addresses to hosts that joined the network. IPv6 takes this a step further, by defining a method for some devices to automatically configure their IP address and other parameters without the need for a server. It also defines a method whereby the IP addresses on a network can be renumbered (changed en masse). These are the sorts of features that make TCP/IP network administrators drool.

The IPv6 autoconfiguration and renumbering feature is defined in RFC 2462, IPv6 Stateless Address Autoconfiguration. The word “stateless” contrasts this method to the server-based method using something like DHCPv6, which is called “stateful”. This method is called “stateless” because it begins from a “dead start” with no information (or “state”) at all for the host to work with, and has no need for a DHCP server.

Stateless autoconfiguration exploits several other new features in IPv6, including link-local addresses, multicasting, the Neighbor Discovery (ND) protocol, and the ability to generate the interface identifier of an address from the underlying data link layer address. The general idea is to have a device generate a temporary address until it can determine the characteristics of the network it is on, and then create a permanent address it can use based on that information. In the case of multi-homed devices, autoconfiguration is performed for each interface separately, as you would expect.

The following is a summary of the steps a device takes when using stateless autoconfiguration:

1. Link-Local Address Generation: The device generates a link-local address. Recall that this is one of the two types of local-use IPv6 addresses. Link- local addresses have “1111 1110 10” for the first ten bits. The generated address uses those ten bits followed by 54 zeroes and then the 64 bit interface identifier. Typically this will be derived from the data link layer (MAC) address as explained in the topic on interface identifiers, or it may be a “token” generated in some other manner.
2. Link-Local Address Uniqueness Test: The node tests to ensure that the address it generated isn’t for some reason already in use on the local network. (This is very unlikely to be an issue if the link-local address came from a MAC address but more likely if it was based on a generated token.) It sends a Neighbor Solicitation message using the Neighbor Discovery (ND) protocol. It then listens for a Neighbor Advertisement in response that indicates that another device is already using its link-local address; if so, either a new address must be generated, or autoconfiguration fails and another method must be employed.
3. Link-Local Address Assignment: Assuming the uniqueness test passes, the device assigns the link-local address to its IP interface. This address can be used for communication on the local network, but not on the wider Internet (since link-local addresses are not routed).
4. Router Contact: The node next attempts to contact a local router for more information on continuing the configuration. This is done either by listening for Router Advertisement messages sent periodically by routers, or by sending a specific Router Solicitation to ask a router for information on what to do next. This process is described in the section on the IPv6 Neighbor Discovery protocol.
5. Router Direction: The router provides direction to the node on how to proceed with the autoconfiguration. It may tell the node that on this network “stateful” autoconfiguration is in use, and tell it the address of a DHCP server to use. Alternately, it will tell the host how to determine its global Internet address.
6. Global Address Configuration: Assuming that stateless autoconfiguration is in use on the network, the host will configure itself with its globally-unique Internet address. This address is generally formed from a network prefix provided to the host by the router, combined with the device’s identifier as generated in the first step. Clearly, this method has numerous advantages over both manual and server-based configuration. It is particularly helpful in supporting mobility of IP devices, as they can move to new networks and get a valid address without any knowledge of local servers or network prefixes. At the same time, it still allows management of IP addresses using the (IPv6- compatible) version of DHCP if that is desired. Routers on the local network will typically tell hosts which type of autoconfiguration is supported using special flags in ICMPv6 Router Advertisement messages.