mboost-dp1

Flickr - saschaaa

Danmark begynder for alvor at løbe tør for IPv4-adresser

- Via Version2 - , redigeret af Net_Srak

Om en måned forventes det at den sidste blok IPv4-adresser Europa tages i brug. Det betyder at det er slut for internetudbyderne i Danmark at få tildelt de adresser de beder om, eftersom de sidste adresser rationeres. Det skriver Version2.

Desværre tyder det på, at internetudbyderne i Danmark langt fra er klar til at tillade skiftet over til IPv6, som ville løse den akutte mangel på adresser. TDC tillader f.eks. kun erhvervskunder at benytte IPv6 og interessen har været lav ifølge dem.

Der har dog været tiltag for at få opmærksomhed omkring IPv6. Sidste år var der et dansk offensiv omkring problemstillingen som vi har omtalt herinde tidligere.





Gå til bund
Gravatar #1 - Felan
6. sep. 2012 09:39
Hvorfor skal folk altid vente til sidste øjeblik...
Gravatar #2 - Robbss
6. sep. 2012 09:40
Altså jeg kan da ikke se problemet i at løbe tør for IP adresser /sarcasm
Gravatar #3 - darkwulf
6. sep. 2012 09:42
Rimeligt fjollet at ikke bruge protokollen allerede nu.
Ihvertfald til privatbrugere, Hr og fru Hansen vil som ren bruger, lægge ikke mærke til forskellen.

Gamle og sløve virksomheder er en lidt anden sag, flere service tilbundet deres faste IP adresser.
Gravatar #4 - kasperd
6. sep. 2012 09:49
I mandags var der 5.2 millioner tilbage til Europa, i tirsdags var der 4.2 millioner. Det er fald på ca. 20% i løbet af et døgn. Slutningen af september begynder at lyde mere sandsynligt end starten af oktober.

darkwulf (3) skrev:
Gamle og sløve virksomheder er en lidt anden sag, flere service tilbundet deres faste IP adresser.
Hvis du kender nogen virksomheder med det problem må du gerne sætte dem i kontakt med mig. Jeg har en overgangsløsning netop beregnet til det.
Gravatar #5 - Brugernavn
6. sep. 2012 10:07
Det mest overraskende ved denne nyhed er at det ikke er Kasper, der har indsendt den.
Gravatar #6 - Erixxxx
6. sep. 2012 10:09
Kommer det som en overraskelse for nogen at de danske internetudbydere overhovedet ikke er klar til det her?
Gravatar #7 - Jackiass
6. sep. 2012 10:12
Erixxxx (6) skrev:
Kommer det som en overraskelse for nogen at de danske internetudbydere overhovedet ikke er klar til det her?

Ja
Gravatar #8 - mbw2001
6. sep. 2012 10:21
#1
Det gør man heller ikke. At ISP'erne ikke kan få tildelt nye puljer betyder ikke at ISP'erne ikke har en masse IP'er frie i allerede tildelte puljer.
Og ellers er der steder man kan "rydde op".

#3
Overgangen til IPv6 er ikke bare at trykke på en knap. Der er stadigvæk rigtig meget udstyr, både end-point, og core-udstyr som ikke fungerer 100% med IPv6.

Og man skifter ikke bare hele sin core med nyt udstyr og krydser fingre for at det fungerer.

