simonebortolin infatti non c'è...
Sky WiFi passerà a MAP-T entro il 2021
- Modificato
Comunque c'è già qualcuno che hosta roba in MAP 1:1, vedo una marea di VPN IKE ed oltre 2200 risultati in totale 
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.
- Modificato
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)
- Modificato
edofullo
Facendo un rapido check anche il mio tool sembra comportarsi correttamente se impostato con i giusti parametri.
Sarebbe da creare una lookup table del IPv6 e applicare la configurazione in maniera automatica così da ridurre l'intervento del utente.
Sky MAP-T Visualizer
- Modificato
hitech95 Facendo un rapido check anche il mio tool sembra comportarsi correttamente se impostato con i giusti parametri.
Confermo usando i dati dell'utente che matcha l'IPv4 senza problemi.
Ad ora sappiamo che la 2a0e:410::/32 (101.58.0.0/16) è l'unica usata per il MAP 1:1 quindi si potrebbero aggiustare i parametri in automatico quando l'IPv6 appartiene a quella classe.
Anche perchè facendo una ricerca su shodan con l'altra classe (101.59.0.0/16) non esce nulla.
Il problema più che altro è sul IPv4 Prefix in 1:16, visto che ce ne sono diversi e non sono mostrati sullo sky hub.
Io chiederei l'IPv4 all'utente, da quello estrarrei la /20 di appartenenza.
Idem per l'IPv6, accetterei pure un IPv6 completo ed estrarrei la /48 di appartenenza... una perdita di generalità (a sto punto funziona solo con Sky) ma un miglioramento all'usabilità. Dimmi se noti problemi.
Forse si potrebbe mettere una checkbox Sky/Altro Operatore
- Modificato
edofullo 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)
Stavo guardando meglio la conf che hanno in MAP-T 1:1.
Allora, abbiamo detto PSID_LEN = 0 E PSID_OFF=0.
Se la pool v6 è una /32 e assegnano la solita /48 EA_LEN=16 come sempre.
Quindi tutti i 16 bit identificano l'IP finale del utente.
Ora considerando che per ora le pool v4 sono rispettate sappiamo che loro hanno una:
101.60.0.0/13
|--> 101.56.0.0/14 Pool Subscrivers
|--> 101.56.0.0/15 Pool Subscrivers MAP-T 1:16
|--> 101.58.0.0/15 Pool Subscrivers MAP-T 1:1
|--> 101.60.0.0/14 Pool InfrastructureQuindi ad occhio io vedo che hanno un solo bit per creare due pool per gli utenti in MAP-T 1:1
101.58.0.0/16
101.59.0.0/16Ho fatto io i conti male o hanno ridotto il EA_LEN?
Sulla slide parlavano di 32 blocchi da 4K utenti...
Mi vien da pensare che la pool v6 MAP-T 1:1 sia più "piccola" ovvero una /36.
Bene che cercherà di riprendere contatti con AVM, anche perché Sky WiFi ultimamente sta spopolando, vedo molte reti chiamate così in giro per la mia città
Supreme69 Se vuoi passivo in A&B mi sa che è l'unica rete decente
simonebortolin direi proprio di si, aspettando Iliad. Ma mi sembrano su un posizionamento di mercato diverso, Sky è più "premium" da quel punto di vista
Oggi mi hanno completato il passaggio a Sky wifi e l'ip wan inizia per 51. Dopo provo a sostituire lo Sky hub con il fritz
DrCarter33 'ip wan inizia per 51
Dual Stack
DrCarter33 Dopo provo a sostituire lo Sky hub con il fritz
Funzionerà, però hano detto che prima o poi verranno migrati in MAP-T dopo essere stati avvisati.
[...] those with 3rd party CPE are being excluded for the time being, but we will have to migrate them eventually. We'll be sending them communications first.
edofullo e vabbè pazienza. Metterò il fritz in cascata quando succederà, sempre nell'attesa di aggiornamento da avm
tanto che è valido questo FRITZ... io ne posseggo alcuni dsl e all'epoca non valevano niente se non l'avere gestione voip e cordless molto user friendly
gianry che novità
Allora ragazzi eccomi, attivo con successo in MAP-T 1:1 su router non Sky "rottame" Hub... vi porto una notizia buona ed una cattiva, purtroppo.
La buona è che ha funzionato (quasi) tutto alla perfezione al primo colpo e che il setup è semplicissimo, basta attaccare il cavo, mettere la VLAN e aspettare una mezz'oretta per fare in modo che il dhcp server si accorga che hai cambiato modem e ti dia un nuovo IP (a ogni riavvio poi è ovviamente istantaneo).
Testato il MAP 1:1 e funziona, ho testato la porta 8000 ed ha funzionato senza problemi, mentre non sono riuscito con la 80, però guardando shodan sembra esserci gente che ci riesce quindi magari sbaglio qualcosa io.
@hitech95 avevi ragione tu, usano /36-/20 con una length minore... valli a capire.
[ 3025.137602] nat46: configure device (map-wan6_4) with 'local.style MAP local.v4 101.58.48.0/20 local.v6 2a0e:410:3000::/36 local.ea-len 12 local.psid-offset 6 remote.v4 0.0.0.0/0 remote.v6 2a0e:402:101:100::/64 remote.style RFC6052 remote.ea-len 0 remote.psid-offset 0'
[ 3025.184694] nat46: insert new rule into device (map-wan6_4) with 'remote.style MAP remote.v4 101.58.48.0/20 remote.v6 2a0e:410:3000::/36 remote.ea-len 12 remote.psid-offset 6'root@OpenWrt:~# ifstatus wan6_4
{
"up": true,
"pending": false,
"available": true,
"autostart": true,
"dynamic": true,
"uptime": 1577,
"l3_device": "map-wan6_4",
"proto": "map",
"updated": [
"routes",
"data"
],
"metric": 0,
"dns_metric": 0,
"delegation": true,
"ipv4-address": [
],
"ipv6-address": [
],
"ipv6-prefix": [
],
"ipv6-prefix-assignment": [
],
"route": [
{
"target": "2a0e:410:3xxx::653a:3xxx:0",
"mask": 128,
"nexthop": "::",
"source": "::/0"
},
{
"target": "0.0.0.0",
"mask": 0,
"nexthop": "0.0.0.0",
"source": "0.0.0.0/0"
}
],
"dns-server": [
],
"dns-search": [
],
"neighbors": [
],
"inactive": {
"ipv4-address": [
],
"ipv6-address": [
],
"route": [
],
"dns-server": [
],
"dns-search": [
],
"neighbors": [
]
},
"data": {
"firewall": [
{
"type": "nat",
"target": "SNAT",
"family": "inet",
"snat_ip": "101.58.53.x"
},
{
"type": "rule",
"family": "inet6",
"proto": "all",
"direction": "in",
"dest": "wan",
"src": "wan",
"src_ip": "2a0e:410:3xxx::653a:3xxx:0",
"target": "ACCEPT"
},
{
"type": "rule",
"family": "inet6",
"proto": "all",
"direction": "out",
"dest": "wan",
"src": "wan",
"dest_ip": "2a0e:410:3xxx::653a:3xxx:0",
"target": "ACCEPT"
}
],
"zone": "wan"
}
}Veniamo al lato dolente... che è quello che ci aspettavamo: le performance.
Il povero Belkin RT3200 con stesse impostazioni che avevo in DS non riesce a tirare più di 500 Mbps mentre teneva il gigabit senza problemi in Dual Stack... un core sta al 100% mentre l'altro sta intorno al 60% (con irqbalance abilitato)
Questo significa che, come ci aspettavamo, la traduzione è una bestiaccia non da ridere a livello computazionale se fatta in software però alla fine poteva anche andare peggio se consideriamo che il belkin costa nuovo circa 100€
Ovviamente questo riguarda solo IPv4, in IPv6 si naviga senza problemi a line rate... quindi è un problema che scomparirà quando (speriamo) IPv4 sarà rilegato a una nicchia di servizi legacy.
Sospetto che se mai AVM aggiungerà il supporto ai FritzBox sul 7530 le performance saranno impetose, e forse pure sul 7590... a meno che non riescano in qualche modo ad accelerarlo in hardware ma su dispositivi vecchi la vedo dura.
Per quanto riguarda la richiesta del prefisso non sono riuscito a testare, visto che una volta preso il prefisso mi viene ridato sempre quello, ed il prefisso l'ho preso prima di settare l'opzione.
Ho verificato con tcpdump che la richiesta è passata con successo al DHCP server... vedremo nei prossimi giorni/mesi se cambierà.
edofullo Testato il MAP 1:1 e funziona, ho testato la porta 8000 ed ha funzionato senza problemi, mentre non sono riuscito con la 80, però guardando shodan sembra esserci gente che ci riesce quindi magari sbaglio qualcosa io.
Io non ho capito se è credibile tutta questa gente che apre varie porte su Sky MAP 1:1, non è che sono testing interni?
edofullo Sospetto che se mai AVM aggiungerà il supporto ai FritzBox sul 7530 le performance saranno impetose, e forse pure sul 7590... a meno che non riescano in qualche modo ad accelerarlo in hardware ma su dispositivi vecchi la vedo dura.
Beh dai sul 7590 non ci dovrebbero essere così tanti problemi....
[cancellato]
simonebortolin Beh dai sul 7590 non ci dovrebbero essere così tanti problemi....
Perché tu credi che quegli affarini lì tengano un SNAT line speed in software? 
credighe ai ufo