gandalf2016 non c'entra nulla, quelle scritte non sono aggiornate da eoni, in riferimento all'uso effettivo degli IP, altrimenti alcune FTTH risulterebbero essere Dialup Wholesale per dire...
edofullo posso capire una azienda che produce pneumatici
LOL, in passato la "Pirelli Tyre S.p.A." figurava come assegnataria dei range di MAC address dei router Pirelli poi divenuti ADB...
[cancellato] Assurdo dell'assurdo, per le easy IP rivendute di fatto esiste la possibilità di averlo statico anche da privato. La mia ADSL è una EasyIP venduta da provider terzo ed ho IP statico, pur essendo un privato cittadino qualunque...
Pero' la linea nei sistemi Telecom molto probabilmente e' intestata alla partita IVA del tuo Operatore finale, non al tuo codice fiscale... Perlomeno con alcuni OLO cosi' accade(va?).
andreagdipaolo beh anche la Vodafone se ne e' allegramente sbattuta ad esempio quando mi migro' da ADSL ATM con IP pubblico ad ADSL ETH con CGNAT... Quel documento prevedeva chiaramente IP pubblici dinamici, e mancanza di filtri o QoS (che poi LOL per TeleTu... lasciamo perdere). All'ovvio reclamo risposero con il copiaincolla che per loro non c'erano disservizi... (Ed era una offerta a marchio TeleTu, quindi senza alcun "modem proprietario" con la backdoor che comunica se vengono aperte porte e disattiva il CGNAT "al volo"...)
simonebortolin un ip pubblico lo hai anche sotto cg-nat (altrimenti non navighi), solamente che non hai tutte le porte
CGNAT pero' non solo implica la mancanza effettiva di IP pubblico (in quanto conta l'indirizzo che viene assegnato all'interfaccia), ma implica anche la non raggiungibilita' dall'esterno, quindi l'applicazione di filtri in entrata, che sempre vanno dichiarati in quel documento se presenti.
handymenny assolutamente no, IP privato e' inteso proprio come IP non pubblico quindi anche quello che oggi viene chiamato CGNAT.
simonebortolin mettere i clienti sotto cg-nat che è loro facoltà in quanto più o meno tutti lo stanno facendo
Ma non ha alcun senso per chi ha la bellezza di 20.761.088 indirizzi IPv4 (e contando solo quelli annunciati da AS3269), visto che fare CGNAT su quella scala significa aumentare i costi (se non di apparati anche solo di progettazione e manodopera), in cambio di... uhm, "nulla di concreto"?
simonebortolin ipv6. Hanno tutta la possibilità di realizzare un buon deploy in una o due settimane....
Mah secondo me, tutti quelli che credono che deployare IPv6 su scala in maniera totalmente sicura sia una cosa da nulla, non hanno mai avuto modo di doverlo fare nella pratica. Cioe', un conto e' configurare indirizzi e rotte e "incrociare le dita", un conto e' (continuare ad) avere poi il pieno controllo della propria rete, anche per quello che e' a tutti gli effetti un "protocollo parallelo", con tante (troppe) opzioni e "casi limite" che e' difficile tenere totalmente sotto controllo come per IPv4. Se ad esempio "segment routing frammentato" non ti fa venire i brividi, beh, ecco questo intendo quando dico che la si prende sempre troppo facilmente... Poi non lamentiamoci il lontano giorno in cui si scopriranno APT (Advanced Persistent Threats) completamente invisibili all'amministratore di rete perche' utilizzeranno chissa' quale combinazione oscura di opzioni IPv6 per bypassare tutte le protezioni a livello di rete...
simonebortolin Un deploy di non mi ricordo che provider in IPoE non italiano assegna sempre un ip 172.X e poi fa NAT 1:1 tra la CPE ed il BRAS, tecnicamente questo cosa sarebbe sempre IP privato anche se lo hai pieno?
Si' esatto. Non potrebbero scrivere "si'" in un documento equivalente a quello italiano.
[cancellato] la NewCo avrà bisogno sicuramente di spazio di indirizzamento per l'infrastruttura attiva, difficile bastino solo indirizzi privati RFC 1918
Telecom pero' usa gia' da molti anni indirizzi RFC1918 per l'infrastruttura attiva, perche' non dovrebbero piu' bastare? Non credo proprio che le mgmt degli OLT poi potrebbero volerle mettere sotto IP pubblico, non sono e non devono essere raggiungibili dall'esterno. (Che poi OLT e in generale tutte le offerte attive non dovevano rimanere in Telecom?)
L'accounting e' il medesimo e il logging non sussiste se fai in modo di avere un'associazione statica (quindi definita a priori e non ambigua) tra [IP CGNAT + concentratore] e [IP pubblico + range di porte pubbliche]. In quel caso non serve loggare anche la porta sorgente privata lato CGNAT perche' in ogni caso le CPE non loggano l'associazione tra IP + porta lato LAN e porta lato WAN, quindi l'informazione della porta sorgente privata non e' una informazione forensicamente utile da mantenere per l'ISP. 😉
[cancellato] tanti auguri a farlo solo via software con la mole di utenze che può avere TIM
Ma mica lo devi centralizzare in un unico moloth gigante che fa CGNAT per tutta Roma o peggio, che ne sai che non lo fanno i vari BRAS in maniera distribuita, senza necessita' di usare schede hardware aggiuntive per una funzione che potrebbe essere benissimo implementata ad esempio negli ASIC gia' presenti?
gandalf2016 ecco, appunto, sigh, come non detto. Ah quanti danni possono fare i commerciali se vengono ascoltati dalle persone sbagliate, che possono prendere decisioni finanziarie senza saper entrare nel merito tecnico in maniera approfondita...
gandalf2016 Comunque alla fine NAT in software è una di quelle funzioni che non viene malissimo
Beh se fatto con cognizione di causa, forse e' anche meglio farlo in software, cosi' come il firewalling in generale... Sicuramente piu' flessibile e piu' trasparente. Pero' ecco non andando a deviare traffico verso il moloth centralizzato con millemila tunnel che si intrecciano a caso peggio di spaghetti sottili in un colabrodo agitato...
mark129 Piuttosto, puoi verificare se i concentratori di back up per tutta Italia sono (tutti e solo) a Roma? Perché così ho capito io.
Magari stanno riciclando cosi' i poveri concentratori di adsl@alice6...
[cancellato] A me fa tanto strana sta cosa, dovrebbero tirarsi nel core tutte le VLAN di consegna delle centrali OLT... no, no... voglio proprio sperare di no.
Faranno tunneling layer2 cosi' come avveniva per adsl@alice6... Ecco sarebbe interessante verificare se anche qui il TCP MSS (o direttamente la MTU della PPPoE) sia inferiore al valore normale, quando capita questa cosa.