Het grote IPv6 topic

[Osiris]

Ik snap niet zo goed waarom DNS sowieso een issue is. Krijgt elke random workstation/laptop/telefoon bij jullie een DNS-entry dan?
Waarom in vredesnaam? En als dat zo'n dynamisch proces is, hoe heb je dat nu onder IPv4 geregeld, want een nieuwe smartphone op je netwerk met een onbekend IPv4-adres zou dan ook voor problemen geven, right?

[CyBeR]

Verwijderd schreef op woensdag 25 september 2013 @ 10:32:
Ik vroeg het gewoon eh, ik ben ook in leerproces. Ik zoek gewoon een manier om ipv6 te configureren zoals ipv4 dat alles dan werkt (voor dns dan). Ik wil niet bij elke nieuwe hosts een script of een tool uitvoeren.

De enige manier om dat te doen is met DHCPv6.

De Privacy Extensions zijn er om een andere reden, namelijk om te zorgen dat je niet over tijd geidentificeerd kunt worden middels je ip-adres; met beveiliging heeft 't niks te maken.

[Verwijderd]

CyBeR schreef op woensdag 25 september 2013 @ 12:02:
[...]


De enige manier om dat te doen is met DHCPv6.

De Privacy Extensions zijn er om een andere reden, namelijk om te zorgen dat je niet over tijd geidentificeerd kunt worden middels je ip-adres; met beveiliging heeft 't niks te maken.

Dus dat is alleen DHCPv6, zonder de RA dan.

[CyBeR]

Ja. SLAAC zelf heeft geen mechanisme om zoiets te doen omdat 't de client is die z'n IP-adres bedenkt, en niet een server.

Enige probleem hiermee is dat niet alle clients DHCPv6 ondersteunen.

[Freeaqingme]

CyBeR schreef op woensdag 25 september 2013 @ 17:11:
Ja. SLAAC zelf heeft geen mechanisme om zoiets te doen omdat 't de client is die z'n IP-adres bedenkt, en niet een server.

Multicast DNS?

[Keiichi]

nieuws: UPC en Ziggo stellen invoering ipv6 uit

UPC en ziggo stellen invoering uit. alweer Hoe moeilijk kan het zijn denk je?

[CyBeR]

Freeaqingme schreef op woensdag 25 september 2013 @ 20:18:
[...]


Multicast DNS?

Dat kan, maar dat is gedecentraliseerd natuurlijk. En los daarvan gebruikt mDNS altijd de link-local (fe80) adressen geloof ik. Sowieso geen PE-adressen want die zijn eigenlijk alleen voor uitgaand gebruik.

[ Voor 28% gewijzigd door CyBeR op 27-09-2013 16:48 ]

[Bigs]

Keiichi schreef op vrijdag 27 september 2013 @ 16:41:
nieuws: UPC en Ziggo stellen invoering ipv6 uit

UPC en ziggo stellen invoering uit. alweer Hoe moeilijk kan het zijn denk je?

Nou als ik bij ons de verhouding IPv6 routerings problemen : IPv4 routerings problemen bekijk dan is het toch behoorlijk moeilijk. Bij veel mensen ligt het gewoon niet zo in de aandacht omdat het weinig wordt gebruikt.

Wel jammer dat UPC geen actie onderneemt. Hulde aan providers die het wel doen. Zelfs mijn lokale glasvezelprovider biedt IPv6!

[joopv]

Keiichi schreef op vrijdag 27 september 2013 @ 16:41:
nieuws: UPC en Ziggo stellen invoering ipv6 uit

UPC en ziggo stellen invoering uit. alweer Hoe moeilijk kan het zijn denk je?

Als je duizenden zakelijke en honderdduizenden particuliere klanten hebt, een grote verscheidenheid aan apparatuur en toeleveranciers en beperkte kennis van je medewerkers kan het (met enig understatement) "best moeilijk" zijn...

Ik heb er maar niet op gewacht en sinds 3 uur vanmiddag heb ik een SixXS tunnel aktief vanaf m'n cisco router naar Surfnet. Dat heeft wel enige effort gekost.

UPC en Ziggo zijn nu eenmaal echte consumenten-massa providers, als je speciale dingen wil moet je bij xs4all gaan.

[Raven]

Bigs schreef op vrijdag 27 september 2013 @ 16:51:
[...]


Nou als ik bij ons de verhouding IPv6 routerings problemen : IPv4 routerings problemen bekijk dan is het toch behoorlijk moeilijk. Bij veel mensen ligt het gewoon niet zo in de aandacht omdat het weinig wordt gebruikt.

Wel jammer dat UPC geen actie onderneemt. Hulde aan providers die het wel doen. Zelfs mijn lokale glasvezelprovider biedt IPv6!

XS4All? Dat is toch de enige glasprovider die het aanbied?

[FatalError]

O.a. Lijbrandt en XMS bieden het ook aan. Zet voor de grap eens 6RD en DHCPv6-PD aan op je router en je krijgt spontaan een IPv6 tunnel en eigen IPv6 subnet.

[Osiris]

Tunnel != native.

[Raven]

With ^

FatalError schreef op vrijdag 27 september 2013 @ 18:22:
O.a. Lijbrandt en XMS bieden het ook aan. Zet voor de grap eens 6RD en DHCPv6-PD aan op je router en je krijgt spontaan een IPv6 tunnel en eigen IPv6 subnet.

en ik heb Concepts.

Overigens valt er in mijn router(-pc) niet veel aan te zetten. Officieel bied IPFire géén ondersteuning voor IPv6, omdat de code van de webinterface een zooi zou zijn en niemand die durft aan te raken. In de volgende branch, wanneer die ooit uitkomt, is dat probleem er niet.

Maar ik heb IPv6 (HE-tunnel) wel werkend weten te krijgen. Alle benodigde modules bleken aanwezig, alleen uitgeschakeld. Na wat trial&error met wat config files werkt mijn HE-tunnel in IPFire.

Er is 1 probleem waar ik vooralsnog geen oplossing voor heb: Er is geen DHCPv6 en geen radvd aanwezig. Commando's om die te installeren (yum/apt-get/dpkg etc) zijn niet beschikbaar... Make overigens wel.

[ Voor 4% gewijzigd door Raven op 27-09-2013 19:32 ]

[MORCIK]

Keiichi schreef op vrijdag 27 september 2013 @ 16:41:
nieuws: UPC en Ziggo stellen invoering ipv6 uit

UPC en ziggo stellen invoering uit. alweer Hoe moeilijk kan het zijn denk je?

Er zijn nog aardig wat oude modems, vooral bij de langzamere abonnementen, in omloop die geen IPv6 ondersteunen. Dan kom je al snel uit bij een tunnel en dat is wat ze net niet willen.

[CyBeR]

MORCIK schreef op zaterdag 28 september 2013 @ 01:39:
[...]

Er zijn nog aardig wat oude modems, vooral bij de langzamere abonnementen, in omloop die geen IPv6 ondersteunen. Dan kom je al snel uit bij een tunnel en dat is wat ze net niet willen.

Oud modem -> geen IPv6 tot je een nieuw modem krijgt.

Overigens alle DOCSIS3 modems kunnen IPv6 aan.

[Maasluip]

CyBeR schreef op zaterdag 28 september 2013 @ 01:43:
[...]

Oud modem -> geen IPv6 tot je een nieuw modem krijgt.

Inderdaad. Dat XS4ALL IPv6 aanbiedt betekent niet dat iedereen die XS4ALL heeft ook via IPv6 surft.

[Osiris]

En is sowieso geen reden om je IPv6-uitrol uit te stellen.

[MORCIK]

CyBeR schreef op zaterdag 28 september 2013 @ 01:43:
Oud modem -> geen IPv6 tot je een nieuw modem krijgt.

Overigens alle DOCSIS3 modems kunnen IPv6 aan.

Het modemgedeelte is nog het eenvoudigst. Maar wat dacht je van de CMTS zijde? Ik kan me voorstellen dat er in een gemixte situatie meer bij komt kijken dan een situatie waar alle modems IPv6 'spreken'. Als het vervangen van modems goedkoper is dan het opbouwen van een configuratie die een gemixte situatie aankan dan kiest een bedrijf voor de goedkoopste oplossing. Dat slechts 2% van de klanten daar anders over denkt deert ze echt niet.

[MORCIK]

Osiris schreef op zaterdag 28 september 2013 @ 13:18:
En is sowieso geen reden om je IPv6-uitrol uit te stellen.

Ik denk niet dat ze iets gaan uitrollen als uit testen blijkt dat het systeem nog te foutgevoelig is. Er zijn genoeg redenen te verzinnen om uitrol uit te stellen.

[Raven]

Osiris schreef op zaterdag 28 september 2013 @ 13:18:
En is sowieso geen reden om je IPv6-uitrol uit te stellen.

Ik geloof dat het niet maken van winst na het invoeren van IPv6 een reden was om er geen vaart achter te zetten. Maar wanneer gaan we in de praktijk nou eigenlijk iets merken van het gebrek aan IPv6 hier? Zijn er al IPv6-only sites waar Europeanen gebruik van ma(a)k(t)en?

[FatalError]

MORCIK schreef op zaterdag 28 september 2013 @ 22:04:
[...]
Het modemgedeelte is nog het eenvoudigst. Maar wat dacht je van de CMTS zijde? Ik kan me voorstellen dat er in een gemixte situatie meer bij komt kijken dan een situatie waar alle modems IPv6 'spreken'.

