Descripción general de BGP

En esta sección se tratan los siguientes temas:

• Sistemas autónomos
• Rutas del AS y atributos
• BGP externo e interno
• Varias instancias de BGP
• Permitir tráfico de protocolo para interfaces de una zona de seguridad

BGP externo e interno

BGP admite dos tipos de intercambios de información de enrutamiento: intercambios entre diferentes AS y dentro de un solo AS. Cuando se usa entre AS, BGP se denomina BGP externo (EBGP) y las sesiones de BGP realizan enrutamiento interAS. Cuando se usa dentro de un AS, BGP se denomina BGP interno (IBGP) y las sesiones de BGP realizan enrutamiento intra-AS. muestra los AS, IBGP y EBGP.Figura 1

Figura 1: AS, EBGP y IBGP

Un sistema BGP comparte información de accesibilidad de red con sistemas BGP adyacentes, a los que se hace referencia como vecinos o pares.

Los sistemas BGP están organizados en grupos. En un grupo de IBGP, todos los pares del grupo, denominados pares internos, están en el mismo AS. Los pares internos pueden estar en cualquier parte del AS local y no tienen que estar directamente conectados entre sí. Los grupos internos utilizan rutas de un IGP para resolver direcciones de reenvío. También propagan rutas externas entre todos los demás enrutadores internos que ejecutan IBGP, calculando el siguiente salto tomando el siguiente salto BGP recibido con la ruta y resolviéndolo utilizando información de uno de los protocolos de puerta de enlace interior.

En un grupo EBGP, los pares del grupo (denominados pares externos) se encuentran en AS diferentes y normalmente comparten una subred. En un grupo externo, el siguiente salto se calcula con respecto a la interfaz que se comparte entre el par externo y el enrutador local.

Una ruta BGP es un destino, descrito como un prefijo de dirección IP, e información que describe la ruta al destino.

La siguiente información describe la ruta de acceso:

• La ruta del AS, que es una lista de números del AS que una ruta pasa para llegar al enrutador local. El primer número de la ruta de acceso es el del último AS de la ruta de acceso, el AS más cercano al enrutador local. El último número de la ruta de acceso es el más alejado del enrutador local, que generalmente es el origen de la ruta de acceso.

• Los atributos de ruta que contienen información extra de la ruta del AS que se usa en la política de enrutamiento.

Los pares BGP anuncian rutas entre sí en mensajes de actualización.

BGP almacena sus rutas en la tabla de enrutamiento de Junos OS ().inet.0 La tabla de enrutamiento almacena la siguiente información sobre las rutas BGP:

• Información de enrutamiento obtenida de los mensajes de actualización recibidos de los pares

• Información de enrutamiento local que BGP aplica a las rutas debido a las políticas locales

• Información que BGP anuncia a los pares de BGP en mensajes de actualización

Para cada prefijo de la tabla de enrutamiento, el proceso de protocolo de enrutamiento selecciona una única ruta de acceso, denominada ruta activa. A menos que configure BGP para anunciar varias rutas al mismo destino, BGP anuncia sólo la ruta activa.

El enrutador BGP que anuncia primero una ruta le asigna uno de los siguientes valores para identificar su origen. Durante la selección de la ruta, se prefiere el valor de origen más bajo.

• 0—El enrutador aprendió originalmente la ruta a través de un IGP (OSPF, IS-IS o una ruta estática).

• 1—El enrutador aprendió originalmente la ruta a través de un EGP (probablemente BGP).

• 2—Se desconoce el origen de la ruta.

Una ruta interna de BGP (IBGP) con una dirección de siguiente salto a un vecino de BGP remoto (protocolo de próximo salto) debe tener su siguiente salto resuelto mediante alguna otra ruta. BGP agrega esta ruta al módulo de resolución rpd para la resolución del próximo salto. Si se utiliza RSVP en la red, el siguiente salto del BGP se resuelve mediante la ruta de entrada RSVP. Esto da como resultado que la ruta BGP apunte a un salto siguiente indirecto y el siguiente salto indirecto apunte a un siguiente salto de reenvío. El reenvío del siguiente salto se deriva del siguiente salto de la ruta RSVP. A menudo hay un gran conjunto de rutas BGP internas que tienen el mismo protocolo next hop y, en tales casos, el conjunto de rutas BGP haría referencia al mismo siguiente salto indirecto.

