AToL: Configuration and NAT in IPv6 environment

20.4.2011 17:13 | Přečteno: 1198× | Linux | poslední úprava: 20.4.2011 17:13

Autor: Martin Bukatovič
Nasledovný príspevok je študentskou prácou, ktorá vznikla v rámci predmetu Advanced Topics of Linux Administration. Predmet je vypisovaný na Fakulte informatiky MU v spolupráci so spoločnosťou Red Hat Czech. Vyučovacím jazykom je angličtina a preto je v nej aj nasledovný príspevok. Komentáre k obsahu príspevku sú vítané v ľubovoľnom zrozumiteľnom jazyku.

The standardization process of the new IPv6 protocol has produced many different ideas about how the future network should work. Some of them were rejected after years of discussion while some others were successfully implemented and accepted among the IPv6 community. And even now, more than a decade after the beginning of the standardization process, we are still not sure which way is the right one in many cases. In this article, I'm going to summarize two essential but still unfinished areas of the new protocol: network configuration and possible alternatives to network address translation.

Quick IPv6 overview

Even though the IPv6 shares many common ideas with the IPv4, it is a completely new protocol and can't be considered to be an extension to the older one. Many essential concepts works in a different way and several completelly new features has been introduced.

At first sight the most visible differences compared to the IPv4 are:

• the address length has grown to 16 B
• network interface of particular machine has usually several different addresses
• address types and it's reachability has been redefined

Unicast

A unicast address identifies a single network interface of individual host. It is the most common type of address and it is used to one to one connections. The IP address is divided to 2 main 64 bit parts: the network prefix and the interface identifier. Unlike IPv4, this division can't be easily changed because it would break other IPv6 standards such as address autoconfiguration.

Some well known prefixes of unicast addresses are:

• fe80::/10 - link local addresses
• fc00::/7 - unique local addresses
• 2000::/3 - global individual addresses

Anycast

An anycast address identifies network interface of closest host from particular group. Each anycast address has assigned a scope which limits the area of the network where the address is valid. The scope should be kept small as possible because each router inside it stores individual routing entry for each such address. As a result there are only few anycast addressees with a global scope such as these dedicated to root DNS servers.

Multicast

A multicast address identifies network interfaces of all hosts from a group. This type of address is recognized by having prefix ff00::/8. Moreover unlike IPv4, IPv6 defines 6 different multicast address scopes from link-local to global scope. For example address for all hosts on particular local network is ff02::1 (note that this is equivalent to IPv4 broadcast).

IPv6 configuration

There are several ways to configure host running the IPv6 protocol. The first solution is manual configuration, which can be helpful when setting up router or server machine with static address. For most other uses the new protocol offers several versions of autoconfiguration.

Neighbor discovery

Before going further, it's worth mentioning the neighbor discovery protocol (ND, defined in RFC 4861) which provides:

• translation of link layer addresses (e.g. MAC) to network ones and vice versa
• router discovery (defines how hosts locate routers on the local network)
• autoconfiguration which includes setting up host address and other network parameters
• neighbor unreachability detection
• duplicate address detection
• redirection (defines how router informs a host about better way to reach particular destination)

The protocol defines five ICMPv6 message types which means that unreasonable blocking of ICMPv6 traffic may cause major problems for basic functionality of IPv6 network.

Network to link address

The process of searching the link address is similar to ARP used with IPv4. Special multicast prefix (ff02:0:0:0:0:1:ff00::/104) is dedicated for this purpose.

Let's see what will happen when host A needs to find out the link address of host B (supposing host A knows the IP address of host B):

• Host A creates solicited node address (multicast) of host B using the prefix and the last 24 bits of host's B IP address.
• Host A sends neighbor solicitation (NS) ICPMv6 message with the full address he needs to translate to the solicited node address.
• Each host listens on multicast group for each IP address it has assigned. In most cases there will just one host in particular multicast group, which then checks if the IP address included in the message is assigned to him. This is true for the host B so he replies with neighbor advertisement (NA) ICMPv6 message with corresponding link address. If the address changes, host can also send this message without prior NS message.
• Host A receives the NA message with the address and stores it in it's neighbor cache.

Link to network address

If a host needs to know an IP address for particular link address, the host will create NS message with appropriate link address while the IP address will be specified to ff02::1, which is a multicast group for all hosts on the local network.

Autoconfiguration and DHCPv6

