IPv4-IPv6 primo step per la transizione del datacenter

Introduzione

Internet Protocol version 6 è forse uno dei protocolli più descritti della storia informatica e questo documento vuole essere una sintesi delle caratteristiche principali per familiarizzare con le sue specificità e cominciare a introdurre questo potentissimo strumento.

IPv6, pur essendo nato per risolvere le limitazioni del protocollo IPv4, incontra delle difficoltà notevoli di adozione nel mondo reale e questo a causa della enorme diffusione che il protocollo IPv4 ha avuto nel corso di questi anni.

Noi pensiamo che sia giunto il momento di cominciare ad utilizzare questo formidabile strumento che, proprio per queste ragioni, ha avuto un tempo di affinazione che non tutte le tecnologie si possono permettere.

In questa prima stesura di questo documento non approfondiremo volutamente le caratteristiche di basso livello del protocollo, già ampiamente trattate in Internet, ma ci concentreremo su alcune peculiarità del protocollo e soprattutto nelle modalità di adozione della tecnologia in ambienti mission-critical e business-critical.

Perché IPv6

La prima domanda che chiunque abbia mai approcciato la tecnologia IPv6 si è posto è:

Perché IPv6 ?

La nostra risposta è che l'adozione di IPv6 Semplifica.

Come tutte le tecnologie anche IPv6 deve essere inizialmente compreso per essere apprezzato. L'approccio per apprezzare IPv6 è nella comprensione del suo utilizzo prima che nella comprensione del suo funzionamento.

L'introduzione estesa di IPv6, in un mondo pensato e compiutamente realizzato in IPv4, è sicuramente una introduzione lenta. Il numero di applicazioni "client" e apparati ancora non IPv6 compliant sono moltissimi e sinceramente alla data attuale (19 luglio 2012) non mi sentirei di consigliare ad un sito di e-commerce di avere come unico IP pubblico un IPv6! Contrariamente, in un datacenter, con centinaia o addirittura migliaia di macchine virtuali, penso che la scelta di utilizzare IPv6 sia un facilitatore.

Obiettivo

Il problema che vogliamo risolvere è la cronica carenza di indirizzamento IP della nostra server farm che cresce a ritmi vertiginosi grazie anche alla virtualizzazione e all'immensa potenza che oggi i server ci mettono a disposizione.

Non vogliamo da subito trasformare la nostra server farm completamente in IPv6 ma vogliamo prima familiarizzare con il protocollo e quindi, una volta comprese le potenzialità, estenderne l'utilizzo.

Identifichiamo quindi un possibile servizio da erogare in IPv6 e cominciamo a fare le prime considerazioni e le verifiche preliminari.

L'obiettivo è riuscire ad accedere via IPv4 e IPv6 avendo come backend un pool di servizi attestati su IPv6. L'indirizzamento IPv4 e IPv6 sarà reso disponibili ai client attraverso VIP.

Valutazione dell'ambiente

La prima valutazione deve essere rivolta all'ambiente su cui abbiamo fatto ricadere la scelta di provare l'erogazione dei servizi in IPv6. Non mi dilungherò sui sistemi operativi perché ormai tutti quelli oggi disponibili mettono a disposizione la possibilità di utilizzare sia IPv4 sia IPv6. Per i nostri esempi utilizzeremo indifferentemente MS Windows, Linux e Solaris contemporaneamente.

Il nostro progetto, prevalentemente di servizi erogati da un datacenter, prevede di utilizzare alcune componenti come web server e application server. L'accertamento deve quindi tendere a verificare se i web server o gli application server utilizzati prevedano o quanto meno non escludano l'utilizzo di IPv6.

Tendenzialmente le componenti server come application server e web server, mantenute aggiornate, prevedono l'utilizzo dei protocolli IPv4 e IPv6. Se non si dovesse trovare documentazione per eseguire i primi test non resta che provare. In ambienti mission-critical o business-critical si consiglia vivamente di consultare il produttore.

Tutte le applicazioni scritte con linguaggi nati per la rete, come ad esempio Java, prevedono l'utilizzo di classi di utilizzo dei Socket con indirizzamento IPv4 o IPv6 es.:

