CuadernoReddeCátedrasTelefónicaLafarragosatransiciónaIPv6 1

ResponsabilidadCorporativaySostenibilidadCuadernoReddeCátedrasTelefónica

UniversidadCarlosIIIdeMadridLafarragosatransiciónaIPv6

CátedraTelefónicadeInternetdelFuturoparalaProductividadLaInternetseencuentraentiemposdifícilesyaqueseestáquedandosindireccionesytendráquesersolucionadoparapermitirelcontinuocrecimientoenlasegundamitaddeladécada2010yposterior.Laideaeraquelasoluciónaesteproblemapasaríasilenciosamenteensegundoplano,peroenlosúltimosaños,haquedadoclaroqueelcambiodelactualIPv4queseestáquedandosindireccionesalanuevaversiónIPv6resultaráunasuntobastantecomplicado.

IljitschvanBeijnum,LisardoPrieto,MarceloBagnuloDiciembre2010

CuadernoReddeCátedrasTelefónicaLafarragosatransiciónaIPv6 2

BiografíaIljitschvanBeijnumIljitschesinvestigadorenelInstitutoIMDEANetworksyrealizasusestudiosdedoctoradoenlaUniversidadCarlosIIIdeMadrid.Iljitshchaescritodoslibros,unosobreBGPyotrosobreIPv6.

LisardoPrietoLisardoesProfesorAyudantedelDepartamentodeIngenieríaTelematicadelaUniversidadCarlosIIIdeMadriddonderealizasusestudiosdedoctorado.

MarceloBagnuloMarceloesProfesorTitulardelDepartamentodeIngenieríaTelematicadelaUniversidadCarlosIIIdeMadrid.EselDirectordelaCatedraTelefónicadeInternetdelFuturoparalaproductividaddelaUniversidadCarlosIIIdeMadrid.

CuadernoReddeCátedrasTelefónicaLafarragosatransiciónaIPv6 3

Índice1.Resúmen

2.Elproblemaengeneral

3.Lacinturadelrelojdearena

4.IPng:¡necesitamosalgomásgrande,algomejor!

5.Todoestoyahabíapasadoantes

6.Barcosenlanocheylapistadecarreras

7.¿QuieresdecirqueIPv6enrealidadesdiferenteaIPv4?

8.Noestansencilloserunadministradordesistemas

9.Configúraloyolvídate

10.ListasblancasenDNS

11.LosúltimosdíasdeIPv4conNAT

12.NATenIPv6

13.PlanB

14.Referencias

CuadernoReddeCátedrasTelefónicaLafarragosatransiciónaIPv6 4

1.ResúmenEn 1993, 1.3millones [1] de hosts (PCs, estaciones de trabajo, servidores, etc.) estabanconectados a Internet. Este verano, ese número alcanzó 769 millones [2] de hosts,únicamenteteniendoencuenta losequiposquetienenunnombreDNS.LanocióndeunordenadorquenoestáconectadoaInternetespotencialmenteabsurda[3]enestosdías.Porsupuesto,hayproblemascomoelspamolosvirusdetipogusano,sinembargonohanconseguidoralentizarlascosas.Todoesovaacambiarenlospróximosaños.LaInternetseencuentraentiemposdifícilesyaqueseestáquedandosindireccionesytendráquesersolucionadoparapermitirelcontinuocrecimientoenlasegundamitaddeladécada2010y posterior. La idea era que la solución a este problema pasaría silenciosamente ensegundoplano,peroenlosúltimosaños,haquedadoclaroqueelcambiodelactualIPv4(InternetProtocolversión4)queseestáquedandosindireccionesalanuevaversiónIPv6resultaráunasuntobastantecomplicado.

2.ElproblemaengeneralEnlastecnologíasdelainformaciónseempleangrandescantidadesdeesfuerzoydineroparamantenersistemasantiguos“heredados”enejecucióndurantedécadas.Hayavionesquevuelanencírculosquemandovaliosocombustibleporqueelcontrolaéreonopuedeestaraldíayutilizasistemasmenospotentesqueunteléfonointeligente.LasredesWi‐Fino alcanzan sus velocidadesmáximas porque un original 802.11 (sin letra) sistema a 2Mbpspodríaaparecer,nuncasesabe.Losejemplosvaríandesdeenormesycostososhastapequeñosysimplementemolestos.Asíquelosingenierossueñan,soñamosendejartodalatecnologíadeayeratrásyempezardecero.Perocuandollegamosahacereso,unadedos:oelnuevosistemapunteronofuncionatanbiencomoseesperaba,olohaceperolosusuariosnoquieren implementarlo. Joel Spolksy lo explicaen supost “Cosasquenuncadeberíahacer,ParteI”[4].