Antes de Junos OS versión 17.2R1, el módulo de resolución del proceso de protocolo de enrutamiento (rpd) resolvía rutas dentro del IBGP recibía rutas de las siguientes maneras:

1. Resolución parcial de rutas: el próximo salto del protocolo se resuelve en función de rutas auxiliares, como rutas RSVP o IGP. Los valores de métrica se derivan de las rutas auxiliares y el siguiente salto se conoce como el siguiente salto de reenvío de resolución heredado de las rutas auxiliares. Estos valores de métrica se utilizan para seleccionar rutas en la base de información de enrutamiento (RIB), también conocida como tabla de enrutamiento.

2. Resolución de ruta completa: el siguiente salto final se deriva y se denomina tabla de enrutamiento del kernel (KRT) que reenvía el siguiente salto según la política de exportación de reenvío.

A partir de Junos OS versión 17.2R1, el módulo de resolución de rpd está optimizado para aumentar el rendimiento del flujo de procesamiento entrante, acelerando la tasa de aprendizaje de RIB y FIB. Con esta mejora, la resolución de ruta se ve afectada de la siguiente manera:

• Los métodos de resolución de ruta parcial y completa se activan para cada ruta de IBGP, aunque cada ruta puede heredar el mismo reenvío resuelto del siguiente salto o el siguiente salto del reenvío KRT.

• La selección de ruta de BGP se aplaza hasta que se realice una resolución de ruta completa para la información de accesibilidad de la capa de red (NLRI) recibida de un vecino de BGP, que podría no ser la mejor ruta en la RIB después de la selección de ruta.

Los beneficios de la optimización del solucionador rpd incluyen:

• Menor costo de búsqueda de resolución RIB: la salida de la ruta resuelta se guarda en una caché de resolución, de modo que los mismos valores de métrica y salto siguiente derivados se puedan heredar a otro conjunto de rutas que compartan el mismo comportamiento de ruta en lugar de realizar un flujo de resolución de ruta parcial y completo. Esto reduce el costo de búsqueda de resolución de ruta al mantener solo el estado de resolución más frecuente en una memoria caché con profundidad limitada.

• Optimización de selección de ruta BGP: el algoritmo de selección de ruta BGP se activa dos veces por cada ruta IBGP recibida: primero, mientras se agrega la ruta en la RIB con el siguiente salto como inutilizable y, segundo, mientras se agrega la ruta con un siguiente salto resuelto en la RIB (después de la resolución de ruta). Esto resulta en seleccionar la mejor ruta dos veces. Con la optimización del solucionador, el proceso de selección de ruta se activa en el flujo de recepción solo después de obtener la información del siguiente salto del módulo del solucionador.

• Almacenamiento en caché interno para evitar búsquedas frecuentes: la caché de resolución mantiene el estado de resolución más frecuente y, como resultado, la funcionalidad de búsqueda, como la búsqueda del salto siguiente y la búsqueda de ruta, se realiza desde la caché local.

• Grupo de equivalencia de ruta: cuando diferentes rutas comparten el mismo estado de reenvío o se reciben del mismo próximo salto de protocolo, las rutas pueden pertenecer a un grupo de equivalencia de ruta. Este enfoque evita la necesidad de realizar una resolución de ruta completa para dichas rutas. Cuando una nueva ruta requiere una resolución de ruta completa, primero se busca en la base de datos del grupo de equivalencia de ruta, que contiene la salida de la ruta resuelta, como el siguiente salto indirecto y el reenvío del salto siguiente.

En esta sección se tratan los siguientes temas:

• Abrir mensajes
• Mensajes de actualización
• Mensajes Keepalive
• Mensajes de notificación
• Mensajes de actualización de ruta

El procesamiento de rutas de BGP generalmente tiene varias etapas de canalización, como recibir actualizaciones, analizar actualizaciones, crear rutas, resolver el próximo salto, aplicar la política de exportación de un grupo de pares BGP, formar actualizaciones por pares y enviar actualizaciones a los pares.

La fragmentación BGP RIB divide una BGP RIB unificada en varias sub-RIB y cada sub-RIB maneja un subconjunto de rutas BGP. El subproceso RPD separado denominado subproceso de partición BGP sirve a cada sub-RIB para lograr la simultaneidad. Los subprocesos de partición de BGP son responsables de todas las etapas de la canalización de procesamiento de rutas de BGP, con la excepción de la formación de actualizaciones por pares y el envío de actualizaciones a los pares. Los subprocesos de partición de BGP reciben las actualizaciones enviadas por los pares de los subprocesos de E/S de actualización de BGP con los subprocesos de E/S de actualización de BGP hash de los prefijos de las actualizaciones y envían las actualizaciones a los subprocesos de partición de BGP aplicables en función del cálculo del hash. El subproceso de partición de BGP procesa la configuración de la misma manera que el subproceso principal de RPD, crea pares, grupos, tablas de ruta y utiliza la información de configuración para el procesamiento de rutas de BGP.

