Het is nog wel bijzonder experimenteel, dus het kan zomaar weer stoppen
met werken, verdwijnen of veranderen, ook kunnen we niet met 100%
zekerheid zeggen dat de inhoud helemaal actueel is. Laat de URL dus niet
meteen op je visitekaartjes drukken en kijk bij twijfel ook even op
www.xs4all.nl want die kan nieuwere informatie bevatten.
Voor de techies, het is niet alleen een IPv6 interface en een AAAA record
wat we hier testen. Het is een ander OS, andere webserver software en deze
machine(s) (vanaf morgen zijn het er 2) staan achter een IPv6 enabled
loadbalancer. De wisselingen in OS/software zijn er oa de reden voor dat
de inhoud niet automatisch gesynced wordt bij updates en waardoor de site
dus iets achter kan lopen op www.xs4all.nl, verder kan het zo zijn dat
bepaalde scripts nog niet helemaal lekker draaien.
Commentaar, opmerkingen en suggesties zijn welkom via deze nieuwsgroep of
mijn mailbox (@ xs4all.nl).
Zoals ik hierboven al schreef, het is een experiment en nog nauwelijks het
alpha stadium ontstegen. Contact zoeken met support of een andere ingang
heeft niet zoveel zin, die kunnen geen ondersteuning bieden.
MarcoH
PS: ook imap.ipv6 zal in de loop van de week achter de loadbalancer
schuiven.
--
who used to be at Demon NL
> Voor de techies, het is niet alleen een IPv6 interface en een AAAA
> record wat we hier testen. Het is een ander OS, andere webserver
> software en deze machine(s) (vanaf morgen zijn het er 2) staan achter
> een IPv6 enabled loadbalancer.
[...]
> PS: ook imap.ipv6 zal in de loop van de week achter de loadbalancer
> schuiven.
Noem dan ook even wat voor loadbalancer jullie gebruiken. :)
Ik ga er tenminste niet vanuit dat jullie ineens alsnog IPv6 enabled
loadbalancers hebben gekocht?
Maarten
Degene die we gekocht hadden was het met ons eens dat IPv6 toch wel
handig was, en heeft ons een beta gegeven van de spulleboel.
Cor
Foundry
> Ik ga er tenminste niet vanuit dat jullie ineens alsnog IPv6 enabled
> loadbalancers hebben gekocht?
Ze zijn nog niet te koop, dat is het punt.
MarcoH
Oh, ben ik wel benieuwd welk OS en welke webserver software dat dan zijn.
;-) Normaal FreeBSD toch?
Ik heb zelf geen ipv6 draaien dus kan ook niet zelf ff kijken hehe.
--
Mvg,
Arlé
Linux, neem ik aan. Zie
http://groups.google.com/group/xs4all.general/msg/307b72399cfa0bcb
> Oh, ben ik wel benieuwd welk OS en welke webserver software dat dan zijn.
> ;-) Normaal FreeBSD toch?
Linux, zie ook Message-ID: <488f9e43$0$49829$e4fe...@news.xs4all.nl>
> Ik heb zelf geen ipv6 draaien dus kan ook niet zelf ff kijken hehe.
Je kan een tunnel aanmaken, maar veel valt er niet aan te zien...de
website is ook gewoon geel.
MarcoH
Je zou verwachten dat je juist voor IPv6 na een OS zou gaan die native
de meest gebruikte referentie implementatie heeft. Maar hoe dan ook
linux zal wel niet ver achterlopen, als ze dat überhaupt al doen.
--
mph
Server Apache/2.2.3
X-Powered-By PHP/5.2.0-8+etch11
Zou genoeg moeten zeggen. ;]
> Ik heb zelf geen ipv6 draaien dus kan ook niet zelf ff kijken hehe.
Je kan altijd via bijv. de v6-v4-gateway van sixxs kijken:
http://www.ipv6.xs4all.nl.ipv4.sixxs.org/
Hans
Ja dat is nou zo jammer... als er nou een motivatie was om ipv6 te
gaan optuigen en te leven met eventuele nadelen, dan ging ik het
misschien wel weer doen. Maar zolang het nog is "met ipv6 kun je
hetzelfde als ipv4" waar begin je dan aan he...
Wees voorbereid op toekomst.
Het wordt ooit echt allemaal IPv6.
Waarom verwacht je dat IPv6 iets meer kan dan IPv4 ?
Uiteindelijk gaat het om wat je applicatie op de TCP dan wel UDP doet.
Die discussie hebben we pas nog gehad hier.
> Waarom verwacht je dat IPv6 iets meer kan dan IPv4 ?
Dat verwacht ik niet, maar daarin ligt juist het probleem.
Als ipv6 iets meer bood (anders dan problemen) dan zou dat een
motivatie zijn om er op over te gaan. Nu is die motivatie er niet.
En dus krijg je weinig mensen zo ver dat ze het gaan gebruiken.
De google site heeft een bewegend logo als dat je over de streep trekt :)
Nou, tegenwoordig doen zelfs mensen als Van Jacobson, ontwikkelaar
van de BSD TCP/IP stack, research op Linux platforms ipv BSD
(zijn research nu is "netchannels")
Diezelfde meneer ( http://en.wikipedia.org/wiki/Van_Jacobson )
zei laatst nog in een talk:
"Based has all the measurements I'm aware of, Linux has the fastest &
most complete stack of any OS."
Dus tsja..
Mike.
> Je zou verwachten dat je juist voor IPv6 na een OS zou gaan die native
> de meest gebruikte referentie implementatie heeft. Maar hoe dan ook
> linux zal wel niet ver achterlopen, als ze dat ?berhaupt al doen.
<cynisch>
Met het huidige gebruik van IPv6 zou ik niet snel spreken van 'meest',
statistiek is niet zo betrouwbaar met kleine aantallen.
</cynisch>
Ik draai bijv zelf meer v6 packets door een OS X machine als door mijn
linux doos.
> Dat verwacht ik niet, maar daarin ligt juist het probleem.
> Als ipv6 iets meer bood (anders dan problemen) dan zou dat een
> motivatie zijn om er op over te gaan. Nu is die motivatie er niet.
> En dus krijg je weinig mensen zo ver dat ze het gaan gebruiken.
Welke problemen zie je ? Het enige waar ik tegenaan loop is een vage bug
in OS X die mijn handmatige config niet pakt, moet met ifconfig aan de
slag. Maar anders dan dat doet alles het en ik heb zelfs een v6 only glue
record aan mijn domeinen hangen en een v6 only MX staan.
Ik heb wel eens een tunnel aangemaakt bij XS4ALL en een dual-stack
setup gemaakt volgens een van de bekende recepten (onder Linux).
Het probleem waar ik tegenaanliep was het eerst proberen van ipv6
bij opzetten van connecties. Sommige sites hadden wel een ipv6
adres maar dit werkte niet, en dan kreeg je dus allerlei random
"langzame sites" of sites die helemaal niet meer werkten.
Sterker nog, vrij hoopvol voor de toekomst :-)
http://www.ipv6.xs4all.nl/~wgm/info.php
--
Groet,
Wietse
Wietse Muizelaar schreef:
>
> Sterker nog, vrij hoopvol voor de toekomst :-)
>
> http://www.ipv6.xs4all.nl/~wgm/info.php
En DAT kan wel een incentive zijn om naar IPv6 te gaan ;)
Maar ben bang dat het zometeen niet meer werkt. Netzoals een tijd
geleden mensen ontdekten hoe je het via een .htaccess bestand kon
activeren :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAki1sUoACgkQJZcrFK+ADqVrFgCgjXN9zNChaJVFilL2VWQH+UZ9
9moAn1QfqDFWz2lHkRtpAgWAmvP26iYp
=xPwy
-----END PGP SIGNATURE-----
Ach; ik ga het toch niet gebruiken. Vond het grappig dat het werkte :-)
(En als dat niet intentional is, is dit de cue om het te disablen,
zeker)
--
Groet,
Wietse
Dat was geen probleem van IPv6 maar van het OS wat je gebruikt, de meeste
moderne stacks kunnen daar beter tegen vandaag de dag.
MarcoH schreef:
> slag. Maar anders dan dat doet alles het en ik heb zelfs een v6 only glue
> record aan mijn domeinen hangen en een v6 only MX staan.
In dit licht, wordt het binnen afzienbare tijd mogelijk om via XS4ALL
bij IPv6-only servers mail af te leveren? Op dit moment werkt het (nog)
niet namelijk.
Tevens viel mij op dat de normale resolvers domeinen met alleen
IPv6-nameservers ook niet zo leuk vonden :)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAki1vHkACgkQJZcrFK+ADqXLlACbBRllRSKJeQyhztXOL6E+gXHL
DowAoI2xT1av0fvm/sp3rDCd0tRPyMIq
=2F6+
-----END PGP SIGNATURE-----
Tja, het OS moet ook eerst de timeout afwachten natuurlijk, ook niet 'zijn'
schuld. Ik zou de schuld eerder leggen bij een prutsende site of netbeheerder
van 't netwerk waar die site in draait ;)
Helaas beweegt http://ipv6.google.com/intl/nl_ALL/images/logo.gif niet echt
bij mij? :(
Osiris schreef:
>
> Helaas beweegt http://ipv6.google.com/intl/nl_ALL/images/logo.gif niet echt
> bij mij? :(
De letters Google golven een keer bij het eerst laden van het plaatje!
- --
Frits Letteboer
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAki1w1IACgkQJZcrFK+ADqXf3ACeKctP2nGSdrry2GGP/eB8YO4E
wc4An0eIDQU1iKtYeuU23o4ck1infPRg
=Vz5n
-----END PGP SIGNATURE-----
Het heeft gewerkt (smtp.ipv6.xs4all.nl) maar door allerlei netwerk
toestanden kunnen we IPv4 en IPv6 op clusters achter een loadbalancer
niet mengen. Het werkt een tijdje en gaat dan op layer2 stuk.
We gaan langzaam voor alle diensten aparte IPv6 clusters optuigen
en in productie zetten.
>Tevens viel mij op dat de normale resolvers domeinen met alleen
>IPv6-nameservers ook niet zo leuk vonden :)
Ah ja, de normale nameservers hebben geen IPv6 connectivity.
Mike.
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Osiris schreef:
>
> >
> > Helaas beweegt http://ipv6.google.com/intl/nl_ALL/images/logo.gif
> > niet echt bij mij? :(
>
> De letters Google golven een keer bij het eerst laden van het plaatje!
Als je de engelse versie instelt golft hij om de 10 seconde.
Rob
>
> Als je de engelse versie instelt golft hij om de 10 seconde.
Je hebt gelijk. Had even langer moeten kijken :)
--
Frits Letteboer
Is het allemaal een beetje in dezelfde categorie. Of linux of FreeBSD
sneller is maakt niet uit, er zijn geen significante verschillen in
performance oogpunt. Overigens is het wel handiger om dit soort dingen
onder een BSD licentie te gooien, dat vergroot de mogelijkheid op een
bredere adoptie en daar gaat het nou net om, onafhankelijk van het OS
waar je het op ontwikkeld.
--
mph
> Ach; ik ga het toch niet gebruiken. Vond het grappig dat het werkte :-)
> (En als dat niet intentional is, is dit de cue om het te disablen,
> zeker)
Was niet geheel de bedoeling
Welke URL dan? Want zowel de bovenstaande als
http://ipv6.google.com/intl/ALL/images/logo.gif hebben maar 1 frame volgens
the GIMP. En kan dus nogal moeilijk golven :P
> Welke URL dan? Want zowel de bovenstaande als
> http://ipv6.google.com/intl/ALL/images/logo.gif hebben maar 1 frame volgens
> the GIMP. En kan dus nogal moeilijk golven :P
Deze:
http://ipv6.google.com/images/ipv6_logo.gif
Maarten
> > Noem dan ook even wat voor loadbalancer jullie gebruiken. :)
> > Ik ga er tenminste niet vanuit dat jullie ineens alsnog IPv6 enabled
> > loadbalancers hebben gekocht?
>
> Degene die we gekocht hadden was het met ons eens dat IPv6 toch wel
> handig was, en heeft ons een beta gegeven van de spulleboel.
Ah, interessant. Dan is het alsnog geen miskoop :)
Maarten
En wat was het? :-)
Mark
PHP op je normale webspace. Is normaal gesproken niet mogelijk ;)
--
Frits Letteboer
Dat is natuurlijk die X waar ze het over hebben...
Zo nu en dan eens een eXtra mogelijkheid erbij dat zou toch moeten
kunnen...
>> PHP op je normale webspace. Is normaal gesproken niet mogelijk ;)
>
> Dat is natuurlijk die X waar ze het over hebben...
>
> Zo nu en dan eens een eXtra mogelijkheid erbij dat zou toch moeten
> kunnen...
Mja, deze 'X' is alweer weg en geeft nu 403 Verboten!
--
Frits Letteboer
En waarom krijg ik die niet als ik gewoon via IPv6 http://ipv6.google.com
bezoek? :X
Taalvoorkeuren in je browser op Nederlands staan? Die animated gif krijg
je alleen bij de Engelse variant.
--
Frits Letteboer
Nou ja, ok, ben even flink aan het klikken geweest, nog geen homepages
trouwens, daar kunnen jullie vast weinig aan veranderen als daar dingen
niet kloppen, maar goed...
De tags op http://www.ipv6.xs4all.nl/opinie/ verwijzen naar
www.xs4all.nl, niet naar www.ipv6.xs4all.nl
Ditto voor de links op http://www.ipv6.xs4all.nl/publiek/
Niet echt serieus, maar goed...
Mark
Mja, ik zal het eens voorleggen aan de webdesigners en ze vragen relatieve
links te gebruiken. Uiteindelijk is het natuurlijk de bedoeling dat
www.xs4all gewoon een AAAA krijgt en lost het probleem zich op.
Ja? Is er al een strategie bedacht voor deze migratie?
In principe onder 1 naam 2 soorten records? of een aparte naam voor
de ipv6 dienst?
Beiden heeft het zo zijn voor en nadelen uiteraard...
Voorlopig houden we het in het ipv6 subdomein, daar zijn meerdere redenen
voor. Het zijn vaak volledig losse machines, met een experimenteel
karakter. Als je dan zowel een AAAA als een A record aan bijv
www.xs4all.nl hangt wordt het een beetje een schizofrene bedoeling waarbij
de IPv6 host down kan zijn en de v4 niet of andersom.
Verder zijn er, hoewel de meeste gefixed zijn, nog steeds broken clients
die geen volledige IPv6 connectivity hebben en timeouts geven of mensen
die een trage v6 tunnel met MTU issues prefereren boven een goedwerkende
native IPv4 link.
Het einddoel is uiteraard volledig dualstack op alle servers en alles ook
gewoon een A en AAAA record.
Ik zal het voorzichtig weer eens proberen dan. Maar een native IPv6
link dat is nog verre toekomst vrees ik, dus pielen met een trage tunnel
is het enige wat er op zit natuurlijk.
Kun je een voorbeeld noemen van zo'n client?
Ciao,
Johan
--
Why do we always come here - I guess we'll never know.
It's like a kind of torture to have to watch the show.
Maar als je op je internet pagina een teller [1] hebt staan, begint die
weer op 1 te tellen ;-)
Ik weet niet of dat bewust is, maar dat viel me toevallig op.
[1] http://cgi-xs4all.xs4all.nl/cgi-bin/usercounter/<username>
Stefan
Ha ja, da's een mooie .. die teller telt per pagina (je kan op
verschillende pagina's verschillende tellers hebben) en
www.xs4all.nl/~username/ is een andere pagina dan
www.ipv6.xs4all.nl/~username/
Mike.
We zijn druk bezig, maar het vergt nog enorm veel werk. Zo moet op
praktisch alle routers in ons netwerk nog nieuwe software. Dat is met de
schaal grootte van xs4all ook geen eenvoudige taak, vooral ook niet omdat
v4 uiteraard wel gewoon moet blijven werken. Testen, nog meer testen,
planning maken, outage aankondigen, midden in de nacht reload in typen. Je
wil dat niet op alle machines tegelijk doen, als er dan opeens toch wat
misgaat heb je 100-duizenden klanten offline.
En dan heb je alleen de techniek, ook bijvoorbeeld alle interne software
moet 'nog even' aangepast om IPv6 adressen te herkennen en te
ondersteunen, het moet gekoppeld aan je account, het ZSC moet het gaan
snappen (bSMTP, DNS instellen) onze abuseafdeing moet bij klachten niet
alleen kunnen vinden dat het jouw IPv6 adres, maar je ook af kunnen
sluiten...is ook niet in een week af.
Dan moet tzt ook al ons trainingsmateriaal en documentatie aangepast worden,
we kunnen het uiteraard wel rollen als 'experiment' maar op termijn moet
dit toch productie worden en moet ook de helpdesk het kunnen ondersteunen.
Alle folders en de website moet nagekeken worden en waar nodig
aangepast...
Oh en ik vergeet het belangrijste, de goedkoopste modems die native IPv6
doen kosten ongeveer 800 euro. Voor die mensen die het er voor over
hebben, hopen we op termijn wel een experiemntele oplossing te bouwen,
exacte details zijn er niet, maar zonder support kunnen we een hoop van
bovenstaande zaken schrappen.
Wat ik niet ga doen is hier en nu een moment noemen, of zelfs maar een
indicatie. Dat leidt alleen maar tot een enorme stroom aan speculatie over
wat 'eind X' of 'medio Y' betekend, of je krijgt postings als 'het is Z
uur, waar blijft het'.
Het is af als het af is en dan hoor je het uiteraard zo snel mogelijk, gok
dat we dan ook wel proefkonijnen zoeken. Dat kan overigens ook al met een
tunnel, de website loopt geen storm en de v6 imap server ziet nog minder
verkeer als de UUCP-over-tcp-over-IPV6 node (wat daadwerkelijk een world
first en waarschijnlijk ook last is).
Er wordt intern in ieder geval hard aan getrokken om het voor elkaar te
krijgen, mensen beginnen steeds bewuster te worden van de omvang van het
probleem en de noodzaak voor een oplossing en het is definitief uit het
'hobby' traject en bloedserieus.
De deadline is in ieder geval bekend, die is ergens eind 2010,
begin 2011:
http://www.potaroo.net/tools/ipv4/index.html
Het is een feature, geen bug. Kan je zien hoe populair IPv6 al is.
Ik wil een dansende X
:-P
Winfried
Ik surf al een hele tijd met ipv6 als preferent. In het begin gebeurde
dit regelmatig, maar de laatste tijd gebeurt het me niet zo heel vaak
meer dat een site vanwege een kapotte ipv6 setup / connectivity eerst
moet time-outen. De laatste keer dat het gebeurde was even contact
opnemen met de webmaster genoeg om het te fixen.
groet,
Winfried
Ik zie het ja... en dan maar hopen dat alle andere partijen er net zo
hard aan werken.
Als we maar de 1e zijn :)
Ik bedoel meer de partijen die ook iets moeten leveren om het resultaat
nuttig te maken.
- modem leveranciers (voor thuisgebruik)
- informatie aanbieders
- voip afhandelaars
etc. Als je alleen maar ipv6 aansluitingen kunt aanbieden maar er ontbreken
nog kritieke schakels om het nuttig te maken, dan heb je er nog weinig aan.
[knip www.ipv6.xs4all.nl/~username is mogelijk]
>>>Maar als je op je internet pagina een teller [1] hebt staan, begint die
>>>weer op 1 te tellen ;-)
>>>Ik weet niet of dat bewust is, maar dat viel me toevallig op.
>>>
>>>[1] http://cgi-xs4all.xs4all.nl/cgi-bin/usercounter/<username>
>>
>> Ha ja, da's een mooie .. die teller telt per pagina (je kan op
>> verschillende pagina's verschillende tellers hebben) en
>> www.xs4all.nl/~username/ is een andere pagina dan
>> www.ipv6.xs4all.nl/~username/
>
> Het is een feature, geen bug. Kan je zien hoe populair IPv6 al is.
Het is dus bewust :-)
Voor mij maakt het ook niet uit, maar misschien dat anderen er wel
problemen mee hebben, vandaar dat ik het maar even gemeld heb.
Stefan
> Sterker nog, vrij hoopvol voor de toekomst :-)
>
> http://www.ipv6.xs4all.nl/~wgm/info.php
Werkende PHP op je user-page? Dat zou een mooie incentive voor IPv6 zijn!!!
de Kameel
Daarnaast wordt het nog interessant hoe de encryptie mogelijkheden van
ipv6 gebruikt gaan worden.
Rob
> IPv6 kan niet veel meer dan IPv4, dat is waar. Maar stel je een wereld
> voor zonder NAT. Als echt ieder device weer rechtstreeks met ieder ander
> device kan praten ziet de wereld er opeens heel anders uit. VoIP gaat er
> dan ook compleet anders uitzien.
Ja nog meer dingen direct bereikbaar die gehacked en misbruikt kunnen
worden...
> Daarnaast wordt het nog interessant hoe de encryptie mogelijkheden van
> ipv6 gebruikt gaan worden.
Uhh, die zijn er niet. Enige eis is dat je IPsec moet hebben in de stack,
staat nergens dat je het ook moet gebruiken.
> Ja nog meer dingen direct bereikbaar die gehacked en misbruikt kunnen
> worden...
>
Hahaha, dat was ook het eerste dat mij te binnen schoot.
Paranoide of ervaren? :-)
--
Bas.
Jaartje of 10/11 voor ISP's doet wonderen :) Maar het is inderdaad 1 van
de issues voor IPv6 op de lastmile. Nat gedraagd zich als een prima
firewall, modempjes met een v6 stack zullen echt een firewall moeten
hebben, anders ben ik bang dat het leed niet te overzien gaat zijn. Nadeel
is dan dat ze meer geheugen en CPU nodig hebben en ik vermoed dat vooral
de GUI nog wel een uitdaging vormt, waardoor die dingen ongetwijfeld weer
duurder worden.
Waarom kost een firewall die alle inkomende connecties blokt behalve een
lijst poorten die je zelf moet opgeven meer geheugen, cpu en gui dan een
NAT functie met mogelijkheid om open poorten te specificeren?
Dat lijkt me toch ongeveer dezelfde functie, kan zelfs simpeler omdat
je niet perse connection tracking hoeft te doen om dit te bereiken.
Dat een firewall nodig is dat staat wel buiten kijf.
Oja als je als provider abonnee iets wilt kunnen met meerdere adressen
en inkomende connecties dan is het ook wel handig als de provider een
DNS editor openstelt voor abonnees (waar de ingestelde hostnaam van de
aansluiting kan dienen als subdomein om enkele namen/adressen onder te
kunnen hangen). telefoon.hostnaam.xs4all.nl ofzo.
Als je geen namen aan je adressen kunt hangen dan heb je er nog steeds
alleen uitgaand wat aan, en dat gaat met NAT ook wel.
Dat zeg ik ook tegen CPE producenten. Voor IPv6 heb je geen NAT nodig
maar een stateful firewall. Maar dat is exact dezelfde code als NAT,
alleen zonder het IP adres + poort vertaling gedeelte.
Mike.
> de issues voor IPv6 op de lastmile. Nat gedraagd zich als een prima
> firewall, modempjes met een v6 stack zullen echt een firewall moeten
> hebben, anders ben ik bang dat het leed niet te overzien gaat zijn. Nadeel
Lijkt mij overigens een perfect moment om bij IPv6 iedereen default
filterniveau 5 te geven, om er maar eens een andere thread bij te halen. :)
--
Jurjen Oskam
Savage's Law of Expediency:
You want it bad, you'll get it bad.
Alleen bestaat er geen NAT voor v6 bij gebrek aan 'private' space...maar
voor de 'consument' zou een reverse genoeg zijn. Dus
*.a.b.c.d.e.f.g.h.8.8.8.0.1.0.0.2.ip6.arpa PTR <hostname>.xs4all.nl
zou moeten volstaan. Maar laten we niet op de zaken vooruit lopen, eerst
maar eens de stack, dan de toeters en bellen.
Ik bedoel uiteraard NAT in combinatie met IPv4. Daarmee kun je je devices
aan internet koppelen zonder dat ze van buitenaf bereikbaar zijn. Wil je
wel bereikbaar zijn dan wil je toch wel weten WAAR, lijkt me.
> voor de 'consument' zou een reverse genoeg zijn. Dus
> *.a.b.c.d.e.f.g.h.8.8.8.0.1.0.0.2.ip6.arpa PTR <hostname>.xs4all.nl
> zou moeten volstaan. Maar laten we niet op de zaken vooruit lopen, eerst
> maar eens de stack, dan de toeters en bellen.
Die reverse dat had ik wel werkend indertijd met de XS4ALL tunnel, maar
daar voor moest je zelf een DNS server draaien. Een forward op die manier
kon niet omdat je geen NS records kunt opnemen. Het zou voor de meesten
handiger zijn om dit gewoon in je service center te kunnen regelen.
Maar goed wieweet komt dat nog wel...
Om te zorgen dat dingen niet bereikbaar zijn, heb je een firewall.
Default alle inkomende verkeer blokkeren is niet moeilijk: dat kan met
elke zinnige firewall wel. Een NAT service is niet bedoeld als
vervanging van een firewall.
>> Daarnaast wordt het nog interessant hoe de encryptie mogelijkheden van
>> ipv6 gebruikt gaan worden.
> Uhh, die zijn er niet. Enige eis is dat je IPsec moet hebben in de
> stack, staat nergens dat je het ook moet gebruiken.
Maar de mogelijkheden zijn er wel degelijk.
IPv6 is ook weer niet zó experimenteel dat het een octadecimaal
getallenstelsel gebruikt.
:D
Hans v. K.
Schrijf mij maar op de lijst van proefkonijnen iig ;) (Zie headers voor IP ->
hostname -> accountgegevens :P)
Met die nieuwe loadbalancers, komt er nu ook een smtps.ipv6.xs4all.nl? Want
tot nu toe gebruik ik gewoon nog smtps.xs4all.nl.
Verder vind ik t nogal wiedes dat de IPv6-site geen storm loopt. Wat heb ik
als klant van XS4ALL daar nou te zoeken. 't Is niet als je favoriete forum of
http://ipv6.google.com ofzo die je dagelijks tientallen malen bezoekt.
PAT en NAT geven schijn veiligheid.
Wil je dat ?
In tegenstelling tot sommige anderen geloof ik niet dat een veiligheids
maatregel die niet 100.000% is dan ook maar meteen weggewuifd moet worden.
NAPT is een prima middel om inkomende connecties tegen te houden. Als
zodanig vervult het een functie. Zeker als er het idee leeft dat alles
in huis een adres moet krijgen.
Natuurlijk, die ook :)
>> Daarnaast wordt het nog interessant hoe de encryptie mogelijkheden van
>> ipv6 gebruikt gaan worden.
>
> Uhh, die zijn er niet. Enige eis is dat je IPsec moet hebben in de stack,
> staat nergens dat je het ook moet gebruiken.
>
Maar dat is ook meteen het verschil met IPv4:je moet IPsec ondersteunen.
Nu is het alleen in gebruik voor VPN's, maar het lijkt logisch dat met
IPv6 al het verkeer ge-encrypt zal zijn.
Het gaat me er om dat IPv6 tot een wereld (nou ja, internet) gaat leiden
die zal gaan verschillende van de huidige. Het is aardig om je voor te
stellen wat er gaat veranderen...
Voorbeeld: peer-2-peer toepassingen en telefonie gaan (versneld) mergen,
of: de invloed van centrale, grote, websites en gekoppelde bedrijven zal
af gaan nemen. Verzin eens wat :)
Rob
> MarcoH
>
Ik wil je verder niet uit je droom halen, maar we zijn al een jaar of 15
bezig en de release van een website levert een draad op van een week, als
we 1(!) sessie killen op ams-ix worden we genoemd in een presentatie in
het europarlement.
Die wereld die je schetst is ver weg...heel ver weg. Denk dat we met zijn
allen vrij blij mogen zijn als we zo tegen 2010 beetje native v6 packets
kunnen schuiven zodat we niet de nma op ons dak krijgen omdat nieuwkomers
in de markt geen v4 meer kunnen krijgen en we opeens een partij met
'aanmerkelijke marktmacht' zijn simpel omdat iemand 15 (dan inmiddels 17)
jaar geleden een redelijk briljant plan had.
Buiten dit alles, voorzie ik in het algemeen en publiek gebruik van IPsec
op alle connecties nog wat issues met trust chains en de wetgever die nu
eenmaal mee wil kijken teneinde uw en ons aller privacy omzeep te helpen
zodat ze de volgende keer als iemand een aanslag wil plegen toch weer net
te laat zijn.
Ik krijg op het moment een 403 bij de root en homedirs, is er iets
stukgegaan?
Het is en blijft een experiment, zoals ook al aangekondigd. Ik begrijp van
de collega die er mee bezig is dat hij bewust even dicht staat om dat er
nog wat problemen waren.
Je krijgt een /48 van xs4all.
Niets let je om daar meerdere /64 van te gebruiken.
Een redelijk stom apparaat als een WRT54G heet al VLAN support aan boord.
Elk VLAN zijn eigen /64 en met ipfilter spijker je de handel op Subnet nivo
dicht.
Ik geloof niet dat de selectieve filters op borders netwerk schaalbaar zijn
en stand gaan houden.
Waar ik wel in geloof is grof filteren op de rand en selectief op de host
zelf.
(Heb het idee dat ik dit al eens eerder gevraagd heb :+)
De IPv6 Tunnelbroker ipspace is 2001:888:1000::/36 volgens een whois. En je
deelt /48's uit. Dus dan heb je ruimte voor 2^(48-36) = 2^12 = 4096 subnets.
Dat lijkt me een klein beetje te weinig voor al jullie klanten? Sure, voor
alleen tunnels ongetwijfeld ruim genoeg, maar voor het klanten-wide uitrollen
van IPv6 met iedereen een /48 heb je op die manier niet genoeg space. Lijkt me
haast dat je daar dan wel een /32 voor nodig hebt?
>> Je krijgt een /48 van xs4all.
>
> (Heb het idee dat ik dit al eens eerder gevraagd heb :+)
Dan heeft iemand je ook vast al eens verteld dat je berekening klopt..
> De IPv6 Tunnelbroker ipspace is 2001:888:1000::/36 volgens een whois. En je
> deelt /48's uit. Dus dan heb je ruimte voor 2^(48-36) = 2^12 = 4096 subnets.
> Dat lijkt me een klein beetje te weinig voor al jullie klanten? Sure, voor
> alleen tunnels ongetwijfeld ruim genoeg, maar voor het klanten-wide uitrollen
> van IPv6 met iedereen een /48 heb je op die manier niet genoeg space. Lijkt me
> haast dat je daar dan wel een /32 voor nodig hebt?
/32 - /48 is 16 bits, oftewel 65536 netwerkjes. Dus nee dat gaat niet
passen...nu kan je die /32 wel groeien als daar noodzaak voor is en hebben
we er uit een overname nog 1 en dan kom je op 2 x /28 en dan kom je al een
heel eind naar wereld dominantie.
Doet niets af aan het feit dat we, met een welliswaar iets grotere pool,
weer terug zijn in een tijd voor 1993 en we lekker wel alles classfull
doen want dan hoef je niet na te denken en die 128 bits zijn niet zomaar
op.
A /32
B /48
C /64
En vooral die laatste is vervelend, want hoewel je strikt genomen voor een
point-to-point maar 2 adressen nog hebt (/127) zijn er talloze stacks en
applicaties die geen masks groter als /64 accepteren.
Is weer net als vroeger, ah u heeft meer dan 1 subnet...dan krijgt u er
meteen maar 256.
Maar goed, als dit faalt zijn we door 1/8 van de space heen..kunnen we
gewoon nog een poging doen :)
(ik zou denken dat een standaardklant die nu genoeg moet hebben aan 1
IP adres voldoende bediend is met 1 /64 subnet en dat mensen die meerdere
subnetten willen dat wel kunnen aangeven, maar kennelijk denkt er ergens
iemand dat iedere mogelijke abonnee meer subnetten moet hebben dan een
flink groot bedrijf nu nodig heeft...)
>Alleen bestaat er geen NAT voor v6 bij gebrek aan 'private' space...maar
>voor de 'consument' zou een reverse genoeg zijn.
Er is best private space in v6. Er is geen NAT in v6 omdat het nergens
voor nodig is, niet bij gebrek aan nonroutable adressen.
En voor de consument is niet alleen een reverse nodig, je moet toch ook
een nette quad-A erbij om er wat aan te hebben, *juist* bij v6.
Jasper
>Wees voorbereid op toekomst.
>Het wordt ooit echt allemaal IPv6.
Met het gebrek aan migratiepad dat er aan ipv6 is gebreid kan dat nog best
even duren.
Sterker nog, ik zou me best kunnen voorstellen dat we toegaan naar een
wereld met routers die NATten tussen een set v6 addressen en een set
interne v4 addressen, maar dan dus niet NAPT maar echte NAT.
Jasper
Het OS kan daar niets aan doen, tenminste niet zonder wel werkende maar
net iets tragere v6 sites de werking door de neus te boren. Als een stack
voor de timeout al overgaat naar v4 is dat eerder een bug dan een feature.
>Tja, het OS moet ook eerst de timeout afwachten natuurlijk, ook niet 'zijn'
>schuld. Ik zou de schuld eerder leggen bij een prutsende site of netbeheerder
>van 't netwerk waar die site in draait ;)
Waar de schuld ligt is verder niet zo relevant, de schuld ligt vanuit de
eindgebruiker gezien simpelweg bij 'ipv6', en dat is ook zo.
Jasper
>IPv6 kan niet veel meer dan IPv4, dat is waar. Maar stel je een wereld
>voor zonder NAT. Als echt ieder device weer rechtstreeks met ieder ander
>device kan praten ziet de wereld er opeens heel anders uit. VoIP gaat er
>dan ook compleet anders uitzien.
Maar niet beter.
Jasper
>De deadline is in ieder geval bekend, die is ergens eind 2010,
>begin 2011:
>
>http://www.potaroo.net/tools/ipv4/index.html
Staat vrij duidelijk dat ie begin 2012 is. En nadat de RIRs geen addressen
meer hebben om uit te geven gaat het ook echt nog wel even duren voordat
het zover doorsijpelt dat het echt problemen gaat geven -- het zou me
helemaal niet verbazen als we nog gaan zien dat de gemiddelde ISP
(hopelijk XS niet) dingen gaat doen met connecties weggooien als ze
inactief zijn en IPs in beslag nemen.
Jasper
Als je wat sneller had gereageerd had er nog 2011 gestaan, als je verder
leest zie je dat het iedere dag opnieuw berekend wordt.
Het is wat prematuur, maar het lijkt erop dat die crisis toch nog ergens
goed voor is.