Incluso si el nuevo sistema es en realidad superior al anterior, los usuarios podríannegarseaactualizarporunagranvariedadderazones.LahistoriadelanuevaCoca‐Cola[5] es ilustrativa a este respecto: a las personas simplemente no les gusta el cambio(pregunteacualquierpersonasialgunavezharediseñadosusitioweb).Einclusocuandoeseproblemasepuedeevitar,avecessimplementenohayformadehacerlo.Porejemplo,

CuadernoReddeCátedrasTelefónicaLafarragosatransiciónaIPv6 5

laespecificaciónoriginaldeEtherneta10Mbpspermitepaquetesde1500bytes.Llenarlos 10Mbps requiere unos 830de esos paquetes de 1500bytes por segundo. Entoncesllegó Fast Ethernet, a 100Mbps, pero el tamaño del paquete sigue siendo elmismo, deforma que se pueda interconectar a una Ethernet de 10 Mbps sin problemas decompatibilidad. Fast Ethernet necesita 8300 paquetes por segundo para llenar el canal.Gigabit Ethernet necesita 83000 y 10 Gigabit Ethernet casi un millón de paquetes porsegundo. Por cada estándar más rápido de Ethernet los proveedores de conmutadoresnecesitanmásparadas para procesar ese número cada vezmás indignante de paquetesporsegundo,ejecutando lasCAMsquealmacenan las tablasdereenvíoavelocidadesdelocura y consumiendo enormes cantidades de energía. La necesidad de conectar lastarjetasantiguasNE2000significaatarsea1500bytesparaFastEthernet,yentonces lanecesidadcomunicarseconesas“rústicas”tarjetasFastEternetimplicanatarsetambiéna1500bytesparaGigabitEthernet,yasísucesivamente,adnauseumadinfinitum.Encadapuntoelsiguientepasotienesentido,perotodoelviajedecididamentemenos.

3.LacinturadelrelojdearenaPero espere un minuto… ¿Las tecnologías de Internet no se encuentran en un cambioconstante? Pasamos de una Ethernet a 10Mbps hasta una de 10 Gbps, de alámbrico ainalámbrico,deunaWebqueapenaseracapazdemostrar textoparpadeanteaunaconcapacidadde ejecutar todo tipo de aplicaciones. Incluso creamos elDNS y el control decongestiónenTCPsóloafinalesdelos80.Larazónporlaquefueroncapacesdecambiartodasestastecnologías,sedebeaqueseproduzcanporencimaopordebajodelProtocolodeInternetenlacapadered.Losprotocolosderedseconstruyencomo“pilas”dondeunnúmerodecapasproporcionanunapartedelafuncionalidadrequerida.ElfamosomodelodereferenciaOSItienesietecapas,perolapilaTCP/IPsólotienecuatro.Elniveldeenlace(dedatos)sabecómoenviarlospaquetesatravésdecablesodelaire.Lacapaderedsabecómoencaminarydireccionar,permitiendoa lospaquetesencontrarsucaminoatravésdelared.Lacapadetransporteconsiguequelascomunicacionesmulti‐paquetefuncionenyfinalmentelacapadeaplicaciónhacequelasaplicacionesfuncionenenred.Esascapassecorrespondencon losnivelesOSI2,3,4y7respectivamente.Cadaunadeesascapastienemuchosprotocolosdiferentesparaelegir,conexcepcióndelacapadered,quesólotieneIP.Estoesloqueasemejaelmodeloalacinturadeunrelojdearena.

Ethernetoperaen lacapadeenlacededatos(y tambiénen lacapa1delmodeloOSI, lacapafísica)ysoportaredescomplejasensímisma,sinembargolasredesEthernetestánlimitadasentamañoyalcance,ypuedenseractualizadasconrelativafacilidad.CadareddeenlacededatosesúnicamenteunsaltoenencaminamientoIP,porloquesólolosdos

CuadernoReddeCátedrasTelefónicaLafarragosatransiciónaIPv6 6

