Het grote IPv6 topic

[Osiris]

Toevallig al mensjes met native IPv6 bij XS4ALL?

Ikzelf ben ex-Demon-klant met MPoA en de pilot doet 't alleen op lijnen met PPPoA

En er is weinig kans dat de MPoA-klanten binnen korte termijn wel "gefixt" worden.

[Verwijderd]

Wij (proserve) gaan binnenkort IPv6 ranges uitdelen aan onze klanten. Klanten met eigen racks kunnen uiteraard een wat grotere range krijgen, maar ook elke dedicated server gaat zijn eigen IPv6 range krijgen. Dus niet alleen als de klant erom vraagt, nee, we gaan het gewoon standaard doen bij nieuwe opleveringen, maar ook op al draaiende servers.

[Verwijderd]

Vanaf vandaag is mijn server volledig over op IPv6 \o/.

Gelijk AAAA records toegevoegd aan mijn domeinen.

[Loekie]

Pfff, ik zit weer op de std 6to4 optie van m'n Fritz!Box, in december heeft Sixxs m'n user disabled zonder enige duidelijkheid te geven over het waarom. Sindsdien heb ik vanaf 3 verschillende domeinen contact met ze op proberen te nemen(waarvan er 2 op de in februari geïntroduceerde whitelist staan), zonder enig antwoord. Ik ben het even kwijt nu, enig andere manier dan info@ schijnt er niet te zijn. Als daar niet geantwoord wordt houd het op.
Iemand hier ervaring met freetz voor de fritz!box en iets als hurricane of gogonet?

[boonie]

[b]Iemand hier ervaring met freetz voor de fritz!box en iets als hurricane of gogonet?

Ja, ik heb een 7140 met Freetz en een HE tunnel. Ik ben er zeer tevreden mee.

Boonie

[Loekie]

boonie schreef op maandag 12 april 2010 @ 18:24:
[...]

Ja, ik heb een 7140 met Freetz en een HE tunnel. Ik ben er zeer tevreden mee.

Boonie

Gewoon freetzen en dan enable IPv6 support aanvinken? Dan krijg je er ws een item IPv6 bij waar je account-gegevens kan invoeren?
Sorry voor de vragen, maar op freetz-wiki en ip-phoneforum staat niets...

[boonie]

[b]Gewoon freetzen en dan enable IPv6 support aanvinken? Dan krijg je er ws een item IPv6 bij waar je account-gegevens kan invoeren?

Ik heb mijn image gehaald bij Frits. http://members.home.nl/fletteboer/

Het was nog een redelijk klusje om het te configureren. Er was iets met inloggen via telnet om daar te zorgen dat je meer rechten krijgt binnen het Freetz deel. De rest zou je min of meer kunnen copieren en plakken van mij. Kijk maar of je me een PM kunt sturen.

[Loekie]

boonie schreef op maandag 12 april 2010 @ 20:37:
[...]


Ik heb mijn image gehaald bij Frits. http://members.home.nl/fletteboer/

Het was nog een redelijk klusje om het te configureren. Er was iets met inloggen via telnet om daar te zorgen dat je meer rechten krijgt binnen het Freetz deel. De rest zou je min of meer kunnen copieren en plakken van mij. Kijk maar of je me een PM kunt sturen.

Als je zelf ook PM aanzet, gaat dat lukken. Heb nu wel een freenet6-account, maar dat schiet niet op. Een HE-tunnel routeert wel op iets van 30 Mbit?

[Trommelrem]

TrailBlazer schreef op dinsdag 19 augustus 2008 @ 21:22:
Site-local was oorsponkelijk bedacht om dezelfde functie van te vervullen als de huidige RFC 1918 adressen (10.0.0.0/8 172.16.0.0/12 en 192.168.0.0/16). Gelukkig werd op tijd ingezien dat dit toch niet zo handig was en is dit ondertussen al weer afgeschaft. Ze waren te herkennen omdat ze begonnen met fec0.

Dit begrijp ik even niet.
Mijn DHCP server deelt nu IPv4 adressen uit in de 10.x.x.x range, maar ik wil ook IPv6 in mijn interne netwerk om alvast voorbereid te zijn op de toekomst, wanneer IPv4 eruit gaat. Nu komen er dus geen Site-local adressen? Wat dan met al die mensen die een router hebben waar 2 of meer devices achter hangen?

Wat moet ik dan gebruiken om een computer via NAT bereikbaar te maken zodra ik een IPv6 capabele router heb? Mijn DHCP server (NT 6.1) accepteert ook geen fec0 / 64 als DHCP range.

[CyBeR]

Trommelrem schreef op dinsdag 27 april 2010 @ 16:47:
[...]


Dit begrijp ik even niet.
Mijn DHCP server deelt nu IPv4 adressen uit in de 10.x.x.x range, maar ik wil ook IPv6 in mijn interne netwerk om alvast voorbereid te zijn op de toekomst, wanneer IPv4 eruit gaat. Nu komen er dus geen Site-local adressen? Wat dan met al die mensen die een router hebben waar 2 of meer devices achter hangen?

Een subnet toegewezen kregen van je ISP.

Wat moet ik dan gebruiken om een computer via NAT bereikbaar te maken zodra ik een IPv6 capabele router heb? Mijn DHCP server (NT 6.1) accepteert ook geen fec0 / 64 als DHCP range.

NAT is een hack om het ipv4-tekort uit te stellen. Dat gaat er compleet uit met IPv6.

[Trommelrem]

CyBeR schreef op dinsdag 27 april 2010 @ 16:50:

Een subnet toegewezen kregen van je ISP.

Ok, maar dan raken de IP adressen wel erg snel op als elk huis een eigen subnet krijgt. Hebben de universiteiten in NL eigenlijk nog steeds een publiek IP adres per werkstation? Ik vraag me af hoe snel de IPv6 adressen opraken als men op deze manier gaat werken

NAT is een hack om het ipv4-tekort uit te stellen. Dat gaat er compleet uit met IPv6.

Maar fec0 is alvast bedacht als oplossing voor het tekort over 5 jaar?

[CyBeR]

Trommelrem schreef op dinsdag 27 april 2010 @ 17:03:
[...]


Ok, maar dan raken de IP adressen wel erg snel op als elk huis een eigen subnet krijgt.

Nee hoor. Er zijn evenveel ISP-niveau subnets in IPv6 beschikbaar (/32) als er überhaupt IPv4-adressen zijn. En elk ISP-subnet bevat dus weer 2^96 ip-adressen.

Hebben de universiteiten in NL eigenlijk nog steeds een publiek IP adres per werkstation?

Met een paar uitzonderingen, ja.

Ik vraag me af hoe snel de IPv6 adressen opraken als men op deze manier gaat werken

Dat duurt dus wel even. Het standaardformaat subnet in IPv6 is /64. Daarin kun je al 2^64, ofwel 18446744073709551616 hosts kwijt. Dat is meer dan genoeg voor een gemiddeld huishouden Er wordt nog gediscussieerd over wat een residentiele aansluiting moet krijgen. Op dit moment is de standaard daarvoor een /48 (65000 /64 subnets), maar dat wordt als wat excessief gezien en daarom wordt nu gepleit voor /56 subnets (256 /64 subnets), om /48's door te routeren naar bedrijven. Maar zelfs als we /48's doorrouteren naar residentiele aansluitingen, daar zijn er 2^48 van, oftewel 281474976710656. Zelfs rekening houdend met een toewijzingsinefficientie (i.e., verspilling) van 75% is dat ruim genoeg om de complete wereldbevolking een paar duizend keer van een /48 te voorzien.

2^128 is een heel groot getal

Maar fec0 is alvast bedacht als oplossing voor het tekort over 5 jaar?

Nee, dat is bedacht als vergelijkende IP-space voor de rfc1819 adressen (die niet zijn gemaakt met NAT in het achterhoofd, dat is andersom gebeurd). Maar ondertussen is de realisatie ontstaan dat dat helemaal niet handig is, en dat het toewijzen van globaal unieke addressering veel wenselijker is voor netwerken die aan het internet hangen.

Overigens is er wel degelijk een stuk adresruimte opzij gezet voor 'privé'-doeleinden, voor netwerken die specifiek bestaan om niet aan het internet te hangen. Daar is ook een soort van assignment in zodat dergelijke netwerken wel nog aan elkaar gehangen kunnen worden zonder enorme complicaties met overlappende adresruimte. Wikipedia: Unique local address

[ Voor 9% gewijzigd door CyBeR op 27-04-2010 17:21 ]

[Trommelrem]

Dan begrijp ik in ieder geval hoe ik een DHCP server moet opzetten. Gewoon het subnet invoeren dat de provider geeft dus.

Maar als de universiteiten in NL voor elke werkplek een publiek IPv4 adres hebben, dan hebben de universiteiten in andere landen dat wellicht ook. Is het tekort aan IPv4 adressen niet gewoon 10 jaar vooruit te schuiven door gewoon van de universiteiten wereldwijd te eisen dat ze hele IPv4 blokken inleveren?