#4
Kasper du bliver sq nødt til at få en grafiker ind over dit projekt. Jeg er ikke i tvivl om du ved vad du laver, men den hjemmeside ligner et gymnasieprojekt.
Gravatar #9 - Wishkeeper
6. sep. 2012 10:35
vil også give mbw2001 ret.......pt er der rigeligt adresser til vores forbrug og hvis der er mangel kan man bare rydde op i de nuværende klasse b og c netværk. f.eks google / TDC osv har "svinet" med de ip adresser de havde tilrådighed. Tror ikke at behovet for IPV6 bliver reelt før om 2-3 år da vi ikke har brug for ip adresser (offentlige ip'er) til alt udstyr som skal sættes til skyen......det er jo blandt andet derfor at routning / netværks tekniker har nok at lave idag......de begyndte allerede at skrige op omkring at der vil ikke være noget internet pga manglende ip adresser i 2010. Vi skriver pt 2012 mon ikke der går 2 år mere endnu før det bliver aktuelt......
Gravatar #10 - El_Coyote
6. sep. 2012 10:38
Erixxxx (6) skrev:
Kommer det som en overraskelse for nogen at de danske internetudbydere overhovedet ikke er klar til det her?


I nyheden står der netop at TDC tilbyder det til erhvervskunder, så jeg ved ikke hvor du får ideen om at man ikke er klar fra.
Der er ikke det store antal IPv4 adresser at hente fra privatkunder set i forhold til atbejdet der ligger i det, så derfor har man vel valgt ikke at bebyrde dem med evt. hardware udskift og support af efterfølgende problemer.
Gravatar #11 - ykok
6. sep. 2012 10:42
Gad vide om IPv6 ikke først bliver udrullet og udrullet hurtigt, når et eller andet vigtigt site i asien kun kører IPv6?

Tror personligt først det sker når der er en stor mængde kunder der kræver det.

Men er da personligt glad for de ufattelig mange offentlige IPv6 addresser jeg har - selvom det selvfølgelig er begrænset hvad jeg kan bruge dem til (men som nørd er det jo altid sjovt at lege med noget nyt teknologi).
Gravatar #12 - FlameBait
6. sep. 2012 10:54
Hvad ville konsekvensen være for mig som slutbruger, at skifte fra IPv4 til IPv6 ? Hvis nogen?
Gravatar #13 - terracide
6. sep. 2012 10:59
At de sidste adresser bliver delt ud til AS'er != at der ikke er flere ledige IPv4 adresser...ffs.
Gravatar #14 - fidomuh
6. sep. 2012 11:02
#12

At du ikke laengere har behov for NAT og du reelt kan faa internet-baserede enheder.

Udover det ... intet ... :D
Gravatar #15 - TuxDK
6. sep. 2012 11:03
#12

Du skal have nyt netværksudstyr, ellers ingen forskel.
Alt kører via DNS opslag alligevel.
Gravatar #16 - fidomuh
6. sep. 2012 11:04
#15

Alt kører via DNS opslag alligevel.


DNS hjaelper ham ikke med at fjerne NAT :P
Gravatar #17 - holiday
6. sep. 2012 11:06
oprydning, nedsætning af leasetider og mere nat er kun kortvarige lappeløsninger.

jeg tror desværre ipv6 implemteringen har lange udsigter. der er så vidt jeg ved major stadig major issues med ipv4 til ipv6 core udstyr, der skal vel laves sekundær ipv6 routning på alt. der er os lang vej før alle services på nettet supporter at sende til ipv6.
Gravatar #18 - mazlink
6. sep. 2012 11:27
Så kunne det da være vi skulle se at få tildelt os den IPv6 range vi har snakket om... Selvom vi har "rigeligt" IPv4 IP'er
Gravatar #19 - kasperd
6. sep. 2012 11:37
Brugernavn (5) skrev:
Det mest overraskende ved denne nyhed er at det ikke er Kasper, der har indsendt den.
Nogen kom mig i forkøbet. Det der pludselige fald på 20% på et døgn havde jeg ikke forudset.

mbw2001 (8) skrev:
Kasper du bliver sq nødt til at få en grafiker ind over dit projekt.
Jeg har haft en webdesigner til at give siderne et løft. For et halvt år siden så siderne lidt kedelige ud.

Wishkeeper (9) skrev:
f.eks google / TDC osv har "svinet" med de ip adresser de havde tilrådighed.
Nej. Der er ikke nogen af dem, som har brugt flere adresser end der var behov for. Faktisk har de holdt mere igen end godt er.

Udbredelsen af NAT skyldtes ikke mangel på adresser, det skyldtes at udbyderne tog urimeligt høje priser for IP adresser. Det har så også udsat forbruget i nogle år.

Men det har ikke løst nogen problemer. NAT enhederne er i dag en af de største forhindringer for at aktivere IPv6, fordi de har så dårlig support for IPv6. De udgør også en forhindring for nogle af transitionsmekanismerne. Det er f.eks. svært at køre en IPv6 tunnel gennem NAT.

Desuden har brugen af NAT betydet at det har taget flere år længere før problemet blev taget seriøst. Det betyder at vi i dag har et langt større internet der skal opdateres, end vi ville have haft, hvis vi ikke havde brugt NAT.

Uden NAT ville det have været nødvendigt at opgradere netværket for flere år siden, men til gengæld ville det være gået nemmere, og vi ville slet ikke have haft så store problemer, som dem vi står overfor nu.

FlameBait (12) skrev:
Hvad ville konsekvensen være for mig som slutbruger, at skifte fra IPv4 til IPv6 ? Hvis nogen?
Den mest sandsynlige oplevelse for den almindelige bruger er at internetforbindelsen vil begynde at føles mindre stabil pga. de problemer som #17 nævner. På et tidspunkt vil man få at vide fra sin internetudbyder, at man skal bruge et nyt modem og en ny router, fordi det gamle ikke kan bruges med IPv6. Der vil stadigvæk være stabilitetsproblemer efter det er udskiftet, det vil bare være andre problemer man oplever. Med tiden vil fejlene blive udbedret.

Forhåbentligt vil stabilitetsproblemerne ikke blive voldsomt store. Mange af dem er allerede identificeret og udbedret. Hvis din browser eller dit operativsystem er fra før 2011 skal det sikkert opdateres for at hjælpe på stabiliteten. For den almindelige bruger vil det betyde at man lever med de problemer der opstår indtil man bliver så træt af det, at man køber en ny computer.

Bemærk at jeg siger ikke at alle computere fra før 2011 skal udskiftes. Har man købt en computer i 2009 kan det sagtens være at der er kommet softwareopdateringer, som løser de stabilitetsproblemer, der måtte være. Og selv hvis den har været leveret med et operativsystem, der ikke har fået de nødvendige opdateringer, så kan der jo installeres et nyere. Sidstnævnte er bare ikke noget den typiske bruger kan finde ud af.

Det er selvfølgelig ikke kun browseren, der er vigtig. Det er bare det stykke software de fleste bruger mest med Internettet. For nogle brugere er det det eneste software, de bruger til Internettet.

Peer-to-peer, IP-telefoni, osv. vil opleve endnu større problemer. Det store Skype nedbrud for et par år siden var det første eksempel på, hvad der venter.
Gravatar #20 - HerrMansen
6. sep. 2012 11:48
TuxDK (15) skrev:
#12

Du skal have nyt netværksudstyr, ellers ingen forskel.
Alt kører via DNS opslag alligevel.


Ja der er vel ikke tale om andet end en eventuel routerudskiftnin for at understøtte IPv6 på internetsiden? Eller skal modem også opdateres til en nyere model?

/offtopic: I får ihvertfald ikke min 80.167.x.x IP! :O
Gravatar #21 - fidomuh
6. sep. 2012 12:50
#20

Ja der er vel ikke tale om andet end en eventuel routerudskiftnin for at understøtte IPv6 på internetsiden?


Hele pointen er, at du ikke skal bruge en router, saa at sige.

Eller skal modem også opdateres til en nyere model?


Hvis den skal skide IPv6 ud paa LAN-siden, saa muligvis, men sandsynligvis ikke.
Det meste udstyr har understoettet IPv6 i et par aar nu :)

/offtopic: I får ihvertfald ikke min 80.167.x.x IP! :O


Du skal ikke bruge din IP til noget, btw.
Med IPv6 faar du et par millioner IP'er og saa er det ligegyldigt med at huske dem anyway :P
Gravatar #22 - NerdDeveloper
6. sep. 2012 12:53
Næsten alle jeg kender der har en server med både IPv4 og IPv6 adresse, der slår man typisk IPv6 fra, da performance rammes hårdt når der laves en IPv4 loopback for hvert enkelt kald, dvs ca. 1 sekund extra pr kald.

Så til hosting brug har det konsekvenser pt. og dette "lag" undgås ved blot at deaktivere IPv6 på en Win2K8
Gravatar #23 - fidomuh
6. sep. 2012 12:56
#22

dvs ca. 1 sekund extra pr kald.


Det er forhaabentligt et isoleret tilfaelde.
Det er ikke noget jeg har bemaerket paa hverken Linux, OS X eller Windows - med IPv6.
Gravatar #24 - NerdDeveloper
6. sep. 2012 13:10
fidomuh (23) skrev:
#22

Det er forhaabentligt et isoleret tilfaelde.
Det er ikke noget jeg har bemaerket paa hverken Linux, OS X eller Windows - med IPv6.


