Subject: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-03.txt

From: [email-masked]
Date: Fri, 15 Jun 2018 23:41:34 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations WG of the IETF.

        Title           : Requirements for IPv6 Customer Edge Routers to Support IPv4 Connectivity as-a-Service
        Authors         : Jordi Palet Martinez
                          Hans M.-H. Liu
                          Masanobu Kawashima
	Filename        : draft-ietf-v6ops-transition-ipv4aas-03.txt
	Pages           : 20
	Date            : 2018-06-15

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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-transition-ipv4aas/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-v6ops-transition-ipv4aas-03
https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-transition-ipv4aas-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-transition-ipv4aas-03

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sat, 16 Jun 2018 08:56:38 +0200

Hi all,

As indicated a couple of day ago, we have updated this document, so instead of an update of RFC8026 and a new option code, we only need to ask IANA to use a NAT64 existing one for the RFC8026 priority table.

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

Let's know any comments you have.

Thanks!

Regards,

Jordi

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

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

Fecha: sábado, 16 de junio de 2018, 8:43

Para: <[email-masked]>

CC: <[email-masked]>

Asunto: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-03.txt

                              Hans M.-H. Liu

                              Masanobu Kawashima

    	Pages           : 20

    	Date            : 2018-06-15

    Abstract:

    

    

    _______________________________________________

    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: Mon, 18 Jun 2018 12:26:25 +0000

Hi Jordi, 

FWIW, please find some comments to this draft at: 

pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-ietf-v6ops-transition-ipv4aas-03-rev%20Med.pdf 
doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-ietf-v6ops-transition-ipv4aas-03-rev%20Med.doc 

Cheers,
Med

> -----Message d'origine-----
> De : v6ops [mailto:[email-masked]] De la part de JORDI PALET MARTINEZ
> Envoyé : samedi 16 juin 2018 08:57
> À : [email-masked]
> Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-03.txt
> 
> Hi all,
> 
> 
> 
> As indicated a couple of day ago, we have updated this document, so instead
> of an update of RFC8026 and a new option code, we only need to ask IANA to
> use a NAT64 existing one for the RFC8026 priority table.
> 
> 
> 
> 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: Mon, 18 Jun 2018 19:05:08 +0200

Hi Med,

Thanks a lot for your inputs.

I've few comments:

1) The requirements language is the same as it was used in RFC7084. We believe it makes a lot of sense to follow that.

2) Some of the comments are related to the usage of expressions such as services vs servers, transition vs service continuity, etc. The authors consider that it is good to use those interchangeable wordings, because for example, if we don't mention transition, a reader may be confused understanding that this is not regarding transition but a new problem "service continuity". Anyway, we will take a look again into this, and also seek for other comments from the WG. 

3) Will clarify anything that doesn't parse easily from your inputs.

4) You're right regarding the numbering of new General and LAN requirements, there is no reason now to follow the numbering of RFC7084, we will start from 1.

5) We believe that it makes sense that in the DEFAULT config, according with the discussion in the list, transition is disabled, so we avoid possible conflicts, unless the ISP turns it on (following RFC8026) or the user (by means of GUI or CLI).

6) The code considerations section was requested in v6ops to be keep as part of the document, not an annex. We are happy to change that again if that's the WG decision.

We will wait a few extra days for any further inputs before submitting a new version (before the cut-off).

Thanks !

Regards,

Jordi

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

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

Fecha: lunes, 18 de junio de 2018, 14:27

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

CC: "[email-masked]" <[email-masked]>

Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-03.txt

    Hi Jordi, 

    Cheers,

    Med

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

    > ipv4aas/?include_text=1

    >     A New Internet-Draft is available from the on-line Internet-Drafts

    > directories.

    >             Title           : Requirements for IPv6 Customer Edge Routers to

    > Support IPv4 Connectivity as-a-Service

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

    > ipv4aas-03

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

    > submission

    v6ops mailing list

    [email-masked]

---

From: <[email-masked]>
Date: Tue, 19 Jun 2018 05:41:10 +0000

Hi Jordi, 

Please see inline. 

Cheers,
Med

> De : JORDI PALET MARTINEZ [mailto:[email-masked]]
> Envoyé : lundi 18 juin 2018 19:05
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : [email-masked]
> 1) The requirements language is the same as it was used in RFC7084. We
> believe it makes a lot of sense to follow that.
> 

[Med] My comment was about "Unlike other IETF documents,". As you mentioned, the core text is also in 7084 which is an IETF document! Please consider deleting that mention. 

> 
> 
> 2) Some of the comments are related to the usage of expressions such as
> services vs servers, transition vs service continuity, etc. The authors
> consider that it is good to use those interchangeable wordings, because for
> example, if we don't mention transition, a reader may be confused
> understanding that this is not regarding transition but a new problem
> "service continuity". Anyway, we will take a look again into this, and also
> seek for other comments from the WG.
> 
> 
> 
> 4) You're right regarding the numbering of new General and LAN requirements,
> there is no reason now to follow the numbering of RFC7084, we will start from
> 1.
> 
> 
> 
> 5) We believe that it makes sense that in the DEFAULT config, according with
> the discussion in the list, transition is disabled, so we avoid possible
> conflicts, unless the ISP turns it on (following RFC8026) or the user (by
> means of GUI or CLI).

