IPv6 via ISATAP, 6to4 eller Teredo

Hej..

Jeg er igang med at læse lidt på hvordan man kan implementere IPv6 i et miljø hvor der er kun IPv4 og ingen native IPv6..
Jeg vil så høre jer lidt hvordan man bedst griber det an? Jeg har etableret et ISATAP netværk og det fungerer men jeg har læst at det er bedre med 6to4 og det er jeg igang med at læse om men det er lidt tungt.. Nogen af jer der kan forklare de forskelligheder der er imellem ISATAP 6to4 og Teredo? (Jeg regner med 3000 ord fra dig Kasperd.. :P )

Af ren interesse, hvad skal det bruges til? (Mindes at du snakkede om DirectAccess for et par uger siden)

Det skal bruges i Direct Access. Jeg har det kørende i produktionsmiljøet med ISATAP men jeg har læst mig frem til, somewhere som jeg ikke kan huske, at det er bedre med 6to4 istedet for ISATAP..

didriksen86 (1) skrev:

Jeg regner med 3000 ord fra dig Kasperd

Det skal du også nok få. Men der er ingen grund til at bruge dem alle sammen på min første kommentar.

didriksen86 (1) skrev:

Jeg har etableret et ISATAP netværk og det fungerer men jeg har læst at det er bedre med 6to4 og det er jeg igang med at læse om men det er lidt tungt..

Jeg har ikke erfaringer med ISATAP, men jeg har nok erfaringer med IPv6 tunnel protokoller til at jeg kunne gennemlæse ISATAP artiklen på Wikipedia og forstå, hvordan det passer ind i en sammenhæng.

Først vil jeg slå fast, at hvis man synes man står med valget mellem ISATAP og 6to4, så har man ikke forstået det problem man står overfor. Fordi ISATAP og 6to4 løser to forskellige problemer. Og forskellen i formålet beskrives meget godt af navnet ISATAP, der står for Intra-Site Automatic Tunnel Addressing Protocol.

6to4 bruges til kommunikation mellem forskellige sites eller kommunikation mellem et site og IPv6 backbone. ISATAP bruges derimod til kommunikation indenfor et site.

ISATAP

ISATAP fungerer som et virtuelt netsegment. Det opfører sig ikke helt lige som Ethernet, men på et overordnet plan kan du godt få en idé om hvordan det bruges ved at forestille dig, at ISATAP er en enkelt virtuel switch. Det som ISATAP kan bruges til er situationen hvor du har forskellige computere indenfor sitet som du gerne vil have IPv6 på, og de computere ikke er direkte forbundet med en eller flere switches.

F.eks. computer A har 192.168.0.2 og computer B har 192.168.1.2. De to computere kommunikerer gennem en router, der har adresse 192.168.0.1 og 192.168.0.2. A og B kan ikke snakke IPv6 direkte med hinanden fordi der sidder en router imellem, og den router snakker kun IPv4. Her kan ISATAP hjælpe.

Hvis derimod A og B kunne kommunikere med hinanden uden at involvere en router, men blot skal sende pakkerne gennem en eller flere switches, så kan du lige så godt bruge native IPv6 mellem A og B. Switchen er ligeglad med om pakkerne er IPv4 eller IPv6.

Og såfremt der er nogle enkelte routere, men de routere kan opgraderes til at køre dual stack, så kan du også køre native IPv6 indenfor sitet.

Endeligt er ISATAP kun relevant hvis det bruges til at skabe forbindelse mellem mere end tre computere, eller hvis IP adresserne på dit lokalnet er dynamiske. Op til tre computere med statiske IP adresser er det simplere at konfigurere statiske 6in4 tunneller på end at sætte ISATAP op.

Så situationerne hvor ISATAP er nødvendigt er forholdsvist begrænsede. Det udelukker dog ikke at du kan være i en af de situationer, hvor det er relevant.

Under alle omstændigheder er ISATAP kun et muligt svar på kommunikation internt. Det giver dig ikke ekstern kommunikation.

6to4

