Het grote IPv6 topic

[Kees]

Raven schreef op woensdag 18 mei 2016 @ 18:39:
[...]

.... dan zou ik eerst uit moeten zoeken hoe ik dat kan doen, IPFire ondersteund officieel niet eens IPv6, het is haast een wonder dat het überhaupt werkt. Er zwerft inmiddels al wel een tijdje een howto op het web

Maar deze vervangen door Ubuntu Server staat al een tijdje op de planning, scheelt de nodige beperkingen.

Het gaat om de MTU van de client, dus waarmee jij browsed, in windows is dat dus iets alla:
'netsh interface ipv6 set subinterface “Local Area Connection” mtu=1280' (zou het alleen voor testen zo laag zetten, het heeft een klein beetje invloed op je normale netwerksnelheid als je hem permanent laag zet)

[ Voor 10% gewijzigd door Kees op 18-05-2016 18:42 ]

[Compizfox]

Raven schreef op woensdag 18 mei 2016 @ 18:23:
[...]
Zou dit trouwens hetzelfde kunnen zijn als waar Tumblr last van heeft? Die komt hier ook wel eens voorbij, zelfde probleem lijkt het. Daar heb ik inmiddels al een aantal servers van aan de hostfile toegevoegd, met het IPv4-adres.

Ik kan sommige servers van Tumblr (ik kom op Reddit wel eens plaatjes tegen die daar gehost worden) ook niet bereiken met mijn tunnel van SixXS.

[maarud]

Op mijn Synology-NAS heb ik een DHCP-server en DNS-server. Nu heb ik op Windows (waar IPv6-enabled is) wat problemen, o.a. dat mijn hostnames niet bereikbaar zijn tenzij ik specifiek de IPv4 DNS-server gebruik in nslookup. Als ik IPv6 uitzet dan werkt alles wel. Nu is het wel leuk om alles werkend te hebben ipv het simpel uitschakelen van IPv6. (Al heb ik daar nu als oplossing voor bedacht het uitschakelen van DHCPv6 in de FritzBox).

Ik ben me een beetje aan het verdiepen in IPv6 maar ik snap er nog bar weinig van Na het lezen van allerlei wiki-pagina's en de OT van dit topic en het bestuderen van mijn FritzBox status-pagina ben ik tot de volgende conclusies gekomen:

- Elk IPv6-apparaat heeft sowieso een link-local adres (beetje als 169.x.x.x.x bij IPv4)
- Je kan er voor kiezen om ULA-adressen te gebruiken (beetje zoals 192.168.x.x of 10.x.x.x adressen in IPv4)
- En je hebt global adressen (vergelijkbaar met alle 'gewone' IPv4-adressen oftewel via het internet bereikbaar).
- De FritzBox heeft een bepaalde prefix voor interne netwerken.

Zonder router e.d. heb je sowieso een local-adres, met mijn router krijg ik ook een global-adres. Als het goed is krijg ik een ula-adres als mijn internetverbinding met XS4all wegvalt (zo is het nu ingesteld op de FB). Op mijn NAS heb ik een local en een global adres (begint met 2001) maar op Windows apparaten heb ik een adres wat begint met de prefix uit de FritzBox. Dat zijn dan ULA adressen denk ik?

Nu heb ik wat vragen:

1. Betekend dat dus dat XS4all een soort van DHCP-server is voor mijn IPv6 global adressen? Of deelt de FritzBox die global-adressen uit?
2. Moet je een global-adres hebben om te kunnen internetten? Je internet dan toch zonder NAT begrijp ik?
3. Mijn NAS heeft een handmatig IP-adres om als DNS-server te kunnen fungeren. Het IP-adres is dus logischerwijs een intern IP-adres (192.168.x.x). Voor IPv6 moet dat ook neem ik aan. Als ik die echte rop manual zet ipv automatisch moet ik waarschijnlijk een 2001: adres maken. Kan ik die dan random verzinnen? Als ie maar begint met mijn XS4all prefix?
4. Is het nu wel of niet verstandig om DHCPv6 te gebruiken? Op sommige wiki's lees ik dat dat niet per se nodig is. In IPv4 vind ik het betrekkelijk simpel, ik heb een DHCP server draaien die als DNS het IP van mijn NAS meegeeft omdat dat de DNS-server is. Bij IPv6 mogen apparaten hun eigen adres verzinnen maar hoe weten ze dan dat mijn NAS de DNS-server is? Dan moet je toch bijna wel DHCPv6 gebruiken? Of gaat dat met die M/O flags?


Als iemand dat een een beetje beknopt uit kan leggen of een goeie how-to website heeft hoor ik het graag. Het is leuk om dat goed te laten werken.

[Orion84]

Net mijn ziggo abo omgezet van het 'oude' internet Z3+tv-standaard naar connect max en play start. Waardoor ik 1 euro minder per maand ga betalen, maar wel naar de nieuwe 300/30 verbinding ga.

Alleen heb ik daar blijkbaar een nieuw modem voor nodig. Ben benieuwd wat dat wordt en of ik daarmee ook weer mijn IPv6 verbinding verlies. Ah well, kan altijd mijn tunneltje weer aanzetten

[CyBeR]

Kees schreef op woensdag 18 mei 2016 @ 18:28:
[...]

Het is meestal vrij eenvoudig te zien of een website daar last van heeft door de MTU van je interface omlaag te zetten naar 1280, als je er dan wel bij kan komen dan heeft die site er last van

Lagere interface MTU bij jou zou dat niet aantonen. Wat er gebeurt bij Tumblr is namelijk dat je een lagere MTU *hebt* (vanwege tunnel), dus passen hun 1500b packets er niet doorheen en gaat er een 'mtu exceeded' icmp naar de verzender ervan (tumblr). Die zijn vervolgens incompetent en filteren die ICMP waardoor er nooit een retry optreedt.

[Kees]

CyBeR schreef op donderdag 19 mei 2016 @ 16:42:
[...]


Lagere interface MTU bij jou zou dat niet aantonen. Wat er gebeurt bij Tumblr is namelijk dat je een lagere MTU *hebt* (vanwege tunnel), dus passen hun 1500b packets er niet doorheen en gaat er een 'mtu exceeded' icmp naar de verzender ervan (tumblr). Die zijn vervolgens incompetent en filteren die ICMP waardoor er nooit een retry optreedt.

Klopt, dat is exact wat er gebeurd, alleen als jij je interface MTU omlaag schroeft dan werkt het wel gewoon omdat je dan meteen al aangeeft dat je kleine packetjes wil hebben. Met een MTU van 1500 heb je een MSS (Maximum Segment Size) van 1440 in je tcp-packet staan (totdat ook jij een icmpv6 response van je tunnel krijgt), met een MTU van 1280 is dat 1220 geworden, en dat negeren ze niet.

[CyBeR]

Kees schreef op donderdag 19 mei 2016 @ 17:36:
[...]

Klopt, dat is exact wat er gebeurd, alleen als jij je interface MTU omlaag schroeft dan werkt het wel gewoon omdat je dan meteen al aangeeft dat je kleine packetjes wil hebben. Met een MTU van 1500 heb je een MSS (Maximum Segment Size) van 1440 in je tcp-packet staan (totdat ook jij een icmpv6 response van je tunnel krijgt), met een MTU van 1280 is dat 1220 geworden, en dat negeren ze niet.

Je hebt gelijk ja, de mss was ik even vergeten.

[Zsub]

Orion84 schreef op donderdag 19 mei 2016 @ 16:38:
Net mijn ziggo abo omgezet van het 'oude' internet Z3+tv-standaard naar connect max en play start. Waardoor ik 1 euro minder per maand ga betalen, maar wel naar de nieuwe 300/30 verbinding ga.

Alleen heb ik daar blijkbaar een nieuw modem voor nodig. Ben benieuwd wat dat wordt en of ik daarmee ook weer mijn IPv6 verbinding verlies. Ah well, kan altijd mijn tunneltje weer aanzetten

Ik heb hetzelfde gedaan en krijg een TC7210, ik verwacht dat m'n tunneltje nog even mag draaien de komende tijd

[Jerrythafast]

Orion84 schreef op donderdag 19 mei 2016 @ 16:38:
Net mijn ziggo abo omgezet van het 'oude' internet Z3+tv-standaard naar connect max en play start. Waardoor ik 1 euro minder per maand ga betalen, maar wel naar de nieuwe 300/30 verbinding ga.

Alleen heb ik daar blijkbaar een nieuw modem voor nodig. Ben benieuwd wat dat wordt en of ik daarmee ook weer mijn IPv6 verbinding verlies. Ah well, kan altijd mijn tunneltje weer aanzetten

Aangezien je in oud-Ziggo gebied zit (uitgaande van je Internet Z3 abonnement), ga je een TC7210 krijgen die momenteel geen IPv6-ondersteuning heeft. Dus inderdaad, je tunneltje mag in ere worden hersteld

[Snow_King]

maarud schreef op donderdag 19 mei 2016 @ 13:15:
1. Betekend dat dus dat XS4all een soort van DHCP-server is voor mijn IPv6 global adressen? Of deelt de FritzBox die global-adressen uit?

Nee, XS4All informeert jouw FritzBox welk subnet (/48) voor jou is. Daarna zet de FritzBox de eerste /64 uit die /48 op jouw LAN interface.

Door middel van SLAAC (autoconfiguratie) verkrijgen je hosts vervolgens hun IPv6 adres.

maarud schreef op donderdag 19 mei 2016 @ 13:15:
2. Moet je een global-adres hebben om te kunnen internetten? Je internet dan toch zonder NAT begrijp ik?

Klopt, zonder NAT, maar wel mét firewall van de Fritzbox.

maarud schreef op donderdag 19 mei 2016 @ 13:15:
3. Mijn NAS heeft een handmatig IP-adres om als DNS-server te kunnen fungeren. Het IP-adres is dus logischerwijs een intern IP-adres (192.168.x.x). Voor IPv6 moet dat ook neem ik aan. Als ik die echte rop manual zet ipv automatisch moet ik waarschijnlijk een 2001: adres maken. Kan ik die dan random verzinnen? Als ie maar begint met mijn XS4all prefix?

Ja, mits deze in de /64 valt die je hebt op je LAN interface.

Al verwacht ik dat je NAS zelf een IPv6 adres aan neemt dmv SLAAC.

maarud schreef op donderdag 19 mei 2016 @ 13:15:
4. Is het nu wel of niet verstandig om DHCPv6 te gebruiken? Op sommige wiki's lees ik dat dat niet per se nodig is. In IPv4 vind ik het betrekkelijk simpel, ik heb een DHCP server draaien die als DNS het IP van mijn NAS meegeeft omdat dat de DNS-server is. Bij IPv6 mogen apparaten hun eigen adres verzinnen maar hoe weten ze dan dat mijn NAS de DNS-server is? Dan moet je toch bijna wel DHCPv6 gebruiken? Of gaat dat met die M/O flags?

Nee, DHCPv6 is niet écht nodig. Via SLAAC kan eigenlijk alles in een thuis netwerk.

Ik heb hier ook alles via SLAAC en geen DHCPv6 in mijn huis. Werkt prima met Linux en iOS devices.