[Med] RFC8026 assumes that corresponding options are requested. If a mechanism is disabled, I assume the corresponding DHCP option won't be included in the request to the server. TRANS-1 is problematic.

I still don't understand the expected behavior.

> 
> 
> 
> 6) The code considerations section was requested in v6ops to be keep as part
> of the document, not an annex. We are happy to change that again if that's
> the WG decision.
> 
> 
> 
>     pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/draft-
> ietf-v6ops-transition-ipv4aas-03-rev%20Med.pdf
> 
>     doc: https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-
> ietf-v6ops-transition-ipv4aas-03-rev%20Med.doc
> 
> 
> 
>     Cheers,
> 
>     Med
> 
> 
> 
> ipv4aas/

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 19 Jun 2018 13:39:55 +0200

Hi Med,

Responding below, in-line.

Regards,

Jordi

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

De: <[email-masked]>

Fecha: martes, 19 de junio de 2018, 7:41

Para: JORDI PALET MARTINEZ <[email-masked]>

Asunto: RE: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-03.txt

    Hi Jordi, 

    Please see inline. 

    Cheers,

    Med

I see now what you mean. Keeping only:

1.1.  Requirements Language - Special Note

   The key words "MUST", "MUST NOT",

   "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",

   "RECOMMENDED", "MAY", and "OPTIONAL" in this document are not used as

   described in RFC 2119 [RFC2119].  This document uses these keywords

   not strictly for the purpose of interoperability, but rather for the

   purpose of establishing industry-common baseline functionality.  As

   such, the document points to several other specifications to provide

   additional guidance to implementers regarding any protocol

   implementation required to produce a successful IPv6 Transition CE

   Router that interoperates successfully with a particular subset of

   currently deploying and planned common IPv6-only access networks.

I've also added (from RFC6092):

   Additionally, the key word "DEFAULT" is to be interpreted in this

   document as pertaining to a configuration as applied by a vendor,

   prior to the administrator changing it for its initial activation.

And changed in the document a couple of usages of default to DEFAULT, so it is more "visible".

Ok, I understand now your point and I believe we have both in mind the same behavior, but the text is not clear.

What we want is that:

1) The corresponding options for each supported transition mechanism are requested.

2) However, the mechanism is DISABLED at the time being (no packets forwarded yet, no routing entries, etc.).

3) Until the RFC8026 mechanisms decides which ones should be actually ENABLED.

4) Then the CE ENABLE those (and configures routing, starts forwarding, etc.).

At this way, if the ISP doesn't support *any* or don't want the CE to enable any, will be able to do it.

So, an alternative wording to clarify this:

TRANS-1:  All the supported transition mechanisms MUST be configured by

              DEFAULT by the IPv6 Transition CE Router via the relevant options 

	for each one, however they MUST be disabled until

	by means of TRANS-4, decides which ones are enabled/disabled.

and

TRANS-4:  The IPv6 Transition CE Router, following Section 1.4 of

             [RFC8026], MUST check for a valid match in

             OPTION_S46_PRIORITY, which will allow enabling/disabling

	each transition mechanism.

Also, maybe is better to change the order of the TRANS requirements so those two are following each other.

    > We will wait a few extra days for any further inputs before submitting a new

    > version (before the cut-off).

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

    > <[email-masked]>

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

    > MARTINEZ

    >     > Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-

    > 03.txt

    >     > As indicated a couple of day ago, we have updated this document, so

    > instead

    >     > of an update of RFC8026 and a new option code, we only need to ask IANA

    > to

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

    > [email-masked]>

    >     >             Title           : Requirements for IPv6 Customer Edge

    > Routers to

    >     >        This document specifies the IPv4 service continuity requirements

    > for

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

    > service

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

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

    > required

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

    > hosts in

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

    >     >     until the htmlized version and diff are available at

    > tools.ietf.org.

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

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

    >     > prohibited, will be considered a criminal offense, so you must reply to

    > the

---

From: <[email-masked]>
Date: Wed, 20 Jun 2018 06:43:02 +0000

Hi Jordi, 

Please see inline. 

Cheers,
Med

> Envoyé : mardi 19 juin 2018 13:40
>     [Med] My comment was about "Unlike other IETF documents,". As you
> mentioned, the core text is also in 7084 which is an IETF document! Please
> consider deleting that mention.
> 
> 
> 
> 
> 

[Med] OK. 

>     [Med] RFC8026 assumes that corresponding options are requested. If a
> mechanism is disabled, I assume the corresponding DHCP option won't be
> included in the request to the server. TRANS-1 is problematic.
> 
> 
> 

[Med] I would omit this step because this is the job of 8026.

> 	by means of TRANS-4, decides which ones are enabled/disabled.

[Med] Why not simply saying: The CE MUST request the relevant configuration option for each of supported mechanism. 

> 	each transition mechanism.

[Med] OK.

> two are following each other.