6to4 er en mulighed for ekstern kommunikation. Det fungerer glimrende, så længe begge endepunkter bruger 6to4. Men til kommunikation hvor det ene endepunkt bruger 6to4 og det andet endepunkt bruger native IPv6 er man afhængig af tredjeparts relays. Disse relays er ikke altid pålidelige, og det har givet 6to4 et dårligt ry. Dette dårlige ry har fået mange til at undgå 6to4 for enhver pris, også i situationer, hvor 6to4 er det bedste valg. Et eksempel på hvor ekstremt nogen undgår 6to4, så undlader Google at indeksere sites, som kun er tilgængelige over 6to4.

Mit råd er at sætte sit netværk op med mulighed for at kommunikere over 6to4, men lad endeligt være med at sætte et netværk op, hvor 6to4 er den eneste mulighed for ekstern kommunikation.

6in4

Dine andre muligheder for ekstern kommunikation er native IPv6 eller en tunneludbyder. Hvis ikke du har adgang til en internetudbyder med native IPv6, så er en tunnel den eneste mulighed.

En tunneludbyder kan vælge mellem et antal forskellige protokoller. 6in4 og ISATAP er begge mulige protokoller, som en tunneludbyder kan vælge at understøtte. Den mest udbredte er mig bekendt 6in4, som også er langt den simpleste. Der er flere forskellige udbydere af gratis 6in4 adgang. Jeg bruger selv primært tunnelbroker.net, som kun understøtter 6in4 men det er nemt at komme i gang.

Teredo

Teredo er en anden autotunnel protokol som er lidt i stil med 6to4. Men hvor 6to4 tillader at man kan bruge det til et større site med op til 65536 netsegmenter, så kan Teredo kun bruges til enkelte hosts. Teredo kan faktisk være endnu mere ustabilt end 6to4 (selvom Teredo kun er afhængigt af et relay, hvor 6to4 er afhængigt af to).

Som udgangspunkt fraråder jeg at man bruger Teredo, med mindre man har et meget specifikt behov, hvor Teredo er den rette løsning.

Men selvom jeg fraråder, at du bruger Teredo, så bør du forberede dig på at kommunikere med andre, som bruger Teredo. Og den måde du forbereder dig på det er ved at sætte dit eget Teredo relay op. Det kræver at du har en enkelt computer med en offentlig IP adresse, for at du kan sætte et Teredo relay op. Hvis computeren kører Linux, så er Miredo nemt at sætte op.

Teredo relayet skal du dog først gå i gang med, når du har en fungerende forbindelse mellem dit site og IPv6 backbone.

Efter jeg har sat mine egne Teredo relays op har jeg fundet en anvendelse, hvor Teredo er et godt valg. Det er til min laptop som ofte befinder sig på netværk hvor jeg hverken har native IPv6 eller en offentlig IPv4 adresse. På de netværk kan min laptop gøre brug af Teredo, som kan fungere gennem en NAT enhed. Selvom Teredo er ustabilt, så er forbindelsen hjem til mine egne netværk stabil, netop fordi jeg har mit eget Teredo relay.

#4
942 ord i første kommentar er vel stadig en sjat. :)

#4
Mange tak. Jeg skal nok huske på dig når jeg vinder i lotto.
Jeg er nået så langt i læseriet at jeg har indset det med ISATP = til intra og 6to4= internet.
Jeg har små noter som jeg kan dele lidt her:

ISATAP:
1: ISATAP i DNS(Microsoft blokerer ISATAP i deres DNS så den skal først unblockes) også fungerer det automatisk i intranet.
2: Det er kun til intranet brug. Ingen ekstern IPv6.

6to4:
1: Har brug for ekstern IPv4 adresse.
2: Kan bruges på internettet
3: Sender router advertisement på intranettet når det er oppe og køre(?)

Teredo:
1: Bruges hvis man sidder bagved et NAT device ellers bruges det ikke normalt.


Er de rigtige nok? :) Så har jeg lige et par spørgsmål til:
1: Tunneludbydere og relays, er det et problem mht. datasikkerheden?
2: IPv6 og firewall's. Findes der firewalls der kan DPI IPv6 og hvorledes gør man med IPv6 trafik og firewalls ret generelt?

didriksen86 (6) skrev:

6to4:
1: Har brug for ekstern IPv4 adresse.

Korrekt. Der er software, som fejlagtigt sætter 6to4 op baseret på en RFC 1918 adresse. Når software begår den slags fejl, så er der ting som holder op med at virke. 6to4 kan kun virke korrekt med en ekstern IPv4 adresse, men 6to4 tillader til gengæld op til 65536 netværk bagved den ene IPv4 adresse.

