Het grote IPv6 topic

quote:

Roetzen schreef op woensdag 01 december 2010 @ 01:13:
Wat Lagerholm bedoelt met "two left" is dat als die twee opgevraagd worden, het spel uit is

Exact, er valt daarna niets meer toe te wijzen, alles is dan al toegewezen. Zondermeer is nog niet alles actief in gebruik op dat moment, maar wel toegewezen.

En dat is feitelijk wel game over.

quote:

Roetzen schreef op woensdag 01 december 2010 @ 01:13:
[...]

Eh nee. Het houdt in dat de laatste die nu nog twee blokken aanvraagt er drie krijgt en de overige vier er nog één krijgen.

Klopt.

quote:

Wat Lagerholm bedoelt met "two left" is dat als die twee opgevraagd worden, het spel uit is

Ja, wat IANA betreft ja. Maar de RIRs hebben dan samen nog 7 /8's uit te delen en dat duurt nog wel even hoor. Zeker omdat ze tegen die tijd een nog strakkere uitgiftepolicy gaan hanteren.

Voor de duidelijkheid: IANA geeft /8's aan RIRs zodat zij ze kunnen toewijzen. Dat is niet meer dan 'RIPE, jullie mogen 123/8 uitgeven. De rest: 123/8 is van RIPE. Afblijven dus'. Het toewijzen 'ISP X, 123.0/16 is bij deze aan jullie toegewezen' is voor de RIRs en dát is wat uitmaakt.

CyBeR wijzigde dit bericht 01-12-2010 01:35 (21%)

quote:

CyBeR schreef op woensdag 01 december 2010 @ 01:33:
Ja, wat IANA betreft ja. Maar de RIRs hebben dan samen nog 7 /8's uit te delen en dat duurt nog wel even hoor. Zeker omdat ze tegen die tijd een nog strakkere uitgiftepolicy gaan hanteren.

Inderdaad, alleen wat de IANA betreft.Het spel gaat dan verder op regionaal niveau en wat dat betreft is het ieder voor zich. De RIRs moeten het dan doen met wat ze hebben, ze kunnen niet meer aanvullen uit de globale voorraad.

De verwachting is dat APNIC aan het eind van volgend jaar door haar voorraad heen is en RIPE en ARIN over twee jaar. Maar dan is het nog niet over, want dan gaat het verder op LIR niveau. En dan op ISP niveau. Het kan dus nog even duren voordat de eerste eindgebruiker geen globaal routeerbaar IPv4 adres krijgt.

quote:

Roetzen schreef op woensdag 01 december 2010 @ 09:33:
Het kan dus nog even duren voordat de eerste eindgebruiker geen globaal routeerbaar IPv4 adres krijgt.

Hetgeen geen enkele reden is om ons rijk te rekenen. Feit blijft namelijk wel dat dat moment er onherroepelijk aan ligt te komen.

quote:

Kharay1977 schreef op woensdag 01 december 2010 @ 16:17:
Hetgeen geen enkele reden is om ons rijk te rekenen. Feit blijft namelijk wel dat dat moment er onherroepelijk aan ligt te komen.

Helemaal mee eens! Het is onontkoombaar en zelfs al duurt het nog vijf jaar voordat we er echt iets van gaan merken, dan zijn we nu al aan de erg late kant met de introductie van IPv6. Erik Huizer heeft het volste gelijk van de wereld: het gaat véél te langzaam. Het feit dat een grote ISP als Ziggo zegt nog niets te doen spreekt boekdelen!

quote:

Roetzen schreef op dinsdag 30 november 2010 @ 22:32:
[...]

Beter dan andersom zou ik zeggen. Jouw probleem is oplosbaar door een andere router te kopen. Mijn provider (Ziggo) zegt nog niks aan IPv6 te doen. Dat los ik niet op met een andere router.

Intern schijnen ze aan het testen te zijn: http://www.webhostingtalk...-ziggo-en-ipv6-zucht.html
Let op de posts van Spyder01

Na wat pogingen in mei vorig jaar wil ik toch ipv6 maar weer eens een nieuwe poging geven. Ik kreeg het toen niet voor elkaar om vanaf een client (W7 RC1) welke een IP via radvd verkreeg online te krijgen.

Ik tracht momenteel hetzelfde te bereiken tussen twee CentOS machines wederom zonder succes. Over een maandje zal ik op deze machines gaan beschikken over native ipv6 in het DC en zou dan ook graag mijn zaken ipv6 enabled hebben.

router:

1. Heeft eth0 (WAN interface)
2. Heeft he-ipv6 voor de tunnel
3. Heeft eth1 (LAN interface) met als IP 2001:470:xxxx:xxxx:xxxx:29ff:fef0:2042/64
4. Heeft ipv6 forwarding geconfigureerd middels "sysctl -w net.ipv6.conf.all.forwarding=1"

Routetabel:
code:

Kernel IPv6 routing table
Destination                                 Next Hop                                Flags Metric Ref    Use Iface
2001:470:xxxx:xxxxx::/64                      *                                       U     256    0        0 he-ipv6
2001:470:xxxx:xxxx:xxxx:29ff:fe48:ab57/128    2001:470:xxxx:xxxx:xxxx:29ff:fe48:ab57    UAC   0      8        0 eth1
2001:470:xxxx:xxxx::/64                      *                                       UA    256    8        0 eth1
fe80::/64                                   *                                       U     256    0        0 eth0
fe80::/64                                   *                                       U     256    0        0 he-ipv6
fe80::/64                                   *                                       U     256    0        0 eth1
*/0                                         *                                       U     1024   0        0 he-ipv6
*/0                                         fe80::20c:29ff:fef0:2042                UGDA  1024   6        0 eth1
localhost6.localdomain6/128                 *                                       U     0      0        1 lo
2001:470:xxxx:xxxx::/128                     *                                       U     0      0        2 lo
xxxxxxxxxx-pt.tunnel.tserv11.ams1.ipv6.he.net/128 *                                       U     0      2        1 lo
2001:470:xxxx:xxxx:xxxx:29ff:fef0:2042/128    *                                       U     0      3        1 lo
fe80::/128                                  *                                       U     0      0        2 lo
fe80::559e:fbd4/128                         *                                       U     0      0        1 lo
fe80::20c:29ff:fef0:2038/128                *                                       U     0      0        1 lo
fe80::20c:29ff:fef0:2042/128                *                                       U     0      3        1 lo
ff02::1/128                                 ff02::1                                 UC    0      10       0 eth1
ff02::1:fff0:2042/128                       ff02::1:fff0:2042                       UC    0      1        0 eth1
ff00::/8                                    *                                       U     256    0        0 eth0
ff00::/8                                    *                                       U     256    0        0 he-ipv6
ff00::/8                                    *                                       U     256    0        0 eth1

client:

1. Heeft eth0 (LAN interface) met als IP 2001:470:xxxx:xxxx:xxxx:29ff:fe48:ab57/64

Routetabel:
code:

Kernel IPv6 routing table
Destination                                 Next Hop                                Flags Metric Ref    Use Iface
2001:470:xxxx:xxxx::/64                      *                                       UA    256    346       0 eth0
fe80::/64                                   *                                       U     256    0        0 eth0
*/0                                         fe80::20c:29ff:fef0:2042                UGDA  1024   6        0 eth0
localhost6.localdomain6/128                 *                                       U     0      0        1 lo
2001:470:xxxx:xxxx:xxxx:29ff:fe48:ab57/128    *                                       U     0      72       1 lo
fe80::20c:29ff:fe48:ab57/128                *                                       U     0      6        1 lo
ff02::1/128                                 ff02::1                                 UC    0      347       0 eth0
ff00::/8                                    *                                       U     256    0        0 eth0

Het resultaat tot zover komt neer op:

1. De router kan zonder problemen naar buiten toe ping6-en
2. De eth1 van de router krijgt netjes een IP uit de range van radvd
3. De eth0 van de client krijgt netjes een IP uit de range van radvd
4. De router en client kunnen elkaar pingen
5. De client kan niet naar www2.surfnet.nl pingen

Nou is mijn route kennis al jaren onder de maat en lijkt me dit een goed leermoment om hier toch maar eens wat meer aandacht aan te besteden. Ik snap nu alleen even niet waar het fout loopt en zou hier graag een duw in de goede richting ontvangen (maak het niet makkelijk met een kant en klare oplossing, ik wil het snappen )


Aangezien ik vanaf de client met een traceroute6 nergens komt verwacht ik dat het probleem ook daar zit. Ik vermoed dan ook dat de client mijn /64 weet te vinden via eth0 maar zou niet weten waar hij de overige naar toe zou moeten sturen.

Is het toevoegen van een route naar 2000/3 via eth0 hier dan de oplossing of snapt de cliënt wel waar zijn ipv6 adres vandaan komt en zal hij onbekende adressen hierheen sturen?

Heb je eth1 wel een statisch IP gegeven uit het subnet wat je met RADVD adverteert?

En hoe ziet je radvd.conf er uit?

Snow_King wijzigde dit bericht 02-12-2010 10:00 (18%)

Druk bezig met het spelen met IPv6, echter zoek ik nu een provider waar ik mijn domein(en) kan hosten en waar ik zelf mijn DNS kan beheren en dus ook AAAA records kan aanmaken.

Iemand tips?
Liefst natuurlijk ook niet te duur, heb ik geen webspace o.i.d. nodig.

edit: Ik heb er een gevonden: http://yourwebhoster.eu, als dit als reclame wordt gezien, dan laat maar horen, haal ik het weer weg.

BlackBurn wijzigde dit bericht 02-12-2010 10:58 (20%)

quote:

Snow_King schreef op donderdag 02 december 2010 @ 10:00:
Heb je eth1 wel een statisch IP gegeven uit het subnet wat je met RADVD adverteert?

En hoe ziet je radvd.conf er uit?

Nee die heeft hij toegewezen gekregen, is dus niet statisch. De config is als volgt:
code:

# cat /etc/radvd.conf
interface eth1 {
        AdvSendAdvert on;
        MinRtrAdvInterval 3;
        MaxRtrAdvInterval 10;
        prefix 2001:470:xxxx:xxxx::/64 {
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr on;
        };
};

quote:

sPENKMAN schreef op donderdag 02 december 2010 @ 11:10:
[...]


Nee die heeft hij toegewezen gekregen, is dus niet statisch. De config is als volgt:
code:

# cat /etc/radvd.conf
interface eth1 {
        AdvSendAdvert on;
        MinRtrAdvInterval 3;
        MaxRtrAdvInterval 10;
        prefix 2001:470:xxxx:xxxx::/64 {
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr on;
        };
};

Ik zou eth1 een static adres geven via je configuratie, daarna kan je via radvd adverteren en moet het werken.

quote:

Raven schreef op woensdag 01 december 2010 @ 19:07:
[...]

Intern schijnen ze aan het testen te zijn: http://www.webhostingtalk...-ziggo-en-ipv6-zucht.html
Let op de posts van Spyder01

Dank voor de link. Interessant leesvoer.

Ik moet zeggen dat ik niet erg onder de indruk ben van de vorderingen bij Ziggo. Het schiet niet echt op. Ik heb niet veel hoop dat ze native IPv6 aan de gewone klanten zoals ik kunnen bieden voordat een niet te verwaarlozen deel van het InterNet IPv6 only zal zijn.

En waar ik me ook een beetje zorgen over maak, is dat enkele IPv6 adres dat Spyder01 krijgt, ipv minimaal een /64. Dat is raar, het druist tegen alles in. Ok, het is een test, maar als dat standaard wordt, dan snappen ze er niks van en moest ik maar weer eens gaan shoppen...

quote:

Roetzen schreef op donderdag 02 december 2010 @ 12:04:
voordat een niet te verwaarlozen deel van het InterNet IPv6 only zal zijn.

Wanneer verwacht je dat dat het geval zal zijn?

quote:

En waar ik me ook een beetje zorgen over maak, is dat enkele IPv6 adres dat Spyder01 krijgt, ipv minimaal een /64. Dat is raar, het druist tegen alles in. Ok, het is een test, maar als dat standaard wordt, dan snappen ze er niks van en moest ik maar weer eens gaan shoppen...

Volgens een Ziggo medewerker is dat een fout en is er geen IPv6 binnen Ziggo.

Je kan ook gewoon NAT'en? Werkt al jaren prima

quote:

Freeaqingme schreef op donderdag 02 december 2010 @ 13:13:
Je kan ook gewoon NAT'en? Werkt al jaren prima

Ik denk dat de meeste onder ons juist van NAT af willen
Ik in ieder geval wel.

icehawk wijzigde dit bericht 02-12-2010 13:45 (4%)

quote:

Olaf van der Spek schreef op donderdag 02 december 2010 @ 12:22:
[...]
Volgens een Ziggo medewerker is dat een fout en is er geen IPv6 binnen Ziggo.

Volgens deze pagins klopt dat ook wel: http://www.peeringdb.com/...ticipant_view.php?id=1668

quote:

Freeaqingme schreef op donderdag 02 december 2010 @ 13:13:
Je kan ook gewoon NAT'en? Werkt al jaren prima

Grapjas. Hoeveel routers gaan niet over hun nek door p2p apps als BT? Windows ondersteunt geen automatic port forwarding (voor apps zonder UPnP), dus veel (oude) p2p apps/games hebben veel last van NAT.

quote:

Olaf van der Spek schreef op donderdag 02 december 2010 @ 12:22:
{Voordat een significant deel van het InterNet IPV6 ony zal zijn}
Wanneer verwacht je dat dat het geval zal zijn?

Volgens Lagerholm:
2% over 2 jaar.
4% over 2,5 jaar
10% over 4 tot 5 jaar.
http://www.ipv4depletion.com/?p=507

quote:

{IPv6 bij Ziggo}
Volgens een Ziggo medewerker is dat een fout en is er geen IPv6 binnen Ziggo.

Sja...

quote:

Olaf van der Spek schreef op donderdag 02 december 2010 @ 14:02:
[...]

Grapjas. Hoeveel routers gaan niet over hun nek door p2p apps als BT?

De vraag is of dat verandert. Ook als je je router als firewall inzet moet deze bijhouden welke client welke verbindingen geopend heeft

quote:

icehawk schreef op donderdag 02 december 2010 @ 13:45:
Ik denk dat de meeste onder ons juist van NAT af willen
Ik in ieder geval wel.

Ik zal het in elk geval niet missen als we eenmaal van IPv4 af zijn...

quote:

Roetzen schreef op donderdag 02 december 2010 @ 14:24:
[...]

Volgens Lagerholm:
2% over 2 jaar.
4% over 2,5 jaar
10% over 4 tot 5 jaar.
http://www.ipv4depletion.com/?p=507

Dat 10% van de clients in Azie geen IPv4 adres heeft is voor Ziggo toch ook geen noodzaak om IPv6 in te voeren?

quote:

Olaf van der Spek schreef op donderdag 02 december 2010 @ 19:05:
[...]

Dat 10% van de clients in Azie geen IPv4 adres heeft is voor Ziggo toch ook geen noodzaak om IPv6 in te voeren?

.A) Wie zegt dat die 10% alleen in Azië zit?

.B) Als het echt alleen clients zijn is er geen probleem. Maar wat als ik met één van die IPv6 only eindstations een P2P wil opbouwen? Hoe moet dat als ik geen IPv6 heb?

quote:

Olaf van der Spek schreef op donderdag 02 december 2010 @ 19:05:
[...]

Dat 10% van de clients in Azie geen IPv4 adres heeft is voor Ziggo toch ook geen noodzaak om IPv6 in te voeren?

