feb 052014
 

Om du inte vill att dina hostar ska autokonfigurera sig för IPv6, t.ex. på ett server-nät, är det naturligtvis bäst att stänga av det på hostarna direkt. Men förmodligen vill man stänga stänga av funktionen redan i routern. Normalt stänger man av RA (Router Advertisement). T.ex. på en Cisco ASA konfigurerar man det på interfacet så här:
ipv6 nd suppress-ra

Under IOS kan det se ut så här:
ipv6 nd ra suppress
Detta stoppar routern från att periodiskt skicka ut RA. Men när t.ex. en host startar skickar den ut Router Solicitation och då svarar routern ändå med RA och hosten konfigurerar sig ändå.

Varianten ipv6 nd ra suppress ska stoppa RA helt och hållet, men finns inte i alla versioner av IOS. Det finns diverse tips om att styra detta med ACLer etc.

Ett annat problem, som även gäller om man kan stänga av RA helt och hållet, är att det då stänger av autokonfigurering i ett läge då man har två eller fler IPv6 nät, men bara vill ha autokonfigurering för ett nät och inte för de andra.

Lösningen är att använda sig av no-autoconfig. På ett interface kan man t.ex. konfigurera följande:
ipv6 nd prefix 2001:AAAA:BBBB:CCCC::/64 14400 14400 no-autoconfig
På det viset kan man styra auto-konfigureringen per prefix. no-autoconfig fungerar genom att A-biten inte sätts i RA.

 Posted by at 12:55
jan 102014
 

vid ett par tillfällen har jag varit med om att IPv6 har stannat på ett interface på Cisco-utrustning. T.ex. kan det se ut så här på ett vlan-interface:

Switch#sh ipv6 int vlan 3 
Vlan3 is up, line protocol is up 
  IPv6 is stalled, link-local address is FE80::EE30:91FF:FE4B:5842 [DUP] 
  No Virtual link-local address(es): 
  Global unicast address(es): 
    2001:aaaa:bbbb:1206::1, subnet is 2001:aaaa:bbbb:1206::/64 [TEN] 
  Joined group address(es): 
    FF02::1 
  MTU is 1500 bytes 
  ICMP error messages limited to one every 100 milliseconds 
  ICMP redirects are enabled 
  ICMP unreachables are sent 
  Output features: Check hwidb 
  ND DAD is enabled, number of DAD attempts: 1 
  ND reachable time is 30000 milliseconds (using 22646) 
  Default router is FE80::EE30:91FF:FE4B:1BC1 on Vlan2

Switchen tyckte att det var duplicate på link-local adressen.

Jag löste det så här genom at först sätta en fast link-local address och sedan ta bort den igen:

Switch(config)#int vlan 3 
Switch(config-if)#ipv6 address fe80::1111 link-local 
Switch(config-if)#^Z 
Switch# 
Switch#sh ipv6 int vlan 3 
Vlan3 is up, line protocol is up 
  IPv6 is enabled, link-local address is FE80::1111 
  No Virtual link-local address(es): 
  Global unicast address(es): 
    2001:aaaa:bbbb:1206::1, subnet is 2001:aaaa:bbbb:1206::/64 
  Joined group address(es): 
    FF02::1 
    FF02::2 
    FF02::1:FF00:1 
    FF02::1:FF00:1111 
  MTU is 1500 bytes 
  ICMP error messages limited to one every 100 milliseconds 
  ICMP redirects are enabled 
  ICMP unreachables are sent 
  Output features: Check hwidb 
  ND DAD is enabled, number of DAD attempts: 1 
  ND reachable time is 30000 milliseconds (using 33127) 
  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. 
Switch#sh run int vlan 3 
Building configuration... 

Current configuration : 133 bytes 
! 
interface Vlan3 
 ip address 10.4.6.1 255.255.255.0 
 ipv6 address FE80::1111 link-local 
 ipv6 address 2001:aaaa:bbbb:1206::1/64 
end 

Switch#conf t 
Enter configuration commands, one per line. End with CNTL/Z. 
Switch(config)#int vlan 3 
Switch(config-if)#no ipv6 address fe80::1111 link-local 
Switch(config-if)#^Z

Efter det såg det bättre ut.

Switch#sh run int vlan 3 
Vlan3 is up, line protocol is up 
  IPv6 is enabled, link-local address is FE80::EE30:91FF:FE4B:5842 
  No Virtual link-local address(es): 
  Global unicast address(es): 
    2001:aaaa:bbbb:1206::1, subnet is 2001:aaaa:bbbb:1206::/64 
  Joined group address(es): 
    FF02::1 
    FF02::2 
    FF02::1:FF00:1 
    FF02::1:FF4B:5842 
  MTU is 1500 bytes 
  ICMP error messages limited to one every 100 milliseconds 
  ICMP redirects are enabled 
  ICMP unreachables are sent 
  Output features: Check hwidb 
  ND DAD is enabled, number of DAD attempts: 1 
  ND reachable time is 30000 milliseconds (using 33127) 
  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. 
