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

Hi Jordi,

Thanks for summarising. My thoughts on the options:

Option A
Agree with Med here. RFC8026 would need to be updated to allow this. I would also want to see some description of how the candidate list would be created when the configuration for the mechanisms could come from DHCPv6, PCP and/or DNS. Client behaviour needs to be deterministic for this otherwise we’ve defeated the object.

Option B & C

Option C would be my preferred solution. It allows XLAT to be configured, but can be over-ridden by supplying DHCPv6 config. Option B is less flexible in this respect (to my mind at least) - e.g. if you have XLAT with RFC7050 and you want to migrate some clients to a different mechanism (DHCPv6 provisioned) then you’ll also need to ensure that the NAT64 prefix isn’t resolved just for the clients that you want to migrate, and all of the clients are capable of the new mechanism (not always knowable if customers supply their own devices).

One thing to clear up here: If the client received an RFC8026 option 111 containing no option codes, then this is an error and the client will discard it. Per the RFC, it may then attempt to configure mechanisms based on the config it has received. The only way to ensure that this doesn’t happen is to not supply the client with the DHCPv6 soffwire config.

Cheers,
Ian

> On 24. Jan 2019, at 10:38, <mohamed.boucadair@orange.com> <mohamed.boucadair@orange.com> wrote:
> 
> Hi Jordi, 
> 
> The problem with option A is that the candidate list will be set by 8026 using DHCP options. So, even if you return 113 in the priority list, xlat won't be added to the candidate list because no DHCP option for xlat is actually returned. RFC8026 can be relaxed to allow for other sources to fed the candidate list, but that is another piece of work.
> 
> One comment about options B and C: These options are not about "Exclude 464XLAT from the stateless "priority" setup that allows RFC8026", but about removing the IANA text asking to add 113 to the S46 priority list. xlat can be added to the priority list if a dhcp option is defined for it.
> 
> My take is to pick option C (with the clarification made above) for the following reasons: 
> * If a dhcp option is defined in the future, the codepoint of that option will be included in the S46 priority list and normal 8026 processing will be followed.
> * If a (stale) method is still present in the network to retrieve the prefix by other means, the priority set by the provider in S46 priority list will be followed because the default priority of xlat as set by draft-ietf-v6ops-transition-ipv4aas won't win. 
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : v6ops [mailto:v6ops-bounces@ietf.org] De la part de JORDI PALET MARTINEZ
>> Envoyé : jeudi 24 janvier 2019 10:12
>> À : v6ops@ietf.org WG
>> Objet : [v6ops] question to the WG about draft-ietf-v6ops-transition-ipv4aas
>> 
>> 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.
>> 
>> 
>> 
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops