Berichten in deze discussie

Permalink Antwoord van Sander Steffann op 29 April 2010 op 9.30

Als een organisatie met Microsoft DirectAccess gaat werken: zonder IPv6 is je applicatie niet bereikbaar voor mobiele medewerkers.

Permalink Antwoord van Martijn Bellaard op 29 April 2010 op 9.31

Dat is een mooi argument, maar de doorsnee applicatie beheerder zal waarschijnlijk geen idee hebben van DA is.

Permalink Antwoord van Michel Kollenhoven op 29 April 2010 op 9.54

true multicast( streamen aan 1000 gebruikens kost evenveel bandbreete als 1 gebruiker, dit wordt door de routers verdeeld aan degene die lid zijn van het multicast) channel
geen nat meer!!!!!!!!
ingeboude encriptie; dit wordt door het os gedaan en is (bijna, afgezien van instellen) transparant voor de applicatie
jubo paketten; hoogere trugput door gebruik van groote fragmenten
auto mtu discovery
ipv6m; adreswijzigeingen worden op router nivo opgelost, gewijzigd en waar nodig geredirect: gevolg zelfs vpn's blijven up na ipwijziging.
bepaalde landen(cirtation needet) zullen een ipv6 only connectie krijgen,waardoor ze alleen ipv6 webdiensten kunen berijken

b.t.w. de meeste applicaties kunnen zonder wijzigingen ipv6 gebruiken(uitzondringen zijn uiteraard als je app met ipv4 adressen werkt(datalength en invoermaskers zijn enkele aandachts punten)

veel suc6, een applicatie ontwikkelaar

Permalink Antwoord van Martijn Bellaard op 29 April 2010 op 10.41

Beste Michel

Ik denk inderdaad de voordelen van Multicast en IPSec voor een applicatie beheerders als "meerwaarde" gezien kan worden, maar dat is ook weer applicatie afhankelijk.

Martijn

Permalink Antwoord van Marc van Selm op 4 Mei 2010 op 2.19

Geen NAT is een goed punt. Maar hangt af of je een gesloten net bent of niet. Gesloten netten hebben geen adres beperking (of je bent wel heel groot maar ik ken eigenlijk geen org die zo groot is). Mbt de koppeling met Internet hangt het er maar van af of je NAT nodig hebt. Als je een beperkt aantal services ondersteund kan een proxy/gateway voldoende zijn. Maar als je peer-to-peer apps (via Internet) ondersteund moet je wel.

Een goed punt is PMTUD inderdaad. De minimale MTU is 1280 voor IPv6. IPv6 routers fragmenteren niet (alleen hosts). IPv4 routers fragmenteren wel indien nodig (tenzij DF-bit in IP header). Dat betekent dat PMTUD moet werken. Veel firewalls blokkeren ICMP en tunnels (IPv6 over IPv4, GRE, IPsec en andere tunnels) kunnen (hoeft niet) PMTUD dwars zitten.

Dit zijn zaken die het waard zijn om over na te denken voor de migratie.

Permalink Antwoord van Marc van Selm op 4 Mei 2010 op 2.09

IPsec en Mcast zijn niet echt uniek voor IPv6. Die werken prima met IPv4. Wat wel beter is is IP mobility (implementaties zijn schaars) maar de vraag van gebruikers is minimaal. Voorlopig is voor mij het argument dat op een bepaald moment zal er meer investering in IPv6 dan in IPv4 gaan (ISDN versus VoIP is een vergelijking). Op dat moment is het prettig als je klaar bent. Als je nu versie neutraal programmeerd (dus dual stack ready socket calls en zo veel mogenlijk met DNS ipv. IP addressen in configuratie files etc) is IPv6 app ontwikkeling niet echt veel anders.

Dus voor mij zou de reden zijn:
Het komt. Is dat over 3 of 10 jaar dat kan ik je niet vertellen. Op een bepaald moment investeerd de markt meer in IPv6 dan in IPv4. Als je nu er over na denkt en nieuwe ontwikkelingen dual stack maakt en ervaring op doet ben je dan klaar voor en is het voor jouw org. geen probleem. Wacht je echter tot je eigenlijk geen keus meer hebt, heb je dan een probleem.

Wat vinden jullie van deze benadering?

Permalink Antwoord van Sander Steffann op 4 Mei 2010 op 3.46

Ik ben het eens met deze benadering. In 2012 zullen de eerste problemen beginnen. Er zullen zeker organisaties zijn die daarna nog een aantal jaren zonder (grote) problemen verder kunnen met IPv4. De bepalende factor daarbij is volgens mij de manier hoe een organisatie het internet gebruikt. Als ze alleen een 'client' zijn (websites browsen, e-mailen etc) dan zal het erg meevallen. In andere gevallen zal het sneller pijn gaan doen.

Permalink Antwoord van J. van Sommeren op 19 November 2010 op 4.07

Het merendeel van organisaties zijn niet alleen client, maar ook beperkt server. Denk hierbij bijvoorbeeld maar eens aan een direct benaderbare smtp server. Deze zal voor organisaties in het buitenland via Ipv6 of dergelijke bereikbaar zijn. Anders krijg je weer lastige relay constructies via de ISP. De vraag is maar of de ISP hiertoe bereidt is, om een IPv6 mailhost te relayen naar ipv4 host van de klant.

Wij zijn ook onze klanten aan het voorbereiden op migratie naar dualstack ipv6/ipv4. meeste wat we als repliek krijgen, tenminste bij meer technische mensen, is dat NAT64 en DNS64 de techniek gaat worden, om "eenvoudig" organisaties te koppelen aan IPv6 internet.

Iemand enige repliek, waarom niet NAT64 en DNS64. Buiten de standaard zaken, zoals je wil geen NAT, latency, etc.

Permalink Antwoord van Michel Kollenhoven op 6 Mei 2010 op 11.03

Mcast werkt inderdaat prima met ipv4 totdat je bij de eerste internet-router komt....(uitzondering van een paar backbone-routers)

in ipv6 zit mcast in de proto-beschrijving, iedereen is dus verplicht om dit te implemmenteren en mcast werkt dus ook op elke ipv6 host

ik ben het trouwens eens met je stelling, hoe eerder een nieuwe verzie hoe beter(net als bij software ijgelijk;) )

