Ik weet niet precies sinds wanneer maar het is wel erg onhandig.
Voorheen zat ik in een ipv6 block wat begon met 2001:1c05:2427:d700 en dan nog wat nummers.
Die 2001:1c05 zijn gelijk gebleven maar die andere twee getallen zijn veranderd zonder waarschuwing.
Geen idee waarom.
Mijn ipv4 is wel hetzelfde gebleven.
Dus vraag ik mij af waarom dat niet bij de ipv6 ook het geval is.
Op enkele plekken moet ik namelijk extern mijn ip adres vrij geven en gezien ipv6 vaker gebruikt wordt moet ik nu beiden vrijgeven (voor de ipv6 een /56 blok).
Waarom blijft dit niet relatief vast net zoals de ipv4? En hoe vaak kunnen we zo'n wisseling nu gaan verwachten?
Opgelost! Ga naar oplossing.
Jij bent de IT-hulplijn in je straat, de verlichting werkt thuis op commando en je groet de pakketbezorger met de slimme deurbel. Herkenbaar? Dan zijn de Community events echt iets voor jou! Doe mee en sluit je aan.
Juist, ik begrijp het. Maar als je dan in plaats van \\10.0.0.30\ de DNS naam \\nas3\ opgeeft, dan zal er een verbinding over IPv6 worden opgebouwd.
SMB draait boven op TCP/IP. Een netwerk protocol is opgebouwd uit lagen. Onder heb je ethernet, daarbovenop IP, daarbovenop TCP, en daar weer bovenop SMB. Op IP niveau wordt met IP adressen een verbinding opgebouwd, dan dan over ethernet loopt SMB zelf bouwt geen verbinding op.
Offtopic en toch weer niet.
Ik heb nog een leuke voor de experts hier:
Als ik onder macOS mijn LAN webserver op een Debian 12 PC probeer te bereiken met http://[fe80::1234:5678:90ab:cdef] dan lukt dat niet. En ook niet met http://[fe80::1234:5678:90ab:cdef%en0]:80. De browser gaat direct naar Google en lijkt dit niet te herkennen als valide IPv6 adres.
curl -6 http://[fe80::1234:5678:90ab:cdef%en0]:80 levert dan weer wel het verwachte resultaat op. (curl -6 http://[fe80::1234:5678:90ab:cdef] overigens niet. Dit werkt dan weer wel onder linux.
ULA adressen zijn zo niet werkbaar. Of zie ik (zoals gebruikelijk) weer wat voor de hand liggends over het hoofd?
Ik kan mijn webserver en andere apparaten binnen het LAN zonder problemen op hun resp. LLA bereiken in de browser, zonder het poortnummer of de scope/interface op te geven.
Maar gebruik je ook macOS?
Met linux (debian) kukt dat prima en Windows 11 moet ik morgen nog even testen, maar dus vanuit deze versie van macOS niet. Dit lijkt een bekend issue, maar maakt de gebruikswaarde van ULA wel een stuk minder.
Ik doe dus voorlopig maar alles via GUA (en/of IPv4).
Ik gebruik Windows 10 en Firefox 129.0.2.
Ik benader LAN hosts vrijwel nooit meer via IP-adres, enkel op hostname, ofwel bekend bij de DHCPv4-server of handmatig ingesteld in geval van een host met statisch IP-adres. Firefox kiest echter altijd het IPv4-adres als voor een hostname alleen IPv4 + IPv6 LLA (en geen GUA en/of ULA) bekend zijn.
De IPv4 en IPv6 adressen van de server toegevoegd aan het hosts file van de linux PC waarop DNSmasq draait.
Dat werkt pima omdat het via GUA gaat.
nslookup server.lan
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: server.lan
Address: 192.168.1.123
Name: server.lan
Address: 2001:1c03:1234:5678:90ab:cdef:1234:5678
Name: server.lan
Address: fe80::1234:5678:90ab:cdef
Met fe80::1234:5678:90ab:cdef heb ik dus problemen, na een goede nachtrust maar eens verder bekijken.
Dat zijn geen ULA adressen, dat zijn LLA adressen. Bij mij lukt http://[fdee::3ea6:2fff:fe57:2a4a]/ prima om vanuit firefox bij mijn Fritz!box te komen.
Standaard staat het begin van ULA adressen altijd op fd00, maar je kunt het hele deel t/m fdff gebruiken. Ik gebruik fdee.
ULA adressen moeten wel door je router geannonceerd worden, net zo als GUA adressen.
@caesarals ik nu \\nas-naam\ in geef werkt dat ook want dat werkt via SMB. Alleen is bijv. een van mijn NAS namen AS-304T en ik verander die namen niet omdat ik ze origineel leuker vind en die ip's toch uit mijn hoofd weet.
Maar dat is dus in elk geval geen verschil met de huidige situatie.
Dat van die lagen was me bekend, maar ik begreep even niet hoe je dat bedoelde dat er geen verbinding gemaakt kon worden. Ja als je via de layers gaat kijken dan niet nee. SMB gaat via tcp/ip mee, uiteraard wordt de verbinding op ip opgezet.
Nu ben ik niet diepgaand bekend met de layer kennis, maar weet wel van het bestaan ervan en van meerdere protocollen.
Ik ga even mee off-topic.
Nu lees ik echter weer iets anders wat ik niet begrijp. Die FE80 adressen zijn toch allemaal link-local adressen? Ik dacht (maar ik weet nog weinig van ipv6) dat die alleen voor interne verbinding binnen ipv6 zelf waren en niet voor je webserver mee te bezoeken.
Daar is dan toch dat ULA voor of niet?
Of is het toch de bedoeling dat je die link-local adressen gebruikt?
Ik kan met mijn gateway link local ip fe80::7eff:4dff:fed7:8368%6 niet de Fritz bereiken. En dat is met de ULA actief zoals jij aanraadde.
Ook weer iets wat ik niet ken, waarom zitten hier % tekens in?
Zoals je weet zijn LLA adressen niet routeerbaar, ULA adressen wel. Ik vermoed dat Firefox alleen maar routeerbare adressen accepteert, en dus geen LLA adressen.
Je gebruikt geen ULA adres maar een LLA adres, die beginnen met fe80:
Je kunt de Fritz bereiken met een adres dat begint met fd00 (als je dat niet aangepast hebt).
Die % cijfers hebben te maken met interne Windows toewijzingen, die maken geen deel uit van het IPv6 adres.
Ik ken geen Link local adressen die met Fd00 beginnen, ook op mijn Windows PC en alle servers beginnen die met FE80.
Zelfde dus wat Marinus probeerde te gebruiken. Ik dacht uit jouw post te begrijpen dat jij daar ook de Fritz mee bereikte. Dan is dat een vergissing mijnerzijds.
Wat ik nu zo raar vindt is dat dit ULA adres niet in de pc als gateway staat zoals met ipv4. Dan kijk je naar het gateway adres en dan heb je het router ip. Dat is dus met ipv6 niet, daar krijg je het LLA te zien en daarmee krijg geen verbinding in de browser. Vervelend verschilletje.
Want dan moet je dus in de Fritzbox gaan kijken wat diens ULA is, in plaats van dat je dat via ipconfig kunt opzoeken.
Dus maar eens een ipconfig /all gedaan en dan heb ik een DNS met 10.0.0.2 (ipv4 fritz) en een ULA fd21:17:63:68:7eff:4dff:fed7:8368 maar daar is ie ook niet op te bereiken.
Dat is de ULA die ik zelf gemaakt heb in de Fritzbox. Maar hoe kom ik nu dan aan de juiste ULA om dat ding te bereiken zoals jij dat doet?
Wat gaat er nu mis?
Die % zou te maken hebben met het scope id las ik ergens, geen idee wat dat is maar dat is zorg voor later als ik wat meer ipv6 geleerd heb.
@Richard G.Als jij \\nas-naam\ opgeeft, dan zal jouw PC bij de Fritz!box via DNA de IP adressen van nas-naam opvragen. Dan komen er vier adressen terug, het IPv6 LLA adres, het IPv6 ULA adres, het IPv6 GUA adres, en het IPv4 adres. De PC zal dan het IPv6 ULA adres gaan gebruiken.
Als jouw AS-304T ook zo in de Fritz!box geregistreerd staat, dan kun je dus ook \\AS-304T\ opgeven.
In jouw Fritz!box heb je de setting Set ULA prefix manually. Daar staat standaard fd00, ik heb er fdee van gemaakt. Als je die setting actief hebt, dan krijgen al jouw IPv6 apparaten een adres er bij dat begint met deze prefix.
Door bij IPconfig te kijken vind je bij het adres van de DNS server ook het ULA adres van de Fritz!box. Maar als je gewoon fritz.box in de browser opgeeft gaat hij ook via het ULA adres.
Een link-local adres is iets heel anders als een ULA adres. Als op een apparaat een IPv6 stack aanwezig is, dan krijgt iedere interface van dat apparaat altijd een link-local adres, dus ook als er helemaal geen IPv6 netwerk draait.
@caesarV.w.b. die NAS, ja dat zal best, maar wat ik bedoel is dat het qua benaderbaarheid geen verschil maakt met ipv4. Als ik die hele ipv6 uitschakel kan ik die NAS op dezelfde manier benaderen.
Dan die ULA. Zoals ik schreef heb ik die ULA veranderd, bij mij begint die dus met fd21:17:63 dat is wat ik liet zien dat ip. Dat is het ip wat in DNS stond.
En als ik dat in de browser in type, dan krijg ik die Fritzbox niet benaderd. Met Fritz.box wel, dat ging met ipv4 ook, maar vind ik even niet interessant momenteel.
Want als hij via ULA te bereiken moet zijn in de browser, moet ik dat toch ook kunnen, daar gaat het me om? Maar bij mij gaat ie dus vrolijk naar Google. Zowel in de nieuwste Firefox alsook in Chrome. Dus vraag ik me af waarom.
Never mind, ik dacht dat jij die haakjes zette zodat de link niet klikbaar zou zijn.
Maar je moet schijnbaar haakjes zetten in de url balk als je ipv6 gebruikt. Weer zo'n irritant verschil met ipv4.
Dus ja met die haakjes werkt het nu wel. Omslachtig gebeuren.
Ja, een gedoe met die haakjes. En daarom gebruik je dus nooit IP adressen in de URL search balk, maar DNS namen. De mensen die http ontwikkelden hadden eventjes geen rekening gehouden met de IPv6 adres notatie, en gebruikten de ":" voor http.
Tja als dat zo makkelijk ging met die DNS namen, tot en met W10 1709 wel. Ik heb sinds die W10 1801 pc's gezien die gewoon niet zichtbaar te krijgen waren op het netwerk met DNS namen, zelfs niet op ip terwijl ze wel te pingen waren. En daar ben ik behoorlijk goed in thuis, maar niks hielp, ook niets wat op internet te vinden was. Of eenzijdig, eentje zag de ander wel, maar de ander zag de ene niet en dat soort dingen.
Maar dat is weer een heel ander verhaal.
Ipv6 in de adresbalk ga ik sowieso toch niet gebruiken, te lang, kan ik niet onthouden, maar wel een handig wetenswaardigheidje in elk geval.
Achja... het is wennen met ipv6, maar zal er toch van moeten komen, alhoewel ik m'n twijfels heb of ik die tijd nog wel mee ga maken. Volgens mij hebben we over 15 jaar nog steeds ipv4 en ipv6 samen.
IPv6 prefix van Ziggo is hier wel stabiel. Ubee1318 in bridge met opnsense erachter. Voorheen een ERlite. Daarmee kreeg ik bij een reboot geheid een nieuwe prefix. Met opnsense is dat niet zo. Opnsense doet bovendien aan interface tracking. Mocht de prefix toch veranderen, dan worden firewall rules automatisch aangepast. Met ULA doe ik niks tot op heden.
Vul de belangrijkste trefwoorden in en vind het topic die past bij je vraag. Onze community zit boordevol kennis.
Start je eigen topic en krijg hulp van anderen. Op de community helpen ervaren klanten je graag op weg.