Jawel, want die zijn dus niet bereikbaar voor Ziggo-klanten en dus krijgen Ziggo-klanten maar een deel van het Internet en dat is niet waar ze voor betalen.

quote:

Roetzen schreef op donderdag 02 december 2010 @ 19:45:
.A) Wie zegt dat die 10% alleen in Azië zit?

Daar stijgt het gebruik van IPv6 het snelst.

quote:

CyBeR schreef op donderdag 02 december 2010 @ 20:05:
Jawel, want die zijn dus niet bereikbaar voor Ziggo-klanten en dus krijgen Ziggo-klanten maar een deel van het Internet en dat is niet waar ze voor betalen.

Is dat zo? Dus als ik een IPv8 server opzet moet Ziggo ook ineens IPv8 invoeren?

Olaf van der Spek wijzigde dit bericht 02-12-2010 20:20 (22%)

quote:

Olaf van der Spek schreef op donderdag 02 december 2010 @ 20:19:
[...]

Is dat zo? Dus als ik een IPv8 server opzet moet Ziggo ook ineens IPv8 invoeren?

Als IPv8 door de internetgemeenschap geaccepteerd en breed geïmplementeerd wordt, ja.

Maar tot die tijd ben jij gewoon een of andere gast die zit te kutten met een protocol dat niemand anders praat, dus nee.

quote:

Snow_King schreef op donderdag 02 december 2010 @ 11:51:
Ik zou eth1 een static adres geven via je configuratie, daarna kan je via radvd adverteren en moet het werken.

Inderdaad, dat werkt. Maar wat is hier het subtiele verschil, als eth1 een dynamic IP heeft zou dit toch niet uit moeten maken (hence autodiscovery) of mis ik hier iets?


Heb wel 1 vreemd ding, de eerste serie met ping's komt niet aan. Als hij pinged en ik probeer het nog een keer gaat wel wel goed. Lijkt dus iets niet helemaal lekker te zitten vooralsnog

client > www2.surfnet.nl
code:

[root@web01 ~]# ping6 www2.surfnet.nl
PING www2.surfnet.nl(2001:610:1:40cd:145:100:186:12) 56 data bytes
64 bytes from 2001:610:1:40cd:145:100:186:12: icmp_seq=9 ttl=58 time=10.3 ms
64 bytes from 2001:610:1:40cd:145:100:186:12: icmp_seq=10 ttl=58 time=10.7 ms

server > www2.surfnet.nl
code:

[root@lb01 ~]# ping6 www2.surfnet.nl
PING www2.surfnet.nl(2001:610:1:40cd:145:100:186:12) 56 data bytes
64 bytes from 2001:610:1:40cd:145:100:186:12: icmp_seq=8 ttl=59 time=10.3 ms
64 bytes from 2001:610:1:40cd:145:100:186:12: icmp_seq=9 ttl=59 time=10.3 ms

externe ipv6 server (ook een tunnelbroker tunnel) naar de client
code:

lucky:~# ping6 2001:470:xxxx:xxxx:xxxx:29ff:fe48:ab57
PING 2001:470:xxxx:xxxx:xxxx:29ff:fe48:ab57(2001:470:xxxx:xxxx:xxxx:29ff:fe48:ab57) 56 data bytes
64 bytes from 2001:470:xxxx:xxxx:xxxx:29ff:fe48:ab57: icmp_seq=18 ttl=62 time=9.64 ms
64 bytes from 2001:470:xxxx:xxxx:xxxx:29ff:fe48:ab57: icmp_seq=19 ttl=62 time=9.68 ms

externe ipv6 server (ook een tunnelbroker tunnel) naar de server @ eth1 (is ook van toepassing op eth0 ipv6 adres)
code:

lucky:~# ping6 2001:470:xxxx:xxxx:xxxx:29ff:fef0:2042
PING 2001:470:xxxx:xxxx:xxxx:29ff:fef0:2042(2001:470:xxxx:xxxx:xxxx:29ff:fef0:2042) 56 data bytes
64 bytes from 2001:470:xxxx:xxxx:xxxx:29ff:fe48:ab57: icmp_seq=10 ttl=62 time=10.0 ms
64 bytes from 2001:470:xxxx:xxxx:xxxx:29ff:fe48:ab57: icmp_seq=11 ttl=62 time=9.44 ms

sPENKMAN wijzigde dit bericht 02-12-2010 22:44 (9%)

quote:

sPENKMAN schreef op donderdag 02 december 2010 @ 22:41:
[...]


Inderdaad, dat werkt. Maar wat is hier het subtiele verschil, als eth1 een dynamic IP heeft zou dit toch niet uit moeten maken (hence autodiscovery) of mis ik hier iets?


Heb wel 1 vreemd ding, de eerste serie met ping's komt niet aan. Als hij pinged en ik probeer het nog een keer gaat wel wel goed. Lijkt dus iets niet helemaal lekker te zitten vooralsnog

Je gateway moet uiteraard een statisch IP hebben En ook zal je default route niet helemaal in orde zijn door het dynamische IP.

En die eerste ping's die je verliest, ik zie dat vaak ook, maar dan mis ik één pakketje. Ik gok dat het komt door de MTU path detectie, of dat de router nog een Neighbour Discovery moet doen. Jij verliest echter wel veel packets.

quote:

CyBeR schreef op donderdag 02 december 2010 @ 20:05:
[...]


Jawel, want die zijn dus niet bereikbaar voor Ziggo-klanten en dus krijgen Ziggo-klanten maar een deel van het Internet en dat is niet waar ze voor betalen.

Hoe groot is de kans dat ik een IPv6 only site in azie wil bezoeken.

Of nog beter gezegd, hoe groot is de kans dat ik uberhaupt en site in azie wil bezoeken

Wat Ziggo en andere providers betreft, voor hun staat ipv6 only hosts buiten het internet.

quote:

Keiichi schreef op vrijdag 03 december 2010 @ 09:24:
[...]

Hoe groot is de kans dat ik een IPv6 only site in azie wil bezoeken.

Of nog beter gezegd, hoe groot is de kans dat ik uberhaupt en site in azie wil bezoeken

Wat Ziggo en andere providers betreft, voor hun staat ipv6 only hosts buiten het internet.

Bepaald Ziggo dan dat jij die site NIET mag bezoeken? Internet is internet, hiermee moet jij gewoon alles kunnen bereiken.

quote:

Keiichi schreef op vrijdag 03 december 2010 @ 09:24:
[...]

Hoe groot is de kans dat ik een IPv6 only site in azie wil bezoeken.

Who cares? Dat heeft Ziggo niet voor jou uit te maken. Dat jij je beperkt tot .nl betekent niet dat ik dat ook moet doen.

CyBeR wijzigde dit bericht 03-12-2010 09:45 (11%)

quote:

Keiichi schreef op vrijdag 03 december 2010 @ 09:24:
[...]

Hoe groot is de kans dat ik een IPv6 only site in azie wil bezoeken.

Ik heb neefjes die nog wel eens in Azië komen. Kan ik met ze skypen. Todat ze ergens komen waar alleen IPv6 beschikbaar is...

quote:

Of nog beter gezegd, hoe groot is de kans dat ik uberhaupt en site in azie wil bezoeken

Wat Ziggo en andere providers betreft, voor hun staat ipv6 only hosts buiten het internet.

Het idee dat IPv6 only beperkt zal blijven tot Australasië en dus ons niet raakt is een waanidee.

Over vijf jaar is een InterNet aansluiting zonder IPv6 even beperkt als een vaste telefoonaansluiting waarmee je alleen naar andere vaste nummers kunt bellen. Twintig jaar geleden had je misschien nog kunnen zeggen "Hoe groot is de kans dat ik naar een mobielofoon wil bellen?" Tien jaar geleden zou een telefoonaanbieder daar al niet meer mee weg gekomen zijn.

