Resumen

  • JRES atribuye a Jehan Procaccia y Emmanuel Halbwachs la coautoría de la presentación de SIRFEX de 2013, dedicada a una interconexión entre redes regionales de investigación mediante una red privada virtual de capa 3 de RENATER. [1] [2] [3]
  • La arquitectura documentada separaba los dominios de rutas mediante interfaces dedicadas, VRF y MPLS, e incluía intercambio de rutas IPv4 e IPv6. El piloto citó a RAP, REVE y RUBIS y contempló comprobaciones de caudal y de ruta alternativa, sin publicar un resultado general cuantificado. [3]
  • Un informe independiente del equipo MiNET identifica a Procaccia como supervisor y agradece su asistencia, como administrador de red de la DSI, durante un despliegue universitario de IPv6. La implantación pertenece al equipo y no puede presentarse como obra individual de Procaccia. [4]
  • El informe MiNET describe una transición con IPv4 e IPv6 en paralelo, decisiones explícitas de direccionamiento y enrutamiento, control de los anuncios de router y el mantenimiento de ciertos servicios administrativos en IPv4 cuando aún no había una protección equivalente. [4]
  • El análisis de BTW encuentra un mismo principio operativo en ambos registros: la continuidad depende de fronteras de rutas explícitas, tratamiento separado de cada familia de direcciones y alternativas realmente probadas. No es una afirmación de resiliencia garantizada ni de resultados no publicados.

Antes de hablar de tecnología, hay que identificar el trayecto

El punto de partida no es una sigla, sino una pregunta que cualquier responsable de una red puede formular: ¿por dónde viaja en realidad el tráfico que importa? La pertenencia de dos centros a una misma comunidad académica no crea por sí sola una ruta directa entre ellos. Tampoco basta con que ambos tengan acceso a Internet. Los equipos encaminan paquetes conforme a la información de rutas que reciben y a las reglas que determinan qué anuncios se admiten en cada contexto.

Una red de investigación y educación presta conectividad a universidades, laboratorios y otras instituciones relacionadas. Puede sostener colaboración entre sedes, acceso a instrumentos compartidos, cálculo distribuido o movimiento de conjuntos de datos. Nada de esto obliga siempre a utilizar un trayecto privado, y los documentos de SIRFEX no formulan una regla universal. Sí plantean una necesidad concreta: varias redes regionales querían intercambiar determinado tráfico sin enviarlo por los mismos caminos del Internet público ordinario. [1] [2] [3]

En este contexto, tránsito ordinario o comercial de Internet significa el servicio general que permite llegar a una gran diversidad de destinos. No es sinónimo de mala calidad ni de inseguridad. Responde a una finalidad amplia. Una interconexión dedicada responde a otra: delimitar participantes, rutas y responsabilidades de operación para un intercambio específico. El valor no procede de la etiqueta “académica”, sino de que esa delimitación pueda verse en interfaces, tablas de rutas, filtros y pruebas.

La diferencia puede pasar inadvertida desde una oficina. Una persona abre una aplicación y solo percibe si funciona. Sin embargo, dos conexiones aparentemente equivalentes pueden seguir trayectos distintos, aprender rutas de fuentes diferentes y reaccionar de otra manera ante una avería. Por eso la pregunta útil no es únicamente si existe conectividad, sino si el camino observado coincide con el camino previsto.

SIRFEX convirtió esa pregunta en una propuesta técnica sobre infraestructura de RENATER. La documentación habla de una red dedicada, interfaces específicas e intercambio controlado de rutas para IPv4 e IPv6. [3] El interés de ese registro está en hacer comprobable una intención institucional. Decir que las redes regionales deben comunicarse directamente expresa una aspiración; definir dónde se intercambian las rutas establece una condición que los operadores pueden inspeccionar.

La contribución de Procaccia se entiende mejor con verbos precisos

Los perfiles sobre infraestructura suelen deformarse cuando un nombre conocido absorbe el trabajo de todo un equipo. En este caso, las fuentes permiten evitar ese error. JRES nombra a Jehan Procaccia y Emmanuel Halbwachs como autores de la presentación de SIRFEX de 2013. [1] [2] La presentación técnica firmada aporta los detalles de arquitectura y del piloto utilizados aquí. [3] Por tanto, “coautor” es un verbo y una relación respaldados por un registro fechado.

