Newsgroup: it.tlc.gestori.fastweb
Titolo: Classe 21.242.

Se se n'è già parlato mi scuso, sono indirizzi ip di rete interna fastweb ?
Ho controllato su 
http://plany.fasthosting.it/dbmap.asp?table=Mappatura
ma credo che debba ancora essere aggiornata.
A quale zona corrispondono ?
Grazie.

 Se se n'č giŕ parlato mi scuso, sono indirizzi ip di rete interna fastweb ?

E' ancora una classe che appunto sembrerebbe della Toscana,ma non ne 
sono certo.
Ecco un altro limite di fastweb :
non potersi collegare alemno con le seguenti reti
1.0.0.0
14.0.0.0
2.0.0.0
11.0.0.0
23.0.0.0
41.0.0.0
37.0.0.0
5.0.0.0 (qui nasce un problema pure con hamachi)
59.0.0.0
26.0.0.0
e altre che al momento non mi sovvengono

 fastweb ?
Si, FW ha introdotto tale indirizzamento a livello di reti metropolitane
(o meglio, regionali) MAN = quella che hai riportato e' infatti una
subnet /16 di utenze xDSL della recente MAN Marche.
Questo e' l'elenco attuale delle MAN Utenze :
==
- MAN Milano                 = IP  1.x.x.x
- MAN Milano Hinterland NORD = IP  2.x.x.x
- MAN Genova                 = IP  5.x.x.x
- MAN Trento/Veneto          = IP 11.x.x.x [*][DoD Information Systems]
- MAN Milano Hinterland SUD  = IP 14.x.x.x [*][IANA Public Data Network]
- MAN Marche                 = IP 21.x.x.x [*][DoD Information Systems]
- MAN Grosseto               = IP 22.x.x.x [*][DoD Information Systems]
- MAN Roma                   = IP 23.x.x.x
- MAN Toscana                = IP 27.x.x.x
- MAN Triveneto              = IP 29.x.x.x [*][DoD Information Systems]
- MAN Bari                   = IP 31.x.x.x
- MAN Sicilia                = IP 36.x.x.x
- MAN Bologna                = IP 37.x.x.x
- MAN Napoli                 = IP 39.x.x.x 
- MAN Torino                 = IP 41.x.x.x [*][AfriNIC]
- MAN Reggio Emilia          = IP 42.x.x.x
Con [*] sono contrassegnati i range /8 assegnati dallo IANA (a registri
RIR/LIR e non solo) :
==
- 
http://www.iana.org/assignments/ipv4-address-space
Quelli non contrassegnati sono ancora di tipo IANA Reserved, e quindi
non sono stati (ancora) assegnati per uso pubblico.
In virtu' delle impostazioni MAN FW non sono quindi raggiungibili per
esempio risorse allocate/annunciate in alcuni dei vari range sparsi su
41.128.0.0/9
, che AfriNIC ha iniziato ad assegnare a provider/telco e ad
aziende nel corso del 2006.
E' sufficiente 
p.es
. un confronto a livello di traceroute tra una 
connessione FW e quella di un altro provider con destinazione l'IP
41.223.252.1 (IP di test AfriNIC) oppure altri pubblicamente allocati ed
annunciati -> e' possibile individuarli, effettuando la ricerca avanzata
(Search level -M / -T inetnum) tramite il WHOIS DB AfriNIC sulla subnet
41.0.0.0/8
 :
==
- 
http://www.afrinic.net/cgi-bin/whois
Analoghi problemi sono presenti con risorse allocate/annunciate sulle
subnet 26/8 [DoD] e 59/8 [APNIC] in virtu' dell'utilizzo lato FW di
indirizzi IP su tali range per uso interno -> ved. identificazione di
apparati di rete con funzioni di gateway e firewall (anche a livello di
utenze Business PMI/Medium/TOP). 
 