Ziggo moet gewoon aan de slag. Doen ze het niet dan raken ze klanten kwijt omdat bijvoorbeeld de skype verbinding met hun kleinzoon in Australië niet meer werkt.

Dat klanten weglopen zal wel meevallen. Een Teredo tunnel is vrij makkelijk opgezet

Tunnels zijn lapmiddelen. Leuk om mee te experimenteren in de overgangsfase, maar niet aanvaardbaar als definitieve oplossing. Tunnels zijn traag en kwetsbaar. Bovendien schaalt het niet goed en geeft het onnodig veel overhead op het netwerk. Als Ziggo massaal tunnels moet gaan opzetten voor haar klanten, heeft ze ook een probleem.

En denk nou niet dat SixXs en Hurricane Electric gratis tunnels blijven aanbieden als native IPv6 de norm wordt. Nee, ISPs die achterblijven, gaan klanten verliezen. Mij in elk geval...

Roetzen wijzigde dit bericht 03-12-2010 11:43 (5%)

En wat denk je van oma die met haar kleinkinderen in Australie wil skypen? Die wil gewoon kunnen kletsen, klaar.. En als dat bij bijvoorbeeld Telfort wel werkt, en Ziggo niet, dan stapt ze op advies van kennissen of programma's als Radar of Kassa wel over.

Precies. Oma weet niks van tunnels en wil daar ook niks van weten. Het moet gewoon werken, punt uit. En doet het dat niet en bij de buurman wel, dan gaat de markt zijn werk doen...

quote:

Roetzen schreef op vrijdag 03 december 2010 @ 13:10:
En doet het dat niet en bij de buurman wel, dan gaat de markt zijn werk doen...

En laat de markt dan ook maar z'n werk doen.

Als ISP <x> gewoon te lui of te krenterig is om geld te steken in IPv6... sjah, leuk jullie gekend te hebben, ISP <x>, veel plezier bij de curator.

Want 50% van de ISP <x>-gebruikers Skypt ook echt met IPv6-only clients in Australië/Azië hè?

Denk dat dat wel los zal lopen..

quote:

Osiris schreef op vrijdag 03 december 2010 @ 15:19:
Want 50% van de ISP <x>-gebruikers Skypt ook echt met IPv6-only clients in Australië/Azië hè?

Dat is dus niet het punt, en als je dat wel denkt dan snap je het dus gewoon niet.

Ik snap jullie theoretische punt wel, maar ik zeg alleen dat een ISP niet wakker zal liggen van z'n handjevol klanten wat mísschien weg zal lopen.

quote:

Osiris schreef op vrijdag 03 december 2010 @ 15:40:
Ik snap jullie theoretische punt wel, maar ik zeg alleen dat een ISP niet wakker zal liggen van z'n handjevol klanten wat mísschien weg zal lopen.

Nee maar dat kunnen ze ook maar een bepaalde tijd volhouden.

quote:

Osiris schreef op vrijdag 03 december 2010 @ 15:19:
Want 50% van de ISP <x>-gebruikers Skypt ook echt met IPv6-only clients in Australië/Azië hè?

Ja, want, waarom zou je de moeite nemen alvast voorbereid te zijn, hè?

Voor het thuisnetwerk waarschijnllijk niet relevant, maar toch leuk leesvoer. Let ook op de twee bekende namen in het commentaar....

IPv6-switches zonder filtering zijn onveilig
Er gaan al enkele jaren stemmen op, dat het vijf voor twaalf is. Nog maar een paar IPv4-adressen over, dus we moeten overstappen naar IPv6. Wel even opletten dat u veilige switches gebruikt.

Read more: http://www.computable.nl/...tering-zijn-onveilig.html

Achja, switches, routers...

quote:

Osiris schreef op vrijdag 03 december 2010 @ 15:40:
Ik snap jullie theoretische punt wel, maar ik zeg alleen dat een ISP niet wakker zal liggen van z'n handjevol klanten wat mísschien weg zal lopen.

Dat dachten ze bij T-Mobile ook.

Totdat Youp zich er mee ging bemoeien....

Edit: De eerlijkheid gebiedt me er overigens bij te zeggen dat T-Mobile zeer actief is met IPv6: http://www.personal.psu.e...is-pushing-ipv6-hard.html

Roetzen wijzigde dit bericht 03-12-2010 17:42 (22%)

kansloos artikel IMHO

quote:

En laat MAC-filtering nu juist een van de belangrijkste beveiligingssystemen zijn voor draadloze netwerken en ook voor netwerken die nog geen of zeer weinig IPv6-functionaliteit aan boord hebben. Doordat deze Cisco switches geen IPv6-filtering op MAC-adresniveau meer toestaan, v

Read more: http://www.computable.nl/...veilig.html#ixzz174U9nhxY

wie gebruikt er nou serieus mac-address filtering op zijn netwerk. Iedere computer idee gebruiker weet dat dit de spoofen is.

Wireless access dien je te beveiligen met een goede encryptie.

T-mo USA != T-mo NL

quote:

TrailBlazer schreef op vrijdag 03 december 2010 @ 18:39:
wie gebruikt er nou serieus mac-address filtering op zijn netwerk. Iedere computer idee gebruiker weet dat dit de spoofen is.

Inderdaad. Dit moet je port-based doen.

quote:

TrailBlazer schreef op vrijdag 03 december 2010 @ 18:39:
kansloos artikel IMHO

[...]

wie gebruikt er nou serieus mac-address filtering op zijn netwerk. Iedere computer idee gebruiker weet dat dit de spoofen is.

Er zijn prima redenen om MAC-filtering te gebruiken. Kwaadwillende gebruikers buiten houden is er niet een van.

quote:

Wireless access dien je te beveiligen met een goede encryptie.

Dit ging om wired, maar verder klopt dat wel ja.

quote:

CyBeR schreef op vrijdag 03 december 2010 @ 21:28:
Er zijn prima redenen om MAC-filtering te gebruiken. Kwaadwillende gebruikers buiten houden is er niet een van.

Wat wel dan?

quote:

CyBeR schreef op vrijdag 03 december 2010 @ 21:28:
[...]


Er zijn prima redenen om MAC-filtering te gebruiken. Kwaadwillende gebruikers buiten houden is er niet een van.


[...]


Dit ging om wired, maar verder klopt dat wel ja.

In dat deel wat ik quote wordt specifiek wireless genoemd anders.
Ik weet trouwens niet over welke mac filtering ze het hebben maar een mac-acl op een Cisco matched sowieso nooit IPv4 verkeer

Het blijft wennen, dat IPv6, de langere adressen zijn voor mij geen probleem, maar de uitbreidingen op het protocol t.o.v. IPv4 zijn wel wat lastiger, bijvoorbeeld omdat je je firewalls nu moet leren dat ze moeten filteren op Routing Header Type 0 (RH0)-packetjes, en meer van dat soort geintjes (voornamelijk ICMPv6-spul).

Als er hier iemand is die een goede software-firewall weet voor CentOS/RHEL op basis van ip6tables, dan hoor ik het graag, want ik heb er nu voornamelijk zelf een scriptje tegenaan gegooid op de servers

Nu moet ik bekennen dat mijn upstream-provider de routing verzorgt voor onze VLAN, dus ik hoef me over dat gedeelte niet druk om te maken, en onze switches zijn dan wel managed, maar allemaal Layer-2, dus ook daar kan ik weinig in betekenen. De kans dat iemand zich fysiek toegang verschaft tot onze switches/LAN-poorten acht ik heel klein, gezien het rack gewoon op slot zit.

Ook is het me nog niet helemaal duidelijk in hoeverre je adressen moet toewijzen, ik houd me als hoster maar aan het oude principe van een publiek IP, en eventueel een management IP per server, maar zou het wellicht beter zijn om elke domeinnaam zijn eigen IPv6 adres te geven? Waarbij ik het dus over gewoon http-verkeer heb, want voor certificaten heb je natuurlijk altijd voor elk domein een eigen adres nodig.