Ook Windows en Mac OSX kunnen probleemloos zonder DHCPv6.


Je zal uiteindelijk merken dat IPv6 veel makkelijker is dan IPv4, maar je moet even begrijpen dat het iets anders is. Daarna wil je niet meer anders.

[maarud]

Maar hoe zit het dan met statische adressen ivm DNS? Of houdt mijn NAS altijd zijn adres, ook met SLAAC? Want anders gaat DNS natuurlijk niet werken, toch?

[databeestje]

maarud schreef op vrijdag 20 mei 2016 @ 11:27:
Maar hoe zit het dan met statische adressen ivm DNS? Of houdt mijn NAS altijd zijn adres, ook met SLAAC? Want anders gaat DNS natuurlijk niet werken, toch?

Tenzij de provider andere prefixen uit gaat delen zal je met SLAAC hetzelfde adres behouden, ook al is deze lang. Je kan hem altijd nog vast instellen als je zou willen.

[Snow_King]

maarud schreef op vrijdag 20 mei 2016 @ 11:27:
Maar hoe zit het dan met statische adressen ivm DNS? Of houdt mijn NAS altijd zijn adres, ook met SLAAC? Want anders gaat DNS natuurlijk niet werken, toch?

Wat databeestje dus al zegt. Je hoeft niet perse SLAAC te gebruiken, je kan ook prima gewoon je NAS een statisch adres geven in zijn configuratie.

Je hebt miljarden adressen om uit te kiezen, dus kies wat je mooi vind voor je NAS.

[CAPSLOCK2000]

Het vervelende van SLAAC is dat het typische erg lange adressen oplevert die voor mensen minder prettig in het gebruik zijn. Een oplossing is om de adressen in DNS te zetten. Dat werkt al iets beter tot er een keer een onderdeel stuk gaat en je NAS/server een ander IP-adres krijgt, dat is maar een hoop gedoe en als je een keer vergeet om DNS bij te werken dan wordt het al snel een puinhoop.

Daar is ook weer een oplossing voor, Dynamische DNS. Het idee is dat je systemen zichzelf melden bij je DNS-server en hun eigen adres registreren. Technisch kan dat tot op zekere hoogte maar over het algemeen wil je clients geen rechten geven om je DNS-server te manipuleren. Je kan er wel weer een wachtwoord of een certificaat ofzo aanhangen maar dan moet je dat wachtwoord weer op je clients krijgen, dat is ook weer gedoe.

De volgende stap is dan Multicast DNS. In plaats van een centrale DNS-server wordt er een multicast kanaal opgezet waarover systemen naar DNS-verzoekjes luisteren. Als ze hun eigen naam zien langskomen dan reageren ze. Zo heb je geen centrale server nodig. Het lijkt erg op oude protocollen als NetBIOS, maar dan op grond van multicast (wat efficient is) in plaats van broadcast (wat niet efficient is in grote netwerken).

[Bigs]

Leuk om te zien: ik heb laatst het gastennetwerk van mijn XS4ALL Fritz!Box in gebruik genomen. Voor IPv4 krijg je dan een extra RFC1918 reeks erbij die naar je enkele uitgaande IP wordt gerouteerd. Voor IPv6 pakt hij een tweede /64 uit de /56 die ik van m'n provider krijg. Zo netjes 👌🏻. Dan is IPv6 wel echt weer een vooruitgang!

[CAPSLOCK2000]

Bigs schreef op zaterdag 21 mei 2016 @ 12:52:
Voor IPv6 pakt hij een tweede /64 uit de /56 die ik van m'n provider krijg. Zo netjes 👌🏻. Dan is IPv6 wel echt weer een vooruitgang!

Zó simpel en elegant dat het mooi is. Ik weet het, eigenlijk stelt het helemaal niks voor, dit is hoe het 30 jaar geleden ontworpen is maar met IPv4/NAT werd het toch steeds weer complex en ingewikkeld. Wat een verademing.

[maarud]

Het gewone deel van IPv6 snap ik dan nu...maar:

- Met IPv6 zijn de adressen redelijk statisch. Maar wat als mijn internetverbinding uitvalt? Pakt ie dan een ULA-adres? Zo ja, dan zou DNS toch niet meer werken omdat die op een 2001:-adres ingesteld staat?
- Ik kan in mijn Synology NAS nergens instellen bij de DNS Server package dat hij zijn eigen adres moet announcen over het netwerk. Nu pakken de apparaten steeds het IPv6-adres van de FritzBox waardoor het hele DNS voor IPv4 ook niet meer werkt. Is dat een limiet van de Synology of snap ik er nog niets van?

[TD-er]

Waarom zou je intern niet met een globaal adres kunnen blijven communiceren wanneer de route na je gateway er tijdelijk even uit ligt?

De DNS van je router heeft een basis-adres gekregen en daarmee mag 'ie naar hartenlust gaan uitdelen.
Pas als je router een nieuw basis-adres krijgt zal je router anders gaan gedragen qua DNS.
Hoe dat precies gaat weet ik ook niet, want ik verwacht eigenlijk dat je dan het 'subscriber-adres' alleen maar hoeft aan te passen. Dus ik zou verwachten dat er een soort van broadcast rond gaat die dat aankondigt.

[stormfly]

maarud schreef op zondag 22 mei 2016 @ 17:18:
Het gewone deel van IPv6 snap ik dan nu...maar:

- Met IPv6 zijn de adressen redelijk statisch. Maar wat als mijn internetverbinding uitvalt? Pakt ie dan een ULA-adres? Zo ja, dan zou DNS toch niet meer werken omdat die op een 2001:-adres ingesteld staat?
- Ik kan in mijn Synology NAS nergens instellen bij de DNS Server package dat hij zijn eigen adres moet announcen over het netwerk. Nu pakken de apparaten steeds het IPv6-adres van de FritzBox waardoor het hele DNS voor IPv4 ook niet meer werkt. Is dat een limiet van de Synology of snap ik er nog niets van?

1: als je met statisch " SLAAC = afgeleid van het mac adres" bedoeld, dan kan dat statisch overkomen. Maar zo hoef je het niet te gebruiken, je kan ook gewoon zelf adressen toewijzen. Nee ULA is eigenlijk gone, dat komt je nagenoeg niet tegen. Hij blijft gewoon in zijn Link Local (FE80) segment communiceren via multicast groepen. Als jouw DNS server in hetzelfde LAN segment valt dan kan hij daar gewoon bij.

2: Nope dat komt omdat je bij IPv6 eigenijk alle DHCPv6 beschikbaarheid of DNS/Gateway details leert via de Link Local FE80 communicatie. De RA (Router Advertisements) geven aan of er überhaupt een DHCPv6 verstuurd mag worden via de M en O bitjes. Die staan volgens mij wel aan bij o.a Ziggo dus een eigen DHCPv6 server (zit niet in Synology) optuigen zou dan de oplossing zijn.

[maarud]

TD-er schreef op zondag 22 mei 2016 @ 20:41:
Waarom zou je intern niet met een globaal adres kunnen blijven communiceren wanneer de route na je gateway er tijdelijk even uit ligt?

De DNS van je router heeft een basis-adres gekregen en daarmee mag 'ie naar hartenlust gaan uitdelen.
Pas als je router een nieuw basis-adres krijgt zal je router anders gaan gedragen qua DNS.
Hoe dat precies gaat weet ik ook niet, want ik verwacht eigenlijk dat je dan het 'subscriber-adres' alleen maar hoeft aan te passen. Dus ik zou verwachten dat er een soort van broadcast rond gaat die dat aankondigt.

Tja geen idee, zit nog met het IPv4-idee in mijn hoofd, niet wetende dat er natuurlijk zoveel IP-adressen zijn dat je interne adres ook meteen je externe adres is (oftewel onderscheid is er eigenlijk niet meer). In dat opzicht is het logisch idd dat je gewoon intern verder kan netwerken want je externe adres is ook intern gewoon bruikbaar.

stormfly schreef op zondag 22 mei 2016 @ 20:50:
[...]


1: als je met statisch " SLAAC = afgeleid van het mac adres" bedoeld, dan kan dat statisch overkomen. Maar zo hoef je het niet te gebruiken, je kan ook gewoon zelf adressen toewijzen. Nee ULA is eigenlijk gone, dat komt je nagenoeg niet tegen. Hij blijft gewoon in zijn Link Local (FE80) segment communiceren via multicast groepen. Als jouw DNS server in hetzelfde LAN segment valt dan kan hij daar gewoon bij.

Ah oke, dus je link-local is ook gewoon lekker bruikbaar i.t.t. IPv4 waar het meestal betekend dat je geen netwerkmogelijkheden hebt?

2: Nope dat komt omdat je bij IPv6 eigenijk alle DHCPv6 beschikbaarheid of DNS/Gateway details leert via de Link Local FE80 communicatie. De RA (Router Advertisements) geven aan of er überhaupt een DHCPv6 verstuurd mag worden via de M en O bitjes. Die staan volgens mij wel aan bij o.a Ziggo dus een eigen DHCPv6 server (zit niet in Synology) optuigen zou dan de oplossing zijn.

Moet ik dan in de router aangeven dat de Synology de DNS-server is? Ik kan alleen dat nergens invullen in de FritzBox, alleen heb ik de keuze uit 3 opties (zo uit mijn hoofd) die idd te maken hebben met die M en O bitjes.

Dat laatste blijft nog ff een lastig punt. Toch beetje moeilijk zo als je altijd IPv4 gewend bent (en de denkwijze daarin)

[Compizfox]

Kees schreef op donderdag 19 mei 2016 @ 17:36:
[...]

Klopt, dat is exact wat er gebeurd, alleen als jij je interface MTU omlaag schroeft dan werkt het wel gewoon omdat je dan meteen al aangeeft dat je kleine packetjes wil hebben. Met een MTU van 1500 heb je een MSS (Maximum Segment Size) van 1440 in je tcp-packet staan (totdat ook jij een icmpv6 response van je tunnel krijgt), met een MTU van 1280 is dat 1220 geworden, en dat negeren ze niet.

Ik las dat ik in plaats van de MTU omlaag schroeven op alle devices in m'n netwerk ook MSS clamping kan toepassen.

Mijn vraag is echter welke waarde ik daar dan moet invullen. Mijn tunnel heeft een MTU van 1280 (kan eventueel omhoog tot 1480, weet niet of dat handig is?) en dat staat dan ook ingesteld als MTU in de tunnel-interface op mijn router.

Ik het vakje ernaast kan ik een MSS opgeven voor MSS clamping. Moet ik daar ook gewoon 1280 invullen? Of moet ik daar nog een bepaald getal van aftrekken ivm 6in4 overhead?

[Newjersey]

Ik kwam gisteravond nog een leuk probleem tegen met Citrix XenApp/Desktop 7.8.

Ik had een testomgeving opgezet in m'n gewone LAN. Hierin is IPv6 actief. Het registeren van de VDA bij de delivery controller werkte niet. Hij kon geen IP vinden aan het DNS record. Wat blijkt: Zodra er een IPv6 en IPv4 DNS record aan een Citrix Delivery Controller zit kan de VDA zich niet registreren.