D'altronde sono situazioni gia' discusse nel corso degli anni in questo
gruppo (ed altri), come puoi vedere da :
==
http://groups.google.it/groups/search?q=afrinic+group%3Ait.tlc.gestori.*
==
e non posso quindi che ribadire quanto ho gia' scritto in passato :
************************************************************************
Tuttavia, la questione reale resta a monte = so/capisco le motivazioni
di provisioning e di gestione dell'indirizzamento interno che hanno
portato FW alla migrazione IP RFC1918 LAN->MAN, ma in ogni caso resta il
fatto che impieghi pool IANA Reserved/PDN - DISA - DoD - APNic - AfriNIC
per uso privato su una rete comunque interconnessa ad Internet. 
************************************************************************
-- 
|Ż \/Ż | /Ż\ /Ż__/Ż__|<|> *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/
 ____<|

 - 
http://www.iana.org/assignments/ipv4-address-space
Era un po' che non lo guardavo e noto subito:
116/8   Jan 07   APNIC                               (
whois.apnic.net
)
117/8   Jan 07   APNIC                               (
whois.apnic.net
)
118/8   Jan 07   APNIC                               (
whois.apnic.net
)
119/8   Jan 07   APNIC                               (
whois.apnic.net
)
120/8   Jan 07   APNIC                               (
whois.apnic.net
)
che si aggiungono a:
121/8   Jan 06   APNIC                               (
whois.apnic.net
)
122/8   Jan 06   APNIC                               (
whois.apnic.net
)
123/8   Jan 06   APNIC                               (
whois.apnic.net
)
124/8   Jan 05   APNIC                               (
whois.apnic.net
)
125/8   Jan 05   APNIC                               (
whois.apnic.net
)
126/8   Jan 05   APNIC                               (
whois.apnic.net
)
Negli ultimi anni è stata rilasciata una quantità notevole di indirizzi IP,
non è poi così irrale l'eventualità di dover rinumerare una parte della
rete interna (sempre che non se ne freghino come stanno facendo per la 41/8
da te segnalata, ad esempio).
Si può tranquillamente dire che le politiche e le scelte di fastweb violino
parte dei principi fondamentali su cui si basa internet.
-- 
X

 
Questo punto è l'unico sul quale non salterà mai fuori la soluzione 
"magica" per bypassare la limitazione dell'architettura..
O magari no ?

 O magari no ?
Ma pare che il NAT non sia un ostacolo. Allora vuol dire che fastweb ha
fallito, ha messo un ostacolo che un ostacolo non è. Insomma, sono dei
cretini. Se è vero che aumentano le soluzioni per rimediare è anche vero
che esiste un costo per superarle, costo su cui tacciono tutti (c'è chi
addirittura chiama il problema "questione di capacità"). Quindi o il NAT
non è un limite e allora dovremmo essere tutti concordi nel dire che è
inutile e varrebbe allora la pena di toglierlo. Ed ecco che si risolve
tutto ;)
-- 
X

 
E' una macchina da soldi, e per questo che se verrà tolto sarà per solo 
pochi motivi
1) Verrà come dici tu abbattutto da qualsiasi applicazione e il servizio 
ippd non avrà piu' mezzo cliente, quindi cosa non produttiva da smantellare
2) Obbligo di non usare piu' gli ip che usano poichè inibiscono 
l'accesso ad una parte di internet = qualcuno si incazza 
dall'alto,revisione dell'architettura a favore di una con ip pubblici 
dinamici.
Ma sono tutto tranne che scemi : guarda che ip usano... si sentono al 
sicuro, quindi putroppo ho l'impressione che, a meno appunto di 
interventi forzati (magari impossibili putroppo) e colpi di scena 
clamorosi (cambio dei vertici, acquisizione ecc ecc)la cosa andrà avanti 
tra gli applausi

 tra gli applausi
D'accordissimo, ma è proprio qua il punto: se non lo tolgono e se ci
ruotano sopra tanti soldi vuol dire che il NAT non è poi una limitazione
banale come qualcuno vuol far credere. E io non credo che in fastweb ci sia
poi gente incompetente, piuttosto sono menefreghisti/opportunisti in tal
senso.
-- 
X

 
Si puo' formulare un'altra ipotesi : oramai non li riescono ad ottenere 
con facilità (ip pubblicidi dinamici).
C'è in ballo anche la distribuzione della tv su ip che non è ostacolo da 
poco : dovrebbe quella continuare ad usare ip privati.
[OT]hai visto Scaglia cosa sta mettendo in piedi ?

 O magari no ?