routers frontera tienen la necesidad de ser compatibles con la tecnología de enlace dedatosencuestión;todalainformacióndelenlacededatoseseliminadaencadasaltoIP.Lacapadetransporte,consusmiembrosprincipalmenteconocidosTCPyUDP,tienealgunosproblemas de capacidad de actualización en símismo, pero en principio los routers nomiranmásalládelacapadered,porloquenoimportasiunpaqueteesTCP,UDPoalgúnotro *P. Así pues, cambiar a un nuevo protocolo de transporte implica únicamente laactualización de los sistemas terminales que envían y reciben los paquetes, los routersintermediosnoimportan(losFirewallslohacen,portantohaymáscomplicacionesenlapráctica). Lo mismo ocurre para protocolos de aplicación como HTTP (web), FTP(transferenciadearchivos)oSMTP(correo).SisunavegadordecideiniciarladescargadepáginaswebatravésdeFTP,estoes,entreelnavegadoryelservidorremoto,elrestodelared no importa. Pero IP está en todas partes. El origen del paquete necesita crear unpaqueteIPválido,paquetequeseránecesarioprocesarportodoslosroutersdelcaminoafin de enviarlo por la ruta correcta, y el destino debe ser capaz de decodificar dichopaquete IP.Asíque cambiar elProtocolode Internet significa cambiar todos loshosts yrouters.

4.IPng:¡necesitamosalgomásgrande,algomejor!Al principio de los años 90, se hizo evidente que las direcciones de 32‐bit en el actualProtocolo de Internet (IPv4) eran demasiado pequeñas para permitir el crecimientocontinuodeInternetmásalládelosprimerosañosdelsiglo21.4,3billonesdedireccionesposibles(con3,7billonesrealmenteútiles),nodanparamuchoenunmundocon6,7oincluso10billonesdepersonas.Asíque la IETFdecidióadoptarelprotocoloOSI/ITU‐TparareemplazarIP,esdecir,CLNP(ConnectionlessNetworkProtocol)[6].Elprotocolodered no orientado a conexión es básicamente IP desde un universo paralelo donde todotiene un nombre distinto, tal como NSAP (Network Service Access Point) o punto deacceso de servicio de red para el término “dirección”. Los NSAPs tienen una longitudvariableconunmáximode160bits, locualseríaunabuenamejorasobre lasexistentesdireccionesIPde32‐bits.

PerolaIETF,sufriendoungravecasodelsíndrome“no‐inventado‐aquí”[7],noloaceptó.Asíquealrededorde1995,elesfuerzoporunIPdepróximageneracióndio lugaraunanuevaversióndelprotocolo IPparaarreglarelproblemade la limitaciónde longitudenlasdirecciones.ElIETFaprovechóestaoportunidadparaarreglaralgunaslimitacionesdel

CuadernoReddeCátedrasTelefónicaLafarragosatransiciónaIPv6 7

existente IPv4 pero con moderación: las quejas sobre el nuevo protocolo IPv6 estánequilibradas entre “han cambiado demasiado” y “no han arreglado lo suficiente”. Comoresultado,laformaenlaqueIPv6(nopreguntenquépasóconlaversión5[8])interactúaconEthernetoconotrascapasmásbajasesbastantediferenteacomolohaceIPv4,DHCPha sido revisado de forma significativa, y existe una autoconfiguración sin estado paraconfigurar lasnuevasdireccionesde128‐bits. Pero apartede eso, IPv6es todavía IP, loqueharíasencilloelprocesodetransicióndeIPv4aIPv6.

5.TodoestoyahabíapasadoantesCuriosamente,laInternetyavivióunatransicióndeunprotocoloaotro.Enladécadade1970, ARPANET utilizaba NCP (Network Control Program). NCP estaba lleno depintorescasnociones talescomo lahabilidaddecontactarconun IMPremoto(router)yaveriguar cuando unmensaje anterior había sido recibido en el otro extremo o no. Unpococomocuandoseenvíaunacartaaunamigoyselepreguntaalserviciodemensajeríasiunacartaenviadaanteriormentellegóono.Estasyotrascomplejidadeserandifícilesdemanejarenredeslentas,ymásaúnenlasredesrápidas,por loqueunnuevoybrillanteprotocolofuedesarrolladoalrededorde1980:IP/TCP(hoyendíadecimosTCP/IP.ObienIPv4,osólo IP,asumiendo laparteTCP implícita).LaRFC801[9]explicacómohacer latransición de NCP a TCP/IP. Básicamente, los dos protocolos podrían coexistir durante1982, y el 1 de enero de 1983, NCP se extinguiría y sólo quedaría TCP/IP. Así pues,necesitabanunañoparalatransicióndeunaredconcercadeuncentenardenodosytresaplicacionesprincipales(telnet,FTPycorreoelectrónico).Porlotantodifícilmentepuedeserunasorpresaquehaciendolomismo(latransicióndel“pronto‐a‐ser‐obsoleto”IPv4alnuevoIPv6)menosdedosdécadasdespuésparaunaredconcientosdemillonesdenodosycientossinomilesdetiposdeaplicaciones,podríallevarunlargotiempo.LaúnicagraciasalvadoraesqueelIETFcomenzóconelesfuerzodesuIPdepróximageneración(IPng),que finalmente produjo IPv6, muy temprano, dándonos cerca de 20 años entre elmomentoenelqueIPv6fueestandarizado(1995)yelmomentoenelquelasdireccionesIPv4seagoten(probablementeenel2012).Lasmalasnoticiassonqueesos20añoscasihanconcluido.