java.lang.Object

extended by java.net.InetAddress

extended by java.net.Inet4Address

extended by java.net.Inet6Address

Questo ovviamente non è sufficiente in caso di applicazioni mission-critical o business-critical ma per effettuare i primi test è sufficiente.

128 bit di indirizzamento

Uno dei primi obiettivi di questo capitolo è capire come utilizzare i 128 bit del protocollo IPv6. I 128 bit, espressi a gruppi di 16 bit per facilitare il computo esadecimale, sono stati concepiti per essere indirizzamenti parlanti e di seguito una prima rappresentazione della loro suddivisione a livello globale (Aggregate Table Global).

Questa è la rappresentazione che viene utilizzata per assegnare identificativi "parlanti" e suddividere in parti logiche l'indirizzo i 128 bit. E' importante memorizzarla per insiemi in quanto, come vedremo in seguito, questa suddivisione logica potrà essere utilizzata, in tutto o in parte, anche per gli indirizzamenti all'interno del datacenter conferendo ordine e leggibilità.

Altra nota la riserviamo ai primi 16 bit. Questi contengono le informazioni essenziali per effettuare il riconoscimento dei pacchetti e determinare la loro tipologia. La tabella di seguito sintetizza le categorie di indirizzi.

Le categorie dell'indirizzamento IPv6 si possono di seguito raggruppare in indirizzi di tipo:

• Unicast: indirizzi di nodi

• Multicast: indirizzi di gruppi di nodi

• Anycast: indirizzi di servizi, come gli indirizzi multicast identificano un gruppo di nodi. Diversamente dai multicast, i pacchetti saranno consegnati al nodo più vicino (in base alle metriche presenti sui router) rispetto al nodo mittente

Di seguito, riprendendo l'ultima tabella, andremo a dettagliare il singolo utilizzo per insieme.

Unicast

In linea generale gli indirizzi IPv6 sono stati pensati per una suddivisione logica composta da due parti : Subnet prefix e Host identifier.

Il Subnet prefix, chiamato anche netmask, identifica la rete di appartenenza. Il Subnet prefix è espresso in numero di bit da sinistra verso destra dell'indirizzo IPv6.

Di norma l''indirizzamento a 128 bit viene utilizzato con Subnet prefix di 64 bit lasciando i restanti 64 bit per l'identificazione dei singoli apparati.

Il prefisso di rete (primi 64 bit)

L'interface ID (ultimi 64 bit)

XXXX:XXXX:XXXX:XXXX: XXXX:XXXX:XXXX:XXXX

Subnet prefix (64bit) Host identifier (64bit)

L'host può essere identificato manualmente o tramite l'identificativo di interfaccia (mac address): il mac address viene ricalcolato per essere usato come parte host dell'indirizzo IPv6 -EUI 64.

Il formato EUI EUI-64

• L'interface ID:

  • Identifica univocamente un'interfaccia

  • Deve essere univoco su un link

  • Può essere ricavato a partire dall'identificatoreEUI-64