IPv6 uitgezet op alle twee de interfaces en voila: Alles werkt. Beetje jammer dat een groot Enterprise software pakket geen IPv6 ondersteund.

[Keiichi]

Newjersey schreef op maandag 23 mei 2016 @ 08:14:
Ik kwam gisteravond nog een leuk probleem tegen met Citrix XenApp/Desktop 7.8.

Ik had een testomgeving opgezet in m'n gewone LAN. Hierin is IPv6 actief. Het registeren van de VDA bij de delivery controller werkte niet. Hij kon geen IP vinden aan het DNS record. Wat blijkt: Zodra er een IPv6 en IPv4 DNS record aan een Citrix Delivery Controller zit kan de VDA zich niet registreren.

IPv6 uitgezet op alle twee de interfaces en voila: Alles werkt. Beetje jammer dat een groot Enterprise software pakket geen IPv6 ondersteund.

Vind het nog vreemder dat bij een IPv6 implementatie roet in het eten gooit.

[Newjersey]

Keiichi schreef op maandag 23 mei 2016 @ 08:32:
[...]


Vind het nog vreemder dat bij een IPv6 implementatie roet in het eten gooit.

Dit was het testen in een privé situatie / test lab

[martijnr17]

Wij gebruiken hier Novell oes, zenworks en iprint en dat was vroeger toch een hele grote jongen en die hebben volgens mij helemaal niets op ipv6. Je kan ook niets vinden over ipv6 een planning ofzo.

[CAPSLOCK2000]

We hadden hier een bekende leverancier van firewalls over de vloer om hun nieuwste producten te testen. Uiteraard vraag ik dan even hoe het met IPv6-ondersteuning zit. Dat zat er in. Ok, vooruitgang! 5 jaar geleden keken ze me dan nog vuil aan om te vertellen dat niemand daar ooit om vroeg.

Mooi, dacht ik, dus toen de mannen ip-adressen nodig hadden om het ding te configureren heb ik ze IPv6-adressen gegeven. Dat viel tegen. Er was wel een veldje om een IPv6-adres in te stellen maar je moet ook nog DNS-servers instellen. Je raadt het al, dat veldje snapte geen IPv6-adressen. Dusver de claims dat het apparaat ook in een IPv6-only omgeving kan werken. Als je niet eens voorbij het start-scherm komt kan ik niet geloven dat ze het apparaat echt in een IPv6-only omgeving hebben getest.


Terzijde nog een ander punt van frustratie: applicaties die IPv4 en IPv6 al gescheiden werelden behandelen. In 99% van de gevallen is de configuratie voor IPv6 gelijk aan die voor IPv4, het enige verschil zit in de adressen zelf. Toch moet ik vaak alles dubbel doen, één keer voor IPv4 en één keer voor IPv6. Ik ken eigenlijk geen enkel geval waar er echt verschillen zijn. In mijn eigen omgeving probeer ik het zo veel mogelijk te unificeren. Zo genereer ik mijn firewalls voor IPv4 en IPv6 op grond van dezelfde configuratiefile. Ik zeg gewoon dat poort 80 open mag staan, de software mag dan uitvogelen hoe dat voor IPv4 en IPv6 moet.

[Compizfox]

CAPSLOCK2000 schreef op maandag 23 mei 2016 @ 19:12:
Terzijde nog een ander punt van frustratie: applicaties die IPv4 en IPv6 al gescheiden werelden behandelen. In 99% van de gevallen is de configuratie voor IPv6 gelijk aan die voor IPv4, het enige verschil zit in de adressen zelf. Toch moet ik vaak alles dubbel doen, één keer voor IPv4 en één keer voor IPv6. Ik ken eigenlijk geen enkel geval waar er echt verschillen zijn. In mijn eigen omgeving probeer ik het zo veel mogelijk te unificeren. Zo genereer ik mijn firewalls voor IPv4 en IPv6 op grond van dezelfde configuratiefile. Ik zeg gewoon dat poort 80 open mag staan, de software mag dan uitvogelen hoe dat voor IPv4 en IPv6 moet.

Hangt natuurlijk van je situatie af, maar vaak is het wel zo dat je voor IPv4 NAT doet en voor IPv6 niet. Dat is wel een belangrijk verschil tussen de configuratie.

[Roetzen]

Compizfox schreef op maandag 23 mei 2016 @ 19:15:
[...]

Hangt natuurlijk van je situatie af, maar vaak is het wel zo dat je voor IPv4 NAT doet en voor IPv6 niet. Dat is wel een belangrijk verschil tussen de configuratie.

Zeker, NAT (IPv4) is wat anders dan een poort in de firewall openstellen (IPv6). Maar in 99% van de gevallen wil je de binnenkomende pakketjes voor IPv4 en IPv6 voor dezelfde poort naar dezelfde host doorsturen. Een slim user interface zou dat in één handeling kunnen regelen. Dus als ik een Port forward voor poort 80 naar 192.168.1.2 configureer, dan kan het configuratieprogrammatje even opzoeken welk MAC adres daar bij hoort en vragen of poort 80 IPv6 pakketjes naar dat zelfde interface doorgestuurd moeten worden.

[CAPSLOCK2000]

Yup, zo heb ik het ongeveer werken. Ik geef in een DSL aan dat ik poort X op machine Y bereikbaar wil maken. De software zoekt dan op welke IP-adressen er bij betrokken zijn en voegt de juiste regels aan m'n firewall toe. Voor IPv6 is het genoeg om het poort open te zetten maar voor IPv4 moet er ook nog een NAT-regeltje worden toegevoegd.

Ik snap wel dat er stukjes zijn die gescheiden moeten blijven, zeker op een firewall, maar ik zie heel vaak een scheiding waar dat conceptueel gezien niet nodig is.

[Kees]

Dat vind ik met mijn nieuwe loadbalancers (brocade) dan wel weer handig. Daar werk je met IP-pools, en dan maakt het niet uit welke adressen erin zitten. Mijn meeste IP pools hebben meerdere ipv4 en ipv6 adressen door elkaar in zo'n pool. Die ik overigens wel weer apart in de firewall moet openzetten.

Nu is het niet allemaal briljant, ze claimen 'full ipv6' te ondersteunen, maar ik ben bij die loadbalancers al wel een paar dingen tegen gekomen die niet helemaal tof onder ipv6 werken. Ik geloof dat ik zo'n lijst opgestuurd heb dat ze het komende jaar nog wel bezig kunnen zijn met die lijst af te werken

Overigens ben ik het niet eens met de stelling dat je voor ipv6 geen NAT doet, dat doe ik bewust wel tenzij een server extern bereikbaar moet zijn. Voor de rest van de servers houd ik bewust ipv6-NAT aan zodat ze via 1 of 2 ip's naar buiten gaan. Ik moet met een aantal services werken die een ip-whitelist hebben en ik heb geen zin om al mijn servers daarin te zetten.

[Snow_King]

Kees schreef op dinsdag 24 mei 2016 @ 18:27:
Dat vind ik met mijn nieuwe loadbalancers (brocade) dan wel weer handig. Daar werk je met IP-pools, en dan maakt het niet uit welke adressen erin zitten. Mijn meeste IP pools hebben meerdere ipv4 en ipv6 adressen door elkaar in zo'n pool. Die ik overigens wel weer apart in de firewall moet openzetten.

Nu is het niet allemaal briljant, ze claimen 'full ipv6' te ondersteunen, maar ik ben bij die loadbalancers al wel een paar dingen tegen gekomen die niet helemaal tof onder ipv6 werken. Ik geloof dat ik zo'n lijst opgestuurd heb dat ze het komende jaar nog wel bezig kunnen zijn met die lijst af te werken

Overigens ben ik het niet eens met de stelling dat je voor ipv6 geen NAT doet, dat doe ik bewust wel tenzij een server extern bereikbaar moet zijn. Voor de rest van de servers houd ik bewust ipv6-NAT aan zodat ze via 1 of 2 ip's naar buiten gaan. Ik moet met een aantal services werken die een ip-whitelist hebben en ik heb geen zin om al mijn servers daarin te zetten.

Die diensten zouden een subnet moeten ondersteunen. Losse IP's is erg IPv4 denken.

NAT en IPv6 is echt eng vind ik en totaal onnodig.

[ik222]

Kees schreef op dinsdag 24 mei 2016 @ 18:27:
Dat vind ik met mijn nieuwe loadbalancers (brocade) dan wel weer handig. Daar werk je met IP-pools, en dan maakt het niet uit welke adressen erin zitten. Mijn meeste IP pools hebben meerdere ipv4 en ipv6 adressen door elkaar in zo'n pool. Die ik overigens wel weer apart in de firewall moet openzetten.

Nu is het niet allemaal briljant, ze claimen 'full ipv6' te ondersteunen, maar ik ben bij die loadbalancers al wel een paar dingen tegen gekomen die niet helemaal tof onder ipv6 werken. Ik geloof dat ik zo'n lijst opgestuurd heb dat ze het komende jaar nog wel bezig kunnen zijn met die lijst af te werken

Wij hebben een paar jaar terug onze Brocade loadbalancers vervangen door een linux oplossing vooral omdat de Brocades niet fatsoenlijk IPv6 konden. En bugfixes gingen destijds niet bepaald vlot, zeker niet voor IPv6 issues. Blijkbaar is het nog steeds niet helemaal op orde dus...

[CAPSLOCK2000]

Kees schreef op dinsdag 24 mei 2016 @ 18:27:
Overigens ben ik het niet eens met de stelling dat je voor ipv6 geen NAT doet,

Dat was niet als algemene stelling bedoeld, alleen hoe het bij mij werkt. Ik ben niet principieel tegen NAT en IPv6, ook onder IPv6 zijn er toepassingen voor, NAT is uiteindelijk gewoon gereedschap. We hebben het gelukkig niet meer nodig omdat er te weinig adressen zijn en we NAT nodig hebben om uberhaupt bereikbaar te zijn.

[ik222]

CAPSLOCK2000 schreef op dinsdag 24 mei 2016 @ 23:02:
[...]


Dat was niet als algemene stelling bedoeld, alleen hoe het bij mij werkt. Ik ben niet principieel tegen NAT en IPv6, ook onder IPv6 zijn er toepassingen voor, NAT is uiteindelijk gewoon gereedschap. We hebben het gelukkig niet meer nodig omdat er te weinig adressen zijn en we NAT nodig hebben om uberhaupt bereikbaar te zijn.

Helemaal mee eens. Schitterend inderdaad dat het niet meer nodig is voor het oplossen van een tekort aan adressen. Maar ik snap inderdaad ook niet waarom NAT bij IPv6 door sommige mensen principeel wordt verworpen. Er zijn namelijk inderdaad best situaties waarin het een prima oplossing is.

[Roetzen]

ik222 schreef op dinsdag 24 mei 2016 @ 23:07:
Er zijn namelijk inderdaad best situaties waarin het een prima oplossing is.

Zoals?

[Compizfox]

Kees schreef op dinsdag 24 mei 2016 @ 18:27:
Overigens ben ik het niet eens met de stelling dat je voor ipv6 geen NAT doet, dat doe ik bewust wel tenzij een server extern bereikbaar moet zijn. Voor de rest van de servers houd ik bewust ipv6-NAT aan zodat ze via 1 of 2 ip's naar buiten gaan. Ik moet met een aantal services werken die een ip-whitelist hebben en ik heb geen zin om al mijn servers daarin te zetten.

