Fastweb filtra SIP?

[Blak]

Ho un problema per quanto riguarda l'utilizzo di Ekiga. In particolare il
NAT viene correttamente riconosciuto come Open NAT e lo stun impostato ma,
seppur riesca ad inviare correttamente (e infatti l'interlocutore mi vede e
mi sente perfettamente) continuo a non ricevere nessuno stream in ingresso
(verificato sniffando un po' di pacchetti). Ora, ho posto il problema sulla
ML di Ekiga pensando soprattutto ad un baco ma sostanzialmente non mi hanno
saputo dire nient'altro che "l'ISP blocca le porte". Non mi risulta che
fastweb filtri SIP, o sbaglio? confermate? Non capisco perchè il server
stun, che dicono funzionante, non sortisca alcun effetto. Mi sa tanto di
"c'è un baco da qualche parte ma non abbiamo voglia di cercarlo", ma prima
vorrei vederci chiaro sul particolare setup.

Comunque, altra domanda: come stiamo messi con la number portability di
numeri telecom verso altri OLO? Perchè mi sono anche un po' rotto i
coglioni di sti problemi, se questa è la modernità che propone fastweb si
stava meglio quando si stava peggio.

[trip65]

Qualche stranezza ci sta :
io uso perfettamente il voip eutelia su fastweb impostando lo stun per gli
apparecchi telefonici ip.
Non c'è bisogno di impostare lo stun se uso il pc con vari software voip e
sorpresa, ho acquistato un cellulare nokia con wi-fi e possibilità di
impostare account sip e va perfettamente con fastweb SENZA stun.
Utilizzo un acces point d-link connesso alla cpe direttamente e natto a mia
volta su lan interna (doppio nat) e uso il cellulare come cordless wi-fi sip
quando sono a tiro di segnale wi-fi
La cosa pazzesca è appunto che per i vari apparati voip dedicati (telefoni e
ata) lo stun ci va altrimenti non ricevo..

[Lord Phobos]

cut

E vai, altro nerdometro saltato in aria e da buttare via...

[Macs]

Ciao

In particolare il NAT viene correttamente riconosciuto come Open NAT e
lo stun impostato

Ni = stun.ekiga.net (alias stun.voxgratia.org) e' associato ad un IP
pubblico su rete FW (83.103.82.85) e quindi vede direttamente il tuo IP
MAN.

Se guardi i tuoi log, vedrai che identifica come External IP appunto il
tuo IP MAN, e non l'IP NAT-R come invece avviene con STUN server esterni
alla rete FW.

Infatti proprio perche' lo STUN non vede peraltro alcun NAT (in quanto
l'IP MAN e' associato direttamente alla Eth0 del computer con il client
Ekiga), vi e' un KO quando cerca di instaurare il socket usando il NAT
type che e' stato specificato.


Inserisco nel discorso la 'stranezza' indicata da Trip65 = vari servizi
SIP sono utilizzabili da client SW dietro NAT anche senza l'utilizzo di
STUN server, perche' prendono in considerazione anche gli indirizzi IP
da cui provengono i pacchetti SIP, e non solo quelli forniti nella
comunicazione su tale protocollo.

In tal caso, quando un utente nat-ted si registra/associa al gateway, vi
e' quindi implicitamente una situazione NAT-aware, visto che si dispone
tanto dell'IP MAN (ved. Contact Field in pacchetto SIP di registrazione)
quanto di quello NAT-R associato.


Tuttavia, cio' non e' possibile usando account ekiga.net per una scelta
ben precisa, come indicano anche le testuali parole di Damien Sandras :
==
------------------------------------------------------------------------
"On Ekiga.net, we are not doing that because it would only work with
special numbers but not with other users, so people would have the
wrong impression that everything is setup correctly when it is not the
case."
------------------------------------------------------------------------

Secondo i tuoi log risulta che hai effettuato tutte le prove con il
tuo account ekiga.net -> normale quindi che andasse in KO, tanto usando
le varie NAT patch rilasciate su CVS quanto senza l'utilizzo di STUN.


