Vodafone inizia a mettere i clienti in CG-NAT?

dalmark Significa che, contrariamente alle raccomandazioni degli enti preposti (RIPE, in questo caso), assegnano una classe di IP con maschera da 63 bit (/63, stessa cosa di IPv4, solo su 128bit di indirizzo invece che 32), permettendo all'utente 4 2 VLAN massime (ammesso che non ne usino una per la connettività tra router e Vodafone stessa).

Le raccomandazioni sono almeno una /56, con 256 VLAN fino ad addirittura una /48, che ne offre 65536. Con le assegnazioni che vengono date agli ISP e le dimensioni delle stesse non dovrebbero avere problemi a dare una /48, ma per uso domestico anche una /56 va più che bene.

itsmatteomanf

itsmatteomanf (ammesso che non ne usino una per la connettività tra router e Vodafone stessa).

Sembrano usare la 2a02:8108::/48 per le p2p BNG-CPE (ci stanno 65k clienti in una /48) e le rimanenti per la prefix delegation.

Praticamente """buttano""" una /64 per la P2P e poi fanno i braccini corti con la prefix delegation

dalmark Qui trovi tutte le best practice https://www.ripe.net/publications/docs/ripe-690

tldr:

IPv6 is not the same as IPv4
Assigning prefixes longer than /56 is strongly discouraged, so your choices are:

• If you want a simple addressing plan use a /48 for each end-user. This will work very well for customers coming from other ISPs, those that have their own ULA, or have been using transition mechanisms. This will also be easier when you have a mix of customers using the same infrastructure, whether they are residential customers, SMEs or even large corporates.
• Differentiate amongst types of customers, even if this will increase the complexity of your network and those of your customers, by offering /48 for business customers and /56 for residential customers.

In order to facilitate troubleshooting and have a future proof network, you should consider numbering the WAN links using GUAs, using a /64 prefix out of a dedicated pool of IPv6 prefixes. If you decide to use /127 for each point-to-point link, it is advisable to allocate a /64 for each link and just use one /127 out of it.

Non-persistent prefixes are considered harmful in IPv6 as you can't avoid issues that may be caused by simple end-user power outages, so assigning persistent prefixes is a safer and simpler approach

[...]

Many operators might perceive the assignment of large IPv6 prefixes to end customers as wasteful, but the reality is that decisions should be based on the IPv6 protocol architecture design. For example, Tony Hain calculated that assigning a /48 to every human on Earth, and never recovering those, will still mean that IPv6 would have a lifetime over the 480 years and we could repeat that several times
On that timescale, there will be other reasons, not just scarcity of IPv6 addresses, that will require the IETF to design a successor to IPv6.

LorenzoB Prova comunque, così vediamo come fa lo switch.
Non dovrebbero esserci dati troppo sensibili, se vuoi puoi mandarmelo su telegram (stesso username) e provvedo io a vedere/censurare.

Se riesci cattura lo switch quando apri le porte.

Pace se dovesse essere HTTPS il TR-069.

edofullo Ce l'ho fatta!

Ho eliminato tutti i pacchetti superflui e ho lasciato solo i pacchetti PPP tra la VSR e il gateway VF. Non ci dovrebbero essere informazioni sensibili apparte il MAC e il seriale della Station, ma non mi interessa tanto non la uso.

Giusto per capire origine-destinazione dei pacchetti in Wireshark: il MAC della VSR ha vendor "Vodafone Italia S.p.A."; il MAC del gateway VF ha vendor "HUAWEI TECHNOLOGIES CO.,LTD".

Ecco il link ai dump: https://ufile.io/f/l3zyv

• PPPoE default è la negoziazione dell'IP privato
• PPPoE switch è lo switch da IP privato a pubblico

Dalla veloce occhiata che gli ho dato sembra che cambi il parametro CGN nel campo Password durante l'autenticazione. CGN dovrebbe stare per CG-NAT ed è a 0 se la VS vuole IP privato, ad 1 se vuole IP pubblico.