Har set det på adskillige servere, med IIS og PHP primært dog. Du kan simpelthen se det via Firebug, det er ca. 1 sekund og du kan så under Ressource manager se at der ligger en forbandet stor mængde IPv4 Loopback forbindelser. (Kan godt være det er IPv6 loopback de står som, kan ikke huske det helt)
Gravatar #25 - CableCat
6. sep. 2012 13:10
Det er hver at bemærke at den sidste /8 block Europa er blevet tildelt er 5.0.0.0/8. Denne block bruges allerede uden tillades af Windows programmet Hamachi, til at spille gamle LAN spil over internettet. Når man bruger Hamachi, bliver man tildelt en unik IP i 5.0.0.0/8, og når man tilgår IP'er i 5.0.0.0/8, så går trafikken altid til Hamachi programmet.

Det betyder at alle der har Hamachi installeret, ikke kan tilgå IP'er fra 5.0.0.0/8. Dermed er disse IP'er mindre vær. Specielt hvis ens primære målgruppe for ens server er gamere.

læse mere her.
Gravatar #26 - kasperd
6. sep. 2012 13:53
HerrMansen (20) skrev:
Eller skal modem også opdateres til en nyere model?
Det kommer lidt an på omstændighederne. I princippet burde det ikke være nødvendigt, da et modem burde arbejde på et lavere protokol niveau end IP. Men nogle modems roder alligevel med oplysninger på højere niveau og har derfor brug for at kende forskel på IPv4 og IPv6. Derudover bruges IP i nogle situationer til at konfigurere modemet.

Hvis modemet er i stand til at bridge Ethernet trafik kan man få IPv6 til at virke selvom modemet ikke selv har IPv6 support. Og konfiguration af modemet er en af de ting der kan gøres med RFC 1918 adresser uden alt for mange problemer, da den slags alligevel sjældent ønskes udenfor den enkelte udbyders netværk.

Men på længere sigt vil udbyderne uden tvivl foretrække at køre den slags på ren IPv6. Så selv hvis et ældre modem kan bruges lidt endnu kan det godt være det skal skiftes på et tidspunkt.

fidomuh (21) skrev:
Hele pointen er, at du ikke skal bruge en router
En router vil give lidt bedre performance og sikkerhed. Desuden kan det være nødvendigt med en IPv6 router i den overgangsperiode hvor man kører dual stack.

I dag har mange en IPv4 router med NAT funktionalitet fordi der ikke er IPv4 adresser nok. Kører man dual stack forsvinder dette behov ikke. Man kan altså ikke forbinde sit lokalnets switch direkte til udbyderens netværk. Når man ikke kan gøre det har man brug for en anden måde at overføre IPv6 trafik mellem lokalnettet og Internettet. Til det formål har man brug for en IPv6 router.

Når engang man helt kan undvære IPv4 bliver det lidt nemmere at undvære en router. Så kan man sætte flere computere på en switch op imod udbyderens netværk.

CableCat (25) skrev:
Det er hver at bemærke at den sidste /8 block Europa er blevet tildelt er 5.0.0.0/8.
Det kommer an på hvad du mener med sidste. Det er den blok der er blevet tildelt adresser fra de sidste måneder. Så vidt jeg kan se er ca. 90% af 5/8 allerede tildelt.

Når RIPE begynder at rationere er der en /8 blok mere at tildele fra. Det er ikke nødvendigvis en sammenhængende blok, og de tildeles kun i meget små brudstykker. Så har man brug for nogle få IPv4 adresser til sin opgradering til IPv6, så kan man få nogle, som ikke kommer fra 5/8. De IPv4 adresser kan f.eks. bruges til IPv6 tunneller, NAT64, dual stack DNS servere osv.

CableCat (25) skrev:
Denne block bruges allerede uden tillades af Windows programmet Hamachi
Ja. Og Hamachi er ikke det eneste. Der er vist et par andre lignende programmer, som gør det samme.

Der er blevet efterspurgt en løsning i flere år, men der har været totalt tavshed fra producenten. Det var først da brugere blev nødt til at afinstallere programmet, at producenten reagerede ved at tilbyde en konfigurationsmulighed til at køre Hamachi i en ren IPv6 opsætning, der ikke ødelægger IPv4 routning til 5/8.
Gravatar #27 - ssch.dk
6. sep. 2012 15:14
Hold nu op...
1. Routning != nat
2. I kommer (forhåbentlig) stadig til at skulle have routere til ipv6, fordi bridging er generelt noget man helst skal undgå på wan links.
3. Hr/fru dk der skal køre dualstack, skal således have en 'dims' der kan lave nat-v4 samtidigt med at route ipv6, og det vil alt andet lige blive mere komplekst end blot nat-v4, og dermed mere ustabilt.
4. Etablerede operatører kommer ikke til at mangle adresser de næste 1-2 år.
Gravatar #28 - fidomuh
6. sep. 2012 15:32
#27

3. Hr/fru dk der skal køre dualstack, skal således have en 'dims' der kan lave nat-v4 samtidigt med at route ipv6, og det vil alt andet lige blive mere komplekst end blot nat-v4, og dermed mere ustabilt.


That'a make'a no'a sense'a .... .. ..

Hvorfor skulle det blive mere ustabilt af at koere en dual stack?
Og i det hele taget, hvorfor ikke bare gaa over til IPv6?

Det er ikke en overraskelse at vi skal skifte. IPv6 har eksisteret i *MEGET* lang tid.
Gravatar #29 - NerdDeveloper
6. sep. 2012 16:19
fidomuh (28) skrev:
#27

That'a make'a no'a sense'a .... .. ..

Hvorfor skulle det blive mere ustabilt af at koere en dual stack?
Og i det hele taget, hvorfor ikke bare gaa over til IPv6?

Det er ikke en overraskelse at vi skal skifte. IPv6 har eksisteret i *MEGET* lang tid.


Der er så godt som uendeligt mange IT løsninger der vil gå mere eller mindre i smadder ved et lyn-skifte.... Y2K var et mindre problem i forhold til dette...

Noget så simpelt som URL-rewriting i div webserver-baserede løsninger som fx. control paneler til gamehosting, TC-admin, whmcs og lignende går fx helt i smadder når localhost lige pludselig er ::1 i stedet for 127.0.0.1

Desuden er der mange der har sat alverdens "glemte" regler op med kald mod IP eller whitelisting af IP'er.

