RFC8950: Announce IPv4 with an IPv6 next-hop

RFC8950: Announce IPv4 with an IPv6 next-hop(anuragbhatia.com)

37 points by porridgeraisin 2 hours ago | 6 comments

asdfsa32 9 minutes ago |

A few more RFCs, a few more IP over IP bandaid, a few more extensions, and we will get there. By God IPv6 is a stain in the history of computer science.

IPv6 should have really just worked like NAT/IP over IP on IPv4 hardware and fast path on IPv6 hardware. But instead we got a monster that keeps growing with things like NAT64, 4over6, DS-Lite, MAP-E, and now BGP stopgaps and a growing

https://en.wikipedia.org/wiki/List_of_IPv6_transition_mechan...

wredcoll 5 minutes ago | |

> IPv6 should have really just worked like NAT/IP over IP on IPv4 hardware

This literally exists. There's no need for it to be part of the original specification because it's a completely separate concept.

There's nothing wrong with ipv6 other than the general human desire to not change things that "work" and for people who are currently powerful because they own a bunch of ipv4 to resist changes.

petecooper 59 minutes ago |

https://www.rfc-editor.org/info/rfc8950/

Alifatisk 1 hour ago |

I guess the point with this to facilitate usage of IPv6.

simoncion 57 minutes ago | |

The Abstract and Introduction sections of the RFC [0] explain what the point of this is. The "Changes Compared to RFC 5549" section is especially good reading, as it both alerts you to the fact that this is an update to a seventeen year old RFC and explains what changed in the update.

[0] <https://datatracker.ietf.org/doc/html/rfc8950>

ozereray1 1 hour ago |

RFC 8950 is quietly useful for operators who want to drop IPv4 addresses from point-to-point links and run an IPv6-only fabric while still carrying IPv4 routes over BGP. How well is it supported in practice across vendors and open-source routing daemons like FRR and BIRD?

esseph 37 minutes ago | |

Your comment was flagged, I vouched it