Automatic configuration basically means that the host is able to generate and assign it's own IP address based on information received from router on the local network without any other help. This method uses a fact that local router already knows all the needed network parameters such as mtu, network address prefix and so on.

The group of last 64 bits of IP address (interface identifier) which is unique for the host on particular local network can be:

• generated by the host itself from it's link address (IPv6 EUI-64, RFC 4291)
• generated by the host itself as random identifier (privacy extensions, RFC 4941)
• created by cryptographic protocol using secure alternative to neighbor discovery (SEND, RFC 3971)
• assigned from DHCPv6 server

Stateless configuration

This is the simplest autoconfiguration method. In this scenario the host will:

• create link local IP address
• check if the link local address is already in use, in case of conflict the autoconfiguration will fail and the network interface will be disabled
• assign itself the link local address
• receive router advertisement ICMPv6 message (by waiting or sending router solicitation message) with configuration for this network (network prefixes, default gateway, mtu, ...)
• assign itself another IP address for each received network prefix with A flag set to 1

As a result if there is no prefix with flag A enabled, the autoconfiguration is disabled and host ends up with just link local address. If there is no IPv6 router available, the host will just try to assign itself the link local address.

The router advertisement message also contains 2 flags which instruct the host which configuration method to use. Besides already mentioned stateless configuration method there are 2 other possibilities:

• DHCPv6 (former statefull configuration) - host uses DHCPv6 server
• stateless DHCPv6 - the combination of both previous options

DHCPv6

The configuration process with DHCPv6 is the same as with stateless autoconfiguration although the last step may be omitted and the DHCPv6 server is contacted using well known multicast address. The protocol also assumes the host has assigned valid link local address because the communication already takes place over IPv6. And sice the DHCPv6 server doesn't provide information about the default gateway, this method has to be used in combination with autoconfiguration.

DNS and IPv6

The information about DNS servers can be provided by either DHCPv6 server or router advertisement message during autoconfiguration. Nevertheless the RFC 6106 which describes the way how to obtain addresses of the DNS servers during stateless autoconfiguration is quite new with just few experimental implementations. As a result the DHCPv6 is the only working way to get this information.

Network address translation

The primary purpose of the NAT mechanism is to reduce usage of network addresses. Since the sheer number of IPv4 addresses is insufficient considering the current demand, this solution is ubiquitous and unenviable.

NAT in the IPv4 environment

In general, NAT is a process translating addresses of machines from private subnet to limited set of public addresses (often just one). This way the local machines are able to establish connections directed to the Internet without having it's own global IP addresses. For the same reason this process makes the connections in the opposite direction impossible with various consequences:

• Good: a little increase in the security for the machines hidden behind NAT. Nevertheless NAT was not designed with security in mind. Thus without proper additional security measures, it rather gives the users false sense of security.
• Bad: breaks end to end communication protocols. These protocols supposes that hosts are able to connect to each other which is impossible with one of the host behind NAT without global public address.
• Ugly: some protocols (e.g. FTP) sends IP addresses in the data section of the packet. Machine providing NAT functionality has to understand the inner structure of packet to be able to translate the address properly.

Emulation of some NAT features in IPv6

What started as a workaround to overcome the size of address space is now shaping our thinking about the way how the network should be run. This leads to an effort to find methods to bring some benefits of NAT to the IPv6 environment without introducing the same mechanism into IPv6 itself.

Changing the ISP

The address space of network hidden behind NAT is independent of the service provider's address space making a switch to another ISP much easier. Without renumbering, there is no need to reconfigure any machine with exception of the NAT server.

Obvious IPv6 solution is to use unique local addresses and store them in local DNS server. These addresses are valid only inside our network and will be preserved when the service provider is changed. Thus there is no need for renumbering them. The problem is that each node needs another global address at the same time. On the one hand the autoconfiguration combined with DHCPv6 makes renumbering of client hosts seamless on the other hand reconfiguration of servers dealing with IP addresses such as firewalls, DNS servers or IDS systems still requires significant effort.

Another solution might be the network prefix translation (NPTv6, previously called NAT66). Unlike IPv4 NAT, NPTv6 changes just a network prefix of an address making local machine accessible from the outside world. However the problem with protocols sending addresses outside the IP header still remains. Apart from that, the protocol is still not standardized thus there are just few experimental implementations.

Multihoming

The local address space also helps when the network is connected to the Internet via several independent providers at the same time. The provider independent address space (PI) works with both versions of the internet protocol, but it's targeted only to big organizations.