Switch#

Varför det blev ett sådant här fel kan jag inte säga med bestämdhet, men jag misstänker att någon har råkat koppla ihop två portar på switchen så att den ser sig själv.

 Posted by at 14:53
Dec 132013
 

Vi fick problem med IPv6 på en ny Debian-server där vi körde 3.10 av kärnan. I normalläget funkade IPv6 bra, men det blev problem t.ex. när man kör över en Sixxs-tunnel med låg MTU, 1280. Att köra från datorn som har hand om tunneländan var inget bekymmer, eftersom MSS (maximum segment size) i TCP tar hand om det då den datorn vet om sin egen MTU på tunnelinterfacet. Däremot blev det problem med enheter som satt på nätet bakom tunneln, då de hade MTU på 1500 och därför högre MSS.

Problemet härleddes till att servern med 3.10 kärnan struntade i ICMP Packet Too Big. Som en första åtgärd sänkte jag MTU till 1280 på servern, vilket fungerade som tillfällig lösning. Sedan backade vi kärnan till 3.2 och då fungerade det som det skulle.

I efterhand ser vi att det verkar vara ett känt problem och att det jobbas på det, även om det inte är allmänt känt. Patchar är på väg.

 Posted by at 12:35
jul 272011
 

Jag behövde flera IPv6-adresser på ett interface på en Ubuntu linux. För IPv4 är det vanligt att man skapar subinterface t.ex. eth0:0, men det var ingen bra idé för IPv6.

Att göra så här i /etc/network/interfaces fungerade inte heller:

iface eth0 inet6 static
 address 2001:2040:2000:7::21
 address 2001:2040:2000:7::22
 netmask 64
 gateway 2001:2040:2000:7::1

Felmeddelandet blev:

# /etc/init.d/networking restart
* Reconfiguring network interfaces...
/etc/network/interfaces:20: duplicate option
ifdown: couldn't read interfaces file "/etc/network/interfaces"
/etc/network/interfaces:20: duplicate option
ifup: couldn't read interfaces file "/etc/network/interfaces"

I stället fick det bli så här:

iface eth0 inet6 static
 address 2001:2040:2000:7::21
 netmask 64
 gateway 2001:2040:2000:7::1
 post-up ip -f inet6 addr add 2001:2040:2000:7::22 dev eth0
 pre-down ip -f inet6 addr del 2001:2040:2000:7::22  dev eth0
 Posted by at 15:23
feb 032011
 

Nu har de fem sista  /8-näten delats ut till de olika RIR.

Just nu pågår livesändning från eventet.

http://www.nro.net/news/icann-nro-live-stream

Dock verkar streamingen inte gå att nå via IPv6  🙁

Mer info: http://www.nro.net/news/ipv4-free-pool-depleted

 Posted by at 16:52
feb 022011
 

Då var det dags igen. Den 9 mars medverkar jag på ett seminarium om IPv6 som .SE och PTS håller i.

De beskriver innehållet så här:

Den 9 mars på Clarion Stockholm vid Skanstull kör vi ett heldagsseminarium kring IPv6. E-delegationen berättar om varför det är dags att börja med IPv6 nu. Johannes Endres från Magazin fuer Computertechnik och Anders Tall från HD delar med sig av sina erfarenheter kring IPv6-projekt. Torbjörn Eklöv från Interlan berättar hur du inventerar och kommer igång. Einar Lönn och Jörgen Eriksson från .SE visar live hur du sätter upp en tunnel och startar dns, webb och mail-servrar med IPv6. Phil Robers från Internet Society presenterar World IPv6 day och vilka som ligger bakom detta arrangemang.

Mer info: http://www.ipv6forum.se/punktse/

 Posted by at 13:09
jan 122011
 

Markera den 8 juni i era kalendrar. Det är ”World IPv6 Day”.

http://isoc.org/wp/worldipv6day/

Flera stora aktörer som t.ex. Google, Facebook, Yahoo!, Akamei och Limelight Networks kommer att testköra IPv6 under ett dygn.

Äntligen händer det lite. För oss som har kört IPv6 under ett antal år känns det här som väldigt sent påkommet. Det borde ha gjorts för länge sedan och flera andra organisationer har med framgång gjort det och även gått live.

Ändå ställer jag mig positiv till detta. Det kommer att öka medvetenheten om att det måste hända mer nu. Förhoppningsvis är det ett test som ganska snart kommer att följas av permanent drift. Det skulle vi alla tjäna på. Det är bara att medge att IPv6 inte fungerar perfekt i alla lägen. Det är ganska normalt för en IPv6-site att ha ca 0,2% misslyckade anslutningar. Det är naturligtvis inte trevligt och pekar på brister i hur IPv6 implementerats på Internet. Det positiva är dock att IPv6 blir bättre och bättre för varje dag som går och vi kan bara förvänta oss att IPv4 kommer att få allt mer problem.

Så trots allt ett stort lycka till!

Det tjänar vi alla på.

 Posted by at 22:15