[CyBeR]

Trommelrem schreef op woensdag 28 april 2010 @ 11:23:
Dan begrijp ik in ieder geval hoe ik een DHCP server moet opzetten. Gewoon het subnet invoeren dat de provider geeft dus.

Het idee uiteindelijk is dat je router dit automatisch doet, maar dat is nog in de toekomst.

Maar als de universiteiten in NL voor elke werkplek een publiek IPv4 adres hebben, dan hebben de universiteiten in andere landen dat wellicht ook.

Sterker nog, MIT alleen heeft een /8 (18.0.0.0/8).

Is het tekort aan IPv4 adressen niet gewoon 10 jaar vooruit te schuiven door gewoon van de universiteiten wereldwijd te eisen dat ze hele IPv4 blokken inleveren?

Niet echt. Bovendien zal ik nog eens herhalen: NAT is een hack die er niet hoort te zijn. Zeker in netwerken met de schaal van een universiteitsnetwerk is dat gewoon niet iets dat je wilt hebben. Toegegeven MIT z'n /8 in laten leveren (evenals wat van die andere legacy-assignments zoals de DoD die er geloof ik 5 heeft) zou wat helpen, maar de rest van de uni's hebben voornamelijk /16's en soortgelijk.

[ Voor 3% gewijzigd door CyBeR op 28-04-2010 11:50 ]

[boonie]

Maar als de universiteiten in NL voor elke werkplek een publiek IPv4 adres hebben, dan hebben de universiteiten in andere landen dat wellicht ook. Is het tekort aan IPv4 adressen niet gewoon 10 jaar vooruit te schuiven door gewoon van de universiteiten wereldwijd te eisen dat ze hele IPv4 blokken inleveren?

En over 10 jaar heeft dan iedereen 10 jaar doorgesnurkt en staan we waar we nu staan. Ik vind dat we er maar gewoon NU voor moeten gaan.

[CAPSLOCK2000]

Trommelrem schreef op woensdag 28 april 2010 @ 11:23:
Maar als de universiteiten in NL voor elke werkplek een publiek IPv4 adres hebben, dan hebben de universiteiten in andere landen dat wellicht ook. Is het tekort aan IPv4 adressen niet gewoon 10 jaar vooruit te schuiven door gewoon van de universiteiten wereldwijd te eisen dat ze hele IPv4 blokken inleveren?

Het zou niet de moeite waard zijn.
We gebruiken momenteel ongeveer 1 /8 netblok per maand.
De meeste Nederlandse universiteiten hebben een /16. Zoals je weet passen er 256 /16's in een /8.
Als alle Nederlandse universiteiten al hun adressen zouden inleveren (en niet alleen de ongebruikte) dan winnen we daar een paar dagen uitstel mee.

Je zou wel vele miljoenen moeten investeren om die adressen vrij te krijgen en dan wil ik nog niet eens denken aan de beveiligingsrisico's van het verhuizen van een IP.

[battler]

Vandaag een beetje begonnen met het verdiepen in IPV6. Mijn eerste conclusie: Hier moet nog een hoop gebeuren!.

Drie dingen waar jullie misschien een antwoord op hebben.
1: Tussen routers onderling, waarom kan communicatie niet plaatsvinden via alleen het Link local address.
In ieder geval zou bij Cisco al de uitgaande interface bepaald kunnen worden via CDP.
2: Erg omslachtig om een EUI-64 adres toe te wijzen op een Windows machine, kan dit niet sneller?
En dan bedoel ik niet de methode waarbij je eerst moet rebooten voordat windows het EUI-64 commando begrijpt.
3: Dat pingen naar een IPV6 adres, wat een pokken werk. Behalve copy paste al snellere methodes gevonden hiervoor?

[CyBeR]

battler schreef op woensdag 12 mei 2010 @ 22:40:
Vandaag een beetje begonnen met het verdiepen in IPV6. Mijn eerste conclusie: Hier moet nog een hoop gebeuren!.

Drie dingen waar jullie misschien een antwoord op hebben.
1: Tussen routers onderling, waarom kan communicatie niet plaatsvinden via alleen het Link local address.

Dat kan prima, maar als je dat wilt debuggen is dat wat lastig en voor dingen als multi-hop BGP is 't gewoon onmogelijk. Bovendien krijgen ICMP berichten gegenereerd door die router op die interface dan ook link-local afzenderadressen en da's niet de bedoeling. Maar technisch kan 't prima.

In ieder geval zou bij Cisco al de uitgaande interface bepaald kunnen worden via CDP.

Zullen we IPv6 niet af laten hangen van cisco-proprietary protocollen?

2: Erg omslachtig om een EUI-64 adres toe te wijzen op een Windows machine, kan dit niet sneller?
En dan bedoel ik niet de methode waarbij je eerst moet rebooten voordat windows het EUI-64 commando begrijpt.

OS-specifiek, heeft niets met IPv6 te maken.

3: Dat pingen naar een IPV6 adres, wat een pokken werk. Behalve copy paste al snellere methodes gevonden hiervoor?

DNS?

[ Voor 7% gewijzigd door CyBeR op 12-05-2010 22:45 ]

[battler]

CyBeR schreef op woensdag 12 mei 2010 @ 22:44:
[...]
Dat kan prima, maar als je dat wilt debuggen is dat wat lastig en voor dingen als multi-hop BGP is 't gewoon onmogelijk.
[...]

Het is jammer dat Packet Tracer dit niet lekker ondersteunt dus ik kan hier niet mee spelen maar in de praktijk werkt dit dus wel gewoon?

Zullen we IPv6 niet af laten hangen van cisco-proprietary protocollen?
[...]

Het leek mij gewoon een goeie manier om een hoop address space te besparen. Uiteraard is het vast geen goed idee ik kon alleen niet bedenken waarom. Nu eigenlijk nog steeds niet.

OS-specifiek, heeft niets met IPv6 te maken.
[...]

Zou wel fijn zijn als dit sneller kon

DNS?

Het is eigenlijk meer voor tijdens de labs. Ik zal wel even kijken of je iets leuks kan doen met hostnames scheelt hoop tik werk.

Bedankt voor je antwoorden

[CyBeR]

battler schreef op woensdag 12 mei 2010 @ 22:54:
[...]

Het is jammer dat Packet Tracer dit niet lekker ondersteunt dus ik kan hier niet mee spelen maar in de praktijk werkt dit dus wel gewoon?

Sure.

Het leek mij gewoon een goeie manier om een hoop address space te besparen.

Address space besparen? Die paar adresjes? Moet ik nog een keer uitleggen hoeveel adressen 2^128 eigenlijk wel niet is?

Uiteraard is het vast geen goed idee ik kon alleen niet bedenken waarom. Nu eigenlijk nog steeds niet.

Ik heb je net minimaal twee hele goede redenen verteld

Zou wel fijn zijn als dit sneller kon

Tsja, moet je bij Microsoft voor zijn. In andere OS'en is dit niet iets waar je lang bij na hoeft te denken.

Het is eigenlijk meer voor tijdens de labs. Ik zal wel even kijken of je iets leuks kan doen met hostnames scheelt hoop tik werk.

Als 't alleen om labs gaat, het gebruik van EUI-64 is niet verplicht he. Je mag prima je hosts 3ffe::1, 3ffe::2, etc. noemen.

[axis]

Ik heb trouwens nog dit topic geopend in PNS: site-to-site ipv6 koppelingen met encryptie? met de vraag hoe we met ipv6 site-to-site encryptie gaan implementeren. Mochten jullie nog ideeen hebben, hoor ik het graag

[Verwijderd]

Ik en mijn collega doen een eindwerk over IPv6 en we hadden graag in onze intro het resultaat van een poll gezet, om aan te tonen hoe het momenteel zit met de overgang van IPv4 naar IPv6.

Poll

Ik heb de poll op een ander forum moeten zetten omdat een poll hier aanmaken jammer genoeg niet ging.

Dus als jullie zo vriendelijk zouden willen zijn om ons even te helpen hiermee. Wij zouden jullie zeer dankbaar zijn!

dank bij voorbaat.

[Osiris]

Beetje stomme poll als je 't mij vraagt. Ik ben namelijk al over op IPv6 en volgens de huidige bewoording van je poll kan ik dus geen antwoord geven.

edit:

En 't is in feite keiharde spam natuurlijk

[ Voor 15% gewijzigd door Osiris op 17-05-2010 16:06 ]

[CyBeR]

Verwijderd schreef op maandag 17 mei 2010 @ 15:36:
Ik en mijn collega

Mijn collega en ik…

doen een eindwerk over IPv6 en we hadden graag in onze intro het resultaat van een poll gezet, om aan te tonen hoe het momenteel zit met de overgang van IPv4 naar IPv6.

Poll

Ik heb de poll op een ander forum moeten zetten omdat een poll hier aanmaken jammer genoeg niet ging.

Dus als jullie zo vriendelijk zouden willen zijn om ons even te helpen hiermee. Wij zouden jullie zeer dankbaar zijn!

