Subject: draft-pref64folks-6man-ra-pref64-00

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 19 Jul 2018 20:13:34 -0400

Hi all,

I've read this document, and I support it.

At the moment I've only a comment. RFC7051 analyzed the different solutions for learning the NAT64 prefix.

At that time, using RA (section 5.7) was considered, but obviously past the time it was published, now we have another view, and I don't agree with the summary neither the conclusion and decision driven by that document.

However, I think it will be very interesting to include some text to "rephrase" what was studied by RFC7051 and also to consider Issue #5 (supporting multiple NSPs).

May be something in the line of (I'm assuming that we support multiple NSPs):

---

Analysis of the Router Advertising option for learning the NAT64 prefix

A new Router Advertising option for learning the NAT64 prefix can solve all the Issues (#1 to #5) indicated in section 3 of RFC7051.

Despite what is indicated in RFC7051, and as demonstrated by the fact of a similar problem resolved with RFC8106 (IPv6 Router Advertisement Options for DNS Configuration), the following are non-problems:

- Configuration and management of all the access routers for this option.

- Operating systems supporting the new option.

- Update of the IPv6 stack to support this option.

- Update of the router configuration when the NSP is modified.

- Standardizing a new RA option (what this document is doing).

- Changes of network-side nodes not part of the NAT64 deployment.

- Providing the right NSP or multiple NSPs to specific nodes/access routers.

---

And maybe add some more text to each of the items to justify it.

Also, I think it may be not too much difficult to make it possible other choices different than 96 bits, so we avoid the discussion of if other choices are being used or not and we provide a single solution for all and there is no need to come back later on ...

We proposed an alternative for DHCPv6 some time ago, that may provide some ideas:

https://tools.ietf.org/html/draft-li-intarea-nat64-prefix-dhcp-option-01

I will be happy to keep providing inputs.

Regards,

Jordi

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
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: Lorenzo Colitti <[email-masked]>
Date: Fri, 20 Jul 2018 10:23:43 -0400

On Thu, Jul 19, 2018 at 8:14 PM JORDI PALET MARTINEZ <jordi.palet=
[email-masked]> wrote:

> However, I think it will be very interesting to include some text to
> "rephrase" what was studied by RFC7051 and also to consider Issue #5
> (supporting multiple NSPs).
>

Jordi,

thanks for the review.

After having read the description in RFC7051, I'm not sure what issue #5
actually is. The RFC mentions load-balancing by using different NSPs. It's
not clear to me what that means.

   - If it means sending different parts of the IPv4 space to different
   NAT64 devices, then that can be accomplished by routing more specifics of
   the NAT64 prefix to different NAT64 devices. -01 explicitly documents this
   and provides an example.
   - But that can be done pretty easily using ECMP load-balancing, which
   should work for both stateless NAT64 and stateful NAT64. -01 doesn't have
   an example of this because we assumed that that would be relatively obvious
   to a network deploying NAT64. But we could add it.

Also, the considerations in RFC 7051 led to the recommendation of using the
mechanism standardized in RFC 7050, and this new option maintains the same
semantics with regard to address synthesis.

I don't think there is a need to address all the considerations in RFC 7051
section 5.7.2 since at this point operational experience has pretty clearly
pointed out that the CONs are really not serious problems, and any networks
on which those problems are relevant can continue to use other options for
prefix discovery.

Cheers,
Lorenzo

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 20 Jul 2018 10:29:34 -0400

Hi Lorenzo,

I see your point about issue #5 and agree that routing and ECMP can solve it, but the example you mention will be good.

May be just some text to say that “actual operational experience vs RFC7051 considerations brings us to the following conclusions …”.

Regards,

Jordi

De: ipv6 <[email-masked]> en nombre de Lorenzo Colitti <lorenzo=[email-masked]>
Fecha: viernes, 20 de julio de 2018, 10:24
Para: <jordi.palet=[email-masked]>
CC: 6man <[email-masked]>
Asunto: Re: draft-pref64folks-6man-ra-pref64-00

On Thu, Jul 19, 2018 at 8:14 PM JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:

Jordi,

thanks for the review.

After having read the description in RFC7051, I'm not sure what issue #5 actually is. The RFC mentions load-balancing by using different NSPs. It's not clear to me what that means.

·         If it means sending different parts of the IPv4 space to different NAT64 devices, then that can be accomplished by routing more specifics of the NAT64 prefix to different NAT64 devices. -01 explicitly documents this and provides an example.

·         But that can be done pretty easily using ECMP load-balancing, which should work for both stateless NAT64 and stateful NAT64. -01 doesn't have an example of this because we assumed that that would be relatively obvious to a network deploying NAT64. But we could add it.

Also, the considerations in RFC 7051 led to the recommendation of using the mechanism standardized in RFC 7050, and this new option maintains the same semantics with regard to address synthesis.

I don't think there is a need to address all the considerations in RFC 7051 section 5.7.2 since at this point operational experience has pretty clearly pointed out that the CONs are really not serious problems, and any networks on which those problems are relevant can continue to use other options for prefix discovery.

Cheers,

Lorenzo

-------------------------------------------------------------------- IETF IPv6 working group mailing list [email-masked] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------