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

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 24 Jan 2019 10:11:36 +0100

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.

---

From: <[email-masked]>
Date: Thu, 24 Jan 2019 09:38:09 +0000

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:[email-masked]] De la part de JORDI PALET MARTINEZ
> Envoyé : jeudi 24 janvier 2019 10:12
> À : [email-masked] WG
> Objet : [v6ops] question to the WG about draft-ietf-v6ops-transition-ipv4aas
> 
> Hi all,
> 
> 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.
> 
> 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).
> 
> 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.
> 
> 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
> 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
> 
> 
> 
> 
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: [email-masked]
Date: Thu, 24 Jan 2019 11:21:58 +0100

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, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Jordi, 
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 28 Jan 2019 11:31:03 +0100

Hi all,

I've discussed with my co-authors about this, and we finally, not having other inputs, decided to go for option c.

We have already submitted the new version:

https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/

Hopefully this resolves this final issue!

Thanks!

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de <[email-masked]>
Fecha: jueves, 24 de enero de 2019, 11:22
Para: "mohamed.boucadair" <[email-masked]>
CC: "[email-masked] WG" <[email-masked]>, JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
Asunto: Re: [v6ops] question to the WG about draft-ietf-v6ops-transition-ipv4aas

    Hi Jordi,

    Option A
    
    Option B & C

    
    Cheers,
    Ian