Le soluzioni ci sono sempre = a suo tempo (Maggio 2006) ti avevo 
p.es
.
indicato uno scenario policy routing per la differenziazione degli
instradamenti sui range ex-IANA 'condivisi' tra rete MAN FW (utenze ed
apparati) e risorse pubbliche assegnate/allocate.
Tale scenario e' implementabile a livello utente, disponendo di una
seconda via di instradamento delle connessioni verso Internet su rete
non FW = seconda linea dati 'on site' oppure routed tunneling su VPN.
Cio' consente di differenziare gli instradamenti in base alle porte
TCP/UDP di destinazione associate ad un preciso indirizzo IP.
Peraltro la stessa FW potrebbe farlo in virtu' della configurazione del
Policy Based Routing lato GSR, introdotto per altre motivazioni (ved.
ulteriore differenziazione degli instradamenti a livello di utenze
business/aziendali) ma utile anche a questo scopo.
Il punto e' comunque sempre il solito = FW e' ovviamente consapevole sin
dalla migrazione LAN->MAN dei 'contro' associati all'utilizzo di range
IANA reserved, e infatti aveva anche sondato a suo tempo la possibilita'
di farsi assegnare direttamente/indirettamente i primi range usati per
le MAN (quando erano ancora realmente reti metropolitane/cittadine).
Tuttavia, al momento e' evidente che non vi e' ancora lato utenza una
rilevante segnalazione di problematiche su instradamenti associati ai
range condivisi -> qualora la situazione dovesse variare in futuro
(soprattutto in caso di riassegnazioni ad ARIN e RIPE) allora FW sarebbe
effettivamente costretta a correggere la situazione.
Riporto in merito un mio vecchio post di fine Novembre 2004, relativo
alle possibilita' di riorganizzazione a livello MAN :
************************************************************************
Non e' necessario implementare una struttura a 8 IP Pubblici per utenza
associati ai servizi utilizzati = e' infatti possibile mantenere
l'attuale topologia per i servizi VoIP/VOD. Per quanto riguarda la
connettivita' di computer, concentrandoci sulle utenze con CPE e quindi
residenziali/SOHO, vi sono 2 strade possibili :
==
- Adattare la soluzione NAT 1-1 time based attualmente usata per IPPD
- Assegnare 1 IP pubblico direttamente ad un computer dell'utenza
Quest'ultima puo' essere implementata tramite la pre-allocazione di
subnet 255.255.255.252 oppure con una gestione su pool dinamici tramite
un sistema di DHCP server/relay con MAC reservation e gestore NAT.
L'architettura di rete FW non e' mai stata statica, anzi = lo dimostrano
in modo evidente tutte le varie migrazioni :
==
- gestione DHCP
- integrazione utenze su xDSL
- passaggio (1Q 2002) da IP RFC-1918 a IANA Reserved per le MAN
- gestione NAT M-1/M-M overload
- sistema di autenticazione in rete e di accounting
==
che hanno comportato riorganizzazioni tecniche anche pesanti in funzione
degli aspetti commerciali di erogazione del servizio.
L'architettura attuale non e' quindi frutto di scelte obbligate lato
tecnico derivanti dalla progettazione iniziale, e non vi sono questioni
tecniche insormontabili che neghino a priori l'assegnazione di 1 IP pub
per utenza residenziale/SOHO. Vi sono ovviamente ragioni di carattere
commerciale/economico, che peraltro sono le medesime che hanno portato
(dopo i test condotti nel 2002) all'attuale soluzione IPPD per le utenze
residenziali/SOHO, in virtu' anche del sistema di accounting associato. 
************************************************************************
-- 
|¯ \/¯ | /¯\ /¯__/¯__|<|> *FAX/Mail Server  : 
+39 - 02700426582
 <|