La coautoría conecta a Procaccia con el planteamiento técnico documentado, pero no reparte entre los dos autores cada idea, configuración o prueba. Un servicio de interconexión puede requerir definir la necesidad, acordar políticas, preparar interfaces, coordinar participantes, revisar rutas, ejecutar ensayos y documentar lo observado. Las fuentes no asignan individualmente cada una de esas tareas. Afirmar que Procaccia diseñó o entregó por sí solo todo el servicio iría más allá de lo que muestran.

El informe del equipo MiNET aporta una relación distinta y separada. Identifica a Procaccia como supervisor del proyecto y le agradece, en su condición de administrador de red de la DSI, la ayuda prestada durante un despliegue de IPv6 en un entorno universitario. [4] El documento atribuye el trabajo de implantación al equipo. La aportación individual demostrable es la supervisión y la asistencia reconocidas por ese equipo.

Esta distinción no reduce la importancia de ayudar a que una migración funcione. Al contrario, muestra dónde se sitúa la evidencia. Supervisar puede incluir orientar, revisar o resolver problemas, pero el informe no permite decir quién introdujo cada orden, eligió cada prefijo o verificó cada dispositivo. Mantener los verbos del documento protege tanto el crédito de Procaccia como el del equipo que llevó a cabo el proyecto.

Dos páginas oficiales de Telecom SudParis lo vinculan además con enseñanza práctica de Internet y redes. [5] [6] Es un contexto profesional limitado, no una prueba de resultados operativos. Impartir o participar en formación técnica no demuestra por sí mismo que alguien construyera un sistema concreto. En este artículo, esos registros solo ayudan a situar un ámbito de trabajo; las contribuciones principales siguen apoyándose en la coautoría de SIRFEX y en el reconocimiento independiente de MiNET.

Una L3VPN separa conversaciones de enrutamiento

La presentación de SIRFEX describe una L3VPN de RENATER. [3] El término designa una red privada virtual de capa 3: un entorno de enrutamiento administrado por el proveedor en la capa IP. “Privada” no quiere decir que todos los datos estén cifrados automáticamente ni que desaparezcan los riesgos. Quiere decir que ciertas rutas se mantienen en un contexto lógico definido y no se mezclan sin control con el enrutamiento general.

Imaginemos una sala de intercambio con una lista de participantes y asuntos permitidos. Cada red regional llega por una interfaz dedicada. Puede anunciar los destinos aprobados y aprender los que otras redes están autorizadas a compartir. El operador transporta esa información dentro del servicio. Las rutas generales de Internet permanecen fuera, salvo que una regla concreta disponga otra cosa.

Esa separación produce preguntas observables. ¿Qué interfaz pertenece al servicio? ¿Qué prefijos puede anunciar cada participante? ¿Se habilitan IPv4, IPv6 o ambos? ¿Quién rechaza una ruta inesperada? ¿Qué prueba confirma el trayecto? ¿Qué ocurre si deja de estar disponible? Ninguna respuesta depende de una declaración de pertenencia; depende del estado de la red y de la responsabilidad asignada.

El registro de SIRFEX respalda una arquitectura propuesta y un piloto con participantes nombrados. [1] [3] No acredita que todas las redes regionales francesas se incorporaran, que existiera una disponibilidad determinada ni que circulara un volumen concreto de tráfico. La explicación de la L3VPN debe permanecer en esa escala: un mecanismo para separar y compartir rutas bajo condiciones definidas.

Desde el punto de vista de quien usa un servicio, esta distinción puede parecer invisible hasta que surge una incidencia. Para el operador, en cambio, determina dónde mirar. Si un destino no responde, debe saber si la ruta falta dentro del entorno dedicado, si el tráfico salió por Internet ordinario o si el trayecto de vuelta no coincide. La frontera lógica reduce la ambigüedad solo cuando está bien documentada y se comprueba.

La VRF es el libro de rutas de cada dominio

Una pieza de esa separación es la VRF, sigla de virtual routing and forwarding. En términos sencillos, es una tabla de enrutamiento separada que evita mezclar un dominio de tráfico con otro. La presentación de SIRFEX sitúa las VRF dentro de la arquitectura descrita. [3] Un mismo equipo puede mantener una visión de rutas para el servicio de investigación y otra para el Internet general.