NAT gebruiken met IPv6 vind ik inderdaad ook IPv4-denken. NAT is een lapmiddel wat gebruikt wordt om IPv4 nog langer te rekken en heeft veel problemen veroorzaakt op het internet. Veel mensen zijn dan ook van mening dat NAT iets inherent slechts is wat nooit uitgevonden had mogen worden (al denk ik er zelf niet zo extreem over, hoor).

Waarom zou je dat gebruiken met IPv6? Je heb adressen zat.

[CAPSLOCK2000]

NAT is meer dan een manier om meerdere computers achter 1 adres te verstoppen.
Je kan het ook gebruiken om de ene poort in de andere om te zetten of het ene adres in het andere te vertalen.

Kees gaf hierboven al een voorbeeld.

Ik heb een applicatie die perse op een bepaalde poort wil zitten, dat is niet te veranderen, maar die poort is niet handig. Een regeltje NAT lost dat probleem op. (Die applicatie is ipv4-only maar dat terzijde).


Ik ben een tijdje geleden van ISP gewisseld. Daardoor kreeg ik ook nieuw adressen en moest ik mijn interne netwerk omnummeren. 1:1 NAT had dat kunnen voorkomen.

[Bigs]

Intern gebruik je gewoon lokale adressen, dan hoef je nooit om te nummeren.

[TD-er]

CAPSLOCK2000 schreef op woensdag 25 mei 2016 @ 01:17:
[...]
Ik heb een applicatie die perse op een bepaalde poort wil zitten, dat is niet te veranderen, maar die poort is niet handig. Een regeltje NAT lost dat probleem op. (Die applicatie is ipv4-only maar dat terzijde).
[...]

Ik snap nog steeds niet waarom een poortnr "niet handig" zou zijn bij IPv6.
Het enige wat je router hoeft te doen, is "alles staat dicht, tenzij je het open zet" en dan zet je dus voor dat (global) IP-adres die ene poort open.
Het is niet zo dat je poortconflicten krijgt, want op de machine waarop dat product draait is het ook geen conflict.

Het enige wat ik zou kunnen voorstellen is wanneer die applicatie alleen op een link-local adres kan binden en niet op zowel local als global.

[ik222]

Bigs schreef op woensdag 25 mei 2016 @ 07:14:
Intern gebruik je gewoon lokale adressen, dan hoef je nooit om te nummeren.

Natuurlijk kan dat maar als elk apparaat meerdere adressen heeft maakt dat beheer ook een stuk complexer, alle apparaten die toch niet extern bereikbaar moeten zijn lokale adressen geven en naar buiten toe NAT gebruiken kan dan in mijn ogen een prima oplossing zijn

[Bigs]

ik222 schreef op woensdag 25 mei 2016 @ 08:55:
[...]

Natuurlijk kan dat maar als elk apparaat meerdere adressen heeft maakt dat beheer ook een stuk complexer, alle apparaten die toch niet extern bereikbaar moeten zijn lokale adressen geven en naar buiten toe NAT gebruiken kan dan in mijn ogen een prima oplossing zijn

Is het niet standaard in IPv6 dat elk apparaat zowel een link-local (fe80::/10) adres als een of meer global unicast adressen heeft?

[Snow_King]

Compizfox schreef op dinsdag 24 mei 2016 @ 23:40:
[...]

NAT gebruiken met IPv6 vind ik inderdaad ook IPv4-denken. NAT is een lapmiddel wat gebruikt wordt om IPv4 nog langer te rekken en heeft veel problemen veroorzaakt op het internet. Veel mensen zijn dan ook van mening dat NAT iets inherent slechts is wat nooit uitgevonden had mogen worden (al denk ik er zelf niet zo extreem over, hoor).

Zo 'extreem' denk ik dus wel over NAT.

Het was een lapmiddel voor IPv4 waar ik bij IPv6 geen enkele noodzaak voor zie. Voor poortjes mappen kan je gewoon transparante proxies gebruiken. Onder Linux kan netcat dat al voor je, maar zo heb je voldoende tools.

In de 8 jaar dat ik inmiddels IPv6 uitrol op grote schaal heb ik de noodzaak voor NAT nog nooit gehad.

[Paul]

TD-er schreef op woensdag 25 mei 2016 @ 07:47:
Ik snap nog steeds niet waarom een poortnr "niet handig" zou zijn bij IPv6.

IPv6 of je router boeit het geen ene ****. De persoon die het moet gebruiken daarentegen...

Zo gebruikt bijna de complete (zakelijke) Trend Micro productfamilie een webinterface om de boel te managen een aantal verschillende poortnummers om die te benaderen, maar ze zijn geen van allen 80 of 443

Was de webproxy nu https://10.11.12.13:8443, of was het 8445? (Hint: Die laatste... 8443 zou te simpel zijn). En de Deep Security Manager, waar zat die ook alweer? Oh ja, poort 4119

[ Voor 15% gewijzigd door Paul op 25-05-2016 09:32 ]

[ANdrode]

Paul schreef op woensdag 25 mei 2016 @ 09:29:
[...]
Zo gebruikt bijna de complete (zakelijke) Trend Micro productfamilie een webinterface om de boel te managen een aantal verschillende poortnummers om die te benaderen, maar ze zijn geen van allen 80 of 443

Was de webproxy nu https://10.11.12.13:8443, of was het 8445? (Hint: Die laatste... 8443 zou te simpel zijn). En de Deep Security Manager, waar zat die ook alweer? Oh ja, poort 4119

Bij Trend Micro was de poort soms de enige beveiliging.

Dus die poort verbergen heeft wel degelijk nut bij die producten .

Maar praktischer:
Het verlaagt de kans op poort conflicten. Die web interfaces hebben meestal geen gereserveerde poorten. Als je daar 8080, 8081, etc... voor gebruikt zitten ze na een tijdje vol.

Dat ken je misschien van een docker host zonder netwerk per logische applicatie.

"Was het nou 8000, 8080, 8081 of 8082...". Dan liever een obscuur nummer per applicatie.

[CAPSLOCK2000]

TD-er schreef op woensdag 25 mei 2016 @ 07:47:
Ik snap nog steeds niet waarom een poortnr "niet handig" zou zijn bij IPv6.

Ik wil niet in gaan op dit specifieke geval, dat gaat over m'n werk.

Maar denk aan een mailserver, die wil je per se op poort 25 hebben, anders maak je het jezelf heel onhandig. Net als DNS, het kan op een andere poort dan 53, maar dat geeft heel veel gedoe.
We hebben een antieke applicatie die oude conventies volgt en dat is realistisch gezien niet te veranderen. NAT is de makkelijke oplossing.

Snow_King schreef op woensdag 25 mei 2016 @ 09:17:
Het was een lapmiddel voor IPv4 waar ik bij IPv6 geen enkele noodzaak voor zie. Voor poortjes mappen kan je gewoon transparante proxies gebruiken. Onder Linux kan netcat dat al voor je, maar zo heb je voldoende tools.

Gereedschap is gereedschap, het heeft geen intrensieke waarde, het gaat er om hoe je het gebruikt. netcat en transparante proxies kunnen een deel van die functionaliteit vervangen maar niet alles. Dat deze tools het ook kunnen bevestigd dat het een legitieme behoefte is. Het voordeel van NAT is dat het in de kernel draait en dus lekker snel is. Andere vormen van pakketjes routeren, manipuleren, filteren etc doe ik ook allemaal in de kernel dus NAT ook. Een poortje vervangen vind ik conceptueel niet zo heel anders als een symlinkje, dat is ook een beetje een hack om dingen onder een andere naam aan te bieden om het leven makkelrijker te maken.

[CyBeR]

CAPSLOCK2000 schreef op woensdag 25 mei 2016 @ 01:17:
Ik heb een applicatie die perse op een bepaalde poort wil zitten, dat is niet te veranderen, maar die poort is niet handig. Een regeltje NAT lost dat probleem op. (Die applicatie is ipv4-only maar dat terzijde).

Dat is PAT.

Ik ben een tijdje geleden van ISP gewisseld. Daardoor kreeg ik ook nieuw adressen en moest ik mijn interne netwerk omnummeren. 1:1 NAT had dat kunnen voorkomen.

Dat is te verhelpen door geen gebruik te maken van IP-adressen maar van DNS. Alternatief idee is dat hiervoor vaak ULA's worden ingezet.

[Roetzen]

CAPSLOCK2000 schreef op woensdag 25 mei 2016 @ 11:47:
[...]

Ik wil niet in gaan op dit specifieke geval, dat gaat over m'n werk.

Maar denk aan een mailserver, die wil je per se op poort 25 hebben, anders maak je het jezelf heel onhandig.

Dat je een mailserver graag op poort 25 wilt hebben snap ik. Het wordt anders voor willekeurige andere mail servers lastig hem te bereiken.Maar wat ik niet snap is dat je om dat voor elkaar te krijgen (met IPv6) NA(P)T nodig hebt. Die mailserver heeft een uniek IPv6 adres. Dan hoeft je toch niet met poorten te gaan goochelen om een pakketje aldaar af te leveren?

Ik sta in het kamp van Snow_King. NAT is IPv4 denken. Zo snel mogelijk vergeten.

[Compizfox]

CAPSLOCK2000 schreef op woensdag 25 mei 2016 @ 01:17:
NAT is meer dan een manier om meerdere computers achter 1 adres te verstoppen.
Je kan het ook gebruiken om de ene poort in de andere om te zetten of het ene adres in het andere te vertalen.

Kees gaf hierboven al een voorbeeld.

Ik heb een applicatie die perse op een bepaalde poort wil zitten, dat is niet te veranderen, maar die poort is niet handig. Een regeltje NAT lost dat probleem op. (Die applicatie is ipv4-only maar dat terzijde).


Ik ben een tijdje geleden van ISP gewisseld. Daardoor kreeg ik ook nieuw adressen en moest ik mijn interne netwerk omnummeren. 1:1 NAT had dat kunnen voorkomen.

Voor het omzetten van poorten heb je geen NAT nodig. Dat kan met een simpele firewallregel. NAT is Network Address Translation, waarmee je dus IP-adressen achter andere IP-adressen kunt verstoppen.

Een simpele firewallrule die verkeer van poort x naar poort y doorstuurt is geen NAT.

Veel mensen (mijzelf een paar jaar geleden inclusief) zitten zo vastgeroest aan NAT dat ze het verschil tussen NAT, firewalling en routing niet weten, en routing of firewalling niet los kunnen zien van NAT, omdat ze het alleen maar icm NAT gebruikt hebben.

[ Voor 11% gewijzigd door Compizfox op 25-05-2016 13:23 ]

[CAPSLOCK2000]

Roetzen schreef op woensdag 25 mei 2016 @ 12:01:
Dat je een mailserver graag op poort 25 wilt hebben snap ik. Het wordt anders voor willekeurige andere mail servers lastig hem te bereiken.Maar wat ik niet snap is dat je om dat voor elkaar te krijgen (met IPv6) NA(P)T nodig hebt. Die mailserver heeft een uniek IPv6 adres. Dan hoeft je toch niet met poorten te gaan goochelen om een pakketje aldaar af te leveren?

