[lacnog] RIPE690 to IETF BCP

[Fernando Gont]

Hola Jordi y maradonianos,

On 20/10/25 17:07, jordi.palet--- vía LACNOG wrote:
> Hola a todos,
> 
> Tal y como comente en el pasado LACNIC, tras la presentación de Jan, hace tiempo que trabajaba en una versión de BCP de IETF en v6ops para hacer más formal el RIPE690.
> 
> Por fin pude completarlo y teniendo en cuenta que es la primera version, espero muchos comentarios!
> 
> https://datatracker.ietf.org/doc/draft-palet-v6ops-prefix-assignment/

Literalmente, hasta el momento, solo lei el parrafo sobre el que envio 
comments a continuacion:

> 3.1.  The Ping-Pong Problem in Point-to-Point Links
> 
>    Some point-to-point links may present the ping-pong problem, (a
>    forwarding loop).  The fundamental root cause of this problem is an
>    IPv6 implementations not performing full Neighbor Discovery (NS/NA)
>    on addresses that the prefix says could exist on the link.
> 
>    IPv6 implementations are assuming that all addresses within the
>    prefix must exist at the other end of the point-to-point link, and
>    send the traffic straight onto the link.  If the address doesn't
>    exist, and there is a covering route back in the other direction, the
>    ping-pong problem occurs.
> 
>    Full Neighbor Discovery is doing more than just resolving the link-
>    layer address of an IPv6 address.  Neighbor Discovery is also
>    determining if the address exists.  Even if a point-to-point link
>    doesn't have link-layer addresses to resolve, ND determining if an
>    address exists on the link is very beneficial because it will prevent
>    the ping-pong problem occurring entirely regardless of the IPv6
>    prefix length being used on the link.

Personalmente creo que esto es mas bien un problema de ruteo o 
configuracion, que de los sistemas "no implementando full ND". Algunos 
comments:

* En el escenario en cuestion, si vos configuras un /64 para un link
   P2P, lo que estas diciendo es "en ese enlace estan todas las
   direcciones de ese /64".

* Por otro lado, y al mismo tiempo, si se trata de un link P2P (de ahi
   el nombre ;-) ), estas diciendo "en este enlace hay solo dos sistemas"

* En un escenario como el item anterior, no tiene sentido hacer ND,
   porque no hay neighbor q descubrir -- el neighbor es simplemente el
   otro extremo.


En tal sentido, el problema se soluciona configurando la info correcta: 
una host-directed route al otro sistema, y nada mas.

(claramente, otra opcion es simplemente usar link-locals para ese 
enlace, o bien el hack de utilizar un /127)


Nota: Si ND *si* se utilizara en ese enlace (por ej., asumamos que el 
enlace P2P es una interfaz Ethernet entre ambos sistemas), ahi, 
cualquier paquete que se envie a una direccion inexistente va a terminar 
en un ICMP host unreachable (el router en cuestion va a querer resolver 
la direccion en el enlace en cuestion, pero nunca va a recibir respuesta).

Slds,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont en si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494