CuadernoReddeCátedrasTelefónicaLafarragosatransiciónaIPv6 8

6.BarcosenlanocheylapistadecarrerasAunqueparalosusuariosylasaplicaciones,IPv4eIPv6seanmuyparecidas,“enelcable”,los protocolos son completamente distintos y no interactúan. En encaminamiento,llamamosestounenfoquede“barcosenlanoche”.Laventajadeestediseñoesquenohaynecesidad de cambiar la infraestructura existente IPv4 (IPv6 es añadido simplementecomounnuevoprotocolo).Todas las limitacionesy fallosquesonpartede IPv4quedanatrás. El problema con este enfoque es que la primera persona que quiere desconectarIPv4 tiene que esperar a la última persona que añada IPv6. Es como tener una red detelefoníamóvil que no estuviera conectada a la telefonía fija. Todo elmundo tiene quetener ambos tipos de teléfono, con la expectativa de que en un futuro lejano, podamosdesconectar las líneas fijas y usar únicamente teléfonos móviles. Y con los teléfonosmóviles existe una ventaja real para el cambio: no hay cable (aunque las líneas fijastambiénpresentanalgunasventajas).ConIPv6noexistenventajasrealesparahacerquemuchos de los usuarios decidan cambiar ya que muchos usuarios no tienden a serimpresionadosporlaeleganciatecnológicaylaargumentaciónfutura.

EstohacequelatransicióndeIPv6seacomolaestrategiatrackstand[10]enciclismoenpista,dondeloscompetidorestratandehacerquesusoponentestomenlainiciativa.Unavezqueeloponenteestáencabeza,el“ganador”deltrackstandpuedetomarventajadelrebufo y mantenerse con un esfuerzo menor. Tras una década haciendo trackstand, lamigración hacia IPv6 está finalmente poniéndose en marcha, pero por desgraciademasiadotardeparaevitar losproblemasquevengancuandoseagoten lasdireccionesIPv4.Perovamosavolveraeso.Enprimerlugar,vamosaecharunvistazoaalgunasdelasdiferenciasentreIPv4eIPv6queseinterponenenelprocesodeunatransiciónfácil.

7.¿QuieresdecirqueIPv6enrealidadesdiferenteaIPv4?CuandoIPv6sedesarrollóhacia lamitaddeladécadade1990, lascosasquedamosporsentadohoyendíanoexistíanonoseutilizabantanampliamente.Porejemplo,hoyendíacasitodoslossistemasquenosonroutersoservidoresdedicadosobtienensudirecciónIPyotromontónde informacióna travésdeDHCP(DynamicHostConfigurationProtocol).

CuadernoReddeCátedrasTelefónicaLafarragosatransiciónaIPv6 9

DHCPesmuycomplejoypropensoaerroresencomparaciónacómootrosprotocolosdeladécadade1980, talescomoIPXyAppleTalk,resolvíanestosproblemas.ConDHCP,elclienteenvíaunapetición.Consuerte,unoomásservidoresveránlapeticióndedireccióny enviaránunofrecimientodedirección IP. El cliente entonces evalúa las ofertas y elijeuna. El servidor elegido debe ahora recordar no dar lamisma dirección a otro sistemahastaquepaseeltiempodeconcesión,yelclientedeberecordarrenovarlaconcesióndeladirecciónconelservidorantesdequeseagoteeltiempo.ConIPXestoresultabamuchomás sencillo, sin dependencia de información almacenada en el servidor o detemporizadores:losrouterspropaganuna“direccióndered”ycadasistemacreasupropiadirecciónindividualcombinandoladirecciónredanunciadayladirecciónMACgrabadaensuchipEthernet.AppleTalkesbastanteparecido,perolasdireccionessonmáscortas,asíqueAppleTalkutilizaunnúmeroaleatorioenvezdeunadirecciónMAC.Igualmenteenvíaunospocospaquetesparadeterminarsialgúnotrosistemayahaelegidoladirección.Muysencillo.