didriksen86 (6) skrev:

Sender router advertisement på intranettet når det er oppe og køre(?)

Det har som sådan ikke noget med 6to4 protokollen at gøre. Har man en router, som kører 6to4, så forventer man at den sender router advertisements på lokalnettet, og det gør de som regel også. Men det er to forskellige interfaces på routeren. På lokalnettet bruger den native IPv6, men man kan stadig se på adresserne, at det er 6to4.

didriksen86 (6) skrev:

Findes der firewalls der kan DPI IPv6

Jeg ved det ikke. IPv6 headeren, som routere skal bruge for at forwarde pakker, er simplere end IPv4 headeren. Det er dermed nemmere at lave en router som hurtigt kan forwarde IPv6 pakker end tilsvarende med IPv4. Til gengæld er IPv6 extension headers en anelse mere kompliceret, og de gør DPI noget besværligt.

Der hvor det bliver udfordrende er med fragmenterede pakker. I IPv6 er fragmenteringsheaderen valgfri, hvor den i IPv4 var en del af IP headeren. Men den virkeligt store forskel for DPI er muligheden for at extension headers også kan fragmenteres.

Da der kan være andre extension headers både får og efter fragment headeren, og extension headers efter fragmentheaderen i sig selv kan være fragmenteret er det vanskeligt at lave DPI. Der kan være så mange extension headers at de fortsætter ind i andet fragment.

Hvis det sker er det umuligt at lave DPI uden først at samle fragmenterne til en enkelt pakke. Første pakke indeholder ikke alle extension headers, og man har ikke selve payload med. Det er ikke engang sikkert at man ved hvilken protokol der gemmer sig inde i pakken.

Anden pakke indeholder måske starten af payload, men man kan ikke fra anden pakke vide præcist hvordan data efter fragmentheaderen skal fortolkes, da man ikke har de mellemliggende data. Man ved med andre ord hverken ved offset er på den første header efter extension headeren eller dens type.

Så en firewall ville være nødt til at huske på den første pakke og så evt. afvise den anden pakke, når den kan evalueres i den rette kontekst. En simplere løsning er at afvise alle pakker, hvor payloadheaderen ikke er med i første fragment.

En afsender kan også forsøge at spekulere i fejlagtig samling af pakker. Hvis man afsender flere pakker med samme ID, så kan en situation med tabte pakker eller redundante firewalls betyde at pakker samles anderledes på firewallen end på sluthosten. Det kan betyde at hosten samler noget, som firewallen ville have afvist, hvis den havde sat samme fragmenter sammen.

Jeg har set et eksempel på en router der droppede pakker med mere end 256 bytes extension headers, hvilket er lidt hen i retning af metoden med at droppe pakker med flere extension headers end der er plads til i første fragment.

didriksen86 (6) skrev:

og hvorledes gør man med IPv6 trafik og firewalls ret generelt?

I princippet gør man det samme som med IPv4. Man skal bare huske at når man har en tunnel, så skal man sikre sig at den ikke går direkte gennem firewallen uden at pakkerne bliver filtreret.

Enten skal firewallen lave DPI for at se IPv6 pakkerne inde i IPv4 pakkerne, eller også skal man route IPv6 pakkerne gennem en firewall når man har pakket dem ud.

På IPv4 har man ofte lavet NAT og firewall sammen og brugt samme stateful inspection til begge formål. På IPv6 er NAT totalt overflødiggjort og bør så vidt muligt undgås. At der ikke er NAT gør boksens opgave lidt simplere da den ikke længere skal modificere pakkerne. Man har så muligheden for helt at undgå tilstand og lave stateless filtrering. Men mange fortrækker dog at holde sig til en stateful firewall som de har været vant til, tilstanden skal så kun bruges til filtrering og ikke længere til at modificere pakkerne, hvilket stadig er en simplificering i forhold til IPv4 og gør kommunikationen lidt mere pålidelig.