La analogía con un libro mayor resulta útil: cada tabla registra qué destinos conoce un contexto y por qué salida debe alcanzarlos. Que una ruta exista en el equipo no basta; debe estar en la tabla correcta. Una interfaz asociada a otra VRF, una regla de importación demasiado estrecha o una exportación demasiado amplia pueden alterar el resultado sin que el enlace físico se haya caído.

La separación añade obligaciones de operación. Los sistemas de monitorización deben consultar la tabla relevante, no solo la vista global del router. Los cambios de política necesitan un responsable. Los anuncios inesperados requieren una respuesta. Una VRF no convierte automáticamente una política incompleta en una política segura; únicamente ofrece el lugar técnico donde esa política puede hacerse efectiva.

Los documentos de SIRFEX permiten explicar el mecanismo y el intercambio acotado de rutas. [3] No incluyen aquí una configuración integral ni una auditoría de todas las posibles filtraciones. En consecuencia, no cabe afirmar que el uso de VRF eliminara cualquier fallo. La conclusión más sobria es que el diseño creaba una frontera inspeccionable y, con ella, la necesidad de demostrar que las rutas correctas estaban en el lugar correcto.

MPLS transporta el contexto, pero no sustituye la comprobación

MPLS, o conmutación de etiquetas multiprotocolo, es un mecanismo que utiliza etiquetas para guiar el tráfico a través de una red de proveedor. La documentación de SIRFEX combina VRF y MPLS sobre infraestructura de RENATER. [3] De manera simplificada, la decisión tomada en el borde se asocia a información que permite conservar el contexto de la red virtual mientras los paquetes atraviesan el núcleo.

Para un lector no especializado, lo esencial es que la separación no termina en la primera interfaz. Debe mantenerse a lo largo del trayecto. La ruta que aparece en el plano de control —la parte que decide qué caminos existen— necesita una correspondencia en el plano de reenvío —la parte que mueve efectivamente los paquetes—. Una entrada visible no garantiza por sí sola que el tráfico llegue.

Esta diferencia explica por qué las comprobaciones de alcance y caudal mencionadas en el piloto importan como categorías de ensayo. [3] Indican que el registro no se quedó únicamente en un diagrama. Sin embargo, la existencia de una comprobación no autoriza a publicar una velocidad, una capacidad sostenida o un nivel de disponibilidad que la fuente no proporciona. Una prueba demuestra solo lo observado dentro de su fecha, método y alcance.

MPLS tampoco es una palabra mágica de resiliencia. Puede formar parte de una arquitectura robusta, pero el resultado depende de interfaces, rutas, etiquetas, retorno y procedimientos de fallo. El operador necesita observar el recorrido que importa a la aplicación. El nombre de la tecnología ayuda a localizar mecanismos; no reemplaza la evidencia del servicio.

El análisis de BTW extrae de aquí una regla de continuidad: una configuración declarada y un camino en funcionamiento son registros diferentes. Deben coincidir. Cuando se separan, el equipo necesita pruebas que indiquen dónde cambió el estado y quién puede corregirlo.

IPv4 e IPv6 comparten cables, no necesariamente resultados

SIRFEX contempló intercambio de rutas para IPv4 e IPv6. [3] Ambas familias de direcciones pueden viajar por la misma infraestructura física y aun así tener políticas, prefijos y fallos distintos. Un filtro puede aceptar el anuncio IPv4 de una organización y omitir el equivalente IPv6. Una interfaz puede estar activa para las dos familias, pero solo una disponer de ruta de retorno.

“La red funciona” es, por ello, una frase incompleta. Una comprobación debe indicar la familia de direcciones utilizada. Cuando un servicio opera en doble pila —IPv4 e IPv6 de forma simultánea durante una transición—, cada familia necesita su propio enrutamiento, filtrado, resolución de nombres y observación de aplicaciones. El buen estado de una no compensa el fallo silencioso de la otra.

Las direcciones son además recursos que deben manejarse con precisión. Los prefijos necesitan una asignación coherente, registros claros y anuncios que conduzcan al responsable correcto. La amplitud del espacio IPv6 no elimina la obligación de evitar solapamientos, mantener agregaciones razonables y conocer qué parte del espacio puede salir de cada dominio.