Ik heb gehoord dat er bij Ziggo bepaalde typen CMTS gebruikt worden in bepaalde regios die niet, of pas sinds kort IPv6 aankunnen. Lijkt me voldoende reden om voorzichtig te zijn met uitrol van IPv6 over deze netwerken.
In een productienetwerk ga je niet zomaar even nieuwe software uitrollen. Daar gaat altijd een testtraject aan vooraf.

[joopv]

Ik heb ipv6 mbv mijn cisco router en een "heartbeat" tunnel (vanuit de router) naar SixXS helemaal ge-enabled. Mijn pc (w7-64b-prof) en android telefoon zijn ok volgens de ipv6 test sites.

Maar mijn werk laptop (eveneens W7-64b-prof) niet. Op die machine kan ik zelfs geen ping ::1 doen, dan krijg ik een transmit failure... Iemand met dezelfde ervaringen?

Ik vermoed een administratieve issue binnen de laptop installatie.

c1841#
c1841#sh ipv6 int fa0/0
FastEthernet0/0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::21B:D4FF:FEC0:4DC4
No Virtual link-local address(es):
Description: Huisnetwerk
Global unicast address(es):
2001:xxxx:xxxx:8A0F::1, subnet is 2001:xxxx:xxxx:8A0F::/64
Joined group address(es):
FF02::1
FF02::2
FF02::1:FF00:1
FF02::1:FFC0:4DC4
MTU is 1500 bytes
ICMP error messages limited to one every 100 milliseconds
ICMP redirects are enabled
ICMP unreachables are sent
ND DAD is enabled, number of DAD attempts: 1
ND reachable time is 30000 milliseconds (using 30000)
ND advertised reachable time is 0 (unspecified)
ND advertised retransmit interval is 0 (unspecified)
ND router advertisements are sent every 200 seconds
ND router advertisements live for 1800 seconds
ND advertised default router preference is Medium
Hosts use stateless autoconfig for addresses.
c1841#

c1841#sh run int fa0/0
Building configuration...

Current configuration : 315 bytes
!
interface FastEthernet0/0
description Huisnetwerk
ip address 192.168.24.2 255.255.255.0
no ip unreachables
ip nat inside
ip virtual-reassembly in
ipv6 address 2001:xxxx:xxxx:8A0F::1/64
ipv6 enable
end

c1841#

[Maurits van Baerle]

FatalError schreef op zondag 29 september 2013 @ 01:24:
[...]


Ik heb gehoord dat er bij Ziggo bepaalde typen CMTS gebruikt worden in bepaalde regios die niet, of pas sinds kort IPv6 aankunnen. Lijkt me voldoende reden om voorzichtig te zijn met uitrol van IPv6 over deze netwerken.
In een productienetwerk ga je niet zomaar even nieuwe software uitrollen. Daar gaat altijd een testtraject aan vooraf.

Dat zou een goede reden kunnen zijn. Wij weten natuurlijk niet hoever ze al zijn achter de schermen, voor hetzelfde geld hebben ze al een hele netwerkstructuur in IPv6 uitgedacht (die er wegens gebrek aan IP schaarste er heel anders uit kan zien dan met IPv4), een groot deel van het netwerk al dual-stack uitgevoerd en zijn er nog één of twee kleine hobbeltjes zoals een provisioning interface of een model CMTS die nog niet helemaal klaar zijn.

Dat er CMTS-en zijn die slecht met IPv6 overweg kunnen verbaast me wel een beetje. Is dat dan erg oude apparatuur? EuroDocsis 3 komt standaard met IPv6 support en er was zelfs een latere EuroDocsis 2.0 variant die IPv6 aankom. Kortom, alle CPE's die de kabelaars de laatste 5+ jaar aan consumenten hebben uitgeleverd ondersteunen allemaal IPv6. Dat er dan nog CMTS-en zijn die het niet ondersteunen verbaast me een beetje, tenzij ze erg oud zijn.

[Bigs]

Raven schreef op vrijdag 27 september 2013 @ 17:53:
[...]

XS4All? Dat is toch de enige glasprovider die het aanbied?

In mijn geval OnsBrabantNet, onderdeel van Reggefiber. Bieden sinds begin dit jaar stilletjes IPv6 via 6rd aan, volgens mij sturen ze inmiddels ook de DHCP optie mee zodat het automatisch geconfigureerd wordt. Tot nu toe werkt het echt uitstekend. Latency en bandbreedtte doen niet onder voor IPv4.

[ik222]

@joopv: Is IPv6 niet gewoon via een GPO disabled op die werklaptop, dat is namelijk een mogelijkheid.

[MORCIK]

Maurits van Baerle schreef op maandag 30 september 2013 @ 10:25:

Dat er CMTS-en zijn die slecht met IPv6 overweg kunnen verbaast me wel een beetje. Is dat dan erg oude apparatuur? EuroDocsis 3 komt standaard met IPv6 support en er was zelfs een latere EuroDocsis 2.0 variant die IPv6 aankom. Kortom, alle CPE's die de kabelaars de laatste 5+ jaar aan consumenten hebben uitgeleverd ondersteunen allemaal IPv6. Dat er dan nog CMTS-en zijn die het niet ondersteunen verbaast me een beetje, tenzij ze erg oud zijn.

De specificatie van DOCSIS 3 en daarmee IPv6 ondersteuning werd in 2006 geïntroduceerd. Cisco had pas enkele jaren later (2008?) de eerste firmware met IPv6-ondersteuning, en ik meen mij te herinneren dat er de nodige bugs in zaten. De firmware stelt bepaalde eisen aan bestaande apparatuur. Verouderde uBR's die toch minstens een afschrijftermijn hebben van 5 jaar kunnen niet gebruikt worden. En als het aan een bedrijf ligt dan wordt apparatuur het liefst benut totdat ze defect zijn.

Maar los van het IPv6-verhaal kunnen er andere bedrijfsmatige redenen zijn om uitrol uit te stellen. Een reden die ik zou kunnen verzinnen is dat ze nu druk zijn met andere problemen, denk aan de problemen met het ontvangstbereik na de introductie van de WiFi-hotspots. Zolang ze intern nog niet op rustig vaarwater zitten, verwacht ik niet dat ze IPv6 gaan uitrollen.

[Keiichi]

Waarom pakken het ze niet ongeveer aan zoals bij xs4all het geval was. Er was eerst volgens mij een heel test traject waar je eigen kon opt-in'en voor ipv6, wel met de duidelijke mededeling dat er geen support op gegeven wordt. Daarna zijn ze enkel nieuwe verbindingen standaard gaan opleveren.

Het lijkt me niet handig om IPv6 in 1x OVERAL gelijk aan te zetten, omdat er dan rustig gekeken kan worden waar het eea nog aan ondersteuning schort.

[joopv]

ik222 schreef op maandag 30 september 2013 @ 13:45:
@joopv: Is IPv6 niet gewoon via een GPO disabled op die werklaptop, dat is namelijk een mogelijkheid.

Bedankt voor je reactie. Nee IPv6 staat niet helemaal uit. Ik kan bepaalde dingen wel doen.

Ik kan wel een ping -6 naar het global ipv6 adres van de router doen.

Nu ik nog eens kijk blijkt de default gateway van m'n laptop het link-local adres te zijn van de router. Dat is niet de bedoeling lijkt me... Er gaat iets fout met de autoconfig.

Samenvattend:
ping -6 ::1 geeft PING: transmit failed. General failure.
ik kan zowel de link-local als het global ipv6 adres pingen vanuit de laptop.
de default-gateway wijst naar de link-local van de router. (FE80::(eui-64))

[Ultraman]

Mja, ik heb hier al tijden een tunnel van Hurricane Electric op mijn UPC verbinding, dat zal nog lekker zo blijven, ding werkt vlekkeloos. Mijn servertje hangt aan XMS, daar heb ik geen HE tunnel meer nodig, want dat 6rd van XMS werkt ook gewoon.

Ik vind het ook jammer dat ze het wederom hebben uitgesteld. IPv6 heeft gewoon zoveel voordelen boven IPv4. Ik vind het onderhand irritant dat ik steeds maar truukjes moet uitvoeren om IPv4 achter de NAT goed te laten werken. Voor IPv6 hoef ik enkel een gaatje in de firewall te prikken, de rest (bijv. DNS) is allemaal simpel. Bij IPv4 moet ik intern in de gaten houden dat ik andere DNS records binnen het netwerk uitdeel voor de machines die de boel lokaal proberen te bereiken via de FQDN.

Hier thuis ga ik denk ik eens stoppen met intern zorgen dat IPv4 ook werkt op FQDN, er wordt toch altijd IPv6 gebruikt omdat het beschikbaar is. Niet dat het megaveel werk zal besparen, intern DNS recordje toevoegen is zo gepiept, maar het voelt gewoon zo stom.

[Osiris]

joopv schreef op maandag 30 september 2013 @ 23:31:
[...]

Nu ik nog eens kijk blijkt de default gateway van m'n laptop het link-local adres te zijn van de router. Dat is niet de bedoeling lijkt me... Er gaat iets fout met de autoconfig.

de default-gateway wijst naar de link-local van de router. (FE80::(eui-64))

Waarom is dat fout?