AsíquecuandosecreóIPv6,el IETFmiróprotocoloscomoIPXyAppleTalkydesarrollouna configuración automática sin estado, la cual es básicamente un enfoque IPX.Posteriormente,motivosdeprivacidadhicieronquesedescartaralaopcióndeadjuntarladirecciónMACdeunamáquinaensudirecciónIPv6,asíqueseañadióunaopciónsimilaraladeAppleTalk: seguirutilizando ladirecciónMAC,sustituirlaporunnúmeroaleatorio,aclarar y repetir cada 24 horas paramantener el gobierno y otros espías en estado dealerta. ¿Pero por qué limitarnos a dosmecanismos para configurar las direcciones IPv6(tressicontamoslaconfiguraciónmanual)?AsíserediseñóDHCPcomoDHCPv6.Apesarde que ambosDHCPs comparten losmismos conceptos y arquitectura, sus formatos demensaje y varios detalles operacionales son completamente diferentes: DHCP está taníntimamente entrelazada con IPv4 que simplemente hacer los campos de direcciónsuficientemente largos como para soportar IPv6 fue casi imposible. Todos los sistemasIPv6 soportan autoconfiguración sin estado.WindowsVista y 7 soportanDHCPv6, peroWindowsXPyMacOSXnolohacen.Enlossistemasoperativosdecódigolibre,unclienteDHCPv6puedeserinstaladosinovienepordefectoconladistribución.Vistay7tambiénutilizan la dirección temporal generada por un número aleatorio por defecto. Otrossistemasoperativosnolohacen.

CuadernoReddeCátedrasTelefónicaLafarragosatransiciónaIPv6 10

8.NoestansencilloserunadministradordesistemasLlegado tan lejos en lahistoria,muchos administradoresde sistemas comienzan a estarmuyincómodossobrelatransiciónaIPv6:nopuedenconfigurarungranservidorDHCPv6que monitorice todas las asignaciones de direcciones y terminar. En las redes quenecesitandarsoporteacosasdistintasqueunWindowsVista/7,esinviablecambiaraunaautoconfiguraciónsinestado,porqueentoncesalgunossistemassimplementenopodríanobtenerunadirección IPv6conDHCPv6.Sinembargo, inclusosi lascorreccionesquesehan desarrollado se llevaran a cabo, algunos administradores de sistemas sostienen lanecesidad de coordinar la información en DHCPv6 y esto resulta demasiado onerosohacerloenlosanunciosdelosrouters,pueslagentederoutingylagentedeservidoresnodeberíannecesitarhablarseentresí.

Hacediezaños,estadiferenciaentreIPv4eIPv6podríahaberserecibidoconunaactitudde se‐puede‐hacer o quizá resignación, pero las peculiaridades de IPv4 están tanarraigadasy los recuerdosdeunmundomulti‐protocoloqueexistiódurante lasúltimasdécadasdelsigloanteriorsedesvanecieronantelafaltadeparecidoentreIPv4eIPv6,loquepodríaserhoyendíaunverdaderoobstáculo.

9.ConfigúraloyolvídateUn problema mucho más fundamental en la migración a IPv6 es el problema de“configuraryolvidarse”.SiunaorganizacióndecideadoptarIPv6,esposiblequetengaqueactualizarhardwareysoftware,elISPdebeproporcionarconectividadIPv6ydireccionesIPv6,yentonceselnuevoprotocolodebehabilitarseenroutersyenDNS[11].Hastaaquítodobien.Acontinuación,algunospingsytraceroutesIPv6sellevanacabo,ycuandotodofunciona como debería todos vuelven a sus negocios como siempre. Debido a que haydemasiadosparticipantesinvolucradoseneltemalasredes,devezencuandoserompencosas.Estopuede serel resultadodeun fallohardware, cables rotos, actualizacionesdesoftware, reconfiguraciones… lo que sea. A menudo, los ISPs y los departamentos detecnologíasdelainformaciónsonmuyproactivosalahoradearreglaresosproblemas,ysi no lo son, los usuarios siempre son de ayuda para darse cuenta de lo costoso einaceptable que resulta el corte. Por eso los problemas suelen ser solucionados conrelativa rapidez. Para IPv4. Si algo falla en IPv6, nueve de cada diez veces nadie se da

CuadernoReddeCátedrasTelefónicaLafarragosatransiciónaIPv6 11