Morale della favola = usa un altro server STUN, 'pescando' tra quelli
pubblici & esterni alla rete FW, e.g.:
==
* http://www.voip-info.org/wiki/view/STUN
-----------------------------------------
- stun.fwdnet.net (no XOR_MAPPED_ADDRESS support)
- stun.ideasip.com (no XOR_MAPPED_ADDRESS support)
- stun01.sipphone.com (no DNS SRV record)
- stun.softjoys.com (no DNS SRV record) (no XOR_MAPPED_ADDRESS support)
- stun.voipbuster.com (no DNS SRV record) (no XOR_MAPPED_ADDRESS)
- stun.xten.com
- stunserver.org
- stun.sipgate.net:10000
- numb.viagenie.ca (XOR_MAPPED_ADDRESS with rfc3489bis magic number ID)

Dopo lascio comunque una versione arricchita di questo messaggio in coda
anche al tuo thread sulla ML Ekiga.

Comunque, altra domanda: come stiamo messi con la number portability
di numeri telecom verso altri OLO?

Due parole per una veloce ricerca su Internet/Usenet = migrazione e
codice ;).

A meta' Giugno 2008 gli operatori hanno firmato/sottoscritto l'accordo
quadro, che approva le modalita' di attuazione delle varie procedure di
Number Portability, compresa anche quella multipla OLO-OLO di numeri
nativi Telecom :
==
* Annuncio relativo all'accordo quadro tra gli operatori -
http://www2.agcom.it/default.aspx?message=viewdocument&DocID=2362

* Delibera Agcom 27/08/CIR
- http://www2.agcom.it/default.aspx?message=viewdocument&DocID=1866

* Modalita' di attuazione della delibera Agcom 274/07/CONS (con Allegati
i documenti tecnici & verbali)
- http://www2.agcom.it/Default.aspx?message=viewdocument&DocID=2365

* Delibera Agcom 274/07/CONS
- http://www2.agcom.it/Default.aspx?message=viewdocument&DocID=2022

