Subject: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-transition-ipv4aas-12: (with DISCUSS)

From: Suresh Krishnan <[email-masked]>
Date: Tue, 08 Jan 2019 20:42:53 -0800

Suresh Krishnan has entered the following ballot position for
draft-ietf-v6ops-transition-ipv4aas-12: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

* Section 3.2.1.

I do not see why the use of RFC8115 (464XLAT-6) is being mandated for the use
of 464XLAT. What is the intent of such a mandate? Especially, since the
uPrefix64 is used for address synthesis for SSM for IPv4 *sources* in the IPv6
domain. Given that IPv4 multicast support itself is only conditional in Section
4, I do not see a need at all for this MUST requirement. Can you please clarify?

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 09 Jan 2019 10:30:06 +0100

Hi Suresh,

You can implement RFC8115 even if there is no multicast support.

We were considering updating RFC8026 to support 464XLAT (which impacts on existing implementations). Then thru the WG discussion, and thanks to the inputs of a Med, co-author of both (RFC8026 and RFC8115), we discovered that we can use this alternative (with zeroed ASM_mPrefix64 and SSM_mPrefix64). This choice doesn't impact on existing implementations.

You can probably better understand this change if you look at v02 (search for RFC8026 and the IANA section, and compare with the actual version 12):
https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/02/?include_text=1

This avoids a new DHCPv6 option for the NAT64 prefix discovery, which failed in previous INT-AREA attempts:
https://tools.ietf.org/html/draft-li-intarea-nat64-prefix-dhcp-option-01

The background is that we need to make sure that:
1) ISP has several choices to offer the NAT64 prefix.
2) They work even if the user changes the DNS servers.
3) The ISP is able to control the priority of the transition mechanism being used.

One more consideration, is that in general the CEs considered by this document, already have multicast support (even if is not needed for implementing RFC8115), as they are becoming more frequently used in services including IPTV support.

So, in summary, implementing or not multicast support, is not related to the implementation of RFC8115 (just a simple DHCPv6 option) which is used here for discovering the NAT64 prefix and allowing the prioritization of the transition mechanisms, avoiding updating other IETF documents and waiting for the IETF to approve a new standard DHCPv6 option specific for the NAT64.

Please, let me know if this clarifies your discuss, or do you need some more info.

Thanks!

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Suresh Krishnan <[email-masked]>
Fecha: miércoles, 9 de enero de 2019, 5:43
Para: The IESG <[email-masked]>
CC: <[email-masked]>, <[email-masked]>, <[email-masked]>
Asunto: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-transition-ipv4aas-12: (with DISCUSS)

    
    
    * Section 3.2.1.

    
    
    _______________________________________________
    v6ops mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/v6ops

**********************************************
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: Lorenzo Colitti <[email-masked]>
Date: Wed, 9 Jan 2019 18:54:26 +0900

On Wed, Jan 9, 2019 at 6:31 PM JORDI PALET MARTINEZ <jordi.palet=
[email-masked]> wrote:

> So, in summary, implementing or not multicast support, is not related to
> the implementation of RFC8115 (just a simple DHCPv6 option) which is used
> here for discovering the NAT64 prefix and allowing the prioritization of
> the transition mechanisms, avoiding updating other IETF documents and
> waiting for the IETF to approve a new standard DHCPv6 option specific for
> the NAT64.
>

Jordi: per my recollection, IIRC the reason there is no DHCPv6 option to
specify the NAT64 prefix is that there was no consensus to define a way to
provision the NAT64 prefix via DHCPv6. (In fact, I think I remember you
presenting such an option a few IETFs ago and receiving pretty negative
opinions on it from the mike line.) If that's the case, then it's not
appropriate to ignore that lack of consensus and essentially define such an
option anyway.

It's not even clear to me how an informational document (which this is) can
take RFC 8115 (which is a standards track document) and redefine the
uPrefix64 field to mean a unicast prefix. RFC 8115 clearly defines
uPrefix64 as not representing standard unicast addresses:

   uPrefix64:  this field identifies the IPv6 unicast prefix to be used
      in SSM mode for constructing the IPv4-embedded IPv6 addresses
      representing the IPv4 multicast sources in the IPv6 domain.

Standards track documents have precedence over informational documents,
right? If so, then even if this informational document is published as is,
the text will effectively be a no-op because it contradicts RFC 8115.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 09 Jan 2019 11:00:39 +0100

Hi Lorenzo,

Yes, I recall that very well. The only objections where from you and from David.

We are using a format that is not defined in RFC8115 for something else. It is a trick, right, but is not contradicting neither changing any standard, because the configuration of the two zeroed fields.

Regards,

Jordi

De: v6ops <[email-masked]> en nombre de Lorenzo Colitti <lorenzo=[email-masked]>
Fecha: miércoles, 9 de enero de 2019, 10:55
Para: JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
CC: "[email-masked] WG" <[email-masked]>, <[email-masked]>, <[email-masked]>, Suresh Krishnan <[email-masked]>, The IESG <[email-masked]>
Asunto: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-transition-ipv4aas-12: (with DISCUSS)