cuenta:lamayorpartedelacomunicaciónessobreIPv4.YsiunasesiónesiniciadasobreIPv6perofalla,normalmentesepasaautomáticamenteaIPv4.Estopodríapasartrasunretardosignificativo,oenunafraccióndesegundo.Silosusuariossequejan,noesinsólitoquelascuestionesrelacionadasconIPv6tienenunaprioridadmuybaja.Porejemplo,MacOSX10.6SnowLeopardtieneunerrorgraveensucódigodeDNSquehaceignorarIPv6enelDNScuandoexisteunrecursodetipoCNAMEinvolucrado(locualnoesinfrecuente).Unañoycuatroactualizacionesmásadelante,elerrorsigueahí.

Una variante de este problema es cuando una nueva tecnología se implementa ensoftware,peronosehadesplegadotodavía.Entonces,cuandoseutiliza lanuevamejora,las cosasno funcionan tanbien, amenudodebidoaque lasprimeras implementacionesson problemáticas. Un ejemplo distinto a IPv6 es el pipelining en HTTP. Cuando sunavegador ledice “cargando93de126” al ir aun sitioweb, el protocolooriginalHTTPrequiereunanueva sesiónTCPpor cadaunadeesas126 transferencias.Esto introduceunagransobrecarga.AsíqueenHTTP1.1esposiblemantenerunasesiónTCPabierta,yvolver a utilizarla para posteriores peticionesHTTP. Esto se conoce comopipelining. Elpipelining se implementó de forma incorrecta en el servidor de Microsoft IIS 4, con elresultado de que cuando los navegadores empleaban esta característica, ocurrían cosasmalas.Durantemuchosaños, losnavegadoreshantenidodeshabilitadoelpipeliningpordefecto.

AlgosimilarpasóconBitTorrenteIPv6.LaoperaciónbásicadeBitTorrentesconectarseaun“tracker”ydecirlequéarchivosepretendedescargaryquépuertospuedenemplearlosdemásparaconectarseati.EntonceseltrackerdevuelveladirecciónIPylosnúmerosdepuerto de otros hosts que también están activos y descargando el mismo archivo. LosclientesdeBitTorrentseconectanalasdirecciones/puertosdesus“peers”,loscualeslesson asignados por el tracker. Llegados a este punto, los peers intercambian partes delarchivo en cuestión directamente entre ellos. La especificación original del protocoloBitTorrent permitía el usode direcciones IPv4 o IPv6 al igual quenombres de dominiocomoreferenciasdesdeeltrackeralosclientes/peers.PerolamayoríadelagentenotieneunnombrededominiofijoencasaynohubosuficientestrackersconcapacidadIPv6enlos primeros días de BitTorrent, sólo direcciones IPv4 fueron utilizadas, y tras un buentiempo, el protocolo BitTorrent fue modificado con capacidad de intercambiar lasdirecciones IPv4 en formato binario entre peers, quitando unmontón de sobrecarga alproceso. Por supuesto rompiendo la compatibilidad con IPv6. Entonces, el tracker deBitTorrent más grande (bueno, sin duda el más visible), dirigido por The Pirate Bay,obtuvo una dirección IPv6. Para evitar problemas con los protocolos BitTorrentactualizados, ThePirateBaydecidió tener clientesBitTorrent conectados al tracker porduplicado:sobreIPv4pararecibirladireccióndelospeersIPv4,ysobreIPv6pararecibirlasdireccionesdelospeersIPv6.Esofuncionabiensielclientelosoporta,peronotanto

CuadernoReddeCátedrasTelefónicaLafarragosatransiciónaIPv6 12

para los clientes existentes con capacidad silenciosa IPv6 (lo cual fue común, ya quemuchos de ellos se escribieron en lenguajes de alto nivel en los que no importan lasdiferenciasentreIPv4eIPv6).EstosclientessóloveríanlospeersIPv6,siacaso.

10.ListasblancasenDNSYcomoejemplodelproblema“nosepuedellegardesdeaquí”eselocurridoconloshostsquecreentenerIPv6,peroenrealidadnofunciona(hacealgunosañosGoogledeterminóqueesoshosts sonmásdel25por cientode loshostsque tienen IPv6).Apesardequesabemos cómo ejecutar IPv4 y sabemos cómo ejecutar IPv6, nos encontramos en unmundo donde ambos protocolos coexisten lado a lado, e interactúan de formasinesperadas.HostsquecreentenerconectividadIPv6intentaránconectarseaservidorescondirecciónIPv6enlosDNSsobreIPv6.Perosi laconectividadIPv6nofunciona,nadaocurreduranteuntiempohastaquelavenceuntemporizadorenlaaplicaciónyreintentaconotradirecciónproporcionadaporelDNS.SiestoesunadirecciónIPv4,laconexióniráadelante y todo funcionará, pero tras una molesta espera. Estos retardos o esperas lecuestanaentidadescomoGoogleunmontóndedinero,asíqueGoogleoptóporrenunciaraponerlasdireccionesIPv6desusservidoresenelDNS.EstasdireccionesIPv6sóloestánexpuestasalosservidoresDNSdelosISPsqueparticipanenelprogramadeGooglesobreIPv6.Por lo tanto sabemosadóndequeremos llegar: una red totalmentehabilitada conIPv6.Peroparalograrlohayquesufrirtiemposdeespera,loscualesgeneranllamadasalsoporte técnico y la pérdida de ingresos, o el uso de capas adicionales de esfuerzo ycomplejidad.