Man skal også huske at på nogle firewalls konfigureres filtrering af IPv4 og IPv6 separat. Så bør man have ca. samme regler for IPv4 og IPv6. Hvis firewallen ikke understøtter IPv6, så kan det være at den enten lukker alle IPv6 pakker igennem eller at ingen IPv6 pakker kommer igennem. Hvis man er nødt til at bruge sådan en firewall, så har man muligheden for at konvertere pakkerne til IPv4 og sende dem gennem firewallen som IPv4. Den slags bør man dog kun gøre i en overgangsperiode.

kasperd (4) skrev:

Et eksempel på hvor ekstremt nogen undgår 6to4, så undlader Google at indeksere sites, som kun er tilgængelige over 6to4.

Jeg opdagede lige at Googles preview funktion vil gerne hente billeder over 6to4 fra min nye server men ikke fra min gamle. Når Google henter billederne fra min nye server sker det med en native IPv6 adresse på Googles side. Det betyder at der involveres tredjeparts relays. Det kunne i teorien betyde at det skyldes upålidelige relays. Men den gamle servers 6to4 prefix kan godt pinge Googles native IPv6 adresse, så relays virker i begge retninger.

Den observation er så ikke af stor betydning for din situation, men illustrerer hvilke overvejelser der kommer ind i billedet, når man kommunikerer mellem 6to4 og native IPv6. Min anbefaling er dog stadig at have begge slags adresser på sit netværk. Om man så vil have både native og 6to4 adresser i DNS eller om man vil nøjes med native adresser i DNS er et lidt sværere valg.

Så blev det til 1.795 ord indtil videre.

Kasperd er allerede over halvvejs med sin "stil". :)

Jeg siger rigtig mange tak, Kasperd. Det har givet mig en hel del viden som gør det nemmere at læse videre.. :)

#10
Hvis du har tid, lyst og mulighed for det må du meget gerne skrive her hvis du støder ind i nogen udfordringer der hænger sammen med DirectAccess (også andet end IPv6). Vil frygtelig gerne høre lidt om andres erfaringer :D

Var det Server 2012 eller 2008 R2 du brugte?

Det skal jeg nok. Jeg er stadigvæk igang med at luge ud i "fejl" vha. BPA. Det er på 2012..

kasperd (8) skrev:

Det betyder at der involveres tredjeparts relays. Det kunne i teorien betyde at det skyldes upålidelige relays.

Indlæg skrevet midt om natten er ikke altid de bedst formulerede. Det jeg mente var at fordi der er involveret tredjeparts relays, så kunne der i teorien være fejl på de tredjeparts relays, som gjorde at Googlebot ikke kunne komme i kontakt med min server på 6to4.

Men da jeg afprøvede en ping af Googles IP adresse, som ville bruge samme par af tredjepartsrelays, kom svaret igennem.

Magten (11) skrev:

Hvis du har tid, lyst og mulighed for det må du meget gerne skrive her hvis du støder ind i nogen udfordringer der hænger sammen med DirectAccess (også andet end IPv6).

Og jeg er selvsagt interesseret i at høre om næsten alt, der har noget med IPv6 at gøre. Så uanset hvilken vej projektet bevæger sig i er der nok nogen herinde, som gerne vil høre mere.

didriksen86 (12) skrev:

Det skal jeg nok. Jeg er stadigvæk igang med at luge ud i "fejl" vha. BPA. Det er på 2012..

Jeg tillader mig lige at spørge dumt: Jeg troede MS havde fjernet kravene til IPv6 i DA med Server 2012?

Det er ikke krav til native IPv6 og kraverne kan læses her(Hvis man har tid):
http://technet.microsoft.com/en-us/library/0064848...
Jeg har desværre ikke haft tid til at kigge på sagen igen men jeg håber at jeg får tid i løbet af den her uge..

Det var lige sådan en artikel jeg ledte efter :) Nu forstår jeg bedre snakken her i tråden :D

didriksen86 (15) skrev:

Det er ikke krav til native IPv6 og kraverne kan læses her(Hvis man har tid):
http://technet.microsoft.com/en-us/library/0064848...

Jeg kiggede lidt på siden og bemærkede at kombinationen af IPv6 Internet og IPv4 intranet ikke er en af mulighederne som står beskrevet. Hvis nogen af jer har brug for den kombination, så tag lige fat i mig, så kan vi godt arrangere at teste om den løsning jeg har på det kan spille sammen med Direct Access.