[Med] I would use this order: TRANS-3, TRANS-1, then TRANS-4.

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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 20 Jun 2018 10:15:39 +0200

Hi Med,

Thanks again!

Here is what I think we are converging:

TRANS-1:  The IPv6 Transition CE Router MUST support the DHCPv6 S46

             priority options described in [RFC8026] (Unified IPv4-in-

             IPv6 Softwire Customer Premises Equipment (CPE): A

             DHCPv6-Based Prioritization Mechanism).

TRANS-2:  The IPv6 Transition CE Router MUST have a GUI and/or CLI

             option to manually enable/disable each of the supported

             transition mechanisms.

TRANS-3:  The IPv6 Transition CE Router MUST request the relevant

             configuration options for each supported transition

             mechanisms, which MUST remain disabled at this step.

             OPTION_S46_PRIORITY, which will allow enabling a transition

             mechanism.

TRANS-5:  In order to allow the service provider to disable all the

             transition mechanisms, the IPv6 Transition CE Router MUST

             NOT enable any transition mechanisms if no match is found

             between the priority list and the candidate list.

", which MUST remain disabled at this step" in TRANS-3 is needed to make sure that none of them are enabled before RFC8026 rules are followed. According to the conversation in this list, some people was not clear that RFC8026 allows enabling or not a given transition mechanism, so this way we state it without doubts.

TRANS-5 is required because RFC8026 has a "MAY" if no match is found or there is an invalid option. In this case, we want to make sure that "no match" from an ISP means "I don't want any mechanism to be turned on".

Regards,

Jordi

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

Fecha: miércoles, 20 de junio de 2018, 8:43

    Hi Jordi, 

    Please see inline. 

    Cheers,

    Med

    > And changed in the document a couple of usages of default to DEFAULT, so it

    > is more "visible".

    [Med] OK. 

    >     > consider that it is good to use those interchangeable wordings, because

    >     > "service continuity". Anyway, we will take a look again into this, and

    > also

    >     > 4) You're right regarding the numbering of new General and LAN

    > requirements,

    >     > there is no reason now to follow the numbering of RFC7084, we will

    > start from

    >     > 5) We believe that it makes sense that in the DEFAULT config, according

    > with

    >     > the discussion in the list, transition is disabled, so we avoid

    > possible

    >     > conflicts, unless the ISP turns it on (following RFC8026) or the user

    > (by

    > Ok, I understand now your point and I believe we have both in mind the same

    > behavior, but the text is not clear.

    > 1) The corresponding options for each supported transition mechanism are

    > requested.

    > 2) However, the mechanism is DISABLED at the time being (no packets forwarded

    > yet, no routing entries, etc.).

    > 3) Until the RFC8026 mechanisms decides which ones should be actually

    > ENABLED.

    > 4) Then the CE ENABLE those (and configures routing, starts forwarding,

    > etc.).

    > At this way, if the ISP doesn't support *any* or don't want the CE to enable

    > any, will be able to do it.

    >               DEFAULT by the IPv6 Transition CE Router via the relevant

    > options

    [Med] OK.

    > Also, maybe is better to change the order of the TRANS requirements so those

    > two are following each other.

    >     > 6) The code considerations section was requested in v6ops to be keep as

    > part

    >     > of the document, not an annex. We are happy to change that again if

    > that's

    >     > We will wait a few extra days for any further inputs before submitting

    > a new

    >     > Asunto: Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-

    >     >     pdf: https://github.com/boucadair/IETF-Drafts-

    > Reviews/blob/master/draft-

    >     >     doc: https://github.com/boucadair/IETF-Drafts-

    > Reviews/raw/master/draft-

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

    > PALET

    >     >     > Objet : Re: [v6ops] I-D Action: draft-ietf-v6ops-transition-

    > ipv4aas-

    >     >     > As indicated a couple of day ago, we have updated this document,

    > so

    >     >     > of an update of RFC8026 and a new option code, we only need to

    > ask IANA

    >     >     > Asunto: [v6ops] I-D Action: draft-ietf-v6ops-transition-ipv4aas-

    >     >     >     A New Internet-Draft is available from the on-line Internet-

    > Drafts

    >     >     >     This draft is a work item of the IPv6 Operations WG of the

    > IETF.

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

    >     >     >        This document specifies the IPv4 service continuity

    > requirements

    >     >     >        Specifically, this document extends the "Basic

    > Requirements for

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

    > of

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

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

    > so

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

    > or

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

    > at the

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

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

    > transition-

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

    > transition-

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

    > time of

    >     >     > This electronic message contains information which may be

    > privileged or

    >     >     > confidential. The information is intended to be for the exclusive

    > use

    >     >     > copying, distribution or use of the contents of this information,

    > even

    >     >     > partially, including attached files, is strictly prohibited and

    > will be

    >     >     > considered a criminal offense. If you are not the intended

    > recipient be

    >     >     > that any disclosure, copying, distribution or use of the contents

    > of

    >     >     > information, even if partially, including attached files, is

    > strictly

    >     >     > prohibited, will be considered a criminal offense, so you must

    > reply to