• L'identificatore EUI-64 si basa sullo stesso principio del MAC Addressd cui è l'evoluzione:

  • Identifica il produttore ed il «numero di serie» di un'apparecchiatura (con 64 bit)

  • Esiste una procedura che consente di passare dall'EUI-48 ID (mac-address) all'EUI-64 ID (si rimanda all'abbondante documentazione in Internet)

Multicast (FF00-FFFF range)

Il Multicast identifica messaggi che devono essere propagati uno --->> a molti.

Differentemente dal Multicast IPv4 il Multicast IPv6 sostituisce il TTL con lo "Scoped Address" che ne determina gli ambiti di propagazione.

Il formato dello "Scoped Address" è così composto:

FF<flags><scope>::<group id>

• FF=Identificativo Multicast

• flag= 0 permanente, 1 temporaneo. Per definizione, sono temporanei tutti gli indirizzi non allocati staticamente da IANA. Sono a disposizione 120 bit per provare schemi di indirizzamento differenti.

• Scope

  • 1 node-local

  • 2 link-local

  • 5 site-local

  • 8 organization-local

  • E global

• group id=identificatore all'interno di uno scope

Nei nostri esempi questo indirizzamento verrà utilizzato come strumento per le procedure di lookup-discovery e per il mantenimento dei lease time dei nodi del cluster attraverso l'HeartBeat.

Anycast

Gli indirizzi Anycast, non distinguibili da un FP specifico, sono indirizzi assegnati ad un insieme di interfacce, di solito appartenenti a nodi diversi. Deve essere esplicitamente indicato che si sta assegnando un indirizzo Anycast.

Gli indirizzi Anycast identificano il server più vicino al mittente e possono essere utilizzati come fail-over nel caso non fosse disponibile il più vicino. Alcuni indirizzi Anycast sono stati riservati per utilizzi specifici come Router e Mobile IPv6 home-agent discovery.

Scelta dell'indirizzamento interno

Per l'indirizzamento interno al datacenter andremo quindi ad utilizzare il tipo di indirizzamento Unicast dovendo identificare precisamente una risorsa. Non volendo essere dipendenti da un indirizzamento composto dall'interfaccia di rete ma volendo orientare l'indirizzamento ai servizi utilizzeremo un indirizzo di classe: FC00 FDFF Unique local unicast.

Con i prefissi espressi dal range FC00-FDFF costruiremo un indirizzamento "parlante" in modo da identificare immediatamente il segmento della rete a cui ci stiamo riferendo.

L'indirizzamento FC00 FDFF Unique local unicast viene così dettagliato:

| 7 bits |1| 40 bits | 16 bits | 64 bits |

+--------+-+------------+-----------+----------------------------+

| Prefix |L| Global ID | Subnet ID | Interface ID |

+--------+-+------------+-----------+----------------------------+

Prefix FC00::/7 prefix identifica localmente un unicast addresses IPv6.

L Set a 1 è assegnato localmente

Set a 0 per un utilizzo futuro

Global ID 40-bit global identifier usato per creare un global unique prefix.

Subnet ID 16-bit Subnet ID è l'identificatore della subnet all'interno del site.

Interface ID 64-bit Interface ID as defined in [ADDARCH].

Per dare prova dell'utilizzo del Subnet Prefix (aka Netmask) negli esercizi che seguiranno utilizzeremo un Subnet Prefix di 48 bit destinando i rimanenti 80bit all'identificatore dell'host.

L'impostazione del Subnet prefix avviene al momento del set dell'indirizzo aggiungendo uno slash e il valore dei bit della subnet nella parte terminale:

es. Solaris: ifconfig e1000g3:1 inet6 fd00:cc:c9:5::/48 up

Linux: ifconfig eth3 inet6 add fd00:cc:c9:4::/48 up

MS Windows: netsh interface ipv6 add address LBLMonitor addr=fd00:cc:c9:2::/48

es.1 Il prefisso di rete (primi 48 bit)

L'host ID (ultimi 80 bit)

XXXX:XXXX:XXXX:XXXX: XXXX:XXXX:XXXX:XXXX

Subnet prefix (48bit) Host identifier (80bit)

In questo esempio utilizzeremo quindi un netmask di 48 bit più che sufficiente a dimostrare l'utilizzo del netmask, non soggetto a vincoli ad esclusione dei primi 16 bit che identificano il tipo di indirizzo.

Supponiamo quindi di avere una organizzazione degli indirizzi che possano esprimere la nostra rete:

# fd00:c9:c9:1::

# | | | | |

# | | | | +---- host locale

# | | | +-------host group

# | | +----------network group c9=public ca=private
cb=backend cc=management

# | +-------------primary group

# +---------------address type (unique link local
unicast)

Questo tipo di indirizzamento ci permette in un solo istante di identificare a quale rete ci si sta riferendo es.:

fd00:c9:c9:1:: si riferisce alla rete pubblica

fd00:ca:c9:1:: si riferisce alla rete privata

fd00:cb:c9:1:: si riferisce alla rete di backend