Vragen, vragen, en dan nog een hoop knutselen om alle services bereikbaar te krijgen, en te houden, op IPv6. DNS, FTP, HTTP en SSH zijn gelukkig achter de rug, resteert voor mij nog SMTP, POP3 en IMAP..

Hier doen we ieder domeinnaam/subdomein 1 ip adres, en dan gewoon lekker ip based vhosts. Dat doe je alleen als ip adressen een gebrek zijn - en dat is bij ipv6 niet het geval.

quote:

AndriesLouw schreef op donderdag 09 december 2010 @ 21:20:
Waarbij ik het dus over gewoon http-verkeer heb, want voor certificaten heb je natuurlijk altijd voor elk domein een eigen adres nodig.

Nee hoor, daar heb je tegenwoordig SNI voor.

quote:

Olaf van der Spek schreef op donderdag 09 december 2010 @ 21:33:
[...]

Nee hoor, daar heb je tegenwoordig SNI voor.

Dan moeten alle certificaten wel op naam van dezelfde organisatie staan? bronnetje

quote:

Freeaqingme schreef op donderdag 09 december 2010 @ 21:40:
Dan moeten alle certificaten wel op naam van dezelfde organisatie staan? bronnetje

Niet dat ik weet. Die paragraaf gaat niet over SNI maar over work arounds zonder SNI.

Ik weet van het bestaan van SNI af, en ook dat dat niet werkt in de wat oudere browsers (*kuch* IE6 en IE7 op XP *kuch*), waardoor het effectief voor 99% van onze klanten niet zinnig is.

Dus nee, SNI is voorlopig niet de oplossing voor het 1 IP-adres <-> 1 domein probleem, certificaten met daarin meerdere CN's zouden wellicht wel een oplossing zijn, maar die laat ik even buiten beschouwing, en dat is wel weer genoeg off-topic..

quote:

AndriesLouw schreef op donderdag 09 december 2010 @ 22:11:
Ik weet van het bestaan van SNI af, en ook dat dat niet werkt in de wat oudere browsers (*kuch* IE6 en IE7 op XP *kuch*), waardoor het effectief voor 99% van onze klanten niet zinnig is.

Die gebruiken zeer waarschijnlijk ook geen IPv6.

quote:

Olaf van der Spek schreef op donderdag 09 december 2010 @ 22:49:
[...]

Die gebruiken zeer waarschijnlijk ook geen IPv6.

SNI is ook bedoeld voor IPv4, en misschien daar voornamelijk wel voor. Daarbij; waarom de moeite nemen om met SNI te prutsen op IPv6, als je de adressen toch volop beschikbaar hebt?

quote:

AndriesLouw schreef op donderdag 09 december 2010 @ 23:07:
[...]

SNI is ook bedoeld voor IPv4, en misschien daar voornamelijk wel voor. Daarbij; waarom de moeite nemen om met SNI te prutsen op IPv6, als je de adressen toch volop beschikbaar hebt?

De configuratie is met SNI waarschijnlijk eenvoudiger dan zonder.

SNI is meer een work-around, dus ik zou zeker niet claimen dat je "daar tegenwoordig gewoon SNI voor hebt"..

quote:

Osiris schreef op donderdag 09 december 2010 @ 23:26:
SNI is meer een work-around, dus ik zou zeker niet claimen dat je "daar tegenwoordig gewoon SNI voor hebt"..

Hoezo is het een work-around?

Sinds gister nieuw (cisco) modem van UPC. Hiermee in de 77.xxx.xxx.xxx range gekomen en tot mijn verrassing hebben we nu native IPv6 adressen!

Helaas gaat chrome nog naar IPv4 default, eens kijken of daar iets aan te doen is.

Wel gratis usenet nu

Osxy wijzigde dit bericht 12-12-2010 02:26 (6%)

quote:

Osxy schreef op zondag 12 december 2010 @ 02:15:
Sinds gister nieuw (cisco) modem van UPC. Hiermee in de 77.xxx.xxx.xxx range gekomen en tot mijn verrassing hebben we nu native IPv6 adressen!

Helaas gaat chrome nog naar IPv4 default, eens kijken of daar iets aan te doen is.

Wel gratis usenet nu

Waar begint dat adres mee?

2002:4df9:27d2

Zie nu overigens dat dit een tunnel adres is? Maakt verder weinig uit, het word wel als native uitgedeeld door UPC. De stap naar echte IPv6 adressen is klein.

Moet wel zeggen dat de Airport als IPv6 tunnel aanstaat dus mogelijk heeft hij wel een normaal extern IPv6 adres? Of kan dit niet.

(Of ik zie spoken en de Airport is dusdanig slim dat hij met een tunnel broker contact heeft?)

Wel mooi om te zien dat onze Airport Extreme prima als IPv6 "router" kan dienen.

Osxy wijzigde dit bericht 12-12-2010 09:51 (75%)

2002:: Is een 6to4 adres. En dat maakt wel heel wat uit. De betrouwbaarheid is veel minder. Dat is ook waarom een fatsoenlijk programma de voorkeur geeft aan IPv4 boven een 6to4 adres.

Zie dit artikel: http://www.fix6.net/archi.../the-trouble-with-6to4-2/

Met zo'n adres gebruik je de tunnel alleen als je naar een IPv6-only adres wil verbinden.

Juist mijn eigen ipV6 subnet gekregen van sixxs

quote:

Olaf van der Spek schreef op donderdag 09 december 2010 @ 23:33:
[...]

Hoezo is het een work-around?

't Is gemaakt om een probleem op te lossen wat er überhaupt niet had moeten zijn

quote:

Osxy schreef op zondag 12 december 2010 @ 09:39:
2002:4df9:27d2

Zie nu overigens dat dit een tunnel adres is? Maakt verder weinig uit, het word wel als native uitgedeeld door UPC. De stap naar echte IPv6 adressen is klein.

Moet wel zeggen dat de Airport als IPv6 tunnel aanstaat dus mogelijk heeft hij wel een normaal extern IPv6 adres? Of kan dit niet.

(Of ik zie spoken en de Airport is dusdanig slim dat hij met een tunnel broker contact heeft?)

Wel mooi om te zien dat onze Airport Extreme prima als IPv6 "router" kan dienen.

Dat is, zoals gezegd, een 6to4-adres. Dat is een geheel automatische tunnel, waar geen tunnel broker set-up aan te pas komt, maar die werkt met vaste (anycast) IPv4-adressen aan de kant van de 'tunnel broker'. Jouw adres zit in de derde tot en met zesde octets verwerkt. Zo weet de tunnel doos waar de getunnelde packets heen moeten in IPv4-land.

Je Airport zet dit automatisch op als 'ie op z'n WAN-poort een niet-RFC1918 IP-adres heeft. UPC heeft er in ieder geval niets mee te maken

quote:

AndriesLouw schreef op donderdag 09 december 2010 @ 21:20:
Als er hier iemand is die een goede software-firewall weet voor CentOS/RHEL op basis van ip6tables, dan hoor ik het graag, want ik heb er nu voornamelijk zelf een scriptje tegenaan gegooid op de servers

Er is een IPv6 variant van Shorewall. Shorewall is niet heel eenvoudig, maar het is goed gedocumenteerd. Met een beetje knutselwerk kun je het grootste deel van je configuratie delen tussen ipv4 en ipv6.

CAPSLOCK2000 wijzigde dit bericht 13-12-2010 00:51 (10%)

quote:

Osiris schreef op zondag 12 december 2010 @ 13:53:
[...]

't Is gemaakt om een probleem op te lossen wat er überhaupt niet had moeten zijn

Waarom niet? Extra adressen toekken alleen voor TLS lijkt me juist een work around.

quote:

Olaf van der Spek schreef op maandag 13 december 2010 @ 01:28:
[...]