Enige waar je 'default gateway' voor dient is om somehow achter het MAC-adres van said router te komen. Op IP-niveau gebeurt daar verder niets mee.

Dus als jouw netwerk-stack achter 't MAC-adres van de router kan komen door een link-local-adres te hebben van je default gateway, prima toch?

[CyBeR]

joopv schreef op maandag 30 september 2013 @ 23:31:
[...]
Nu ik nog eens kijk blijkt de default gateway van m'n laptop het link-local adres te zijn van de router. Dat is niet de bedoeling lijkt me... Er gaat iets fout met de autoconfig.

Dat is normaal.

[MORCIK]

XS4ALL is op technisch gebied, mede door z'n klantenkring, vooruitstrevender geweest dan de overige providers die 'internet voor het volk' aanbieden. Ik heb hemel en aarde moeten bewegen om de infrastructuurverantwoordelijke bij een multinational te laten informeren over IPv6, laat staan dat we ermee aan de slag gingen. Bij de CIO hoefde ik al helemaal niet aan te kloppen aangezien hij er geen brood in zag. "Dan gebruiken we toch NAT?" En een systeembeheerder vond NAT 'veiliger' De externe Cisco specialist zag er gewoon geen noodzaak in: "Het gaat toch prima zo?"

Elk bedrijf heeft te maken met dergelijke klassieke discussies tussen techneut en manager. XS4ALL heeft het geluk dat de directie technisch goed onderlegd is. Bovendien hadden kabelmaatschappijen het druk zat met de versnelde overgang van het COM21-platform naar DOCSIS wat zeker t/m 2006 geduurd heeft. Ik ga ook geen druk meer uitoefenen, ik informeer slechts en waarschuw voor de gevaren. Als de zaak ploft komt IPv6 vanzelf

[Raven]

IPv6 vaagheid

Heb eindelijk weer een HE-tunnel in gebruik die lijkt te werken ondanks dat IPFire het officieel niet eens ondersteund. Ik kan vanaf de client ping -6 doen naar ipv6.google.com en www.kame.net, http://test-ipv6.com/ geeft 10/10, maar wel de opmerking dat de browsers IPv6 weigeren te gebruiken, zowel IE/FF als Chrome. Die helaas geen IPv6 sites openen.

Dus de verbinding lijkt er te zijn, maar de browsers doen er niets mee, ra ra hoe kan dat

edit: Vaag, http://ipv6.tunnelbroker.net/ lijkt het wel te doen

[ Voor 10% gewijzigd door Raven op 04-10-2013 11:18 ]

[Keiichi]

pmtu probleem?

[Raven]

Geen flauw idee, hoe kan ik dat testen?