Het gaat niet om een mailserver maar om een ander product, maar omdat het iets met mijn werk te maken heeft wil ik dat niet bij naam noemen. Het principe is hetzelfde. De server wil poort X gebruiken. De client wil poort Y gebruiken. De software aanpassen is moeilijk. De poort laten doorsturen is makkelijk.

Ik sta in het kamp van Snow_King. NAT is IPv4 denken. Zo snel mogelijk vergeten.

Sure, ga je gang. Ik weiger geen gereedschap, alles mag in mijn gereedschapskist, ik kies wanneer ik welk gereedschap toepas. In een ideale wereld zou NAT niet bestaan, maar de wereld is niet ideaal. Als professional wil ik opties hebben om uit te kiezen. Soms is NAT het minste kwaad.

[Paul]

Roetzen schreef op woensdag 25 mei 2016 @ 12:01:
Die mailserver heeft een uniek IPv6 adres. Dan hoeft je toch niet met poorten te gaan goochelen om een pakketje aldaar af te leveren?

Een TCP poortnummer bevindt zich op laag 4 van het ISO-model, je IPv4-adres op laag 3. Of je nu TCP aflevert op IPv4, op IPv6, op IPX of op Appletalk DDP (voor zover dat kan op die protocollen ), als je ene pakketje aan wilt passen zodat het niet meer naar poort X gaat maar naar poort Y dan zul je dat op een of andere manier moeten doen...

NAT vertroebelt een beetje want die overkoepelende naam kan pakketjes op meerdere lagen van het OSI-model aanpassen. Dat je het op laag 3 vies vindt sinds IPv6 kan ik me indenken, maar er zijn nog steeds redenen om het op laag 4 te blijven gebruiken.

[CAPSLOCK2000]

Compizfox schreef op woensdag 25 mei 2016 @ 12:55:
Voor het omzetten van poorten heb je geen NAT nodig. Dat kan met een simpele firewallregel. NAT is Network Address Translation, waarmee je dus IP-adressen achter andere IP-adressen kunt verstoppen.

Een simpele firewallrule die verkeer van poort x naar poort y doorstuurt is geen NAT.

Dat is semantiek. Noem het zo je wil. Het effect blijft hetzelfde: je hebt een IP-pakketje en manipuleert de waarde van sommige velden.

Veel mensen (mijzelf een paar jaar geleden inclusief) zitten zo vastgeroest aan NAT dat ze het verschil tussen NAT, firewalling en routing niet weten, en routing of firewalling niet los kunnen zien van NAT, omdat ze het alleen maar icm NAT gebruikt hebben.

Waarvan acte want jij gaat ook de mist in . Als je onderscheid wil maken tussen NAT en de firewall dan moet je ook onderscheid maken tussen PAT en de firewall. Onder Linux (wat de meesten hier denk ik voor ogen hebben) is PAT onderdeel van NAT wat weer onderdeel van de firewall is. Als je dus echt op alle slakken zout wil leggen dan hoort het vervangen van een poort meer bij NAT dan bij de firewall. Maar goed, zo wordt het een vervelende discussie en dat was ook weer niet de bedoeling.

[Roetzen]

CAPSLOCK2000 schreef op woensdag 25 mei 2016 @ 13:48:
[...]

Het gaat niet om een mailserver maar om een ander product, maar omdat het iets met mijn werk te maken heeft wil ik dat niet bij naam noemen. Het principe is hetzelfde. De server wil poort X gebruiken. De client wil poort Y gebruiken. De software aanpassen is moeilijk. De poort laten doorsturen is makkelijk.

Maar dan heb je een client die niet gemaakt is voor die server. Dat lijkt me eerder een kwestie van een verkeerde keuze. Maar ja, ik ken helaas het verschijnsel van opgescheept zijn met de gevolgen van verkeerde keuzes in het verleden en het ontbreken van "politieke moed" van het management om te "beter ten halve gekeerd dan ten hele gedwaald" in de praktijk te brengen.

Sure, ga je gang. Ik weiger geen gereedschap, alles mag in mijn gereedschapskist, ik kies wanneer ik welk gereedschap toepas.

Ik zorg er voor dat mijn gereedschapskist niet te vol wordt. Om ruimte te maken voor nieuw en beter gereedschap gooi ik er wel eens iets wat oud en nog zelden gebruikt wordt uit.

In een ideale wereld zou NAT niet bestaan, maar de wereld is niet ideaal.

Een IPv6 only omgeving zou een wereld zonder NAT kunnen zijn.

Als professional wil ik opties hebben om uit te kiezen. Soms is NAT het minste kwaad.

In de IPv4 wereld. Maar ik ben nog steeds niet overtuigd dat het met IPv6 ook zo is. Je voorbeeld van de server die poort X en de client die poort Y wil, overtuigt me niet, want je stelt zelf al dat dat een IPv4 only ding is. Dus die gaat er toch een keer uit en bij de volgende zorg je er dan wel voor dat je een server en een client bij elkaar zoekt waar dat probleem niet speelt.

Overigens hebben degenen die opmerkten dat het dan om het vertalen van poortnummers en niet om het vertalen van adressen gaat natuurlijk gelijk. Het is geen NAT, maar PAT.

Paul schreef op woensdag 25 mei 2016 @ 13:50:
[...]
NAT vertroebelt een beetje want die overkoepelende naam kan pakketjes op meerdere lagen van het OSI-model aanpassen.

Het wordt dan ook vaak NAPT genoemd.

Dat je het op laag 3 vies vindt sinds IPv6 kan ik me indenken, maar er zijn nog steeds redenen om het op laag 4 te blijven gebruiken.

Noem er dan eens één. Om meerdere servers die één globaal adres delen uit elkaar te houden zit er vaak niets anders op dan met poortnummers te gaan rommelen. Maar met IPv6 kun je iedere server een eigen uniek adres geven, dus waarom dan nog rommelen met poortnummers?

Als ik iets over het hoofd zie hoor ik het graag.

[ Voor 15% gewijzigd door Roetzen op 25-05-2016 16:33 ]

[Paul]

Roetzen schreef op woensdag 25 mei 2016 @ 16:23:
Noem er dan eens één.

Nóg één? Of überhuapt één? Want er is toch al een aantal keer de applicatie-die-op-de-verkeerde-poort-luistert genoemd? Wat overigens wel meteen de enige is die ik zo snel kan verzinnen, daar niet van...

Qua niet gebruiken van NAT op laag 3, hoe doe je dat met multi-WAN-opstellingen? Hoe ga je asymetrische routering dan tegen?

[CAPSLOCK2000]

Roetzen schreef op woensdag 25 mei 2016 @ 16:23:
Maar dan heb je een client die niet gemaakt is voor die server. Dat lijkt me eerder een kwestie van een verkeerde keuze. Maar ja, ik ken helaas het verschijnsel van opgescheept zijn met de gevolgen van verkeerde keuzes in het verleden en het ontbreken van "politieke moed" van het management om te "beter ten halve gekeerd dan ten hele gedwaald" in de praktijk te brengen.

Klopt helemaal, ik zal met de situatie moeten omgaan.

Ik zorg er voor dat mijn gereedschapskist niet te vol wordt. Om ruimte te maken voor nieuw en beter gereedchap gooi ik er wel eens iets wat oud en nog zelden gebruikt wordt uit.

Het fijne van een digitale gereedschapskist is dat er veel ruimte is.

Een IPv6 only omgeving zou een wereld zonder NAT kunnen zijn.

Eeen IPv4 only omgeving zou ook een wereld zonder NAT kunnen zijn, je moet er alleen wat voor opgeven, net als bij IPv6, het is maar de vraag wat de minst gore oplossing is.

In de IPv4 wereld. Maar ik ben nog steeds niet overtuigd dat het met IPv6 ook zo is. Je voorbeeld van de server die poort X en de client die poort Y wil, overtuigt me niet, want je stelt zelf al dat dat een IPv4 only ding is. Dus die gaat er toch een keer uit en bij de volgende zorg je er dan wel voor dat je een server en een client bij elkaar zoekt waar dat probleem niet speelt.

Het is een kwestie van tijd voor ik weer in een situatie kom die moervast zit en waar toch een oplossing moet komen. Als ik alles in m'n eentje mocht beslissen zag de wereld er heel anders uit

Als het nodig is kan ik ieder bit op de hardeschijven van mijn systemen veranderen. Niet dat ik dat vaak doe, maar als het nodig is dan kan het. Over netwerkpakketjes denk ik hetzelfde. Zodra ze op mijn systeem zijn aangekomen mag/kan ik er alles mee doen. Als professioneel beheerder wil ik de mogelijkheid hebben om ook daar iedere bit te veranderen die ik wil. Het is aan mij om er verstandig mee om te gaan.

[databeestje]

Paul schreef op woensdag 25 mei 2016 @ 17:05:
[...]
Nóg één? Of überhuapt één? Want er is toch al een aantal keer de applicatie-die-op-de-verkeerde-poort-luistert genoemd? Wat overigens wel meteen de enige is die ik zo snel kan verzinnen, daar niet van...

Qua niet gebruiken van NAT op laag 3, hoe doe je dat met multi-WAN-opstellingen? Hoe ga je asymetrische routering dan tegen?

De enige geldige NAT in combinatie met IPv6 is naar mijn mening NPt die 1:1 prefixes vertaald, dat is wel redelijk transparant te ontcijferen en een noodzakelijk kwaad voor multiwan opstellingen zonder in een of ander LISP thesis project te belanden welke niet praktisch in gebruik is.

Het antwoord "gebruik BGP" is wat ik geef aan bedrijven, maar voor mensen thuis met een 3G stick als backup of iets in die trend is mijn inziens een valide oplossing.

[Roetzen]

databeestje schreef op woensdag 25 mei 2016 @ 20:04:
Het antwoord "gebruik BGP" is wat ik geef aan bedrijven, maar voor mensen thuis met een 3G stick als backup of iets in die trend is mijn inziens een valide oplossing.

BGP en PIR is inderdaad het antwoord dat ik ook zou geven aan de grote jongens. "Zou" want ik ben al lang pensionado en niemand betaalt mij nog om mijn advies te horen.

Ik ben dus nu een van "de mensen thuis". En het toeval wil dat ik voor IPv6 inderdaad dual homed ben. Niet met een 3G stickje, maar met twee tunnels. Eén van SixXs en één van he.net. De machine waarop mijn servers draaien heeft een IPv6 adres van he.net en een IPv6 adres van SixXs. Niks NAT, gewoon twee adressen, één voor ieder "kanaal".

Paul schreef op woensdag 25 mei 2016 @ 17:05:
[...]
Nóg één? Of überhuapt één? Want er is toch al een aantal keer de applicatie-die-op-de-verkeerde-poort-luistert genoemd? Wat overigens wel meteen de enige is die ik zo snel kan verzinnen, daar niet van...

Zoals ik al aangaf, ik vind dat ene voorbeeld niet overtuigend. Het is het gevolg van een verkeerde keuze van de applicatie. Die fout zal hopelijk niet nog een keer gemaakt worden,

