Hello Lorenzo: I agree with 1 2 and 3. 1 and 2 in particular are not overly complex to specify and code, and seem pretty useful. 3 is more complex and more on the nice-to-have side. I would
have done one and 2. But hey, the consensus can be otherwise. I’m concerned because this transition seems to last a lot longer than we thought. It may last 20 more years, or never really end. We may not have seen something coming that will
make it so that a node that needs NAT64 may be fooled in a network that has something newer. Now, if you have an escape strategy for that day like this other option and you can prove there’s no place for backward compatibility problem at that time, then fine with me.
Also fine with me is if that draft is only for NAT64, in which case you could even have NAT64 in the name of the option to make things clearer. If the consensus is to go without any of the above, well, that what consensus is for. I’ll keep fingers crossed… Take care, Pascal From: Lorenzo Colitti <lorenzo@xxxxxxxxxx>
On Tue, Jun 23, 2020 at 6:55 PM Pascal Thubert via Datatracker <noreply@xxxxxxxx> wrote:
We (the authors) did discuss this at some length and we opted for the current behaviour for reasons of simplicity. Here are a few reasons why:
That complexity is a downside of supporting multiple transition mechanisms. And the upside is limited. We do feel that the likelihood of another transition technology becoming
widely used by end hosts is low, because NAT64 is already so widely deployed and so easy to implement in hosts. (In fact, if the host doesn't care about IPv4 literals or IPv4-only apps, the work required to implement NAT64 is actually zero.) Additionally,
if a new transition technology does end up being widely supported by hosts, it's always possible to define a new DHCP option code for it. So we felt that it was best to keep this option simple. IIRC (but other authors and chairs, please correct me if I'm wrong) there was not much discussion in the WG that this should
be changed, so I think the WG was pretty happy with the current semantics. Cheers, Lorenzo |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call