Subject: [v6ops] Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-02.txt

From: Lencse Gábor <[email-masked]>
Date: Thu, 24 Jan 2019 18:13:24 +0100

Dear v6ops Members,

We have revised our draft "Pros and Cons of IPv6 Transition Technologies 
for IPv4aaS" making significant changes including:

    o  Ian Farrer has joined us as an author.

    o  Restructuring: the description of the five IPv4aaS technologies
       was moved to a separate section.

    o  More details and figures were added to the description of the five
       IPv4aaS technologies.

    o  Section titled "High-level Architectures and their Consequences"
       has been completely rewritten.

    o  Several additions/clarification throughout Section titled
       "Detailed Analysis".

    o  Section titled "Performance Analysis" was dropped due to lack of
       results yet.

    o  Word based text ported to XML.

    o  Further text cleanups, added text on state sync and load
       balancing.  Additional comments inline that should be considered
       for future updates.

We kindly request your feedback.

Best regards,

Gábor Lencse

-------- Továbbított üzenet --------
Tárgy: 	New Version Notification for 
draft-lmhp-v6ops-transition-comparison-02.txt
Dátum: 	Thu, 24 Jan 2019 08:25:45 -0800
Feladó: 	[email-masked]
Címzett: 	Lee Howard <[email-masked]>, Jordi Palet Martinez 
<[email-masked]>, Ian Farrer <[email-masked]>, 
Jordi Palet <[email-masked]>, Gabor Lencse 
<[email-masked]>, Richard Patterson <[email-masked]>

A new version of I-D, draft-lmhp-v6ops-transition-comparison-02.txt
has been successfully submitted by Gabor Lencse and posted to the
IETF repository.

Name: draft-lmhp-v6ops-transition-comparison
Revision: 02
Title: Pros and Cons of IPv6 Transition Technologies for IPv4aaS
Document date: 2019-01-24
Group: Individual Submission
Pages: 23
URL: 
https://www.ietf.org/internet-drafts/draft-lmhp-v6ops-transition-comparison-02.txt
Status: 
https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/
Htmlized: 
https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-02
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-lmhp-v6ops-transition-comparison
Diff: 
https://www.ietf.org/rfcdiff?url2=draft-lmhp-v6ops-transition-comparison-02

Abstract:
Several IPv6 transition technologies have been developed to provide
customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only
access and/or core network. All these technologies have their
advantages and disadvantages, and depending on existing topology,
skills, strategy and other preferences, one of these technologies may
be the most appropriate solution for a network operator.

This document examines the five most prominent IPv4aaS technologies
considering a number of different aspects to provide network
operators with an easy to use reference to assist in selecting the
technology that best suits their needs.

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

---

From: Lencse Gábor <[email-masked]>
Date: Tue, 29 Jan 2019 21:47:35 +0100

Dear Med,

Thank you very much for your comments. Please, see my replies inline.

1/25/2019 9:13 AM keltezéssel, [email-masked] írta:
>
> Hi Gabor,
>
> Some quick comments on the draft:
>
> ·You indicate that tr69 is available for xlat provisioning, but I’m 
> not aware of any device model work done at BBF for xlat. The model 
> supports DS-Lite and MAP; I’m not sure for the other.
>

It will be addressed by Ian. (He has prepared the table.)

> ·For YANG, RFC8512 does support CLAT/NAT64. You may update the table 
> accordingly.
>

Thank you for mentioning that. Now, I have included it into the XML 
source. (And also deleted RFC 6050, which was a typo, I meant RFC 6020, 
the definition for YANG)

> ·Why DNS64 is listed in table 2?
>

I think, because it is often used together with 464 XLAT. (But Ian can 
tell, why he included it.)

> ·You may add pointer to rfc6889 when discussing NAT64/xlat matters 
> (section 3.2)
>

It seems to be a good analysis. We will definitely include it.

> ·“In the centralized model” is not that accurate when talking about 
> CGNs, because distributed CGNs are deployed to avoid risks related to 
> centralized models.
>

