ARGOMENTO:

Salve a tutti,
Solitamente in certificazione si studia Isole IPv6 collegate da una rete IPv4 di mezzo;
per cui si possono utilizzare le varie tecniche di tunnel: Manual IPv6, GRE, 6to4 o ISATAP, che servono a far traghettare IPv6 dentro IPv4.

Nello scenario che propongo invece, Isola IPv4 <-Router-> Isola IPv6, è necessario applicare per forza il NAT-PT? Oppure si può utilizzare una tecnica di tunnel in qualche modo particolare?

In attesa della risposta, posto anche l'esempio che ho creato ed il problema sorto.
Lo scenario presenta tre router (R1, R2, R3) creati per simulare tre host dell'Isola IPv4;
Un BorderRouter su cui farò NAT-PT, e che ha quindi un interfaccia nella parte IPv4, ed un interfaccia nella parte IPv6;
Un router ISP che parla solo IPv6. Di seguito la Topologia:


Di seguito le configurazioni create

---

[R1 Config]:
interface FastEthernet0/0
ip address 192.168.0.5 255.255.255.0
duplex auto
speed auto

ip route 0.0.0.0 0.0.0.0 FastEthernet0/0

(R2 ed R3 configurazione simile) (R2 = 192.168.0.6) (R2 = 192.168.0.7)

---

[Border Router Config]:
interface FastEthernet0/0
no ip address
duplex auto
speed auto
ipv6 address 2002::1/64
ipv6 nat
ipv6 ospf 10 area 0
!
interface FastEthernet0/1
ip address 192.168.0.1 255.255.255.0
duplex auto
speed auto
ipv6 nat

ipv6 router ospf 10
router-id 10.1.1.1
log-adjacency-changes
redistribute connected
!
ipv6 nat v4v6 source 192.168.0.5 2002::5
ipv6 nat v6v4 source 2002::2 192.168.0.100
ipv6 nat prefix 2002::/96

---

[ISP Config]:
interface FastEthernet0/0
no ip address
duplex auto
speed auto
ipv6 address 2002::2/64
ipv6 ospf 10 area 0
!
!
ipv6 router ospf 10
router-id 10.2.2.2
log-adjacency-changes

---

