Newsgroup: it.tlc.gestori.fastweb
Titolo: Fastweb filtra SIP?

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.
-- 
http://img169.imageshack.us/img169/1054/medioevowb0.jpg

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..

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

 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.
-- 
|Ż \/Ż | /Ż\ /Ż__/Ż__|<|> *FAX/Mail Server  : 
+39 - 02700426582
 <|
|Ż|\/|Ż|/Ż_Ż\|(__\__ \<|> *Casella Vocale   : 
+39 - 0230312251
  <|
|_|  |_/_/ \_\___|___/<|> *FAQ ITGF 
http://plany.fasthosting.it
 <|
|>- RST - Plany/MACS -<|> *FAQ GCN  
http://faq.news.nic.it/
 ____<|

 [...]
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.
-- 
http://img169.imageshack.us/img169/1054/medioevowb0.jpg

 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. 
------------------------------------------------------------------------


 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?
-- 
Conte Frobenius

 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.


 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.

 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 
-- 
|¯ \/¯ | /¯\ /¯__/¯__|<|> *FAX/Mail Server  : 
+39 - 02700426582
 <|
|¯|\/|¯|/¯_¯\|(__\__ \<|> *Casella Vocale   : 
+39 - 0230312251
  <|


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

 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.
-- 
http://img169.imageshack.us/img169/1054/medioevowb0.jpg