Det bliver ren change-and-pray......
Gravatar #30 - burgurne
6. sep. 2012 17:15
Nu er jeg ikke netværks"nørd", men hvis man kan/bør/skal fjerne sin router, hvordan kan man så få tilsluttet flere PC'ere som er bag en firewall? Det er jo det vi alm. dødelige gør i dag med en router?
Gravatar #31 - fidomuh
6. sep. 2012 17:18
#29

Der er så godt som uendeligt mange IT løsninger der vil gå mere eller mindre i smadder ved et lyn-skifte.... Y2K var et mindre problem i forhold til dette...


... OK ? :)
Hvem brugte systemer der ikke virkede henover aar 2000? :)
- Udover folk der er komplet fucktardede og ikke burde roere et stykke software? :)

Noget så simpelt som URL-rewriting i div webserver-baserede løsninger som fx. control paneler til gamehosting, TC-admin, whmcs og lignende går fx helt i smadder når localhost lige pludselig er ::1 i stedet for 127.0.0.1


Arh, jeg tror du overvurderer hvor nemt det er at lave en s/127.0.0.1/::1/g i en fil.
Derudover saa er det godt nok mange aar siden at jeg har brugt URL-rewriting til noget som helst baseret paa IP'er.

Desuden er der mange der har sat alverdens "glemte" regler op med kald mod IP eller whitelisting af IP'er.


Ja, udokumenterede systemer kommer og sparker en i kuglerne.
I'm sorry to tell you this, but that is how the world works :D

Det bliver ren change-and-pray......


Det vil det stort set altid vaere, men udstyrsmaessigt er det vel ufatteligt faa forbruger produkter der ikke understoetter IPv6, saa principielt vil du stadig kunne komme online, etc.

Derudover saa er det naeppe tilfaeldet at man skifter uden at bridge paa en eller anden maade :)
Der er en del ISP'er i udlandet som bare udbyder begge dele lige pt og andre som laver NAT mellem IPv4 og IPv6.
Det havde nok vaere smart at goere det samme her i DK, men det kan jo vaere de starter nu. :P

Gravatar #32 - fidomuh
6. sep. 2012 17:25
#30

Det kommer lidt an paa hvordan ISP'en vaelger at implementere det.
Det kan blive routet for dig, eller du kan smide din egen router op.
Lidt som det fungerer i dag, hvor man hos Fullrate fx kan faa bridging slaaet til (ogsaa kendt som Offentlig IP, eller lignende), hvor du saa selv saetter en router paa.

Det vil nok vaere at foretraekke hvis folk oensker at bruge en firewall, men ellers kan routing sagtens varetages af ISP'en.
Gravatar #33 - kasperd
6. sep. 2012 17:40
ssch.dk (27) skrev:
4. Etablerede operatører kommer ikke til at mangle adresser de næste 1-2 år.
Hvis nogen operatør har adresser nok til så lang tid, så må der være sket en fejl, for det er ikke i overensstemmelse med politikken
http://www.ripe.net/ripe/docs/ripe-553#-----policies-and-guidelines-for-allocations skrev:
The RIPE NCC allocates enough address space to LIRs to meet their needs for a period of up to 12 months.

Starting on 1 July 2010, a gradual reduction in the allocation period will be applied as follows:

As of 1 July 2010, the RIPE NCC will start allocating enough address space to LIRs to meet their needs for a period of up to nine months.

As of 1 January 2011, the RIPE NCC will start allocating enough address space to LIRs to meet their needs for a period of up to six months.

As of 1 July 2011, the RIPE NCC will start allocating enough address space to LIRs to meet their needs for a period of up to three months.


fidomuh (28) skrev:
Hvorfor skulle det blive mere ustabilt af at koere en dual stack?
Det er mere kompliceret og betyder derfor større risiko for implementationsfejl. Jeg kan give to helt konkrete eksempler, som er set i praksis, hvor dual stack var mindre stabilt en ren IPv4:

1. Hvis en computer får adgang til native dual stack vil den som udgangspunkt foretrække IPv6 fremfor IPv4. Hvis man prøver at tilgå et website som har dual stack DNS records, men det kun er IPv4 versionen der fungerer godt, så vil brugeren få en oplevelse af en mindre stabil forbindelse, når den bliver opgraderet til dual stack. Der er f.eks. websites som har AAAA records med en ugyldig IPv6 adresse. Der er også nogen som har en adresse som bruger en mindre stabil protokol som f.eks. 6to4 eller Teredo. Der er webservere som ikke svarer på IPv6 adressen (f.eks. set ved Bolignet Aarhus) og der er sites med en IPv6 adresse som der slet ikke er nogen rute til (også set ved Bolignet Aarhus).

2. Interaktion mellem protokollagene kan give uventede resultater. Jeg kan ikke huske præcist hvilken kombination af protokoller, der gav følgende problem, men jeg tror det involverede ADSL. Der var en router, som i en ren IPv4 opsætning ville genstarte protokollen på at lavere niveau, hvis den mistede sin IPv4 adresse. Denne genstart på et lavere niveau var i nogle situationer nødvendig for at kunne få en IPv4 adresse igen. Men da routeren også skal kunne bruges, når vi engang er gået over til ren IPv6, så genstarter den ikke lavniveauprotokollen, hvis den har en IPv6 adresse. Adressekonfigurationen til IPv6 var mere stabil end den til IPv4, det betød at i en dual stack opsætning kunne man risikere at routeren mistede IPv4 adressen men stadigvæk havde IPv6 og derfor ikke prøvede at genstarte forbindelsen.

Brugerne ville opleve at de periodisk mistede forbindelse til det meste af Internettet og var nødt til at genstarte routeren for at få forbindelse igen. Og det oplevede de aldrig før deres forbindelse blev opgraderet til dual stack.

fidomuh (28) skrev:
Og i det hele taget, hvorfor ikke bare gå over til IPv6?
Fordi så mange stadig kun kører IPv4. Internettet er for stort til at vi bare kan skifte fra den ene dag til den anden. Sådan et skift havde været mere realistisk, hvis det var blevet gjort tidligere. Men selv for ti år siden kunne man ikke bare afbryde hele Internettet for at opgradere.

fidomuh (28) skrev:
Det er ikke en overraskelse at vi skal skifte. IPv6 har eksisteret i *MEGET* lang tid.
Ja, men faktum er at der er mange som intet har gjort for at forberede sig.