Waarom niet? Extra adressen toekken alleen voor TLS lijkt me juist een work around.

SNI is onhandig omdat je daarmee voordat je TLS genegotiate hebt (dus plaintext) informatie aan het versturen bent over wie je daar verwacht aan te treffen. Het andere alternatief, subjectAltName, is onhandig omdat je bij elke nieuwe hostname een nieuw certificaat moet fixen.

De 'goede' manier van TLS is inderdaad mutually exclusive met virtual hosting. Je hebt namelijk vantevoren een idee van welke website je verwacht te krijgen, en laat die server achter dat ip maar bewijzen dat 'ie dat is, zonder te weten dat jij ernaar op zoek bent.

CyBeR wijzigde dit bericht 13-12-2010 01:39 (25%)

quote:

CyBeR schreef op zondag 12 december 2010 @ 15:08:
[...]
Je Airport zet dit automatisch op als 'ie op z'n WAN-poort een niet-RFC1918 IP-adres heeft.

Het is natuurlijk heel mooi dat ie helemaal zelfstandig 6to4 kan doen, maar of je er nu zo blij mee moet zijn dat het default aan staat?...

http://www.fix6.net/archi.../the-trouble-with-6to4-2/

6to4 schijnt nogal wat problemen te geven. misschien is het middel erger dan de kwaal. Misschien toch maar vast zoeken naar het "uit" knopje?

quote:

Roetzen schreef op maandag 13 december 2010 @ 10:58:
[...]


Het is natuurlijk heel mooi dat ie helemaal zelfstandig 6to4 kan doen, maar of je er nu zo blij mee moet zijn dat het default aan staat?...

http://www.fix6.net/archi.../the-trouble-with-6to4-2/

6to4 schijnt nogal wat problemen te geven. misschien is het middel erger dan de kwaal. Misschien toch maar vast zoeken naar het "uit" knopje?

6to4 geeft eigenlijk alleen problemen omdat er maar vrij weinig relays zijn. Als het gros van de ISPs dat als daadwerkelijke productiedienst op gaan zetten voor hun klanten wordt het verhaal al weer heel anders. De techniek zelf is vrij solide.

En voor de duidelijkheid: het geldt als een back-up zodat je IPv6-only content kunt bekijken zonder echte IPv6-verbinding. Als dezelfde content ook via IPv4 bereikbaar is, gaat dat voor op het moment dat je een 6to4-verbinding hebt.

CyBeR wijzigde dit bericht 13-12-2010 13:31 (15%)

quote:

CyBeR schreef op maandag 13 december 2010 @ 01:36:
SNI is onhandig omdat je daarmee voordat je TLS genegotiate hebt (dus plaintext) informatie aan het versturen bent over wie je daar verwacht aan te treffen.

Wat is daar onhandig aan?

quote:

De 'goede' manier van TLS is inderdaad mutually exclusive met virtual hosting. Je hebt namelijk vantevoren een idee van welke website je verwacht te krijgen, en laat die server achter dat ip maar bewijzen dat 'ie dat is, zonder te weten dat jij ernaar op zoek bent.

Dat heeft toch niks met security te maken?

quote:

Olaf van der Spek schreef op maandag 13 december 2010 @ 16:00:
[...]

Wat is daar onhandig aan?

Dat ik, privacy invadende netwerksniffer, weet dat jij naar https://www.wikileaks.org/ gaat, terwijl je dat anders compleet geheim had kunnen houden (de dns-lookup kun je voorkomen, en afhankelijk van waar ik als sniffer zit krijg ik die sowieso niet per definitie te zien) of in ieder geval vol had kunnen houden dat dat niet je bedoeling was ('plausible deniability').

quote:

Dat heeft toch niks met security te maken?

Natuurlijk wel. Als ik al vantevoren vertel wie ik ergens verwacht maakt 't dat een stuk makkelijker om diegene na te doen, nietwaar? Als ik iets verwacht en jij bevestigt dat zonder die verwachting te kennen is dat een stuk beter.

CyBeR wijzigde dit bericht 13-12-2010 16:12 (12%)

Voor shared hosting en dergelijke zou ik ook liever geen SNI gebruiken, maar voor diensten als google.* is het best handig. Je kunt in zo'n geval aan het IP-adres toch al wel zien dat iemand wil Googlen, het ergste wat je door SNI dus kunt achterhalen is welk TLD iemand gebruikt. Nou ja, vooruit dan maar.

quote:

CyBeR schreef op maandag 13 december 2010 @ 01:36:
Het andere alternatief, subjectAltName, is onhandig omdat je bij elke nieuwe hostname een nieuw certificaat moet fixen.

En omdat je daardoor als client alle gebruikte hostnamen kunt enumereren...

quote:

CAPSLOCK2000 schreef op maandag 13 december 2010 @ 00:50:
[...]

Er is een IPv6 variant van Shorewall. Shorewall is niet heel eenvoudig, maar het is goed gedocumenteerd. Met een beetje knutselwerk kun je het grootste deel van je configuratie delen tussen ipv4 en ipv6.

Shorewall en shorewall6 draaien bij mij naar volle tevredenheid. Wel op een Debian-systeem, maar het zal hoogstwaarschijnlijk ook op CentOS/RHEL draaien.

quote:

CyBeR schreef op maandag 13 december 2010 @ 13:29:
6to4 geeft eigenlijk alleen problemen omdat er maar vrij weinig relays zijn. Als het gros van de ISPs dat als daadwerkelijke productiedienst op gaan zetten voor hun klanten wordt het verhaal al weer heel anders. De techniek zelf is vrij solide.

Ik heb (binnen Nederland) eigenlijk alleen maar positieve ervaringen met 6to4. Inherent aan het systeem is ook dat als je eigen provider het niet ondersteunt het wordt doorgegeven, net zo lang tot je er een (=router) tegen komt die je wel wil helpen.

Eindelijk een ipv6 range van BT gekregen En nu hebben ze ook de router tof ingesteld, dus het werkt nu ein-de-lijk. Nu eens kijken wat de tofste manier is om ons kantoornetwerk op te delen in 3 /64's en ddns te hebben. Eigenlijk hetzelfde zoals we het nu ook met ipv4 doen.

Ik heb zowel met Teredo als 6to4 slechte ervaringen. Mijn website is meerdere keren niet te bereiken geweest voor gebruikers met dit soort tunnels. Telkens weer ergens een provider een dode of haperende relay had staan.

Na wat puzzelwerk zijn die dan wel te vinden en vaak lossen ze het redelijk snel op, maar het blijft een doosje wat ergens in een hoekje staat bij veel providers. En dan eentje wat vaak niet bewaakt wordt.

Als je dus wat met IPv6 wil doen, neem dan een echte tunnel. Ik ben zelf tevreden over Hurricane Electric (tunnelbroker.net).

Vandaag mijn SIXXS tunneltje aan de praat gekregen. Had nog wel even een leuk probleempje met het installeren van de TAP driver. Het bijbehorende batch bestandje is geschreven voor de Engelse versie van WIndows.. Maar ik heb een Duitse versie en daar heten de directories anders. Niet "Program Files", maar "Programme" bijvoorbeeld. Moest even de paden aanpassen om het aan de gang te krijgen.

Als het goed is, is mijn einde van de tunnel te pingen op test6.vlist.eu.

Nu de rest nog...

quote:

Roetzen schreef op woensdag 15 december 2010 @ 20:47:
Als het goed is, is mijn einde van de tunnel te pingen op test6.vlist.eu.

Niet helemaal zeg maar
code:

PING test6.vlist.eu(cl-938.ede-01.nl.sixxs.net) 56 data bytes
From gw-627.ede-01.nl.sixxs.net icmp_seq=1 Destination unreachable: No route
From gw-627.ede-01.nl.sixxs.net icmp_seq=2 Destination unreachable: No route
From gw-627.ede-01.nl.sixxs.net icmp_seq=3 Destination unreachable: No route
From gw-627.ede-01.nl.sixxs.net icmp_seq=4 Destination unreachable: No route

