Overheidsingrijpen aan de vraagkant helpt in mijn ogen wel. Wil je aan de overheid leveren? IPv6.
[...]
Ow daar zijn we over eens. Mijn punt dat dat als we willen dat het sneller gaat. We moeten stopen om ons op de techniek te richten. Maar op op economische aspecten te richten en zorgen wij technische in controle blijven en geen speelbal gaan worden van de accountants en investeringens fondsen.
Dit is één van de redenen om dit als standaard te gaan vragen van leverancier. Het grootste nadeel van IPv4 gebruik is dat bepaalde businessmodellen nu door kosten per IP zo'n barriére tot toetreding hebben dat ze niet haalbaar zijn.
Bij iot is IPv6 gewoon eleganter. Verder zit er teveel in de standaard wat nu niet gebruikt wordt. Extension headers, IPsec support, zijn dingen die complexiteit geven en niet bruikbaar zijn, wat achteraf een vergissing lijkt.
Overheidsingrijpen aan de vraagkant helpt in mijn ogen wel. Wil je aan de overheid leveren? IPv6.
Ik werk zelf bij een overheidsdienst en wij mogen bij nieuwe diensten naar de burger (icm een centrale overheidskoppeling) alleen nog aanbieden als daar ipv6 bij zit. https://www.logius.nl/act...ngen-bereikbaar-zijn-ipv6
xbeam schreef op vrijdag 9 december 2022 @ 10:18:
@Roetzen Daarom is het belangrijk te weten waar en wie bezit en hoeveel procent is nog over van die nog nooit gebruikt zeg maar kwijt 30% van de ipv4 adressen. Welke bedrijven bespelen de markt en waarom gaan provider als vodafone niet over zoals zoals Tmobile USA
Je weet niet hoe het Vodafone core netwerk eruit ziet, misschien zit daar nog wat dure routers die geen IPv6 doen, en wachten ze nog een paar jaar tot die afgeschreven zijn. Misschien wachten ze nog even tot de kinderziektes er bij Vodafone Deutschland uit zijn (daar hebben ze recent IPv6 uitgerold), misschien zijn ze nog teveel bezig met de Ziggo-integratie, wellicht hebben ze specifieke beperkingen. Elke ISP en telco heeft zijn eigen tempo waarin ze grote netwerk upgrades uitvoeren.
Hoe duurder IPv4 wordt (of dat nou kunstmatig is of niet), hoe groter de prikkel om IPv6 uit te rollen, immers: dan kan je de vrijgekomen IPv4 adressen mooi te gelde maken in je hosting business.
Ik weet niet of je kunt stellen dat het "tipping point" al bereikt is, maar in elk geval groeit IPv6 en dat gaat doorzetten.
Er is niet echt een "tipping point" heb ik het idee, er is gewoon een (grotendeels onzichtbare) geleidelijke transitie bezig.
[Voor 15% gewijzigd door Dreamvoid op 12-12-2022 11:22]
Je weet niet hoe het Vodafone core netwerk eruit ziet, misschien zit daar nog wat dure routers die geen IPv6 doen
SP routers doen al 10+ jaar IPv6 en Vodafone heeft geen oude troep in hun core.
Verder draait de hele forwarding core op label switching en de packet core in software.
Infra gaat het probleem dus niet zijn.
When you do things right, people won't be sure you've done anything at all.
Ik werk zelf bij een overheidsdienst en wij mogen bij nieuwe diensten naar de burger (icm een centrale overheidskoppeling) alleen nog aanbieden als daar ipv6 bij zit. https://www.logius.nl/act...ngen-bereikbaar-zijn-ipv6
En zoals ik het lees gaat het om IPv6 aan de edge. Niet wat er intern in een netwerk gebruikt wordt, maar in ieder geval bereikbaar op een v6 adres.
Dat is voor mij ook waar de waarde zit. Wat er achter aan load-balancer gebeurt maakt niet uit. Intern IPv6 doen is in de praktijk soms behoorlijk pijnlijk is mijn ervaring (VPN naar cloud providers, k8s, ...).
En zoals ik het lees gaat het om IPv6 aan de edge. Niet wat er intern in een netwerk gebruikt wordt, maar in ieder geval bereikbaar op een v6 adres.
Dat is voor mij ook waar de waarde zit. Wat er achter aan load-balancer gebeurt maakt niet uit. Intern IPv6 doen is in de praktijk soms behoorlijk pijnlijk is mijn ervaring (VPN naar cloud providers, k8s, ...).
Ik zie IPv4 voor interne netwerken voorlopig ook nog niet verdwijnen. En de requirement voor IPv6 op de edge is relatief eenvoudig. Proxy je website via een cloudedge partij zoals Fastly, Akamai of Cloudflare en je krijgt er gratis IPv6 bij.
When you do things right, people won't be sure you've done anything at all.
JackBol schreef op maandag 12 december 2022 @ 11:49:
[...]
Ik zie IPv4 voor interne netwerken voorlopig ook nog niet verdwijnen. En de requirement voor IPv6 op de edge is relatief eenvoudig. Proxy je website via een cloudedge partij zoals Fastly, Akamai of Cloudflare en je krijgt er gratis IPv6 bij.
En zelfs die partijen hebben IPv6 nog niet volledig voor elkaar: Voor zover ik weet ondersteunt Fastly nog geen IPv6 naar origin.
Aan de andere kant is er voor IPv6 voor interne netwerken soms een business case. Teveel nodes in je netwerk voor de rfc1918 ranges? Teveel modems om te managen? Geen zin om een overlap in rfc1918 ranges tussen kantoren te hebben, waardoor security incidenten lastiger traceerbaar zijn?
Dan heb je een bedrijfsmatige incentive om IPv6 uit te rollen. En als je een beperkte set endpoints hebt (Android, iOS, laptops) dan werkt DNS64+NAT64 en het triggerren van de CLATs goed. Windows omgeving? Tough luck
[Voor 34% gewijzigd door ANdrode op 12-12-2022 12:02]
Overheidsingrijpen aan de vraagkant helpt in mijn ogen wel. Wil je aan de overheid leveren? IPv6.
Dat had de overheid jaren geleden al moeten doen!
Ik heb mij in 2010 al voorgenomen geen nieuw netwerkspul meer te kopen wat geen IPv6 ondersteunt. Dat is bijna gelukt.
Dit is één van de redenen om dit als standaard te gaan vragen van leverancier. Het grootste nadeel van IPv4 gebruik is dat bepaalde businessmodellen nu door kosten per IP zo'n barriére tot toetreding hebben dat ze niet haalbaar zijn.
Wat dat betreft heeft Freedom het wel goed gedaan vind ik. Ze hebben de benodigde IPv4 adressen niet gekocht, maar ze leasen ze. Daarmee zijn ze op de lange termijn wel duurder uit dan wanneer ze ze zouden kopen, maar een echte lange termijn is er natuurlijk niet en door te leasen leggen ze het kapitaalverlies bij instorten van de IPv4 markt bij de verhuurder.
Wat ik dan weer niet begrijp is dat ze pe sé iedere klant een publiek IPv4 adres willen aanbieden. Het lijkt me dat juist de doelgroep van Freedom wel gevoelig is voor het argument dat we moeten leren leven met het gegeven dat er hoe dan ook niet genoeg IPv4 is om iedere wereldburger een eigen publiek IPv4 adres te geven en dat we daar net zo goed morgen mee kunnen beginnen. Dat ze de tijd nog niet rijp achten voor volledig IPv6 only kan ik me voorstellen, maar ze zouden de de keus aan de klant kunnen laten door een korting te geven bij afzien van een publiek IPv4 adres.
Roetzen schreef op maandag 12 december 2022 @ 12:46:
Wat ik dan weer niet begrijp is dat ze pe sé iedere klant een publiek IPv4 adres willen aanbieden. Het lijkt me dat juist de doelgroep van Freedom wel gevoelig is voor het argument dat we moeten leren leven met het gegeven dat er hoe dan ook niet genoeg IPv4 is om iedere wereldburger een eigen publiek IPv4 adres te geven en dat we daar net zo goed morgen mee kunnen beginnen. Dat ze de tijd nog niet rijp achten voor volledig IPv6 only kan ik me voorstellen, maar ze zouden de de keus aan de klant kunnen laten door een korting te geven bij afzien van een publiek IPv4 adres.
Die kun je ook omdraaien. Als je de doelgroep van Freedom als een stel nerds ziet is de kans ook groot dat die thuis services hebben draaien. Dan is het wel handig als die ook een publiek IP hebben zodat ze bv ook bereikbaar zijn voa Vodafone . Het lijkt mij juist voor de grote telecomboeren makkelijker om CGNAT in te zetten omdat juist daar 75% of meer van het klantenbestand er geen benul van heeft. En die 25% wat dat wel heeft je gewoon publiek IPv4 op aanvraag levert.
Ik zie IPv4 voor interne netwerken voorlopig ook nog niet verdwijnen. En de requirement voor IPv6 op de edge is relatief eenvoudig. Proxy je website via een cloudedge partij zoals Fastly, Akamai of Cloudflare en je krijgt er gratis IPv6 bij.
Het ligt er dus maar net aan. Zo zie je dat Microsoft, Apple en ook het nieuwe Smart Home systeem Matter helemaal gebruik maken van IPv6 in het lokale netwerk en vooral Link-Local.
Je ziet daar dus al een hele tijd v4 en v6 naast elkaar.
Ik ben mijn huidige colocatie aan het uitfaseren en omzetten naar IPv6 only. Dat scheelt weer dubbel firewall beheer en de kosten van het IPv4 subnet wat ieder jaar stijgt in prijs.
Aangezien ik alleen webapplicaties doe, is alleen van belang dat port 80 en 443 voor IPv4 bereikbaar zijn. Dat doe ik met nginx (icm modules stream_ssl_preread en upstream naar IPv6 adres port 443). SSL certificaten staan op de IPv6 servers zelf. IPv6 verkeer komt dus rechtstreeks op de server uit, IPv4 gaat via de nginx proxy, enige nadeel is dat je het nginx proxy IP adres zie in de logging. (Mocht iemand daar een oplossing voor hebben...)
Outbound verkeer gaat via NAT64/DNS64 (vooral voor github bedoeld).
[Voor 8% gewijzigd door zx9r_mario op 12-12-2022 13:41]
Dreamvoid schreef op maandag 12 december 2022 @ 11:17:
Hoe duurder IPv4 wordt (of dat nou kunstmatig is of niet), hoe groter de prikkel om IPv6 uit te rollen, immers: dan kan je de vrijgekomen IPv4 adressen mooi te gelde maken in je hosting business.
Dat is ook mijn punt. En te lang wachten is dan ook niet handig, want die prijzen van IPv4 blijven niet eeuwig hoog.
Er is niet echt een "tipping point" heb ik het idee, er is gewoon een (grotendeels onzichtbare) geleidelijke transitie bezig.
Je kunt dat tipping point uiteraard pas achteraf zien als het al gebeurd is. Tot nu toe zie ik inderdaad geen duidelijk afgebakend punt van omslag, alleen een geleidelijke verandering. Misschien als de prijs van IPv4 weer gaat dalen?
Die kun je ook omdraaien. Als je de doelgroep van Freedom als een stel nerds ziet is de kans ook groot dat die thuis services hebben draaien. Dan is het wel handig als die ook een publiek IP hebben zodat ze bv ook bereikbaar zijn voa Vodafone .
Van die kant bekeken wel natuurlijk. Onder de Freedommers zullen er relatief veel klanten zijn die om die reden graag een publiek IPv4 adres hebben. En als dat 95% is, dan heeft het misschien geen zin om voor die 5% die het niet nodig heeft iets aparts te regelen.
Het lijkt mij juist voor de grote telecomboeren makkelijker om CGNAT in te zetten omdat juist daar 75% of meer van het klantenbestand er geen benul van heeft. En die 25% wat dat wel heeft je gewoon publiek IPv4 op aanvraag levert.
Die 75% lijkt me eigenlijk nog aan de krappe kant. 95% of zelfs 98% lijkt me meer in de buurt komen. Maar dat terzijde.
Ik draai ook servers. Iets meer dan een jaar of vijf geleden dacht ik dat Ziggo mij wel eens zo maar van full dual stack naar DS-Lite zou kunnen omzetten. Inmiddels lijkt dat - voorlopig althans - van de baan. Het omgekeerde gebeurde juist. De klanten van voormalig UPC worden van DS-Lite naar full dual stack omgezet. Kennelijk kon alleen op die manier voldaan worden aan IPv6 in bridge mode.
Maar ik ben toen - vijf jaar geleden - wel mijn knopen gaan tellen. Wat als.. Ik ben gaan experimenteren met het op IPv6 only zetten van de servers. Uiteindelijk kwam ik uit bij feste-ip.net. Misschien is dat ook een tussenoplossing voor Freedom. Voor wie volledige inkomende toegang via IPv4 nodig heeft is het geen oplossing, maar voor wie maar één or twee poorten nodig heeft kan het uitkomst bieden als Freedom als alternatief een feste.ip.net gateway biedt.
Hoe dan ook, alleen een eigen publiek IPv4 voor hen die het nodig hebben en die noodzaak willen bekrachtigen door de portemonnee te trekken bespaart de kosten voor iedereen. Kostenbesparing is een argument dat bijna iedereen wel aanspreekt. Het lijkt me in elk geval zinnig dat er over wordt nagedacht....
Aangezien de certificaten op de webservers zelf staan vermoed ik dat de reverse proxy de boel niet decrypt en re-encrypt. Een header toevoegen zal dan niet lukken.
Een optie is je reverse proxy als router in te richten voor de webservers en nginx het source-adres van het request te laten gebruiken in het request naar de webservers? Op Citrix ADC (voorheen Netscaler) heet dat Use Source IP (USIP) maar ik heb geen idee of nginx dat ook kan
Wel zou ik dat goed testen, want het is niet de meest standaard situatie Mogelijk is het simpeler / beter om de certificaten op de reverse proxy te zetten zodat je wel x-forwarded-for kunt gebruiken.
"Your life is yours alone. Rise up and live it." - Richard Rahl Rhàshan - Aditu Sunlock
Nee, jij bent degene die er niks van snapt. Beurswaarde ontstaat doordat kopers van aandelen een bepaalde waarde toekennen aan de aandelen. Die toekenning van waarde doen ze onder meer op basis van de bezittingen van het bedrijf. Voorraden IPv4 zouden daar bij kunnen behoren. Maar dan moeten de kopers van aandelen daarvan wel op de hoogte zijn. Niemand gaat toch een waarde toekennen aan iets waarvan hij/zij niet eens weet of het wel bestaat. Dat staat geheel los van een eventuele wettelijke publicatie plicht. Iets waarvan het bedrijf niet bekend maakt dat het er is genereert geen beurswaarde. Waarom is dat nou zo moeilijk te begrijpen?
jammer hier ben je och echt af. 99 procent van de bedrijven wereldwijd hoeven niets publiceren en worden niet publieke verhandelt. Nederland kent +-150 NV.s
Dus hou eens op beurs waarden is gebaseerd publiekelijke ge bla bla enz
Dat je dan rest niet snapt begrijp ik. De vraag van mij aan mij zelf of het zonde van mijn tijd is om op economische reacties van jouw te reageren. geef ik nog ik nog één kans.
Hierbij wel mijn verzoek om mocht iemand daarna in de toekomst er weer over begingen deze discussie dan niet weer als complot of onzin enz enz af te doen. want dat is het namelijk niet. Alleen wil je dat niet in zien omdat het gewoon niet wil of echt niet begrijpt wat er onder je neus af speelt.
ik zeg dit als oud ISP / a VF sub brand netwerk beheerder/bouwer) die naast informatica als 2 studie commerciële economie heeft gedaan. ik weet echt wel iets van marktwerking bedrijfs strategieën.
[Voor 25% gewijzigd door xbeam op 12-12-2022 20:00]
Tja, wat niet op de beurs verhandeld wordt kan uiteraard sowieso geen beurswaarde genereren. Maar deze subthread ging dan ook niet speciaal over de BV Vodafone maar was een reactie op deze uitspraak van @xbeam
Omdat die procenten waarschijnlijk de partijen /aandeelhouders zijn die vanwege prijs speculaties of beurs waarde er baat hebben die overgang naar ipv6 tegen te werken/vertragen.
jammer hier ben je och echt af. 99 procent van de bedrijven wereld wijd hoeven niets publiceren en worden niet publieke verhandelt. Nederland kent +-150 NV.s
dus hou eens op beurs waarden publiekelijke ge bla bla enz
dat je rest niet snap ik als dit al niet snapt is het zonde van mijn tijd om economische op je te reageren.
hierbij wel mijn verzoek om mocht hier in de toekomst weer over begingen deze discussie niet als complot of onzin af te doen. want dat is het namelijk niet alleen wil je dat niet in zin omdat het gewoon niet (wil ) begrijpen wat er onder je neus af speelt.
ik zeg dit als oud ISP / a VF sub brand netwerk beheerder/bouwer) die naast informatica als 2 studie commerciële economie heeft gedaan. ik weet echt wel iets van marktwerking bedrijfs strategieën.
Om je argument een hart onder de riem te steken, ISPs draaien om het maken van winst. Als je door het verpatsen van IPv4 adressen meer zouden verdienen dan met internet leveren aan klanten, zouden ze dat vandaag nog doen.
Liggen er IPv4 ranges op de plank hier en daar? Vast en zeker want niet alle publieke IP space zijn zichtbaar in de global routing table. Is dat een definitief antwoord? Nee, want veel pre-classless organisaties gebruiken nog steeds public IP om hun interne netwerken te adresseren (wat volkomen legaal is, er is geen verplichting om publieke IPv4 space te announcen). En bijv. de meeste IX'en announcen hun Peering VLAN subnets niet, terwijl dat wel publieke IP space is.
En ja, theoretisch kan je daar dus private IP space voor gebruiken. En bij de meeste bedrijven met een accountant is die berekening vast al een keer gemaakt, of het interessant is om IPv4 adressen te verpatsen. Maar een /20 levert tegenwoordig 200k op. Dus je projectkosten om van die reeks af te komen zijn waarschijnlijk hoger dan de prijs die je krijgt voor je adressen.
When you do things right, people won't be sure you've done anything at all.
IPv6 implementeren kost geld. Geld wat niet naar de aandeelhouders gaat (of dat nu een besloten of naamloze vennootschap is). Er zijn genoeg partijen die geen enkele zin hebben om IPv6 te implementeren vanwege de kosten en die zullen zo lang mogelijk tegen werken. Er is zelfs een hele industrie omheen ontstaan. Die CGNAT boxen bestonden 20 jaar geleden nog niet. Dat er financieel motieven zijn om IPv6 adoptie tegen te gaan, is zeker geen fabel.
When you do things right, people won't be sure you've done anything at all.
xbeam schreef op maandag 12 december 2022 @ 17:00:
[...]
dat je rest niet snap ik als dit al niet snapt is het zonde van mijn tijd om economische op je te reageren.
hierbij wel mijn verzoek om mocht hier in de toekomst weer over begingen deze discussie niet als complot of onzin af te doen. want dat is het namelijk niet alleen wil je dat niet in zin omdat het gewoon niet (wil ) begrijpen wat er onder je neus af speelt.
ik zeg dit als oud ISP / a VF sub brand netwerk beheerder/bouwer) die naast informatica als 2 studie commerciële economie heeft gedaan. ik weet echt wel iets van marktwerking bedrijfs strategieën.
En IP adressen zijn op een balans niet veel waard. Zolang de utilisatie ergens op slaat.
CAPEX voor modems is >100 euro per klant per 3 jaar.
IP adressen zijn EUR ~50 per klant aan CAPEX (bij inkoop in bulk) of OPEX van een paar euro per maand als je via een broker werkt. Het is worst case geen belangrijke post ten opzichte van de acquisitie, en waarschijnlijk zelfs support kosten per klant.
zx9r_mario schreef op maandag 12 december 2022 @ 13:39:
Ik ben mijn huidige colocatie aan het uitfaseren en omzetten naar IPv6 only. Dat scheelt weer dubbel firewall beheer en de kosten van het IPv4 subnet wat ieder jaar stijgt in prijs.
Aangezien ik alleen webapplicaties doe, is alleen van belang dat port 80 en 443 voor IPv4 bereikbaar zijn. Dat doe ik met nginx (icm modules stream_ssl_preread en upstream naar IPv6 adres port 443). SSL certificaten staan op de IPv6 servers zelf. IPv6 verkeer komt dus rechtstreeks op de server uit, IPv4 gaat via de nginx proxy, enige nadeel is dat je het nginx proxy IP adres zie in de logging. (Mocht iemand daar een oplossing voor hebben...)
Outbound verkeer gaat via NAT64/DNS64 (vooral voor github bedoeld).
Waarschijnlijk doet het proxy protocol (nginx blog) wat je wilt. Voor zover ik weet is kan je hiermee ook end-to-end encryptie houden.
Bij TCP loadbalancing kan dit ook - maar dan zit je in een v4 wereld. De load-balancer is de router vna het subnet. De LB DNAT het verkeer naar de backend server. En op de terugweg zit de router op het pad en herschrijft deze het dan weer.
Tja, wat niet op de beurs verhandeld wordt kan uiteraard sowieso geen beurswaarde genereren. Maar deze subthread ging dan ook niet speciaal over de BV Vodafone maar was een reactie op deze uitspraak van @xbeam
[...]
I rest my case...
BV hebben ook aandeelhouders en besloten holdings en investeringsfondsen koppen/ azen via beurs genoteerde bedrijven op ipv4. Daarnaast kunnen NV's weer dingen weg stoppen in BV's en fonds en daar een waarde aan toe kennen. je zal inderdaad negens letterlijk een kopje waarde ipv4 stack tegen komen in een jaar verslag. Holdings structuren zijn allemaal niet iets gecompliceerder jouw situatie schets.
It also seems that there could be speculation on the part of some potential sellers, who are seeing the doubling of price in the past year, and wondering if it will continue to double each year. Thus, they are hesitating in coming to market. It may also be that many potential sellers are looking at the continued slow uptake of IPv6, and are hanging on to their IPv4 addresses, just in case they need them
Om jouw punt van ipv4 te kort uit een te zetten tegenover de toegevoegde (economische) waarde van ipv6. waarom zouden aandeelhouders van bedrijven overgaan op ipv6 en geld uitgeven aan jouw voor hen niet bestaande te kort?
Some commentators have superior the view that an escalating value for IPv4 will increase the financial incentive for IPv6 adoption, and this will likely certainly be the case. Nonetheless, there are different potential substitutes which were used, most notably NATs (Community Handle Translators). Whereas NATs don’t get rid of the demand stress for IPv4, they will go a protracted solution to enhance the deal with utilization effectivity of IPv4 addresses. NATs enable the identical deal with for use by a number of prospects at completely different instances. The bigger the pool of consumers that share a standard pool of NAT addresses, the better the achievable multiplexing functionality. NATs usually are not simply an address-sharing functionality. A number of endpoints can use the identical deal with on the “inside” of the NAT. They use the transport protocol and inside port quantity, including an additional 16 bits to the efficient deal with dimension. If the timeshare part is fourfold (2 bits), then the whole end result of NATs is to extend the out there deal with capability in IPv4 from 4 billion endpoints (232) to some 1,000 trillion endpoints (250). Relying on the widespread definition of an end-site prefix, the usable deal with capability in IPv6 is someplace between 49 bits and 58 bits. This conclusion factors to the remark that the general carrying capability of IPv6 just isn’t all that completely different from that of a dense IPv4 deployment making extremely environment friendly use of NATs.
Het is just een misvatting dat er nu een te kort aan ipv4 is omdat de bron en dat ipv6 meer cliënts kan handelen. Juist dat geschreeuw om te kort richting de directie drijft speculatie in de hand zorgt voor dat partijen ipv4 stack in sokken onder het bet gaan leggen. Voor speculatie op potentieel toekomstig gebruike of waarde speculatie. Als je honderd duizend van iets bezit. Dat gratis hebt gekregen en nu elkaar verdubbeld in waarden verdubbeld? Wat zou jij doen? Er zijn genoeg bedrijven die echt lucht op de hebben staan ( bitcoins ) ipv4 is tenminste nog iets. ( nogmaals ik ben geen voor standerd om dat te doen.
ik probeer aalleen maar duidelijk te maken dat het steeds meer gebeurt en dat onderstap gaat vertragen. ipv6 is technische beter. maar niet economische niet direct nodig. zoals @JackBol goed uitlegt .Heeft ipv4 naast werkelijke kosten en opbrengst ook een strategische waardoor de waarden van aanhouden, verkopen of gebruiken en het gebruiken van ipv6 niet alleen kosten post woord gezien maar ook als een en instap drempel verlagen. En dat is waar veel partijen eigenlijk van uit concurrentie overwegingen helemaal niet op zitten te wachten.
Nogmaals ik vind niet dat we op ipv4 moeten blijven en ben het volledig eens dat we vanwege technische redenen over moeten ipv6. Maar als we dat willen moeten volgens mij de discussie anders gaan voeren. Op techniek gaan we hem niet meer van de accountants binnen je bedrijf en speculanten. Anders hadden was de baas al lang om
Door dit niet te erkenen blijft het voorlopig ook de vertragende factoor.
Overheidsingrijpen aan de vraagkant helpt in mijn ogen wel. Wil je aan de overheid leveren? IPv6.
Dat is altijd met overheids ingrijpen op korte termijn lijkt het altijd te werken alleen verstoort het altijd/meestal wel de natuurlijke markt. Waardoor er later of andere plekken een gedrocht van aap uit de komt wat veel schadelijker of kostbaarder is dan niet economische ingrijpen. de markt stop niet namelijk niet bij de grens en ontwikkeld zicht tegen Draads met beoogde locale doel verder.
Dat werk zal zeker of dat het beoogde doel zonder kleerschuren gaat brengen is altijd de vraag.
Paul schreef op maandag 12 december 2022 @ 16:31:
[...]
Aangezien de certificaten op de webservers zelf staan vermoed ik dat de reverse proxy de boel niet decrypt en re-encrypt. Een header toevoegen zal dan niet lukken.
Een optie is je reverse proxy als router in te richten voor de webservers en nginx het source-adres van het request te laten gebruiken in het request naar de webservers? Op Citrix ADC (voorheen Netscaler) heet dat Use Source IP (USIP) maar ik heb geen idee of nginx dat ook kan
Wel zou ik dat goed testen, want het is niet de meest standaard situatie Mogelijk is het simpeler / beter om de certificaten op de reverse proxy te zetten zodat je wel x-forwarded-for kunt gebruiken.
Waarom zet je de dns proxy provider niet als reverse proxy in. cloudflare kan bijv request of request origine based port rewritten. Naar de gewenste applicatie/site.
Scheelt een hoop eigen proxy onderhoud. En de sizzling gebeurd lekker op afstand waardoor alleen een je portjes naar je dns proxy provider open zet en naar de hele wereld.
Origin Rules allow you to customize where the incoming traffic will go and with which parameters. Currently you can perform the following overrides:
Host header: Overrides the Host header of incoming requests.
Server Name Indication (SNI): Overrides the Server Name Indication (SNI) value of incoming requests.
DNS record: Overrides the resolved hostname of incoming requests.
Destination port: Overrides the resolved destination port of incoming requests.
The Origin Rule expression will determine when these overrides will be applied.
[Voor 124% gewijzigd door xbeam op 13-12-2022 09:04]
Overheidsingrijpen aan de vraagkant helpt in mijn ogen wel. Wil je aan de overheid leveren? IPv6.
[...]
Dit is één van de redenen om dit als standaard te gaan vragen van leverancier. Het grootste nadeel van IPv4 gebruik is dat bepaalde businessmodellen nu door kosten per IP zo'n barriére tot toetreding hebben dat ze niet haalbaar zijn.
Bij iot is IPv6 gewoon eleganter. Verder zit er teveel in de standaard wat nu niet gebruikt wordt. Extension headers, IPsec support, zijn dingen die complexiteit geven en niet bruikbaar zijn, wat achteraf een vergissing lijkt.
Maar even los van een dwingende vraagkant en elegantie:
Wat zijn op dit moment de praktische voordelen om (naast IPv4) ook IPv6 te gebruiken?
Hetzij thuis/prive; hetzij zakelijk (mkb en/of large enterprise)?
En ja - de vraag is serieus bedoeld - ik ben serieus nieuwsgierig hoe jullie dit zien.
Airw0lf schreef op dinsdag 13 december 2022 @ 07:00:
Maar even los van een dwingende vraagkant en elegantie:
Wat zijn op dit moment de praktische voordelen om (naast IPv4) ook IPv6 te gebruiken?
Hetzij thuis/prive; hetzij zakelijk (mkb en/of large enterprise)?
En ja - de vraag is serieus bedoeld - ik ben serieus nieuwsgierig hoe jullie dit zien.
Prive/thuis:
- geen random portscans van duizenden Russen/Chinezen meer op mijn zelf-gehoste spul
- geen geklooi met split-DNS
- ik kan IPv6 peers bereiken
Enterprise:
- eenvoudiger netwerk structuur
- geen geklooi met split-DNS
- ik kan IPv6 peers bereiken
Maar even los van een dwingende vraagkant en elegantie:
Wat zijn op dit moment de praktische voordelen om (naast IPv4) ook IPv6 te gebruiken?
Hetzij thuis/prive; hetzij zakelijk (mkb en/of large enterprise)?
En ja - de vraag is serieus bedoeld - ik ben serieus nieuwsgierig hoe jullie dit zien.
Praktische voordelen? Net hoe je het bekijkt. In de basis heb je gewoon internet. Via IPv6 niet spannender dan IPv4.
Als techneut is het erg fijn dat je gewoon P2P internet hebt! Ik kan services thuis zoals mijn NAS gewoon direct bereiken. Ook mijn P1 Slimme meter monitor en andere zaken. Gewoon DNS entry en ik kan er bij. Ideaal.
Maar vooral: Het internet beweegt naar IPv6 toe. Langzaam of snel (ligt er aan welke blik je hebt), maar IPv6 gaat niet meer weg. In vele delen al >50% van het verkeer.
Maar daarin zitten dan ook de risicofactoren: als ipv6 op grote schaal gebruikt wordt kloppen de Chinezen en Russen ook massaal op het Internet deurtje?
Waar ik naar zoek is een pragmatische ipv6 invulling. Dus als iemand me deelgenoot will maken van zijn/haar aanpak?
Ik ben jaren terug afgehaakt op de hoeveelheid variabelen en beta-stacks om te komen tot een stabiele en veilige ipv6 invulling.
Maar als er iemand is die me hier kan helpen met een pragmatische jumpstart dan wil ik de knop zeker nog eens omzetten!
Airw0lf schreef op dinsdag 13 december 2022 @ 10:08:
Maar daarin zitten dan ook de risicofactoren: als ipv6 op grote schaal gebruikt wordt kloppen de Chinezen en Russen ook massaal op het Internet deurtje?
Er zijn zo'n 3,7 miljard potentieel geldige publieke IPv4-adressen. Dat aantal is met hedendaagse verbindingssnelheden vrij snel volledig te scannen, en omdat een groot gedeelte van die adressen daadwerkelijk in gebruik zijn heeft dat ook een goede "hit-rate".
Voor IPv6 is het zoekbereik gigantisch veel groter, en zijn het overgrote merendeel van de potentieel geldige adressen niet in gebruik. Ieder /64 subnet heeft immers 264 adressen beschikbaar, waarvan er bij thuisgebruikers vaak maar enkele tientallen of honderden in gebruik zijn (bij datacenters of grote organisaties meer, maar nog steeds maar een minieme fractie van het beschikbare aantal).
Daardoor heeft het veel minder zin om "blind" op IPv6 te scannen: tenzij je al een goed idee hebt van welke adressen daar in gebruik zijn heb je weinig kans om binnen redelijke tijd een adres te vinden dat daadwerkelijk in gebruik is. En dan heb ik het nog niet eens gehad over open poorten...
Airw0lf schreef op dinsdag 13 december 2022 @ 10:08:
Maar daarin zitten dan ook de risicofactoren: als ipv6 op grote schaal gebruikt wordt kloppen de Chinezen en Russen ook massaal op het Internet deurtje?
Daar heb je een firewall voor :-)
Maar als dat echt zo'n probleem zou zijn, dan zouden de grote partijen toch IPv6 nooit aanzetten? Ziggo, KPN, Facebook, Google, Netflix, etc.
JackBol schreef op maandag 12 december 2022 @ 17:55:
[...]
Om je argument een hart onder de riem te steken, ISPs draaien om het maken van winst. Als je door het verpatsen van IPv4 adressen meer zouden verdienen dan met internet leveren aan klanten, zouden ze dat vandaag nog doen.
Dus voor wie het zelf in gebruik heeft - op wat voor manier dan ook - zal het misschien niet lonend zijn het te verkopen. Maar wie het alleen maar op de plank heeft liggen en er zelf niets mee doet, is een dief van eigen portemonnee als hij het niet te gelde maakt. Door te verkopen of te verhuren..
Maar een /20 levert tegenwoordig 200k op.
En over 5 jaar misschien 1000K. Of maar €100. Dat is een gok. En we weten wie in het casino altijd de echte winnaar is. Dat is de bank.
IPv6 implementeren kost geld. Geld wat niet naar de aandeelhouders gaat (of dat nu een besloten of naamloze vennootschap is).
Zeker, dat kost geld. Maar hoe langer je wacht hoe duurder het uiteindelijk onvermijdelijke gaat worden. Beleggen is een zaak vam lange termijn, dus het moet niet zo moeilijk zijn dat aan de aandeelhouders uit te leggen.
Er zijn genoeg partijen die geen enkele zin hebben om IPv6 te implementeren vanwege de kosten en die zullen zo lang mogelijk tegen werken.
Zeker, die zijn er. Maar of die ook de macht hebben de transitie naar IPv6 als geheel daadwerkelijk significant te vertragen vraag ik me dan wel af.
Wie nu nog niet inziet dat tegenwerken van IPv6 een achterhoedegevecht is verdient hetzelfde lot als de bouwer van stoommachines.
Er is zelfs een hele industrie omheen ontstaan. Die CGNAT boxen bestonden 20 jaar geleden nog niet.
Tien jaar geleden wel.
Dat er financieel motieven zijn om IPv6 adoptie tegen te gaan, is zeker geen fabel.
Maar dat die pogingen uiteindelijk succesvol zullen zijn is wensdenken.
Ik zat een tijdje geleden te praten met een netwerkengineer van Verizon (die beheren ons netwerk). Vroeg hem ook waarom wij helemaal geen ipv6 deden intern (amerikaanse multinational, wij hadden 13.0.0.0/8). Oh nee, dat was lastig en moeilijk en niet de moeite waard. Want intern deed je toch NAT (klopt, intern zitten wij op 10.0.0.0/8).
Wel veel geleerd over virtual WANs, SD-WANs en routing.
Ja tis allemaal leuk als je netwerk statisch blijft, totdat je een bedrijf overneemt dat op overlappende 10.0.0.0/8 ranges zit en je de boel intern nog eens moet gaan lopen NATen.
Ik bedoel, tis allemaal wel te fixen, mensen doen dit al jaren. Maar het is wel een geknutsel op een gegeven moment.
[Voor 25% gewijzigd door Dreamvoid op 13-12-2022 17:38]
Dreamvoid schreef op dinsdag 13 december 2022 @ 17:29:
Ja tis allemaal leuk als je netwerk statisch blijft, totdat je een bedrijf overneemt dat op overlappende 10.0.0.0/8 ranges zit en je de boel intern nog eens moet gaan lopen NATen.
Ik bedoel, tis allemaal wel te fixen, mensen doen dit al jaren. Maar het is wel een geknutsel op een gegeven moment.
Bij een beetje multinational duurt zoon integratie een jaar of langer en kan je zeggen dan is subnet overlap niet exht je grootste probleem (uitdaging) waar je wakker van ligt.
Bij een beetje multinational duurt zoon integratie een jaar of langer en kan je zeggen dan is subnet overlap niet exht je grootste probleem (uitdaging) waar je wakker van ligt.
Subnet overlap is toch ook geen probleem zolang het tussen kantoren is? Je moet de prefixes van gedeelde diensten alleen even slim routeren.
Wanneer RFC1918 op is kan je 100.64.0.0/10 gebruiken. Als dat niet meer lukt heb je 240/4 nog.
Subbnet overlap is toch ook geen probleem zolang het tussen kantoren is? Je moet de prefixes van gedeelde diensten alleen even slim routeren.
"Alleen even slim routeren". Jaja...
Wanneer RFC1918 op is kan je 100.64.0.0/10 gebruiken. Als dat niet meer lukt heb je 240/4 nog.
100.64.0.0/10 gebruiken is niet handig want dat is gereserveerd voor de CGNAT van ISPs. Dan loop je het risico van een conflict. 240/4? Nou, veel geluk er mee. Ik denk dat overschakelen op IPv6 minder problemen geeft.
Hoeveel ranges voor diensten die tussen locaties gedeeld worden heeft een gemiddeld bedrijf? En hoeveel daarvan zijn IPs ipv DNS?
[...]
100.64.0.0/10 gebruiken is niet handig want dat is gereserveerd voor de CGNAT van ISPs. Dan loop je het risico van een conflict. 240/4? Nou, veel geluk er mee. Ik denk dat overschakelen op IPv6 minder problemen geeft.
Het zijn geen mooie oplossingen. Wordt wel gedaan (240/4, 100.64/10) en is bijzonder effectief.
Tot vorig jaar kon je ook wat DOD prefixen gebruiken als hack – maar die werden vorig jaar opeens (NANOG) aangekondigd in de default free zone
Dit zijn geen mooie oplossingen maar ze zijn wel deploybaar.
[Voor 3% gewijzigd door ANdrode op 14-12-2022 11:04]
@ANdrode
"Geen mooie oplossingen" is een eufemisme. Als je iets gaat gebruiken waarvoor het niet bedoeld is (DOD blok of 100.64/10) of iets wat gereserveerd is (240/4) loop je altijd het risico dat er vroeger of later een conflict ontstaat en dat je weer opnieuw kunt beginnen
Roetzen schreef op woensdag 14 december 2022 @ 11:44:
@ANdrode
"Geen mooie oplossingen" is een eufemisme. Als je iets gaat gebruiken waarvoor het niet bedoeld is (DOD blok of 100.64/10) of iets wat gereserveerd is (240/4) loop je altijd het risico dat er vroeger of later een conflict ontstaat en dat je weer opnieuw kunt beginnen
Maar tot die tijd heb je een goed werkende workaround [...] die je vandaag nog kan uitrollen in een netwerk.
Als het om gereservereerd/niet gereserveerd gaat dan is de multicast range (224.0.0.0/4) ook een kandidaat. Zeker omdat multicast routing waarschijnlijk niet is ingeregeld in een bedrijfsnetwerk.
Ontzettend vies. Maar in de praktijk ontloop je er wel de problemen mee die je anders door tekort aan RFC1918 of overlappende ranges hebt.
Workarounds genoeg, daar draaien we al 30+ jaar op Je wordt het alleen op een gegeven moment wel zat, al die onverwachte bijwerkingen en knutselconfigs die je allemaal weer moet gaan uitleggen aan anderen als er wat personeelsverloop is.
[Voor 27% gewijzigd door Dreamvoid op 14-12-2022 13:14]
Dreamvoid schreef op woensdag 14 december 2022 @ 13:12:
Workarounds genoeg, daar draaien we al 30+ jaar op Je wordt het alleen op een gegeven moment wel zat, al die onverwachte bijwerkingen en knutselconfigs die je allemaal weer moet gaan uitleggen aan anderen als er wat personeelsverloop is.
Gaat Ipv6 al het bestaande digitale Duc-tape opruimen en voorkomen dat we in de toekomst moeten Duc-Tapen?
Gaat Ipv6 al het bestaande digitale Duc-tape opruimen en voorkomen dat we in de toekomst moeten Duc-Tapen?
Mensen blijven mensen en knutselwerk zal er altijd wel komen, maar dat je je netwerk netjes hierarchisch kan routeren richting de endpoints ruimt natuurlijk wel lekker op.
Laten we het hopen, want je personeel vragen om hun thuisnetwerk om te nummeren vanwege een conflict met de VPN Server IP Range is best wel lullig en straks hopelijk niet meer nodig!
Laten we het hopen, want je personeel vragen om hun thuisnetwerk om te nummeren vanwege een conflict met de VPN Server IP Range is best wel lullig en straks hopelijk niet meer nodig!
Dat is met ipv4 ook nooit nodig.Het gaat fout dat veel beheerders de verkeerde oplossing kiezen en mensen via bijv een veel te resources intensieve VPN’s wil laten verbinding en daar mee ook nog eens hun netwerken blootstellen aan all rotzooi die gebruikers prive over hun netwerk binnen halen en op hun pc hebben draaien In 99 procent van de gevallen (Developers en beheerders daar gelaten) hebben gebruikers alleen toegang tot een drive , Exchange en wat interne web applicaties nodig.
Dat kan je veel beter via bijv ZTNA over het internet beschikbaar maken.
xbeam schreef op woensdag 14 december 2022 @ 19:53:
[...]
In 99 procent van de gevallen (Developers en beheerders daar gelaten) hebben gebruikers alleen toegang tot een drive , Exchange en wat interne web applicaties nodig. Dat kan je veel beter via bijv ZTNA over het internet beschikbaar maken.
Zero trust netwerk oplossingen zijn lastig aan beheerders uit te leggen. Jammer, want het is een veel betere ervaring, veiliger, én geeft veel betere performance.
Dreamvoid schreef op woensdag 14 december 2022 @ 13:12:
Workarounds genoeg, daar draaien we al 30+ jaar op Je wordt het alleen op een gegeven moment wel zat, al die onverwachte bijwerkingen en knutselconfigs die je allemaal weer moet gaan uitleggen aan anderen als er wat personeelsverloop is.
Knutselconfigs zijn hels. Helemaal als je alsnog krap zit in adresruimte. De extreem lompe oplossing die ik voorstelde om 240/4 te gebruiken geven in ieder geval ruimte. Mogelijk genoeg om hiërarchisch te routeren.
RFC1918 is niet groot genoeg voor één IP per device en IPv4 heb je toch nodig in de praktijk. Je kan niet NAT64+CLAT in het OS gebruiken als je windows endpoints hebt.
Kan je dat wel (mac, linux, iOS, Android) dan wordt het simpel. NAT64, geen DHCP lease per endpoint meer nodig.
RFC1918 is niet groot genoeg voor één IP per device en IPv4 heb je toch nodig in de praktijk. Je kan niet NAT64+CLAT in het OS gebruiken als je windows endpoints hebt.
Kan je dat wel (mac, linux, iOS, Android) dan wordt het simpel. NAT64, geen DHCP lease per endpoint meer nodig.
Mede door wat tekst-en-uitleg van @Raymond P in het grote pihole topic en later off-line (soort-van) overweeg ik om IPv4 uit te faseren. Als ik bovenstaand zo lees: is zoiets op dit moment realistisch?
Ook al omdat een SIDN pagina spreekt over een IPv6 adoptie van ongeveer 40% wereldwijd: https://www.sidn.nl/moderne-internetstandaarden/ipv6
Mijn zorg zit met name aan de Windows-10/11 kant - afgaande op wat ik erover gelezen heb schijnt de combi IPv6/IPv4 niet echt een goede te zijn?
En hoe zit het met port forwarding? Is dat een-op-een om te zetten?
Tot slot: op dit moment krijgen alle endpoints via SLAAC een IPv6-adres en een default gateway. Ook ben ik aan het stoeien met de door KPN beschikbaar gestelde IPv6-prefix.
Maar tot nu toe heeft geeneen endpoint een IPv6-DNS-server toegewezen gekregen.
Nu weet ik dat de default gateway gedeeld wordt via RA. En dat er met RFC 6106 iets vergelijkbaars mogelijk is voor DNS server(s)?
Alleen heb ik hier tot nu toe geen voorbeelden van gevonden - ook niet in combinatie met zoiets als pihole. Iemand suggesties?
[Voor 3% gewijzigd door Airw0lf op 14-12-2022 22:21]
Single-stack IPv6 is inmiddels te doen met servers (NAT64/proxy ervoor hangen), met telefoons (want alles op iOS en Android werkt gegarandeerd zonder IPv4), maar IPv4 is praktisch gezien nog niet echt uit te faseren op 'gemixte' netwerken met desktops en ander networked spul als printers, vrijwel iedereen doet dat vooralsnog met dual stack.
Windows 10/11 werkt prima in een dual stack v4+v6 omgeving, honderden miljoenen gebruikers hebben dat. Onder andere alle vaste-lijn Ziggo en KPN klanten in Nederland.
[Voor 19% gewijzigd door Dreamvoid op 15-12-2022 12:31]
Port-forwarding is iets van NAT, en dus (grotendeels) een IPv4-hack die bedacht is om met het gebrek aan adressen om te gaan.
Met IPv6 doe je dus niet aan port-forwarding. In plaats daarvan zet je in de firewall op je router (of net waar je edge-firewalling doet) een regel die verkeer toestaat van het internet naar de poort op het IPv6-adres van het "interne" device (zoals een webserver).
Dus ipv port forward (extern):443 -> (intern):443 wordt het src: any dst:(intern) service:443 action:allow
Het is dus niet zozeer omzetten naar een ander soort port forward, het is omzetten naar een firewall-regel. Toegegeven, bij een port forward hoort ook een firewall-regel, maar heel veel firewalls/routers doen dat onderwater (of hebben überhaupt geen firewall van WAN naar LAN omdat verkeer dat niet bij een NAT-regel of port forward hoort er toch niet door komt omdat de router niet weet waar het verkeer naartoe moet).
"Your life is yours alone. Rise up and live it." - Richard Rahl Rhàshan - Aditu Sunlock
Met IPv6 doe je dus niet aan port-forwarding. In plaats daarvan zet je in de firewall op je router (of net waar je edge-firewalling doet) een regel die verkeer toestaat van het internet naar de poort op het IPv6-adres van het "interne" device (zoals een webserver).
Dus ipv port forward (extern):443 -> (intern):443 wordt het src: any dst:(intern) service:443 action:allow
Het is dus niet zozeer omzetten naar een ander soort port forward, het is omzetten naar een firewall-regel. Toegegeven, bij een port forward hoort ook een firewall-regel, maar heel veel firewalls/routers doen dat onderwater (of hebben überhaupt geen firewall van WAN naar LAN omdat verkeer dat niet bij een NAT-regel of port forward hoort er toch niet door komt omdat de router niet weet waar het verkeer naartoe moet).
Vraag ik me wel af of er binnen IPv6 nog zaken bedacht zijn om iets als dit alsnog te kunnen doen. En daarme wil ik dus zeggen: een IP adres 'naar buiten' onafhankelijk laten zijn van welk stukje hardware 'binnen' het nu daadwerkelijk host.
Dan denk ik bijv. aan een webserver in je netwerk welke je ooit gaat vervangen met nieuwe hardware. Met standaard IPv6 krijgt de nieuwe machine een ander IP en zou je dus al je verwijzingen hiernaar (directe IP links, DNS entries, etc) moeten aanpassen. Dus dan zou het wel fijn zijn dat of je router hier wat aan vertaling doet of dat je ook een 2e 'vast' IP kan toekennen aan de vervangen hardware. En dat laatste dan het liefste via iets vergelijkbaar met een fixed DHCP entry, zodat je dit hele verhaal op 1 plek (je router) kan inrichten ipv. op verschillende plekken (op ieder apparaat los dingen instellen).
You see things; and you say, "Why?" But I dream things that never were; and I say, "Why not?"
Vraag ik me wel af of er binnen IPv6 nog zaken bedacht zijn om iets als dit alsnog te kunnen doen. En daarme wil ik dus zeggen: een IP adres 'naar buiten' onafhankelijk laten zijn van welk stukje hardware 'binnen' het nu daadwerkelijk host.
Dan denk ik bijv. aan een webserver in je netwerk welke je ooit gaat vervangen met nieuwe hardware. Met standaard IPv6 krijgt de nieuwe machine een ander IP en zou je dus al je verwijzingen hiernaar (directe IP links, DNS entries, etc) moeten aanpassen. Dus dan zou het wel fijn zijn dat of je router hier wat aan vertaling doet of dat je ook een 2e 'vast' IP kan toekennen aan de vervangen hardware. En dat laatste dan het liefste via iets vergelijkbaar met een fixed DHCP entry, zodat je dit hele verhaal op 1 plek (je router) kan inrichten ipv. op verschillende plekken (op ieder apparaat los dingen instellen).
Je kan gewoon statisch een IPv6 adres aan een server geven. Zodra je die vervangt geef je gewoon een ander apparaat dat adres.
ShadowLord schreef op donderdag 15 december 2022 @ 15:16:
Vraag ik me wel af of er binnen IPv6 nog zaken bedacht zijn om iets als dit alsnog te kunnen doen. En daarme wil ik dus zeggen: een IP adres 'naar buiten' onafhankelijk laten zijn van welk stukje hardware 'binnen' het nu daadwerkelijk host.
Oh, maar NAT (en daarmee port forwards) kunnen binnen IPv6 zeker. Het is alleen (over het algemeen) niet meer nodig. In plaats daarvan kun je de poort op de firewall open zetten.
Met standaard IPv6 krijgt de nieuwe machine een ander IP
Dat hoeft niet, je kunt ook gewoon adressen vast opgeven. En voor servers is het volgens mij (maar ik ben geen expert) gebruikelijk om een vast adres te nemen, juist omdat ze voor anderen bereikbaar moeten zijn en je dus niet het risico wil lopen dat ze via SLAAC of DHCPv6 ineens een ander adres krijgen.
Je zou de nieuwe server dus hetzelfde adres kunnen geven. Je zou zelfs de server een bepaald adres kunnen geven voor beheer, en de dienst die aangeboden wordt een ander adres, zodat je losse diensten kunt verhuizen naar andere servers. Je hebt immers 1,8*1019 adressen per /64
Als voorbeeld een webserver met 2 websites. Je geeft dan de server 3 adressen:
2001:db8::1 voor server01.shadowlord.tld
2001:db8::2 voor website1.com
2001:db8::3 voor website2.nl
Als je dan een nieuwe server wil voor alleen website2.nl dan geef je de nieuwe server 2001:db8::4, en verhuis je adres 2001:db8::3 van de oude naar de nieuwe server.
"Your life is yours alone. Rise up and live it." - Richard Rahl Rhàshan - Aditu Sunlock
Paul schreef op donderdag 15 december 2022 @ 15:27:
[...]
Je zou de nieuwe server dus hetzelfde adres kunnen geven. Je zou zelfs de server een bepaald adres kunnen geven voor beheer, en de dienst die aangeboden wordt een ander adres, zodat je losse diensten kunt verhuizen naar andere servers. Je hebt immers 1,8*1019 adressen per /64
Als voorbeeld een webserver met 2 websites. Je geeft dan de server 3 adressen:
2001:db8::1 voor server01.shadowlord.tld
2001:db8::2 voor website1.com
2001:db8::3 voor website2.nl
Als je dan een nieuwe server wil voor alleen website2.nl dan geef je de nieuwe server 2001:db8::4, en verhuis je adres 2001:db8::3 van de oude naar de nieuwe server.
Dat kan, maar dat lost het probleem van ShadowLord niet op Dan heb je nog steeds een IP (of eigenlijk, een heleboel...) aan een machine hangen ipv aan een dienst, en als je die machine vervangt dan moet je extern iets aanpassen. Tenzij je de machine 1:1 vervangt en alle diensten overzet naar de nieuwe machine en dus de hele /64 meeneemt.
"Your life is yours alone. Rise up and live it." - Richard Rahl Rhàshan - Aditu Sunlock
xbeam schreef op woensdag 14 december 2022 @ 19:53:
Dat is met ipv4 ook nooit nodig.Het gaat fout dat veel beheerders de verkeerde oplossing kiezen en mensen via bijv een veel te resources intensieve VPN’s wil laten verbinding en daar mee ook nog eens hun netwerken blootstellen aan all rotzooi die gebruikers prive over hun netwerk binnen halen en op hun pc hebben draaien In 99 procent van de gevallen (Developers en beheerders daar gelaten) hebben gebruikers alleen toegang tot een drive , Exchange en wat interne web applicaties nodig.
Dat kan je veel beter via bijv ZTNA over het internet beschikbaar maken.
Ik heb daar zeer beperkte kennis over, maar wat ik er wel over weet zorgt ervoor dat ik met een aantal issues zit wat dat hele gedoe betreft :
- Vaak zit je daarmee te werken vanuit een Microsoft en dus Windows oogpunt.
Wat er dus ook voor zorgt dat een lullige brakke Windows Update het een en ander kan slopen zonder dat je het door hebt!
- Waar het op neer kwam is geloof ik dat elke applicatie een eigen SSL VPN achtige verbinding opbouwt richting een resource wat er dus ook weer voor zorgt dat je hardware meer verbindingen moet kunnen verwerken!
- Hoe zit het met non-Windows Clients
En dan bedoel ik dus niet alleen een Mac/Linux/*BSD Client maar ook een telefoon of tablet...
Tegenover al die dingen staat dus een VPN en daarvan weet je tenminste één ding zeker : Die is op bijna elk apparaat wel aan de praat te krijgen!
ANdrode schreef op woensdag 14 december 2022 @ 21:03:
Zero trust netwerk oplossingen zijn lastig aan beheerders uit te leggen. Jammer, want het is een veel betere ervaring, veiliger, én geeft veel betere performance.
Vertel!
Dreamvoid schreef op donderdag 15 december 2022 @ 12:12:
IPv4 is praktisch gezien nog niet echt uit te faseren op 'gemixte' netwerken met desktops en ander networked spul als printers, vrijwel iedereen doet dat vooralsnog met dual stack.
* nero355 browsed effe naar de webGUI van zijn stokoude Samsung CLP-365W en ziet daar... jawel... IPv6 features
ShadowLord schreef op donderdag 15 december 2022 @ 15:16:
Dan denk ik bijv. aan een webserver in je netwerk welke je ooit gaat vervangen met nieuwe hardware. Met standaard IPv6 krijgt de nieuwe machine een ander IP en zou je dus al je verwijzingen hiernaar (directe IP links, DNS entries, etc) moeten aanpassen. Dus dan zou het wel fijn zijn dat of je router hier wat aan vertaling doet of dat je ook een 2e 'vast' IP kan toekennen aan de vervangen hardware. En dat laatste dan het liefste via iets vergelijkbaar met een fixed DHCP entry, zodat je dit hele verhaal op 1 plek (je router) kan inrichten ipv. op verschillende plekken (op ieder apparaat los dingen instellen).
Ik mag hopen dat je Servers dan wel belangrijke netwerkapparatuur een Statisch IP adres hebben en een DHCP Reservering alleen "voor het geval dat" aanwezig is
Paul schreef op donderdag 15 december 2022 @ 15:27:
Dat hoeft niet, je kunt ook gewoon adressen vast opgeven. En voor servers is het volgens mij (maar ik ben geen expert) gebruikelijk om een vast adres te nemen, juist omdat ze voor anderen bereikbaar moeten zijn en je dus niet het risico wil lopen dat ze via SLAAC of DHCPv6 ineens een ander adres krijgen.
Je zou de nieuwe server dus hetzelfde adres kunnen geven. Je zou zelfs de server een bepaald adres kunnen geven voor beheer, en de dienst die aangeboden wordt een ander adres, zodat je losse diensten kunt verhuizen naar andere servers. Je hebt immers 1,8*1019 adressen per /64
Als voorbeeld een webserver met 2 websites. Je geeft dan de server 3 adressen:
2001:db8::1 voor server01.shadowlord.tld
2001:db8::2 voor website1.com
2001:db8::3 voor website2.nl
Als je dan een nieuwe server wil voor alleen website2.nl dan geef je de nieuwe server 2001:db8::4, en verhuis je adres 2001:db8::3 van de oude naar de nieuwe server.
Paul schreef op donderdag 15 december 2022 @ 16:36:
Dat kan, maar dat lost het probleem van ShadowLord niet op Dan heb je nog steeds een IP (of eigenlijk, een heleboel...) aan een machine hangen ipv aan een dienst, en als je die machine vervangt dan moet je extern iets aanpassen. Tenzij je de machine 1:1 vervangt en alle diensten overzet naar de nieuwe machine en dus de hele /64 meeneemt.
In de hosting wereld is het niet heel ongewoon om in een dergelijk situatie gewoon de HDD's over te zetten naar de nieuwe Server
Je had weleens klanten die zoiets deden :
- Huidige Server : HPE DL100 of 300 Serie en een LSI HBA dan wel HPE P4xx RAID Controller.
- Nieuwe Server : Volgende generatie uit die reeks (G8/G9/enz.) en dus ook de opvolgende HPE P4xx RAID Controller of de HBA ging gewoon mee.
De RAID Controller migraties waren soms een beetje tricky maar zolang je alles netjes deed en je aan de regels/beperkingen hield dan ging het meestal wel goed!
Tailscale heeft een goede uitleg (tailscale is mooi). De kern is dat je de grens van je netwerk niet meer op de fysieke laag of per subnet ziet maar per device - en elk device minimale permissies geeft.
De office VPN van een kantoormedewerker hoeft niet bij de staging omgeving van de developers. De developers hoeven vrijwel altijd niet bij productie. Als je dit integreert in een VPN client die ook de identiteit van het device controleert dan kan je makkelijk:
Minimale permissies hebben per gebruiker en device
Het kopiëren van permissies van device x naar y zonder toestemming voorkomen
Ik moest ook gelijk aan Routers en Routing Protocols denken bij het lezen van dat stukje : Mooie feature!
Er staat een bird config bij: Dit is echt gewoon BGP naar de host. Erg leuke architectuur - maar als software engineer nooit zelf opgezet.
Ik heb daar zeer beperkte kennis over, maar wat ik er wel over weet zorgt ervoor dat ik met een aantal issues zit wat dat hele gedoe betreft :
- Vaak zit je daarmee te werken vanuit een Microsoft en dus Windows oogpunt.
Wat er dus ook voor zorgt dat een lullige brakke Windows Update het een en ander kan slopen zonder dat je het door hebt!
- Waar het op neer kwam is geloof ik dat elke applicatie een eigen SSL VPN achtige verbinding opbouwt richting een resource wat er dus ook weer voor zorgt dat je hardware meer verbindingen moet kunnen verwerken!
- Hoe zit het met non-Windows Clients
En dan bedoel ik dus niet alleen een Mac/Linux/*BSD Client maar ook een telefoon of tablet...
Tegenover al die dingen staat dus een VPN en daarvan weet je tenminste één ding zeker : Die is op bijna elk apparaat wel aan de praat te krijgen!
Windows heeft niet zo veel ZTNA te maken en allees werkt ook Android, linux. MacOS en IOS. Over vpn remote diensten zoals Rdp en SSH zijn zijn ook geen probleem.
[...]
Vertel!
Zie je eigen post
Ik Wil best een keer onder jou werk tijd van de baas met een cloudflare of watchguard pet op een half dagje jouw kant op komen voor een goeie bak koffie
Ztna vs VPN
[Voor 27% gewijzigd door xbeam op 16-12-2022 10:24]
Tailscale heeft een goede uitleg (tailscale is mooi). De kern is dat je de grens van je netwerk niet meer op de fysieke laag of per subnet ziet maar per device - en elk device minimale permissies geeft.
Zo effe snel lees ik vooral veel reclame en te weinig van dit :
ANdrode schreef op woensdag 14 december 2022 @ 21:03:
Zero trust netwerk oplossingen zijn lastig aan beheerders uit te leggen. Jammer, want het is een veel betere ervaring, veiliger, én geeft veel betere performance.
De office VPN van een kantoormedewerker hoeft niet bij de staging omgeving van de developers. De developers hoeven vrijwel altijd niet bij productie. Als je dit integreert in een VPN client die ook de identiteit van het device controleert dan kan je makkelijk:
Minimale permissies hebben per gebruiker en device
Het kopiëren van permissies van device x naar y zonder toestemming voorkomen
Hebben we dat niet al jarenlang in de vorm van RADIUS Authentication
Er staat een bird config bij: Dit is echt gewoon BGP naar de host. Erg leuke architectuur - maar als software engineer nooit zelf opgezet.
Bedoelde meer dat zelfs een 10 jaar oude Printer blijkbaar IPv6 heeft dus als je straks nog steeds een Printer hebt die geen IPv6 heeft dan wordt het echt tijd om die te vervangen!
Ik Wil best een keer onder jou werk tijd van de baas met een cloudflare of watchguard pet op een half dagje jouw kant op komen voor een goeie bak koffie
Gaat gij nu zegen dat gij genen koffie lust.
Denk neem je een keer 15 min mee in de wondere wereld van cloudflare en ZTNA (Zoe ingewikkeld is het allemaal niet) de rest van de tijd was om over mijn Bovinophobia heen te komen en mijn nieuwsgierigheid wie er nu echt schuil gaat achter Fear my cow’s of anders gezegd de Romeinse keizer Nero die we moet vrezen
[Voor 90% gewijzigd door xbeam op 17-12-2022 14:22]
Denk neem je keer 15 min mee in de wondere wereld van cloudflare en ZTNA (Zoe ingewikkeld is het allemaal niet)
Ik hoop eerlijk gezegd dat ik daar nooit mee te maken zal krijgen : Laat mij maar lekker rommelen met netwerkapparatuur en Linux/*BSD bakken die daar niks mee doen!
Beetje spelen met nieuwe hardware mag ook!
in de rest van de tijd was om over mijn Bovinophobia heen te komen
offtopic: Ik heb hier in de buurt een mooie Hooglanders familie waarmee je mooi kan oefenen als ze weer eens op het pad staan en heel veel mensen dan ineens niet verder durven te lopen!
Terwijl het gewoon lieve koeien zijn!
en en nieuwsgierigheid wie er nu echt schuilgaat achter gaat achter Fear my cow’s of anders gezegd de Romeinse keizer Nero die we moet vrezen [Afbeelding]
offtopic: LOL!
In principe is er een groepje medeTweakers uit Fotografie, video en design die wel weten wie ik ben vanwege de meetings waar ik heen ben geweest in het verleden!
nero355 schreef op vrijdag 16 december 2022 @ 15:33:
Bedoelde meer dat zelfs een 10 jaar oude Printer blijkbaar IPv6 heeft dus als je straks nog steeds een Printer hebt die geen IPv6 heeft dan wordt het echt tijd om die te vervangen!
Printer fabrikanten zijn wel aardig bij de tijd (er zijn veel bedrijven die IPv6 eisen dus dat rolt dan door naar het hele gamma), maar ga je naar consumenten spul als smart tv's of spelcomputers kijken (Nintendo Switch bv) dan wordt er ook nu nog een hoop spul verkocht dat niet werkt zonder IPv4. Dus zitten we nog wel een tijdje vast aan dual stack.
Een jaar of 10-15 geleden eens een eerste poging gedaan om IPv6 aan de praat te krijgen. Destijds zonder resultaat (d.w.z. geen native IPv6 connectivity en (te!)veel “gedoe” met betaversies).
De afgelopen week eens een nieuwe poging gedaan. Met als insteek een IPv6-only netwerk wat is gebaseerd op het IPv6 netwerk adres van KPN. Tot nu toe met hetzelfde resultaat (min-of-meer): alleen als een endpoint rechtstreeks op de KPN-EB is aangesloten is native-IPv6 connectivity mogelijk.
Voor endpoints die via de Omada- of de OpnSense router zijn aangesloten blijft alles enkel via IPv4 werken.
De uitgangspunten achter de inrichting:
Een eigen router (Omada of OpnSense) achter die van KPN (EB10A)
De prefix van het segment tussen de eigen- en KPN-router blijkt “2a02:a458:ba4:1::/64 ” te zijn (en is niet aan te passen?).
Alle IPv6-instellingen via SLAAC en stateless DHCPv6.
Deze IPv6-instellingen uitdelen via DNSMASQ (als onderdeel van PiHole) met de config-regel (voorbeeld): dhcp-range=2a02:a458:ba4:139::,ra-stateless,ra-names,ra-advrouter.
Achter de Omada-router leven verschillende vlans; elk met hun eigen /24 IPv4 subnet.
Deze subnet-nummers worden tevens gebruikt als onderdeel van de /64 prefix voor de IPv6 kant van de vlans – een paar voorbeelden:
Alle testen zijn uitgevoerd middels een Windows 10 en een MacOS endpoint. Omdat Windows 10 het meest gebruikt is (naast wat Android devices) heb ik deze testresultaten als leidend beschouwt. De resultaten verschillen weinig met die van MacOS.
De IPv6 instellingen van het Windows station staan op "automatically only". De IPv4 instellingen zijn uitgeschakeld. Uit bovenstaand overzicht blijkt dat KPN "iets" heeft lopen waardoor het meteen werkt. Waaronder het local-link adres van de EB10A als default gateway. En "twee" DNS-servers die via poort 53 en 54 aangesproken kunnen worden (?).
Hoe dan ook - deze resultaten heb ik vervolgens vertaalt naar instellingen voor de Omada router:
WAN-kant: Dynamic IP (SLAAC/DHCPv6) en "get IPv6 address automatically"
De DNS-server blijkt te kloppen - maar de default gateway niet. Dat is het local-link adres van de ethernet aansluiting van het systeem waar PiHole/DNSMASQ op draait. Bij de testen met de MAC staan hier ook de DNS-servers van Google...
Ook blijkt het routing overzicht gegevens te bevatten van de prefix tussen de Omada- en KPN-router (geldt ook voor de MAC) - geen idee langs welke weg die daar terecht zijn gekomen...
Iemand een idee waar ik de fout in ga? En hoe op te lossen? Anders dan het IPv6 adres van de DNS-server en de default gateway hardcoded op te nemen in de DNSMASQ-config?
Airw0lf schreef op zondag 18 december 2022 @ 14:02:
Een jaar of 10-15 geleden eens een eerste poging gedaan om IPv6 aan de praat te krijgen. Destijds zonder resultaat (d.w.z. geen native IPv6 connectivity en (te!)veel “gedoe” met betaversies).
De afgelopen week eens een nieuwe poging gedaan. Met als insteek een IPv6-only netwerk wat is gebaseerd op het IPv6 netwerk adres van KPN. Tot nu toe met hetzelfde resultaat (min-of-meer): alleen als een endpoint rechtstreeks op de KPN-EB is aangesloten is native-IPv6 connectivity mogelijk.
Voor endpoints die via de Omada- of de OpnSense router zijn aangesloten blijft alles enkel via IPv4 werken.
De uitgangspunten achter de inrichting:
Een eigen router (Omada of OpnSense) achter die van KPN (EB10A)
De prefix van het segment tussen de eigen- en KPN-router blijkt “2a02:a458:ba4:1::/64 ” te zijn (en is niet aan te passen?).
Alle IPv6-instellingen via SLAAC en stateless DHCPv6.
Deze IPv6-instellingen uitdelen via DNSMASQ (als onderdeel van PiHole) met de config-regel (voorbeeld): dhcp-range=2a02:a458:ba4:139::,ra-stateless,ra-names,ra-advrouter.
Achter de Omada-router leven verschillende vlans; elk met hun eigen /24 IPv4 subnet.
Deze subnet-nummers worden tevens gebruikt als onderdeel van de /64 prefix voor de IPv6 kant van de vlans – een paar voorbeelden:
Alle testen zijn uitgevoerd middels een Windows 10 en een MacOS endpoint. Omdat Windows 10 het meest gebruikt is (naast wat Android devices) heb ik deze testresultaten als leidend beschouwt. De resultaten verschillen weinig met die van MacOS.
De IPv6 instellingen van het Windows station staan op "automatically only". De IPv4 instellingen zijn uitgeschakeld. Uit bovenstaand overzicht blijkt dat KPN "iets" heeft lopen waardoor het meteen werkt. Waaronder het local-link adres van de EB10A als default gateway. En "twee" DNS-servers die via poort 53 en 54 aangesproken kunnen worden (?).
Hoe dan ook - deze resultaten heb ik vervolgens vertaalt naar instellingen voor de Omada router:
WAN-kant: Dynamic IP (SLAAC/DHCPv6) en "get IPv6 address automatically"
De DNS-server blijkt te kloppen - maar de default gateway niet. Dat is het local-link adres van de ethernet aansluiting van het systeem waar PiHole/DNSMASQ op draait. Bij de testen met de MAC staan hier ook de DNS-servers van Google...
Ook blijkt het routing overzicht gegevens te bevatten van de prefix tussen de Omada- en KPN-router (geldt ook voor de MAC) - geen idee langs welke weg die daar terecht zijn gekomen...
Iemand een idee waar ik de fout in ga? En hoe op te lossen? Anders dan het IPv6 adres van de DNS-server en de default gateway hardcoded op te nemen in de DNSMASQ-config?
Je eigen router dient prefix delegation te gebruiken op het wan gekoppeld naar een lan vlan. Anders weet de KPN router nooit wat er achter jouw router leeft.
Daarna stapsgewijs pingen. Naar de gateway vanaf een cliënt. En vanaf de router naar de EB10A of ipv6.Google.com
stormfly schreef op zondag 18 december 2022 @ 15:08:
Je eigen router dient prefix delegation te gebruiken op het wan gekoppeld naar een lan vlan.
Anders weet de KPN router nooit wat er achter jouw router leeft.
Het probleem begint al bij zijn "NAT achter NAT" opstelling : Die ExperiaBox kan je amper instellen en moet je een hoop automatische rommel van accepteren helaas...
IMHO kom je een flink stuk verder als je dat kreng uit de opstelling haalt, maar dan moet je ook met het IPTV gedoe aan de gang als je dat afneemt en dat kan soms echt heel ellendig zijn zonder KPN eigen apparatuur!
Zo vaak gezien in [Ubiquiti & IPTV] Ervaringen & Discussie namelijk :
- Je krijgt alles werkend.
- Het gaat een hele tijd goed.
- En dan komt er toch opeens een ERROR!!! tevoorschijn die alleen maar verdwijnt als je toch weer effe dat IPTV kreng achter de ExperiaBox zet!
Maar goed...
Het houdt je uit de kou op het moment zullen we maar zeggen!
Het probleem begint al bij zijn "NAT achter NAT" opstelling : Die ExperiaBox kan je amper instellen en moet je een hoop automatische rommel van accepteren helaas...
[...]
Het houdt je uit de kou op het moment zullen we maar zeggen!
Het houdt me inderdaad uit de kou... klopt.
Maar hoe zie je dat met NAT-achter-NAT i.c.m. IPv6?
Ik had begrepen dat zoiets niet bestaat als je werkt met SLAAC en stateless DHCPv6?
Geen idee eerlijk gezegd, want nog nooit mee gestoeid
Ik zou wel wat kunnen bedenken, maar dan moet toch echt die ExperiaBox eruit dus zolang je die daar houdt dan heeft het geen nut om daar verder over te discussiëren...
Ik volg het niet helemaal, maar kun je niet een prefix delegation uit een KPN box peuteren. Ik dacht van wel. Dan moet het toch redelijk out of the box kunnen werken.
Maar hoe zie je dat met NAT-achter-NAT i.c.m. IPv6?
Ik had begrepen dat zoiets niet bestaat als je werkt met SLAAC en stateless DHCPv6?
Hoe dit zou moeten werken is dat de eerste router (EB10A) als een soort ISP zou moeten werken met prefix delegation. Dus aan de WAN kant krijg hij een /48 prefix van KPN. De EB10A zou deze /48 moeten verdelen naar bijv. /56 prefixes en deze uitdelen aan de 2de laag routers over DHCP. Dus elke router in de 2de laag krijgt een /56 toegewezen van de 1ste router (EB10A).
Vervolgens kunnen de 2de laags routers er een /64 prefix van maken en deze /64 prefix aan de (v)lan kant advertisen naar de end-client. Die maken er vervolgens zelf een /128 adres van met slaac.
Wat jij nu doet is dat je na de EB10A al een /64 prefix hebt (namelijk 2a02:a458:ba4:1::/64). Bij IPv6 zijn de laatste 64 bits voor de 'end-point' om er met slaac een uiteindelijk IPV6 /128 adres van te maken.
De sleutel zit hem er dus in om de EB10A delen van de /48 prefixes uit te laten delen als /56 prefixes aan de routers. Ik weet alleen niet of dit mogelijk is met de EB10A (denk het niet eigenlijk).
Hoe dit zou moeten werken is dat de eerste router (EB10A) als een soort ISP zou moeten werken met prefix delegation. Dus aan de WAN kant krijg hij een /48 prefix van KPN. De EB10A zou deze /48 moeten verdelen naar bijv. /56 prefixes en deze uitdelen aan de 2de laag routers over DHCP. Dus elke router in de 2de laag krijgt een /56 toegewezen van de 1ste router (EB10A).
Vervolgens kunnen de 2de laags routers er een /64 prefix van maken en deze /64 prefix aan de (v)lan kant advertisen naar de end-client. Die maken er vervolgens zelf een /128 adres van met slaac.
Wat jij nu doet is dat je na de EB10A al een /64 prefix hebt (namelijk 2a02:a458:ba4:1::/64). Bij IPv6 zijn de laatste 64 bits voor de 'end-point' om er met slaac een uiteindelijk IPV6 /128 adres van te maken.
De sleutel zit hem er dus in om de EB10A delen van de /48 prefixes uit te laten delen als /56 prefixes aan de routers. Ik weet alleen niet of dit mogelijk is met de EB10A (denk het niet eigenlijk).
Bedankt voor de uitgebreide reactie - wordt zeer gewaardeerd!
Even hardop lezend/denkend (met een IPv4 perspectief): vanwaar die "tussenstap" met /56?
Met twee routers achter de EB en een prefix van /48 maakt beiden toch evengoed uniek op basis van het local-link adres (wat een onderdeel is van het IPv6 adres)?
Dat zou dan voldoende moeten zijn om onderscheid te maken tussen de achterliggende vlans/subnets?
Voor de volledigheid :
Via de OpnSense router heb ik nu IPv6 connectivity naar het WAN/EB. Daarbij maakt het niet uit of ik /48 of /56 gebruik - beiden werken hiermee.
De Omada router lijkt verder niks te doen met deze prefix: nada IPv6 connectivity richting het WAN/EB.
Aan de LAN-kant van de EB (d.w.z. tabje Connected Devices) worden beide routers gezien met een IPv6 adres met prefix "2a02:a458:ba4:1" en een local-link adres. Dat local-link adres zie ik ook terug in het IPv6 adres (uiteraard zonder FE80).
Nu alleen nog de LAN/client kant van beide eigen routers - dat wil nog niet vlotten.
OpnSense wil daar perse full DHCPv6 gebruiken; dus inclusief het uitdelen van IPv6 adressen, gateway en DNS-servers.
Waardoor ik moet gaan nadenken wat dan weer handige reeksen zijn => nog suggesties?
Als het dan toch moet zou ik die reeksen het liefst gelijk houden aan die van IPv4: 11 t/m 59.
Airw0lf schreef op maandag 19 december 2022 @ 13:42:
Even hardop lezend/denkend (met een IPv4 perspectief): vanwaar die "tussenstap" met /56?
Met twee routers achter de EB en een prefix van /48 maakt beiden toch evengoed uniek op basis van het local-link adres (wat een onderdeel is van het IPv6 adres)?
Dat zou dan voldoende moeten zijn om onderscheid te maken tussen de achterliggende vlans/subnets?
Ehm... dat adres is niet routeerbaar hé!
De naam zegt het al : Het is een LOKAAL adres!
Verder is het nou eenmaal gewoon zo ooit bedacht dus daar doe je weinig aan denk ik...
Nu alleen nog de LAN/client kant van beide eigen routers - dat wil nog niet vlotten.
OpnSense wil daar perse full DHCPv6 gebruiken; dus inclusief het uitdelen van IPv6 adressen, gateway en DNS-servers.
Ik kan me haas niet voorstellen dat de *sense achtigen geen SLAAC doen eerlijk gezegd
Dat zou IMHO gewoon raar zijn, want je hebt dan een probleem met sommige Clients die of geen DHCPv6 accepteren of geen SLAAC accepteren!
Verder is het nou eenmaal gewoon zo ooit bedacht dus daar doe je weinig aan denk ik...
[...]
Ik kan me haas niet voorstellen dat de *sense achtigen geen SLAAC doen eerlijk gezegd
Dat zou IMHO gewoon raar zijn, want je hebt dan een probleem met sommige Clients die of geen DHCPv6 accepteren of geen SLAAC accepteren!
Een lokaal adres wat begint met fe80 is inderdaad niet routeerbaar. Maar ik zie dat dat lokale adres ook gebruikt worden door fe80 te vervangen met (in mijn geval) zoiets als 2a02-a458-ba4-<vlan>. Waarbij dat "<vlan>" iets is wat ik er aangeplakt heb. Vanaf dat moment is het wel te gebruiken om te routeren - toch?
Ik heb niet de intentie om iets aan de werking te veranderen. Maar wil wel graag begrijpen hoe "het" bedoeld is te werken; idealiter inclusief de variabelen en de invloed van elk van die variabelen op "het". Met in het bijzonder de werking van "het" i.c.m. OpnSense - want die invulling begrijp ik nog niet zo.
[Voor 4% gewijzigd door Airw0lf op 19-12-2022 17:31]
Maar ik zie dat dat lokale adres ook gebruikt worden door fe80 te vervangen met (in mijn geval) zoiets als 2a02-a458-ba4-<vlan>.
Waarbij dat "<vlan>" iets is wat ik er aangeplakt heb.
Vanaf dat moment is het wel te gebruiken om te routeren - toch?
Klopt! Maar dan is het een Global Address geworden en geen Link-Local meer!
Ik heb niet de intentie om iets aan de werking te veranderen.
Maar wil wel graag begrijpen hoe "het" bedoeld is te werken; idealiter inclusief de variabelen en de invloed van elk van die variabelen op "het".
Met in het bijzonder de werking van "het" i.c.m. OpnSense - want die invulling begrijp ik nog niet zo.
Ooit had ik een leraar die altijd zei : "Noem het beestje bij zijn naampje!"
Kortom : Wees eens wat duidelijker, want ik begrijp er geen bal van!
Klopt! Maar dan is het een Global Address geworden en geen Link-Local meer!
[...]
Ooit had ik een leraar die altijd zei : "Noem het beestje bij zijn naampje!"
Kortom : Wees eens wat duidelijker, want ik begrijp er geen bal van!
Ow - ok - wist niet dat er een stikker voor was - anders dan een uitvoeringsvorm van een IPv6 adres...
En v.w.b. dat "beestje-en-zijn-naam" (op een eerder moment aangeduid met "het" ):
Geen idee hoe je het samenspel tussen de verschillende soorten IPv6 adressen en de relevante instellingen van Ubuntu, dnsmasq, OpnSense en Omada zou kunnen labellen. Maar als je er één stikker op wil/kunt plakken... be my guest...
Airw0lf schreef op maandag 19 december 2022 @ 17:48:
Geen idee hoe je het samenspel tussen de verschillende soorten IPv6 adressen en de relevante instellingen van Ubuntu, dnsmasq, OpnSense en Omada zou kunnen labellen. Maar als je er één stikker op wil/kunt plakken... be my guest...
Broddelwerk
V.w.b. fat de link local & publieke IPv6 adressen dezelfde suffix hebben. Dat zal vast ermee te maken hebben dat het (gebaseerd is op) het MAC adres. Waarbij je op PC / ... dan twee publieke IPv6 adressen krijgt. Eentje die vast is en je kunt gebruiken voor inkomende verbindingen (en dus ook voor in DNS etc) en dat is dus (een afgeleide van) het MAC adres. En daarnaast dat willekeurige privacy adres dat regelmatig wijzigd voor uitgaande verbindingen zodat je niet getrackt kan worden online.
Edit:
Zo te zien heb ik op mijn (Android) telefoon zelfs (ook) 5 IP adressen. De link local, twee publieke, en ik heb nog een local dingetje met fd00:<vlan id>:: voor wat statische adressen (interne DNS bv) en daarvan heeft telefoon er ook 2. Maar ze zijn wel allemaal uniek / ik zie er geen dubbele suffixen in zoals jij ziet. Maar dat ligt vast ook aan het apparaat / OS hoe die per interface de suffixes bepaald.
[Voor 19% gewijzigd door RobertMe op 19-12-2022 18:14]
V.w.b. fat de link local & publieke IPv6 adressen dezelfde suffix hebben. Dat zal vast ermee te maken hebben dat het (gebaseerd is op) het MAC adres. Waarbij je op PC / ... dan twee publieke IPv6 adressen krijgt. Eentje die vast is en je kunt gebruiken voor inkomende verbindingen (en dus ook voor in DNS etc) en dat is dus (een afgeleide van) het MAC adres. En daarnaast dat willekeurige privacy adres dat regelmatig wijzigd voor uitgaande verbindingen zodat je niet getrackt kan worden online.
Om in die context maar eens voorbeeld te noemen:
Bij Ubuntu is dat net iets anders dan bij een MAC - om nog maar te zwijgen van Windows - daar heb ik tot nu toe 5 of 6 verschillende IPv6 adressen voorbij zien komen...
En dat is dan zonder vlans... ben benieuwd wat dat nog gaat brengen...
Verder is het nou eenmaal gewoon zo ooit bedacht dus daar doe je weinig aan denk ik...
[...]
Ik kan me haas niet voorstellen dat de *sense achtigen geen SLAAC doen eerlijk gezegd
Dat zou IMHO gewoon raar zijn, want je hebt dan een probleem met sommige Clients die of geen DHCPv6 accepteren of geen SLAAC accepteren!
@Airw0lf, OPNSense (en PfSense verwacht ik ook) ondersteund inderdaad gewoon SLAAC en DHCPv6 voor IPv6
Onder het kopje "Services" kun je kiezen voor "Router Advertisements" en na het selecteren van de netwerk adapter kun je kiezen voor:
Select which flags to set in Router Advertisements sent from this interface. Use "Router Only" to disable Stateless Address Autoconfiguration (SLAAC) and DHCPv6, "Unmanaged" for SLAAC (A flag), "Managed" for Stateful DHCPv6 (M+O flags), "Assisted" for Stateful DHCPv6 and SLAAC (M+O+A flags), or "Stateless" for Stateless DHCPv6 and SLAAC (O+A flags).
Ik ben aan het zoeken hoe IPv6 op mijn "thuisserver" / "NAS" / ... te gebruiken. Op PC / telefoon / ... werkt het al een tijd prima, nu eens het "infrastructuur" VLAN om gooien. Dit wil ik dan doen op Proxmox (host) als Debian based LXC containers.
Om iets met statische adressen te doen zonder 100% statisch te gaan (want Ziggo levert natuurlijk geen statisch adres) kom ik uit op iets met ip token set ::dead:beef/64 dev eth0. Maar om mijzelf een hoop gepruts, frustraties en downtime ver voorkomen zou ik willen weten of anderen hier dit al gedaan hebben / een voorbeeld hebben. Ik gok dat dit commando (uiteraard in aangepaste vorm) als zodanig opgenomen kan worden in /etc/network/interfaces{,.d/*}. Maar zou daar graag iets van bevestiging / voorbeeld van zien als iemand dat heeft . Waarbij ik mij ook afvraag of ik met de Debian LXCs zomaar in die file kan gaan zitten frotten. Volgens mij wordt die namelijk elke boot opnieuw gegenereerd uit de host. Maar mogelijk dat dat deel dan in /etc/network/interfaces.d/ kan en LXC zelf de /etc/network/interfaces config file genereerd.
Voor systemd-network ziet het er dan weer wel vrij eenvoudig uit incl. voorbeeld in de man page
Examples:
code:
1
2
Token=eui64
Token=::1a:2b:3c:4d
bron
Maarja, daar heb ik niks aan, want Debian gebruikt dat niet
@Airw0lf, OPNSense (en PfSense verwacht ik ook) ondersteund inderdaad gewoon SLAAC en DHCPv6 voor IPv6
Onder het kopje "Services" kun je kiezen voor "Router Advertisements" en na het selecteren van de netwerk adapter kun je kiezen voor:
[...]
Klopt inderdaad - maar krijg ik pas te zien na:
(1) - IPv6 config type op track interface te zetten
(2) - IPv6 Prefix ID inte vullen
(3) - Vinkje te zetten bij "Allow manual adjustment of DHCPv6 and Router Advertisements"
Na dat stukje configuratiewerk gedaan te hebben werkt het toch nog niet.
Dat wil zeggen de MAC krijgt alleen IPv4 gegevens. En van IPv6 alleen de DNS-server.
Terwijl beiden op automatisch staan...
De NDP table laat wel de nodige fe80 adressen zien.
En ook een global IPv6 WAN adres (wat begint met 2a02:a458:ba4:1).
Maar verder geen - wat volgens mij wel zou moeten?
De handleiding van OpnSense helpt hier ook niet echt...
Iemand nog tips; misschien zelfs een voorbeeld?
Zie ook afbeelding:
Er wordt gesproken over een prefix-id om de /64 prefix in te stellen.
Waar zou ik dat id dan kunnen koppelen aan een /64 prefix?
[Voor 36% gewijzigd door Airw0lf op 20-12-2022 11:30]
Bedankt voor de uitgebreide reactie - wordt zeer gewaardeerd!
Even hardop lezend/denkend (met een IPv4 perspectief): vanwaar die "tussenstap" met /56?
Met twee routers achter de EB en een prefix van /48 maakt beiden toch evengoed uniek op basis van het local-link adres (wat een onderdeel is van het IPv6 adres)?
Dat zou dan voldoende moeten zijn om onderscheid te maken tussen de achterliggende vlans/subnets?
Voor de volledigheid :
Via de OpnSense router heb ik nu IPv6 connectivity naar het WAN/EB. Daarbij maakt het niet uit of ik /48 of /56 gebruik - beiden werken hiermee.
De Omada router lijkt verder niks te doen met deze prefix: nada IPv6 connectivity richting het WAN/EB.
Aan de LAN-kant van de EB (d.w.z. tabje Connected Devices) worden beide routers gezien met een IPv6 adres met prefix "2a02:a458:ba4:1" en een local-link adres. Dat local-link adres zie ik ook terug in het IPv6 adres (uiteraard zonder FE80).
Nu alleen nog de LAN/client kant van beide eigen routers - dat wil nog niet vlotten.
OpnSense wil daar perse full DHCPv6 gebruiken; dus inclusief het uitdelen van IPv6 adressen, gateway en DNS-servers.
Waardoor ik moet gaan nadenken wat dan weer handige reeksen zijn => nog suggesties?
Als het dan toch moet zou ik die reeksen het liefst gelijk houden aan die van IPv4: 11 t/m 59.
Het klopt dat de adresssen op je vlan (bijv. 2a02:a458:ba4:139::) nu globaal uniek zijn. Echter zijn deze niet routeerbaar. Omdat het de voorgaande hop niet bekend is hoe ze bij deze IP adresens moeten komen. En link local adressen beginnend met (fe80) kunnen alleen binnen de lan gebruikt worden.
Ik zal het proberen te illustreren met een analogy. U bent vast bekend met het fiets kruispunten netwerk in NL. Als u van A naar B wilt fietsen, maakt u een lijst van alle knooppunten waar u langs moet fietsen om op de bestemming te komen. Echter, met alleen deze lijst zult u uw bestemming niet vinden. Er is meer info nodig, namelijk op elke kruispunt. Wanneer u op een kruispunt aankomt staan er bordjes op het kruispunt welke kant u op moet om bij het volgende kruispunt te komen. Dus op de kruispunten is alleen info over de route naar het volgende kruispunten.
Dit is het zelfde met IP routering. Je kan het ip adres zijn als een lange lijst met kruispunten waar je langs moet om bij de eindbestemming te komen. Waarbij elk stukje van het ip adres (tot /64 in het geval bij IPv6) een kruispunt beschrijft. Waarbij het 'subnetmask' een indicatie is hoe dicht je bij de eindebestemming bent.
Dus het ip pakket is op weg van de server naar een eind client op je netwerk. Hij is al tot je ISP gekomen met het /40 subnetmask. Hier komt hij bij de router en vraagt, hoe kom ik bij dit ip adres. De router aldaar zegt, weet ik niet, maar wat ik wel weet is dat als je dit draadje neemt (link1), dan kom je bij 2a02:a458:ba4:::/48 (uw router). Dus dan denkt het ip pakket, mooi laat ik deze link nemen en dan ben ik weer een stap dichter bij mijn bestemming. Dus het pakket volgt de link en komt bij uw router (EB10A) aan. Hier vraagt hij wederom, hoe kom ik bij dit adres? EN hier gaat het mis. want jouw router is alleen maar bekend met het /64 adres 2a02:a458:ba4:1::/64, dus de router heeft geen idee welke link er genomen moet worden om bij de eind bestemming aan te komen. Het packet wordt dus ter zijde geschoven en zal nooit de eind bestemming bereiken.
Dus wanneer router (EB10A) wel prefix delegation heeft gedaan met een /56 subnetmask, is deze informatie wel bekend bij de EB10A. Namelijk er staat in de routing tabel, welk /56 ip adres bij welke link hoort. (dus volgens de analogy zijn de juiste bordjes op het kruispunt geplaatst). Dan kan het ip adres dus wel naar de juiste 2de router door verwezen worden en zal het pakket uiteindelijk de eindbestemming bereiken.
Vandaar dat de onderverdeling naar /56 subnetten nodig is.
De discussies die hierboven plaatsvinden zijn allemaal goed en leerzaam! Fijn dat mensen de tijd nemen elkaar dingen te leren.
De basis hier achter is echter routering: Onder IPv4 en IPv6 het zelfde.
IPv6 heeft een paar mooie technieken zoals DHCPv6 Prefix Delegation en SLAAC, maar in de basis kan je met IPv6 ook gewoon een statisch gerouteerd netwerk neerzetten zoals je dat met IPv4 zou doen,
Vergeet NAT, denk aan gewoon echt routeren zoals het internet is: P2P
Dan is IPv6 los van de lengte van het adres eigenlijk bijna het zelfde als IPv4.
De basis hier achter is echter routering: Onder IPv4 en IPv6 het zelfde.
IPv6 heeft een paar mooie technieken zoals DHCPv6 Prefix Delegation en SLAAC, maar in de basis kan je met IPv6 ook gewoon een statisch gerouteerd netwerk neerzetten zoals je dat met IPv4 zou doen,
Vergeet NAT, denk aan gewoon echt routeren zoals het internet is: P2P
Dan is IPv6 los van de lengte van het adres eigenlijk bijna het zelfde als IPv4.
Ja precies dit
Heb van mijn provider een /56 en een /126 gateway en 'customer router' adres (transit netwerkje) gekregen.
Het /56 subnet verdeel je zelf over je vlans als /64 subnetten.
Alleen nog een statische default route naar het gateway adres en alles werkt simpel en overzichtelijk.
Heb van mijn provider een /56 en een /126 gateway en 'customer router' adres (transit netwerkje) gekregen.
Het /56 subnet verdeel je zelf over je vlans als /64 subnetten.
Alleen nog een statische default route naar het gateway adres en alles werkt simpel en overzichtelijk.
Klopt.
Niets anders dan een /30 IPv4 interconnect subnet tussen je ISP en jouw router die vervolgens een /21 IPv4 naar jouw router zijn adres routeert. Die knip je daarna weer op in enkele /24 IPv4 subnets.
Allemaal statisch te configureren net zoals je dat met IPv6 zou kunnen doen.
Dat je vervolgens met DHCP(v6) aan de slag wil gaan in de LAN segmenten voor adresuitgifte is een ander verhaal.
Routing is routing en dat is al jarenlang het zelfde. Een router kijkt naar het dst IP van een pakketje en routeert die verder. Deze kijkt met Ipv6 naar een 128-bit dst adres waar het altijd 32-bits was.
[Voor 24% gewijzigd door Snow_King op 20-12-2022 17:08]
@Jef61 en @Snow_King : ik zie dat ook zo en probeer dat ook voor elkaar te krijgen via die delegate functies. Maar tot nu toe zonder succes.
KPN komt binnen met een /48 prefix. Die probeer ik via /56 naar twee routers te verdelen. Om van daaruit weer verder te gaan met /64 voor de individuele vlans. De endpoints krijgen dan iets met /128...
Aan de Omada/TP-link kant heb ik het al opgegeven - hun IPv6 implementatie is gewoon bagger en werkt voor geen meter...
Aan OpnSense kant lijkt het beter te werken. En ben ik nu aan het grasduinen in de pfSense docs om te begrijpen hoe e.e.a. ingesteld zou moeten worden i.c.m. een /64 prefix - tot nu toe zonder positief resultaat.
Ik ben nu een paar dagen bezig met een serieuze poging de principe werking van IPv6 te begrijpen. En deze vervolgens te vertalen naar een router configuratie - in dit geval de OpnSense variant. Maar die laatste stap lijkt geen eenvoudige.
Het (voor mij) grootste gemis is het gebrek aan use cases (met instellingen!) - laat staan iets wat enigszins aansluit bij hetgeen ik voor elkaar probeer te krijgen: een paar vlans/"subnetten" waarbij de default gateway (als ik het zo mag noemen), DNS- en NTP servers via DHCPv6 uitgedeeld worden (analoog aan IPv4 en idealiter met dnsmasq).
Dat laatste met het idee dat de IPv6 adressen via een prefix en SLAAC tot stand komen. Dus voor endpoints liefst geen vaste of via DHCPv6 uitgedeelde IPv6 adressen.
Tenzij ik dat alles verkeerd begrepen heb...
@MaartenBW
Unne dikke merci voor je uitgebreide verklaring - zo had ik er nog niet naar gekeken - heeft inderdaad veel weg van de traditionele IPv4 aanpak.
[Voor 8% gewijzigd door Airw0lf op 20-12-2022 17:48]
Wil je het /48 subnet doormidden hakken en verdelen of probeer je 2 stuks /56 netwerken verder te routeren?
Als je doormidden wilt hakken moet je 2x een /49 netwerk routeren.
2x een /56 netwerk verder routeren kan natuurlijk ook maar dan moet je dat wel op de juiste manier doen (en je gooit een hoop weg, hoewel dat bij IPv6 niet zo'n rol speelt )
Wil je het /48 subnet doormidden hakken en verdelen of probeer je 2 stuks /56 netwerken verder te routeren?
Als je doormidden wilt hakken moet je 2x een /49 netwerk routeren.
2x een /56 netwerk verder routeren kan natuurlijk ook maar dan moet je dat wel op de juiste manier doen (en je gooit een hoop weg, hoewel dat bij IPv6 niet zo'n rol speelt )
Dat /48 subnet komt binnen via een KPN-EB model 10A. Daar zou ik graag twee eigen routers achter willen plakken - elk met hun eigen set van vlans/subnetten. En of dat dan met een /50 prefix is of groter (bijvoorbeeld /57), dat maakt me verder niet zoveel.
Ik meen ergens gelezen te hebben dat een /64 prefix bij SLAAC verplicht is. Dus de tweede laag routers zou een prefix moeten krijgen die ligt tussen 48 en 64. En dan ligt 56 precies in het midden (hoewel verder wellicht niet eens niet relevant)...
Achter een router komen max. 5 vlans en achter de andere max 3 - althans - zo is het nu met IPv4 ingericht. De IPv4 adressen beginnen allemaal 192.168.X.Y/24 - het derde octet is dan het vlan en zou ik een onderdeel willen maken van een IPv6 adres en zijn prefix.
Dat zijn zo een beetje de uitgangspunten waarop ik afgelopen weekend gestart ben (of eigenlijk al een jaar of 10-15 terug)...
[Voor 18% gewijzigd door Airw0lf op 20-12-2022 19:18]
Is het eigenlijk zo dat in de praktijk men gewoon Link-Local gebruikt voor hetzelfde doel of toch niet ??
Ik heb namelijk ooit begrepen dat één van de IPv6 voordelen is dat we eindelijk van die ellendige /30 interconnects af zijn en alles via Link-Local gaan doen om te "neighbouren"
Aan OpnSense kant lijkt het beter te werken. En ben ik nu aan het grasduinen in de pfSense docs om te begrijpen hoe e.e.a. ingesteld zou moeten worden i.c.m. een /64 prefix - tot nu toe zonder positief resultaat.
Airw0lf schreef op dinsdag 20 december 2022 @ 19:03:
Dat /48 subnet komt binnen via een KPN-EB model 10A. Daar zou ik graag twee eigen routers achter willen plakken - elk met hun eigen set van vlans/subnetten. En of dat dan met een /50 prefix is of groter (bijvoorbeeld /57), dat maakt me verder niet zoveel.
Als je nou eens begint met die OPNsense bak als de "Core Router" in je netwerk dan heb je kans dat het ooit gaat werken!
KPN als WAN van een willekeurige non-KPN Router instellen is zo gedaan :
- VLAN 6
- PPPoE met username en password kpn/kpn of internet/internet of wat je ook leuk vindt...
Als je nou eens begint met die OPNsense bak als de "Core Router" in je netwerk dan heb je kans dat het ooit gaat werken!
KPN als WAN van een willekeurige non-KPN Router instellen is zo gedaan :
- VLAN 6
- PPPoE met username en password kpn/kpn of internet/internet of wat je ook leuk vindt...
En gaan met die banaan!
Nou eehhh - liever niet - ik wil geen gedoe met die KPN-TV/Media-doosjes!
Bovendien... het IPv4 verkeer komt zonder problemen OpnSense en de EB door . Daar zou ik IPv6 dan aan toe willen voegen .
Als ik OpnSense een connectivity audit laat doen komt ie ook via IPv6 zonder problemen de EB door!
Dus tja... ook hier geen aanleiding om die EB er tussenuit te halen...
Het enige wat ik nu niet voor elkaar krijg is IPv6 connectivity via de vlans/subnetten aan de LAN-kant van OpnSense.
=====
Edit 21:30
Hieronder de IPv6 connectivity test resultaten en de instellingen van de DMZ/WAN-poort van OpnSense. Deze poort is aangesloten op de KPN EB - er zit geen switch of iets meer tussen.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Checking connectivity for host: opnsense-update.deciso.com -> 2001:1af8:4700:a137:12::2
PING6(1548=40+8+1500 bytes) 2a02:a458:ba4:1:ce3:4dff:feca:e7d4 --> 2001:1af8:4700:a137:12::2
1508 bytes from 2001:1af8:4700:a137:12::2, icmp_seq=0 hlim=57 time=4.999 ms
1508 bytes from 2001:1af8:4700:a137:12::2, icmp_seq=1 hlim=57 time=4.861 ms
1508 bytes from 2001:1af8:4700:a137:12::2, icmp_seq=2 hlim=57 time=4.790 ms
1508 bytes from 2001:1af8:4700:a137:12::2, icmp_seq=3 hlim=57 time=5.197 ms
--- 2001:1af8:4700:a137:12::2 ping6 statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 4.790/4.962/5.197/0.155 ms
Checking connectivity for repository (IPv6): https://opnsense-update.deciso.com/${SUBSCRIPTION}/FreeBSD:13:amd64/22.10
Updating OPNsense repository catalogue...
Fetching meta.conf: . done
Fetching packagesite.pkg: .......... done
Processing entries: .......... done
OPNsense repository update completed. 817 packages processed.
All repositories are up to date.
[Voor 44% gewijzigd door Airw0lf op 20-12-2022 21:41. Reden: Testresultaten en config bijgevoegd.]
Ik heb namelijk ooit begrepen dat één van de IPv6 voordelen is dat we eindelijk van die ellendige /30 interconnects af zijn en alles via Link-Local gaan doen om te "neighbouren"
Bij mijn vorige provider was de gateway idd een link-local adres maar dat ging via een auto connect protocol (hoefde zelf geen default gateway in te brengen).
Als je de routering statisch wil configureren lijkt me dat je zelf het transit netwerk moet configureren.
Bij mijn huidige provider zijn dit geen link-local adressen maar public IPv6 adressen van de priovider zelf. Heb dus zelf een default gateway ingebracht. Lijkt me dat je hiervoor (in je eigen netwerk) ook private IPv6 adressen voor zou kunnen gebruiken (fc00::/7)
Het probleem begint al bij zijn "NAT achter NAT" opstelling : Die ExperiaBox kan je amper instellen en moet je een hoop automatische rommel van accepteren helaas...
IMHO kom je een flink stuk verder als je dat kreng uit de opstelling haalt, maar dan moet je ook met het IPTV gedoe aan de gang als je dat afneemt en dat kan soms echt heel ellendig zijn zonder KPN eigen apparatuur!
Ah, een router achter een router . Hoeft op zich geen probleem te zijn want NAT achter NAT heeft niets te maken met IPv6 door 2 routers routeren. Probleem zal idd zijn dat die KPN box niet te configureren is. Ik zou zeggen routeer het hele /48 IPv6 subnet door naar de volgende router en ga daar verder opdelen.
Lukt dat niet dan de ExperiaBox vervangen (door een Mikrotik bv, dan ben je voorlopig ook van straat ).
Is het eigenlijk zo dat in de praktijk men gewoon Link-Local gebruikt voor hetzelfde doel of toch niet ??
Ik heb namelijk ooit begrepen dat één van de IPv6 voordelen is dat we eindelijk van die ellendige /30 interconnects af zijn en alles via Link-Local gaan doen om te "neighbouren"
Klopt. Je kan het allemaal via LL doen. Je ziet dat DHCPv6+PD dat eigenlijk ook altijd doet. Je kan ook gewoon een /64 pakken.
Zo hebben wij een /48 genaamd "interconnect" waaruit we /64s halen voor de interconnect subnets tussen onze routers en switches. Omdat we BGP gebruiken hebben we wel GUA adressen nodig om die BGP sessies over te configureren.
Nu gebruiken we ook BGP unnumbered (RFC5549) en daar wordt LL wel gebruikt.
Maar mijn punt is vooral: Routing met IPv6 is niet anders dan met IPv4.
Ah, een router achter een router . Hoeft op zich geen probleem te zijn want NAT achter NAT heeft niets te maken met IPv6 door 2 routers routeren. Probleem zal idd zijn dat die KPN box niet te configureren is. Ik zou zeggen routeer het hele /48 IPv6 subnet door naar de volgende router en ga daar verder opdelen.
Lukt dat niet dan de ExperiaBox vervangen (door een Mikrotik bv, dan ben je voorlopig ook van straat ).
Wat zou er op die EB ingesteld moeten kunnen worden?
Zou vervangen door de KPN-Fritzbox helpen?
Kun je een 'statische route' of 'static route' inbrengen op die EB? lijkt me van niet...?
Op een Fritzbox kan dat volgens mij wel, heb ooit een Fritzbox gehad in mijn xs4all tijd maar dat is alweer lang geleden (en misschien is het een door KPN aangepaste Fritzbox met weer beperkingen?).
Let op: Let op: Blijf netjes reageren, en laat dit topic niet verzanden in een "wellus / nietus" discussie.. Opmerkingen als "het werkt hier ook" zijn ook niet gewenst.
Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.
Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.
Functioneel en analytisch
Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie.
Meer details
janee
Relevantere advertenties
Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht.
Meer details
Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.
Ingesloten content van derden
Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden.
Meer details
:strip_icc():strip_exif()/u/340735/crop6448f8f93e3de.jpg?f=community)
/u/11437/wandcontactdoos.png?f=community)
/u/3626/front-kabels.png?f=community)
Ipv4
Ipv6:strip_icc():strip_exif()/u/371543/pirat60.jpg?f=community)
. Het lijkt mij juist voor de grote telecomboeren makkelijker om CGNAT in te zetten omdat juist daar 75% of meer van het klantenbestand er geen benul van heeft. En die 25% wat dat wel heeft je gewoon publiek IPv4 op aanvraag levert.
:strip_exif()/u/26026/snowrabb.gif?f=community)
/u/127261/crop5dcd39ec2f45d_cropped.png?f=community)
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/bHuaqEivFyWWNLh4PMURQnTJ.jpg?f=user_large "https://tweakers.net/i/Z4umh7lefwrYm_sKxL9iPFZ6eDs=/full-fit-in/4920x3264/filters:max_bytes(3145728):no_upscale():strip_icc():fill(white):strip_exif()/f/image/bHuaqEivFyWWNLh4PMURQnTJ.jpg?f=user_large")
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/42KinzrSevAvmzH2TetHFZsO.jpg?f=user_large "https://tweakers.net/i/B2D49EH-Lgw_bkBdnru_Q6lGohc=/full-fit-in/4920x3264/filters:max_bytes(3145728):no_upscale():strip_icc():fill(white):strip_exif()/f/image/42KinzrSevAvmzH2TetHFZsO.jpg?f=user_large")
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/hED1raof0LQJYYaQazx3OoAn.jpg?f=user_large "https://tweakers.net/i/BxAiQ1j1on4J06TbCcJ8y1HJP0k=/x800/filters:strip_icc():strip_exif()/f/image/hED1raof0LQJYYaQazx3OoAn.jpg?f=fotoalbum_large")
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/GSIqP0SzLJGhnfsOzlFDRGAD.jpg?f=user_large "https://tweakers.net/i/1yjf9VKu3NT1dZoV-K1foCGZ6sM=/x800/filters:strip_icc():strip_exif()/f/image/GSIqP0SzLJGhnfsOzlFDRGAD.jpg?f=fotoalbum_large")
:strip_icc():strip_exif()/u/144633/crop643e593ea432f_cropped.jpg?f=community)
/u/53007/DustPuppy.png?f=community)
:strip_exif()/u/49248/DPCkoeienUD.gif?f=community)
In 99 procent van de gevallen (Developers en beheerders daar gelaten) hebben gebruikers alleen toegang tot een drive , Exchange en wat interne web applicaties nodig. /u/8555/Shadow_60x60.png?f=community)
Dan heb je nog steeds een IP (of eigenlijk, een heleboel...) aan een machine hangen ipv aan een dienst, en als je die machine vervangt dan moet je extern iets aanpassen. Tenzij je de machine 1:1 vervangt en alle diensten overzet naar de nieuwe machine en dus de hele /64 meeneemt.
:no_upscale():strip_icc():fill(white):strip_exif()/f/image/zKlncZGJGYE1pfAhvmReRiZZ.jpg?f=user_large "https://tweakers.net/i/5nWnJDixgwbYCWGS7x8ojPVYppk=/800x/filters:strip_icc():strip_exif()/f/image/zKlncZGJGYE1pfAhvmReRiZZ.jpg?f=fotoalbum_large")
:strip_exif()/u/262016/Hipska.gif?f=community)
:strip_icc():strip_exif()/u/671790/crop56cef352f3117_cropped.jpeg?f=community)
/u/363743/crop61aa1329d36b8_cropped.png?f=community)
:fill(white):strip_exif()/f/image/kQiBfqo69Kvj43IwDNpswd6n.png?f=user_large "https://tweakers.net/i/wYUlnzqYvM-sbbRzpUB4YB_eXag=/800x/filters:strip_exif()/f/image/kQiBfqo69Kvj43IwDNpswd6n.png?f=fotoalbum_large")
/u/358033/crop6238ef90ce5cf_cropped.png?f=community)
. Daar zou ik IPv6 dan aan toe willen voegen :fill(white):strip_exif()/f/image/WMaSby3O78NLq1Ev2Ojt5Nxc.png?f=user_large "https://tweakers.net/i/n9d4MHbbT2VPal4vofQ9wvTAMXg=/800x/filters:strip_exif()/f/image/WMaSby3O78NLq1Ev2Ojt5Nxc.png?f=fotoalbum_large")
