Subject: Re: [v6ops] New Version Notification for draft-ietf-v6ops-transition-ipv4aas-05.txt

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

Hi Med,

Our DHCPv6 individual draft was not progressing, however, this one seems to be in a different situation and may be adopted soon as a WG item.

We can anyway, have some more time to decide, depending on the ID progress and also the opinion of the reviewers that yesterday volunteered to check our document and the timing to go for the last-call, etc.

The alternative is to remove this, publish our document as an RFC when passes the last-call, then do a -bis version, but I feel a waste of time if both documents progress.

Regards,

Jordi

-----Mensaje original-----

De: v6ops <[email-masked]> en nombre de <[email-masked]>

Fecha: viernes, 20 de julio de 2018, 10:08

Para: JORDI PALET MARTINEZ <jordi.palet=[email-masked]>, v6ops <[email-masked]>

Asunto: Re: [v6ops] New Version Notification for draft-ietf-v6ops-transition-ipv4aas-05.txt

    Hi Jordi, 

    I disagree with including I-D.pref64folks-6man-ra-pref64 for the same reason the WG decided to removed your dhcp individual draft. 

    Please remove it from the draft. Thanks

    Cheers,

    Med

    > -----Message d'origine-----

    > De : v6ops [mailto:[email-masked]] De la part de JORDI PALET MARTINEZ

    > Envoyé : vendredi 20 juillet 2018 09:17

    > À : v6ops

    > Objet : Re: [v6ops] New Version Notification for draft-ietf-v6ops-transition-

    > ipv4aas-05.txt

    > Hi all,

    > Following yesterday discussion, I've posted a new version, removing G-1

    > (RFC7608).

    > Also, considering draft-pref64folks-6man-ra-pref64, we have included this

    > (after consulting with the chairs, as it is a time being an individual ID).

    > We have also included a very simple priority mechanism in case several NAT64

    > prefix discovery are available.

    > As we have free time today in the meeting, if somebody disagree with this,

    > please speak up and let's discuss it.

    > Thanks!

    > Here is the relevant text:

    >    464XLAT-4:  The IPv6 Transition CE Router MUST implement

    >                [I-D.pref64folks-6man-ra-pref64] (Discovering PREF64 in

    >                Router Advertisements) and [RFC7050] (Discovery of the

    >                IPv6 Prefix Used for IPv6 Address Synthesis) in order to

    >                discover the PLAT-side translation IPv4 and IPv6

    >                prefix(es)/suffix(es).

    >    464XLAT-7:  The priority for the NAT64 prefix, in case the network

    >                provides several choices, MUST be: 1) [RFC7225], 2)

    >                [RFC8115], 3) [I-D.pref64folks-6man-ra-pref64] and 4)

    >                [RFC7050].

    > Regards,

    > Jordi

    > -----Mensaje original-----

    > De: <[email-masked]>

    > Fecha: viernes, 20 de julio de 2018, 9:12

    > Para: Masanobu Kawashima <[email-masked]>, "Hans M.-H. Liu"

    > <[email-masked]>, Jordi Palet Martinez

    > <[email-masked]>, Jordi Palet

    > <[email-masked]>, Hans Liu <[email-masked]>

    > Asunto: New Version Notification for draft-ietf-v6ops-transition-ipv4aas-

    > 05.txt

    >     A new version of I-D, draft-ietf-v6ops-transition-ipv4aas-05.txt

    >     has been successfully submitted by Jordi Palet Martinez and posted to the

    >     IETF repository.

    >     Name:		draft-ietf-v6ops-transition-ipv4aas

    >     Revision:	05

    >     Title:		Requirements for IPv6 Customer Edge Routers to Support

    > IPv4 Connectivity as-a-Service

    >     Document date:	2018-07-20

    >     Group:		v6ops

    >     Pages:		21

    >     URL:            https://www.ietf.org/internet-drafts/draft-ietf-v6ops-

    > transition-ipv4aas-05.txt

    >     Status:         https://datatracker.ietf.org/doc/draft-ietf-v6ops-

    > transition-ipv4aas/

    >     Htmlized:       https://tools.ietf.org/html/draft-ietf-v6ops-transition-

    > ipv4aas-05

    >     Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-

    > transition-ipv4aas

    >     Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-

    > transition-ipv4aas-05

    >     Abstract:

    >        This document specifies the IPv4 service continuity requirements for

    >        an IPv6 Customer Edge (CE) router, either provided by the service

    >        provider or thru the retail market.

    >        Specifically, this document extends the "Basic Requirements for IPv6

    >        Customer Edge Routers" in order to allow the provisioning of IPv6

    >        transition services for the support of "IPv4 as-a-Service" (IPv4aaS)

    >        by means of new transition mechanisms.  The document only covers

    >        transition technologies for delivering IPv4 in IPv6-only access

    >        networks, commonly called "IPv4 as-a-Service" (IPv4aaS), as required

    >        in a world where IPv4 addresses are no longer available, so hosts in

    >        the customer LANs with IPv4-only or IPv6-only applications or

    >        devices, requiring to communicate with IPv4-only services at the

    >        Internet, are still able to do so.

    >     Please note that it may take a couple of minutes from the time of

    > submission

    >     until the htmlized version and diff are available at tools.ietf.org.

    >     The IETF Secretariat

    > **********************************************

    > 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.

    > _______________________________________________

    > v6ops mailing list

    > [email-masked]

    > https://www.ietf.org/mailman/listinfo/v6ops

    _______________________________________________

    v6ops mailing list

    [email-masked]

    https://www.ietf.org/mailman/listinfo/v6ops