Qua niet gebruiken van NAT op laag 3, hoe doe je dat met multi-WAN-opstellingen? Hoe ga je asymetrische routering dan tegen?

Zie boven: BGP en PIR voor de grote jongens, meerdere adressen per server voor "de mensen thuis".

CAPSLOCK2000 schreef op woensdag 25 mei 2016 @ 18:15:

Een IPv4 only omgeving zou ook een wereld zonder NAT kunnen zijn, je moet er alleen wat voor opgeven, net als bij IPv6, het is maar de vraag wat de minst gore oplossing is.

Bij IPv4 is NAT inmiddels al meer dan een decennium breed ingeburgerd om het gebrek aan IP adressen te ondervangen. Tijdmachines zijn nog niet uitgevonden en dus is het terugdraaien daarvan is vooralsnog niet mogelijk. Als het voor IPv4 niet uitgevonden was vanwege het tekort aan adressen, hadden we het helemaal niet gehad en hadden we andere oplossingen gevonden voor de problemen waarvoor we nu menen dat het voor iPv6 ingezet kan worden. Maar die andere oplossingen zoeken voor problemen die niet gerelateerd zijn aan een tekort aan adressen, dat kan natuurlijk nog steeds.

Als ik alles in m'n eentje mocht beslissen zag de wereld er heel anders uit

Je bent niet de enige die dat wel eens denkt.

[ Voor 56% gewijzigd door Roetzen op 26-05-2016 01:21 ]

[Compizfox]

CAPSLOCK2000 schreef op woensdag 25 mei 2016 @ 13:54:
[...]

Dat is semantiek. Noem het zo je wil. Het effect blijft hetzelfde: je hebt een IP-pakketje en manipuleert de waarde van sommige velden.

Het is inderdaad semantiek. We hebben allebei gelijk, maar jij hanteert een andere definitie van NAT dan ik.

[...]

Waarvan acte want jij gaat ook de mist in . Als je onderscheid wil maken tussen NAT en de firewall dan moet je ook onderscheid maken tussen PAT en de firewall. Onder Linux (wat de meesten hier denk ik voor ogen hebben) is PAT onderdeel van NAT wat weer onderdeel van de firewall is. Als je dus echt op alle slakken zout wil leggen dan hoort het vervangen van een poort meer bij NAT dan bij de firewall. Maar goed, zo wordt het een vervelende discussie en dat was ook weer niet de bedoeling.

Nou moet ik eerlijk toegeven dat ik nog nooit van PAT heb gehoord. Ik kan je verhaal dan ook niet helemaal volgen.

Ik weet dat in Linux NAT onderdeel is van de firewall (netfilter/iptables), maar mijn punt was meer dat sommigen helemaal niet weten dat er ook iets is als routing zonder NAT. Misschien niet zo vreemd, want dat is ook de enige setup die mensen in een thuis-/MKB-omgeving met IPv4 tegenkomen. Zoals ik al zei ben ik daar vroeger ook zelf schuldig aan geweest

[CAPSLOCK2000]

Meerdere adressen per machine heb ik ook een tijdje gedaan. Op een gegeven moment had ik sixxs, he, xs4all, een tunnel via m'n werk en een tunnel via een vps lopen, een 6to4 en ook nog site-local (en dan nog ipv4).

Even was dat leuk, tot ik een meter perl nodig had om m'n dns zone-files en firewalls te genereren en ik genoeg had van tientallen configuratiefiles aanpassen als er weer eens iets aan m'n netwerk veranderde.

Nu zal ik niet ontkennen dat ik soms wat moeite heb met maat houden en dat het met 2 ip-ranges wellicht minder pijnlijk was geweest, maar toen ben ik toch een beetje afgestapt van het idee om m'n hele netwerk multi-homed te maken.

Voor mij thuisnetwerk is BGP niet echt een optie, al is het maar omdat ik als consument niet zomaar een ip-range kan kopen. Daar is op zich nog wel een mouw aan te passen. Ik huur een vm'tje met daarbij een ipv6-range. Een blokje daaruit tunnel ik door naar mij thuis. Maar ja, eigenlijk is dat het probleem verplaatsen, niet oplossen. Eigenlijk wat sixxs & he doen maar dan onder eigen beheer.

[Paul]

Roetzen schreef op donderdag 26 mei 2016 @ 00:54:
Niks NAT, gewoon twee adressen, één voor ieder "kanaal".

Dat is leuk voor verkeer dat van buitenaf komt, maar je zit natuurlijk ook nog met het verkeer dat je zelf genereert.

Als ik het zo hoor gebruik je dan dus eigenlijk maar één van de internetverbindingen, of je moet per PC gaan zitten pielen met de instellingen om te zorgen dat je op de ene PC het internet op gaat via SixXs en op de andere met he.net, in plaats van dat je router dat intelligent kan regelen?

Zoals ik al aangaf, ik vind dat ene voorbeeld niet overtuigend. Het is het gevolg van een verkeerde keuze van de applicatie. Die fout zal hopelijk niet nog een keer gemaakt worden,

Dus jouw oplossing is om die hele applicatie dan maar niet te gebruiken of zo? Is je goed recht, maar we hebben die applicatie natuurlijk niet voor niks

[Dutch2007]

Google Public DNS64 --> https://developers.google...s/docs/dns64#introduction

IPv6 excuse bingo: http://ipv6bingo.com/

[ Voor 18% gewijzigd door Dutch2007 op 26-05-2016 12:20 ]

[CAPSLOCK2000]

Dutch2007 schreef op donderdag 26 mei 2016 @ 12:16:
IPv6 excuse bingo: http://ipv6bingo.com/

"IPV6 can't do NAT" mag daar aan worden toegevoegd

[Verwijderd]

Zometeen op RIPE72
https://ripe72.ripe.net/programme/meeting-plan/ipv6-wg/

Recent:
https://code.facebook.com...ing-scale-may-2016-recap/
Bij "Day 2"

[Jerrythafast]

Roetzen schreef op zaterdag 20 februari 2016 @ 12:31:
[...]

Is je IPv6 adres stabiel? Het is al die tijd hetzelfde gebleven?

Vandaag mijn Ubee321b herstart omdat de WiFi instabiel was (symptomen waren exact gelijk aan die van de TC7210 WiFi-bug, namelijk wel bereik en connectie maar verkeer komt niet meer aan op de bestemming). En na de herstart is mijn IPv6 prefix, die ik al had sinds 7 februari, veranderd Is dus ruim 3,5 maanden hetzelfde gebleven.

IPv4 adres is nog dezelfde.

[Roetzen]

CAPSLOCK2000 schreef op donderdag 26 mei 2016 @ 01:51:
Meerdere adressen per machine heb ik ook een tijdje gedaan. Op een gegeven moment had ik sixxs, he, xs4all, een tunnel via m'n werk en een tunnel via een vps lopen, een 6to4 en ook nog site-local (en dan nog ipv4).

Even was dat leuk, tot ik een meter perl nodig had om m'n dns zone-files en firewalls te genereren en ik genoeg had van tientallen configuratiefiles aanpassen als er weer eens iets aan m'n netwerk veranderde.

Nu zal ik niet ontkennen dat ik soms wat moeite heb met maat houden en dat het met 2 ip-ranges wellicht minder pijnlijk was geweest, maar toen ben ik toch een beetje afgestapt van het idee om m'n hele netwerk multi-homed te maken.

Ach, het is een interessant experiment. Maar net als bij mij is het natuurlijk alleen virtuele multi-homing. Het gaat bij mij allemaal over het groene kabeltje van Ziggo en als een graafmachine het kabeltje kapot trekt is alles weg. Dat gebeurde verleden jaar met de renovatie van de straat. Het duurde een paar uur voordat het hersteld was. Daar kan ik wel mee leven. Ik heb de eerste 55+ jaar van mijn leven zonder internet geleefd.Als het nog eens een paar uur uitvalt, overleef ik het ook wel.

Ik heb een kennis die wel echte multi-homing heeft . Hij heeft DSL van Xs4All en kabel van ZIggo. Voor IPv4 gebruikt hij uiteraard NAT. Voor IPv6 is ie nog niet multi-homed, want alleen X44All levert hem native IPv6. Maar hij is al heel hard aan het nadenken hopen hij dat gaat aanpakken als het zo ver is.

Ik zelf hoef dat niet zo nodig. Als ik een ISP heb die mij stabiel native IPv6 levert, gaan de tunneltjes er uit en doe ik het wel met een enkelvoudige aansluiting. Dat met die twee tunneltjes is een experiment. Dat overuigens goed werkte toen de SixXs tunnel er een paar dagen uit lag. Ik had nog steeds IPv6 via he.net. Zowel inkomend als uitgaand.

Voor mij thuisnetwerk is BGP niet echt een optie, al is het maar omdat ik als consument niet zomaar een ip-range kan kopen.

Ik heb me er nog niet in verdiept hoe en wie er een PIR kan krijgen. Ik vermoed dat je een eigen ASN moet hebben. Als het al zou kunnen voor een particulier, denk ik toch niet dat ik er op mijn oude dag nog aan ga beginnen.

Maar voor een bedrijf ligt dat anders. Een andere kennis van mij is systeembeheerder bij een niet al te groot bedrijf en die is ook aan het uitpuzzelen hoe hij met multi-homing moet omgaan.

Paul schreef op donderdag 26 mei 2016 @ 08:17:
[...]
Dat is leuk voor verkeer dat van buitenaf komt, maar je zit natuurlijk ook nog met het verkeer dat je zelf genereert. Als ik het zo hoor gebruik je dan dus eigenlijk maar één van de internetverbindingen,

Klopt, maar dat is in mijn geval niet zo'n punt. Het gaat mij niet om load balancing, het doel van het experiment was om te zien hoe ik fall back kon bereiken. En in dat opzicht voldoet het. Als één van de twee tunnels uitvalt, gaat het probleemloos verder zonder dat ik in hoeft te grijpen over het andere.

[...]
Dus jouw oplossing is om die hele applicatie dan maar niet te gebruiken of zo? Is je goed recht, maar we hebben die applicatie natuurlijk niet voor niks

"we"? Zit jij bij dezelfde toko als Caps?

Caps gaf zelf al aan dat het aan antieke IPv4 only applicatie was. Dat NAPT voor IPv4 een noodzakelijk kwaad is, staat niet ter discussie, Maar we hebben het hier over IPv6. En met een antieke IPv4 only applicatie op de proppen komen om IPv6 NAT te rechtvaardigen vind ik nou niet zo'n strerke redenering.

Die antieke applicatie hoeft dan misschien niet vandaag weg, maar als ie IPv4 only is, dan zijn de dagen hoe dan ook geteld. Zoals ik al eerder opmerkte, er is bij de aanschaf van die applicatie een foute keuze gemaakt, De client en de server pasten niet bij elkaar. Die fout zal toch hopelijk niet herhaald worden als de opvolger, die dan uiteraard wel IPv6 kan, in beeld komt?

[ Voor 23% gewijzigd door Roetzen op 26-05-2016 22:55 ]

[Paul]

Roetzen schreef op donderdag 26 mei 2016 @ 22:39:
"we"? Zit jij bij dezelfde toko als Caps?