Terwijl mijn andere IPv6 hier wel prima werkt.

quote:

CyBeR schreef op maandag 13 december 2010 @ 16:08:
Dat ik, privacy invadende netwerksniffer, weet dat jij naar https://www.wikileaks.org/ gaat, terwijl je dat anders compleet geheim had kunnen houden (de dns-lookup kun je voorkomen, en afhankelijk van waar ik als sniffer zit krijg ik die sowieso niet per definitie te zien) of in ieder geval vol had kunnen houden dat dat niet je bedoeling was ('plausible deniability').


[...]


Natuurlijk wel. Als ik al vantevoren vertel wie ik ergens verwacht maakt 't dat een stuk makkelijker om diegene na te doen, nietwaar? Als ik iets verwacht en jij bevestigt dat zonder die verwachting te kennen is dat een stuk beter.

Dus je wilt een 1:1 mapping tussen DNS naam en adres, het adres is bekend en je wilt de naam geheimhouden? Lijkt me niet handig daar op te vertrouwen.

quote:

Olaf van der Spek schreef op woensdag 15 december 2010 @ 23:56:
[...]

Dus je wilt een 1:1 mapping tussen DNS naam en adres, het adres is bekend en je wilt de naam geheimhouden? Lijkt me niet handig daar op te vertrouwen.

Eh. Gegeven een IP-adres en geen reverse DNS voor dat ip, hoe ga jij achter die naam komen dan? Die mapping is helemaal niet 1:1.

CyBeR wijzigde dit bericht 16-12-2010 01:40 (4%)

Bedankt voor de tips richting Shorewall, maar van wat ik er van lees is dat bedoeld voor gateway's en/of losstaande firewall's. Ik ben dus eigenlijk op zoek naar een firewall die direct op een server is in te zetten, waarbij de server op een IP zit dat publiek gerouted wordt, enkel gescheiden van het "grote boze internet" door een enkele managed switch.

Op dit moment gebruik ik voor IPv4 een door mezelf behoorlijk aangepaste versie van KISS My Firewall, en zoek dus iets gelijkend voor IPv6. Niets meer dan een rits makkelijk aanpasbare ip6tables regels in een bash-scriptje dus, waarin wel de basis zaken zijn opgenomen (alles blokkeren, behalve bepaalde poorten/protocollen, beveiliging tegen ICMPv6-issues, etc).

Maar ik zal Shorewall zijn broncode eens doorpluizen, kijken of ik er best-practices uit kan halen voor het script dat ik tot dusver staan heb.

quote:

Snow_King schreef op woensdag 15 december 2010 @ 21:23:
[...]


Niet helemaal zeg maar
code:

PING test6.vlist.eu(cl-938.ede-01.nl.sixxs.net) 56 data bytes
From gw-627.ede-01.nl.sixxs.net icmp_seq=1 Destination unreachable: No route
From gw-627.ede-01.nl.sixxs.net icmp_seq=2 Destination unreachable: No route
From gw-627.ede-01.nl.sixxs.net icmp_seq=3 Destination unreachable: No route
From gw-627.ede-01.nl.sixxs.net icmp_seq=4 Destination unreachable: No route

Terwijl mijn andere IPv6 hier wel prima werkt.

Werkt prima hoor, tenminste, vanaf mijn native verbinding:
code:

# ping6 test6.vlist.eu -c 5
PING test6.vlist.eu(cl-938.ede-01.nl.sixxs.net) 56 data bytes
64 bytes from cl-938.ede-01.nl.sixxs.net: icmp_seq=0 ttl=118 time=41.0 ms
(..)
64 bytes from cl-938.ede-01.nl.sixxs.net: icmp_seq=4 ttl=118 time=40.7 ms

--- test6.vlist.eu ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4000ms
rtt min/avg/max/mdev = 40.428/40.625/41.057/0.351 ms, pipe 2

quote:

AndriesLouw schreef op donderdag 16 december 2010 @ 01:41:
[...]


Werkt prima hoor, tenminste, vanaf mijn native verbinding:
code:

# ping6 test6.vlist.eu -c 5
PING test6.vlist.eu(cl-938.ede-01.nl.sixxs.net) 56 data bytes
64 bytes from cl-938.ede-01.nl.sixxs.net: icmp_seq=0 ttl=118 time=41.0 ms
(..)
64 bytes from cl-938.ede-01.nl.sixxs.net: icmp_seq=4 ttl=118 time=40.7 ms

--- test6.vlist.eu ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4000ms
rtt min/avg/max/mdev = 40.428/40.625/41.057/0.351 ms, pipe 2

Bij mij nog steeds niet. Getest vanuit NXS (AS16237) en PCextreme (AS48635) netwerk, beide locaties krijg ik 'Destination unreachable: No route'

Beide keren komt deze reply vanaf: nlede01.sixxs.net

Ik krijg nu vanuit AS47869 (Netrouting) ook geen antwoord meer. Het lijkt alsof hij de tunnel niet 24/7 up houdt.

quote:

AndriesLouw schreef op donderdag 16 december 2010 @ 01:35:
Op dit moment gebruik ik voor IPv4 een door mezelf behoorlijk aangepaste versie van KISS My Firewall, en zoek dus iets gelijkend voor IPv6. Niets meer dan een rits makkelijk aanpasbare ip6tables regels in een bash-scriptje dus, waarin wel de basis zaken zijn opgenomen (alles blokkeren, behalve bepaalde poorten/protocollen, beveiliging tegen ICMPv6-issues, etc).

Ik heb een tijd geleden Kiss omgebouwd voor gecombineerde IPv4 en IPv6 support. Misschien niet 100% wat je wilde maar toch een goed begin.

Script/install instructies: http://www.webhostingtalk...all-met-ipv6-support.html

quote:

CyBeR schreef op donderdag 16 december 2010 @ 00:26:
[...]


Eh. Gegeven een IP-adres en geen reverse DNS voor dat ip, hoe ga jij achter die naam komen dan? Die mapping is helemaal niet 1:1.

Een IP adres -> een domain (geen vhost), dus hoezo niet 1:1? Zonder reverse DNS is het misschien iets moeilijker.
Maar heb je dit 'issue' zelf verzonnen of is het een bekend issue? Want volgens mij wordt het certificaat gewoon als plaintext door de server verstuurd.

quote:

AndriesLouw schreef op donderdag 16 december 2010 @ 09:30:
Ik krijg nu vanuit AS47869 (Netrouting) ook geen antwoord meer. Het lijkt alsof hij de tunnel niet 24/7 up houdt.

Vreemd. Ik ben inderdaad nog in de testfase en de tunnel zal voorlopig nog niet 24/7 in de lucht zijn. Maar hij is wel continue in de lucht geweest sinds mijn vorige bericht.

Ik heb de TTL voor het AAAA record van test6.vlist.eu op één dag staan. Kan het zijn dat de laatste wijziging (gister, eind van de middag) nog niet overal is doorgedrongen?

Edit: Inmiddels zijn er 24 uur verstreken. Zou iemand het nog eens willen proberen? Ping6en naar test6.vlist.eu?

Roetzen wijzigde dit bericht 16-12-2010 18:12 (8%)

C:\Users\marigo>ping test6.vlist.eu

Pinging test6.vlist.eu [2001:7b8:2ff:3a9::2] with 32 bytes of data:
Destination net unreachable.
Destination net unreachable.
Destination net unreachable.
Destination net unreachable.

Ping statistics for 2001:7b8:2ff:3a9::2:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

quote:

marigo schreef op donderdag 16 december 2010 @ 22:34:
C:\Users\marigo>ping test6.vlist.eu

Pinging test6.vlist.eu [2001:7b8:2ff:3a9::2] with 32 bytes of data:
Destination net unreachable.