Situazione che ho:
BorderRouter pinga i tre host (comunicazione IPv4 ok);
BorderRouter e ISP pingano (comunicazione IPv6 ok);
Quando provo a pingare da R1 (192.168.0.5) l'IP 192.168.0.100, mi aspetto che si traduca in 2002::5 e riesca a pingare l'ISP....ma non riesce a pingare.
Viceversa se da ISP provo a fare ping 2002::5 (mi aspetto che si traduca in 192.168.0.100 e riesca a pingare R1...ma non riesce neanche questo.

Dopo i tentativi falliti, cmq digitando su BorderRouter "show ipv6 nat translations", mi fa vedere le translazioni fatte, quindi sembra che funzioni, ma i ping non riescono.
Come mai?

Intanto bravo Andrea che si cimenta in tecnologie nuove che non siano i soliti OSPF e BGP
Credo che il problema sta nel fatto che hai nattato su indirizzi appartenenti alle network, quindi quelli che succedere è che:
R1 effettua una ARP request verso il 192.168.0.100 e non riceve risposta
ISP effettua un neighbour discovery verso 2002::5 e non riceve risposta.

Prova a nattare su reti differenti, tipoDovrebbe funzionare

Ho modificato il nat sul BorderRouter, in questo modo:
ipv6 nat v4v6 source 192.168.0.5 2002:1::5
ipv6 nat v6v4 source 2002::2 192.168.1.100
ipv6 nat prefix 2002:1::/96

Su ISP ho aggiunto la rotta statica:
ipv6 route 2002:1::5/128 2002::1

Adesso se dall'ISP provo: ISP# ping 2002:1::5
succede una cosa strana: tutti i ping riescono alternati, in out: !.!.! come mai?

Domanda: ma come faccio poi la prova finale di ping? Cioè da ISP, se provo a pingare 2002:1::5, vuol dire che sto pingando R1? Perchè se provo a fare ISP# ping 192.168.0.5,
mi dice che non è attivo il protocollo di routing.
Come si fa la prova finale di comunicazione tra ISP ed R1?

Altra domanda: su R1 c'era già configurata la default-route verso il BorderRouter, quindi secondo me doveva funzionare ugualmente; ed invece non riusciva nulla finchè non ho aggiunto la rotta statica come mi consigliavi tu:
"ip route 192.168.1.1 255.255.255.255 192.168.0.1" --> come mai con la default-route non funzionava?

andrea_ballone ha scritto: Ho modificato il nat sul BorderRouter, in questo modo:
ipv6 nat v4v6 source 192.168.0.5 2002:1::5
ipv6 nat v6v4 source 2002::2 192.168.1.100
ipv6 nat prefix 2002:1::/96

Su ISP ho aggiunto la rotta statica:
ipv6 route 2002:1::5/128 2002::1

Benissimo

andrea_ballone ha scritto: Adesso se dall'ISP provo: ISP# ping 2002:1::5
succede una cosa strana: tutti i ping riescono alternati, in out: !.!.! come mai?

Suppongo sia un malfunzionamento di packet tracer, potresti provare la stessa config in Dynamips, il comportamento devrebbe essere differente, dovresti vedere tutti gli icmp a segno

andrea_ballone ha scritto: Come si fa la prova finale di comunicazione tra ISP ed R1?

ISP parla solo IPv6, R1 solo IPv4 è per questo che traduci il protocollo con NATPT, non puoi pingare 192.168.0.5 da ISP, perchè non parla quel protocollo, ma grazie alla traduzione puoi pingare 2002:1::5 che è esattamente R1 tradotto per IPv6, lo stesso discorso vale al contrario per R1.

andrea_ballone ha scritto: Altra domanda: su R1 c'era già configurata la default-route verso il BorderRouter, quindi secondo me doveva funzionare ugualmente; ed invece non riusciva nulla finchè non ho aggiunto la rotta statica come mi consigliavi tu:
"ip route 192.168.1.1 255.255.255.255 192.168.0.1" --> come mai con la default-route non funzionava?

No dovrebbe funzionare anche con la rotta di default a patto di tradurre con un indirizzo non appartenente alla 192.168.0.0/24, sei certo di non aver configurato la statica verso la f0/0 invece che verso il next hop?

Sabato mattina abbiamo la lezione IPv6 proprio sulle tecniche di transizione, se vuoi puoi partecipare!

Tutto ok Virgilio, grazie risolto.
Si pinga benissimo, e come prova finale a prova del nove innegabile ho fatto:
ISP# debug ipv6 packet
R1# ping 192.168.1.100

R1# debug ip packet
ISP# ping 2002:1::5

I debug confermano che la comunicazione avviene proprio tra i due!

Per quanto riguarda il problema dei ping alternati....bè quello rimane, cmq sto utilizzando GNS3, su tutti i router gira IOS C3700 - probabile quindi che anche su GNS3 ci sia tale baco.
Sempre che a nessun altro venga in mente se ci possa esser un motivo valido a tale risposta al ping...!!!

Per questo sabato, magari Virgilio. Probabile sono a casa, se mi puoi inviare via mail l'evento ed il link, se ci sono partecipo con piacere. Cmq ti confermo.

Ciao Andrea, ho provato la cosa su apparati reali ed il problema del ping alternato non sussiste.
Sabato mattina verrai invitato alla lezione che si terrà di mattina dalle 9 alle 13

Ciao Andrea,
per risolvere il problema dei ping alternati su dynamips è sufficiente disabilitare il cef, il problema esiste perchè il dynamips gestisce in maniera errata il cef perchè questa è una funzionalità che dipende grandemente dall'hardware.

vspaziani ha scritto: Credo che il problema sta nel fatto che hai nattato su indirizzi appartenenti alle network, quindi quelli che succedere è che:
R1 effettua una ARP request verso il 192.168.0.100 e non riceve risposta
ISP effettua un neighbour discovery verso 2002::5 e non riceve risposta.

Prova a nattare su reti differenti, tipo
<code>IPv4 192.158.1.1 installando una statica su R1
ip route 192.168.1.1 255.255.255.255 192.168.0.1
IPv6 2002:1::5 installando una statica su ISP
ipv6 route 2002:1::5/128 2002::1
</code>

Come mai invece in logica IPv4 questo si poteva fare?
Cioè se il link pubblico punto-punto con l'ISP fosse stato ad esempio 87.35.100.1/24 (quindi l'ISP sarà ad es. 87.35.100.2/24) --> in IPv4 gli indirizzi Inside-Local potevano benissimo esser tradotti in Global come, ad es., 87.35.100.50, 51, 52..etc. Cioè appartenenti quindi alla stessa subnet 87.35.100.0/24, e tutto funzionava.
Come mai in IPv6 invece no?

andrea_ballone ha scritto: Come mai invece in logica IPv4 questo si poteva fare?

In realtà quello che devi tradurre come indirizzo diverso dalla lan è l'indirizzo outside local, cioè come viene vista la macchina esterna sulla rete locale, in NAT44 cioè IPv4, non fai questo, non traduci l'indirizzo di outside, se facessi questo convarrebbe lo stesso discorso.