Nope, maar Caps is natuurlijk niet de enige die met applicaties zit die zich niet netjes gedragen (of zich op zich wel netjes gedragen maar om legitieme reden niet op het gewenste poortnummer kunnen of willen binden), en die zullen vast ook niet allemaal antiek of IPv4-only zijn

[Roetzen]

Paul schreef op vrijdag 27 mei 2016 @ 10:01:
[...]
en die zullen vast ook niet allemaal antiek of IPv4-only zijn

Dat is een veronderstelling die ik toch graag met een concreet voorbeeld onderbouwd zou willen zien voordat ik mee ga lopen met de ezels die zich tig keer aan dezelfde steen stoten.

[Paul]

Paul in "Het grote IPv6 topic" Trend Micro dus bijvoorbeeld.

[Snow_King]

Nieuwe Ziggo verbinding in Amersfoort online met een TC7210, maar geen IPv6

In het modem ook niets van IPv6 te bespeuren, alles is IPv4-only.

Software versie op het modem is STF0.76.09

[Roetzen]

Paul schreef op vrijdag 27 mei 2016 @ 11:34:
Paul in "Het grote IPv6 topic" Trend Micro dus bijvoorbeeld.

Dat is al gedebunked door ANdrode:

http://gatherin.tweakers....message/46957983#46957983

Snow_King schreef op vrijdag 27 mei 2016 @ 12:29:
Nieuwe Ziggo verbinding in Amersfoort online met een TC7210, maar geen IPv6

Dat is balen. Maar het bevestigt weer dat Ziggo momenteel alleen met de UBee 321b IPv6 ondersteunt.

[ Voor 32% gewijzigd door Roetzen op 27-05-2016 13:01 ]

[Paul]

Roetzen schreef op vrijdag 27 mei 2016 @ 12:59:
Dat is al gedebunked door ANdrode:

http://gatherin.tweakers....message/46957983#46957983

Debunked? Dan moet je die post misschien nog een keer lezen... Of beter uitleggen wat je bedoelt, want het (bijvoorbeeld DSM) draait hier toch echt af fabriek (en volgens mij, maar ik heb er niet bijzonder veel tijd in gestoken, ook niet aan te passen) op 4119 ipv 80...

[Roetzen]

Het is geen gevalletje "de server wil poort X en de client wil poort Y". Dat dat webinterface niet op poort 80 staat, is geen enkel probleem. Elke fatsoenlijke webbrowser kan met niet standaard poortnummers overweg. Ik zie geen noodzaak tot NAT of PAT.

[Paul]

Zeg, de techniek is er toch om de mens te helpen, of was het andersom? De client (lees: de eindgebruiker) wil helemaal niet na hoeven denken over op elke poort dienst X nu weer draait.

[Roetzen]

Daarom hebben webbrouwsers hulpmiddelen om een url die lastig te onthouden is, terug te vinden. Ze noemen dat bladwijzers, bookmarks of zo. Daar kun je zo wel de hostnaam als het poortnummer in kwijt.

[Paul]

Dat werkt ook zo geweldig als je achter een andere computer gaat zitten. Maar dan nog: Je vroeg om een applicatie die op de verkeerde poort luistert en die heb ik een (of een aantal, als je de diverse producten van Trend apart beschouwd) genoemd.

Als je dat niet voldoende vindt, tja, dan doe je het toch op de moeilijke manier? Nu doe ik dat in dit specifieke geval ook omdat er maar een klein handje beheerders naar die website toe hoeven, maar ik blijf erbij dat NAT een stuk gereedschap is. En net zoals je met een schroevendraaier spijkers in de muur kunt slaan en je met een zaag kabels kunt strippen, kun je met NAT ook van alles wat je er eigenlijk niet mee zou moeten doen. Dat maakt NAT an sich nog niet iets slechts...

[zx9r_mario]

CAPSLOCK2000 schreef op donderdag 26 mei 2016 @ 01:51:
Ik huur een vm'tje met daarbij een ipv6-range. Een blokje daaruit tunnel ik door naar mij thuis. Maar ja, eigenlijk is dat het probleem verplaatsen, niet oplossen. Eigenlijk wat sixxs & he doen maar dan onder eigen beheer.

Hoe heb je dat precies aangepakt? Zit nu ook bij Sixxs maar ik las dat die gaan stoppen cq afbouwen.

[Roetzen]

Paul schreef op vrijdag 27 mei 2016 @ 14:07:
Dat werkt ook zo geweldig als je achter een andere computer gaat zitten. Maar dan nog: Je vroeg om een applicatie die op de verkeerde poort luistert en die heb ik een (of een aantal, als je de diverse producten van Trend apart beschouwd) genoemd.

De applicatie luistert op de poort zoals door de ontwerper bedoeld. Dat is dus niet de verkeerde poort. En er is natuurlijk een reden voor de ontwerper om niet de standaardpoort te gebruiken. Jij vindt dat onhandig, maar dat is een mening geen objectief feit. Het admin interface van mijn webserver gebruikt ook een andere poort dan poort 80. Ik weet niet uit mijn hoofd welke, maar dat geeft niet, ik klik gewoon op het betreffende icoontje. Dat het daardoor lastiger wordt het admin interface vanaf een andere computer te benaderen vind ik helemaal niet erg. In tegendeel. Van buitenaf het LAN benaderen gaat al helemaal niet, want de firewall laat die niet standaard poort niet door. Prima! Als ik er zelf niet bij kan van buiten af, kan een ander het ook niet.

Ik ken de redenen van Trend Micro om niet de standaard port 80 te gebruiken niet. Ik ken het product niet. Maar misschien is het net als bij mij wel een extra slotje om te voorkomen dat iemand er van buiten af bij kan. Als jij dat slotje er af wilt halen middels NAPT omdat je dat zo lekker makkelijk vindt, is dat jouw keuze natuurlijk.

Als je dat niet voldoende vindt, tja, dan doe je het toch op de moeilijke manier? Nu doe ik dat in dit specifieke geval ook omdat er maar een klein handje beheerders naar die website toe hoeven, maar ik blijf erbij dat NAT een stuk gereedschap is. En net zoals je met een schroevendraaier spijkers in de muur kunt slaan en je met een zaag kabels kunt strippen, kun je met NAT ook van alles wat je er eigenlijk niet mee zou moeten doen. Dat maakt NAT an sich nog niet iets slechts...

Sommige gereedschappen heb ik liever niet in mijn gereedschapskist. Omdat je er alleen maar dingen mee kunt doen, die je eigenlijk helemaal niet zou moeten doen. Ja, met een pistool kun je ook spijkers in de muur slaan. Maar ik wil geen pistool in mijn gereedschapskist. Veel te grote kans op ongelukken. Ik reken NAT voor IPv6 ook onder de gereedschappen die ik niet in de gereedschapskist wil hebben.

We dwalen trouwens weer aardig af, want het ging in eerste instantie om NAT, maar de voorbeelden waarmee je komt, gaan niet over NAT, maar over PAT. En dat is zoals opgemerkt niet hetzelfde.

[Orion84]

Snow_King schreef op vrijdag 27 mei 2016 @ 12:29:
Nieuwe Ziggo verbinding in Amersfoort online met een TC7210, maar geen IPv6

In het modem ook niets van IPv6 te bespeuren, alles is IPv4-only.

Software versie op het modem is STF0.76.09

Hier sinds vandaag ook naar een TC7210, ter vervanging van de Ubee 321b. Helaas nu dus geen IPv6 meer, maar even mijn router weer instellen voor gebruik van de sixxs tunnel.

[Paul]

Roetzen schreef op vrijdag 27 mei 2016 @ 14:49:
De applicatie luistert op de poort zoals door de ontwerper bedoeld.

Ja dahag Ooit gehoord van RFC's? Ik hou er mee op.

[Roetzen]

zx9r_mario schreef op vrijdag 27 mei 2016 @ 14:34:
Zit nu ook bij Sixxs maar ik las dat die gaan stoppen cq afbouwen.

Jeroen vond dat het veel te lang duurde allemaal. En terecht. En dus heeft ie om druk uit te oefenen een tunnelstop ingesteld. Of dat permanent of tijdelijk is, is niet duidelijk. Of het iets uithaalt moeten we ook maar afwachten. Hij heeft in elk geval niet gezegd dat SixXs gaat stoppen of afbouwen. Het zou natuurlijk wel kunnen dat hij vandaag of morgen de handdoek in de ring gooit. Maar voorlopig is daar nog geen sprake van.

[CAPSLOCK2000]

Roetzen schreef op vrijdag 27 mei 2016 @ 13:29:
Het is geen gevalletje "de server wil poort X en de client wil poort Y". Dat dat webinterface niet op poort 80 staat, is geen enkel probleem. Elke fatsoenlijke webbrowser kan met niet standaard poortnummers overweg. Ik zie geen noodzaak tot NAT of PAT.

Elke fatsoenlijke applicatie kan dat, maar we hebben helaas ook applicaties die niet fatsoenlijk zijn. Wij willen er ook van af maar dat lukt zo maar niet. Als jij nu met 50 miljoen euro over de tafel komt dan kunnen we nog een keer praten over wat we nog kunnen doen om het nog sneller te laten gaan. De voorbeelden die hier genoemd worden zijn allemaal niet goed genoeg voor je. Sorry, ik kan het ook niet mooier maken.

NAT is geen ideaal gereedschap maar het is echt niet lelijker dan de hex-editor die ik ook wel eens inzet om gedaan te krijgen wat nodig is.

[Roetzen]

Helaas, ik heb geen 50 M€ achter de hand. De aangedragen voorbeelden overtuigen mij inderdaad niet van de noodzaak of wenselijkheid van NAT bij IPv6. (Wat dus - ik zeg het nog maar even - niet hetzelfde is als PAT)

We gaan het niet eens worden. Dus zullen we dan maar afsluiten met "we agree to disagree"?

[ Voor 5% gewijzigd door Roetzen op 27-05-2016 15:50 ]

[Snow_King]

Orion84 schreef op vrijdag 27 mei 2016 @ 14:49:
[...]

Hier sinds vandaag ook naar een TC7210, ter vervanging van de Ubee 321b. Helaas nu dus geen IPv6 meer, maar even mijn router weer instellen voor gebruik van de sixxs tunnel.

Mja, gewoon jammer. Had er wel de hoop op bij een nieuwe verbinding.

[zx9r_mario]

@capslock2000 Hoe tunnel je een ipv6 blokje van je vps naar je home netwerk?

[CAPSLOCK2000]

Ik ben onderwerg dus ik jat even iemand anders z'n voorbeeld:

# modprobe ipv6
# ip tu ad sittun mode sit local 10.7.7.7 remote 10.8.8.8 ttl 64 dev eth0
# ip ad ad dev sittun 2001:0DB8:1234::000e/127
# ip li se dev sittun up
# ip -6 ro ad 2001:0DB8:5678::/48 via 2001:0DB8:1234::000f
# ip -6 ro ad 2001:0DB8:5679::/48 via 2001:0DB8:1234::000f
# ip -6 ro ad 2001:0DB8:567a::/48 via 2001:0DB8:1234::000f