burgurne (30) skrev:
Nu er jeg ikke netværks"nørd", men hvis man kan/bør/skal fjerne sin router, hvordan kan man så få tilsluttet flere PC'ere som er bag en firewall?
Du kan køre IPv6 uden router, men du bør ikke gøre det. Der er udbydere som har begrænsning på antal MAC adresser, hvilket har til formål at begrænse fobruget af IPv4 adresser. Men sådan en foranstaltning vil også begrænse antallet af computere du kan have online med IPv6 uden en router. Den begrænsning kan først fjernes når IPv4 udfases.

Men selv til den tid er det en fordel at have en router. Jo flere computere du har på lokalnettet, des flere multicast pakker sendes der. Uden router bruger alle disse multicast pakker af din båndbredde.

Desuden kan en router indeholde firewall funktionalitet. Jeg tror mange routere med IPv6 support vil have en eller anden form for firewall som default.
Gravatar #34 - fidomuh
6. sep. 2012 20:51
#33

Det er mere kompliceret og betyder derfor større risiko for implementationsfejl. Jeg kan give to helt konkrete eksempler, som er set i praksis, hvor dual stack var mindre stabilt en ren IPv4:

1. Hvis en computer får adgang til native dual stack vil den som udgangspunkt foretrække IPv6 fremfor IPv4. Hvis man prøver at tilgå et website som har dual stack DNS records, men det kun er IPv4 versionen der fungerer godt, så vil brugeren få en oplevelse af en mindre stabil forbindelse, når den bliver opgraderet til dual stack. Der er f.eks. websites som har AAAA records med en ugyldig IPv6 adresse. Der er også nogen som har en adresse som bruger en mindre stabil protokol som f.eks. 6to4 eller Teredo. Der er webservere som ikke svarer på IPv6 adressen (f.eks. set ved Bolignet Aarhus) og der er sites med en IPv6 adresse som der slet ikke er nogen rute til (også set ved Bolignet Aarhus).


Omend du har ret, saa kan det jo koges ned til "Hvis folk har sat deres DNS forkert op" ...

2. Interaktion mellem protokollagene kan give uventede resultater. Jeg kan ikke huske præcist hvilken kombination af protokoller, der gav følgende problem, men jeg tror det involverede ADSL. Der var en router, som i en ren IPv4 opsætning ville genstarte protokollen på at lavere niveau, hvis den mistede sin IPv4 adresse. Denne genstart på et lavere niveau var i nogle situationer nødvendig for at kunne få en IPv4 adresse igen. Men da routeren også skal kunne bruges, når vi engang er gået over til ren IPv6, så genstarter den ikke lavniveauprotokollen, hvis den har en IPv6 adresse. Adressekonfigurationen til IPv6 var mere stabil end den til IPv4, det betød at i en dual stack opsætning kunne man risikere at routeren mistede IPv4 adressen men stadigvæk havde IPv6 og derfor ikke prøvede at genstarte forbindelsen.


Hvilken router er det?
Og i det hele taget, wtf?! :)
Jeg ville nok kategorisere det der som et defekt modem :D

Brugerne ville opleve at de periodisk mistede forbindelse til det meste af Internettet og var nødt til at genstarte routeren for at få forbindelse igen. Og det oplevede de aldrig før deres forbindelse blev opgraderet til dual stack.


Og det er et problem der kommer uanset hvad. Saa der er ikke saa meget at goere end at springe ud i det.

Fordi så mange stadig kun kører IPv4. Internettet er for stort til at vi bare kan skifte fra den ene dag til den anden.


Ja, men nu er det ikke "en dag til anden" .. Det er whine, med whine paa, i 10 aar.
Folk maa altsaa tage sig sammen hvis de vil koere en webserver, no offence :D

Sådan et skift havde været mere realistisk, hvis det var blevet gjort tidligere. Men selv for ti år siden kunne man ikke bare afbryde hele Internettet for at opgradere.


Ofc not. For 10 aar siden havde det givet mening at begynde at dual stacke.
Som sagt, det fungerer fint i andre lande - og har gjort det i en del aar.

Ja, men faktum er at der er mange som intet har gjort for at forberede sig.


Hvis jeg ikke forbereder mig paa at skulle skide min. 1 gang hver 2. dag, saa skider jeg sgu i bukserne.
Welcome to the real world. Shit stinks :D

Den begrænsning kan først fjernes når IPv4 udfases.


- Lige et hurtigt spoergsmaal:
Hvorfor?
Hvis der er en begraensning paa antallet af mac adresser paa et givent netvaerk, kan maskinen der spytter IP'erne ud vel bare noejes med at allokere x adresser til et givent punkt og saa bare levere IPv6 i overflod? :)

Uden router bruger alle disse multicast pakker af din båndbredde.

Desuden kan en router indeholde firewall funktionalitet. Jeg tror mange routere med IPv6 support vil have en eller anden form for firewall som default.


Firewall er nok mere at foretraekke, end at have en router for at begraense multicast ;)
Gravatar #35 - kasperd
6. sep. 2012 22:37
fidomuh (34) skrev:
Omend du har ret, så kan det jo koges ned til "Hvis folk har sat deres DNS forkert op" ...
Der er meget andet i det end blot DNS opsætning.

fidomuh (34) skrev:
Hvilken router er det?
Jeg kan ikke huske om jeg faktisk fik at vide hvilken router det var. Det er ikke et problem jeg selv har oplevet, men jeg har fået problemet beskrevet af en person, som vidste hvad han havde med at gøre.

Man kunne selvfølgelig godt argumentere for, at på nuværende tidspunkt er god support for dual stack vigtigere end god support for ren IPv6, og derfor burde routeren som default have opført sig anderledes.

Jeg aner ikke om opførslen på det punkt kunne konfigureres, men det ville give mening, hvis routeren betragtede ren IPv6 som en fejlopsætning og prøvede alle midler for at få en IPv4 adresse, også selvom det betød at den midlertidigt mistede IPv6 adgang.

fidomuh (34) skrev:
Og det er et problem der kommer uanset hvad. Så der er ikke så meget at gøre end at springe ud i det.
Ja, og man burde have startet for 10 år siden. Havde man startet for ti år siden med at få dual stack ud til én bruger og derefter arbejdet på at fordoble antallet af brugere en gang per kvartal, så ville man have været færdig før IANA løb tør for IPv4 adresser. Og en fordobling per kvartal giver rimelig god tid til at man kan opdage fejl mens de kun påvirker et lille antal brugere og få dem udbedret i tide.