fd00:cc:c9:1:: si riferisce alla rete di management

Vogliamo porre in evidenza che la suddivisione è completamente arbitraria e limitata solo dall'utilizzo del Subnet prefix (netmask) che identifica lo "scope" della nostra rete nei primi 48 bit. Il nostro indirizzo ha quindi un Subnet prefix di /48 bit, tutto quello che sta oltre il 48° bit identifica la risorsa, il punto di erogazione del servizio.

Di seguito riportiamo per Linux e MS Windows e Solaris degli snap che riportano un ipotetico server con indirizzamento IPv6:

Piano degli indirizzi

Per questo piano di indirizzamento prevediamo quindi quattro tipologie di rete:

VIRTUALE PUBBLICA PRIVATA BACK-END MANAGEMENT

Per la rete VIRTUALE predisporremo sia un indirizzo IPv4 (192.168.43.10) sia un indirizzo IPv6 (fd00:c9:c9:a::/48). Questo permetterà di porre lo strato di instradamento in grado di "ascoltare" sia in IPv4 sia in IPv6 dando la possibilità ai client di accedere indifferentemente da IPv4 o IPv6 alle stesse risorse attestate unicamente in IPv6.

Duplicate Address Discovery and High Availability

Per porre in alta affidabilità un indirizzo IP è necessario far migrare l'indirizzo da un nodo ad un altro nodo. IPv6 introduce il servizio Duplicate Address Discovery (aka DAD) che permette, in situazioni normali, di individuare la duplicazione dell'indirizzamento e disabilita in automatico l'indirizzo duplicato. Questa funzionalità, utile per i client, deve essere disabilitata per le interfacce di rete che si utilizzano come supporto all'alta affidabilità (VIP) perché potrebbero causare la disattivazione dell'indirizzo durante la migrazione.

La modalità di disattivazione è diversa su ogni sistema operativo e di seguito ne verrà data una spiegazione con esempi per MS Windows, Linux e Solaris.

MS Windows:

Con MS Windows (Windows Vista / Server 2008 or Windows 7 / Server 2008 R2 o superiori) è possibile disabilitare il servizio IPv6 DAD attraverso il comando netsh. La procedura prevede di ricavare l'indice del NIC e quindi disattivare il servizio.

1-Rilevazione dell'indice del NIC:

C:> netsh interface ipv6 show interfaces

Idx Met. MTU Stato Nome

--- ---------- ---------- ------------
---------------------------

1 50 4294967295 connected Loopback Pseudo-Interface 1

14 25 1500 connected Connessione rete wireless

10 20 1500 connected LBLPublic