Los subprocesos de E/S de actualización de BGP son responsables del final de esta canalización de BGP, lo que implica generar actualizaciones por par para grupos BGP individuales y enviarlas a los pares. Un subproceso de actualización puede servir a uno o más grupos BGP. Los subprocesos de E/S de actualización de BGP crean actualizaciones para grupos en paralelo e independientes de otros grupos a los que sirven otros subprocesos de actualización. Esto podría ofrecer una mejora significativa de la convergencia en una carga de trabajo de escritura pesada, que implica publicidad para muchos pares distribuidos en muchos grupos. Los subprocesos de E/S de actualización de BGP también son responsables de escribir y leer desde los sockets TCP de los pares BGP que anteriormente proporcionaban los subprocesos de BGPIO (de ahí el sufijo IO en BGP Update IO).

Los subprocesos de E/S de actualización de BGP se pueden configurar independientemente de la función de particionamiento RIB, pero su uso es obligatorio con el particionamiento RIB, a fin de lograr una mejor eficiencia de empaquetado de prefijos en el mensaje de actualización de BGP saliente. El particionamiento BGP divide la RIB en varias sub-RIB que son servidas por subprocesos RPD separados. Por lo tanto, los prefijos que podrían haber entrado en una sola actualización saliente terminan en diferentes fragmentos. Para poder construir actualizaciones de BGP con prefijos con el mismo atributo saliente que podría pertenecer a diferentes subprocesos de partición de RPD, todos los subprocesos de partición envían información de anuncios compactos para que los prefijos se anuncien a un subproceso de actualización que sirva a ese grupo del mismo nivel de BGP. Esto permite que el subproceso de actualización, que sirve a este grupo par BGP, empaquete prefijos con los mismos atributos, que pueden pertenecer a diferentes particiones en el mismo mensaje de actualización saliente. Esto minimiza el número de actualizaciones que se anunciarán y, por lo tanto, ayuda a mejorar la convergencia. El subproceso de E/S de actualización administra cachés locales de contenedores pares, de grupo, de prefijos, TSI y RIB.

El subproceso de actualización de BGP y el particionamiento de RIB de BGP están deshabilitados de forma predeterminada. Si configura el subprocesamiento de actualizaciones y la partición de costillas en un motor de enrutamiento, RPD creará subprocesos de actualización. De forma predeterminada, el número de subprocesos de actualización y subprocesos de partición creados es el mismo que el número de núcleos de CPU en el motor de enrutamiento. El subprocesamiento de actualizaciones solo se admite en un proceso de protocolo de enrutamiento (rpd) de 64 bits. Opcionalmente, puede especificar el número de subprocesos que desea crear mediante instrucciones and en el nivel de jerarquía.set update-threading <number-of-threads>set rib-sharding <number-of-threads>[edit system processes routing bgp] Para el subproceso de actualización de BGP, el intervalo es actualmente de 1 a 128 y para el particionamiento de RIB BGP, el intervalo es actualmente de 1 a 31.

Cuando se configura NSR para las características de particionamiento RIB BGP y BGP Update IO, la RPD de copia de seguridad crea el mismo número de fragmentos de BGP y subprocesos de E/S de actualización de BGP en el motor de enrutamiento de copia de seguridad. Los subprocesos de E/S de actualización de BGP de RPD de copia de seguridad leen la actualización de BGP replicada, otros mensajes recibidos de los pares, así como la actualización de BGP replicada y otros mensajes enviados a los pares. En función del hash de los prefijos, los subprocesos de E/S de actualización de BGP de RPD de copia de seguridad envían estos mensajes BGP a la partición BGP aplicable y a los subprocesos principales de RPD. La partición BGP y los subprocesos principales de RPD en la RPD de copia de seguridad crean el estado de ruta recibido y anunciado utilizando estos mensajes BGP replicados. Cuando se produce un error en el motor de enrutamiento principal, el motor de enrutamiento de copia de seguridad se convierte en el motor de enrutamiento principal y el RPD de reserva se convierte en el RPD principal sin problemas sin afectar a las sesiones de BGP con los pares.