Las fuentes de SIRFEX no ofrecen aquí un inventario completo de prefijos de los participantes. [3] Respaldan la afirmación más limitada de que el intercambio incluía IPv4 e IPv6. Esto basta para concluir que una validación exclusivamente IPv4 habría dejado sin probar una parte declarada del diseño, pero no permite atribuir al piloto un resultado cuantitativo sobre adopción o rendimiento de IPv6.

Para una institución usuaria, la consecuencia práctica es clara. Una aplicación puede elegir IPv6 cuando está disponible y parecer lenta o inaccesible si ese camino está incompleto, aunque IPv4 continúe operativo. La monitorización debe seguir la misma selección que hacen los dispositivos y no limitarse a preguntar si existe alguna ruta posible.

El piloto acotó los participantes y las preguntas

La presentación firmada menciona a RAP, REVE y RUBIS en el piloto de SIRFEX. También describe intercambio de rutas, comprobaciones de caudal y pruebas de retorno al Internet ordinario como alternativa. [3] Nombrar esas redes es importante porque impide convertir el piloto en una afirmación sobre adopción general.

Una prueba de intercambio puede empezar por observar si un participante aprende el prefijo que otro está autorizado a anunciar. Después debe comprobarse si los paquetes siguen el entorno dedicado y si la respuesta vuelve por un camino válido. El éxito en un único sentido puede ocultar asimetrías. La presencia de una ruta tampoco demuestra que una aplicación se comporte como se espera.

La comprobación de caudal aporta una observación diferente: cuántos datos se entregan durante un intervalo y bajo un método determinado. La fuente señala que hubo comprobaciones, pero no ofrece base para convertirlas aquí en una cifra general, una promesa de capacidad o una comparación comercial. Presentar una prueba como garantía permanente borraría sus límites.

Lo mismo vale para la tolerancia a fallos. Ensayar un camino alternativo demuestra que el equipo consideró el escenario. No demuestra que cualquier incidencia futura vaya a resolverse sin pérdida o dentro de un tiempo fijo. Harían falta medidas fechadas, topología, condiciones y procedimiento para sostener una conclusión de ese tipo.

La fuerza del piloto reside en otra cosa: une una arquitectura con participantes y preguntas operativas concretas. Permite preguntar qué rutas se aprendieron, qué trayecto se observó y cómo se comportó la alternativa. Es una evidencia más útil que una declaración estratégica, aunque no sea un informe exhaustivo de producción.

Una alternativa solo existe cuando se ha ensayado como modo de servicio

La documentación de SIRFEX describe pruebas de fallback a través del Internet ordinario. [3] En este artículo, fallback significa un camino alternativo probado que se utiliza cuando la ruta preferente no está disponible. Una segunda conexión dibujada en un esquema no basta. Debe poder alcanzar los destinos necesarios, transportar el tráfico previsto y sostener el retorno sin crear un estado inaceptable.

Cambiar de trayecto puede modificar más que la latencia. El tráfico puede salir del entorno dedicado y atravesar tránsito público. Los filtros pueden ser diferentes. Una aplicación limitada a ciertos orígenes puede dejar de comportarse igual. La exposición y los supuestos de seguridad pueden cambiar aunque el usuario solo vea que el servicio sigue respondiendo.

Por ello, la regla de operación debe indicar qué condición activa la alternativa, qué tráfico puede utilizarla, quién declara el fallo y cómo se recupera el camino normal. Un cambio automático y una maniobra manual tienen riesgos distintos. Ambos necesitan registros que permitan reconstruir lo ocurrido.

La fuente respalda que el piloto incluyó la prueba de una alternativa. [3] No afirma que el Internet ordinario ofreciera condiciones idénticas a la L3VPN ni que la transición fuera imperceptible. Tampoco comunica aquí tiempo de convergencia, sesiones conservadas o comportamiento de ambas familias. Esos datos siguen siendo preguntas para quien opere una red equivalente.

El límite de la evidencia es útil para la dirección. Obliga a especificar qué significa “tenemos respaldo”. ¿Se probó IPv4, IPv6 o ambos? ¿Entre qué puntos? ¿Qué ruta se retiró? ¿Cambió la frontera de seguridad? ¿Cómo se volvió al estado preferente? Sin esas respuestas, la palabra alternativa describe una posibilidad, no una capacidad demostrada.

MiNET observa la continuidad desde el borde universitario

