Network Evolution

1
Network Evolution

• IPng

2
Utgangspunktet

• uttømt adresserom
• Kunne ikke forutses (anslag 1987 100.000 en gang
  langt inne i framtiden - jan. 95 antatt nådd i
  1996)
• IPv4 32 bits adresser gt4 milliarder hosts,
  16.7 mill nettverk
• Kan ikke utnyttes fullt ut samspill av tekniske
  og organisatoriske forhold (stor
  routing-tabeller, adminsitrasjon av tildeling av
  adresser, hierarkisk struktur, ..)

3
Utgangspunktet, forts.

• Routing and Addressing group (ROAD) etablert i
  1991.
• forslag 1992 CIDR,
• utsatt
• Vår 1992 IAB IPv7 forslag, CLNP. Neststemt av
  IETF (spirited discussion)
• Juli/sept. 1993 IPng diskusjon, IPng Area
  opprettet
• Retningslinjer for organisering og gjennomføring
  ble etablert

4
Tekniske krav

• Kriterer for evaluering av alternative forslag
• Ba om forslag - 21 white papers ble levert

5
Tekniske krav, forts.

• complete specification .
• architectural simplicity
• scale
• topological flexibility
• performance
• robust service
• transition
• media independence
• datagram service

• configuration ease
• security
• unique names
• access to standards
• multicast support
• extensibility
• service classes
• mobility
• control protocol
• tunneling support

6
Forslag

• Diverse løsninger under utvikling
• Dynamikk (IPAESIP)PIP SIPP
• Tre forslag ble evaluert i 1994
• CATNIP
• konvergens-protokoll - CLNP, IP, IPX
• common ground between OSI, Internet, Novell
• OSI adressering

7
Forslg, forts.

• SIPP
• evolutionary step from IPv4
• interoperable med v4
• fra 32 til 64 bits adresser
• ny header
• TUBA
• CLNP adressering

8
Evaluering

• CATNIP
• not completely specified
• innovative
• best vision
• not detailed ebough plans
• complexity
• does not deal with the routing problems
• poor support for multicasting and mobility
• does not deal with security

9
Evaluering, forts.

• SIPP
• den mest aktive gruppen
• "aesthetically beautiful protocol well tailored
  to compactly satisfy today's known network
  requirements."
• problem med overgangsplan The biggest problem
  the reviewers had with SIPP was with IPAE, SIPP's
  transition plan. The overwhelming feeling was
  that IPAE is fatally flawed and could not be made
  to work reliably in an operational Internet.
• stor uenighet ang. addresserings-mekanismene
• dårlig routing-løsning

10
Evaluering, forts.

• TUBA
• header-problemer
• tilfrestiller ikke mange av kravene

11
Konklusjon

• alle har svakheter
• både SIPP og TUBA vil kunne brukes
• problemer må løses
• CATNIP for ufullstendig for definitiv vurdering
• Ny SIPP adressering, overgangs-strategi,

12
Anbefaling

• Krav om beslutning
• SIPP
• Løser de viktigste problemene
• adressering
• overgang
• routing
• automatisk adresse-konfigurering

13
IPv6

• expanded addressing and routing capabilities
• simplified header format
• support for extension headers and options
• support for authentication and privacy
• support for autoconfiguration
• support for source routes
• simple and flexible transition from IPv4
• Incremental upgrade
• Incremental deployment.
• Easy Addressing
• Low start-up costs.
• quality of service capabilities

14
Hva er ikke med?

• mobilitet
• bredbånd
• sanntids multimedia
• 68 Internet standarder må endres
• Nye behov AAA (authentication, authorization,
  accounting)

15
Overgang

• Short term
• Opprettelse av Working Group
• Beskrive overgangsprosessen
• Utarbeide spesifikasjoner for
• leverandører
• nett-operatører

16
Long term

• Make the transition from a currently deployed
  protocol to a new protocol while accommodating
  heterogeneity and decentralized management.
• Since it is often difficult or impossible to
  replace all legacy systems or software, it is
  important to understand the characteristics and
  operation of a long period of coexistence between
  a new protocol and the existing protocol.

17
Long term, forts.

• The Internet must now be considered a utility.
  We are far removed from a time when a new
  technology could be deployed to see if it would
  work in large scale situations. Rigorous
  architectural and interoperability testing must
  be part of the predeployment phase of any
  proposed software for the Internet. Testing the
  scaling up behaviors and robustness of a new
  protocol will offer particular challenges. The WG
  should determine if there are lessons to be
  learned from OSPF, BGP4 and CIDR Deployment,
  the AppleTalk 1 to 2 transition, DECnet Phase 4
  to Phase 5 planning and transition, among others.

18
Overgangs-strategi

• Må være så fleksibel som mulig, Internet er for
  stort for koordinert overgang
• gamle og nye protokoller må kunne benyttes
  samtidig (interoperability)
• Dual stack
• Tunneling