Considerando che gli operatori hanno ancora tempo per adeguare le loro
piattaforme, onde attenersi completamente a quanto previsto da tale
accordo, questa e' l'attuale situazione per le linee FW residenziali :
==
1. Le utenze FW con numerazione Telecom portata su linee ADSL (tanto ULL
quanto Wholesale) possono richiedere/ottenere il codice migrazione
per passare ad altri operatori OLO (Portabilita' Multipla), oppure
rientrare con Telecom (annullamento NP).

2. Le utenze FW con numerazione Telecom portata su linee Fibra non
possono ancora ottenere un codice migrazione.

3. Le utenze FW ADSL/Fibra con numerazione nativa (cioe' non portata da
precedente linea Telecom) possono ancora passare solo ad operatori
terzi, che abbiano sottoscritto appositi accordi bilaterali con FW
per la portabilita' delle rispettive numerazioni native -> e.g.
accordo con Eutelia (che si estende in cascata anche ad alcuni
operatori, che si appoggiano a numerazioni Eutelia per fornire i
propri servizi di fonia su VoIP/SIP).


La questione 2 e' di base tecnica & legata al fatto che il codice di
migrazione sia stato determinato in prima istanza, usando i database
per le linee d'accesso della rete in rame di Telecom Italia.


La questione 3 e' invece solo economica = come previsto da tale accordo
quadro, vi e' un apposito sottoprocesso tecnico di migrazione/passaggio
tra OLO Donating ed OLO Recipient relativo al caso in cui il Donor
(cioe' il proprietario del numero) non sia Telecom Italia.

Tuttavia, gli operatori OLO non usano tale sottoprocesso, poiche' non
sono d'accordo con il prezzo definito a listino Telecom (Ultima Offerta
riferimento 2008) per il servizio di transito del Routing Number (RgN
C60) nei casi in cui non vi sia interconnessione diretta tra la rete
dell'operatore Donor e quella del Recipient.

[Blak]

Il Wed, 15 Oct 2008 04:43:31 +0200, Macs ha scritto:

Prima di tutto grazie per la risposta, sia qui che sulla ML, in pochi
avrebbero avuto voglia di leggere tutto e scrivere altrettante parole. Te
ne sono grato.

Post by Macs
Ni = stun.ekiga.net (alias stun.voxgratia.org) e' associato ad un IP
pubblico su rete FW (83.103.82.85) e quindi vede direttamente il tuo IP
MAN.

Questo lo avevo già notato una delle primissime volte quando feci un
traceroute pensando che il server stun fosse irraggiungibile o down (ed è
capitato talvolta, a quanto ho visto sulla ML). Ma stupidamente non ho dato
peso a questa cosa anche perchè comunque davo per scontato che non vedesse
il mio IP privato.

Post by Macs
Se guardi i tuoi log, vedrai che identifica come External IP appunto il
tuo IP MAN, e non l'IP NAT-R come invece avviene con STUN server esterni
alla rete FW.

Purtroppo non li ho guardati più di tanto per mancanza di tempo, pazienza e
scarsa conoscenza di quei protocolli, ma ora mi rendo conto che in effetti
ci sarei potuto arrivare senza infastidire così tante persone :(

Post by Macs
[...]

Confermo il pieno funzionamento con un server stun differente.
Grazie per i chiarimenti, ne è anche nata una discussione interessante e
che magari può servire anche ad altri in futuro.

Post by Macs

Post by Blak
Comunque, altra domanda: come stiamo messi con la number portability
di numeri telecom verso altri OLO?

Due parole per una veloce ricerca su Internet/Usenet = migrazione e
codice ;).
A meta' Giugno 2008 gli operatori hanno firmato/sottoscritto l'accordo
quadro, che approva le modalita' di attuazione delle varie procedure di
Number Portability, compresa anche quella multipla OLO-OLO di numeri
[...]

Interessante... era ora tra l'altro. Speriamo che si passi in fretta dalle
parole ai fatti, anche se in generale la situazione degli ISP italiani non
mi sembra delle più rosee.
Piccola divagazione estemporanea: tralasciando un attimo il discorso NAT,
da un punto di vista puramente qualitativo mi ritengo sicuramente più che
soddisfatto del servizio offerto ma trovo discutibili molti aspetti della
politica aziendale (della quale, a mio avviso, il NAT ne è in parte una
conseguenza). Ora non voglio entrare più di tanto nel discorso che per
altro ha poco a che vedere con quello di cui stavamo parlando, mi pongo
tuttavia la domanda di quale politica intenda adottare Fastweb con
l'adozione di IPv6. Probabilmente lo sta testando e seppur sia in la da
venire, soprattutto per i clienti residenziali, dovrà fare una
progettazione fra non molto tempo, e ancor prima una relativa valutazione.
Trapela qualcosa? Anche se temo fortemente che non ci sarà un grosso
cambiamento di rotta, si possono già fare delle ipotesi? Sebbene per
l'azienda sia necessario fruttare il più possibile le attuali
infrastrutture, non concedere la piena raggiungibilità (e anzi, molteplici
indirizzi) sarebbe un vero e proprio paradosso. Qualche idea/opinione in
proposito?

Detto questo.. beh, non rimane che ringraziarti :)
La tua disponibilità, cortesia e professionalità sono oggetto di invidia.

[Macs]

Ciao

Post by Blak
Prima di tutto grazie per la risposta, sia qui che sulla ML, in pochi
avrebbero avuto voglia di leggere tutto e scrivere altrettante parole.
Te ne sono grato.

[...]

Post by Blak
Confermo il pieno funzionamento con un server stun differente.
Grazie per i chiarimenti, ne è anche nata una discussione interessante
e che magari può servire anche ad altri in futuro.