El informe MiNET trata un escenario distinto al de SIRFEX. Un equipo de proyecto documentó un despliegue de IPv6 en un entorno universitario, identificó a Jehan Procaccia como supervisor y agradeció su ayuda como administrador de red de la DSI. [4] Esa independencia es importante: no repite la atribución de la presentación coescrita, sino que aporta otro tipo de relación personal con trabajo práctico.

El documento aborda doble pila, direccionamiento, enrutamiento y controles de Router Advertisement. [4] Es decir, sigue el camino desde la asignación de una dirección hasta la forma en que un dispositivo descubre su red local y puede alcanzar otros destinos. También documenta decisiones sobre servicios que no debían migrar todavía.

La implantación, sin embargo, corresponde al equipo que redactó el informe. El reconocimiento a Procaccia prueba supervisión y asistencia, no autoría individual de cada cambio. Esta separación permite contar la contribución sin apropiarse de un resultado colectivo. También evita inferir una posición actual a partir de un documento histórico.

SIRFEX y MiNET no deben fusionarse como si fueran un único programa. El primer registro se ocupa de interconectar redes regionales dentro de una frontera de rutas dedicada. El segundo examina una transición IPv6 en un ámbito universitario. Comparten problemas de continuidad, pero sus responsables, escalas y objetos son distintos.

Precisamente por esa diferencia, la combinación aporta valor. La coautoría vincula a Procaccia con un diseño y un piloto de interconexión. El reconocimiento del equipo lo vincula con supervisión y ayuda operativa en una migración. Las páginas docentes añaden contexto limitado. [1]-[6] Cada fuente cumple una función específica y ninguna necesita transformarse en una biografía total.

La doble pila es una transición con dos estados operativos

El equipo MiNET documentó un despliegue de doble pila. [4] La expresión significa mantener IPv4 e IPv6 al mismo tiempo durante la migración. De este modo, los servicios que dependen de IPv4 pueden continuar mientras se introducen y prueban rutas y aplicaciones sobre IPv6.

La coexistencia reduce el riesgo de un corte brusco, pero amplía el número de estados que hay que observar. Un dispositivo puede preferir IPv6 si recibe esa opción. Si el trayecto IPv6 tiene un fallo parcial, la aplicación puede tardar o fallar antes de intentar IPv4. Desde el punto de vista del usuario, parece una única incidencia; para el operador, son dos caminos con dependencias diferentes.

El direccionamiento también exige decisiones. Los prefijos deben corresponder a dominios operativos comprensibles, quedar registrados de manera consistente y anunciarse con el alcance previsto. Una gran disponibilidad de direcciones no elimina la necesidad de saber quién responde por cada bloque ni cómo se agrega.

El informe respalda que el equipo tomó decisiones explícitas de direccionamiento y enrutamiento. [4] No permite afirmar que ese diseño siga vigente ni que deba copiarse en cualquier campus. Es un registro fechado de una migración que trató la continuidad como una cuestión de configuración y comprobación, no como una simple declaración de adopción.

Según el análisis de BTW, preservar temporalmente el servicio IPv4 mientras se verifica IPv6 refleja la primacía del funcionamiento real. No es una defensa de la demora indefinida. La transición se completa cuando las aplicaciones, rutas y controles funcionan en el nuevo camino, no cuando una dirección IPv6 aparece en una presentación.

Los anuncios de router sitúan la frontera junto al dispositivo

El informe MiNET incluye decisiones sobre Router Advertisement. [4] Un anuncio de router es un mensaje de IPv6 que informa a los dispositivos sobre cómo configurarse y alcanzar la red. Puede comunicar un prefijo y un router predeterminado, entre otros parámetros que afectan al estado local.

Este mecanismo facilita la incorporación de equipos, pero también desplaza una parte del control hacia los mensajes recibidos en cada segmento. Un anuncio erróneo o no autorizado puede conducir a un dispositivo hacia una puerta de enlace equivocada o darle una configuración no prevista. La red troncal puede estar correctamente encaminada y, aun así, el usuario no alcanzar el destino.

Las medidas dependen del entorno: qué interfaces emiten anuncios, dónde se aceptan, cómo se detecta una fuente inesperada y cómo se coordina la autoconfiguración con otros servicios. La fuente documenta que el equipo tomó decisiones sobre este mecanismo. [4] No demuestra que se eliminara toda amenaza imaginable ni atribuye esas decisiones, una por una, a Procaccia.

