Insomma è più una questione di scelte aziendali più che un problema hardware, ormai i router sono compatibili con IPV6 da decenni manco anni.
IPv6 vs IPv4
- Modificato
PippoGi Diciamo che se TIM volesse non avrebbe troppi problemi.
Però non vai a investire in qualcosa che nel breve periodo non da altro che ridurre i tuoi profitti (vedi punto 2), poi c'è anche da addestrare quelli dei call center (in teoria)...
Quello che mi stupisce è che gli altri dormano, TIM me lo aspettavo che avrebbe spinto in là il più possibile.
Quello che invece mi fa girar le goleador è che molti piccoli ISP che non hanno una rete estesa come quella di TIM CGNATtano a manetta, fanno pagare gli IPv4 una fortuna e continuano imperterriti s non supportare IPv6.
edofullo
passare ad ipv6 non è una passeggiata.... pick your poison
juststupid A parte il verde mi pare la mappa delle regioni 
- Modificato
juststupid Non ho detto che è una passeggiata ma se Telekom e BT supportano IPv6 anche TIM ce la può fare...
Comunque al giorno d'oggi la soluzione (seria) è una sola: Dual Stack
Per quanto riguarda le soluzioni IPv4 in IPv6 (MAPT e comagnia) son belle ma finchè
non sarà più diffuso IPv6 la vedo difficile.
[cancellato]
edofullo Comunque al giorno d'oggi la soluzione (seria) è una sola: Dual Stack
Sì, il problema delle tecnologie di transizione si pone solo per gli ISP che non hanno IPv4 a sufficienza, o che si trovano a dover far transitare IPv6 su reti IPv4 only.
Credo che tutti i maggiori che già oggi assegnano IPv4 pubblici senza CG-NAT non avrebbero alcun problema "tecnico" ad offrire una soluzione dual-stack nativa. Non lo fanno per motivi economici e amministrativi, tanto una domanda da parte degli utenti consumer per ora non c'è, quindi sarebbe un investimento "inutile".
edofullo
se il dual stack fosse unica soluzione seria non avrebbero inventato tutte queste soluzioni. dual stack ha i suoi bei problemi soprattutto se uno fa parte di quelli che hanno un core full bgp e se uno fa parte dei sveglioni che si tengono inutilmente una FIRT in casa e non applicono filtri tra RIB e FIB.
[cancellato]
stemax97 Se 8.8.8.8 è un secondary IP di un host locale e lo raggiungi via rotta statica o comunque più prioritaria del default GW... why not? 
juststupid Dipende. Stai parlando di tutte tecniche per far coesistere IPv6 in una rete di trasporto IPv4-only. Se vai di dual stack, problemi assolutamente non ce ne sono.
Oppure, fai come fa Sky e usi una core IPv6 only e "traduci" gli IPv4 nel trasporto.
juststupid Non vedo come il dual stack sia legato alla FIRT IPv4. La cardinalità dei prefix IPv6 ad ora sono ben poche.
[cancellato]
coesistenza per forza, penso che sia commercialmente impensabile staccare la spina al ipv4 da un giorno all'altro in italia. Poi certo che ipv4 over ipv6 sarebbe il meglio. dual stack non è la panacea per via dei carichi sui device avresti un ipv4 + ipv6 core per cui disogna fare bene i conti per il futuro che arriva a piena velocità. Anche vero che le altre soluzioni non sono semplici a livello ingegneristico. Ognuno si deve fare i conti in tasca su cosa gli convenga. Non so cosa utilizzi sky italia (map-e map-T)
(chiedo venia per la risposta ho cercato più volte di fare il "cita dei cita" ma usciva na roba strana)
[cancellato]
juststupid Non so cosa utilizzi sky italia (map-e map-T)
Doveva. Ma al momento pare che assegni semplicemente IPv4 pubblici dinamici ad ogni utenza (confermi, @Supreme69 ?), che poi traduce in IPv6 nel trasporto. Almeno, mi ricordo così.
- Modificato
[cancellato] Oppure, fai come fa Sky e usi una core IPv6 only e "traduci" gli IPv4 nel trasporto
Però questo è quello che hanno scritto nella presentazione(di cui ho il PDF
)... non sarei sicurissimo nella pratica sia così.
Anche perché per ora non pare così, idem per MAP-T che non è di fatto per ora utilizzato .
Loro secondo me si fanno di fatto il loro bel Ethernet over MPLS, quindi IP non lo toccano
IPv6 Core only inoltre appare nello scenario MAP-T e abbandono IPv4... è per quello che mi è sorto il dubbio.
Penso sia l’obiettivo quello
Infatti DNS e Voce confermerebbero questo trend, col v6 only.
Quali sarebbero evidenti vantaggi del "tradurre" ipv4 ipv6 nel trasporto rispetto alle altre soluzioni ? mi piacerebbe capirne di più di una tale scelta perchè ovviamente ci sono altrimenti non lo avrebbero fatto.
- Modificato
juststupid mi associo alla domanda, io non ne vedo.
Vero anche che è mezzanotte passata... quindi 
[cancellato]
- Modificato
juststupid Che hai una core IPv6 only, e ti preoccupi della gestione del routing IPv4 solo all'edge.
Originariamente la cosa penso sia stata fatta per il MAP-T. Non hai problemi però di difformità di percorsi tra IPv4 e IPv6, niente doppio protocollo di routing interno, niente doppi indirizzi alle interfacce da gestire... almeno, io a mezzanotteemezza mi vien in mente questo.
Però se me lo chiede il gandalf2016 che mi mangia a colazione in quanto a competenze forse sto dimenticandomi qualcosa per strada...
EDIT: Tanto per mettere i nomi giusti che io non me li ricordavo, Sky dovrebbe usare 464XLAT. 
Lettura per la sera, o la mattina: https://www.lacnic.net/innovaportal/file/2621/1/ipv6-trans-and-ipv6-only_v8.pdf
- Modificato
[cancellato] nah.. figurati. Probabile stia dimenticando io
Sì ragionevolmente potrebbe essere quello, Se guardi un loro trace attuale è molto pulito.
I nodi che lavorano in L3 nudo e crudo sono veramente pochi gli utenti fanno 2-3 hop e sono in internet... in sostanza:
BNG(dopo che sono arrivati dall’Edge), Metro, Core ed escono.
A questo punto rimane:
Poco ma sicuro il BNG deve avere IPv4 per terminarti l’utente e anche i peering/transit routers.
Rimangono i core (che però sono pochi per natura) e il metro( e qui la faccenda potrebbe complicarsi)
Avessero una implementazione di rete alla Fastweb con tantissimo Layer3 puro in mezzo effettivamente il problema si porrebbe ma mi sa che per i numeri attuali e come la hanno implementata gestirsi un dual-stack non è poi tanto oneroso.
allora anche la soluzione di sky è presente nella tabellina delle regioni.
[cancellato] Se 8.8.8.8 è un secondary IP di un host locale e lo raggiungi via rotta statica o comunque più prioritaria del default GW... why not?
era quello che intendevo io ma te l'hai spiegato meglio 
Avevo capito, mi sembrava soltanto una soluzione meno lineare di fare DNS-Hijacking le richieste DNS, per sua natura è molto più trasparente. Risolverebbe anche il problema degli altri server (in un colpo solo hai bloccato l'uso di DNS server su porta 53 diverso da quello voluto, al posto di fare una static route per 1.1.1.1, 4.2.2.2, 208.67.222.222, ecc).
Non funzionerebbe per bloccare DNS-OVER-TLS o DNS-OVER-HTTPS, in quel caso le rotte statiche sono l'opzione migliore 
Chiuso OT 