edit: Net een hele lading IPv6-ondersteundende sites geprobeerd. De meeste openen via IPv4, een aantal server not found (zoals bij http://ipv6.google.com en www.v6.facebook.com ) maar http://www.solo-buon-umore.com/ opent en geeft in FF een IPv6 adres weer. Dus heb nu maar liefst 2 sites gevonden die werken, nu de rest nog...

Maar IPv6-testsites zoals http://test-ipv6.com/ en http://ipv6-test.com/ geven beide aan dat het werkt

[ Voor 98% gewijzigd door Raven op 04-10-2013 18:28 ]

[alm]

Raven schreef op vrijdag 04 oktober 2013 @ 11:36:
Geen flauw idee, hoe kan ik dat testen?

edit: Net een hele lading IPv6-ondersteundende sites geprobeerd. De meeste openen via IPv4, een aantal server not found (zoals bij http://ipv6.google.com en www.v6.facebook.com ) maar http://www.solo-buon-umore.com/ opent en geeft in FF een IPv6 adres weer. Dus heb nu maar liefst 2 sites gevonden die werken, nu de rest nog...

Maar IPv6-testsites zoals http://test-ipv6.com/ en http://ipv6-test.com/ geven beide aan dat het werkt

Blokkeert je router/firewall wellicht ICMPv6 verkeer?

Hoe staat de MTU voor de tunnel ingesteld?

Met ping zou je met diverse pakketgroottes wel moeten kunnen achterhalen wat de grootste pakketgrootte is die je door de verbinding heen krijgt...

[Raven]

Niet dat ik weet, bij mijn weten zit er niet eens een IPv6 firewall in. Ik heb overigens vóór het testen in een gevirtualiseerde IPFire een virtuele pc met Fedora tijdelijk voorzien van IPv6 en die kan zonder problemen van IPv6 gebruik maken. Protocol 41 wordt dus iig doorgelaten en aangezien het daar in werkt ICMPv6 ook.
Daarnaast, als ICMPv6 geblokkeerd zou worden, dan zou ik toch ping -6 niet succesvol kunnen uitvoeren?

Bij de tunnel instellingen op tunnelbroker.net staat 1480 (default), in IPFire staat het volgende:

code:

[root@ipfire-test ~]# ip link   
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN mode DEFAULT 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ip6tnl0: <NOARP> mtu 1452 qdisc fq_codel state DOWN mode DEFAULT 
    link/tunnel6 :: brd ::
3: sit0: <NOARP> mtu 1480 qdisc fq_codel state DOWN mode DEFAULT 
    link/sit 0.0.0.0 brd 0.0.0.0
4: red0: <BROADCAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT qlen 1000
    link/ether 00:50:56:27:7f:b1 brd ff:ff:ff:ff:ff:ff
5: green0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT qlen 1000
    link/ether 00:50:56:26:a9:a5 brd ff:ff:ff:ff:ff:ff
6: he-ipv6: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1480 qdisc fq_codel state UNKNOWN mode DEFAULT 
    link/sit 192.168.1.41 peer 216.66.84.46

De green0-(LAN)-interface 1500, de he-ipv6 tunnelinterface 1480.

edit: Ik zie net wat, althans, volgens mij is het relevant. Google leverde berichten op waarbij mensen moesten testen mbv telnet. Als ik vanaf de gevirtualiseerde IPFire telnet ipv6.google.com 80 uitvoer en wat toetsen indruk, krijg ik reactie van ipv6.google.com terug. Doe ik hetzelfde op mijn Windows 7 pc:

code:

C:\Users\Raven>telnet ipv6.google.com 80
Er wordt verbinding gemaakt met ipv6.google.com...Kan geen verbinding met de host maken, op poort 80: Het maken van de v
erbinding is mislukt

C:\Users\Raven>

Er lijkt dus toch ergens wat geblokkeerd te worden.

edit2:

code:

telnet ipv6.l.google.com 80

werkt wél en telnetten naar het IPv6 addres dat IPFire na het uitvoeren van telnet ipv6.google.com 80 weergeeft werkt ook.

Vaag

edit3: Ah, nu komen we ergens:
Test site http://[2001:7b8:3:32:213:136:0:22]/ werkt:

BETA -This tab is a work in progress.
Your Internet help desk may ask you for the information below.
Dual Stack - but no Quad-A's (AAAA's)
IPv4: Good, AS12871 - NL-CONCEPTS Concepts ICT Autonomous System
IPv6: no
IPv4 address: *.*.*.*
IPv6 address: 2001:****:**15:***9::3

En nog maar een edit:
Ik zie een dansende kame en IPv6 websites lijken nu wel te werken,
Oplossing: De IPv4 DNS-servers van Google instellen bij de fysieke LAN-interface van mijn pc.

Ik kan nu blijkbaar ook naar IPv6 sites pingen zonder -6 aan ping toe te hoeven voegen

[ Voor 32% gewijzigd door Raven op 05-10-2013 12:10 ]

[alm]

Raven schreef op zaterdag 05 oktober 2013 @ 10:41:
Niet dat ik weet, bij mijn weten zit er niet eens een IPv6 firewall in. Ik heb overigens vóór het testen in een gevirtualiseerde IPFire een virtuele pc met Fedora tijdelijk voorzien van IPv6 en die kan zonder problemen van IPv6 gebruik maken. Protocol 41 wordt dus iig doorgelaten en aangezien het daar in werkt ICMPv6 ook.
Daarnaast, als ICMPv6 geblokkeerd zou worden, dan zou ik toch ping -6 niet succesvol kunnen uitvoeren?

Ik bedoelde dat je op de IPv6 router (dus de tunnel-router) wellicht ICMPv6 blokkeert van buitenaf. Dat je op de internet router geen IPv6 hebt maakt niet uit, want IPv6 komt binnen via je IPv6 tunnel router.

Uitgaand ICMPv6 verkeer is meestal toegestaan, maar inkomend (van buitenaf) moet je wel e.e.a. toestaan om PMTU goed te laten werken. ICMP is noodzakelijk om Internet goed te laten functioneren, dat zomaar blokkeren levert allerlei problemen op.

Ik neem wel aan dat je op de IPv6 router wel een firewall hebt draaien die je netwerk beschermd tegen ongewenste benaderingen van buitenaf? Als je alles doorlaat dan ben je afhankelijk van de bescherming van de host zelf omdat iedere host een publiek adres heeft.

Alles werkt nu je de DNS van Google hebt ingesteld?

[Raven]

Oh zo, nee, voor zover ik weet niet. Ik weet niet anders dat alles qua IPv6 doorgelaten wordt, vooral omdat er geen mogelijkheden zijn in de webinterface om het te blokkeren (er is geen één IPv6-gerelateerde instelling daar) en meende dat ergens gelezen te hebben. Wel zijn standaard IPv6-features uitgeschakeld, maar dat was zo opgelost.

Er draait een firewall, die wat er standaard in zit en alleen aan IPv4 doet. Voor ip6tables moet ik even kijken of al het nodige er is, volgens mij wel:

code:

ip6_queue
ip6table_filter
ip6table_mangle
ip6table_raw
ip6_tables
ip6t_ah
ip6t_eui64
ip6t_frag
ip6t_hbh
ip6t_ipv6header
ip6t_LOG
ip6t_mh
ip6t_REJECT
ip6t_rt

Bovenstaande moet ik nog even toevoegen aan /etc/sysconfig/modules om ze bij 't starten te laten laden en dan kijken of het goed werkt na een stel ip6tables rules aangemaakt te hebben. Uiteraard ga ik daar eerst mee aan de gang vóór ik IPv6 daadwerkelijk in de router inschakel, voor nu zet ik voor het testen de VM aan die op dit moment dus geen IPv6 firewall heeft, maar ik heb een tijd terug wat getest en bleek dat ESS6 die op de host draait IPv6 ondersteund en dat ook blokkeert indien nodig. Dus dat de VM geen IPv6 firewall heeft is niet zo heel erg.

Inderdaad, sinds ik de DNS-servers (8.8.8.8/8.8.4.4) van Google op de fysieke LAN-interface van de host van de VM heb ingesteld werkt het, al kan ik het niet verklaren. Wat het probleem iig (b)leek te zijn was dat Windows 7 geen AAAA lookups deed terwijl de gevirtualiseerde IPFire dat wel deed. Maar het gekke is, beide maken gebruik van dezelfde LAN-verbinding met de (fysieke) router, de WAN-interface van de VM is als bridged ingesteld, dus directe toegang tot hetzelfde netwerk als de host. En de VM maakt ook gebruik van dezelfde DNS-instelling (192.168.1.1, de fysieke router) als de host had, de VM maakt daar nog steeds gebruik van, de host niet meer dus.

[ Voor 3% gewijzigd door Raven op 06-10-2013 11:53 ]

[Raven]

Ik ben nu met mijn eerste ip6tables firewall bezig en volgens mij ben ik op de goede weg:

code:

# Flush and remove chains
ip6tables -F
ip6tables -X

# set default policy
ip6tables -P OUTPUT  DROP
ip6tables -P INPUT   DROP
ip6tables -P FORWARD DROP

# allow incoming ICMP ping pong stuff
ip6tables -A INPUT -p ipv6-icmp -j ACCEPT
ip6tables -A OUTPUT -p ipv6-icmp -j ACCEPT


# allow all on green0
ip6tables -A INPUT  -i green0 -p all -j ACCEPT
ip6tables -A OUTPUT -o green0 -p all -j ACCEPT

ip6tables -A FORWARD -i green0 -j ACCEPT


# Filter all packets that have RH0 headers:
ip6tables -A INPUT -m rt --rt-type 0 -j DROP
ip6tables -A FORWARD -m rt --rt-type 0 -j DROP
ip6tables -A OUTPUT -m rt --rt-type 0 -j DROP


# Allow HTTP and HTTPS
ip6tables -A OUTPUT  -p tcp --dport 80 -j ACCEPT
ip6tables -A INPUT   -p tcp --sport 80 -m state --state ESTABLISHED -j ACCEPT
ip6tables -A OUTPUT  -p tcp --dport 443 -j ACCEPT
ip6tables -A INPUT   -p tcp --sport 443 -m state --state ESTABLISHED -j ACCEPT

Er is alleen een probleem. Op de router is er internet toegang over poort 80 en 443 (dat is mijn bedoeling), maar niet op de host van de IPFire VM waar ik dit in test. Blijkbaar zijn de 3 regels onder # allow all on green0 niet voldoende? Green0 is hier LAN overigens.

code:

[root@ipfire-test]# ip6tables -L -v
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    9   648 ACCEPT     ipv6-icmp    any    any     anywhere             anywhere            
    0     0 DROP       all      any    any     anywhere             anywhere             rt type:0 segsleft:0
    5  1436 ACCEPT     tcp      any    any     anywhere             anywhere             tcp spt:http state ESTABLISHED
    5   368 ACCEPT     tcp      any    any     anywhere             anywhere             tcp spt:https state ESTABLISHED

Chain FORWARD (policy DROP 11 packets, 614 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       all      any    any     anywhere             anywhere             rt type:0 segsleft:0
   11   826 ACCEPT     all      green0 any     anywhere             anywhere            

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    6   416 ACCEPT     ipv6-icmp    any    any     anywhere             anywhere            
    0     0 DROP       all      any    any     anywhere             anywhere             rt type:0 segsleft:0
    5   373 ACCEPT     tcp      any    any     anywhere             anywhere             tcp dpt:http
    5   379 ACCEPT     tcp      any    any     anywhere             anywhere             tcp dpt:https
[root@ipfire-test]#

edit: Bleek heel simpel, 1 regeltje vergeten:

code:

ip6tables -A FORWARD -i he-ipv6 -m state --state ESTABLISHED -j ACCEPT

Nu ziet het er zo uit:

code:

[root@ipfire-test ~]# ip6tables -L -v          
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   12   864 ACCEPT     ipv6-icmp    any    any     anywhere             anywhere            
    0     0 ACCEPT     all      green0 any     anywhere             anywhere            
    0     0 DROP       all      any    any     anywhere             anywhere             rt type:0 segsleft:0
    5  1436 ACCEPT     tcp      any    any     anywhere             anywhere             tcp spt:http state ESTABLISHED
    0     0 ACCEPT     tcp      any    any     anywhere             anywhere             tcp spt:https state ESTABLISHED

Chain FORWARD (policy DROP 232 packets, 12116 bytes)
 pkts bytes target     prot opt in     out     source               destination         
  714 77509 ACCEPT     all      green0 any     anywhere             anywhere            
  587  371K ACCEPT     all      he-ipv6 any     anywhere             anywhere             state ESTABLISHED
    0     0 DROP       all      any    any     anywhere             anywhere             rt type:0 segsleft:0

Chain OUTPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   13  2104 ACCEPT     ipv6-icmp    any    any     anywhere             anywhere            
    0     0 ACCEPT     all      any    green0  anywhere             anywhere            
    0     0 DROP       all      any    any     anywhere             anywhere             rt type:0 segsleft:0
    5   372 ACCEPT     tcp      any    any     anywhere             anywhere             tcp dpt:http
    0     0 ACCEPT     tcp      any    any     anywhere             anywhere             tcp dpt:https
[root@ipfire-test ~]#

Nu eens kijken wat de beste manier is om de firewall bij opstarten actief te maken.

[ Voor 63% gewijzigd door Raven op 08-10-2013 13:28 ]

[Snow_King]

Heeft er trouwens al iemand eens IPv6 gehad in een hotel of publieke WiFi?

Iedere keer kijk ik weer (zoals nu) en is er geen IPv6. Ik hoop nog steeds op dat moment.

[Ultraman]

Zolang de grote providers het nog nauwelijks aanbieden en/of er geen grote vraag naar is zul je het denk ik niet snel zien in die omgeving.
Wanneer meer providers het gaan aanbieden zal de mainstream vanzelf volgen en zulke installaties dan ook. Daarom moeten ze imo eens vaart maken met die IPv6.

[Freeaqingme]

Toevallig afgelopen twee weken bezig geweest met een Puppet module voor iptables ( https://github.com/example42/puppet-iptables/tree/devel ), wat ik daarbij gedaan heb is een default policy van Allow instellen. Dat stelt je in staat om eventueel gedropped verkeer nog te loggen. Eventueel kan je ook ip6tables-save gebruiken, heb je met 1 commando in 1 keer alle regels.

Template die ik gebruik ziet er zo uit:

# Generated by ip6tables-save v1.4.12 on Tue Oct 8 21:44:22 2013
*raw
:PREROUTING ACCEPT [4:288]
:OUTPUT ACCEPT [0:0]
COMMIT
# Completed on Tue Oct 8 21:44:22 2013
# Generated by ip6tables-save v1.4.12 on Tue Oct 8 21:44:22 2013
*mangle
:PREROUTING ACCEPT [4:288]
:INPUT ACCEPT [4:288]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed on Tue Oct 8 21:44:22 2013
# Generated by ip6tables-save v1.4.12 on Tue Oct 8 21:44:22 2013
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m limit --limit 30/min --limit-burst 10 -m state --state INVALID -j LOG --log-prefix "iptables"
-A INPUT -m state --state INVALID -j DROP

# Traceroute
-A INPUT -p udp -m udp --dport 33434:33523 -j ACCEPT

# Dhcp
-A INPUT -i eth0 -p udp -m udp --sport 67:68 --dport 67:68 -j ACCEPT

-A INPUT -m pkttype --pkt-type broadcast -j ACCEPT
-A INPUT -m pkttype --pkt-type multicast -j ACCEPT
-A INPUT -p ipv6-icmp -m limit --limit 1/sec -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m limit --limit 30/min --limit-burst 10 -j LOG --log-prefix "iptables"
-A INPUT -j REJECT --reject-with icmp6-adm-prohibited
-A FORWARD -m limit --limit 30/min --limit-burst 10 -m state --state INVALID -j LOG --log-prefix "iptables"
-A FORWARD -m state --state INVALID -j DROP
-A FORWARD -p ipv6-icmp -m limit --limit 1/sec -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m limit --limit 30/min --limit-burst 10 -j LOG --log-prefix "iptables"
-A FORWARD -j REJECT --reject-with icmp6-adm-prohibited
-A OUTPUT -m limit --limit 30/min --limit-burst 10 -m state --state INVALID -j LOG --log-prefix "iptables"
-A OUTPUT -m state --state INVALID -j DROP

# Traceroute
-A OUTPUT -p udp -m udp --dport 33434:33523 -j ACCEPT
-A OUTPUT -p ipv6-icmp -m limit --limit 1/sec -j ACCEPT
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -m limit --limit 30/min --limit-burst 10 -j LOG --log-prefix "iptables"
-A OUTPUT -j REJECT --reject-with icmp6-adm-prohibited
COMMIT
# Completed on Tue Oct 8 21:44:22 2013

Ik zou in ieder geval het ICMP verkeer limiten, anders loop je het risico op een SMURF-attack, en ook expliciet te checken op de state INVALID. Door die bovenaan iedere chain te plaatsen zorg je ervoor dat de rest van je regels niet 'onbedoeld' een verkeerd pakketje matcht.

[Orion84]

Hoezo heb je een default accept policy nodig om te kunnen loggen?

En als ik het goed zie doet deze firewall setup dus niets anders dan invalid pakketjes droppen en wat icmp verkeer rejecten? Verder wordt alles geaccepteerd. Hetzij door specifieke accept regels, hetzij door de default accept policy.

[Raven]

Freeaqingme schreef op dinsdag 08 oktober 2013 @ 22:15:
Toevallig afgelopen twee weken bezig geweest met een Puppet module voor iptables ( https://github.com/example42/puppet-iptables/tree/devel ), wat ik daarbij gedaan heb is een default policy van Allow instellen. Dat stelt je in staat om eventueel gedropped verkeer nog te loggen. Eventueel kan je ook ip6tables-save gebruiken, heb je met 1 commando in 1 keer alle regels.

Template die ik gebruik ziet er zo uit:

[...]


Ik zou in ieder geval het ICMP verkeer limiten, anders loop je het risico op een SMURF-attack, en ook expliciet te checken op de state INVALID. Door die bovenaan iedere chain te plaatsen zorg je ervoor dat de rest van je regels niet 'onbedoeld' een verkeerd pakketje matcht.

Ip6tables-save heb ik naar gekeken, maar dat levert in IPFire een file op dat alles behalve makkelijk leesbaar en aan te passen is. Heb uiteindelijk alle leesbare/duidelijke ip6tables commando's met comments erbij in de rc.local gegooid, onder de ip commando's voor de tunnel.

ICMP(v6) limiten? Dat is een goeie, zal daar later vandaag eens naar kijken.

[Freeaqingme]

Orion84 schreef op woensdag 09 oktober 2013 @ 08:37:
Hoezo heb je een default accept policy nodig om te kunnen loggen?

Oke, dat klopt inderdaad niet helemaal. Ik zou in ieder geval onderaan je chains een logstatement zetten om eventueel gedropped verkeer te loggen. De default accept policy lijkt een best-practice te zijn waarmee je jezelf niet buitensluit als je je firewall flusht.
[/quote]

Orion84 schreef op woensdag 09 oktober 2013 @ 08:37:
En als ik het goed zie doet deze firewall setup dus niets anders dan invalid pakketjes droppen en wat icmp verkeer rejecten? Verder wordt alles geaccepteerd. Hetzij door specifieke accept regels, hetzij door de default accept policy.

Alle source/destination-based regels heb ik er uit gefiltered, de echte ruleset is aanzienlijk langer. Wel doe ik aan 't eind van iedere chain een reject --reject-with icmp6-adm-prohibited, dus verkeer wat niet expliciet gematched wordt wordt wel degelijk gedropped.

[Orion84]

Freeaqingme schreef op woensdag 09 oktober 2013 @ 14:24:
[...]
Oke, dat klopt inderdaad niet helemaal. Ik zou in ieder geval onderaan je chains een logstatement zetten om eventueel gedropped verkeer te loggen. De default accept policy lijkt een best-practice te zijn waarmee je jezelf niet buitensluit als je je firewall flusht.

Daar zit op zich wat in. Je kan dan inderdaad het volgende doen:
<specifieke regels>
<generieke drop regel (evt. incl. logging)>
<Accept ALL policy>

Maar dat kan je ook oplossen door gewoon twee scripts te maken: 1 om je firewall te stoppen (flush all, policy op accept) en een script om je firewall te starten (flush all, policy op drop, specifieke regels voor accept etc.). Verschillende linux distro's hebben dat soort scripts volgens mij ook standaard aan boord.

[Freeaqingme]

Orion84 schreef op woensdag 09 oktober 2013 @ 15:01:
[...]

Maar dat kan je ook oplossen door gewoon twee scripts te maken: 1 om je firewall te stoppen (flush all, policy op accept) en een script om je firewall te starten (flush all, policy op drop, specifieke regels voor accept etc.). Verschillende linux distro's hebben dat soort scripts volgens mij ook standaard aan boord.

Absoluut waar. Het probleem in deze is alleen wel dat als iemand vergeet dat je zo'n script hebt, en een keer zonder er bij na te denken iptables -F doet, je jezelf buitensluit (en de hele server onbenaderbaar maakt). Zolang je het hele ding niet flusht is er niets aan de hand, maar het moment dat je dat een keertje wel doet, speel ik het het liefst op safe.

(en ja, die junior sysadmin die zich zelf buitensluit van een willekeurige productieserver heeft meteen een heel goede les...).

[Raven]

Freeaqingme schreef op woensdag 09 oktober 2013 @ 14:24:
[...]


Oke, dat klopt inderdaad niet helemaal. Ik zou in ieder geval onderaan je chains een logstatement zetten om eventueel gedropped verkeer te loggen. De default accept policy lijkt een best-practice te zijn waarmee je jezelf niet buitensluit als je je firewall flusht.

Misschien een domme opmerking, maar dat is toch niet zo heel erg zolang ie via IPv4 nog toegankelijk is?

[Freeaqingme]

Raven schreef op woensdag 09 oktober 2013 @ 15:08:
[...]

Misschien een domme opmerking, maar dat is toch niet zo heel erg zolang ie via IPv4 nog toegankelijk is?

Goed punt

Ik ga van de week een aantal ipv6-only LXC "vm's" opzetten, kijken waar ik dan tegen aan loop. Over time gaat IPv4 er natuurlijk uit, dus als je 't hebt over ipv6 best-practices zou ik me daar niet teveel afhankelijk opstellen van ipv4.

[Raven]

Zolang dualstack blijft is IPv4 iig wel een mooi alternatief mocht je de firewall een beetje verkloten

Maar ik vraag mij af of IPv4 er ooit helemaal uit gaat, om bijvoorbeeld iets op te noemen: Hoe gemakkelijk is het om een IPv6 LAN op te zetten? Volgens mij gaat dat niet zo makkelijk als bij IPv4, of wel?

[Freeaqingme]

Raven schreef op woensdag 09 oktober 2013 @ 15:19:
Maar ik vraag mij af of IPv4 er ooit helemaal uit gaat, om bijvoorbeeld iets op te noemen: Hoe gemakkelijk is het om een IPv6 LAN op te zetten? Volgens mij gaat dat niet zo makkelijk als bij IPv4, of wel?

Wat versta je onder 'een lan op zetten'?

Op het moment dat iedereen IPv6 geimplementeerd heeft is IP-connectiviteit via die weg geborgd, en is er natuurlijk geen reden meer om IPv4 draaiende te houden.De TCO van een dualstack environment zal per definitie hoger zijn dan een single stack. Tot die tijd zullen er steeds meer Carrier Grade Nat dingen komen om toch nog in de nood van IPv4 te kunnen voorzien (aan de limiet an 2^32 adressen kan niemand iets doen immers).

Wat dat opzetten betreft, met IPv6 heb je natuurlijk het concept van Link Local adressen. Zonder enige configuratie whatsoever heeft je OS al een adres wat begint met FE80, en eindigt met iets wat op je mac-adres is gebasseerd. Met IPv4 heb je dan toch minstens iets als een DHCP server nodig, of moet je handmatig ip's gaan instellen.

[Raven]

Computers binnen een lokaal netwerk met elkaar laten babbelen, maar dan met de IPv6 tegenhanger van 192.168.1.* om het maar op een andere manier te beschrijven

[CyBeR]

Daar krijg je van je ISP ook gewoon adressen voor. En voor niet-internet-connected LANs kun je ofwel iets zelf bedenken ofwel (beter idee) een ULA-prefix gebruiken. Wikipedia: Unique local address. Of als 't heel klein is, gewoon link-local addressering gebruiken.

Een directe tegenhanger van rfc1918 bestaat niet in ipv6.

[ Voor 19% gewijzigd door CyBeR op 09-10-2013 16:36 ]

[Bigs]

Raven schreef op woensdag 09 oktober 2013 @ 16:34:
Computers binnen een lokaal netwerk met elkaar laten babbelen, maar dan met de IPv6 tegenhanger van 192.168.1.* om het maar op een andere manier te beschrijven

Daar zijn dus de link-local adressen voor. Daar heb je met IPv6 dus minder werk aan dan met IPv4, aangezien je niet geeneens een DHCP server nodig hebt. Verder krijg je met IPv6 gewoon een eigen adresblok van je provider waar je apparaten zichzelf een adres uit toekennen (op basis van de RA's van je router). Veel makkelijker wordt het niet

[ Voor 18% gewijzigd door Bigs op 09-10-2013 16:36 ]

[Raven]

Link-local, die fe80 adressen? Hmm, okee.

Mijn router-pc doet helaas geen RA's of DHCPv6 (er komt crosscompiling bij kijken om het misschien werkend te krijgen), kan dus op dit moment alleen gebruik maken van een statische configuratie.

[Freeaqingme]

Die link local adressen gaan vanzelf, enige wat daarvoor nodig is is ipv6 support in de kernel. Heb je niet een ander device wat veel online is? Die kan je eventueel ook RA laten spelen...

[Raven]

Nope, op de router-pc en download-pc na (die nog gecombineerd gaan worden) heb ik niets dat 24/7 draait. Maar die statische config is niet zo heel erg, het werkt tenminste terwijl mijn router-pc officieel niet met IPv5 overweg kan

[ Voor 14% gewijzigd door Raven op 09-10-2013 16:45 ]

[Ultraman]

IPv6 Stateless address autoconfiguration (SLAAC) is hartstikke prima, voor thuis in ieder geval.
Ik heb het een tijd met puur radvd gedaan, dat werkte gewoon met OSen die voldoende IPv6 support hebben.

Vaste IPv6 adressen krijg je als je de IPv6 Privacy Extensions op de machine uit zet, dan krijg je een IPv6 adres gebaseerd op MAC adres. Dat gebruik ik voor mijn serverende machientjes en dingen die ik een vast IP wil laten hebben.

[CyBeR]

Ultraman schreef op woensdag 09 oktober 2013 @ 17:09:
IPv6 Stateless address autoconfiguration (SLAAC) is hartstikke prima, voor thuis in ieder geval.
Ik heb het een tijd met puur radvd gedaan, dat werkte gewoon met OSen die voldoende IPv6 support hebben.

Vaste IPv6 adressen krijg je als je de IPv6 Privacy Extensions op de machine uit zet, dan krijg je een IPv6 adres gebaseerd op MAC adres. Dat gebruik ik voor mijn serverende machientjes en dingen die ik een vast IP wil laten hebben.

Als je die PE aan laat ook. De PE addresses zijn extra. Je hebt altijd een vastm EUI-64-gebaseerd SLAAC adres als je PE hebt.

[Raven]

Ultraman schreef op woensdag 09 oktober 2013 @ 17:09:
IPv6 Stateless address autoconfiguration (SLAAC) is hartstikke prima, voor thuis in ieder geval.
Ik heb het een tijd met puur radvd gedaan, dat werkte gewoon met OSen die voldoende IPv6 support hebben.

Vaste IPv6 adressen krijg je als je de IPv6 Privacy Extensions op de machine uit zet, dan krijg je een IPv6 adres gebaseerd op MAC adres. Dat gebruik ik voor mijn serverende machientjes en dingen die ik een vast IP wil laten hebben.

Ehm, ik heb gewoon handmatig de boel ingevoerd en niks met IPv6 Privacy Extensions gedaan. De routed /64 prefix van tunnelbroker met een 1 erachter voor de LAN interface van IPFire en met een 2 voor mijn pc. Dan nog subnet, gateway en de DNS-server. Gewoon op dezelfde manier gedaan als met IPv4

[joopv]

Freeaqingme schreef op woensdag 09 oktober 2013 @ 15:12:
[...] Ik ga van de week een aantal ipv6-only LXC "vm's" opzetten, kijken waar ik dan tegen aan loop. Over time gaat IPv4 er natuurlijk uit, dus ....

Ik denk dat jij tegen die tijd aardig tegen je pensioen aan zal zitten

[ Voor 13% gewijzigd door joopv op 09-10-2013 21:28 ]

[Maurits van Baerle]

Ik heb even een vraag. Ik ben op dit moment voor een klant bezig om hun toekomststrategie vorm te geven. Een onderdeel daarvan is uitbreiding van hun online service naar China en India. Aangezien daar de IPv6-only verbindingen in opkomst zijn moeten we dus voorbereidingen gaan treffen om IPv6 compatible te worden. Op dit moment is het product en de hoster (Windows Azure) nog niet IPv6 compatible en hebben we geen enorme haast. Wel wil ik voorkomen dat er nu keuzes worden gemaakt die een latere ondersteuning van IPv6 bemoeilijken.

Ik heb tot nu toe twee voorwaarden gegeven aan de developers:
1) Gebruik alleen hostnames, geen hardcoded IP's etc. (Dan lost het onderliggend OS wel op of het IPv4 of IPv6 wordt).
2) Waar er wel met IP's gewerkt moet worden (abuse logs bijvoorbeeld) hou er rekening mee dat er ook een IPv6 notatie opgeslagen moet kunnen worden.

Verder heb ik geen punten gesteld, en eerlijk gezegd heb je op dit hoge niveau natuurlijk amper met IP adressen te maken dus waarschijnlijk ook niet zoveel nodig.

Het draait op Windows Azure dus een hoop OS-level zaken zijn niet hun kopzorg, het gaat puur om de dienst die daar bovenop draait. Heeft iemand nog andere tips waar de developers nu alvast in hun design rekening mee moeten houden?

[CAPSLOCK2000]

Freeaqingme schreef op woensdag 09 oktober 2013 @ 15:07:
Absoluut waar. Het probleem in deze is alleen wel dat als iemand vergeet dat je zo'n script hebt, en een keer zonder er bij na te denken iptables -F doet, je jezelf buitensluit (en de hele server onbenaderbaar maakt). Zolang je het hele ding niet flusht is er niets aan de hand, maar het moment dat je dat een keertje wel doet, speel ik het het liefst op safe.

Dat kun je ook omdraaien he:

Het probleem in deze is alleen wel dat als iemand vergeet dat je zo'n script hebt, en een keer zonder er bij na te denken iptables -F doet, je de server voor de hele wereld benaderbaar maakt. Zolang je het hele ding niet flusht is er niets aan de hand, maar het moment dat je dat een keertje wel doet, speel ik het het liefst op safe.

FTFY ;-)

Maurits van Baerle schreef op donderdag 10 oktober 2013 @ 13:57:
Het draait op Windows Azure dus een hoop OS-level zaken zijn niet hun kopzorg, het gaat puur om de dienst die daar bovenop draait. Heeft iemand nog andere tips waar de developers nu alvast in hun design rekening mee moeten houden?

Mijn eis is dat het moet werken in een ipv6-only omgeving.
Als je vraagt om IPv6-compatability dan wordt dat als snel uitgelegd als "gaat niet stuk als er IPv6 in het netwerk zit". Verder kan het moeilijk zijn om te testen of IPv6 ook echt werkt als er ook nog IPv4 aanwezig is.

[ Voor 27% gewijzigd door CAPSLOCK2000 op 10-10-2013 14:12 ]

[Paul]

Freeaqingme schreef op woensdag 09 oktober 2013 @ 15:07:
(en ja, die junior sysadmin die zich zelf buitensluit van een willekeurige productieserver heeft meteen een heel goede les...).

Daar heb je iLO / DRAC / VMware console voor... Ik heb ook wel eens de netwerkkaart van een server uitgezet, had net een nieuwe Wacom en de 'disable' en 'properties' (of status, weet al niet meer wat ik precies wilde doen) zaten wel erg dicht bij elkaar

[Snow_King]

nieuws: Microsoft: Xbox One online-gaming verloopt soepeler via ipv6

Dat zijn wel de leuke berichten die hopelijk wat extra druk achter IPv6 kunnen zetten.

Zulke berichten hebben we er meer van nodig, want dan gaan mensen bij hun ISP zeuren omdat ze IPv6 nodig hebben.

Ik blijf nog steeds voor een gratis adult content website op IPv6-only, zodra die bestaat zullen héél veel mensen IPv6 willen.

[Bigs]

Hmm.. dat is inderdaad wel een leuke ja. In de Playstation community zie je ook mensen stoeien met 'NAT type 3' zoals Sony het noemt. Als duidelijk wordt dat IPv6 aan die gamers een voordeel beidt dan wordt er misschien wel meer druk gezet op providers om IPv6 aan te bieden.

Wat betreft die adult content; ik denk dat de gratis nieuwsgroepen van IPv6 ook wel aan het aantal IPv6 gebruikers heeft bijgedragen.

[Maurits van Baerle]

CAPSLOCK2000 schreef op donderdag 10 oktober 2013 @ 14:01:
Mijn eis is dat het moet werken in een ipv6-only omgeving.
Als je vraagt om IPv6-compatability dan wordt dat als snel uitgelegd als "gaat niet stuk als er IPv6 in het netwerk zit". Verder kan het moeilijk zijn om te testen of IPv6 ook echt werkt als er ook nog IPv4 aanwezig is.

Daar heb je wel een goed punt. Helaas kunnen we dat nu nog niet testen aangezien Windows Azure helaas nog geen IPv6 ondersteunt. Het is wel iets om tegen die tijd te testen met IPv4 uitgeschakeld, ik ga het toevoegen aan onze ticket. Dank!

[Orion84]

Ik ben wel benieuwd hoeveel soepeler het in de praktijk echt gaat zijn. Adressering wordt natuurlijk makkelijker, je weet precies met wel IP aan de overkant je wilt communiceren, maar de best practise op firewall gebied is wel zo'n beetje om connecties die vanaf buiten geïnitieerd worden te blocken.

Uiteindelijk kom je dan toch weer op oplossingen waarbij de client via upnp of iets dergelijks gaatjes moet gaan prikken in een firewall. En of dat nu NAT is of daadwerkelijk een firewall, ik vraag me af of dat heel veel verschil gaat maken. But we'll see

[Maurits van Baerle]

Ik weet niet of het zo moeilijk hoeft te zijn. Als je een hele simpele firewall ontwerpt die simpelweg alle verbindingen van buitenaf blokkeert voor het hele subnet, tenzij een IP binnen het subnet al een verbinding heeft met het IP buiten het subnet heb je al een gelijke situatie aan NAT. Van binnen naar buiten staat alles wagenweid open, van buiten naar binnen staat alles dicht tenzij er iets van binnen geïnitieerd is (beiden zoals gebruikelijk bij NAT zonder firewall).

Het voordeel van bovenstaand systeem is dat je een technologie gebruikt die er specifiek voor is gemaakt, in plaats van hopen dat de toevallige bijwerking van NAT je beschermt.

Als iemand in Shenzen een opdracht heeft om in een namiddagje even een NAT implementatie in elkaar te flansen voor hun nieuwe router van drie tientjes zal het doel zijn om meerdere interne IP's achter één externe IP te delen. Niet om het netwerk te beschermen tegen verkeer van buiten. Een NAT implementatie die al het verkeer dat hij niet begrijpt simpelweg doorstuurt naar het eerste actieve interne IP is een NAT implementatie die aan alle NAT doelstellingen voldoet en in veel gevallen door testen heen komt. Maar, het is ook geen beveiliging ondanks dat hij aan alle eisen voldoet.

Een basale firewall zal in IPv6 altijd simpeler te ontwerpen zijn dan een NAT implementatie. Hoe simpeler het ontwerp hoe minder er mis kan gaan.

[ Voor 5% gewijzigd door Maurits van Baerle op 11-10-2013 13:56 ]

[CyBeR]

Orion84 schreef op vrijdag 11 oktober 2013 @ 13:34:
Ik ben wel benieuwd hoeveel soepeler het in de praktijk echt gaat zijn. Adressering wordt natuurlijk makkelijker, je weet precies met wel IP aan de overkant je wilt communiceren, maar de best practise op firewall gebied is wel zo'n beetje om connecties die vanaf buiten geïnitieerd worden te blocken.

Uiteindelijk kom je dan toch weer op oplossingen waarbij de client via upnp of iets dergelijks gaatjes moet gaan prikken in een firewall. En of dat nu NAT is of daadwerkelijk een firewall, ik vraag me af of dat heel veel verschil gaat maken. But we'll see

Het is op zich wel simpeler om de juiste gaatjes te prikken in een firewall dan door een NAT-device heen. Je zou gewoon kunnen zeggen, 'device X mag alle inkomende verbindingen gewoon krijgen'.

Mijn Wii hangt ook met een publiek IP aan 't internet want anders is online spelen bijna onmogelijk.

[CAPSLOCK2000]

Orion84 schreef op vrijdag 11 oktober 2013 @ 13:34:
Uiteindelijk kom je dan toch weer op oplossingen waarbij de client via upnp of iets dergelijks gaatjes moet gaan prikken in een firewall. En of dat nu NAT is of daadwerkelijk een firewall, ik vraag me af of dat heel veel verschil gaat maken. But we'll see

Ik ben het met je eens, onbeperkt edge-to-edge internet zijn we kwijt. Of het nu door NAT komt of door firewalls die de voordeur dicht houden. Gelukkig wordt de wereld er wel een stuk overzichtelijker van als we overal "echte" IPv6 adressen hebben (in tegenstelling tot de RFC1918 situatie) en geen NAT.
Dat iedere externe poort maar 1 keer te gebruiken is maakt NAT toch een kliederboel als je het wat serieuser wil gebruiken. Probeer maar eens twee mailservers achter NAT te draaien, die willen allebei echt poort 25 hebben.
Ook de interface (voor mensen) kan een stuk eenvoudiger. Nu is zo'n NAT-tabel toch een lijst met enge cijfers. 1.2.3.4:5678 -> 192.168.3.4:7890 . In de toekomst kan het misschien iets worden dat mensen weer begrijpen:
PC-van-jantje: VOIP (ja/nee)


De behoefte van clients om de router te vragen om een poort open te zetten zal blijven. UPNP zal wel een keer vervangen worden door iets beters (bv iets met authenticatie). Als ik het nu zou moeten bedenken zou ik naar OpenFlow en SDN kijken. Nog een idee: we kunnen applicaties een netwerk-manifest meegeven. Net zoals je Android-apps nu een lijstje met permissies bevatten die ze nodig hebben kunnen applicaties in de toekomst een lijstje met netwerkinstellingen meegeven om automatisch je router aan te passen. Als gebruiker krijg je een dialoog te zien:
"De applicatie die u nu heeft de volgende netwerkverbindingen nodig: 'poort 80+443/tcp uitgaande + poort 8081/tcp inkomend'. Wilt u dit verzoek doorsturen naar uw firewall?".

[Freeaqingme]

Orion84 schreef op vrijdag 11 oktober 2013 @ 13:34:
Uiteindelijk kom je dan toch weer op oplossingen waarbij de client via upnp of iets dergelijks gaatjes moet gaan prikken in een firewall. En of dat nu NAT is of daadwerkelijk een firewall, ik vraag me af of dat heel veel verschil gaat maken. But we'll see

Het grootste voordeel van een firewall tav een NA(P)T oplossing is sowieso dat je geen adressen hoeft te herschrijven. Alle protocollen die zo aardig zijn om in Layer-7 ip-adressen te communiceren zullen zonder heel erg vreemde truuks blijven werken. Dat is nu met bijvoorbeeld VOIP best wel een probleem (ja, er bestaan inmiddels heel veel hacks voor, maar dat zijn het: hacks).

Anders dan dat worden makers van OS's nu ook eens wakker, en hun devices secure by default maken, zodat een firewall niet per se benodigd is (noem een Microsoft die poort 139 alleen openzet voor verkeer binnen hetzelfde subnet).

Wie weet heeft de gemiddelde consument over 5 jaar dan helemaal geen firewall (of NAT-setup) nodig. Paradigm shift!

[joopv]

Ik had CBAC aangezet op m'n IPv6 tunnel vanuit de cisco router. Anders hang je ook maar met je blote reet aan het publieke internet.

Toen keek ik naar de actieve sessies. Ik weet niet of ik hier nou om moet lachen of huilen.

c1841#
c1841#show ipv6 inspect sessions
Established Sessions
[....]
Session 6832012C (2001:610:xxx:xxxx:9C36:E300:6FE5:481:51065)=>(2A03:2880:F010:601:FACE:B00C:0:1:443) tcp SIS_OPEN

IP adresbits gebruiken als reclame uiting?? ..

Extra bedroevend is dat ik al zeker een week niet op facebook geweest ben. Wat doet die $%^&* sessie daar?
_{ps: dat was een retorische vraag..}

[ Voor 3% gewijzigd door joopv op 11-10-2013 23:05 ]

[Freeaqingme]

joopv schreef op vrijdag 11 oktober 2013 @ 23:03:

IP adresbits gebruiken als reclame uiting?? ..

Extra bedroevend is dat ik al zeker een week niet op facebook geweest ben. Wat doet die $%^&* sessie daar?

Een beetje creativiteit mag toch wel? Doe dat hier ook, als 't even kan (hoewel marketing er altijd meer chars in wil hebben dan A-F). Als jij geen traffic naar facebook wil, dan block je dat? Zal wss een site zijn die dat embedt...

[ Voor 4% gewijzigd door Freeaqingme op 11-10-2013 23:07 ]

[CyBeR]

Bijna al die facebook like icons komen bij facebook zelf vandaan.

[databeestje]

Noorwegen is goed bezig, die zijn in een paar dagen (vanaf 9 oktober) omhoog geschoten van 1.5 naar 7.6%

Het vermoeden is dat de opera mini servers IPv6 hebben gekregen.

Edit: Eerste grote schaal NAT problemen in zicht
http://mailman.nanog.org/.../2013-October/061663.html

[ Voor 25% gewijzigd door databeestje op 17-10-2013 08:35 ]

[Keiichi]

joopv schreef op vrijdag 11 oktober 2013 @ 23:03:


Extra bedroevend is dat ik al zeker een week niet op facebook geweest ben.

Je hebt vast en zeker een site ergens bezocht met een facebook iframe. o.a. het social sharing icoon hier op tweakers telt daarvoor mee.

[Maasluip]

databeestje schreef op donderdag 17 oktober 2013 @ 07:31:

Edit: Eerste grote schaal NAT problemen in zicht
http://mailman.nanog.org/.../2013-October/061663.html

Ik denk dat Google daar snel klaar mee is: "Our servers are fully IPv6 compatible. Suggest you do the same".

[Bigs]

databeestje schreef op donderdag 17 oktober 2013 @ 07:31:
Noorwegen is goed bezig, die zijn in een paar dagen (vanaf 9 oktober) omhoog geschoten van 1.5 naar 7.6%

Het vermoeden is dat de opera mini servers IPv6 hebben gekregen.

Edit: Eerste grote schaal NAT problemen in zicht
http://mailman.nanog.org/.../2013-October/061663.html

Een hele (kleine) ISP achter één IP adres. Klinkt behoorlijk eng, maar dat is dus wel de kant die we opgaan. Ik verwacht niet dat deze ISP al met IPv6 bezig is trouwens.

[Raven]

databeestje schreef op donderdag 17 oktober 2013 @ 07:31:
Noorwegen is goed bezig, die zijn in een paar dagen (vanaf 9 oktober) omhoog geschoten van 1.5 naar 7.6%

Het vermoeden is dat de opera mini servers IPv6 hebben gekregen.

Edit: Eerste grote schaal NAT problemen in zicht
http://mailman.nanog.org/.../2013-October/061663.html

Ik vraag mij af wat voor nut dat heeft, noem één mobiele telefoon provider die aan IPv6 doet

[CyBeR]

Raven schreef op donderdag 17 oktober 2013 @ 11:05:
[...]

Ik vraag mij af wat voor nut dat heeft, noem één mobiele telefoon provider die aan IPv6 doet

Ik denk dat je verkeerd redeneert hier.

[Raven]

Hoezo? Opera Mini is over het algemeen op mobieltjes te vinden.

[Maasluip]

Wifi?
En anders heb je een kip-en-ei situatie. Als er geen vraag naar IPv6 is zullen mobile providers ook geen vaart maken met IPv6.

[Raven]

Ah ja, wifi niet aan gedacht, ik geef de nog niet werkende cafeïne de schuld

[ Voor 3% gewijzigd door Raven op 17-10-2013 12:04 ]

[Bigs]

Raven schreef op donderdag 17 oktober 2013 @ 11:05:
[...]

Ik vraag mij af wat voor nut dat heeft, noem één mobiele telefoon provider die aan IPv6 doet

Al is de verbinding tussen mobiel en de Opera servers via IPv4, dan wil dat niet zeggen dat de verbinding van de Opera servers naar de websites ook over IPv4 moet lopen aangezien het een volledige HTTP proxy is.

[CyBeR]

Bigs schreef op donderdag 17 oktober 2013 @ 12:53:
[...]


Al is de verbinding tussen mobiel en de Opera servers via IPv4, dan wil dat niet zeggen dat de verbinding van de Opera servers naar de websites ook over IPv4 moet lopen aangezien het een volledige HTTP proxy is.

Dit.

De opera mini servers gebruiken, als ze inderdaad IPv6 hebben, IPv6 om websites te bereiken. Wat mobieltjes doen heeft daar niks mee te maken.

[Maurits van Baerle]

Raven schreef op donderdag 17 oktober 2013 @ 11:05:
[...]

Ik vraag mij af wat voor nut dat heeft, noem één mobiele telefoon provider die aan IPv6 doet

Verizon Wireless in de VS. Met ruim 110 miljoen klanten is het misschien niet één van de grootsten maar toch ook geen kleintje. Ieder mobieltje dat op hun LTE netwerk toegelaten wordt moet verplicht IPv6 ondersteunen. Verizon is ook de reden dat IPv6 zo goed ondersteunt wordt op mobieltjes, de meeste fabrikanten willen Verizon niet mislopen.

Het heeft nog effect ook, ruim een kwart van al hun mobiel verkeer ging in April al middels IPv6. Aangezien de mobiele markt de grootste groeimarkt is zie je daar ook dat het IPv4 tekort veel nijpender is dan op ADSL of kabel en zijn het dus de mobiele providers die er het meest baat bij hebben.

[ Voor 3% gewijzigd door Maurits van Baerle op 17-10-2013 18:56 ]

[databeestje]

CyBeR schreef op donderdag 17 oktober 2013 @ 13:18:
[...]


Dit.

De opera mini servers gebruiken, als ze inderdaad IPv6 hebben, IPv6 om websites te bereiken. Wat mobieltjes doen heeft daar niks mee te maken.

Vrijwel alle mensen in Nederland gebruiken de config instellingen welke door de providers verstuurd worden om de mobiel online te krijgen. Zowel KPN als Vodafone sturen hier ook proxy instellingen mee welke door de browsers en applicaties gebruikt 'kunnen' worden.

Als de providers dual stack proxy servers inrichten is daar in ieder geval het probleem van de onbereikbare website mee opgelost. Het enige probleem is dat het internet niet uit poort 80 bestaat.

[Freeaqingme]

databeestje schreef op donderdag 17 oktober 2013 @ 07:31:
Noorwegen is goed bezig, die zijn in een paar dagen (vanaf 9 oktober) omhoog geschoten van 1.5 naar 7.6%

Het vermoeden is dat de opera mini servers IPv6 hebben gekregen.

Waar heb jij stats van Noorwegen?

[Keiichi]

Freeaqingme schreef op donderdag 17 oktober 2013 @ 19:47:
[...]


Waar heb jij stats van Noorwegen?

Google geeft op haar site cijfers van ongeveer dezelfde grootte aan: http://www.google.com/ipv...per-country-ipv6-adoption

[Freeaqingme]

Keiichi schreef op donderdag 17 oktober 2013 @ 19:49:
[...]


Google geeft op haar site cijfers van ongeveer dezelfde grootte aan: http://www.google.com/ipv...per-country-ipv6-adoption

Ik hoopte op stats waarbij een onderscheid gemaakt wordt tussen in- en uitgaand verkeer. Als je heel veel inkomend ipv6 verkeer ziet, wat niet de andere kant op gaat, dan zou 't inderdaad voor de hand liggen dat het om een proxy service zou gaan (of half Noorwegen is gaan torrenten met IPv6...).

Overigens is het plaatje van Google wel interessant. Ik gebruik sinds een paar dagen weer een HE Tunnelbroker adres, met een eindpunt in Zwitserland. Echter, alle geoip dingen die ik ben tegengekomen gebruiken het land van het ASN waar je ip bij hoort. In het geval van de HE Tunnelbroker dus allemaal vanuit de US.

[CAPSLOCK2000]

Cisco heeft ook leuke plaatjes:
http://6lab.cisco.com/stats/cible.php?country=NO
http://6lab.cisco.com/stats/cible.php?country=NL
http://6lab.cisco.com/stats/cible.php?country=world

[Keiichi]

CAPSLOCK2000 schreef op donderdag 17 oktober 2013 @ 21:21:
Cisco heeft ook leuke plaatjes:
http://6lab.cisco.com/stats/cible.php?country=NO
http://6lab.cisco.com/stats/cible.php?country=NL
http://6lab.cisco.com/stats/cible.php?country=world

De world is precies als van http://www.google.com/ipv6/statistics.html#tab=ipv6-adoption . Hebben ze niet ergens een samenwerking zitten hier

[joopv]

databeestje schreef op donderdag 17 oktober 2013 @ 07:31:
Edit: Eerste grote schaal NAT problemen in zicht
http://mailman.nanog.org/.../2013-October/061663.html

Ik (wij) zijn al jaren geleden tegen NAT problemen aangelopen. Zo delen alle of tenminste heel veel mobiele providers RFC1918 adressen uit aan de klanten. Kijk zelf even wat voor ip adres je 3g mobieltje gekregen heeft met een tooltje als "Ping&DNS", en je zult een 10.x.x.x adres zien.

Dat levert problemen op als je via vpn meerdere locaties over 3g wilt ontsluiten. Moet je weer speciale abbonementen en afspraken maken met de kpn/vodafone/whatever.

Ik ben ook al een zweedse of deense ISP tegengekomen die meerdere aansluitingen naar 1 publiek adres NATte. Het kost je iedere keer weer tijd en moeite om het recht te breien.

Ik ben bang dat we hier voorlopig nog niet van af zijn.

Het is wel een opsteker om te zien dat mijn aldi android telefoontje ipv6 ready is, als ik dat aanbied via wifi.

[Keiichi]

Check, hollands nieuwe (vodafone) en heb inderdaad een 10.0.0.0/8 range adres

[Osiris]

Vondafone idem ditto, een 10.0.0.0/8-adres.

Geen IPv6-adres tho..

[DDX]

Reden die vorige week in xs4all nieuwsgroep gepost werd door xs4all medewerker (op persoonlijke titel) :

Tsja, dat is ook nog een probleem- UMTS/HSDPA hardware die IPv6
doet. Vaak zit de protocol stack voor een groot deel in de
chipset ingebakken, en doet die gewoon geen IPv6. Daarom kan
vrijwel geen een Android telefoon IPv6 over het mobiele netwerk.

Ander probleem is dat voor de telco vaak dual-stack betekent
"dual license", het zijn 2 sessies dus betaal je 2x zoveel aan
de leverancier voor je licentie. In de laatste standaarden voor
3G is dat opgelost door IPv4 en IPv6 in 1 PDP te doen, maar
dat moet je apparatuur ook maar ondersteunen.

Bij LTE is IPv6 support verplicht, dus dat moet in alle
apparatuur zitten. Vraag is of het aanstaat natuurlijk.. kans
is van niet.

[DDX]

<oops dubbel>

[ Voor 97% gewijzigd door DDX op 17-10-2013 22:46 ]

[Osiris]

Zo, HTC maar meteen eens een support-vraagje gesteld via het contactformulier. Verwacht er niet veel van though, vorige keren reageerden ze ook nooit.