Caratteristiche tecniche della FTTH iliad

dickfrey Intanto grazie per questa prima bozza di FAQ. Volevo chiederti perchè preferisci il Map-T.

Credo che serva una spiegazione approfondita di questo discorso e senza sapere a che è l'MTU di iliad non si possa fare di più di 2 chiacchere da BAR.
Premetto che la principale differenza tra MAP-T e MAP-E è come avviene la traduzione/incapsulamento del frame IPv4 in IPv6. Nel caso di MAP-T viene tradotto e usato l'header v6, nel caso di MAP-E viene incapsulato e ci sono 2 header, quindi:
a) MAP-T è più pulito di MAP-E in quanto c'è un tunnel in meno e vengono sfruttati gli header IPv6 per contenere le informazioni IPv4, con l'header di dimensione minore, ma sempre maggiore rispetto ad un IPv4 standard si hanno prestazioni lievemente superiori.
b) con un aumento dell'MTU del trasporto, possibile solamente dove c'è passivo e/o OF non ha rilegamenti creativi [quindi NON in area bianca] è possibile arrivare ad un bellissimo MTU di 1500, che molto probabilmente iliad se lo sogna con il MAP-E (Translation vs Encapsulation e quindi -40byte vs -20byte), e l'MTU di iliad sarà bello basso, si può ipotizzare 1460/1440 (Vedi FAQ #16), anche aumentando l'MTU ethernet, difficile è raggiungere un valore accettabile senza avere problemi nelle aree openstream.
c) la gestione del protocolli portless, è differente, la gestione di MAP-E non è così brillante, infatti si usa il tunnel 4in6.
d) il costo necessario per l'incapsulamento 4in6 è simile a quello per la traduzione, e sinceramente non vedo motivi per incapsulare quando è possibile una traduzione, e l'unico vantaggio di MAP-E è avere altri tunnel 4in6 realizzabili senza problemi.

dickfrey Tenuto conto che nel caso di Skywifi va fatto port forwarding sulle porte e si aspetta che l' automatismo ti porti in Map-T 1:1 (dopo un tempo variabile tra poche ore ed un giorno), nel Map-E si farebbe una cosa simile o sarebbe differente ?

L'implementazione Iliad è differente [ricordo che è una chiaccera da bar ipotizzando il deploy francese]: tu che voglia o non voglia le porte apribili rimani in MAP-E 1:X, se vuoi aprire le porte ricevi un altro IPv4 privato con 4in6 incapsulato ma fuori dal dominio MAP.
Se tu non hai nulla di compatibile con MAP potrai ottenere solo l'altro IPv4 privato. È un ottimo workaround.

Dato che non posso più modificare le FAQ se ci sono dubbi o cose non chiare che ho specificato nelle FAQ #2, #5, #12, #13, #14, #15 che ti hanno fatto venire questo dubbio dimmi cosa e dove.

simonebortolin Le ultime versioni della playstation (4 e 5) fanno molto meno uso delle porte aperte rispetto alle 3 o precedenti, e i produttori delle console e dei giochi devono cambiare approccio di sviluppo senza più chiedere l'apertura delle porte perché è una roba troppo old school incompatibile con la attuale carenza di IPv4.

Non è questione di "old school", ma una questione di vili €€€.

Se tu fai p2p diretto con l'apertura delle porte crei un gioco che potenzialmente andrà "per sempre" sulle sue gambe... poca spesa tanta resa.

Se invece eviti l'apertura delle porte devi creare (€€€) e mantenere nel tempo (€€€€€€€) uno o più server che fanno da tramite per diversi anni, anche dopo che il gioco stesso smette di creare entrate apprezzabili. Il giorno che spegni l'ultimo server ucciderai completamente il multiplayer di quel gioco, per la felicità dei suoi utenti ancora attivi.