Prego ;) -> Damien aveva gia' intuito a suo tempo che qualcosa potesse
creare problemi agli utenti FW, che usavano account Ekiga.net con
stun.ekiga.net, ma era stato fuorviato da un lato dalle segnalazioni
non precise di altri utenti e dall'altro dalla non completa conoscenza
dell'architettura di rete FW.

Ora le cose dovrebbero essere finalmente chiare (spero).

Post by Blak
mi pongo tuttavia la domanda di quale politica intenda adottare
Fastweb con l'adozione di IPv6.

[...]

Post by Blak
Trapela qualcosa? Anche se temo fortemente che non ci sarà un grosso
cambiamento di rotta, si possono già fare delle ipotesi?

FW ha ancora il blocco IPv6 2001:0b00::/32 assegnato & con la seguente
situazione di announcement da AS12874 :
==
- http://www.cidr-report.org/cgi-bin/as-report?as=AS12874&view=2.0&v=6
- http://www.go6.it/bgp/bgp-page-complete.html (dynamic update)
- http://www.as29449.com/bgp/bgp-page-complete.html
- http://www.go6.it/bgp/24h_history/IT-FASTWEB-20030213.html
- http://www.as29449.com/bgp/24h_history/IT-FASTWEB-20030213.html

Non vi sono informazioni ufficiali, e le comunicazioni in merito ad IPv6
provenienti da FW sono limitate a qualche vago accenno in vecchie
interviste (e.g. Corriere Economia 10 Maggio 2004) -> qualche ulteriore
informazione e' presente in alcuni PPT/PDF reperibili in rete, in virtu'
della partecipazione di FW all'IPv6 Task Force Italiana, ma non fanno
accenno ovviamente a tempi/modalita' di "presentazione" alle utenze
finali.

Per quanto riguarda poi le ipotesi su come FW potrebbe incorporare IPv6
inizialmente sulla sua rete, un primo scenario dovrebbe prevedere almeno
la definizione di un suo Tunnel-Broker (stile ngnet.it per Telecom)
destinato alle utenze FW (soprattutto quelle su rete privata MAN).

L'approccio commerciale potrebbe essere quello di una sperimentazione
gratuita & con definizione di tunnel autenticati con limitazione di
banda in Download/Upload (e.g. 50 kByte/s in DL/UL)... sempre che non
venisse fuori l'anima 'Telco' di FW (come e' successo per il servizio
IPPD IP Pubblico).

Se FW implementa il NAT per motivi commerciali, lo fa proprio perche'
ragiona & si comporta da Telco sin da quando ha avviato i suoi servizi,
e non come un ISP = una Telco punta sui *servizi* che puo erogare sulla
sua rete in funzione praticamente esclusiva del solo costo addebitabile
agli utenti, mentre un ISP e' ben piu' attento alle varie questioni di
connettivita' con Internet (anche perche' magari vende come prodotto
primario/esclusivo solo quella).


