search

becarpenter / book6

A collaborative IPv6 book
Other
232 stars 24 forks source link

6rd as tunnel; ping6/traceroute6; tools might show IPv4 addresses #107

Closed danwing closed 2 months ago

becarpenter commented 2 months ago

One point we could discuss is that 6rd is also listed in the 'Obsolete techniques' section. I assume that today we'd recommend an ISP to deploy native IPv6 in preference to 6rd. Thoughts welcome from @danwing and @buraglio. Anyway, thanks Dan!

buraglio commented 2 months ago

Yes, I would always recommend against 6rd for an ISP given native is fairly well supported.

danwing commented 2 months ago

Agreed 6rd should be dis-recommended in 2024. Perhaps just needs a forward reference to the obsolete techniques section? (If there are other tunnel techniques which are also obsolete, I would enumerate them all and forward reference them all.)

becarpenter commented 2 months ago

Yes, I'll patch that forward reference in. However, book6 is reporting, not making policy... maybe the IETF should officially declare certain techniques to be deprecated?

danwing commented 2 months ago

There seems some appetite for deprecating IPv6 transition technologies when it impacts clients, for example https://datatracker.ietf.org/doc/draft-buraglio-deprecate7050. But 6rd isn't noticed or seen by clients, so I dunno if there is appetite to spend time to deprecate a transition mechanism. Something to ask v6ops in case someone wants fame (with little fortune).

cron2 commented 2 months ago

If people run 6rd with public IPv4 addresses on the CPE endpoints, there might be money to be made moving towards other access technologies that are based on a native v6 network and CGN... (and selling off the IPv4 space). But changing a production network is not an easy undertaking, so might not be considered worth the effort & risk.

becarpenter commented 2 months ago

@cron2, agreed, but the "Obsolete techniques" section already says "Readers are advised to ignore these techniques for new deployments, and to consider removing them from existing deployments." I think every operator will follow the "not broken, don't fix" approach, as you say.