La soluzione tecnica esiste: richiedere IPv6 obbligatorio per giocare in multiplayer con le porte aperte e escludere tutti gli utenti che usano ancora IPv4.... Vedrai che i gamer faranno la corsa per cambiare ISP e andare da chi gli fornisce IPv6 (la copertura in tutta Italia c'è già, sia FTTC/FTTH sia FWA) o si armano di pazienza e si installeranno un tunnel HE o simile per poter giocare sul loro vecchio ISP obsoleto.

ragazzi una domanda, se non ho capito male i 5 Gbs non sono per singolo pc, ma cumulativo giusto? per singola utenza sono massimo 2,5 Gbs giusto? altra domanda secondo voi questo abbassamento dei prezzi anche sul fisso, secondo voi sarà la strategia giusta per avere anche una fibra di qualità?
ps mi aspetto di vedere cosa tireranno fuori i vari kena, ho e very

simonebortolin Che si alzi o meno l'MTU sul sottostante ethernet, comunque MAP-E comporta una perdita di prestazioni rispetto al MAP-T perché ogni pacchetto IPv4 cresce di 40byte dovuti all'header IPv6 aggiunto "in testa" a quello v4, quindi comunque la parte di overhead data dai protocolli di trasporto è più alta di un IPv6 "puro" trasformato con MAP-T (perdita dimezzata data solo dalla differente lunghezza dei due header tra v4 e v6).
L'interfaccia fisica sottostante può trasmettere sempre lo stesso numero di bit/s, quali che siano gli incapsulamenti sovrastanti, e il policer di traffico quando c'è (se non c'è si sbatte sul limite fisico della "portante") si fa layer2.

Cambia poco, ma visto che c'è gente che si strappa le vesti per gli 8 byte aggiunti dalla PPPoE+PPP...

LSan83 cfr. "rasoio e lametta"

simonebortolin È comunque una strategia legacy incompatibile con l'attuale disponibilità di IPv4

Sposti il problema ai cloud provider, sia per disponibilità IP (es. Hetzner ora lo fa pagare a parte, mica per loro sono infiniti) che di banda.
Esistono soluzioni alternative per costruire un tunnel tra due parti entrambe sotto NAT (sono usate per esempio dai sistemi di conferenze WebRTC), ma qui si va oltre la discussione.

simonebortolin Sì, ma marginalmente.

simonebortolin Ormai costano così poco un server che non è un problema IMHO

Il server non si limita al solo noleggio/acquisto, ma ha bisogno di personale per la gestione e lo sviluppo/aggiornamento del relativo software. Su molti giochi non è una spesa trascurabile (non penso che Blizzard abbia speso poco per i server di WoW negli anni...).
E non tutti i giochi sono AAA che vendono a palate. Ci sono anche giochi con multiplayer che faticano a pagare le spese di sviluppo in cui i server sono un'ulteriore perdita economica.
Costa molto meno imporre come requisito di gioco l'IPv6.

[cancellato] Cambia poco, ma visto che c'è gente che si strappa le vesti per gli 8 byte aggiunti dalla PPPoE+PPP...

Sono finezze da nerd. All'atto pratico se vuoi veri cambiamenti bisognerebbe avere i Jumbo Frame della LAN

simonebortolin Ok, ma io aspetterei un attimo a fare un thread perchè tutte le informazioni prese adesso sono nostre supposizioni personali basate su quello che fanno in francia ed su un paio di pdf che abbiamo già visto essere incompleti se non proprio errati.

Se poi qualcuno si abbona comprando un router da centinaia di euro pensando sia compatibile ed ha problemi non è bello.

Abbiamo bisogno di qualcuno con l'IliadBox che ci mandi la pagine dello status con gli IP e di qualcuno che ci mandi uno screenshot dei parametri di configurazione che si trovano sul sito prima di tirare conclusioni.

Spiegazione veloce:

MAP ha queste tre funzionalità principali:

• autoconfigurazione delle CPE via DHCPv6 (option 95 e penso 97)
• address sharing statico (allocazione delle porte ai clienti per [S]NAT)
• IPv4aaS attraverso traduzione IPv4->IPv6 (MAP-T, che su OpenWRT usa nat46) oppure incapsulamento IPv4 in IPv6 (MAP-E, che usa ip6tunnel/ipip6/4in6)

Quello che PENSO stia succedendo è che ai clienti registrati modem libero (che non riceveranno nemmeno il freebox mi sa) viene assegnato un prefisso IPv6 statico in un pool particolare che viene mappato in 1:1 (come Sky).

A questo punto ci sono due possibilità:

• se la CPE cliente supporta MAP-E tutto viene autoconfigurato
• se la CPE non supporta MAP-E ma supporta ipip6 basico, si possono bypassare i primi due requisiti visto che l'autoconfigurazione non è necessaria visto che i parametri sono sempre uguali e l'address sharing non è necessario se si è in 1:1 (come con Sky), quindi il MAP-E "collassa" nella creazione di un singolo tunnel IPIP6 configurato opportunamente che può essere settato manualmente (la cui configurazione manca totalmente nella guida Mikrotik)

A me non piace che abbiano scritto che basta il supporto ad IPIP6, io lo vedo come un workaround, avrebbero secondo me dovuto scrivere che serve il MAP-E, lasciando agli utenti l'onere ed il rischio di trovare ed usare i workaround.

Però sembra che ci abbiano pensato almeno al modem libero (che chiamano "net neutrality" nei loro documenti ufficiali )

Fronte MTU a parte

Ripeto, solo supposizioni finchè non avremo le info che ho scritto prima e qualcuno con un router x86 attivo che possa fare un paio di prove.

Comunque penso di fare delle prove in lab nei prossimi giorni