dank bij voorbaat.

Die poll schiet niet op. Iedereen is van plan over te stappen op IPv6, alleen al omdat 't op een gegeven moment moet. Je kunt beter vragen hoeveel mensen al IPv6 gebruiken. hoe lang ze dat doen, wat de rationale was, etc.

[3p0x]

Osiris schreef op donderdag 08 april 2010 @ 23:58:
Toevallig al mensjes met native IPv6 bij XS4ALL?

Ikzelf ben ex-Demon-klant met MPoA en de pilot doet 't alleen op lijnen met PPPoA

En er is weinig kans dat de MPoA-klanten binnen korte termijn wel "gefixt" worden.

*meld*

Speciaal voor m'n stageopdracht een abbo hierop genomen, werkt goed op m'n 2e aderpaar, de verbinding in stabieler dan m'n andere lijn

Ben aan het testen met een webserver ect maar daar kom ik nog wat probleempjes tegen, op onverklaarbare reden is ie soms niet te bereiken, zelfs op v4 niet. Ik weet nog niet precies waar dat aan ligt....

Gebruikte hardware:
Draytek Vigor 120
Draytek Vigor 2130N

Installatie stelt niet voor, een paar dingen aanvinken en klaar

[analog_]

Heb net samen met een vriend van me een tweeltal ipv6 tunnels opgezet bij Sixxs, vanaf nu is 2001:6f8:14a3 en 14a2/48 online. Ik begin me al een beetje te ergeren aan wat problemen die ik tegen kom zoals de onkunst van de Windows stack om als een AAAA record offline is de A record te gebruiken. Erg vervelend aangezien niet elke service op die machine al ipv6 ondersteunt maar indien dat wel is wil ik dat hij het gebruikt (preference for AAAA dus in de windows resolver).

Hoe doen jullie het of beter, hoe werkt het eigenlijk, want ik merk dat windows ervoor kiest om voorkeur te geven voor IPv6 name servers, maar welke gebruiken jullie (en zet je die als IPv4 DNS entry erin of als IPv4/6 adres?). Kan je bijvoorbeeld windows vanzelf laten querien naar AAAA records op een ipv4 server (met voorkeur voor ipv6 adressen als gevolg).

Tevens kan ik ook geen nette goed werkende manier vinden voor een dual stacked debian lenny machine. Ik zit nu met losse commandos in rc.local (ip addr ... , route --inet6 default gw ..). Dit is nogal vervelend omdat de IPv6 enabled servers daarna nog moeten gerestart worden.

[ Voor 14% gewijzigd door analog_ op 18-06-2010 05:12 ]

[analog_]

Over dat NAT gedoe, een pro argument om het toch in te voeren is dat NAT niet alleen gebruikt wordt voor zoals we het kennen in de thuis routers. (combinatie van source en destination nat). Er zijn wel degelijk scenarios te bedenken waarop 1-op-1, 1-op-veel, veel-op-1 of veel-op-veel functionaliteit gewenst kan zijn. Nu waren dit meestal verhalen met overlappende subnetten tussen twee partijen waarbij dan veel-op-veel werd gebruikt met twee 'virtuele' subnetten maar je sluit wel mogelijkheden uit.


mybad, edit knopje enzo :x

[ Voor 3% gewijzigd door analog_ op 18-06-2010 05:20 ]

[deadlock2k]

-

[ Voor 100% gewijzigd door deadlock2k op 06-08-2021 16:15 ]

[Marzman]

deadlock2k schreef op vrijdag 18 juni 2010 @ 09:04:
[...]

Hoe kom je daarbij? Dat laatste is namelijk big bullcrap. En sowieso is het geen 'hack die er niet hoort te zijn', het is een aanpassing. Een van de betere van IPv4 en het is een schande dat het niet in IPv6 zit.

In IPV6 kun je toch ook wel een eigen IPV6 ip als gateway instellen en zo het internet op gaan? Dat lijkt me hetzelfde werken als met de interne ip's.

[Orion84]

Mr.SiS schreef op vrijdag 18 juni 2010 @ 05:10:
Heb net samen met een vriend van me een tweeltal ipv6 tunnels opgezet bij Sixxs, vanaf nu is 2001:6f8:14a3 en 14a2/48 online. Ik begin me al een beetje te ergeren aan wat problemen die ik tegen kom zoals de onkunst van de Windows stack om als een AAAA record offline is de A record te gebruiken. Erg vervelend aangezien niet elke service op die machine al ipv6 ondersteunt maar indien dat wel is wil ik dat hij het gebruikt (preference for AAAA dus in de windows resolver).

Hoe doen jullie het of beter, hoe werkt het eigenlijk, want ik merk dat windows ervoor kiest om voorkeur te geven voor IPv6 name servers, maar welke gebruiken jullie (en zet je die als IPv4 DNS entry erin of als IPv4/6 adres?). Kan je bijvoorbeeld windows vanzelf laten querien naar AAAA records op een ipv4 server (met voorkeur voor ipv6 adressen als gevolg).

Tevens kan ik ook geen nette goed werkende manier vinden voor een dual stacked debian lenny machine. Ik zit nu met losse commandos in rc.local (ip addr ... , route --inet6 default gw ..). Dit is nogal vervelend omdat de IPv6 enabled servers daarna nog moeten gerestart worden.

Dat is op te lossen door service specifieke DNS namen te gebruiken. Dus om een willekeurig voorbeeld te geven: www.bla.com heeft AAAA en A, want webserver doet zowel v4 als v6; smtp.bla.com heeft alleen een A record, omdat de smtp server alleen op v4 draait. Een andere optie is om bijvoorbeeld een A record v4.bla.com aan te maken en dat te gebruiken voor het benaderen van alle services die geen v6 ondersteunen.

Voor websites is dat lelijk, omdat je mensen gewoon simpele domeinnamen wilt laten intypen in de adresbalk, maar een webserver op v6 aanbieden zal het probleem niet zijn. Voor de meeste andere services boeit het niet zo dat je er een specifieke hostname voor in moet stellen in de client lijkt me?

[CyBeR]

deadlock2k schreef op vrijdag 18 juni 2010 @ 09:04:
[...]

Hoe kom je daarbij? Dat laatste is namelijk big bullcrap. En sowieso is het geen 'hack die er niet hoort te zijn', het is een aanpassing. Een van de betere van IPv4 en het is een schande dat het niet in IPv6 zit.