Ik begrijp het niet. Of toch? "Destination net unreachable" is iets anders dan "no repsons". Toch? Dus dan zou er iets niet goed staan bij Bit of Sixxs en ligt het niet aan mijn kant.

Ik kan vanaf hier beide einden van de tunnel pingen. Ook uitgaand IPv6 werkt goed zo te zien.

quote:

C:\Dokumente und Einstellungen\Michiel>ping6 test6.vlist.eu

test6.vlist.eu [2001:7b8:2ff:3a9::2] wird angepingt
von 2001:7b8:2ff:3a9::2 mit 32 Bytes Daten:

Antwort von 2001:7b8:2ff:3a9::2: Bytes=32 Zeit<1ms
Antwort von 2001:7b8:2ff:3a9::2: Bytes=32 Zeit<1ms
Antwort von 2001:7b8:2ff:3a9::2: Bytes=32 Zeit<1ms
Antwort von 2001:7b8:2ff:3a9::2: Bytes=32 Zeit<1ms

Ping-Statistik für 2001:7b8:2ff:3a9::2
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ungefähre Zeitangaben in Millisekunden:
Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms

C:\Dokumente und Einstellungen\Michiel>ping6 2001:7b8:2ff:3a9::1

Pinging 2001:7b8:2ff:3a9::1 wird angepingt
von 2001:7b8:2ff:3a9::2 mit 32 Bytes Daten:

Antwort von 2001:7b8:2ff:3a9::1: Bytes=32 Zeit=14ms
Antwort von 2001:7b8:2ff:3a9::1: Bytes=32 Zeit=13ms
Antwort von 2001:7b8:2ff:3a9::1: Bytes=32 Zeit=11ms
Antwort von 2001:7b8:2ff:3a9::1: Bytes=32 Zeit=12ms

Ping-Statistik für 2001:7b8:2ff:3a9::1
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ungefähre Zeitangaben in Millisekunden:
Minimum = 11ms, Maximum = 14ms, Mittelwert = 12ms

Schiet mij maar lek...

misschien heb je icmp in je firewall disabled vanaf het WAN?

quote:

AndriesLouw schreef op donderdag 16 december 2010 @ 01:35:
Bedankt voor de tips richting Shorewall, maar van wat ik er van lees is dat bedoeld voor gateway's en/of losstaande firewall's. Ik ben dus eigenlijk op zoek naar een firewall die direct op een server is in te zetten, waarbij de server op een IP zit dat publiek gerouted wordt, enkel gescheiden van het "grote boze internet" door een enkele managed switch.

Je kan Shorewall ook prima op een losse server gebruiken, al is het misschien een beetje overkill, maar het kan prima. Zie bv: http://www.shorewall.net/standalone.htm

samengevat:
code:

/etc/shorewall/interfaces
#ZONE   INTERFACE       BROADCAST       OPTIONS
net     eth0            detect          tcpflags,nosmurfs,routefilter,logmartians

/etc/shorewall/zones
#ZONE   TYPE    OPTIONS                 IN                      OUT
fw      firewall
net     ipv4

/etc/shorewall/policy
#SOURCE ZONE   DESTINATION ZONE   POLICY   LOG LEVEL   LIMIT:BURST
$FW            net                ACCEPT
net            all                DROP     info
all            all                REJECT   info

/etc/shorewall/rules
#ACTION   SOURCE    DESTINATION     PROTO       DEST PORT(S)
ACCEPT    net       $FW             tcp          80
ACCEPT    net       $FW             tcp          143

CAPSLOCK2000 wijzigde dit bericht 16-12-2010 23:05 (8%)

quote:

marigo schreef op donderdag 16 december 2010 @ 23:02:
misschien heb je icmp in je firewall disabled vanaf het WAN?

Nop. icmp ping staat aan.

Edit: Of misschien toch niet.

Ik heb nog een ander vinkje gevonden. Dat onder iaccu. Dat ook maar aan gezet.

En misschien kan iemand ook het andere eind van de tunnel even proberen... 2001:7b8:2ff:3a9::1

Roetzen wijzigde dit bericht 17-12-2010 01:10 (32%)

$ ping6 test6.vlist.eu
PING test6.vlist.eu(cl-938.ede-01.nl.sixxs.net) 56 data bytes
From nlede01.sixxs.net icmp_seq=1 Destination unreachable: No route
From nlede01.sixxs.net icmp_seq=2 Destination unreachable: No route
From nlede01.sixxs.net icmp_seq=3 Destination unreachable: No route
From nlede01.sixxs.net icmp_seq=4 Destination unreachable: No route
From nlede01.sixxs.net icmp_seq=5 Destination unreachable: No route
^C
--- test6.vlist.eu ping statistics ---
5 packets transmitted, 0 received, +5 errors, 100% packet loss, time 4007ms


$ traceroute6 test6.vlist.eu
traceroute to test6.vlist.eu (2001:7b8:2ff:3a9::2), 30 hops max, 80 byte packets
1 xxxxxx (xxxxx) 0.513 ms 0.493 ms 0.504 ms
2 xxxxx-1.tunnel.tserv11.ams1.ipv6.he.net (xxxxxxxx::1) 30.616 ms 35.772 ms 40.637 ms
3 gige-g2-20.core1.ams1.he.net (2001:470:0:7d::1) 41.369 ms 41.447 ms 43.030 ms
4 amsix-501.xe-0-0-0.jun1.bit-1.network.bit.nl (2001:7f8:1::a501:2859:2) 43.031 ms 43.017 ms 43.165 ms
5 nlede01.sixxs.net (2001:7b8:3:4f:202:b3ff:fe46:bec) 43.827 ms !N 43.898 ms !N 43.512 ms !N

idem hier
code:

sylvesterrr@saturnus:~$ ping6 2001:7b8:2ff:3a9::1
PING 2001:7b8:2ff:3a9::1(2001:7b8:2ff:3a9::1) 56 data bytes
From 2001:7b8:3:4f:202:b3ff:fe46:bec icmp_seq=1 Destination unreachable: No route
From 2001:7b8:3:4f:202:b3ff:fe46:bec icmp_seq=2 Destination unreachable: No route
From 2001:7b8:3:4f:202:b3ff:fe46:bec icmp_seq=3 Destination unreachable: No route
From 2001:7b8:3:4f:202:b3ff:fe46:bec icmp_seq=4 Destination unreachable: No route
^C
--- 2001:7b8:2ff:3a9::1 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 3004ms

sylvesterrr@saturnus:~$ traceroute 2001:7b8:2ff:3a9::1
traceroute to 2001:7b8:2ff:3a9::1 (2001:7b8:2ff:3a9::1), 30 hops max, 80 byte packets
 1  2001:470:1f14:xxxx::1 (2001:470:1f14:xxxx::1)  8.608 ms  12.399 ms  7.892 ms
 2  gige-g2-20.core1.ams1.he.net (2001:470:0:7d::1)  16.130 ms  16.083 ms  16.033 ms
 3  amsix-501.xe-0-0-0.jun1.bit-1.network.bit.nl (2001:7f8:1::a501:2859:2)  12.432 ms  12.366 ms  12.298 ms
 4  nlede01.sixxs.net (2001:7b8:3:4f:202:b3ff:fe46:bec)  12.356 ms !N  12.267 ms !N  12.323 ms !N
sylvesterrr@saturnus:~$

Verder dan nlede01.sixxs.net (2001:7b8:3:4f:202:b3ff:fe46:bec) kom ik niet.

Op mijn xp sp3 PC moet ik eerst de ipv6 gateway pingen voordat ik een host op ipv6 kan pingen.
Geen idee hoe dit komt, vind het niet belangrijk genoeg om uit te zoeken.

Wellicht is dat ook wat hierboven aan de hand is.

Zojuist weer een verse /32 het internet opgeschoten!