van http://www.linuxfoundatio...oups/networking/tunneling

Je maakt eerst een SIT tunnel aan over IPv4 (van 10.7.7.7 naar 10.8.8.8) en hangt daar een IPv6-adres aan (2001:0DB8:1234::000e). De andere kant doet hetzelfde maar uiteraard met een ander adres (2001:0DB8:1234::000f). Vervolgens kun je ip-ranges over die tunnel heen routeren.

Aan de andere kant laat je IPv6 default-route via die tunnel lopen.

ip -6 ro ad add via 2001:0DB8:1234::000e

Bovenstaande is allemaal niet gecontroleerd maar geeft het idee denk ik wel prima.

[kabski]

Het lijkt mij leuk om ook zo'n tunnel in eigen beheer te maken via een VPS. Probleem is dat ik alleen VPS-providers kan vinden die losse IPv6-adressen aanbieden of hooguit een enkele /64. Maar om een /64 naar het thuisnetwerk te kunnen tunnelen moet je op de VPS meerdere /64's hebben of een groter blok.

Waar kun je meer dan een enkele /64 krijgen op een VPS?

[eymey]

Bij Transip heb ik een /48....

edit: Fout, het subnet is wel /48, maar hierbinnen kan ik alleen individuele adressen kiezen uit een /64 .....

[ Voor 66% gewijzigd door eymey op 30-05-2016 18:55 ]

[Roetzen]

Dat is dan geen beperking opgelegd door Transip, maar een beperking van je router.

[eymey]

Dat zou je normaal wel zeggen ja, behalve dat het in dit geval een VPS betreft (en ik daar voor zover ik weet zelf geen router heb ) en het beheerpaneel bij de VPS het al op deze manier doet.

[CAPSLOCK2000]

Sorry, ik kan je niet helpen, de leveranciers van de vms/ips die ik gebruik zijn niet-commercieel.

Owja, hierboven heb ik een algemene configuratie gepost die het op iedere Linux zou moeten doen. Distributies zoals Debian hebben echter hun eigen systeem om netwerken te configureren die misschien wat vriendelijker zijn, zie bv onderstaande voor Debian.

auto 6in4
iface 6in4 inet6 v4tunnel
  address [Your IPv6 Endpoint]
  netmask [Prefix Length]
  endpoint [PoP IPv4 Endpoint]
  gateway [PoP IPv6 Endpoint]

Je kan ook zelf een 6to4-server opzetten, daar heb je geen eigen ip-blok voor nodig. 6to4 is misschien niet de mooiste oplossing maar het is wel leuk en leerzaam om het op te zetten en om die reden alleen al de moeite waard.

Je zou ook een subnet kleiner dan /64 kunnen gebruiken. In een /96 kun je nog altijd 4 miljard computers kwijt, dat moet voldoende zijn. Er is wel een conventie dat je niet kleiner gaat dan /64 maar dat is niet meer dan een conventie, eigenlijk alles werkt ook wel op kleinere subnetten.
Autoconfiguratie is de enige uitzondering die ik ken maar dat is geen essentiele feature, je kan zoder.

[Compizfox]

Compizfox schreef op maandag 23 mei 2016 @ 00:07:
[...]

Ik las dat ik in plaats van de MTU omlaag schroeven op alle devices in m'n netwerk ook MSS clamping kan toepassen.

Mijn vraag is echter welke waarde ik daar dan moet invullen. Mijn tunnel heeft een MTU van 1280 (kan eventueel omhoog tot 1480, weet niet of dat handig is?) en dat staat dan ook ingesteld als MTU in de tunnel-interface op mijn router.

Ik het vakje ernaast kan ik een MSS opgeven voor MSS clamping. Moet ik daar ook gewoon 1280 invullen? Of moet ik daar nog een bepaald getal van aftrekken ivm 6in4 overhead?

Kickje. Iemand?

Voor de context: dit gaat dus over het probleem dat ik sommige websites (die zo incompetent zijn om ICMPv6 te blocken) niet kan bereiken, zoals Tumblr.

[CAPSLOCK2000]

Roetzen schreef op maandag 30 mei 2016 @ 19:10:
Dat is dan geen beperking opgelegd door Transip, maar een beperking van je router.

Voor zover ik weet zit het "probleem" toch echt bij TransIP. TransIP heeft al z'n klanten in dezelfde /48 gestopt en verkondigt dit ook via router advertisments. Het voordeel voor transip is denk ik dat iedereen dezelfde gateway gebruikt ipv dat de router in ieder netwerkje moet zitten.

[Roetzen]

CAPSLOCK2000 schreef op maandag 30 mei 2016 @ 19:36:
Voor zover ik weet zit het "probleem" toch echt bij TransIP. TransIP heeft al z'n klanten in dezelfde /48 gestopt

Ah, dat had ik niet begrepen. Ik ging er van uit dat er per klant een /48 beschikbaar was.

[kabski]

Je hebt gelijk dat het qua aantal IP's al gauw genoeg is met minder dan een /64 (bijvoorbeeld /96), maar IPv6 wordt in de praktijk heel lastig als je met kleinere subnetten gaat werken. Het werkt dan gewoon niet lekker meer.

Voorbeeld, als je de /64 die je van TransIP krijgt zelf gaat opdelen in meerdere /96's, dan krijg je problemen die vergelijkbaar zijn met het opdelen van een IPv4 /24 in meerdere /28's terwijl de andere kant denkt dat het een /24 is. Met hacks als proxy ARP lukt dat wel, maar voor het IPv6 equivalent daarvan (Neighbor Discovery) is geen proxy in bijvoorbeeld pfSense.

Als je het aan de VPS kant al werkend krijgt dan kun je aan de thuiskant geen SLAAC meer gebruiken (dan valt heel IPv6 voor Android al af), CPE routers zoals die van Apple verwachten een /64, etc., etc.

De problemen zijn allemaal eenvoudig op te lossen als je ieder VLAN een hele /64 kan geven. Dat kan als de VPS bijvoorbeeld een echte /48 of /56 heeft, maar die heb ik nog niet kunnen vinden.

[Jerrythafast]

Compizfox schreef op maandag 30 mei 2016 @ 19:19:
[...]

Kickje. Iemand?

Voor de context: dit gaat dus over het probleem dat ik sommige websites (die zo incompetent zijn om ICMPv6 te blocken) niet kan bereiken, zoals Tumblr.

Jij bent het perfecte proefkonijn voor mij Kan jij http://ipv6.jerweb.nl bereiken? Draait hier vanachter mijn Ziggo modemroutertje (Ubee 321b) op een native dual stack verbinding. Als ik hiervandaan naar http://ipv6-test.com/ surf krijg ik te lezen dat ICMPv6 wordt gefilterd (met default settings in mijn modem). Ik heb er zelf nog totaal geen last van gehad (of niet gemerkt in ieder geval) maar misschien dat het voor mensen zoals jij dus wel een probleem is dat mijn webservertje achter dit modem zit.

[Compizfox]

Jerrythafast schreef op maandag 30 mei 2016 @ 21:57:
[...]

Jij bent het perfecte proefkonijn voor mij Kan jij http://ipv6.jerweb.nl bereiken? Draait hier vanachter mijn Ziggo modemroutertje (Ubee 321b) op een native dual stack verbinding. Als ik hiervandaan naar http://ipv6-test.com/ surf krijg ik te lezen dat ICMPv6 wordt gefilterd (met default settings in mijn modem). Ik heb er zelf nog totaal geen last van gehad (of niet gemerkt in ieder geval) maar misschien dat het voor mensen zoals jij dus wel een probleem is dat mijn webservertje achter dit modem zit.

Die kan ik gewoon bereiken.

[Jerrythafast]

Compizfox schreef op maandag 30 mei 2016 @ 22:17:
[...]

Die kan ik gewoon bereiken.

Bedankt voor het testen Dan zal ICMPv6 toch niet helemaal op zijn gat liggen hier.

[stormfly]

Jerrythafast schreef op maandag 30 mei 2016 @ 22:41:
[...]

Bedankt voor het testen Dan zal ICMPv6 toch niet helemaal op zijn gat liggen hier.

Is het niet zo dat ICMPv6 alleen voor link local communicatie wordt gebruikt, Binnen alle /64's die je aflegt in het pad wordt ICMPv6 en MLD gebruikt, niet end to end.

Waardoor je omgekeerd kan redeneren, mijn browser zal nooit ICMPv6 praten met jouw webserver. Als jouw router ICMPv6 praat aan de LAN zijde en ook nog een keer aan de WAN zijde op beide segmenten werkt het.

ICMPv6
Like IPv4, IPv6 does not provide facilities for reporting errors. Instead, IPv6 uses an updated version of the Internet Control Message Protocol (ICMP) named ICMPv6. ICMPv6 has the common ICMPv4 functions of reporting delivery or forwarding errors and providing a simple echo service for troubleshooting.

The ICMPv6 protocol also provides a framework for the following:
Neighbor Discovery

Neighbor Discovery is a series of five ICMPv6 messages that manage node-to-node communication on a link. Neighbor Discovery replaces Address Resolution Protocol (ARP), ICMPv4 Router Discovery, and the ICMPv4 Redirect message. For more information about Neighbor Discovery, see “Neighbor Discovery” later in this section.

Multicast Listener Discovery (MLD)

Multicast Listener Discovery is a series of three ICMP messages that manage subnet multicast membership. Multicast Listener Discovery replaces version 2 of the Internet Group Management Protocol (IGMP) for IPv4. For more information about Multicast Listener Discovery, see “Multicast Listener Discovery” later in this section.

ICMPv6 is required for an IPv6 implementation. The following table lists and describes the ICMPv6 messages that are defined in RFC 2463.

[Bigs]

Net weer een 'mooie' ontdekt: Nieuwe Netgear m4300 switch forwardt (layer 2) op de een of andere manier geen IPv6 verkeer in 2016. IPv4 over dezelfde segmenten werkt prima en met een andere switch werkt IPv6 ook gewoon.

Heb maar even een support case bij Netgear geopend.

[CyBeR]

Zet IGMP snooping uit?

[Paul]

stormfly schreef op dinsdag 31 mei 2016 @ 06:17:
Is het niet zo dat ICMPv6 alleen voor link local communicatie wordt gebruikt

Lijkt me niet, ICMP is bij IPv6 volgens mij juist belangrijker dan bij IPv4 en wordt gebruikt om zaken over je verbinding te vertellen of optimaliseren. Sowieso is 'ping' ook ICMP: ICMP Echo Request en ICMP Echo Reply, en je kunt dingen op het internet gewoon pingen

Zaken als Destination Unreachable, Time Exceeded en Packet Too Big zijn ook wel handig om te weten Als je een pakketje stuurt met DNF (Do Not Fragment) en je komt bij een link met een MTU die lager is dan nodig om je pakketje te versturen krijg je dus een ICMP-pakketje terug... Allemaal zaken die (veel) verder weg (kunnen) plaatsvinden dan op je lokale netwerk.

De IP-stack van jouw computer praat dus met de IP-stack van het punt waarop het fout gaat (of waar je een Echo Request aan doet), als dat de webserver is dan is het inderdaad niet de browser die ICMP praat maar wel degelijk jouw computer