Para cada prefijo de la tabla de enrutamiento, el proceso de protocolo de enrutamiento selecciona una única y mejor ruta. Una vez seleccionada la mejor ruta, la ruta se instala en la tabla de enrutamiento. La mejor ruta se convierte en la ruta activa si un protocolo con un valor de preferencia global más bajo (más preferido) no aprende el mismo prefijo, también conocido como distancia administrativa. El algoritmo para determinar la ruta activa es el siguiente:

1. Compruebe que se puede resolver el siguiente salto.

2. Elija la ruta con el valor de preferencia más bajo (preferencia de proceso de protocolo de enrutamiento).

   Las rutas que no son aptas para ser utilizadas para el reenvío (por ejemplo, porque fueron rechazadas por la política de enrutamiento o porque no se puede acceder a un salto siguiente) tienen una preferencia de –1 y nunca se eligen.

3. Prefiere la ruta con mayor preferencia local.

   Para rutas que no sean BGP, elija la ruta con el valor más bajo .preference2

4. Si el atributo Protocolo de puerta de enlace interior acumulado (AIGP) está habilitado , agregue la métrica IGP y prefiera la ruta con el atributo AIGP inferior.

5. Prefiera la ruta con el valor de ruta del sistema autónomo (AS) más corto (omitida si la instrucción está configurada).as-path-ignore

   Un segmento de confederación (secuencia o conjunto) tiene una longitud de ruta de acceso de 0. Un conjunto de AS tiene una longitud de ruta de acceso de 1.

6. Prefiera la ruta con el código de origen inferior.

   Las rutas aprendidas de un IGP tienen un código de origen más bajo que las aprendidas de un protocolo de puerta de enlace exterior (EGP), y ambos tienen códigos de origen más bajos que las rutas incompletas (rutas cuyo origen se desconoce).

7. Prefiera la ruta con la métrica de discriminador de salida múltiple (MED) más baja.

   En función de si está configurado un comportamiento de selección de ruta de tabla de enrutamiento no determinista, existen dos casos posibles:

   • Si el comportamiento de selección de ruta de la tabla de enrutamiento no determinista no está configurado (es decir, si la instrucción no está incluida en la configuración del BGP), para rutas con los mismos números de AS vecinos al frente de la ruta del AS, prefiera la ruta con la métrica MED más baja.path-selection cisco-nondeterministic Para comparar siempre los MED independientemente de si los AS pares de las rutas comparadas son los mismos, incluya la instrucción.path-selection always-compare-med

   • Si se configura un comportamiento de selección de ruta de tabla de enrutamiento no determinista (es decir, la instrucción se incluye en la configuración del BGP), prefiera la ruta con la métrica MED más baja.path-selection cisco-nondeterministic

   Las confederaciones no se tienen en cuenta al determinar los AS vecinos. Una métrica MED faltante se trata como si un MED estuviera presente pero cero.

   Nota:

   La comparación MED funciona para la selección de una sola ruta dentro de un AS (cuando la ruta no incluye una ruta de AS), aunque este uso es poco común.

   De forma predeterminada, solo se comparan las MED de las rutas que tienen los mismos sistemas autónomos pares (AS). Puede configurar las opciones de selección de ruta de la tabla de enrutamiento para obtener comportamientos diferentes.

8. Prefiera rutas estrictamente internas, que incluyen rutas IGP y rutas generadas localmente (estáticas, directas, locales, etc.).

9. Prefiera las rutas de BGP estrictamente externas (EBGP) a las rutas externas aprendidas a través de sesiones internas de BGP (IBGP).

10. Prefiera la ruta cuyo próximo salto se resuelve a través de la ruta IGP con la métrica más baja. Las rutas BGP que se resuelven a través de IGP son preferibles a las rutas inalcanzables o rechazadas.

    Nota:

    Una ruta se considera una ruta BGP de igual costo (y se usará para el reenvío) si se realiza un desempate después del paso anterior. Se tienen en cuenta todas las rutas en con los mismos AS vecinos aprendidas por un vecino de BGP habilitado para varias rutas.

    La multiruta BGP no se aplica a rutas que comparten el mismo costo de MED-plus-IGP pero difieren en el costo de IGP. La selección de rutas múltiples se basa en la métrica de costo del IGP, incluso si dos rutas tienen el mismo costo de MED más IGP.