On Wed, Jan 9, 2019 at 6:31 PM JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:

Jordi: per my recollection, IIRC the reason there is no DHCPv6 option to specify the NAT64 prefix is that there was no consensus to define a way to provision the NAT64 prefix via DHCPv6. (In fact, I think I remember you presenting such an option a few IETFs ago and receiving pretty negative opinions on it from the mike line.) If that's the case, then it's not appropriate to ignore that lack of consensus and essentially define such an option anyway.

It's not even clear to me how an informational document (which this is) can take RFC 8115 (which is a standards track document) and redefine the uPrefix64 field to mean a unicast prefix. RFC 8115 clearly defines uPrefix64 as not representing standard unicast addresses:

Standards track documents have precedence over informational documents, right? If so, then even if this informational document is published as is, the text will effectively be a no-op because it contradicts RFC 8115.

_______________________________________________ v6ops mailing list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 9 Jan 2019 19:06:58 +0900

It *is* contradicting the standard. The standard says that the uPrefix64 is
"to be used in SSM mode for constructing the IPv4-embedded IPv6 addresses
representing the IPv4 multicast sources in the IPv6 domain". This document
says that it should be used as a unicast NAT64 prefix.

On Wed, Jan 9, 2019 at 7:01 PM JORDI PALET MARTINEZ <jordi.palet=
[email-masked]> wrote:

> We are using a format that is not defined in RFC8115 for something else.
> It is a trick, right, but is not contradicting neither changing any
> standard, because the configuration of the two zeroed fields.
>
>
> Regards,
>
> Jordi
>
>
>
>
>
>
>
> *De: *v6ops <[email-masked]> en nombre de Lorenzo Colitti
> <lorenzo=[email-masked]>
> *Fecha: *miércoles, 9 de enero de 2019, 10:55
> *Para: *JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
> *CC: *"[email-masked] WG" <[email-masked]>, <
> [email-masked]>, <[email-masked]>,
> Suresh Krishnan <[email-masked]>, The IESG <[email-masked]>
> *Asunto: *Re: [v6ops] Suresh Krishnan's Discuss on
> draft-ietf-v6ops-transition-ipv4aas-12: (with DISCUSS)
>
>
>
> It's not even clear to me how an informational document (which this is)
> can take RFC 8115 (which is a standards track document) and redefine the
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>
> 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: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 09 Jan 2019 11:09:44 +0100

Only if the other two fields are zeroed, which is a case not defined in the standard. At least that’s my understanding.

Regards,

Jordi

De: v6ops <[email-masked]> en nombre de Lorenzo Colitti <lorenzo=[email-masked]>
Fecha: miércoles, 9 de enero de 2019, 11:08
Para: JORDI PALET MARTINEZ <jordi.palet=[email-masked]>
CC: "[email-masked] WG" <[email-masked]>, <[email-masked]>, <[email-masked]>, Lorenzo Colitti <lorenzo=[email-masked]>, The IESG <[email-masked]>, Suresh Krishnan <[email-masked]>
Asunto: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-transition-ipv4aas-12: (with DISCUSS)

It *is* contradicting the standard. The standard says that the uPrefix64 is "to be used in SSM mode for constructing the IPv4-embedded IPv6 addresses representing the IPv4 multicast sources in the IPv6 domain". This document says that it should be used as a unicast NAT64 prefix.

On Wed, Jan 9, 2019 at 7:01 PM JORDI PALET MARTINEZ <jordi.palet=[email-masked]> wrote:

Hi Lorenzo,

Regards,

Jordi

---

From: Ole Troan <[email-masked]>
Date: Wed, 9 Jan 2019 11:21:11 +0100

> It *is* contradicting the standard. The standard says that the uPrefix64 is "to be used in SSM mode for constructing the IPv4-embedded IPv6 addresses representing the IPv4 multicast sources in the…

I must agree with Lorenzo here.
This is not the right document to specify a new NAT64 prefix discovery mechanism.

Ole

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 14 Jan 2019 11:01:48 +0100

Hi all,

We just submitted a new version, which I think address all the discuss and comments (some of them were clarifications that were provided by email responses to the IESG).

This included removing the reference to RFC8115 as a DHCP method to obtain the NAT64 prefix.

That means that this can only be done by PCP/RFC7225 (if available) or RFC7050.

https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/?include_text=1

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Ole Troan <[email-masked]>
Fecha: miércoles, 9 de enero de 2019, 11:22
Para: Lorenzo Colitti <lorenzo=[email-masked]>
CC: "[email-masked] WG" <[email-masked]>, <[email-masked]>, <[email-masked]>, The IESG <[email-masked]>, JORDI PALET MARTINEZ <jordi.palet=[email-masked]>, Suresh Krishnan <[email-masked]>
Asunto: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-transition-ipv4aas-12: (with DISCUSS)

    
    Ole