Lorenzo Colitti <lorenzo@xxxxxxxxxx> wrote:
> As for putting NAT64 in the name of the option, I'm not sure that's
> particularly useful. The only case in which this would make a difference is
> if a new transition technology becomes widely deployed - otherwise it
> doesn't matter what the name is. If the new technology is mostly
> transparent to hosts just like NAT64 is, then we would want to continue to
> use the same option. If we put NAT64 in the name of the option we might not
> be able to do that easily. So that argues against making the option more
> "NAT64 specific" than it already is.
I strongly agree with you -- putting the name in does not particularly help,
I think.
I am less convinced that having the name would harm us in the end, if we
picked it carefully, but I have a hard time finding that name.
The key point of the option is that host does not need IPv4.
I agree with some commenters that it isn't obvious that it implies that NAT64
is available. But, we have other signals for that, I think.
NAT64 puts *no* requirements on the hosts (except that they be willing to
succeed network attachment without IPv4).
I can imagine some other v6-over-v4 mechanism (inspired by 6to4, or Teredo perhaps) could
perhaps be introduced which did not involve the network creating state.
But in that case, it would also be transparent to the end host, as you say.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] mcr@xxxxxxxxxxxx http://www.sandelman.ca/ | ruby on rails [
Attachment:
signature.asc
Description: PGP signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