More accessible solution might be the shim6 protocol. The basic idea behind this solution is that the protocol monitors global communication and ISP accessibility. In the case of primary ISP failure the connections are redirected to another ISP using methods borrowed from the mobility support. Unfortunately there are no stable implementations yet.

Privacy

Because of the fact that the IPv6 host identifier is based on MAC address, it's possible to track users even across different networks. The answer to this issue are the privacy extensions for stateless address autoconfiguration. When enabled, the host generates additional random host id with a priority over addresses assigned by other methods. The new address is used only for a short period of time (from hours to days) and when the address expires another random identifier is generated. Since this address is not stored in the DNS, it's not possible to do a reverse DNS lookup which can cause problems because some servers refuse to grant access to clients without proper DNS name. The effort to protect privacy of individual nodes conflicts with the effort to maintain the whole network. Therefore proper monitoring service logging the usage of temporary addresses should be used.

RFC

• http://tools.ietf.org/html/rfc4193
• http://tools.ietf.org/html/draft-mrw-nat66-12
• http://tools.ietf.org/html/rfc5902
• http://tools.ietf.org/html/rfc4864
• http://tools.ietf.org/html/draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-00
• http://tools.ietf.org/html/rfc4861
• http://tools.ietf.org/html/rfc4007
• http://tools.ietf.org/html/rfc4941

       

Komentáře

[IPv6]

Az átállás az IPv4-ről IPv6-ra nem tud az egész Interneten egy időben lezajlani, ezért szükséges, hogy a két rendszer egymás mellett működhessen, akár az Interneten vagy a gépen belül is. Ezt az átmenetet a kompatibilis címek (az IPv4 címek egyszerűen átalakíthatók IPv6-címekké), és a különféle alagutak alkalmazása biztosítja. Használható egy kettős protokollcsomag, (dual stack IP ) nevű technika is, amely mindkét protokollt egy időben támogatja. A két teljesen különálló hálózati alrendszer és a két különböző protokollverzió nincs hatással egymásra.

[AsciiWolf]

Jdi do prdele s tím trollingem.

Pokud ti dělají problémy základy technické angličtiny, nechápu, proč navštěvuješ tento portál a ne technet, zive a podobné portály, určené pro jedince, jako jsi ty.

[Zdeněk Burda]

Netušil jsem, že podmínkou pro čtení abclinuxu.cz je znalost angličtiny...

[AsciiWolf]

Není, nicméně dle mého názoru je alespoň elementární znalost technické angličtiny nutnost, pokud chce člověk jako "IT profesionál" obstát.

A osobně si myslím, že velkou část návštěvníku ábíčka tvoří právě lidé, pracující v IT, druhá velká část jsou "geekové".

Obě tyto skupiny by dle mého názoru s angličtinou, minimálně na technické úrovni, neměly mít problém.

p.s. A ruku na srdce. Vás ti místní trollové neštvou?

[pavlix]

Není, nicméně dle mého názoru je alespoň elementární znalost technické angličtiny nutnost, pokud chce člověk jako "IT profesionál" obstát.

Podle mě jsou zase základy slušného chování elementární znalost, pokud nechce člověk působit jako nevychované hovádko :).

A osobně si myslím, že velkou část návštěvníku ábíčka tvoří právě lidé, pracující v IT, druhá velká část jsou "geekové".

Nicméně ABCLinuxu nemá vstupní formulář k odsouhlasení geekovství (jako mají některé jiné weby odsouhlasení věku) ani znalost angličtiny.

p.s. A ruku na srdce. Vás ti místní trollové neštvou?

Ano, štvete mě :).

[Marek 'marx' Grác]

Myslím, že v úvode (a x-krát predtým v tomto blogu) je vysvetlené, prečo sú texty v angličtine. A práve to, či študenti dokážu napísať text, ktorý má hlavu a pätu anglicky je potrebné zistiť. Verím, že podľa názvu nie je problém klikať len na vhodné blogy (prípadne si tento rovno zablokovať).

Bývalá redakcia mi publikovanie tohoto blogu v angličtine odsúhlasila. A ďalšie študentské práce budú nasledovať, takže koho to štve nech si blog zablokuje.

[pavlix]

Myslím, že v úvode (a x-krát predtým v tomto blogu) je vysvetlené, prečo sú texty v angličtine. A práve to, či študenti dokážu napísať text, ktorý má hlavu a pätu anglicky je potrebné zistiť. Verím, že podľa názvu nie je problém klikať len na vhodné blogy (prípadne si tento rovno zablokovať).

