hitech95 3rd party CPEs, I've been engaged by only one vendor so far, I believe due to your forum thread

Un uccellino mi dice AVM? Speriamo...

hitech95 PSID Offset, we intentionally chose the default recommendation of 6 bits, which excludes the privileged ports 0-1024. It has been observed that there are firewalls and other such appliances out on the internet that don't like seeing flows sourced from these privileged ports. The side-effect of this design decision, is that the port ranges are carved up in to several non-contiguous blocks. You could also say there's a marginal privacy benefit of this as well, that flows are less identifiable based on source ports (unless the destination has visibility of the MAP rule being used)

Ha senso... son curioso di vedere cosa farà Iliad con 4rd. In francia hanno un range unico.

hitech95 We'll be sending them communications first

Mi sembra una buona idea...

hitech95 Currently we're opting out back to dual stack, but then manually rolling those over to MAP-T 1:1

Due cambi di prefix per nulla 🙄

hitech95 Riesci a fare un check se cè l'hint?

Dammi 10 minuti e verifico

              [cancellato] Credo che Technicolor lo usi - non so quante altre CPE sono basate su RDK.

              Da quello che dicono qui lo usano solo per DOCSIS: https://www.technicolor.com/news/connectedhome/technicolors-ashwani-saigal-explores-how-future-open-software-broadband-access-will-improve

              Per XDSL invece usano openwrt, infatti se non erro i kit di broadcom si basano proprio su di esso

                hitech95 Riesci a fare un check se cè l'hint?

                Ad Agosto quando me li hai mandati non c'era, c'è però la Vendor class in questo formato "4.10.0.1|001|SR203|[redacted]"

                Immagino che il primo sia la versione del firmware (kernel magari?) il terzo il modello del router e l'ultimo il numero seriale.

                Però in una settimana io sono ancora sullo stesso IPv4 ed IPv6 quindi di certo non cambia frequentemente.

                    edofullo Due cambi di prefix per nulla 🙄

                    Credo che li mandano in map-t quando hanno verificato che effettivamente tutto funziona.

                    edofullo Però in una settimana io sono ancora sullo stesso IPv4 ed IPv6 quindi di certo non cambia frequentemente.

                    Io ho un uptime di 26gg e da allora non mi è mai cambiato. Non era cambiato nemmeno prima quando ho riavviato il server e ho fatto manutenzione (un paio di ore).
                    Direi bene

                          hitech95 Beh ma in dual stack non vedo perchè debba non funzionare.

                          Se MAPT 1:16 andava probabilmente andrà pure 1:1

                            x_term edit: da oggi mi è cambiato l'IPv4 in 101.58.xxx quindi credo di essere in MAP-T

                                EmilioCapuano Hai attivato DMZ o Port Forwarding? Dovresti essere in 1:1

                                    edofullo ho appena controllato dall'app e non c'è né DMZ né Portforwarding, perdona l'ignoranza ma come faccio a controllare se sono 1:1? Che vantaggio/svantaggio c'è?

                                        EmilioCapuano ho appena controllato dall'app e non c'è né DMZ né Portforwarding

                                        Strano, quella mi sembra essere la subnet del 1:1, la stessa dell'altro utente. Poco male comunque.

                                        Con cosa inizia l'IPv6? 2a0e:4xx:?

                                        EmilioCapuano perdona l'ignoranza ma come faccio a controllare se sono 1:1?

                                        Un metodo l'ho descritto qua edofullo ma non c'è bisogno che tu lo faccia se non ti interessa.

                                        EmilioCapuano Che vantaggio/svantaggio c'è?

                                        È l'equivalente dell'IP Pubblico invece del CGNAT.

                                                  EmilioCapuano Al posto delle x?

                                                  Oppure se vuoi girami su telegram la pagina Rete Sky dello Sky Hub oppure postala qua, appena un mod la vede la rimuove.

                                                  Non ci sono informazioni troppo riservate, solo gli indirizzi IP che usi attualmente ma se non hai nulla esposto in internet (come hai detto sopra) non è un problema.

                                                      edofullo guarda non riesco ad entrare da 192.168.0.1, non capisco perché. In ogni caso ti scrivo qua entrambi gli IP

                                                      [redacted]

                                                          Avm ha rilasciato un aggiornamento per fritzbox. Non ho letto il Changelog, magari c'è mapt

                                                            EmilioCapuano Ho visto ora che mi sono dimenticato di risponderti.

                                                            Sei nello stesso range dell'altro utente, dovrebbe essere 1:1

                                                            Strano se non hai attivato Port Forwarding, uPnP, DMZ o simili ma tant'è, meglio così.

                                                              In seguito ad alcune domande nate nella chat Telegram FibraClick ho provveduto a chiedere a Patterson come al solito:

                                                              How are IPv6 PD assiged from the pool? are they sequential or random, etc? This is just to better understand the efficacy of the IA PD hint. Is the SKY hub sending the Hint? BAck in august from TCP dump this was not the case.

                                                              DHCPv6 PD leases will be assigned linearly from the Server's perspective. If the Client hints for a prefix and it's available, it should be able to obtain it.
                                                              Our Sky Hubs don't always include the old prefix in the Solicit's IA_PD as a hint, but they do sometimes under some scenarios.

                                                              Another question, what if I try to ping a MAP-T CPE from outside is the request taken by the BR? We know that from a request originating from the CPE a field is set to idetify the right client to route the reply to. What about the case of MAP-1:1? an ID to idetify the CPE might be not necessary in this case.

                                                              Pinging through the BR to the CPE should work in 1:1, but as you pointed out, if the IPv4 doesn't live on the CPE itself, then it will need to DNAT it through to somewhere else. This will be implementation dependent, our Sky Hub for example doesn't have the public IPv4 bound to an interface.

                                                              What about a subscriber want to talk to some other user on the same shared IPv4? We know that Opwnert is not aware of the IP of the map interface but I'm not sure how the Sky Hub handle it.

                                                              Again this will be implementation dependent, but customers sharing the same IPv4 address in 16:1 should still be able to communicate with each other over IPv4. As above, the IPv4 address (and therefore /32 route) doesn't exist on our Sky Hub, so packets destined for the shared IPv4 will still follow the default route out and get translated to IPv6.

                                                              We are trying to contact AVM to have a feedback about a possible MAP-T implementation but the request does not get forwared to the right departement. Most of people that want to use a 3rd paty CPEs is from them. (Easy UI, and stable firmware)

                                                              Let me know how you get on with AVM, I think we may have had a very brief chat with them a while ago, I'll ask around internally to see if we have contacts and can restart that conversation.

                                                                hitech95 Pinging through the BR to the CPE should work in 1:1, but as you pointed out, if the IPv4 doesn't live on the CPE itself, then it will need to DNAT it through to somewhere else. This will be implementation dependent, our Sky Hub for example doesn't have the public IPv4 bound to an interface.

                                                                Questa è una seccatura.

                                                                Confermo che OpenWRT non registra l'IPv4 che riceve via MAP-T come suo, semplicemente imposta delle regole SNAT e spedisce all'interfaccia nat46 che lo converte in IPv6.

                                                                Questo vuol dire che in caso di Hairpin NAT alla meglio si fa tutto il giro dal BR, alla peggio non funziona proprio.
                                                                Inoltre non so come potrebbe comportarsi con flussi non TCP/UDP, che in MAP 1:1 dovrebbero tecnicamente funzionare.

                                                                Ovviamente la "acquisizione" del IP come proprio potrebbe funzionare solo in 1:1

                                                                hitech95 DHCPv6 PD leases will be assigned linearly from the Server's perspective.

                                                                Ho compilato la mia patch per OpenWRT e l'ho installata sul Belkin, se sono stato passato in MAP-T punto a farvi sapere se si riesce.

                                                                Non vedo troppi problemi, soprattutto se si richiede un prefisso "alto".
                                                                Inoltre in questo modo dovrebbe essere possibile pure richiedere uno specifico IPv4, volendo.

                                                                Dai dati che mi ha passato @EmilioCapuano le impostazioni per il map 1:1 dovrebbero essere:

                                                                IPv6 pool: 2a0e:410::/32
                                                                Endpoint PD: 2a0e:410::/48
                                                                Mapped IPv4: 101.58.0.0/16
                                                                PSIDLEN: 0
                                                                PSIDOFF: 0

                                                                Il map 1:1 è garantito dal fatto che 48-32 = 16 bit che è uguale alla lunghezza massima del port number (quindi viene assegnato un solo range 0-65535)

                                                                      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