17 50 1280 disconnected isatap.{A7670B47-0AAE-4DAC-9BE5-

25 50 1280 disconnected isatap.homenet.telecomitalia.it

15 50 1280 disconnected Teredo Tunneling Pseudo-Interface

12 50 1477 disconnected Connessione di rete Bluetooth

27 50 1280 disconnected isatap.{278375D9-F269-47C8-BEF2-

21 20 1500 connected VirtualBox Host-Only Network

***2-Disattivazione del servizio DAD per l'interfaccia individuata:***

C:> netsh interface ipv6 set interface "10" dadtransmits=0

OK.

***3-Verifica dell'avvenuta disattivazione:***

C:> netsh interface ipv6 show interface "10"

Parametri LBLPublic interfaccia

----------------------------------------------

IfLUID : ethernet_6

IfIndex : 10

Stato : connected

Metrica : 20

MTU collegamento : 1500 byte

Tempo raggiungibile : 18500 ms

Tempo raggiungibile base : 30000 ms

Intervallo di ritrasmissione : 1000 ms

**Trasmissioni DAD : 0**

Lunghezza prefisso sito : 64

ID sito : 1

Inoltro : disabled

Annunci : disabled

Individuazione router adiacenti : enabled

Rilevamento irraggiungibilità router adiacenti : enabled

Individuazione router : enabled

Configurazione indirizzi gestiti : enabled

Altre opzioni di configurazione con stato : enabled

Invii host vulnerabile : disabled

Ricezioni host vulnerabile : disabled

Utilizza metrica automatica : enabled

Ignora route predefinite : disabled

Durata router annunciato : 1800 secondi

Annuncia route predefinita : disabled

Limite di hop corrente : 0

Forza modelli di attivazione ARPND : disabled

Modelli di attivazione MAC indirizzati : disabled

LINUX:

Per disabilitare la funzionalità DAD in Linux si deve identificare il nome dell'interfaccia attraverso il comando ifconfig -a quindi impostare i parametri:

net.ipv6.conf.<interface_name>.dad_transmits

net.ipv6.conf.<interface_name>.accept_dad

L'impostazione dei parametri è consigliabile eseguirla allo startup del sistema aggiungendo ad esempio al file /etc/sysctl.conf le seguenti righe (esempio con eth0):

net.ipv6.conf.eth0.dad_transmits = 0

net.ipv6.conf.eth0.accept_dad = 0

Dopo aver riavviato il sistema operativo verificare se l'impostazione è stata effettivamente recepita attraverso il comando:

sysctl net.ipv6.conf.eth0.accept_dad

net.ipv6.conf.eth0.accept_dad = 0

sysctl net.ipv6.conf.eth0.dad_transmits

net.ipv6.conf.eth0.dad_transmits = 0

Oracle SOLARIS:

Solaris utilizza un algoritmo DAD impostato per default ad Optimistic (vedere Oracle^®^ Solaris Administration: IP Services e Solaris IP Duplicate Address Detection

James Carlson). Per l'utilizzo delle funzionalità di HA abbiamo disabilitato, per le interfacce e per gli indirizzi specifici, la trasmissione della rilevazione dell'indirizzamento duplicato.

Per eseguire questa operazione è sufficiente agire nei parametri del daemon ndp e impostare la disabilitazione attraverso la variabile DupAddrDetectTransmits.

Con un editor aggiungere al file /etc/inet/ndpd.conf i seguenti comandi per ogni interfaccia di gestione dell'indirizzamento virtuale:

if e1000g0:3 DupAddrDetectTransmits 0

prefix fd00:c9:c9:a::/48 e1000g0:3

Al termine dell'impostazione dei parametri eseguire il seguente comando per l'aggiornamento del daemon:

# pkill -HUP in.ndpd

Setup Sistema operativo Jessica

Il setup di Jessica lo effettueremo in un sistema operativo Linux dove saranno impostate 4 interfacce di rete. Abbiamo utilizzato una distribuzione Ubuntu con kernel revisone 3. Per comodità abbiamo lasciato commentate le vecchie interfacce IPv4. Per abilitarle è sufficiente togliere i commenti. L'interfaccia di monitor (aka management) è stata posta in un alias avendo voluto utilizzare la quarta interfaccia di rete (eth3) per uscire verso Internet (utile nel setup iniziale, verrà disabilitato in produzione):

FILE: /etc/networks/interfaces

This file describes the network interfaces available on your system and how to activate them. For more information, see interfaces(5). The loopback network interface

auto lo

iface lo inet loopback

The primary network interface

auto eth0

#iface eth0 inet static

# address 192.168.43.110

# netmask 255.255.255.0

iface eth0 inet6 static

address fd00:c9:c9:4::/48

The private network interface

auto eth1

#iface eth1 inet static

# address 192.168.44.110

# netmask 255.255.255.0

# up route add -net 224.0.0.0 netmask 240.0.0.0 dev eth1

iface eth1 inet6 static

address fd00:ca:c9:4::/48

The backend network interface

auto eth2

#iface eth2 inet static

# address 192.168.45.110

# netmask 255.255.255.0

iface eth2 inet6 static

address fd00:cb:c9:4::/48

The management network interface

auto eth2:0

iface eth2:0 inet static

address 192.168.46.110

netmask 255.255.255.0

iface eth2 inet6 static

address fd00:cc:c9:4::/48

The internet network interface

auto eth3

iface eth3 inet dhcp

#pre-up /sbin/ifconfig $IFACE mtu 1300

#iface eth1 inet static

# address 192.168.46.110

# netmask 255.255.255.0

Dopo aver effettuato un reboot eseguendo ifconfig -a si dovrebbe ottenere questa configurazione:

Setup Sistema operativo Roger Rabbit

L'installazione di RogerRabbit è analoga all'installazione di Jessica. Se siamo in ambiente virtualizzato si potrebbe procedere al clone della macchina virtuale e quindi si procederà alla modifica dell'hostname e degli indirizzi statici. Anche in questo caso è stato utilizzato un alias come indirizzo di management per poter assegnare via dhcp la scheda di rete eth3 e quindi accedere verso Internet. Quest'ultimo indirizzo, comodo nel setup iniziale, verrà disabilitato in produzione.

FILE: /etc/networks/interfaces

This file describes the network interfaces available on your system and how to activate them. For more information, see interfaces(5).

The loopback network interface

auto lo

iface lo inet loopback

The primary network interface

auto eth0

#iface eth0 inet static

# address 192.168.43.109

# netmask 255.255.255.0

iface eth0 inet6 static

address fd00:c9:c9:3::/48

The private network interface

auto eth1

#iface eth1 inet static

# address 192.168.44.109

# netmask 255.255.255.0

# up route add -net 224.0.0.0 netmask 240.0.0.0 dev eth1

iface eth1 inet6 static

address fd00:ca:c9:3::/48

The backend network interface

auto eth2

#iface eth2 inet static

# address 192.168.45.109

# netmask 255.255.255.0

iface eth2 inet6 static

address fd00:cb:c9:3::/48

The management network interface

auto eth2:0

iface eth2:0 inet static

address 192.168.46.109

netmask 255.255.255.0

iface eth2 inet6 static

address fd00:cc:c9:3::/48

The internet network interface

auto eth3

iface eth3 inet dhcp

#pre-up /sbin/ifconfig $IFACE mtu 1300

#iface eth1 inet static

# address 192.168.46.109

# netmask 255.255.255.0

Dopo aver effettuato un reboot di rogerrabbit ed eseguendo ifconfig -a si dovrebbe ottenere questa configurazione:

Setup Oplon Application Delivery Controller Jessica

Per semplicità utilizzeremo dei commenti a degli snap della management console delle parti più significative.

Il vrrpserver, attestato nella rete privata, è un server HTTP e serve a scambiare le informazioni di routing tra i nodi Oplon Application Delivery Controller. L'indirizzo IPv6 è quello relativo alla rete di HeartBeat privata.

[fd00:ca:c9:4::]

In systemsmonitor_m è interessante notare che è possibile indicare indirizzi virtuali (VIP) IPv4 e IPv6 in maniera molto semplice. Oplon Application Delivery Controller distingue automaticamente gli indirizzi IPv6 dagli IPv4 attraverso la loro peculiare definizione e quindi imposta di conseguenza le network card opportunamente.

Altra cosa da notare è che per Linux gli indirizzi IPv6 possono essere aggiunti alla definizione della Network Card direttamente senza la necessità di utilizzare degli alias come avviene per IPv4.

La configurazione del collettore delle statistiche, se embedded, non deve essere modificata. Se si dovesse utilizzare un broker centralizzato IPv6 il parametro remoteServerURL dovrà essere modificato come di seguito:

Esempio di remoteServerURL IPv6:

LBL_GLOBAL_ADDRESS_BROKERWEBCACHE=[fd00:cb:c9:6::]

Con il file di lookup si istruisce Oplon Application Delivery Controller ad effettuare il lookup discovery degli altri nodi attraverso la rete privata di HeartBeat. Come per IPv4 LBL esige di indicare l'indirizzo dell'interfaccia dove sarà effettuato il multicast o UDP per non propagare i messaggi su tutte le reti. L'indirizzo multicast o UDP utilizzato è comunque di tipo link-local e quindi avente come scope la lan.

Siamo finalmente giunti al file di configurazione dell'instradamento e bilanciamento. Nel paragrafo <listeners> si può osservare una novità e cioè la possibilità d indicare più indirizzi di listening relativi ad uno stesso bind. In questo caso ci permette di impostare nello stesso paragrafo <bind> sia indirizzi IPv4 che indirizzi IPv6.

Nel paragrafo riservato agli <endpoints> è possibile osservare come si indicano le risorse dove sono attestati i servizi.

Come per l'IPv4 il servizio di HealthCheck non è influenzato da cambiamenti essendo un servizio di loopback ad uso del sistema di fail-over dei nodi Oplon Application Delivery Controller.

Setup Oplon Application Delivery Controller Roger Rabbit

Nella stessa maniera di Jessica di seguito andremo a dettagliare il setup della componente di instradamento Oplon Application Delivery Controller. Le impostazioni sono identiche per la componente di instradamento IPv6 gateway. Sono ovviamente tipizzate per le componenti relative al nodo.

Il vrrpserver è un servizio HTTP che, attraverso la rete privata di HeartBeat, scambia le informazioni di instradamento tra i nodi del cluster di bilanciamento.

Come per Jessica il file di lookup istruisce Oplon Application Delivery Controller ad effettuare il lookup discovery degli altri nodi attraverso la rete privata di HeartBeat. Come per IPv4 LBL esige di indicare l'indirizzo dell'interfaccia dove sarà effettuato il multicast UDP per non propagare i messaggi su tutte le reti. L'indirizzo multicast UDP utilizzato è comunque di tipo link-local e quindi con scope la lan.

Start del servizio Tomcat

Lo start del servizio Tomcat verrà in questo caso effettuato su un server MS Windows per permettere di verificare anche questa piattaforma.

Per impostare l'indirizzo IPv6 di backend si procederà come da immagine andando nel Pannello di controllo, Rete e Internet, Connessioni di rete e quindi nel NIC prescelto impostare l'indirizzo IPv6 come da immagine...

Una volta effettuata l'impostazione è possibile avviare tomcat che per default esegue un listening su tutte le interfacce presenti e quindi anche sull'indirizzo IPv6...

Test delle funzionalità Oplon Application Delivery Controller IPv6 gateway

A questo punto non ci resta che accedere attraverso il browser ai servizi erogati in IPv6 indifferentemente da IPv4 o IPv6....

IPv4... http://192.168.43.10/trainingw/ (opens in a new tab)

IPv6...http://[fd00:c9:c9:a::]/trainingw/

Il risultato dell'instradamento si può apprezzare dalla seguente immagine dove indipendentemente dall'ingaggio della richiesta, virtual IPv4 o IPv6, il forwarding viene effettuato nel servizio posto nel backend in IPv6.

Andiamo ora a disabilitare gli instradamenti sugli endpoint attestati nell'indirizzo IPv6 statico di backend e andiamo a impostare lo stesso servizio Tomcat attestato però nell'indirizzo autoconfigurato dello stesso server...

Il risultato è un forwarding delle richieste provenienti dagli indirizzi virtuali IPv4 e IPv6 verso il backend IPv6 con indirizzo autoconfigurato...

Conclusione

A conclusione di questo documento possiamo affermare che l'utilizzo pratico dell'IPv6 non è dissimile dall'utilizzo dell'IPv4 dando però nel contempo una flessibilità ed un ordine nell'assegnazione degli indirizzi di livello decisamente superiore permettendo di utilizzare al massimo le possibilità offerte dalla virtualizzazione. La compatibilità delle applicazioni con Oplon Application Delivery Controller viene garantita offrendo una piattaforma che permette di introdurre in maniera soft il nuovo indirizzamento dando la possibilità inoltre agli operatori di familiarizzare con questo protocollo e tutto il mondo creato attorno ad esso come DNS, politiche di sicurezza, routing.

Acronimi e definizioni

IPv4 Internet Protocol versione 4 IPv6 Internet Protocol versione 6 endpoint Servizio di backend listener Punto di accesso ai servizi Netmask Subnet prefix in IPv6 Subnet prefix Netmask in IPv4 DAD Duplicate Address Discovery

Tabella riassuntiva e descrittiva Aggregate Table Global IPv6