Staremo quindi a vedere -> nel frattempo non serve aspettare le mosse
FW a chi e' interessato ad usare connettivita' IPv6, anche per questioni
di visibilita' diretta/pubblica tanto su IPv6 quanto su IPv4 tramite
gateway IPv6toIPv4 (e.g. siti web IPv6 + uso del gateway pubblico SixXS
http://ipv6gate.sixxs.net/ ).

Gli utenti su linee FW in architettura base, pur essendo dietro NAT
Hidden/Dynamic M-1 (NON modificabile a meno di attivare IP Pubblico IPPD
in ambito Residenziale/SOHO o Opzioni Address per Business/Aziende),
possono infatti avere piena connettivita' end-to-end IPv6, scegliendo
tra alcuni servizi *free* forniti da terze parti.

Queste sono le info aggiornate, visto che alcuni servizi citati in
passato hanno subito delle variazioni :
==
------------------------------------------------------------------------
* Fast-Labs
--------------
- http://www.fast-labs.net/

Dal 2003 Fast-Labs forniva un servizio TunnelBroker gratuito & rivolto
alle utenze FW previa registrazione sul loro sito.

Recentemente il servizio ha cambiato nome/caratteristiche, diventando
MyIp -> la procedura di registrazione richiede ora qualche dato in piu',
ma consente ancora di gestire i servizi disponibili gratuitamente :
==
- http://www.fast-labs.net/register.php
- http://www.fast-labs.net/ua/

------------------------------------------------------------------------
* Teredo
--------
- http://en.wikipedia.org/wiki/Teredo_tunneling
- http://www.microsoft.com/technet/network/ipv6/teredo.mspx
- http://www.simphalempin.com/dev/miredo/
- http://www.progsoc.org/~wildfire/debian/miredo/

Teredo e' un protocollo di tunneling che consente connettivita' IPv6 a
sistemi IPv4 dietro NAT non modificabile, tramite l'UDP Encapsulation su
IPv4 dei pacchetti IPv6.

Ad inizio Aprile 2006 Marco d'Itri ha attivato un relay Teredo, che
consente di avere un indirizzo IPv6 -> non e' necessaria alcuna
registrazione o configurazione particolare = e' sufficiente attivare il
client Teredo ed appoggiarsi al seguente server :
==
- teredo.remlab.net

Nota : gli utenti con Windows XP devono aver installato, oltre al
Service Pack 2, anche l'ultima versione dello stack TCP/IPv6 disponibile
su WindowsUpdate (che supporta il nuovo prefisso 2001::/32 allocato
dallo IANA per Teredo) -> inoltre e' necessario che siano installati gli
aggiornamenti KB922819 e/o KB920342.

------------------------------------------------------------------------
* AYIYA
-------
- http://en.wikipedia.org/wiki/AYIYA
- http://www.sixxs.net/main/
- http://www.sixxs.net/faq/account/?faq=10steps
- http://www.sixxs.net/tools/aiccu/

Sistema di tunnel UDP IPv4 su cui vengono incapsulati i pacchetti IPv6
-> una volta approvata la registrazione gratuita a SixXS (che va
effettuata su http://www.sixxs.net/signup/ ) e' sufficiente usare il
client automatico AICCU per configurare/utilizzare un tunnel AYIYA.

------------------------------------------------------------------------
* Freenet6
----------
- http://www.go6.net/4105/freenet.asp
- http://www.go6.net/4105/register.asp

Servizio gratuito (previa registrazione) per l'accesso a connettivita'
IPv6 & utilizzabile anche da utenze dietro NAT non modificabile ->
prevede sia la modalita' tramite tunnel autenticato con assegnazione
statica di prefisso/indirizzo IPv6 che quella su tunnel anonimo con
assegnazione dinamica.
------------------------------------------------------------------------

[Conte Frobenius]

Post by Macs
Per quanto riguarda poi le ipotesi su come FW potrebbe incorporare IPv6
inizialmente sulla sua rete, un primo scenario dovrebbe prevedere almeno
la definizione di un suo Tunnel-Broker (stile ngnet.it per Telecom)
destinato alle utenze FW (soprattutto quelle su rete privata MAN).

Si è anche parlato di un possibile "NAT 1:1", non meglio specificato. Hai
qualche informazione in merito?

[Macs]

Ciao

Si è anche parlato di un possibile "NAT 1:1", non meglio specificato.
Hai qualche informazione in merito?

Tale sarebbe uno scenario piu' probabile qualora appunto prevalesse
l'anima 'Telco' di FW sulla necessita' di effettuare preventivamente una
fase di test/sperimentazione sulla rete di produzione tramite TB.

Un tale meccanismo di transizione (a differenza di quelli tramite tunnel
o encapsulation) prevede infatti che non siano effettuate operazioni sul
client/host IPv4, in modo che questo (o perlomeno le sue applicazioni su
TCP/UDP) possano "comprendere/parlare" su V6.

E' quindi decisamente piu' user-friendly, e consente l'accesso a risorse
V6 anche a sistemi/apparati sui quali lo stack IPv6 non possa essere
implementato (e.g. anche vari router per uso residenziale/SOHO).

Tuttavia, cio' richiede un maggior onere per il provider in termini di
risorse & configurazione = devono essere infatti definite sui suoi
router/apparati apposite regole per instradamento & traduzione dei
pacchetti con riscrittura V4->V6, e viceversa.


Esistono diversi meccanismi per fare tutto cio' in base a cosa si voglia
realmente tradurre (tutte le connessioni di rete, solo quelle TCP/UDP, o
alcune specifiche come HTTP/SMTP/DNS) -> uno possibile vedrebbe p.es.
l'abbinamento di :
==
- SIIT (Stateless IP/ICMP Translation) per la riscrittura dei pacchetti
- NAT/NAPT Protocol Translation per il mapping dell'host IPv4
- DNSALG per la riscrittura delle richieste/risposte di risoluzione DNS

In caso di una tale scelta/configurazione da parte FW l'utente finale
dovrebbe quindi effettuare solo una procedura analoga a quella del
servizio IPPD - IP Pubblico, accedendo da una pagina web per registrare
il client/host IPv4 & associargli IPv6 = il suo sistema continuerebbe ad
usare solo IPv4 (anche per attivita' su rete MAN/pubblica FW), ma su
Internet sarebbe visibile anche tramite IPv6.

Una procedura cosi' analoga, che a quel punto FW potrebbe abbinarla e/o
allinearla proprio a IPPD ed alle relative condizioni commerciali d'uso,
ved. monte ore di servizio gratuito + costi aggiuntivi per il tempo
extra.


Personalmente ritengo che, non solo per una questione economica (visto
che le alternative free non mancano), sarebbe comunque preferibile una
prima transizione tramite TB lato utente (stile appunto ngnet.it per le
utenze Telecom). Un tale scenario introdurrebbe gradualmente a livello
del parco utenze (specie quelle MAN) l'utilizzo reale/diretto IPv6
tramite risorse FW, mentre la traduzione V4/V6 non farebbe altro che
mantenere praticamente l'attuale status quo lato utente, rimandando la
questione.

Una tale sperimentazione su rete di produzione darebbe inoltre a FW la
possibilita' di monitorare adeguatamente le attivita' & di conseguenza
dimensionare opportunamente i meccanismi per le fasi successive di
transizione V4/V6.

Partire da subito invece con una traduzione V4/V6 a livello globale di
rete esporrebbe a varie questioni di criticita', considerando peraltro
che un conto e' implementare tale meccanismo su reti locali anche grandi
ed un altro e' la sua definizione/operativita' a livello di rete WAN
geografica estesa di un provider con piu' di 1 milione di utenze come
ordine di grandezza della 'popolazione'.

Lo stesso servizio IPPD, benche' sia ormai al suo 6° compleanno, paga
ancora qualche "problemino" di dimensionamento/configurazione = e.g. le
questioni relative a dimensionamento/disponibilita' dei pool IPPD sulle
singole MAN & gestione NAT Loopback sugli IP IPPD per le connessioni
provenienti da IP MAN, ed in particolare quelli attestati al medesimo
POP.

[lorenzodes]

Post by Macs
Ciao

Si è anche parlato di un possibile "NAT 1:1", non meglio specificato.
Hai qualche informazione in merito?

Tale sarebbe uno scenario piu' probabile qualora appunto prevalesse
l'anima 'Telco' di FW sulla necessita' di effettuare preventivamente una
fase di test/sperimentazione sulla rete di produzione tramite TB.

Anima telco o meno, il decreto legislativo 30 maggio 2008, n. 109 così come
modificato dal Decreto-Legge 2 ottobre 2008, n. 151, prevede che gli ISP
debbano garantire "la disponibilità e l’effettiva univocità degli indirizzi
di protocollo internet” ai propri clienti, e ciò a partire dal 31 dicembre p.v.

Ovviamente non si tratta di norma pensata a vantaggio del consumatore, i temi
della norma sopra citata sono la data retention a l'associabilità agli utenti
del loro traffico Internet.

[Macs]

Ciao

il decreto legislativo 30 maggio 2008, n. 109 così come modificato dal
Decreto-Legge 2 ottobre 2008, n. 151, prevede che gli ISP debbano
garantire "la disponibilità e l’effettiva univocità degli indirizzi
di protocollo internet” ai propri clienti, e ciò a partire dal 31
dicembre p.v.

E' vero che la definizione g) dell'articolo 1 del Dlgs.109 indica come
indirizzo IP univocamente assegnato l'IP, che consenta l'identificazione
diretta di un utente, che effettui comunicazioni sulla rete pubblica.

Tuttavia, va tenuto conto delle procedure tecniche & degli 'interessi
forti' (leggansi anche lobby) = gia' in seguito alla pubblicazione del
Dlgs.109, FW - H3G - Vodafone (in quanto componenti della Commissione
sulla sicurezza delle TLC) hanno 'suggerito' a Governo & Garante che,
tra le specifiche tecniche fornite ad ISP/ASP per l'identificazione
univoca dell'utenza dietro richiesta dell'Autorita' Giudiziaria, sia
considerata anche la porta sorgente, comportando quindi la seguente
tripletta :
==
- Indirizzo IP sorgente
- Porta TCP/UDP sorgente
- Data/Ora dell'associazione IP:porta

[lorenzodes]

Post by Macs
==
- Indirizzo IP sorgente
- Porta TCP/UDP sorgente
- Data/Ora dell'associazione IP:porta

Sappiamo entrambi, tuttavia, che quella soluzione è solo teoricamente
equivalente a quanto richiesto dalla legge che, fra l'altro, sul punto è ben
precisa.

[Blak]

Il Thu, 16 Oct 2008 13:34:25 +0200, Macs ha scritto:

Scusa del ritardo con cui rispondo ma sono stato molto impegnato :)

Post by Macs
L'approccio commerciale potrebbe essere quello di una sperimentazione
gratuita & con definizione di tunnel autenticati con limitazione di
banda in Download/Upload (e.g. 50 kByte/s in DL/UL)... sempre che non
venisse fuori l'anima 'Telco' di FW (come e' successo per il servizio
IPPD IP Pubblico).

Male, perchè sappiamo tutti e due che un qualunque tunnel broker *oggi*
fornisce stesse funzionalità e banda, se non di più. Scaricando da
switch.ch tramite un tunnel fornito da sixxs (e itgate) vado spesso e
volentieri a banda piena. Certo, mi è concesso perchè i volumi di traffico
generati non sono molti, tutt'altro, però questa ipotetica soluzione di
fastweb non mi sembra una proposta attraente.

Post by Macs
Se FW implementa il NAT per motivi commerciali, lo fa proprio perche'
ragiona & si comporta da Telco sin da quando ha avviato i suoi servizi,
e non come un ISP = una Telco punta sui *servizi* che puo erogare sulla
sua rete in funzione praticamente esclusiva del solo costo addebitabile
agli utenti, mentre un ISP e' ben piu' attento alle varie questioni di
connettivita' con Internet (anche perche' magari vende come prodotto
primario/esclusivo solo quella).

Lo so, ma in questo caso penso sia peggio: cosa farà tra 5-10 anni quando
gli altri ISP offriranno un prodotto che include IPv6 senza ulteriori
esborsi? Se da un lato è vero che la sua clientela non è attenta a queste
problematiche è anche vero che dovrà essere brava a far buon viso a cattivo
gioco. Capisco che gli attuali investimenti debbano avere un ritorno a
breve termine ma questo è un cambiamento non proprio banale e non
propriamente comunque nella storia.

Post by Macs
Staremo quindi a vedere

Non possiamo fare altro :) Mi auguro solo che gli altri ISP non stiano a
guardarsi per troppo tempo.
E speriamo che la reale number portability diventi una realtà molto presto.

Ciao e grazie ancora.