fidomuh (34) skrev:
Ja, men nu er det ikke "en dag til anden" .. Det er whine, med whine på, i 10 år.
Jeg svarede på hvorfor man ikke bare kan skifte. Man er nødt til at køre begge i en overgangsperiode. Den overgangsperiode burde være sluttet i 2010, men sådan gik det ikke. Der er stadig brug for en overgangsperiode, også selvom den først starter nu, hvor den burde have været overstået.

fidomuh (34) skrev:
Folk må altså tage sig sammen hvis de vil køre en webserver
Det er ikke kun webservere der er problemer med. Og det store problem her er at man er nødt til at levere en løsning der kan fungere sammen med det værste juks andre systemadministratorer kan finde på.

Hvis du har sat dit eget netværk rigtigt op, men det stadigvæk ikke virker, fordi man skal kommunikere sammen med et netværk sat op af en amatør, så er det stadig dig der får skylden, når dine brugere oplever et problem.

For nogle betyder det at man er nødt til at virke perfekt sammen med ethvert fejlkonfigureret netværk eller også miste sine brugere.

fidomuh (34) skrev:
Den begrænsning kan først fjernes når IPv4 udfases.


- Lige et hurtigt spoergsmaal:
Hvorfor?
Hvis der er en begrænsning på antallet af mac adresser på et givent netværk, kan maskinen der spytter IP'erne ud vel bare nøjes med at allokere x adresser til et givent punkt og så bare levere IPv6 i overflod? :)
Jeg ved faktisk ikke præcist hvad der foregår på det næste niveau.

Med IP over kabel TV netværk er det meget almindeligt at begrænsning af antal MAC adresser flyttes helt ud i kabelmodemet selv. Men på den anden side er udstyr på udbyderens side i stand til at se både kabelmodemets MAC adresse og de enkelte computeres MAC adresse.

Jeg ved ikke hvorfor udbyderne ikke bare kan bruge de to oplysninger til at begrænse antallet af IPv4 adresser per kabelmodem.

Det ville være smart hvis de tildelte f.eks. to offentlige IPv4 adresser til hver kunde. Den ene tildeles den første enhed kunden kobler op med. Den anden IPv4 adresse bruges til NAT af resten af kundens enheder.

fidomuh (34) skrev:
Firewall er nok mere at foretrække, end at have en router for at begrænse multicast
Nu var det ikke et valg mellem to muligheder. Grænsen mellem en firewall og en router er alligevel ikke klart defineret.

Med IPv6 er der ikke nogen grund til at bruge NAT, så sådan en enhed skal ikke modificere pakkerne, den skal blot beslutte hvilke den lukker igennem og hvilke den blokerer. Det er en langt simplere opgave end at skulle modificere pakkerne.

Om man så vil lave stateful inspection eller blot stateles filtre er mindre vigtigt. Til TCP ville jeg foretrække at det var stateles, fordi det giver mulighed for hurtigere routing i hardware, og fordi at man så kan genstarte routeren uden at tabe forbindelser.
Gravatar #36 - fidomuh
6. sep. 2012 23:18
#35

Jeg tror vi kan koge det ned til:
"Vi er loebet toer for adresser. Needs fix naow."

Problemet er, at vi ikke har 10 aar til en overgangsfase - Jeg er helt enig i at det havde vaeret optimalt. Men nu har folk ignoreret problemet i mange aar og "pludselig" skal det loeses.
Jeg kan ikke se nogen anden loesning end at vi massivt ruller dual-stack enheder ud.

Og i fx Frankrig virker de ganske fint.
Saa der ER testede enheder, som er testet i en aarraekke.

Hvorvidt de virker perfekt skal nok ses i relief til det udstyr vi har i dag og hvor ofte det byttes ud ... :)
Gravatar #37 - tentakkelmonster
8. sep. 2012 11:46
fidomuh (14) skrev:
#12
At du ikke laengere har behov for NAT og du reelt kan faa internet-baserede enheder.

Det er faktisk interessant, hvis det forholder sig sådan. NAT er en kæmpe begrænsning når de gælder direkte udveksling mellem to internet-brugere. Der vil være mange nye slags services der pludselig bliver mulige, hvis folk pludselig ikke er spærret inde bag en firewall, de ikke kan finde ud af at konfigurere - hvilket jo er tilfældet med NAT og Hr og Fru Danmark.
Gravatar #38 - kasperd
8. sep. 2012 23:58
tentakkelmonster (37) skrev:
Der vil være mange nye slags services der pludselig bliver mulige, hvis folk pludselig ikke er spærret inde bag en firewall
Der vil nok stadigvæk være mange, som er bagved en firewall. Men selv i de tilfælde er det nemmere at få pakker mellem to brugere, end hvis de befinder sig bagved hver sin NAT.

Der findes metoder til at få pakker mellem brugere bagved hver deres NAT, men de er meget upålidelige. Desuden afhænger pålideligheden i høj grad af, hvordan NAT enheden opfører sig. Med nogle NAT enheder er det næsten umuligt.

Anvender applikationen samme metoder mellem brugere bagved hver deres firewall (uden NAT selvfølgelig), så virker det mange gange mere pålideligt.

Pointen er følgende. Firewallen tillader at klienterne bagved den kan sende pakker ud til servere på Internettet. Den tillader også at pakker sendes tilbage fra serveren til klienten.

Begge klienter kan kommunikere med samme server. Klienten kan fortælle serveren, at den ønsker at kommunikere med en anden klient. Serveren kan fortælle klienterne IP adresserne på hinanden.

Hvis klienterne på samme tid sender pakker til hinanden vil de to pakker passere hinanden på nettet mellem de to firewalls. Når pakkerne når frem til den anden ende vil hver firewall tro det er et svar på den pakke som den så klienten sende ud. Dermed er forbindelsen etableret.

Prøvede man at gøre det samme med en NAT ville det ikke virke lige så pålideligt, da den laver om på portnumre og IP adresser på pakkerne på en uforudsigelig måde. Dermed ved serveren ikke hvilken adresse den skal fortælle hver klient om.

