• [cancellato]

IMHO in LAN usare DHCPv6 stateful è la soluzione ottimale - a meno che non sia una piccolissima LAN con poche interazioni per i dispositivi locali - specialmente quanto hai l'integrazione DHCP-DNS e per motivi di sicurezza è assolutamente sconsigliabile che siano i singoli dispositivi a registrarsi con il DNS, è meglio che l'unico autorizzato ad aggiornare il DNS sia il DHCP. Così hai anche i log centralizzati e puoi continuare a fare reservation degli IP evitando che SLAAC ne usi uno perché in quel momento non è in uso (anche se le collisioni dovrebbero essere assai rare).

SLAAC per me era una buona idea nel 1996 (la specifica di DHCP è solo del 1993, completata nel 1997) quando i link erano lenti, costosi, i server pochi e con poche risorse e i sistemi molto centralizzati. Delegare ai router sembrava allora sensato. Nel 2020 molto meno, tranne dove non ha senso usare DHCP.

4 mesi dopo

Per altro l'IPV6 di fastweb funziona su qualunque operatore, basta possedere un IP pubblico statico v4.
Qualcuno conosce altri border relay oltre al blasonato 81.208.50.214?
Facendo un confronto usandolo con Telecom, funziona mostruosamente meglio del dual stack telecom!
Il dual stack telecom, a me perde un sacco di pacchetti, ha più latenza del 6RD fastweb su rete telecom ed ha il difetto enorme di cambiare rete /64 ad ogni connessione. Una assurdità per IPv6.
Non si può pretendere da un servizio sperimentale comunque! Peccato lo sia da 10 anni! Uscirà dalla sperimentazione quando sarà ora di pensionarlo di sto passo!
Ad oggi ormai tutte le console moderne e i sistemi operativi prediligono IPv6 per vari motivi. Non parliamo di tutti i dispositivi IoT e i vari assistenti domestici! Siamo in piena epoca IoT e siamo castrati da IPv4!!!

    • [cancellato]

    MarcoMondin basta possedere un IP pubblico statico v4.

    Non serve sia statico, basta riconfigurare a modo il tunnel 6in4 al variare dell'IP WAN 😉

      MarcoMondin Per altro l'IPV6 di fastweb funziona su qualunque operatore, basta possedere un IP pubblico statico v4.

      Cos? Non richiede autenticazione il tunnel?

      Io uso il tunnel HE che mi porta il traffico IPv6 a Londra, se non avessi già subnettato la mia bella /48 sarebbe stata meglio la /64 di FW...

      MarcoMondin Facendo un confronto usandolo con Telecom, funziona mostruosamente meglio del dual stack telecom!

      Ci mancherebbe altro, quello è una schifezza immonda.
      È davvero sperimentale...

        Sky come va in IPv6? E Dimensione?

        [cancellato] Certo, ma così ti ritroveresti il prefix /64 che cambia per ogni cambio di IP, giusto?

        Per il fatto che ti danno connettività senza autenticazione direi che non è un grosso problema per Fastweb avendo un mapping 1:1 IPv4-Prefisso... Ci fossero abusi basta una banale conversione hex->dec per trovare l'IPv4 responsabile

          Scusate la domanda ma a cosa dovrebbe servirmi un indirizzo IPv6?

          • lore20 ha risposto a questo messaggio
            • [cancellato]

            edofullo Non richiede autenticazione il tunnel?

            No...

            lore20 Certo, ma così ti ritroveresti il prefix /64 che cambia per ogni cambio di IP, giusto?

            Sì, assolutamente sì.. d'altronde, è una soluzione che di per sé è già un po' una schifezza (tunnel v6-in-v4)... va bene per smanettare e provare, non ci andrei a cablare una rete di casa con IPv6 statici però.
            Con indirizzi dinamici tutto sommato si può anche fare.

            eang Un singolo indirizzo IPv6 ad abbastanza poco, ti darebbe la possibilità di accedere ai siti IPv6-only, ma non conosco siti di qualche utilità che non siano raggiungibili anche in IPv4.

            Il grosso vantaggio è che il modello di utilizzo previsto per l'IPv6 dovrebbe prevedere il completo superamento del NAT. Le linee guida prevedono che l'operatore assegni all'utente finale non un indirizzo, ma un prefisso, quindi tanti indirizzi. Il router tuo di casa non opererebbe più da NAT e ogni dispositivo connesso accederebbe ad internet con un suo proprio IP pubblico derivato da quell'indirizzo. Quindi addio problemi di port-forwarding... E soprattutto per gli ISP addio Carrier-Grade NAT!

            Per quanto riguarda me, ad esempio, ho ottenuto un prefisso /48 tramite tunnel da un provider americano (Hurricane Electrics) e ho assegnato IPv6 pubblici statici a vari dispositivi da casa che possono essere raggiunti da remoto. Grazie a IPv6 ogni dispositivo ha il suo indirizzo e non vanno fatte cose strane tipo reverse-proxy o differenziare le porte esterne che uso per raggiungere ogni dispositivo.
            Ovviamente per ora si tratta molto di "baloccarsi", visto che è raro che in Italia possa trovare un'altra connessione IPv6 da cui accedere ai miei servizi, ma le cose lentamente stanno cambiando...

            • eang ha risposto a questo messaggio
            • eang ha messo mi piace.

              lore20 Hmm capisco, ma l'idea di avere tutti i miei device esposti ad internet non so se mi alletta. Il NAT è anche una forma di protezione, basta un unico firewall sul ruoter WAN e sei apposto. Con l'IPv6 non c'è modo di fare NAT se si desidera?

                eang Non è necessario, ti basta un firewall: anche se non sono "NATttate" le connessioni transitano comunque tutte dal router/gateway.

                Puoi mettere come regola di default per il forwarding router <-> rete interna un bel DROP, e aprire solo lo stretto necessario a livello di ip, porta, o combo ip-porta.

                Io ad esempio ho protocollo icmp (ping/traceroute) abilitato verso tutti gli ip interni. SSH abilitato verso tutti gli ip di una sottorete, porte 80/443 abilitate solo su specifici ip dove mi servono, tutto il resto chiuso...

                Credo (qua non sono sicuro) che a livello di performance sia leggermente più veloce un firewall che un nat, ma roba di microsecondi per gamers fissati col ping!

                • eang ha messo mi piace.

                Capisco, grazie. Effettivamente così diventa interessante...

                Non sono esposti totalmente, il dispositivo continua a fare funzioni di router e firewall, solo che non dovrà più fare anche NAT, che significa: niente modifica di ogni singolo pacchetto in entrata/uscita... meno uso di CPU/memoria per i router e anche meno tempo (anche se come ha detto @lore20 parliamo di microsecondi)

                  Un firewall basta! Si evita il NAT con tutto quello che ne consegue! Molto meglio!
                  Poi si possono costruire grossi sistemi IoT interfacciati agli assistant! Non è male!
                  Ormai i SERVER e i PC sono tutti pronti per una transizione trasparente. Forse alcuni HW dei providers non lo sono, ma i tempi per una transizione trasparente non sono solo maturi, tra un po' diventano avariati!

                    • [cancellato]

                    eang Il NAT è anche una forma di protezione, basta un unico firewall sul ruoter WAN

                    NAT e firewall sono due cose diverse, anche se per come funziona il NAT in ambito consumer è analogo a una forma grezza di firewall. Ma se fai ad esempio NAT 1:1 non ha quel tipo di protezione. Con IPv6 diventa indispensabile un firewall, almeno sul router (o subito dietro).

                    eang Con l'IPv6 non c'è modo di fare NAT se si desidera?

                    Sì può fare - purché si usi un router che lo supporti, anche se è sconsigliato. Però ci sono situazioni in cui può diventare necessario, ma nella maggior parte dei casi togliere NAT di mezzo semplifica la vita.

                    x_term meno uso di CPU/memoria per i router e anche meno tempo (anche se come ha detto @lore20 parliamo di microsecondi)

                    Con le connessioni a 1Gb però comincia a diventare non irrilevante - tant'è che i router senza sufficienti risorse di calcolo devono trovare modo per accelerarlo pena connessioni più lente.

                    MarcoMondin Forse alcuni HW dei providers non lo sono,

                    Credo che i motivi siano altri - dover modificare e validare l'intera infrastruttura, il training di tutti gli operatori, perdere alcune fonti di reddito come l'affitto degli IP statici, un aumento della complessità del supporto all'utente finale, il rischio che gli smanettoni si facciano il datacenter in cantina o soffitta....

                    Per chi fosse interessato a come siamo messi rispetto al resto del mondo:

                    https://ipv6ripeness.ripe.net/

                    eang l'IPv6 comunque nasce soprattutto perché gli IPv4 sono finiti, cosa che sta costringendo gli ISP a usare il NAT, quindi è progettato in modo che non serva più fare "porcate" come il NAT. Il NAT è un gigantesco pasticcio, per funzionare deve manipolare i pacchetti a diversi livelli violando completamente il funzionamento a strati dei protocolli di rete. Non ce ne libereremo facilmente ma l'IPv6 è la soluzione.

                    Questo dal punto di vista tecnico ovviamente, all'utente medio cambia poco e niente... A parte forse se gioca online

                    • [cancellato]

                    Se gli ISP non implementeranno IPv6 come dio comanda, temo che di pasticci ne vedremo ancora. Se ad esempio non ascoltano le raccomandazioni di dare almeno un /56 e daranno solo /64 ci sarà chi farà NAT tra quelli e gli indirizzi ULA per usare le sue subnet. O se ti cambiano il prefisso ad ogni riavvio costringendoti a trovare un modo per evitare il renumbering. Se poi uno cambia operatore spesso, ha di nuovo questo problema....

                    3 mesi dopo
                    2 messaggi sono stati spostati in Sky Wifi e IPv6.
                    4 giorni dopo

                    MarcoMondin Per altro l'IPV6 di fastweb funziona su qualunque operatore, basta possedere un IP pubblico statico v4.

                    È legale/lecito utilizzarlo da un altro operatore?

                      • [cancellato]

                      stemax97 Buona domanda... Probabilmente sì anche perché l'indirizzo v4 di fatto rimane visibile anche negli indirizzi sorgenti v6 "tradotti".

                        Informativa privacy - Informativa cookie - Termini e condizioni - Regolamento - Disclaimer - 🏳️‍🌈
                        P.I. IT16712091004 - info@fibraclick.it

                        ♻️ Il server di questo sito è alimentato al 100% con energia rinnovabile