[v6ops] question to the WG about draft-ietf-v6ops-transition-ipv4aas

[JORDI PALET MARTINEZ <[e-mail]>]

Hi all,

Sorry the long email, but it needs to be explained in detail so v6ops folks can understand it and provide inputs.

As part of the IESG telechat where this document was evaluated, it was raised a discuss regarding using RFC8115 in a way that introduces a "trick" to provide a DHCP option for a NAT64 prefix.

After hearing the comments in the list, we decided to remove it, but we still need a way to make sure that 464XLAT/NAT64 can be prioritized as well as the other mechanisms, so the ISP has control over it.

Our suggested approach was to keep using RFC8026 for all the mechanisms.

RFC8026 requires a *top-level Option Request* in order to respond with the S46 option, which define the priority of the mechanisms. We didn't realize about that before because it was "intrinsically there" while we had RFC8115.

Because we don't have an explicit DHCP option for configuring the NAT64, it means the option code for NAT64/464XLAT (113, which was already defined for an IPv6 /64 prefix, but we are asking IANA to include in the RFC8026 defined table just for signaling the priority) will not be provided unless the CE ask via DHCP for the configuration of other transition mechanisms.

In the opinion of the document co-authos, this is fine, because precisely we expect that the CE supports several (hopefully all the 5).

So, in this case (let's call this OPTION A), the behavior will be:

1) CE get the configuration parameters for all the mechanisms (including a NAT64 prefix via PCP or RFC7050, and the other 4 by means of DHCP).

2) As part of the request for DHCP configurable mechanism, the CE will ask for S46 priority. If NAT64 is available in the ISP, the S46 will also contain the 113.

3) As a result, the CE can follow RFC8026 to decide which one match the ISP preference with what the CE can "use".

What is the issue? If the CE only supports 464XLAT, then the CE must be forced to anyway, ask for "another" DHCPv6 configurable mechanism and ignore that information, but use the S46 response to check if the ISP supports NAT64. Not an issue, in our opinion.

If the ISP only supports 464XLAT, then is forced to anyway, respond to the DHCPv6 request for configuration options of all the other 4 mechanisms (so this will work in any case despite "what" the CE is supporting), but in the S46 response, will include only the 113, to signal that *only* supports NAT64. Again, not an issue in our opinion.

It is just a matter of having some text in the document that explains this workaround because of the lack of explicit DHCPv6 configuration option for NAT64.

This workaround keeps the door open to a future possible DHCPv6 option for NAT64 and we think is not contradicting RFC8026.

**** While we don't think it breaks anything, RFC8026 authors believe is contradicting RFC8026 (we still don't see how or if it a minor detail in the text, that could be updated with an errata or it requires an RFC8026-bis, etc.).

So the question here. Do the WG believe this is fine? Or somebody can explain if that will break anything/contradicting RFC8026?
    
OPTION B
Exclude 464XLAT from the stateless "priority" setup that allows RFC8026, by setting it on "top of it" (higher priority). So, if the NAT64 prefix is available (by means of PCP or RFC7050), the CE will just configure it, because the ISP is telling him "I've a NAT64 for you, don't care about other options".

This just works, but it forces an ISP to make sure that only the customers that ISP wants to use the NAT64 are able to identify it (only in case, they have different "customer" groups with different mechanisms). If, in the future, we define a DHCP option for NAT64, it forces the ISP to not provide the NAT64 by means of PCP neither RFC7050. A configuration mistake in the ISP network regarding who is getting and what for S46, will still allow the customers to use the NAT64.

OPTION C
Similar to b, but having the 464XLAT/NAT64 with the *lower* priority.

In this case, as well, it will work, but it forces the ISP to make sure that for those customers that the ISP wants they use the NAT64, the S46 options must not return anything, otherwise the CE will never use the 464XLAT. So a mistake with the S46 may disallow customers using the NAT64. If, in the future, we define a DHCPv6 option for NAT64, it will just work as well.

Of course, in all the 3 options, there may be other things to consider, but we think it is not possible to predict all them. All them depend on "if we define in the future a DHCPv6 option for NAT64, we will need to update the firmware of the CEs to support that, so it is safe to assume that we may need to revise at that point as well RFC8026 and possibly draft-ietf-v6ops-transition-ipv4aas ...".
    
Co-authors take: Option A is fine, unless we can understand why it is contradicting RFC8026, then option B, unless we agree to start the work to update RFC8026 to support NAT64 someway (with or without a new DHCPv6 option), in which case, option C makes more sense.

Please, let us know what do you think, and specially if you see that the procedure specified as OPTION A, is fine, in which case the issue is resolved.

Thanks!

Regards,
Jordi
 
 



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.