11.LosúltimosdíasdeIPv4conNATMientras tanto, el99porcientode Internetutiliza solamente IPv4.SimplementenohaymaneradequetodofuncioneconIPv6antesdequenosquedemossindireccionesIPv4endos o quizá tres años. Así pues, necesitamos dar a IPv4 algún tipo de soporte vital. Enrealidad,paraaquellosdenosotrosquetenemosdireccionesIPv4hoyendía,realmentenohaymucho problema a corto plazo. Sólo es que no habrámás direcciones para nuevosusuariosdentrodeunosaños.Pero,obviamente,sóloatenderalosusuariosexistentes,sinningunaoportunidaddecrecimientonovaafuncionarenWallStreet.Lasolución:hacerquelosusuarioscompartanunamismadirecciónIPv4.Lagenteyahaceestoensuscasas

CuadernoReddeCátedrasTelefónicaLafarragosatransiciónaIPv6 13

utilizandoNAT(NetworkAddressTranslation).Estohacequeseaposiblequeunedificioentero de viviendas salga a Internet con una única dirección IP. Pero ese nivel defrugalidad no será suficiente: pronto, los ISPs se ocuparán de hacer NAT de forma quemuchosclientescompartanunaúnicadirecciónIPv4.

Arquitectónicamente,NATesunacosamala.Rompetodotipodesupuestosrelacionadosconlosprotocolos,pudiendointerponerseenlaformaenlaquelasaplicacioneshacensutrabajo.Estoesespecialmenteciertoparalasaplicacionespeer‐to‐peercomoBitTorrent,pero también para VoIP (incluyendo Skype). Sin embargo, a lo largo de los años loscreadoresdeaplicacioneshandescubiertounaformadeconvivirconlosNATs.UnaformadehacerestoeshablarconelrouterlocalqueestéempleandoNATypedirlequeredirijalasconexionesentrantesutilizandounprotocolodemapeodepuertos.EstofuncionabiencuandoseutilizaNATencasa,peronodemasiadobiencuandoelISPutilizaungranNAT.No sólo diferentes tipos de usuario compiten por losmejores números de puerto, sinotambiénlosprotocolosdemapeodepuertosutilizadosfrecuentemente(UPnPIGDyNAT‐PMP),loscualesnopuedenhablarconunNATavariossaltosdedistancia.Yhacerquelasaplicaciones peer‐to‐peer funcionen o no es de alta prioridad para los ISPs –los cualestiendenadistribuircontenidosdevídeoy/oadedicarsealnegociodelasllamadasdevoz.Peoraún,elNATproporcionadoporelISPpodríaacabarconelmecanismodetunnelingdeIPv6quepermitealagenteobtenerconectividadIPv6sisuISPnoseloproporciona.Yla implementacióndeesos complejosy costososequiposNATpuedequitar los recursosquedeotraformaseríanutilizadosparallevaracaboundesplieguedeIPv6enlared.

12.NATenIPv6Mientrastanto,hayacaloradasdiscusionesenelinteriordelIETFsobrelaposibilidaddeespecificar el temidoNAT IPv6 después de todo. El argumento en contra es el disgustoarquitectónico–elIETFtambiénaprobóenprincipiolacreacióndeunNATIPv4‐peroelargumentoafavoresqueunNATIPv6conbuencomportamientonoseríatanmalocomounNATIPv4recompiladoparadireccionesde128‐bits.LoquecrealamayorpartedelosproblemasconNATes lacomparticióndedirecciones.ConNATIPv6,podríaserposiblecrearasignacionesdedirecciones1‐a‐1envezdelas1‐a‐muchosutilizadasconNATIPv4,por lo que todavía sería posible ocultar la red interna que utiliza direcciones privadas,pero las aplicaciones peer‐to‐peer –si se permite a través de un cortafuegos‐ podríantrabajarconunpocodelógicaadicional.LafaltadeNATIPv6tambiénescitadacomounobstáculoeneldesplieguedeIPv6,yaqueesotroaspectoquediferenciaIPv4eIPv6.ElNATde IPv6,diferentealNAT IPv4noseríadegranayudaenesteámbito.Entoncesde