Permalink Antwoord van Marc van Selm op 7 Mei 2010 op 2.12

Ok heeft iemand al eens Mcast getest over z'n provider's IPv6 feed. Dat je Mcast forwarding ondersteund in een router wil nog niet zeggen dat ook Mcast routes uitwisseld met peers. Volledige Mcast routing is meer dan MLD en IGMP.

Any ISPs listening?

Permalink Antwoord van vansijll op 13 Februari 2011 op 20.53

Ik vind je verhaal goed, maar jou redenen zijn bij ons niet doorslaggevend.

Ik gebruik het volgende - want wij hebben honderden buiten lokaties die zijn benaderbaar/ zij benaderen het domein, dmv Routing met VPN-Tunnels (LAN-WAN-LAN), zo wel MS-RDP als Citrix PS4.5 (XenApp Server) en andere hosted virtual applicaties in ASP. Maar ook Camera's.
Dat is dus een probleem, want die honderden lokaties (ge-routeerde VPN-Tunnels) zijn internationaal. Routerende VPN-Tunnels over WAN zullen last krijgen van IPv6 - als het niet goed getest en geïmplementeerd is.

Ik heb al tests gedaan met mij ISP; InterNL.net - zij waren 1 van de eerten in NL met Internet, zijn waren de 'Backbone' van NL-Internet maar hun DNS en ReverseDNS is niet IPv6 Ready.....

Permalink Antwoord van Michel Kollenhoven op 29 Juni 2010 op 3.08

spam

• ‹ Vorige
• 1
• 2
• Volgende ›
• Pagina