Vertel me, in godsnaam waarom is NAT 'een van de betere' hacks van IPv4? Het breekt alles behalve de simpelste situatie. Als je NAT nodig hebt is imo je netwerk slecht ontworpen (afgezien van het 'ik krijg maar 1 ip-adres van m'n isp' argument.)

[serkoon]

Bovendien is NAT natuurlijk prima mogelijk in IPv6; je zou het alleen niet moeten willen.

[deadlock2k]

-

[ Voor 138% gewijzigd door deadlock2k op 06-08-2021 16:15 ]

[CyBeR]

deadlock2k schreef op vrijdag 18 juni 2010 @ 13:33:
[...]

Omdat de buitenwereld niets met mijn netwerk te maken heeft. Het is veilig en eenvoudig en van mij mag de buitenwereld niet zelf een connectie initieren met de clients in mijn interne netwerk.

Oh, jij ziet NAT als een firewall. Dan moet ik je teleurstellen want dat is niet zo. En bovendien: de buitenwereld moet dat wel degelijk voor veel protocollen. FTP wil dat graag, bijvoorbeeld, evenals vrijwel elk VoIP-protocol. NAT veroorzaakt zoveel gezeik dat er nog weer aparte protocollen zijn om er alsnog doorheen te komen, en dat routers die NAT doen ondersteuning moeten hebben voor specifieke protocollen om sommige soorten verkeer (VoIP en P2P zijn notoir) überhaubt te laten werken.

NAT hoort gewoon niet thuis in een netwerk. Het is een hack om het IPv4-adrestekort te vertragen.

En IPv6 kan nog niet NAT'en. Hier een mooi artikel over de toevoeging van NAT aan IPv6 en op welke manieren dat vormgegeven zal worden: http://www.networkworld.com/news/2008/072108-ipv6nat.html

Dat artikel gaat, als ik de eerste paragrafen lees, niet over NAT zoals jij 't kent in IPv4 maar over NAT tussen IPv4 en IPv6. Meer een Protocol translation, dus.

Sowieso is het gebruik van IPv6 in interne netwerken vrij overbodig, op een enkele toepassing na. Het maakt je netwerk onoverzichtelijker. Mits je een strak en logisch IPv4 plan geïmplementeerd hebt tenminste.

En hoe wil jij IPv6 op het internet gebruiken zonder 't op je interne netwerk te hebben? Ik ben 't met je eens dat voor de meeste netwerken IPv6 op zich niet nodig is, maar aangezien het Internet wat groter is dan de meeste netwerken is het dat uiteindelijk toch.

[ Voor 33% gewijzigd door CyBeR op 18-06-2010 13:58 ]

[Osiris]

CyBeR schreef op vrijdag 18 juni 2010 @ 13:53:
[...]

Dat artikel gaat, als ik de eerste paragrafen lees, niet over NAT zoals jij 't kent in IPv4 maar over NAT tussen IPv4 en IPv6. Meer een Protocol translation, dus.

Plus: het artikel is alweer 2 jaar oud, wat best een tijd is in de wondere wereld der internet

[deadlock2k]

-

[ Voor 103% gewijzigd door deadlock2k op 06-08-2021 16:15 ]

[Osiris]

deadlock2k schreef op vrijdag 18 juni 2010 @ 14:23:
[...]

Haha, waar heb je het over Ik zie NAT niet als firewall. Alhoewel het wel tot op bepaalde hoogte wel zo ingezet kan worden natuurlijk.

Waarom zou ik mijn 2000 clients willen laten P2P'en of VoIP'en naar buiten toe? Of zelfs maar FTP'en? En denk je serieus niet dat als we zouden VoIP'en dat dat met onze PBX (mocht die op internet aangesloten zijn in plaats van op een ISDN-30 verbinding) en de Juniper NetScreen 500 firewalls niet kan?

Ze *hoefen* ook niet per see t P2P-en of te VoIP-en. Overigens allemaal zaken die je dient te blokkeren in je firewall. Of je nou NAT draait of niet, zonder firewall kunnen hosts in je netwerk probleemloos 't enge internet op verbinden, dus tja.. Daar doet NAT geen flikker aan.

Verder is het internet *ontworpen* zonder NAT. End-to-end-connectivity. NAT is nooit een functie geweest, totdat het broodnodig was.

En het enige argument wat ik van jou hoor is dat je je interne netwerk wilt "verbergen" van het grote boze internet. Why?

[CyBeR]

deadlock2k schreef op vrijdag 18 juni 2010 @ 14:23:
[...]

Haha, waar heb je het over Ik zie NAT niet als firewall. Alhoewel het wel tot op bepaalde hoogte wel zo ingezet kan worden natuurlijk.

Waarom zou ik mijn 2000 clients willen laten P2P'en of VoIP'en naar buiten toe? Of zelfs maar FTP'en? En denk je serieus niet dat als we zouden VoIP'en dat dat met onze PBX (mocht die op internet aangesloten zijn in plaats van op een ISDN-30 verbinding) en de Juniper NetScreen 500 firewalls niet kan?

Inderdaad, waarom zou je meer toestaan dan web, want iets anders wordt toch nooit bedacht laat staan gebruikt

Het gaat ook over v6<=>v6 NAT.

En nog niemand implementeert dat. Mooi zo, want 't hoort niet thuis in een netwerk.

Jij werkt niet in de IT merk ik al wel. Dat kan je gewoon transleren namelijk.

Nee, ik werk niet in de IT. Ik ben maar een netwerkbeheerder bij een internetbedrijf, dus weet ik veel waar ik 't over heb.

[deadlock2k]

-

[ Voor 99% gewijzigd door deadlock2k op 06-08-2021 16:14 ]

[Orion84]

deadlock2k schreef op vrijdag 18 juni 2010 @ 14:23:
[...]

Haha, waar heb je het over Ik zie NAT niet als firewall. Alhoewel het wel tot op bepaalde hoogte wel zo ingezet kan worden natuurlijk.

Als je NAT gebruikt om je netwerk af te schermen van de buitenwereld dan ben je het aan het inzetten als firewall. Daar is niks "tot op bepaalde hoogte" aan.

deadlock2k schreef op vrijdag 18 juni 2010 @ 14:49:
[...]

Uiteraard wordt dat in de firewall ook geblokkeerd. Of nou jah, alles wordt geblokkeerd behalve http en https verkeer eigenlijk. Grote verschil is dat met NAT er niet zomaar van buiten naar binnen gekoekeloerd kan worden. In mijn ogen onmisbare functionaliteit.
[...]
Dingen worden wel vaker gebruikt voor een doel waarvoor het oorspronkelijk niet ontworpen is. So what.
[...]
De buitenwereld hoeft niet te weten wat er allemaal in mijn netwerk zit. Extra veiligheid. Of is dat tegenwoordig geen sleutelwoord meer in IT-land?

Zonder er een zinloos welles nietes spelletje van te maken ben ik eigenlijk wel benieuwd naar jouw argumenten om NAT te gebruiken in plaats van een statefull-firewall. Je hebt het over onmisbare functionaliteit, maar bent je schijnbaar niet bewust van het feit dat dezelfde bescherming ook met een paar firewall regels te realiseren is.

Ik heb er niet bijzonder veel verstand van, maar thuis zijn mijn IPv4 hosts via NAT verbonden met het internet (ik krijg immers maar één publiek IP), wat inderdaad voor enige afscherming zorgt. Voor het IPv6 gebeuren, waar ik een publiek toegankelijk subnet routeer, heb ik gewoon een paar firewall regels opgesteld die naar mijn idee dezelfde bescherming bieden (drop all, allow related/established).

[ Voor 29% gewijzigd door Orion84 op 18-06-2010 14:58 ]

[deadlock2k]

-

[ Voor 100% gewijzigd door deadlock2k op 06-08-2021 16:14 ]

[CyBeR]

deadlock2k schreef op vrijdag 18 juni 2010 @ 14:49:
[...]

Uiteraard wordt dat in de firewall ook geblokkeerd. Of nou jah, alles wordt geblokkeerd behalve http en https verkeer eigenlijk. Grote verschil is dat met NAT er niet zomaar van buiten naar binnen gekoekeloerd kan worden. In mijn ogen onmisbare functionaliteit.

Als jij jouw firewall niet in kunt stellen om dat te doen zonder NAT, mag je wmb meteen ontslag nemen en aardappels gaan schillen.

Dingen worden wel vaker gebruikt voor een doel waarvoor het oorspronkelijk niet ontworpen is. So what.

Je maakt hier een fundamentele fout. Je hebt gelijk, maar dat is niet toepasbaar op deze situatie. Het end-to-end-principe is de fundamentele manier waarop het internet ontworpen is om te werken. Dat dat zo gedaan is heeft een heel specifieke reden: het netwerk zit dan op geen enkele manier in de weg van een applicatie. De applicaties kunnen dus alles wat ze moeten doen om te werken gewoon doen, zonder dat het netwerk daar van af moet weten. Dat is nu anders: NAT-routers moeten allerlei protocol handlers hebben om zelfs veelgebruikte protocollen niet kapot te maken.

NAT is niet 'iets gebruiken waarvoor het niet ontworpen is', dat is de fundamentele werking aanpassen. 'Iets gebruiken waarvoor het niet ontworpen is', is meer het gebruik van HTTP CONNECT om je SSH-verbinding te tunnelen.

De buitenwereld hoeft niet te weten wat er allemaal in mijn netwerk zit. Extra veiligheid. Of is dat tegenwoordig geen sleutelwoord meer in IT-land?

Dat is waar een firewall voor is. Niet NAT. FIREWALL.

deadlock2k schreef op vrijdag 18 juni 2010 @ 14:56:
[...]

Je maakt echt een enorme denkfout. Niet alle omgevingen zijn hetzelfde. Sterker nog, veel kantooromgevingen zijn dusdanig ingericht dat er een whitelist wordt gebruikt zodat er slechts een beperkt setje URL's opgevraagd kan worden. Of omgekeerd een enorme blacklist. En dan wordt echt alleen maar http en https verkeer toegestaan. Je opmerking is dan ook een drogreden.

Dat is dus firewallfunctionaliteit. NAT heeft daar werkelijk geen flikker mee te maken.

Als je niet weet dat je dat gewoon kan omzetten dan lijkt het daar wel op.

Sorry maar ik zie protocol translation als iets dat NOG erger is dan NAT.

[ Voor 25% gewijzigd door CyBeR op 18-06-2010 15:02 ]

[deadlock2k]

-

[ Voor 99% gewijzigd door deadlock2k op 06-08-2021 16:20 ]

[deadlock2k]

-

[ Voor 99% gewijzigd door deadlock2k op 06-08-2021 16:20 ]

[Orion84]

deadlock2k schreef op vrijdag 18 juni 2010 @ 15:00:
[...]

Nou, de binnenkant is beschermd maar de buitenkant niet. Daardoor is het geen firewall.

Geen volledige firewall nee, maar dat zeg ik toch ook niet? Een firewall is een mechanisme om ongewenste communicatie tussen netwerken en/of hosts te blokkeren. Als jij NAT gebruikt om je interne netwerk af te schermen van het internet, dan gebruik je het dus als firewall. Dat je daarnaast ook nog een andere firewall hebt om bescherming te bieden die NAT niet kan bieden staat daar los van.

[...]
Er staan ook meedere firewalls, uiteraard van verschillende merken, die ons publieke subnet beschermen, maar dit voegt een extra laag veiligheid toe zonder dat je er iets voor hoeft te doen.

Zonder dat je er iets voor hoeft te doen? Noem het aanpassen van pakketjes, met alle eventuele negatieve effecten die daarbij komen kijken, maar niets...
Multi-layer security is natuurlijk prachtig, maar als de ene laag (een goede firewall) de andere (NAT) overbodig maakt, terwijl die tweede laag wel beperkingen in functionaliteit veroorzaakt, dan vraag ik me toch af waarom je die twee lagen allebei zou gebruiken?

Maar goed, een extra laagje slagroom is al heel wat anders dan "onmisbare functionaliteit" zoals je het eerst omschreef. Dus wat dat betreft komen we dichter bij elkaar

[ Voor 6% gewijzigd door Orion84 op 18-06-2010 15:12 ]

[CyBeR]

deadlock2k schreef op vrijdag 18 juni 2010 @ 15:07:
[...]

Als je de end-to-end functionaliteit simpelweg niet nodig hebt is er absoluut geen reden om over te stappen. "If it ain't broken..."

Dan stap je niet over. Maar dan ben je op een gegeven moment (kan nog wel even duren helaas) wel afgesloten van het internet. Moet je verder zelf weten.

Err, nee. De fundamentele werking wordt niet aangepast.

Excuseer, ik gebruikte de verkeerde term. Een fundamenteel principe wordt aangetast.

En ik zeg dat NAT nog een extra laag beveiliging toevoegt. Er staat al een sloot firewalls en dit is gewoon extra slagroom.

En ik zeg dat NAT geen beveiliging is. Jij verwart het daarmee omdat de meeste NAT-routers ook doen alsof ze firewall zijn door inkomende verbindingen niet toe te staan. En leuk, die extra slagroom, maar als de rest goed is dus niet nodig.

[Marzman]

deadlock2k schreef op vrijdag 18 juni 2010 @ 15:00:
[...]

Nou, de binnenkant is beschermd maar de buitenkant niet. Daardoor is het geen firewall.

[quote]Zonder er een zinloos welles nietes spelletje van te maken ben ik eigenlijk wel benieuwd naar jouw argumenten om NAT te gebruiken in plaats van een statefull-firewall. Je hebt het over onmisbare functionaliteit, maar bent je schijnbaar niet bewust van het feit dat dezelfde bescherming ook met een paar firewall regels te realiseren is.

In de meeste routertjes is het toch wel een firewall te noemen tegenwoordig. In mijn gratis TelfortZyxel kan ik precies instellen wat voor verkeer ik wel en niet door wil laten naar binnen en of naar buiten en ook hele websites zijn te blokkeren.

Ik weet niet in hoeverre dit anders gaat zijn straks met IPV6, volgens mij is het voornaamste verschil dat het allemaal "publieke ipadressen" zijn, maar het moet nog steeds langs je router dus zul je het vast ook wel anders in kunnen stellen.

[TrailBlazer]

NAT is inderdaad een hack die nodig was om het tekort aan IPv4 adressen op te vangen. Toevallig geeft NAT ook nog wat security voordelen. Om dat dan maar als motivatie te gebruiken om NAT als een security tool te betitelen is wat mij betreft onzin.
Het is voor hackers al een onmogelijk om poortscans te doen omdat ze je IPv6 adres een stuk moeilijker kunnen gokken. Op ieder segement heb je namelijk 2^46 mogelijke hosts zitten (bij eui-64) adressering. veel plezier om daar net 1 van die 10 hosts op je thuisnetwerk uit te vissen. Als je 100 adressen per seconde kan scannen ben je 22000 jaar bezig om ze allemaal te scannen.

[analog_]

Je zou het gebruik van NATv6 toch een dikke DEPRECATED label kunnen geven en beargumenteren waarom. Als men daar in de specs maar genoeg aandacht aan besteed gaat dit terug komen in de tutorials 'later on'.

[CyBeR]

Mr.SiS schreef op vrijdag 18 juni 2010 @ 16:40:
Je zou het gebruik van NATv6 toch een dikke DEPRICATED label kunnen geven en beargumenteren waarom. Als men daar in de specs maar genoeg aandacht aan besteed gaat dit terug komen in de tutorials 'later on'.

Nee, dat is een slecht idee. De ideeën die bij IPv4 noodzakelijk zijn vanwege de kleine adresruimte zitten ZO HARD ingebakken dat 't er onmogelijk weer uit te halen is. Zie de discussie hierboven over NAT. Die vieze hack bestaat alleen vanwege dat probleem, maar omdat 't al zo lang gebeurt is 't compleet geaccepteerd geworden. En dan wordt dat dus gewoon overgenomen in deployments van IPv6, terwijl dat eigenlijk compleet ongewenst is. Dus kun je 't beter maar gewoon niet implementeren, dan kan 't ook niet gebruikt worden.

[Trommelrem]

Maar misschien willen systeembeheerders nou juist wel NAT hebben. Juist vanwege de beperkingen (voor de users).

[CyBeR]

Trommelrem schreef op vrijdag 18 juni 2010 @ 18:51:
Maar misschien willen systeembeheerders nou juist wel NAT hebben. Juist vanwege de beperkingen (voor de users).

En daar gaan we weer. NAT legt geen beperkingen op, NAT maakt slechts dingen kapot. Beperkingen leg je op met een firewall. Daar zijn die dingen voor.

[Whizzer]

TrailBlazer schreef op vrijdag 18 juni 2010 @ 15:28:
NAT is inderdaad een hack die nodig was om het tekort aan IPv4 adressen op te vangen. Toevallig geeft NAT ook nog wat security voordelen. Om dat dan maar als motivatie te gebruiken om NAT als een security tool te betitelen is wat mij betreft onzin.
Het is voor hackers al een onmogelijk om poortscans te doen omdat ze je IPv6 adres een stuk moeilijker kunnen gokken. Op ieder segement heb je namelijk 2^46 mogelijke hosts zitten (bij eui-64) adressering. veel plezier om daar net 1 van die 10 hosts op je thuisnetwerk uit te vissen. Als je 100 adressen per seconde kan scannen ben je 22000 jaar bezig om ze allemaal te scannen.

Wel eens aan gedacht wat voor shit dit geeft op de router waar de "te scannen" netwerkrange "directly connected" is? Daarvoor moet je wel goede maatregelen nemen...

[CyBeR]

Whizzer schreef op vrijdag 18 juni 2010 @ 20:25:
[...]


Wel eens aan gedacht wat voor shit dit geeft op de router waar de "te scannen" netwerkrange "directly connected" is? Daarvoor moet je wel goede maatregelen nemen...

Toevallig heb ik dat wel 's getest. Je moet aardig wat verkeer naar niet-bestaande hosts genereren om daar een probleem mee te veroorzaken. En dan moet je dat moedwillig doen om dat probleem te veroorzaken. Als bij-effect van een poort scan is 't bijna onmogelijk.

[Whizzer]

CyBeR schreef op vrijdag 18 juni 2010 @ 20:33:
En dan moet je dat moedwillig doen om dat probleem te veroorzaken.

Tja, en niet iedereen is even lief (op het Internet) helaas..... Een goede filtering aan de edge van je netwerk hierop is in mijn beleving wel belangrijk!

[CyBeR]

Whizzer schreef op zondag 20 juni 2010 @ 10:40:
[...]


Tja, en niet iedereen is even lief (op het Internet) helaas..... Een goede filtering aan de edge van je netwerk hierop is in mijn beleving wel belangrijk!

't is best lastig te filteren op iets wat niet bestaat, alleen. En nogmaals: ik heb dit dus echt geprobeerd. Ik heb een paar routers genomen (Juniper M5, Cisco 7204, Linux) en daar met een traffic generator een bak verkeer heengegooid naar hosts die niet bestonden. Met de default waarden voor timeouts kreeg ik eigenlijk geen probleem veroorzaakt.

[Olaf van der Spek]

Whizzer schreef op vrijdag 18 juni 2010 @ 20:25:
Wel eens aan gedacht wat voor shit dit geeft op de router waar de "te scannen" netwerkrange "directly connected" is? Daarvoor moet je wel goede maatregelen nemen...

Wat kan er nou fout gaan?

[CyBeR]

Olaf van der Spek schreef op zondag 20 juni 2010 @ 15:23:
[...]

Wat kan er nou fout gaan?

Hij doelt op het opvullen van de neighbour detection tabel. Het equivalent van de IPv4 ARP-tabel. Met IPv4 heb je meestal hoogstens kans op 253 adressen daarin per aangesloten netwerk (meer kan natuurlijk, met kleinere prefixes) maar het standaardnetwerk met IPv6 is 2^64 hosts. Da's een flinke tabel.

Maar zoals ik al zei: om daar daadwerkelijk een probleem mee te veroorzaken moet je echt heel flink je best doen. Met een ADSL-lijntje kom je er iig niet.

[Olaf van der Spek]

CyBeR schreef op zondag 20 juni 2010 @ 16:12:
Hij doelt op het opvullen van de neighbour detection tabel. Het equivalent van de IPv4 ARP-tabel. Met IPv4 heb je meestal hoogstens kans op 253 adressen daarin per aangesloten netwerk (meer kan natuurlijk, met kleinere prefixes) maar het standaardnetwerk met IPv6 is 2^64 hosts. Da's een flinke tabel.

Wat is het probleem dan? In die tabel komen toch alleen geldige entries?

[TrailBlazer]

ja maar hij moet het wel doen. Dus het vraagt wat resources. Nou is het idee van een portscan dat je een werkende verbinding overhoudt en geen DOS.

[CyBeR]

Olaf van der Spek schreef op zondag 20 juni 2010 @ 19:58:
[...]

Wat is het probleem dan? In die tabel komen toch alleen geldige entries?

Nee. Daarin komen ook 'pending' entries. Na een tijdje timeouten die.

[ Voor 5% gewijzigd door CyBeR op 20-06-2010 20:32 ]

[Olaf van der Spek]

CyBeR schreef op zondag 20 juni 2010 @ 20:31:
Nee. Daarin komen ook 'pending' entries. Na een tijdje timeouten die.

Een router die daar niet mee om kan gaan is geen goede router...

[CyBeR]

Olaf van der Spek schreef op zondag 20 juni 2010 @ 20:33:
[...]

Een router die daar niet mee om kan gaan is geen goede router...

Dat is niet het punt.

[Olaf van der Spek]

CyBeR schreef op zondag 20 juni 2010 @ 20:47:
[...]


Dat is niet het punt.

Wat is het punt dan? Dat een hostscan lastig is?

[CyBeR]

Olaf van der Spek schreef op zondag 20 juni 2010 @ 21:00:
[...]

Wat is het punt dan? Dat een hostscan lastig is?

Je mag natuurlijk nooit uitgaan van dat apparatuur 'goed' is.

Maar zelfs in crappy apparatuur* zal een daadwerkelijke host scan dit probleem niet veroorzaken. Het idee daarvan is tenslotte dat je erachter komt welke hosts er bestaan, en daarvoor moet je wachten op antwoord. Dat limiteert het aantal pogingen dat je kunt uitvoeren al genoeg.

Ik denk overigens dat host scans in essentie tot het verleden gaan horen. Mischien dat er mensen zijn die naar servers gaan scannen die een 'mooi' adres hebben (2001:dead:beef::1, ::2, etc.) maar meer niet. Het is gewoon ondoenlijk om EUI-64 adressen te scannen.

*) Tenzij die apparatuur zodanig crappy is dat de tabel überhaupt niet geleegd wordt ofzo, maar goed da's dan je eigen schuld