Hvis man ser på nogle af de transitionsmekanismer som findes til overgangen fra IPv4 til IPv6 og hvis man ser på de problemer disse mekanismer lider af, så hænger mange af problemerne sammen med brugen af NAT til IPv4. Det gælder for 6to4, 6in4 og Teredo. Selvom Teredo er designet til at virke på trods af NAT, er den ikke voldsomt pålidelig, hvis begge endepunkter er bagved NAT.

Det er NAT som udgør det store problem ikke firewalls. Desværre er der mange, som ikke har forstået forskellen.
Gravatar #39 - CableCat
11. sep. 2012 09:03
kasperd (38) skrev:
Det er NAT som udgør det store problem ikke firewalls. Desværre er der mange, som ikke har forstået forskellen.


Problemet i NAT er i høj grad state, altså at NAT-boxen skal huske forbindelser. Hvis man for eksempel køre SSH igennem en dårlig NAT-box, og ikke fortage sig noget i et stykke tid, så tabes forbindelsen.

Det samme problem har en state-full firewall. Så det problem bliver ikke løst med IPv6.

Det faktisk nemt at lave en state-less firewall. Formålet med state er normalt at tillade retur-traffik, men samtidigt blokerer for nye forbindelser.

Problemnet har været før i tiden at man uden state, ikke kunne se forskel på om en pakke var retur-traffik eller en ny forbindelse.

Men langt om længe, så føljer de fleste OS standarten for hvilke porte der bliver brugt til retur-traffik (dynamiske porte). Som siger at porte fra 48K skal bruges til retur-trafik. Dog bruger Linux fra 32K, man kan ændre det, eller antage at der alligevel ikke køre nogle services imellem 32K og 48K.

Eksempel på state-less firewall, der tillader returtrafik

permit udp any any eq ntp #NTP klienter bruger port 123 som source adresse
deny tcp any any range 0 32767 #Ikke dynamiske porte blokers
deny udp any any range 0 32767 #Ikke dynamiske porte blokers
permit ip any any #Tillad alt andet
Gravatar #40 - stekkurms
11. sep. 2012 10:18
kasperd (19) skrev:
Det store Skype nedbrud for et par år siden var det første eksempel på, hvad der venter.
Oh noes.

kasperd (38) skrev:
Det er NAT som udgør det store problem ikke firewalls. Desværre er der mange, som ikke har forstået forskellen.
Hvis jeg står med et stykke hardware, som jeg kan sætte mellem mit lokalnet og internettet, hvordan finder jeg så ud af, om det er en firewall eller NAT?
Gravatar #41 - fidomuh
11. sep. 2012 10:20
#40

det goer du, sjovt nok, ved at se om den laver NAT.
Hvis den ikke laver NAT, saa er det enten bare en switch, router eller hub. Hvis den laver NAT, saa er det stadig en router, den laver bare NAT ogsaa.

Hvis du samtidig laver port/ip/pakke filtrering, saa er det en firewall.

Easy :D
Gravatar #42 - kasperd
11. sep. 2012 11:34
CableCat (39) skrev:
Problemet i NAT er i høj grad state, altså at NAT-boxen skal huske forbindelser.
Det er kun et af problemerne. Selv hvis NAT har RAM nok til at huske alle forbindelserne, så udgør den stadigvæk et problem for P2P protokoller (og for den sags skyld alle protokoller, som ikke følger en klient-server model).

En workaround for det problem kræver at NAT genbruger mappings fra åbne forbindelser, når der oprettes nye forbindelser hvor det ene endepunkt matcher en eksisterende forbindelse. Samtidigt kræver det at applikationen forsøger at sende simultane pakker fra begge ender af kommunikationen.

CableCat (39) skrev:
Hvis man for eksempel køre SSH igennem en dårlig NAT-box, og ikke fortage sig noget i et stykke tid, så tabes forbindelsen.
Nogle NAT enheder taber også forbindelsen så snart man logger ind fordi klienten ændrer forbindelsens ToS afhængigt af om det er en interaktiv forbindelse.

CableCat (39) skrev:
Det samme problem har en state-full firewall. Så det problem bliver ikke løst med IPv6.
Nej, men andre større problemer bliver løst. Det faktum at der kun filtreres og ikke laves om på pakkerne undervejs betyder at portnumre er forudsigelige for applikationen.

CableCat (39) skrev:
Problemnet har været før i tiden at man uden state, ikke kunne se forskel på om en pakke var retur-traffik eller en ny forbindelse.
For TCP kan man nå langt ved blot at betragte flags. Hvis man spærrer for SYN pakker fra Internettet og lader alt andet komme igennem er man i princippet sikret, så længe der ikke er store fejl i TCP implementationen anvendt af computere på lokalnettet.

Man kan gå et skridt videre og kun lukke pakker fra Internettet ind såfremt der enten er en indgang som matcher, eller pakken fra Internettet ser meget almindelig ud. På den måde sikrer man sig, at man ikke uden videre kan angribe TCP stakken på lokalnettet ved at sende usædvanlige pakker.

Samtidigt oprettes TCP forbindelsen automatisk i firewallen, hvis der sendes pakker udad (og det ikke er TCP reset pakker).

Med den kombination har man en rigtig god beskyttelse, og selv hvis firewallen har glemt en forbindelse er der stor chance for at den automatisk kan genoprettes på sikker vis.

En totalt stateless firewall har dog den store fordel, at den er nemmere at replikere.

CableCat (39) skrev:
Men langt om længe, så føljer de fleste OS standarten for hvilke porte der bliver brugt til retur-traffik
Jeg ville være mere tryg ved en firewall der baserede filtreringen på TCP flags end en, der baserer det på portnumre.

stekkurms (40) skrev:
hvordan finder jeg så ud af, om det er en firewall eller NAT?
Begge er features som normalt tilføjes til en router. De kan også godt tilføjes på et andet lag, f.eks. i en switch. Hvis ikke det er en router, så bør det fremgå helt klart, at det er tilfældet.

At mange så også bruger betegnelsen router, når de reelt snakker om en NAT enhed, gør situationen mere indviklet.

F.eks. betyder bridging firewall, at det er en firewall som er en switch og ikke en router. Men da du ikke har nævnt andet, vil jeg gå ud fra at du spørger til enheder i router kategorien.

En firewall er en router, som udfra en konfigureret politik beslutter, hvilke pakker der tillades, og hvilke der ikke tillades. Det kan være stateless eller stateful. Stateless betyder at politikken entydigt angiver om en pakke tillades eller om den ikke tillades. Med en stateful firewall afhænger beslutningen ikke kun af den pågældende pakke, men kan også afhænge af tidligere pakker.

