Però c'è anche da dire che SKY ha dovuto farsi riadattare l'implementazione OpenWRT di MAP-T perché quella nel broadcom SDK era inusabile, questo la dice lunga sulla maturità di MAP-T lato CPE
Sky WiFi passerà a MAP-T entro il 2021
[cancellato]
[cancellato] Risposta bruttabruttabrutta, tradotto in italiano: "voglio la pappa pronta"...
Ah beh, di fatto è una distro ottimizzata di FreeBSD con una GUI dedicata e poco altro. Non che mi aspettassi qualcosa di diverso, ma visto che non c'era una feature request specifica gliel'ho aggiunta. Così chi cerca la trova, con la loro risposta. Poi dipenderà da quanti ISP cominceranno ad adottare 464XLAT, MAP-T e compagnia.
[cancellato] Resta quindi l'ipotesi OpenWRT o linux "puro" per NAPTv4 e MAP-T di edge
Sì, è meno pratico dove è comodo avere un singolo device, non sono mai particolarmente portato a far girare router e firewall in VM tranne che in laboratorio. Comunque se il router Sky permette di fare routing puro facilmente te la puoi cavare anche con quello, e dietro il pfSense. Se poi cominci a consumare buona parte dei servizi in IPv6 non hai nemmeno i problemi di NAT. Dipende sempre se il router poi diventa in cavallo di troia per il lock-in per qualche anno.
Tra l'altro da quello che leggo Sky è in grado di rilevare l'uso di DMZ/forwrding/ecc. solo se usi il loro router perché usa un'applicazione sviluppata da Comcast che legge le informazioni via protocollo di gestione remota - quindi router che non controllano gli creano ulteriori problemi.
[cancellato]
[cancellato] di fatto è una distro ottimizzata di FreeBSD con una GUI dedicata e poco altro.
Sì certo però offrono contratti di assistenza commerciale.. e se il problema sta sotto la GUI, sul kernel o i demoni BSD che fanno? Rispondono al cliente pagante "t'attacchi"? Così volano dalla finestra in 3 secondi netti prima ancora di metter giù il telefono.
[cancellato] se il router Sky permette di fare routing puro facilmente te la puoi cavare anche con quello, e dietro il pfSense.
Ottima domanda... non saprei, ci vorrebbe la collaborazione di qualche cliente Sky WiFi, ma vedendo quanto @Supreme69 ha patito anche solo per impostare i canali WiFi... la vedo dura, molto dura.
- Modificato
[cancellato] se il router Sky permette di fare routing puro
Cosa intendete per "routing puro"?
Io direi che la soluzione più semplice è mettere un proprio router in cascata sotto DMZ, così si passa anche al MAP-T 1:1
Poi sarebbe anche da capire cosa intendono per "abuso" del MAP-T 1:1
[cancellato]
- Modificato
handymenny In IPv6, routing 
non ci sono tante altre definizioni...
In IPv4 dovrebbe essere lui che fa il masquerading della rete privata verso l'IP assegnato via MAP-T. Il problema è che se a valle c'è un secondo router va da sé che debba supportare il masquerading di più di una subnet, cosa che gli apparati consumer molto difficilmente supportano già di suo, senza tirare in ballo il MAP-T.
handymenny mettere un proprio router in cascata sotto DMZ
Ma così fai NAT due volte, con tutte le rogne del caso.
handymenny cosa intendono per "abuso" del MAP-T 1:1
Dato che ne hanno relativamente pochi (una /16 a memoria), non vogliono che gli utenti tengano attivi i NAT inutilmente solo per vedersi assegnato l'IP mappato 1:1. Potrebbero andare ad ispezionare se c'è traffico entrante? Non lo so..
- Modificato
handymenny Cosa intendete per "routing puro"?
Che fa da gateway per i device a valle.
Per clienti business si fa anche in v4.
Ovvero fa da router col suo IP pubblico a cui punterà il firewall del cliente.
[cancellato]
[cancellato] Sì certo però offrono contratti di assistenza commerciale.. e se il problema sta sotto la GUI, sul kernel o i demoni BSD che fanno?
Pushano upstream e aspettano FreeBSD mi sa... basta vedere il tempo che ci è voluto per avere ALTQ funzionante sulle interfacce ix - che sono Intel e pure di fascia medio-alta. O QAT - l'unica cosa che fanno è magari backportare qualcosa, come hanno fatto proprio con QAT, il driver è apparso in FreeBSD 13 e loro l'hanno portato sulla 12 ma solo per la versione commerciale. Comunque finché non paghi hai poco da lamentarti 
handymenny Cosa intendete per "routing puro"?
Routing semplice senza usare default host ma con routing table (anche statica). Così se hai più subnet lato pfSense non hai bisogno di far fare ulteriore NAT al pfSense.
handymenny così si passa anche al MAP-T 1:1
Sì, quello sarebbe l'unico motivo per farla
handymenny Poi sarebbe anche da capire cosa intendono per "abuso" del MAP-T 1:1
Secondo me vanno a vedere quanto effettivamente lo usi e quanto traffico ci fai.
[cancellato] Il router Sky lo hanno installato i tecnici. Appena se ne sono andati ho attaccato il mio ONT ho copiato il backup e provato. Si era collegato. Ho avviato la macchina PfSense. Cambiato da PPPoE a vlan101, DHCP e aspettato. Prima avevo provato ad usare l'HUB quando mi ha scrtitto "scarica l'app per configurare il port forward" ho detto: "ciao ciao." E ho cercato su internet il perchè trovando questa discussione.
Pensando che sono passato a Sky anche per il dual stack...
[cancellato]
- Modificato
hitech95 quando mi ha scrtitto "scarica l'app per configurare il port forward" ho detto: "ciao ciao."
hitech95 Pensando che sono passato a Sky anche per il dual stack...
Però era noto fin dall'inizio che puntavano su MAP-T. Putroppo per gli ISP la soluzione dual-stack è la più complessa e costosa. Così temo che chi come TIM siede su un bel numero di IPv4 non ha alcun reale interesse per ora ad offrire IPv6 (e si vede), mentre chi non li ha inevitabilmente deve andare su soluzioni diverse - meglio però a questo punto una rete nativa IPv6 con MAP-T che una soluzione solo IPv4 con CG-NAT - nonostante la nuova complessità se si vuole gestire IPv6 lato LAN.
[cancellato] Anche Melita parla di MAP-T. Loro hanno il CG-NAT in v4 abilitato però.
[cancellato]
Sì, il vero problema di MAP-T è la mancanza di supporto da parte dei router cliente, da quello che ho capito Sky si è fatta il software apposta usando l'implementazione di OpenWRT dopo che il loro primo tentativo era fallito. Da quel punto di vista CG-NAT essendo tutto lato operatore funziona con qualunque router - però probabilmente al crescere del numero dei clienti diventa più oneroso. Sky punta ad averne tanti.... vediamo se ci riesce.
- Modificato
[cancellato] però probabilmente al crescere del numero dei clienti diventa più oneroso
Bisogna vedere come i Cisco NCS, che sono l’ossatura della loro infrastruttura, gestirebbero il CG-NAT.
Perche è merchant silicon, non il classico ASR dove si mette la card e via… case-study interessante
- Modificato
[cancellato] Sì, il vero problema di MAP-T è la mancanza di supporto da parte dei router cliente, da quello che ho capito Sky si è fatta il software apposta usando l'implementazione di OpenWRT dopo che il loro primo tentativo era fallito.
Questo mi preoccupa assai, se vi fosse una implementazione lato consumer non sarebbe veramente male. Ma se solo loro, OpenWRT e un router TP-Link la hanno... beh la vedo nera!
hitech95 e un router TP-Link la hanno...
Il problema è che se ha quella di riferimento broadcomm, è inusabile (fonte: sky)
[cancellato]
Tecnicamente non è neanche estremamente complessa. Però come tutte le implementazioni delle funzionalità critiche è delicata e le prestazioni sono importanti. Mi chiedo con quali router client Netgate testi l'implementazione della parte BR in TNSR - finirà che la testa con OpenWRT, mi sa 
Certo che Sky usa l'Italia come apripista... e finché viene più che altro usata a livello consumer non ci vedo una corsa ad implementarlo da parte di diversi prodotti.
[cancellato]
[cancellato] Eh sì, però alla fine a tendere nel futuro le strade saranno due: o translation (MAP-T, MAP-E, 464XLAT,...) o CG-NAT... Gli IPv4 sono finiti da anni, e la fama di connessioni e macchine in cloud non si arresta, con il risultato che diventeranno sempre più costosi (chi ne ha vuole monetizzare, e non gli do torto).
Chi è storico ed è riuscito a fare incetta 15 o 20 anni fa sta tranquillo, i nuovi player si trovano senza risorse e senza possibilità di miglioramento (a meno che Apple e il DoD non mollino un bel po' delle /8 legacy che hanno, ma non credo lo fanno "per la patria").
[cancellato]
- Modificato
[cancellato] la fama di connessioni e macchine in cloud non si arresta,
Mi sa che per un po' sarà proprio il cloud a tentare di sottrarre IPv4 ad altri sistemi per far contento il classico sysadmin che "uelllllllla.... IPv6 c'ha troppi numeri, mica lo voglio usare io!" sottraendoli alle reti "consumer". che verranno migrate prima ad IPv6 con piccoli pool IPv4 condivisi per quello che non possono accedere direttamente in IPv6. Da quello che vedo AWS ad esempio nonostante le dimensioni non è proprio un pioniere dell'adozione di IPv6.
Chissà se vedrò il ritiro di IPv4... è più facile che rilasci gli indirizzi il DoD che Apple... mi sa che questa un giorno ne approfitterà per affittare dispositivi iPV4 Edition - a prezzo adeguato, con indirizzo inciso in oro sullo chassis.
Il DoD però da poco ha cominciato ad annunciare i blocchi che ha da anni non utilizzati - ha dato l'incarico ad una misteriosa società della Florida. Pare per evitare che lo facesse qualche provider criminale.
[cancellato]
- Modificato
[cancellato] Chissà se vedrò il ritiro di IPv4
Che IPv4 venga ritirato guarda non ci credo nemmeno io, magna tranquillo come dicevano... però che possa venire ridimensionato ecco forse sì.
[cancellato] sarà proprio il cloud a tentare di sottrarre IPv4 ad altri sistemi per far contento il classico sysadmin che "uelllllllla.... IPv6 c'ha troppi numeri, mica lo voglio usare io!"
Sì e no. Il problema è sempre lo stesso di fondo: non sono compatibili gli uni con gli altri, e se devi mettere a disposizione un servizio usabile dal consumer qualunque, ti tocca avere anche macchine esposte in v4.
È un cane che si morde la coda, fin quando gli ISP non daranno IPv6 massivamente i sysadmin vecchio stile non saranno incentivati a migrare, e a loro volta gli ISP senza una killer application in v6 non si sogneranno mai di sprecare soldi (secondo la loro visione) perché "tanto ho IPv4 da vendere"...
Poi certo si potrebbe ottimizzare, per dire le macchine interne del cloud di un'azienda potrebbero usare IPv6, ma giustamente anche IPv4 privati RFC1918 indifferentemente, lasciando l'obbligo di avere v4 pubblicamente ruotabili solo alle macchine di edge/DMZ/load balancing che sia... in molti casi è già così (i private cloud che fanno pagare i cosiddetti floating IP a peso d'oro), in altri no (vedasi le macchinette VPS "general purpose").
[cancellato] Il DoD però da poco ha cominciato ad annunciare i blocchi che ha da anni non utilizzati - ha dato l'incarico ad una misteriosa società della Florida. Pare per evitare che lo facesse qualche provider criminale.
Mah questa non l'ho capita... in ogni caso non mancano esempi di prefissi IP annunciati a cappella, se non proprio ab-usati senza possederli (es. molte reti storiche assegnavano indirizzi sulla 1.0.0.0/8, ante-RFC1918 appunto, Hamachi si era inventato di usare qualcosa della 5.0.0.0/8, e me ne sto dimenticando di sicuro molti).
Poi, vogliamo parlare di una intera /8 sprecata per il localhost?? A che cappero serve, non ne bastavano di meno?
Qui IMHO tirata d'orecchie a IPv6... ne avete a braziliardi, e mi dedicate solo un indirizzo al loopback (::1)??? Cacchio vi costava dedicare almeno il prefisso 0:0:0:0::/64 al localhost? O 0:0:0:1::/64 toh, per non confonderlo con l'IP "nullo", almeno uno può mettere in listen più servizi sulla stessa lo.
IPv4, inutle nasconderselo, ha fatto il suo tempo (egregiamente, sia chiaro!)... patisce ora terribilmente decisioni prese a cuor leggero quando il mondo (connesso) era molto più piccolo, e le idee si potevano ancora sintetizzare su un fazzoletto di carta. 
[cancellato]
[cancellato] se devi mettere a disposizione un servizio usabile dal consumer qualunque, ti tocca avere anche macchine esposte in v4
Vero, però se cominci appunto a spostare prima i "consumer" verso IPv6 poi ti bastano i front-end in IPv6. In quel modo puoi tentare di riservare IPv4 alle connessioni "B2B" dove tenti di far soldi vendendo servizi distribuiti, e dove non vuoi inimicarti troppo sysadmin e sviluppatori "pigri" causando problemi di migrazione - gli indirizzi RFC1918 li puoi usare internamente fino ad un certo punto fra reti di clienti diversi. Mia previsione, sia chiaro, magari sarò clamorosamente smentito. Però ci vedo qualche telco indebitata (o semplicemente avida) vendere qualcuno dei suo blocchi IPv4 ad AWS/Azure/Google/etc. se li pagano bene.
[cancellato] Mah questa non l'ho capita...
È la spiegazione ufficiale che hanno dato. È vero che ci sono sempre più spammer & C. che tentano di annunciare blocchi "dimenticati", e questi pian piano quando possibile sono stati riassegnati, ma andare a cercarsi guai con il DoD...
[cancellato] Poi, vogliamo parlare di una intera /8 sprecata per il localhost??
Sarebbe da usare per il cloud... un enorme "localhost".... 
OT: ma tu riesci a raggiungere https://cisco.jiveon.com/ ?