11. Si ambos caminos son externos, prefiera el camino más antiguo, en otras palabras, el camino que se aprendió primero. Esto se hace para minimizar el aleteo de rutas. Esta regla no se utiliza si se cumple alguna de las condiciones siguientes:

    • path-selection external-router-id está configurado.

    • Ambos pares tienen el mismo ID de enrutador.

    • Cualquiera de los pares es un par de la confederación.

    • Ninguna de las rutas es la ruta activa actual.

12. Prefiere una ruta principal a una secundaria. Una ruta principal es aquella que pertenece a la tabla de enrutamiento. Una ruta secundaria es aquella que se agrega a la tabla de enrutamiento a través de una política de exportación.

13. Prefiere la ruta del par con el ID de enrutador más bajo. Para cualquier ruta con un atributo de ID de originador, sustituya el ID de originador por el ID de enrutador durante la comparación de ID de enrutador.

14. Prefiere la ruta con la longitud de lista de clústeres más corta. La longitud es 0 para ninguna lista.

15. Preferya la ruta del par con la dirección IP del par más baja.

• Selección de ruta de tabla de enrutamiento
• Selección de ruta de tabla BGP
• Efectos de anunciar múltiples rutas a un destino

Junos OS admite sustancialmente las siguientes RFC y borradores de Internet, que definen estándares para BGP IP versión 4 (IPv4).

Para obtener una lista de los estándares BGP IP versión 6 (IPv6) compatibles, consulte Estándares IPv6 compatibles.

BGP de Junos OS admite la autenticación para intercambios de protocolos (autenticación MD5).

• RFC 1745, BGP4/IDRP para interacción IP-OSPF

• RFC 1772, Aplicación del Protocolo de puerta de enlace de frontera en Internet

• RFC 1997, Atributo BGP Communities

• RFC 2283, Extensiones multiprotocolo para BGP-4

• RFC 2385, Protección de sesiones BGP mediante la opción de firma TCP MD5

• RFC 2439, Amortiguación de aletas de ruta BGP

• RFC 2545, Uso de extensiones multiprotocolo BGP-4 para enrutamiento entre dominios IPv6

• RFC 2796, Reflexión de ruta BGP: una alternativa al IBGP de malla completa

• RFC 2858, Extensiones multiprotocolo para BGP-4

• RFC 2918, Capacidad de actualización de ruta para BGP-4

• RFC 3065, Confederaciones de sistemas autónomos para BGP

• RFC 3107, Llevar información de la etiqueta en BGP-4

• RFC 3345, Condición de oscilación de ruta persistente del Protocolo de puerta de enlace de borde (BGP)

• RFC 3392, Anuncio de capacidades con BGP-4

• RFC 4271, Protocolo de puerta de enlace de borde 4 (BGP-4)

• RFC 4273, Definiciones de objetos administrados para BGP-4

• RFC 4360, Atributo BGP Extended Communities

• RFC 4364, Redes privadas virtuales (VPN) BGP/MPLS IP

• RFC 4456, Reflexión de ruta BGP: Una alternativa al BGP interno de malla completa (IBGP)

• RFC 4486, Subcódigos para el mensaje de notificación de cese de BGP

• RFC 4659, Extensión de red privada virtual (VPN) BGP-MPLS IP para VPN IPv6

• RFC 4632, Enrutamiento entre dominios sin clase (CIDR): El plan de asignación y agregación de direcciones de Internet

• RFC 4684, Distribución de rutas restringidas para conmutación de etiquetas multiprotocolo (BGP/MPLS) Protocolo de Internet (IP) Redes privadas virtuales (VPN)

• RFC 4724, Mecanismo de reinicio correcto para BGP

• RFC 4760, Extensiones multiprotocolo para BGP-4

• RFC 4781, Mecanismo de reinicio correcto para BGP con MPLS

• RFC 4798, Conexión de islas IPv6 a través de MPLS IPv4 mediante enrutadores perimetrales de proveedor IPv6 (6PE)

  No se admite la opción 4b (redistribución eBGP de rutas IPv6 etiquetadas de AS a AS vecino).

• RFC 4893, compatibilidad BGP con espacio de número de AS de cuatro octetos

• RFC 5004, Evite las transiciones de la mejor ruta de BGP de una externa a otra

• RFC 5065, Confederaciones de sistemas autónomos para BGP

• RFC 5082, El mecanismo de seguridad TTL generalizada (GTSM)