[ Voor 16% gewijzigd door CyBeR op 20-06-2010 21:09 ]

[Olaf van der Spek]

CyBeR schreef op zondag 20 juni 2010 @ 21:08:
Je mag natuurlijk nooit uitgaan van dat apparatuur 'goed' is.

Waarom niet? Als je daar niet vanuit gaat, kun je nergens vanuit gaan.

Maar zelfs in crappy apparatuur* zal een daadwerkelijke host scan dit probleem niet veroorzaken. Het idee daarvan is tenslotte dat je erachter komt welke hosts er bestaan, en daarvoor moet je wachten op antwoord. Dat limiteert het aantal pogingen dat je kunt uitvoeren al genoeg.

Wat is de reden dat je op antwoord moet wachten?

[CyBeR]

Olaf van der Spek schreef op zondag 20 juni 2010 @ 21:11:
[...]

Waarom niet? Als je daar niet vanuit gaat, kun je nergens vanuit gaan.

Als we daar altijd van uit gingen zou 't internet elke drie kwartier kapot gaan.

Wat is de reden dat je op antwoord moet wachten?

Omdat je anders niet aan 't scannen bent maar gewoon aan 't DoSsen? Er is een maximum aan het aantal pogingen dat je tegelijk hebt uitstaan ten eerste en dat je überhaupt door je eigen verbinding kunt proppen ten tweede. En dan heb je ook nog een maximum aantal antwoorden dat je binnen kunt krijgen. Met de kans dat je een actieve host tegenkomt in de 2^64 adressen die je moet scannen wil je niet dat dat ene antwoord kwijt raakt tenslotte. (De rest levert als 't goed is na een tijdje een ICMP van de router op.)

[axis]

CyBeR schreef op zondag 20 juni 2010 @ 21:15:
[...]


Als we daar altijd van uit gingen zou 't internet elke drie kwartier kapot gaan.


[...]


Omdat je anders niet aan 't scannen bent maar gewoon aan 't DoSsen? Er is een maximum aan het aantal pogingen dat je tegelijk hebt uitstaan ten eerste en dat je überhaupt door je eigen verbinding kunt proppen ten tweede. En dan heb je ook nog een maximum aantal antwoorden dat je binnen kunt krijgen. Met de kans dat je een actieve host tegenkomt in de 2^64 adressen die je moet scannen wil je niet dat dat ene antwoord kwijt raakt tenslotte. (De rest levert als 't goed is na een tijdje een ICMP van de router op.)

En daarnaast hebben we dan clients met 'ipv6 privacy extensions' die ook nog regelmatig van ip's wisselen, tegen de tijd dat je een werkend ip hebt gevonden is ie al weer weg

[Whizzer]

Al met al kost het gewoon resources. En wanneer iets teveel resources kost, gaat het niet goed.... Dat heeft niets te maken met crappy hardware of niet. Als ik in een file sta op de snelweg omdat deze vol zit, is dan de weg crappy? Of zijn we gewoon met teveel man op de weg? Of misschien een beter vergelijk: Als ik stil sta voor een stoplicht, is dat stoplicht dan crappy?

Het punt is helaas ook niet of je er interessante hosts mee kan vinden (beheerbakken/servers enzo) of dat d.m.v. privacy extensions na korte tijd alles weer weg is, het probleem is gewoon dat dit resources kost van jouw gateway. Het is gewoon een ordinaire (D)DoS methode...

Zoals CyBeR al aangeeft heb je dus redelijk wat verkeer nodig om hier hinder van te kunnen gaan ondervinden. De wet van de grote getallen (lees: botnets en dat soort ongein) maakt het wel makkelijker de (on)gewenste ellende te veroorzaken.

Als je gericht op zoek wil naar interessante hosts, kan het wel eens leuk worden... Wij IT'ers hebben toch graag orde en overzicht, dus soortgelijke apparaten zullen we wel dezelfde host-id's geven. Net zoals nu bijna alle default gateways .1 of .254 zijn.

[serkoon]

Ik geloof dat we al vast hadden gesteld dat als/omdat je met IPv6 geen NAT gebruikt, je firewall er voor zorgt dat interne hosts niet zomaar van buitenaf direct bereikbaar zijn.
Een gateway die geen inkomend verkeer toestaat voor het interne netwerk gaat dus ook geen neighbor discoveries uitsturen als iemand een port scan uitvoert. Ergo: een non-probleem.

[Edgarz]

CyBeR schreef op vrijdag 18 juni 2010 @ 19:28:
[...]


En daar gaan we weer. NAT legt geen beperkingen op, NAT maakt slechts dingen kapot.

Eerste deel akkoord, maar het tweede deel van je zin mag je even toelichten.

[CyBeR]

Edgarz schreef op dinsdag 22 juni 2010 @ 19:52:
[...]


Eerste deel akkoord, maar het tweede deel van je zin mag je even toelichten.

Heel simpel: het IP-adres op de lokale interface en die in de packets die remote aankomen klopt niet meer. Dus zelfs als je een 1-op-1 NAT hebt (twee kanten op) kun je niet meer gewoon als applicatie zeggen: jeaux ftp server, connect eens naar <mijn ip> poort zoveel. Aardig wat protocollen doen dat. In plaats daarvan moet ofwel de NAT-gateway in je packets gaan zitten kutten met ALG's, of de applicatie moet moeilijk doen om z'n echte IP te achterhalen.

[Edgarz]

KLopt. Maar ik zoek nog even naar de link met "kapot maken", kijkend naar het doel dat NAT dient. Een ontploffende granaat maakt ook dingen kapot, maar da's het doel van een granaat, net zoals NAT ook een doel heeft binnen netwerken. Of is dit doel volgens jou (gewone andenkende mensen, non-Geen Stijl spelling ) een onbedoeld bij-effect van NAT?

[CyBeR]

Edgarz schreef op dinsdag 22 juni 2010 @ 20:48:
KLopt. Maar ik zoek nog even naar de link met "kapot maken", kijkend naar het doel dat NAT dient. Een ontploffende granaat maakt ook dingen kapot, maar da's het doel van een granaat, net zoals NAT ook een doel heeft binnen netwerken. Of is dit doel volgens jou (gewone andenkende mensen, non-Geen Stijl spelling ) een onbedoeld bij-effect van NAT?

Oh, ik heb nooit gezegd dat dingen kapot maken het doel is van NAT. Dat is namelijk niet zo, het is bedoeld om het IPv4-adrestekort wat uit te stellen. Maar als bij-effect maakt 't dingen kapot. Daar zijn we inmiddels zo compleet aan gewend dat we het normaal vinden dat we ALG's moeten hebben en protocollen als STUN, etc., maar dat neemt niet weg dat die alleen bestaan omdat NAT dingen kapot maakt.

[axis]

CyBeR schreef op dinsdag 22 juni 2010 @ 20:56:
[...]
Oh, ik heb nooit gezegd dat dingen kapot maken het doel is van NAT. Dat is namelijk niet zo, het is bedoeld om het IPv4-adrestekort wat uit te stellen. Maar als bij-effect maakt 't dingen kapot. Daar zijn we inmiddels zo compleet aan gewend dat we het normaal vinden dat we ALG's moeten hebben en protocollen als STUN, etc., maar dat neemt niet weg dat die alleen bestaan omdat NAT dingen kapot maakt.

With stupid

Men moest iets om om te kunnen gaan met de geringe hoeveelheid ip's, dan maar deze vieze hack.

Sommige protocollen zoals SIP zijn echt niet gemaakt om met NAT om te kunnen gaan, daar kom je pas goed achter als je dieper in het sip protocol duikt. Moet je allemaal truukjes gaan uithalen om het alsnog werkend te krijgen, zoals STUN. Gelukkig zijn we daar over niet al te lange tijd vanaf.. (Bij ons op de zaak zijn we al deels over op ipv6, en hebben we dus ook een boel nat-gezeik niet meer)

Er zullen in het ipv6 tijdperk nog steeds mensen zijn die gebruik willen maken van NAT omdat het voor hen veilig en vertrouwd voelt, maar gelukkig hebben een aantal leveranciers zoals cisco al gemeld dat ze in hun apparatuur geen nat over ipv6 gaan ondersteunen.. (hoewel het technisch wel mogelijk is, is het voor niemand wenselijk).

[ Voor 3% gewijzigd door axis op 22-06-2010 21:22 ]

[JackBol]

CyBeR schreef op dinsdag 22 juni 2010 @ 20:14:
[...]


jeaux ftp server, connect eens naar <mijn ip> poort zoveel.

Hoe kan je zo ageren tegen NAT en dan FTP als voorbeeld nemen? Dat is net zo'n flagrante schending van het OSI-model...

[CyBeR]

_DH schreef op dinsdag 22 juni 2010 @ 21:47:
[...]


Hoe kan je zo ageren tegen NAT en dan FTP als voorbeeld nemen? Dat is net zo'n flagrante schending van het OSI-model...

Omdat iedereen FTP kent en het andere voorbeeld waar dat voor geldt (http) nou eenmaal wel met NAT werkt. Een voorbeeld kiezen dat niemand kent heeft me eigenlijk nog nooit geholpen

[ Voor 10% gewijzigd door CyBeR op 22-06-2010 21:52 ]

[TrailBlazer]

waarom zou FTP het OSI model schenden?

[JackBol]

TrailBlazer schreef op woensdag 23 juni 2010 @ 06:38:
waarom zou FTP het OSI model schenden?

Het PORT-command gebruikt het IP adres en TCP port number als parameter.


Volgens het OSI model zouden de onderliggende lagen deze informatie voor de applicatie moeten abstraheren. Als de applicatie deze kennis toch moet overdragen zou de functionaliteit verzocht moeten worden van de onderliggende lagen (TCP/IP stack) in plaats van de aanname te doen die nu gedaan word.

[CyBeR]

_DH schreef op woensdag 23 juni 2010 @ 11:43:
[...]

Volgens het OSI model zouden de onderliggende lagen deze informatie voor de applicatie moeten abstraheren. Als de applicatie deze kennis toch moet overdragen zou de functionaliteit verzocht moeten worden van de onderliggende lagen (TCP/IP stack) in plaats van de aanname te doen die nu gedaan word.

Ik weet niet of ik dat zó strak zou willen interpreteren. Ik zie dat toch meer als dat Laag 4 zich niet bezig houdt met hoe Laag 3 z'n werk doet, Laat 3 niet met Laag 2, etc. Maar bijvoorbeeld L3 heeft toch echt L2 info nodig (op Ethernet, ARP enzo) om te kunnen werken.

[JackBol]

CyBeR schreef op woensdag 23 juni 2010 @ 12:00:
[...]


Ik weet niet of ik dat zó strak zou willen interpreteren. Ik zie dat toch meer als dat Laag 4 zich niet bezig houdt met hoe Laag 3 z'n werk doet, Laat 3 niet met Laag 2, etc. Maar bijvoorbeeld L3 heeft toch echt L2 info nodig (op Ethernet, ARP enzo) om te kunnen werken.

Klopt, L3 kan gewoon services requesten van L2. Daar zijn interfaces tussen de lagen voor. Echter zou L4 nooit iets te maken moeten hebben met L2.

Eensgelijks met FTP (L7) die zich niet bezig moet houden met L3/L4 zaken.

[Whizzer]

serkoon schreef op maandag 21 juni 2010 @ 10:57:
Ik geloof dat we al vast hadden gesteld dat als/omdat je met IPv6 geen NAT gebruikt, je firewall er voor zorgt dat interne hosts niet zomaar van buitenaf direct bereikbaar zijn.
Een gateway die geen inkomend verkeer toestaat voor het interne netwerk gaat dus ook geen neighbor discoveries uitsturen als iemand een port scan uitvoert. Ergo: een non-probleem.

Tja, met zo'n gedachte vraag ik me af waarom ik toch nog steeds verzuip in het werk... Een stuk van de kracht van IPv6 is trouwens dat je interne dingen weer direct benaderbaar zou kunnen maken.

Natuurlijk moet je goed filteren aan de edges, dat is IP (en al helemaal NAT) onafhankelijk... Sterker nog; thuis heb jij waarschijnlijk ook sloten op je deur (=edge).

Maar als je als groot bedrijf alleen aan de buitenkant filtert, vertrouw je dus je eigen mensen? Of de laptops die regelmatig naar buiten en binnen komen?

Samenvatting: Ja het probleem is relatief makkelijk te voorkomen en nee, het zal niet al te snel gebeuren, maar je moet er wel over nadenken!

[Olaf van der Spek]

CyBeR schreef op dinsdag 22 juni 2010 @ 20:14:
Heel simpel: het IP-adres op de lokale interface en die in de packets die remote aankomen klopt niet meer. Dus zelfs als je een 1-op-1 NAT hebt (twee kanten op) kun je niet meer gewoon als applicatie zeggen: jeaux ftp server, connect eens naar <mijn ip> poort zoveel. Aardig wat protocollen doen dat. In plaats daarvan moet ofwel de NAT-gateway in je packets gaan zitten kutten met ALG's, of de applicatie moet moeilijk doen om z'n echte IP te achterhalen.

Active FTP is gewoon brak ontworpen en het public IP adres achterhalen is zo moeilijk niet.

Het grote probleem met NAT is dat automatic port forwarding niet (goed) geregeld is. Dat is echter geen fout van het NAT concept.

[ Voor 8% gewijzigd door Olaf van der Spek op 23-06-2010 18:07 ]

[Snow_King]

_DH schreef op woensdag 23 juni 2010 @ 11:43:
[...]


Het PORT-command gebruikt het IP adres en TCP port number als parameter.


Volgens het OSI model zouden de onderliggende lagen deze informatie voor de applicatie moeten abstraheren. Als de applicatie deze kennis toch moet overdragen zou de functionaliteit verzocht moeten worden van de onderliggende lagen (TCP/IP stack) in plaats van de aanname te doen die nu gedaan word.

Het FTP protocol moeten we ook allang afschaffen, sFTP (over SSH) is veel gaver

Anyway, om even terug te komen op NAT, als ik ergens een hekel aan heb is het wel NAT, wat een drama is dat!

Zelf werk ik ook in een groot netwerk als beheerder waar veel VOIP wordt gebruikt en iedere keer, keer op keer blijft NAT maar weer in de weg zitten.

Verder ben ik het geheel met Cyber eens, NAT geeft nu per toeval een stukje veiligheid, maar dat is alleen maar vervelend.

Om dan even naar de thuisrouters te kijken, die zullen straks waarschijnlijk bij default alle unrelated connecties inboud blokkeren.

[CyBeR]

Olaf van der Spek schreef op woensdag 23 juni 2010 @ 18:02:
[...]
Het grote probleem met NAT is dat automatic port forwarding niet (goed) geregeld is. Dat is echter geen fout van het NAT concept.

Euh, hallo? Dat soort poort-forwarding hacks zijn een hack om de problemen van een andere hack (NAT) te omzeilen.

Dat NAT is ook echt wel verdomd hard eringebrand he. Voor de duidelijkheid: NAT is NIET normaal.

[Olaf van der Spek]

CyBeR schreef op woensdag 23 juni 2010 @ 19:52:
Euh, hallo? Dat soort poort-forwarding hacks zijn een hack om de problemen van een andere hack (NAT) te omzeilen.

Ja, en?

Dat NAT is ook echt wel verdomd hard eringebrand he. Voor de duidelijkheid: NAT is NIET normaal.

NAT is nu eenmaal de realiteit. Liefst had ik tien jaar geleden al IPv6 gehad natuurlijk, maar helaas, het liep anders.

[CyBeR]

Olaf van der Spek schreef op woensdag 23 juni 2010 @ 20:19:
[...]

Ja, en?

We proberen een nieuw IP-protocol in te voeren, en dan gaan we die vieze hacks maar gewoon weer lekker over nemen? Vind je dat nou werkelijk een goed idee?

NAT is nu eenmaal de realiteit. Liefst had ik tien jaar geleden al IPv6 gehad natuurlijk, maar helaas, het liep anders.

NAT is de realiteit in IPv4. Daar heb ik vrede mee. Maar de 'fout' die NAT veroorzaakt heeft (te weinig adresruimte) is in IPv6 opgelost, dus laten we de gevolgen dan niet meenemen.

[Olaf van der Spek]

CyBeR schreef op woensdag 23 juni 2010 @ 20:21:
NAT is de realiteit in IPv4. Daar heb ik vrede mee. Maar de 'fout' die NAT veroorzaakt heeft (te weinig adresruimte) is in IPv6 opgelost, dus laten we de gevolgen dan niet meenemen.

Eh, je hebt me verkeerd begrepen. Natuurlijk wil ik ook af van NAT. Ik zeg alleen dat het leed van NAT beperkt had kunnen blijven als automatic port forwarding fatsoenlijk was geimplementeerd.

[ Voor 14% gewijzigd door Olaf van der Spek op 23-06-2010 20:35 ]

[axis]

Aan de andere kant: hoe groter het NAT-probleem in ipv4, hoe sneller men over wil naar ipv6

Collega systeembeheerder van me begin nu voor het eerst serieus te spelen met SIP achter zijn NAT-routertje thuis, en die hoor ik regelmatig vloeken..

[Loekie]

axis schreef op vrijdag 25 juni 2010 @ 11:27:
Aan de andere kant: hoe groter het NAT-probleem in ipv4, hoe sneller men over wil naar ipv6

Collega systeembeheerder van me begin nu voor het eerst serieus te spelen met SIP achter zijn NAT-routertje thuis, en die hoor ik regelmatig vloeken..

Ken jij registrars die ipv6 aanbieden? Ik ben op zoek, maar tot op heden nog niet tegengekomen.
Da's nog steeds de ellende, je kunt er klaar voor zijn, maar als de rest van de wereld dat nog niet is heeft het weinig zin....

[Skinkie]

Olaf van der Spek schreef op woensdag 23 juni 2010 @ 20:33:
[...]

Eh, je hebt me verkeerd begrepen. Natuurlijk wil ik ook af van NAT. Ik zeg alleen dat het leed van NAT beperkt had kunnen blijven als automatic port forwarding fatsoenlijk was geimplementeerd.

Dat is met uPNP ook best aardig geimplementeerd. Maar realiseer je ook dat het aantal poorten beperkt is. Dus je kunt niet op eens 10000 machines achter NAT hangen als ze allemaal 6 flows met data opstarten.

[axis]

Loekie schreef op vrijdag 25 juni 2010 @ 12:30:
[...]

Ken jij registrars die ipv6 aanbieden? Ik ben op zoek, maar tot op heden nog niet tegengekomen.
Da's nog steeds de ellende, je kunt er klaar voor zijn, maar als de rest van de wereld dat nog niet is heeft het weinig zin....

Idd, het schiet allemaal maar niet op.. onze klanten en leveranciers ben ik al steeds meer aan het kietelen, telkens als ze om het ip van een webserver vragen bijvoorbeeld, geef ik ze de ipv4 en ipv6 ip's, ondanks dat ik weet dat ze nog niets met ipv6 doen. Als een klant een mailserver in onze dns wil wijzigen, vraag ik 'm altijd of ik ook nog een ipv6 adres erbij moet zetten. Hebben ze niet, maar op die manier gaan ze volgens mij wel een beetje achter de oren krabben, omdat ze zien dat anderen in de industrie er dus wel al mee klaar zijn en er al gewoon mee werken.

[Olaf van der Spek]

Skinkie schreef op vrijdag 25 juni 2010 @ 12:36:
[...]

Dat is met uPNP ook best aardig geimplementeerd. Maar realiseer je ook dat het aantal poorten beperkt is. Dus je kunt niet op eens 10000 machines achter NAT hangen als ze allemaal 6 flows met data opstarten.

Kan best hoor...
Ik ben helemaal niet tevreden met de huidige status van UPnP. Windows Firewall/Networking zou de port forwarding moeten doen, niet elke app afzonderlijk.

[ Voor 10% gewijzigd door Olaf van der Spek op 25-06-2010 19:42 ]

[Osiris]

Portforwarding zou überhaupt niet nodig moeten zijn

[CAPSLOCK2000]

NAT heeft op zich best nuttige toepassingen (veel load-balancers werken bv met NAT). Helaas heeft het ook flinke nadelen als het gebruikt om meerdere PC's achter een 1 IP te stoppen. Het maakt de bi-directionaliteit van Internet stuk en dat maakt interactie een stuk moeilijker. Een belangrijk deel van het succes van Skype is dat ze als een van de eerste om de beperkingen van NAT heen hebben weten te werken.

NAT heeft kwa beveiliging geen enkel voordeel boven een state-full firewall die geen inkomend verkeer toestaat.
De interface op een consumentenrouter om poorten open te zetten kan exact hetzelfde blijven. (Je hoeft alleen geen dubbele poorten meer te veranderen ).

[Osiris]

CAPSLOCK2000 schreef op maandag 28 juni 2010 @ 02:05:
NAT heeft op zich best nuttige toepassingen (veel load-balancers werken bv met NAT).

Wat ook prima zonder NAT kan.

[CyBeR]

CAPSLOCK2000 schreef op maandag 28 juni 2010 @ 02:05:
NAT heeft op zich best nuttige toepassingen (veel load-balancers werken bv met NAT).

Load balancers die NATten creeeren een enorme bottleneck: zichzelf.

[Olaf van der Spek]

CAPSLOCK2000 schreef op maandag 28 juni 2010 @ 02:05:
NAT heeft op zich best nuttige toepassingen (veel load-balancers werken bv met NAT). Helaas heeft het ook flinke nadelen als het gebruikt om meerdere PC's achter een 1 IP te stoppen. Het maakt de bi-directionaliteit van Internet stuk en dat maakt interactie een stuk moeilijker.

Zoals ik al zei is dat niet zozeer de schuld van NAT als wel het gebrek aan automatic port forwarding.

[CAPSLOCK2000]

Olaf van der Spek schreef op maandag 28 juni 2010 @ 12:13:

Zoals ik al zei is dat niet zozeer de schuld van NAT als wel het gebrek aan automatic port forwarding.

Dat ben ik niet met je eens, automatisch poorten forwarden zou een aantal van de problemen verminderen die je krijgt als je NAT gebruikt om meerdere PC's achter 1 ip te stoppen maar je blijft problemen houden.

Als ik bv 2 mailservers heb (om maar direct een lekker voorbeeld te pakken) dan moeten die allebei op poort 25 zitten. Je kan NATten wat je wil, maar daar kom je niet om heen. Automatische poorten mappen gaat daar niet bij helpen, je hebt maar 1 poort 25 per ip adres en mail moet nu eenmaal via poort 25.

Mail is dan direct wel het meest stugge voorbeeld mogelijk. Webservers zijn een stuk flexibeler; je kan de poort gewoon in een URL opnemen. Maar als die poort kan veranderen dan kun je geen URL's meer gebruiken.

Als we nog wat extremer denkt dan kom je met IPSEC in de problemen. IPSEC is encryptie voor IP verkeer. Als je zo'n pakketje gaat zitten veranderen dan werkt je encryptie niet meer.

Nu is hier ongetwijfeld ook wel weer een oplossing voor te vinden maar het punt blijft dat als je NAT gebruikt om meerdere PC's aan te sluiten dat je dan een aantal basisaannames van internet schendt.
NAT zo gebruiken is een noodoplossing, niet iets dat je moet willen.

[Marzman]

CAPSLOCK2000 schreef op maandag 28 juni 2010 @ 17:28:
[...]
Dat ben ik niet met je eens, automatisch poorten forwarden zou een aantal van de problemen verminderen die je krijgt als je NAT gebruikt om meerdere PC's achter 1 ip te stoppen maar je blijft problemen houden.

Als ik bv 2 mailservers heb (om maar direct een lekker voorbeeld te pakken) dan moeten die allebei op poort 25 zitten. Je kan NATten wat je wil, maar daar kom je niet om heen. Automatische poorten mappen gaat daar niet bij helpen, je hebt maar 1 poort 25 per ip adres en mail moet nu eenmaal via poort 25.

Dat is ook prima op te lossen door het op een sterkere server te gooien of een mailcluster te maken. Een mailserver zit trouwens zelden achter nat.