|¯|\/|¯|/¯_¯\|(__\__ \<|> *Casella Vocale   : 
+39 - 0230312251
  <|


 l'attuale topologia per i servizi VoIP/VOD.
con quali ip mi domando ? Intendo quelli per il servizio VOD.

Piattaforma IPPD :
Nata all'epoca per porre rimedio ad una situazione allarmante che 
indusse ad una iniziativa di parecchi utenti  (oggi da come se ne 
discute pare che le applicazioni NAT-TRASVERSAL prolifichino e si 
migliorino e quindi lo scenario è cambiato) che precludeva sul serio 
tanti utilizzi e trasformatasi in un servizio a pagamento dei piu' cari...
Che come dici potrebbe essere riallocata per l'assegnazione di almeno un 
ip pubblico dinamico associato ad un computer/device associato dal 
cliente come fa tutt'ora con ippd.(regitrazione di un mac-address a suo 
piacimento)
Sarebbe interessante conoscere *quanto ippd fattura*, cosa è costata la 
sua implementazione e alla luce di quello che appare (il problema NAT è 
nella maggior parte dei casi superabile e aggirabile si dice) e solo a 
questo punto si potrà avere una risposta sul perchè questa architettura 
sopravviva ancora specialemnte sulle adsl ove nessuno con 512k/1M senza 
nessuna garanzia di banda potrebbe fronire servizi commerciali di 
livello tale da costituire una minaccia al fasthosting..
Oltre al problema di ottenere i necessari ip pubblici dinamici che 
potrebbe a questo punto essere certo possibile ma meno facile di qualche 
anno fa.

poco : dovrebbe quella continuare ad usare ip privati.
Mica vero.
-- 
ciao,
Marco

 
Ovvero un ip pubblico per ogni device iptv/VOD ?
Sinceramente sarebbero sprecati. La soluzione proposta da macs mi pare 
quella che :
1) Costo praticamente nullo per fastweb in quanto con la stessa 
piattaforma che usa adesso per assegnare ip pubblici dinamici a 
pagamento. L'utente che collega un pc o device (router o quanto si 
voglia) con un determinato mac, riceve in automatico l'ip pubblico 
dinamico riconosciuto su internet.L'utente puo' associar/cambiare mac 
quando vuole dal pannello di controllo di ippd come fa adesso.
Vuole colegare 10 pc ? Benisssimo natta lui e sono affare suoi,ma almeno 
potrà ridirezionare le porte ad es per usare bittorren proficuamente (un 
esempio a caso).
2) I servizi voip iptv vod e videocamere per videotelefoni interni a 
fastweb continueranno a mantenere i privati comunque DIVERSI da quelli 
al momento usurpati.Magari con politiche di QoS e precedenza atte allo 
scopo.
Rimarrebbe solo l'inconveniente di avere cmq un nat bidirezionale 1:1 
tra ip pubblico e ip utente fastweb che comunque in rarissimi casi puo' 
creare problemi. Tuttavia questa circostanza a me non ha mai creato 
nessun problema : attivando ippd sono riuscito a far funzionare il 100% 
di tutto cio' che è in mio possesso.
Solo qualche vecchio programma si ostinava a comunicare il suo ip 
interno fastweb ma parliamo di software spazzatura.

 di tutto cio' che è in mio possesso.
Concordo. E' anche la mia esperienza.

Marc Serafino ha scritto:

Ci sono aolo alcune vecchie applicazioni (oramai non piu' sviluppate e 
quindi sarebbero da ignorare) che si ostinano a passare al server l'ip 
proprio della man.
Ma qui la colpa è del programmatore al quale basterebbe semplicemenete 
fare una piccola modifica al codice, ma come dicevo sono appliazioni 
morte e non supportate.
Quindi ippd = sei su internet al 100%

 
Mi sono perso un pezzo di thread e sono rimasto a circa 2 anni fa su questo
argomento, ma:
- non si era detto che se si abilitassero tutti gli utenti FW con ippd, i
router & C. dovrebbero sopportare un carico maggiore e non ce la farebbero
a gestire tutti gli utenti?
- non dovrebbero i signori di FW procurarsi un pool addizionale di 500.000
IP publici? Sarebbero free?
Saluti,
			Mao