En firewall vil enten tillade eller afvise en pakke. Den laver ikke om på pakkerne. (Eller lidt mere præcist, den laver ikke om på pakkerne på anden måde end en router ville gøre, det vil sige at den tæller TTL ned og ændrer evt. ECN flag for at indikere congestion.)

En NAT laver om på pakkerne. Nærmere specifikt kan den lave om på IP adresser og portnumre. Der er forskellige underklasser af NAT afhængigt af, hvilke oplysninger, der ændres.

En NAT kan også være enten stateless eller stateful. Dog har stateless NAT ikke ret mange anvendelser. De fleste referer normalt til stateful NAT.

En NAT behøver til gengæld ikke lave filtrering på pakker. Den kan i princippet sende vilkårlige pakker igennem. Dog vil en NAT i nogle tilfælde stå med pakker, som den ikke kan sende videre, fordi de ikke passer med dens tilstand eller konfiguration. I så fald er en NAT enhed nødt til at afvise sådanne pakker. Det er denne egenskab ved NAT, som gør at den nogen gange forveksles med en firewall.

En router kan godt have både firewall og NAT funktionalitet. F.eks. har iptables til Linux begge typer funktionalitet. Og iptables har også features, som ikke passer helt ind i hverken den ene eller anden klasse, da iptables kan ændre felter i pakkerne som en NAT ikke laver om på.
Gravatar #43 - kasperd
11. sep. 2012 12:20
I løbet af den sidste uge er beholdningen af /8 blokke reduceret fra 1.31 til 1.15. Når man trækker den reserverede blok fra betyder det et fald fra 0.31 til 0.15. Det er over halvdelen brugt på en uge.

Jeg tror ikke længere på, at de holder måneden ud.
Gravatar #44 - fidomuh
11. sep. 2012 12:55
#43

Men ifoelge Terracide har ISP'erne masser af IP'er. Saa 1-2 aar endnu er vel realistisk? :)
Gravatar #45 - kasperd
11. sep. 2012 14:27
fidomuh (44) skrev:
Men ifoelge Terracide har ISP'erne masser af IP'er. Saa 1-2 aar endnu er vel realistisk?
Den påstand er også blevet fremsat af en anden bruger i denne tråd. Den besvarede jeg allerede i #33.

Udbydere som har fået en ansøgning behandlet før 1. juli i år var berettiget til at få nok adresser til 6 måneder. Det vil sige indtil 1. januar 2013. Udbydere som får adresser tildelt i denne uge er berettiget til at få nok til 3 måneder. Det vil sige indtil engang i december.

Først efter 1. oktober i år vil udbydere i Europa være berettiget til at få allokeringer til at strække længere end 1. januar 2013. Og det vil kun gælde, hvis forbruget sløver ned øjeblikkeligt. Hvis den nuværende hastighed holder, vil grænsen hvor en ny politik træder i kraft blive krydset inden udgangen af september.

Det vil sige at udbyderne kan godt have en reserve frem til nytår.

Allokeringerne sker i store blokke, og derfor vil reserven naturligvis variere. Den politik jeg citerede angav ikke om de 3 måneder skal fortolkes som minimum eller maksimum. Hvis det er et minimum kan der godt være udbydere som er heldige og har adresser nok til længere tid.

Men jeg tvivler på at alle danske internetudbydere bare har været heldige. Hvis alle de danske udbydere har rigeligt med adresser om et halvt år, så har de nok fundet en måde at omgå den politik, jeg citerede.
Gravatar #46 - fidomuh
11. sep. 2012 14:52
#45

Saa realistisk set skal vi have IPv6 inden December... ;)
Gravatar #47 - kasperd
11. sep. 2012 15:33
fidomuh (46) skrev:
Saa realistisk set skal vi have IPv6 inden December
Når udbyderne løber tør har de nogle valgmuligheder:
- De kan sige nej til nye kunder (usandsynligt)
- De kan købe adresser af andre, som er i stand til at reducere deres brug (men udbuddet vil nok være meget begrænset)
- De kan forringe den ydelse de leverer til kunderne (og det vil nok ske).

En model hvor forringelserne kun rammer nye kunder tror jeg ikke helt kan hænge sammen, så det kommer nok til at ramme eksisterende kunder.

De kan nedsætte lease tiden på dynamiske adresser. Det kræver så at kundernes DHCP klient refresher den oftere. Og du vil oftere opleve at du får en ny adresse fordi din DHCP klient ikke har kommunikeret med serveren i et stykke tid.

Det betyder f.eks. at hvis man slukker for sin router i et stykke tid er der større sandsynlighed for at IP adressen er ændet når den tændes igen.

Men det er begrænset hvor mange adresser man kan spare på den måde.

En anden mulighed er at bruge CGN og lade være med at give kunderne en offentlig IP adresse. Hvis en udbyder gør det, før de har native IPv6 support ude hos kunderne, bør miste deres kunder.

Udbyderne kan også give kunderne færre IP adresser som udgangspunkt og øge prisen på ekstra. Det hjælper bare ikke så meget, da der nok er mange kunder som alligevel kun bruger en enkelt til deres router og selv kører NAT.

Så udbyderne kan sagtens finde måder at udskyde opgraderingen længere end de allerede har gjort det. Men det er ikke noget man som kunde bør acceptere.
Gravatar #48 - Magten
11. sep. 2012 15:54
fidomuh (44) skrev:
#43

Men ifoelge Terracide har ISP'erne masser af IP'er. Saa 1-2 aar endnu er vel realistisk? :)
Skal vi nu ikke lige forholde os til det han rent faktisk skriver? Det er jo langt fra det der.
Gravatar #49 - fidomuh
11. sep. 2012 17:58
#48

Teh foo. Det var ikke Terracide der skrev det. Det var ssch.dk :)

My bad. Jeg er for vant til at trolle terracide :/
Gravatar #50 - kasperd
14. sep. 2012 16:34
Brugernavn (5) skrev:
Det mest overraskende ved denne nyhed er at det ikke er Kasper, der har indsendt den.
Til gengæld har jeg indsendt den næste. https://www.ripe.net/internet-coordination/news/ri...
Gå til top

Opret dig som bruger i dag

Det er gratis, og du binder dig ikke til noget.

Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.

Opret Bruger Login