Mně to neříkej :).

Bývalá redakcia mi publikovanie tohoto blogu v angličtine odsúhlasila. A ďalšie študentské práce budú nasledovať, takže koho to štve nech si blog zablokuje.

Já čtu anglicky víc než česky, a angličtina v blogu mi vůbec nevadí. Navíc je to uvedeno česky, což taky chválím.

Reagoval jsem na AsciiWolfa a na to co psal.

[AsciiWolf]

Ano, štvete mě :).

Já netrolluju. Kdybych trolloval, vypadá to jinak.

[pavlix]

To záleží na úhlu pohledu :).

[AsciiWolf]

Podle mě jsou zase základy slušného chování elementární znalost, pokud nechce člověk působit jako nevychované hovádko :).

Jestli narážíš na slovo "prdel", máš pravdu, trochu jsem to přehnal. Měl jsem místo vulgarity použít něco jiného.

Jen mne prostě už štve, že pod každým blogem či článkem člověk nalezne hromadu voidů, fredů, Woknařů a ostatních anonymních individuí.

[pavlix]

Jestli narážíš na slovo "prdel", máš pravdu, trochu jsem to přehnal. Měl jsem místo vulgarity použít něco jiného.

Jazyk nezná sprostá slova... takže o prdel jako takovou mi fakt nejde :).

Jen mne prostě už štve, že pod každým blogem či článkem člověk nalezne hromadu voidů, fredů, Woknařů a ostatních anonymních individuí.

Já jsem se s nima tak nějak sžil :). Ten první příspěvek mě náhodou i docela pobavil, ačkoli jsem mu vůbec nerozuměl (nebo spíš proto).

Woknař je úsměvná postavička, o kterym vůbec nevíš, co to je ve skutečnosti za člověka. Prezentuje se tu jako až neuvěřitelnej blb, takže ho trochu podezřívám z hulánovství.

Ale to tvrzení, že každej (nebo skoro každej) návštěvník Abclinuxu musí umět anglicky, to je totální volovina.

[Käyttäjä 11133]

To je podmínka pro libovolný odborný portál z oblasti IT, ne? :)

[Zdeněk Burda]

Abclinuxu nepovažuji jako odborný portál z oblasti IT, poslední dobou se sem sem tam kouknu jako na zábavný web (nebo spíš ?)

[RoboShim]

K tomu NATu. NAT by nemel byt treba, pokud si firma zazada o vlastni sit (/64). Pak bude mit porad stejnou a pri zmene ISP by se zmenily pouze routovaci tabulky do firemni site. Bohuzel, kdyz se firma nacpe k "ISP", ktery prideluje pouze jedno IPcko na zakaznika, tak ma samozrejme nasledne problem. Kazda normalni firma by mela pouzivat skutecne ISP.

A nebo pouzivat IPsec nekam do Internetu.

[marbu]

K tomu NATu. NAT by nemel byt treba, pokud si firma zazada o vlastni sit (/64). Pak bude mit porad stejnou a pri zmene ISP by se zmenily pouze routovaci tabulky do firemni site.

Tomuhle se rika Provider-independent address space. Ale tezko se to da povazovat za univerzalni a dostupne resini, protoze to zvysuje zatez globalnich smerovacu a tak si to muze dovolit jen opravdu velka firma.

[Ondrej 'SanTiago' Zajicek]

To michas do sebe dve neprilis souvisejici veci - pokud firma dostane vlastni sitovy prefix (treba /64 nebo i vetsi), tak obvykle z rozsahu sveho ISP a takova sit je pak dostupna jen pres daneho ISP a pri zmene ISP ty adresy musi prestat pouzivat. Je mozne tedy zazadat i o provider independent adresy, ale ty se pouzivaji dost malo. Zaprve - alespon pro IPv4 - za ne RIPE chce dost vyrazne poplatky, zadruhe je (AFAIK) nedostanete pokud neprovozujete alespon multihoming (najednou pripojeni pres vic ISP) a navic je to narocnejsi na administaci (nestaci jen default routa, je treba provozovat BGP router na hranici s IPS).

[petr_p]

Traktát by měl větší informační hodnotu, kdyby jednotlivé závěry (žádná stabilní implementace shim6, nepodpora RDNSS) byly podloženy (alespoň názvem implementace), jinak si laskavý čtenář nebude moci za půl roku ověřit, zda tomu tak stále je.