La comprobación completa debe seguir el trayecto de extremo a extremo. Empieza por la dirección y la puerta de enlace que recibe el dispositivo, continúa por las rutas del campus y termina en el destino y su retorno. Observar solo el núcleo o solo el puesto final deja una parte de la frontera sin verificar.

Para un lector no técnico, este caso muestra por qué “IPv6 habilitado” dice muy poco. Un estado útil especifica el prefijo anunciado, el comportamiento de la puerta de enlace, el alcance de las rutas, el resultado de una prueba y la persona o equipo responsable de intervenir.

Mantener ciertos servicios en IPv4 fue una excepción delimitada

MiNET documentó la decisión de dejar algunos servicios administrativos en IPv4 cuando todavía no existía una protección equivalente para el nuevo camino. [4] La fuente no permite concluir que IPv6 fuera inseguro en general. Describe una frontera local de migración: el equipo no trasladó cada servicio solo para poder declarar una adopción completa.

Esta secuencia puede ser prudente. Una nueva familia de direcciones puede ampliar los caminos alcanzables, modificar supuestos de filtrado o exponer una aplicación a través de controles que aún no cubren ese tráfico. Antes de considerar equivalentes los dos caminos, el operador debería revisar autenticación, reglas de acceso, registros, monitorización y respuesta a incidentes.

Una excepción también puede convertirse en deuda si carece de responsable y fecha de revisión. Mantener un servicio en IPv4 preserva un control conocido durante la preparación de IPv6, pero no explica por sí solo cuándo será posible avanzar. El registro operativo necesita la razón, una protección compensatoria y una condición verificable de salida.

El informe atribuye la implantación y esas decisiones al equipo, mientras sitúa a Procaccia como supervisor y colaborador de red. [4] No hay base para afirmar que él eligiera en solitario cada excepción o garantizara su seguridad. La precisión del sujeto sigue siendo tan importante como la precisión técnica.

El análisis de BTW interpreta el episodio como una decisión basada en el sistema que funcionaba. Una métrica de adopción no debe ocultar que una aplicación carece de controles equivalentes. Reconocer la brecha permite gestionarla; declararla resuelta antes de tiempo solo traslada el riesgo a usuarios y operadores.

Dos registros distintos convergen en una disciplina de límites

Las arquitecturas de SIRFEX y MiNET no son iguales, pero los mecanismos documentados comparten una pauta. SIRFEX delimitó el intercambio entre redes regionales mediante una L3VPN, tablas separadas y una alternativa ensayada. [3] MiNET delimitó una transición mediante doble pila, decisiones de direccionamiento y rutas, control de anuncios y excepciones temporales en IPv4. [4]

El hilo común no es que Procaccia inventara esas técnicas ni que operara personalmente todos los componentes. Es que los registros asociados a su trabajo tratan la conectividad como una serie de decisiones explícitas. Qué rutas se comparten, qué familia funciona, qué servicio migra, qué señal configura al dispositivo y qué camino queda cuando falla el preferente son preguntas operativas.

El análisis de BTW denomina a esta pauta continuidad operativa. Continuidad no significa inmovilidad ni ausencia de fallos. Significa preservar una función definida durante un cambio o, si no es posible, fallar de una forma observada y controlable. Para ello hacen falta límites conocidos, pruebas y registros que expliquen el estado.

Esta capa de realidad evita confiar en etiquetas institucionales. Una red no se vuelve resistente por llevar el nombre de una comunidad o una región. La confianza procede de recursos correctamente registrados, políticas de rutas acotadas, trayectos que funcionan, alternativas probadas y responsabilidades claras.

La misma disciplina limita la atribución personal. El crédito se adhiere a la coautoría documentada, a la supervisión reconocida y a la asistencia descrita. La implantación y los resultados quedan con los equipos e instituciones que configuraron, probaron y operaron los sistemas. Esta precisión no debilita el perfil: muestra la red humana y técnica que hace posible la continuidad.

Fuentes

  1. Entrada del archivo JRES 2013 sobre la presentación de SIRFEX
  2. Índice del archivo JRES 2013
  3. Presentación técnica firmada de SIRFEX
  4. Informe del proyecto MiNET: Déploiement de l’IPv6 à la Maisel
  5. Registro de Telecom SudParis sobre enseñanza práctica de Internet
  6. Registro de Telecom SudParis sobre formación en redes