Architettura e amministrazione di Internet

Transcript

Architettura e amministrazione di Internet
Marzo 2000
Architettura e amministrazione
di Internet
Edoardo CALIA
[email protected]
Fulvio RISSO
[email protected]
Internet Architecture - 1
Marzo 2000
Agenda
Cenni riepilogativi dell’architettura di rete
TCP/IP
Organizzazione di Internet
Enti amministrativi e tecnici
Autonomous Systems e Internet Service
Provider
Interconnessione
di Internet Provider:
Neutral Access Point (NAP)
Internet Architecture - 2
Marzo 2000
Organizzazione amministrativa di
Internet
Internet
nasce
e
cresce
come
interconnessione di reti indipendenti
Non esiste un “padrone” di Internet, ma
esistono regole generali che occorre
rispettare per poter comunicare
Alcuni enti amministrativi e tecnici: ISOC,
IAB, IESG, IETF, IRTF, IANA.
Internet Architecture - 3
Marzo 2000
Internet Society (ISOC)
6000 membri individuali e 150 istituzionali
(aziende)
Coordina la gestione delle problematiche di
evoluzione di Internet
Sponsorizzazione
di
conferenze
(INET),
pubblicazioni, ...
A ISOC fanno riferimento IETF e IAB, che si
occupano della produzione di specifiche
tecniche
Internet Architecture - 4
Marzo 2000
Internet Architecture Board (IAB)
Gruppo di consulenti tecnici dell’ISOC
Elegge
i membri dell’IESG (Internet
Engineering Steering Group)
Fornisce le direttive principali per le
specifiche di protocolli e per il processo
della loro implementazione
Redime
eventuali divergenze che si
possono manifestare nei processi di
standardizzazione
Internet Architecture - 5
Marzo 2000
IETF
Internet Engineering Task Force
Comunità aperta di tecnici e specialisti
Organizzato in Working Groups, ciascuno dei quali si
occupa di un problema specifico
Gran parte del lavoro avviene via posta elettronica
Meeting organizzati tre volte all’anno
Scopi
Realizzazione di documenti (standard tracks) che abbiano
ottenuto un certo consenso relativamente all’ambito del
working group
Gli standard tracks (proposte di standard) sono
sottomessi ad IESG per il loro avanzamento a standard
effettivo
Internet Architecture - 6
IETF “raccomanda” all’IESG la pubblicazione di un esistente
draft sotto la forma di “proposed standard”
Marzo 2000
IESG
Internet Engineering Steering Group
Sovrintende alla definizione degli “effettivi”
standard Internet (non tutte le RFC
diventano standard)
I documenti approvati da IETF devono
essere approvati e validati da un apposito
gruppo ristretto di supervisori
Gli standard approvati da IESG sono
pubblicati da ISOC
Internet Architecture - 7
Marzo 2000
IRTF
Internet Research Task Force
Come IETF ma focalizzata sulla ricerca
Discussione di idee innovative in un particolare
argomento
Non focalizzata sulla produzione di uno standard da
implementare
L’output può essere una pubblicazione scientifica,
una Informational o Experimental RFC
IRSG: corrispondente dell’IESG
Organizza gruppi di lavoro per fare ricerca su
particolari argimenti legati ad Interent (protocolli,
applicazioni, tecnologia)
Mantiene la suddivisione in working groups, che però
possono non essere aperti a tutti
I WG hanno normalmente durata più ampia rispetto a
quelli di IETF
Internet Architecture - 8
Marzo 2000
Standard Track Process (1)
I documenti in procinto di diventare standard
evolvono secondo i seguenti passi:
Proposed Standard: specifica sufficientemente
stabile, ha ricevuto un sufficiente feedback dagli
sviluppatori, ha un certo interesse nella comunità
Internet; tuttavia questa specifica non è ancora
ritenuta sufficientemente matura; gli implementatori
devono trattare questa specifica come una specifica
ancora immatura
Draft Standard: richiede la presenza di almeno due
implementazioni che hanno dimostrato la loro
interoperabilità; indica che l’IESG ritiene lo standard
sufficientemente maturo
Standard: richiede la presenza di un numero di
implementazioni significativo e una notevole
esperienza dimostrata dagli utenti su questo
standard; gli viene assegnato un numero
progressivo nella lista degli standard (STD)
Internet Architecture - 9
Marzo 2000
Standard Track Process (2)
I documenti che non sono ritenuti adatti ad essere
Internet Standards vengono etichettati come
Experimental:
documento relativo a qualcosa
ancora in fase di ricerca; viene pubblicata a titolo
informativo senza che ci sia la pretesa di farlo
diventare standard a breve
Può essere l’output di un gruppo di lavoro Internet
(sia IETF che IRTF), oppure un contributo individuale
Informational: documento di tipo “informativo” su
un determinato argomento; può non disporre di un
particolare consenso nella comunità Internet e non
rappresenta una raccomandazione di sorta
Historic: standard che sono orma completamente
rimpiazzati da nuove specifiche oppure sono caduti
in disuso
Internet Architecture - 10
Marzo 2000
Standard Track Process (3)
Best Common Practice (BCP)
Documenti
che suggeriscono alcuni modi di
comportamento / configurazione che non sono
standard ma consigliati
Deve esistere consenso anche in questo caso,
ma il processo di approvazione è più veloce
non si effettua il 3-stage standard track process
Internet Architecture - 11
Marzo 2000
IANA
Internet Assigned Numbers Authority
Coordina l’assegnazione univoca di valori ai
parametri dei protocolli utilizzati su Internet
Tra gli altri valori, assegna anche gli
indirizzi IP
Internet Architecture - 12
Marzo 2000
Enti delegati di IANA
Per la gestione delle assegnazioni di
indirizzi nei vari paesi IANA si serve di
organizzazioni locali:
InterNIC
per gli USA
RIPE per l’Europa
Asia Pacific NIC (APNIC)
Internet Architecture - 13
Marzo 2000
Organizzazione tecnica di
Internet
La rete Internet è organizzata in sezioni
omogenee
dal
punto
di
vista
amministrativo, dette Autonomous Systems
Gli AS impongono il massimo livello di
gerarchia sulla rete
Internet Architecture - 14
Marzo 2000
Autonomous Systems
AS 2
AS 1
AS 4
Internet Architecture - 15
AS 3
Marzo 2000
Autonomous Systems
Ciascun AS è gestito indipendentemente
dagli altri, in particolare per quanto riguarda
l’instradamento dei pacchetti IP al suo
interno
AS diversi possono utilizzare IGP diversi
L’unico punto di accordo deve essere il
protocollo utilizzato alla frontiera (EGP)
Internet Architecture - 16
Marzo 2000
Autonomous Systems
Uno o più router interni a un AS sono
selezionati per svolgere le funzioni di ASBR
(AS boundary router)
Gli
ASBR devono partecipare sia al
protocollo di routing interno, sia a quello
esterno per propagare le informazioni verso
altri AS
Internet Architecture - 17
Marzo 2000
ASBR
IGP2
IGP1
EGP
(es. BGP4)
Internet Architecture - 18
Marzo 2000
IGP ed EGP
IGP: protocolli di routing utilizzati per
trasportare informazioni di instradamento
tra i router interni a un AS
EGP: protocolli di routing utilizzati per
comunicare all’esterno dell’AS:
informazioni riassuntive sullo stato interno
dell’AS
informazioni di transito apprese da altri AS
Internet Architecture - 19
Marzo 2000
ASBR e protocolli di routing
I router di frontiera devono avere a bordo
una istanza del protocollo IGP e una istanza
del protocollo EGP
L’amministratore
del
sistema
deve
predisporre
opportunamente
la
propagazione delle informazioni tra i due
protocolli (redistribuzione)
Internet Architecture - 20
Marzo 2000
Redistribuzione
Specifica
quali
informazioni generate internamente all’AS
devono essere propagate all’esterno
quali informazioni ricevute dall’esterno dell’AS
devono essere propagate al suo interno
Consente di rendere alcune destinazioni
visibili o meno
Internet Architecture - 21
Marzo 2000
Redistribuzione mutua
Generalmente occorre redistribuire le
informazioni prelevate dall’EGP nel IGP e
viceversa
Occorre attenzione per evitare il formarsi di
loop di redistribuzione (importazione in un
protocollo di informazioni precedentemente
esportate dallo stesso protocollo)
Internet Architecture - 22
Marzo 2000
Politiche di routing
I problemi di routing tra AS sono diversi in principio
rispetto ai problemi di instradamento interni all’AS
Entro un AS si tende a ottenere l’instradamento
ottimo verso la destinazione
L’instradamento tra AS implica problemi di
autorizzazione all’uso di risorse
Un AS potrebbe non desiderare essere utilizzato
come transito tra altri due AS
Si possono quindi avere percorsi non ottimi a causa
di accordi (o mancati accordi) di tipo amministrativo
ed economico
Internet Architecture - 23
Marzo 2000
Transito di AS
AS 2
AS 1
AS2 è un AS di transito
per il traffico da AS1 ad AS3
AS 3
Internet Architecture - 24
Marzo 2000
Peering tra AS
Gli accordi amministrativi (e i conseguenti
accordi tecnici) tra i gestori di AS differenti
per stabilire le politiche di transito e
raggiungibilità sono detti accordi di peering
Una relazione di peering si stabilisce tutte le
volte che un EGP viene attivato tra due AS
differenti
Esistono generalmente siti particolari dove
viene creato un punto di contatto tra diversi
AS: NAP o Neutral Access Point
Es. NAP (CILEA), MIX (Milano), VIX (Vienna)
Internet Architecture - 25
Marzo 2000
Neutral Access Point
Dal punto di vista pratico è una LAN su cui
sono connessi router appartenenti ad AS
differenti, tra i quali viene opportunamente
configurato un EGP (generalmente BGP4)
Internet Architecture - 26
BGP4
Marzo 2000
Neutral Access Point
I NAP sono spesso configurati in un paese
tra diversi provider (ciascuno con un
proprio AS), per abbreviare i percorsi di
raggiungibilità reciproche
Internet Architecture - 27
Marzo 2000
Neutral Access Point
AS4
AS3
Olanda
Italia
AS1
Internet Architecture - 28
AS2
In assenza di un NAP,
AS1 e AS2 possono comunicare
utilizzando un percorso complesso
Marzo 2000
Neutral Access Point
AS4
AS3
Olanda
Italia
AS1
AS2
Stabilendo un accordo di peering
AS1 e AS2 comunicano direttamente
Internet Architecture - 29
Marzo 2000
Evoluzione dell’indirizzamento
su Internet:
Classless Inter Domain Routing
Internet Architecture - 30
Marzo 2000
Crescita 1997 (n. host)
Jan 1997
Feb 1997
Mar 1997
Apr 1997
May 1997
Jun 1997
Jul 1997
Aug 1997
Sep 1997
Oct 1997
Nov 1997
Dec 1997
3921946
4046925
4213308
4391508
4598408
4738080
4840248
4959336
5122501
5381413
5645111
5789853
Internet Architecture - 31
+247689
+124979
+162460
+177931
+206900
+139672
+102168
+114877
+163165
+299880
+263698
+146416
+ 6.7%
+ 3.2%
+ 4.0%
+ 4.2%
+ 4.7%
+ 3.0%
+ 2.2%
+ 2.4%
+ 3.3%
+ 5.9%
+ 4.9%
+ 2.6%
+535128
+14.6%
+524503
+12.4%
+380210
+ 8.0%
+709994
+13.9%
Marzo 2000
Crescita 1998 (n. host)
Jan 1998
Feb 1998
Mar 1998
Apr 1998
May 1998
Jun 1998
Jul 1998
Aug 1998
Sep 1998
5942491
6103338
6321235
6440998
6652681
6795885
6982995
7250734
7455316
Internet Architecture - 32
+170131
+136246
+209119
+119763
+211683
+143204
+187119
+267739
+204582
+ 2.9%
+ 2.3%
+ 3.3%
+ 1.9%
+ 3.3%
+ 2.2%
+ 2.8%
+ 3.8%
+ 2.8%
+515496
+ 8.9%
+474650
+ 7.5%
+659431
+ 9.7%
Marzo 2000
Reti assegnate annualmente
25,000
20,000
15,000
10,000
5,000
Internet Architecture - 33
96
A
94
92
90
88
86
C
84
non noto
0
Marzo 2000
Totale reti assegnate
100,000
Internet Architecture - 34
96
A
94
92
90
88
86
C
84
non noto
90,000
80,000
70,000
60,000
50,000
40,000
30,000
20,000
10,000
0
Marzo 2000
CIDR
Classless Inter Domain Routing
RFC 1517, 1518, 1519 e 1520
Consiste nell’identificare un gruppo
indirizzi contigui usando l’indirizzo
partenza e una maschera
Internet Architecture - 35
di
di
Marzo 2000
CIDR
Tecnica
utilizzata
per
diffondere
informazioni di raggiungibilità di un gruppo
di reti contigue
Esempio:
199.9.4.0
con maschera 255.255.252.0
rappresenta 199.9.4.0, 199.9.5.0, 199.9.6.0 e
199.9.7.0
Internet Architecture - 36
Marzo 2000
Assegnamento e CIDR
Per beneficiare dei vantaggi del CIDR
bisogna assegnare gli indirizzi ai provider
che:
partizionano
gli insiemi in fase di assegnazione
li aggregano in fase di annuncio
IPv6 avrà solo indirizzi provider based
Internet Architecture - 37
Marzo 2000
AS e CIDR
192.154.0.0/18
192.154.32.0/19
192.154.0.0/19
192.154.0.0/20
192.154.0.0/20
Internet Architecture - 38
192.154.16.0/20
192.154.16.0/20
192.154.32.0/19
192.154.32.0/19
Marzo 2000
I protocolli e il CIDR
Non supportano il CIDR
BGP-3,
RIP, IGRP
Supportano il CIDR
BGP-4,
RIPv2, OSPFv2
EIGR, I-IS-IS
I protocolli di routing di IPv6
RIPv6, OSPFv6, IDRPv2
Internet Architecture - 39