**********************************************
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: <[email-masked]>
Date: Fri, 20 Jul 2018 14:21:04 +0000

Re-,

I do prefer to not have it and have whatever discussion. As a general rule, individual drafts should be removed from profile RFCs. Only stable specs should be listed.  

The RA proposal is a déjà vu. It was discussed in behave WG and the IETF consensus as documented in 7051 is to not recommend it.   

I reiterate my request to remove it from the draft. Thanks.

Cheers,
Med

> Envoyé : vendredi 20 juillet 2018 10:12
> À : v6ops
> Our DHCPv6 individual draft was not progressing, however, this one seems to
> be in a different situation and may be adopted soon as a WG item.
> 
> 
> 
> We can anyway, have some more time to decide, depending on the ID progress
> and also the opinion of the reviewers that yesterday volunteered to check our
> document and the timing to go for the last-call, etc.
> 
> 
> 
> The alternative is to remove this, publish our document as an RFC when passes
> the last-call, then do a -bis version, but I feel a waste of time if both
> documents progress.
> 
> 
> 
> Regards,
> 
> Jordi
> 
> 
> 
> 
> 
> 
> 
>     I disagree with including I-D.pref64folks-6man-ra-pref64 for the same
> reason the WG decided to removed your dhcp individual draft.
> 
> 
>

---

From: Fred Baker <[email-masked]>
Date: Fri, 20 Jul 2018 12:56:47 -0400

> On Jul 20, 2018, at 10:21 AM, [email-masked] wrote:
> 

I suspect the consensus has changed. The DNS model is seriously flawed: consider, for example, the case in which an ISP configures the AAAA record for ipv4only.arpa with a prefix other than the default one, a Public Resolver such as OpenDNS configures the default prefix or some third prefix, and a subscriber configures the use of the Public Resolver. The CLAT will request the translation prefix and get none or the wrong one, disabling CLAT service. We need a solution that is reliable and definitively gets the right Pref64 to the CLAT.

Using the RA does so, and a DHCP option would do so. DNS does not. If the IETF consensus is to use the DNS model, the community represented in dnsop isn't part of that consensus, and the operators in v6ops (as represented in the f2f discussion yesterday) are not. At minimum, that consensus needs to be revisited.