• RFC 5291, Capacidad de filtrado de ruta de salida para BGP-4 (soporte parcial)

• RFC 5292, Filtro de ruta saliente basado en prefijo de dirección para BGP-4 (soporte parcial)

  Los dispositivos que ejecutan Junos OS pueden recibir mensajes ORF basados en prefijos.

• RFC 5396, Representación textual de números de sistema autónomo (AS)

• RFC 5492, Anuncio de capacidades con BGP-4

• RFC 5512, Identificador de familia de direcciones posteriores de encapsulación BGP (SAFI) y atributo de encapsulación de túnel BGP

• RFC 5549, Publicidad de información de accesibilidad de la capa de red IPv4 con un próximo salto IPv6

• RFC 5575, Difusión de reglas de especificación de flujo

• RFC 5668, Comunidad extendida de BGP específico de AS de 4 octetos

• RFC 6286, Identificador BGP único en todo el sistema autónomo para BGP-4: totalmente compatible

• RFC 6368, BGP interno como protocolo perimetral proveedor/cliente para redes privadas virtuales (VPN) BGP/MPLS IP

• RFC 6810, La infraestructura de clave pública de recursos (RPKI) para el protocolo de enrutador

• RFC 6811, Validación de origen del prefijo BGP

• RFC 6996, Reserva de Sistema Autónomo (AS) para uso privado

• RFC 7300, Reserva de los números del último sistema autónomo (AS)

• RFC 7611, BGP ACCEPT_OWN atributo de comunidad

  Apoyamos la RFC al permitir que los enrutadores de Juniper acepten rutas recibidas de un reflector de ruta con el valor de comunidad .accept-own

• RFC 7752, Distribución en dirección norte de información de estado de vínculo e ingeniería de tráfico (TE) mediante BGP

• RFC 7854, Protocolo de supervisión BGP (BMP)

• RFC 7911, Anuncio de múltiples rutas en BGP

• RFC 8212, Comportamiento de propagación de rutas BGP externo predeterminado (EBGP) sin políticas: totalmente compatible

  Excepciones:

  Los comportamientos en RFC 8212 no se implementan de forma predeterminada para evitar la interrupción de la configuración existente del cliente. El comportamiento predeterminado aún se mantiene para aceptar y anunciar todas las rutas con respecto a los pares EBGP.

• RFC 8326, Apagado correcto de la sesión BGP

• RFC 9069, Compatibilidad con RIB local en el protocolo de supervisión de BGP (BMP)

• Borrador de Internet draft-idr-rfc8203bis-00, Comunicación de cierre administrativo BGP (expira en octubre de 2018)

• Borrador de Internet draft-ietf-grow-bmp-adj-rib-out-01, Soporte para Adj-RIB-Out en el Protocolo de monitoreo de BGP (BMP) ( expira el 3 de septiembre de 2018)

• Borrador de Internet draft-ietf-idr-aigp-06, The Cumulative IGP Metric Attribute for BGP (expira en diciembre de 2011)

• Borrador de Internet draft-ietf-idr-as0-06, Codificación del procesamiento del AS 0 (expira en febrero de 2013)

• Borrador de Internet draft-ietf-idr-link-bandwidth-06.txt, BGP Link Bandwidth Extended Community (expira en julio de 2013)

• Borrador de Internet draft-ietf-sidr-origin-validation-signaling-00, Estado de validación de origen del prefijo BGP Comunidad extendida (soporte parcial) ( expira en mayo de 2011)

  La comunidad extendida (estado de validación de origen) se admite en la política de enrutamiento de Junos OS. No se admite el cambio especificado en el procedimiento de selección de ruta.

• Borrador de Internet draft-kato-bgp-ipv6-link-local-00.txt, Emparejamiento BGP4+ mediante dirección local de vínculo IPv6

Los siguientes RFC y borradores de Internet no definen estándares, sino que proporcionan información sobre BGP y tecnologías relacionadas. El IETF los clasifica de diversas maneras como "experimentales" o "informativos".

• RFC 1965, Confederaciones de sistemas autónomos para BGP

• RFC 1966, BGP Route Reflection—Una alternativa al IBGP de malla completa

• RFC 2270, Uso de un AS dedicado para sitios alojados en un solo proveedor

• Borrador de Internet draft-ietf-ngtrans-bgp-tunnel-04.txt, Connecting IPv6 Islands across IPv4 Clouds with BGP (expira en julio de 2002)