CuadernoReddeCátedrasTelefónicaLafarragosatransiciónaIPv6 14

nuevo,laúnicacosaquerealmenteparece,hueleysabecomoauténticoIPv4es…IPv4.Enalgúnmomento,IPv6tienequeserunprotocoloporsímismo.

13.PlanBNohayplanB.ApesardelalargalistadeproblemasconIPv6y/osuimplementación,nohayalternativas.NoshallevadolamejorpartededosdécadasllegarhastaaquíconIPv6–nohaymaneradequelleguemosaimplementarydesplegarunaalternativaantesdequela falta de direcciones IPv4 sea un problema serio. La compartición de direccionesutilizandoNATyalgunaotra formaderedistribucióndedirecciones (remuneradoono)permitiráaIPv4seguiroperandosinmuchosproblemasduranteunpardeañosdespuésdelagotamientodedirecciones.Sinembargo,actualmenteestamosponiendoenusocadaañounas200millonesdedireccionesnuevas.Esoconllevaunasreglasmuypesadassobrequiénpuedeobtener lasdireccionesyeldespliegue intensivodeNATs.Al contrarioquelos Estados Unidos, los países de Europa septentrional y occidental, que no recibierongrandescantidadesdeespaciodedireccionesIPv4cuandohabíamuchasenladécadade1980,todavíausanmásdeunadirecciónIPv4porhabitanteytodavíaestáncreciendounpoco.InclusolosEstadosUnidos–con1.5billonesdedireccionesIPv4–estánutilizandocadavezmásdireccionesIPv4nuevascadaaño.

NoimportacómoserepartaelespaciodedireccionesIPv4,novaasostenerunaredglobalenelfuturodondepaísescomoChinayBrasilestánavanzandorápidamentemientrasquemuchospaísesenelmundodesarrolladonotienennadaparecidoaunrepartoequitativotodavía.Asíque,aunquetodavíaestamostratandodeentender lapregunta, larespuestatendráqueser“IPv6”.AlgunasdelasdeficienciasrealesydetectadasdeIPv6estánsiendoabordadasporel IETFyotros lugares.ApesardequehaymuypocodesplieguedeIPv6hoyendía,yaexisteunproblemaheredado:algunas implementaciones inicialesdeIPv6notienensoporteparaDHCPv6,porejemplo.PerolamayorpartedesistemashabilitadosparaIPv6todavíaestánrecibiendoactualizaciones(semi)automáticasdesoftware,asíquelosproblemasheredadosnodeberíanserinsuperablesenestaocasión.VamosatenerquemovernosatravésdeunperiodoenelqueIPv4vadebuenoapeordebidoalaumentodecapas de NAT, mientras que IPv6 todavía se encuentra en una fase torpe y carente defuncionalidades secundarias o de la sencilla compatibilidad a la que nos hemosacostumbradoconIPv4.YquizáalgunossistemasacabensiendosóloIPv4mientrasotrosseansóloIPv6.Apesardequelatransiciónnovaasertanfácilcomoesperábamos,vamosa terminar con una Internetmás fuerte y estable, con un potencial casi infinito para elcrecimiento después de la transición. Justo mientras nos aseguramos de que hay unaformadellegardesdeaquí.

CuadernoReddeCátedrasTelefónicaLafarragosatransiciónaIPv6 15

14.Referencias[1] http://ftp.isc.org/www/survey/reports/1995/01/report.html

[2] http://ftp.isc.org/www/survey/reports/2010/07/

[3] http://blogs.apress.com/?p=1328

[4] http://www.joelonsoftware.com/articles/fog0000000069.html

[5] http://www.ajc.com/business/25‐years‐since‐coca‐484445.html

[6] http://www.itu.int/rec/T‐REC‐X.233/en/

[7] http://www.joelonsoftware.com/articles/fog0000000007.html

[8] http://www.iana.org/assignments/version‐numbers/version‐numbers.xhtml

[9] http://tools.ietf.org/rfcmarkup?rfc=801

[10] http://www.youtube.com/watch?v=Q0O8ZzFuMkQ

[11] http://www.apress.com/book/downloadfile/2446

[12] http://ars‐technica.com/hardware/news/2007/05/ipv6‐firewall‐mixed‐blessing.ars/2