Of course, we wanted to refer to the first one of the following two cases:

    o  Centralized Stateful NAPT44 (DS-Lite, 464XLAT)

    o  Distributed Stateful NAPT44 (lw4o6, MAP-E, MAP-T)

Which word would you recommend to use for that?

> ·PCP is required for NAT64 (section 4.3)
>

Would you agree with the following change?

    Port Control Protocol (PCP) [RFC6877  <https://tools.ietf.org/html/rfc6877>] provides a mechanism for a
    client to request an external public port from a CGN device and is
    supported in some DS-Lite AFTR implementations.

-->

    Port Control Protocol (PCP) [RFC6877  <https://tools.ietf.org/html/rfc6877>] provides a mechanism for a
    client to request an external public port from a CGN device*. For server operation, ***it is required* with NAT64/464XLAT, and it *is
    supported in some DS-Lite AFTR implementations.

> ·You may add some text about dyndns issues. For solutions making use 
> of PCP (dslite), a proposal is described in RFC7393
>

Thank you for mentioning that. We will include it, too.

> ·The logging part should be update to reflect that even when A+P is 
> deployed, some regulation in specific countries are requiring the full 
> 5-uple to be logged!
>

Do you mean that even if it is clear that a given port range for a given 
public IPv4 address is statically assigned to a given subscriber (and 
thus no one else can use it), the ISP still must track all the 
activities of the user (by logging the 5-tuple)?

If your answer is yes, then I have a question about the following:

    Stateless technologies that pre-allocate the IPv4 addresses and ports
    only require that copies of the active MAP rules (for MAP-E and MAP-
    T), or binding-table (for lw4o6) are retained along with timestamp
    information of when they have been active.  Support tools (e.g.,
    those used to serve data retention requests) may need to be updated
    to be aware of the mechanism in use (e.g., implementing the MAP
    algorithm so that IPv4 information can be linked to the IPv6 prefix
    delegated to a client).  As stateless technologies do not have a
    centralized stateful element which customer traffic needs to pass
    through, so if data retention laws mandate per-session logging, there
    is no simple way of meeting this requirement with a stateless
    technology alone.

Does the two statements together mean that the logging requirements of 
that countries may not be satisfied, when stateless technologies (e.g. 
MAP protocols) are used?

Best regards,

Gábor

>
> Cheers,
>
> Med
>
> *De :*v6ops [mailto:[email-masked]] *De la part de* Lencse Gábor
> *Envoyé :* jeudi 24 janvier 2019 18:13
> *À :* [email-masked] list
> *Objet :* [v6ops] Fwd: New Version Notification for 
> We have revised our draft "Pros and Cons of IPv6 Transition 
> Technologies for IPv4aaS" making significant changes including:
>
> *Tárgy: *
> New Version Notification for draft-lmhp-v6ops-transition-comparison-02.txt
>
> *Dátum: *
>
> 	
>
> Thu, 24 Jan 2019 08:25:45 -0800
>
> *Feladó: *
>
> 	
>
> [email-masked] <mailto:[email-masked]>
>
> *Címzett: *
>
> 	
>
> Lee Howard <[email-masked]> <mailto:[email-masked]>, Jordi Palet 
> Martinez <[email-masked]> 
> <mailto:[email-masked]>, Ian Farrer 
> <[email-masked]> <mailto:[email-masked]>, Jordi Palet 
> <[email-masked]> 
> <mailto:[email-masked]>, Gabor Lencse 
> <[email-masked]> <mailto:[email-masked]>, Richard Patterson 
> <[email-masked]> <mailto:[email-masked]>
>
>
>
>

---

From: Fred Baker <[email-masked]>
Date: Tue, 29 Jan 2019 15:25:16 -0800

> On Jan 29, 2019, at 12:47 PM, Lencse Gábor <[email-masked]> wrote:
> 
>> ·         Why DNS64 is listed in table 2?
> 
> I think, because it is often used together with 464 XLAT. (But Ian can tell, why he included it.)

I'm not Ian, but I can tell you that NAT64 deployments have the option to include it. 464XLAT deployments are likely to use other mechanisms such as RFC 7750.

--------------------------------------------------------------------------------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu

---

From: <[email-masked]>
Date: Wed, 30 Jan 2019 06:40:57 +0000

Hi Lencse,

Please see inline.

Cheers,
Med

De : v6ops [mailto:[email-masked]] De la part de Lencse Gábor
Envoyé : mardi 29 janvier 2019 21:48
À : [email-masked] list
Objet : Re: [v6ops] Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-02.txt

Dear Med,

Thank you very much for your comments. Please, see my replies inline.
1/25/2019 9:13 AM keltezéssel, [email-masked]<mailto:[email-masked]> írta:
Hi Gabor,

·         You indicate that tr69 is available for xlat provisioning, but I’m not aware of any device model work done at BBF for xlat. The model supports DS-Lite and MAP; I’m not sure for the other.

[Med] OK

·         For YANG, RFC8512 does support CLAT/NAT64. You may update the table accordingly.

Thank you for mentioning that. Now, I have included it into the XML source.
[Med] OK.

(And also deleted RFC 6050, which was a typo, I meant RFC 6020, the definition for YANG)
[Med] You may then add a pointer to RFC7950.

I think, because it is often used together with 464 XLAT. (But Ian can tell, why he included it.)
[Med] OK, thanks. Let’s wait for Ian to clarify.

·         You may add pointer to rfc6889 when discussing NAT64/xlat matters (section 3.2)

·         “In the centralized model” is not that accurate when talking about CGNs, because distributed CGNs are deployed to avoid risks related to centralized models.

[Med] I’m not sure 464xlat can be listed as “Centralized Stateful NAPT44”

[Med] I would avoid both and use “A+P” vs. “CGN-based approaches”. CGN-based address sharing can be deployed in both centralized and distributed schemes.

·         PCP is required for NAT64 (section 4.3)

   Port Control Protocol (PCP) [RFC6877<https://tools.ietf.org/html/rfc6877>] provides a mechanism for a

-->

   Port Control Protocol (PCP) [RFC6877<https://tools.ietf.org/html/rfc6877>] provides a mechanism for a

   client to request an external public port from a CGN device. For server operation, it is required with NAT64/464XLAT, and it is

[Med] Works for me. Thank you.

·         You may add some text about dyndns issues. For solutions making use of PCP (dslite), a proposal is described in RFC7393

Thank you for mentioning that. We will include it, too.
[Med] Great. I assume the discussion will cover all schemes.

·         The logging part should be update to reflect that even when A+P is deployed, some regulation in specific countries are requiring the full 5-uple to be logged!

Do you mean that even if it is clear that a given port range for a given public IPv4 address is statically assigned to a given subscriber (and thus no one else can use it), the ISP still must track all the activities of the user (by logging the 5-tuple)?
[Med] Yes. Please refer to https://mailarchive.ietf.org/arch/msg/softwires/a5oyA20hGRWlZM6LXfktJYDKcok

   technology alone.

Does the two statements together mean that the logging requirements of that countries may not be satisfied, when stateless technologies (e.g. MAP protocols) are used?

[Med] For these countries, a “glue” is needed at BRs.

Best regards,

Gábor

·

Cheers,
Med

De : v6ops [mailto:[email-masked]] De la part de Lencse Gábor
Envoyé : jeudi 24 janvier 2019 18:13
À : [email-masked]<mailto:[email-masked]> list
Objet : [v6ops] Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-02.txt

Dear v6ops Members,

We have revised our draft "Pros and Cons of IPv6 Transition Technologies for IPv4aaS" making significant changes including:

      IPv4aaS technologies.

      "Detailed Analysis".

      results yet.

      for future updates.

Gábor Lencse

-------- Továbbított üzenet --------
Tárgy:

Dátum:

Feladó:

[email-masked]<mailto:[email-masked]>

Címzett:

Lee Howard <[email-masked]><mailto:[email-masked]>, Jordi Palet Martinez <[email-masked]><mailto:[email-masked]>, Ian Farrer <[email-masked]><mailto:[email-masked]>, Jordi Palet <[email-masked]><mailto:[email-masked]>, Gabor Lencse <[email-masked]><mailto:[email-masked]>, Richard Patterson <[email-masked]><mailto:[email-masked]>

Name: draft-lmhp-v6ops-transition-comparison
Revision: 02
Title: Pros and Cons of IPv6 Transition Technologies for IPv4aaS
Document date: 2019-01-24
Group: Individual Submission
Pages: 23
URL: https://www.ietf.org/internet-drafts/draft-lmhp-v6ops-transition-comparison-02.txt
Status: https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparison/
Htmlized: https://tools.ietf.org/html/draft-lmhp-v6ops-transition-comparison-02
Htmlized: https://datatracker.ietf.org/doc/html/draft-lmhp-v6ops-transition-comparison
Diff: https://www.ietf.org/rfcdiff?url2=draft-lmhp-v6ops-transition-comparison-02

Abstract:

The IETF Secretariat

---

From: tom petch <[email-masked]>
Date: Wed, 30 Jan 2019 10:16:08 +0000

Top posting one minor point.

YANG is RFC7950 unless you particularly want the previous version.

Tom Petch

----- Original Message -----
From: "Lencse Gábor" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, January 29, 2019 8:47 PM

>     Port Control Protocol (PCP) [RFC6877
<https://tools.ietf.org/html/rfc6877>] provides a mechanism for a
>     Port Control Protocol (PCP) [RFC6877
<https://tools.ietf.org/html/rfc6877>] provides a mechanism for a
>     client to request an external public port from a CGN device*. For
server operation, ***it is required* with NAT64/464XLAT, and it *is
> > New Version Notification for
> > Group: Individual Submission
https://www.ietf.org/internet-drafts/draft-lmhp-v6ops-transition-compari
son-02.txt
> > Htmlized:
https://datatracker.ietf.org/doc/html/draft-lmhp-v6ops-transition-compar
ison
> > Diff:
https://www.ietf.org/rfcdiff?url2=draft-lmhp-v6ops-transition-comparison
-02
> > until the htmlized version and diff are available at tools.ietf.org.

------------------------------------------------------------------------
--------

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

---

From: Richard Patterson <[email-masked]>
Date: Wed, 30 Jan 2019 11:01:15 +0000

Hi Med,

On Wed, 30 Jan 2019 at 06:41, <[email-masked]> wrote:

>          The logging part should be update to reflect that even when A+P
> is deployed, some regulation in specific countries are requiring the full
> 5-uple to be logged!
>

I believe that we have already covered this concern with the following
statement in section 3.3, do you agree?

   However, it is also worth noting that if the data retention
   regulatory requirements in force mandate per-flow logging, then a
   centralised NAPT44 model may be the only way to meet this
   requirement.

Or would you prefer if we add another similar statement within the logging
section as well?

-Rich

---

From: <[email-masked]>
Date: Wed, 30 Jan 2019 13:21:48 +0000

Hi Richard,

I prefer to have the discussion included in one single place: Section 4.7.

I also suggest that logging section includes a discussion about deterministic NAT (for CGNs):  RFC 7422.

Thank you.

Cheers,
Med

De : Richard Patterson [mailto:[email-masked]]
Envoyé : mercredi 30 janvier 2019 12:01
À : BOUCADAIR Mohamed TGI/OLN
Cc : Lencse Gábor; [email-masked] list
Objet : Re: [v6ops] Fwd: New Version Notification for draft-lmhp-v6ops-transition-comparison-02.txt

Hi Med,

On Wed, 30 Jan 2019 at 06:41, <[email-masked]<mailto:[email-masked]>> wrote:

         The logging part should be update to reflect that even when A+P is deployed, some regulation in specific countries are requiring the full 5-uple to be logged!

I believe that we have already covered this concern with the following statement in section 3.3, do you agree?

   requirement.

Or would you prefer if we add another similar statement within the logging section as well?

-Rich