Subject: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion

From: Fred Baker <[email-masked]>
Date: Sat, 14 Apr 2018 22:00:40 -0700

At IETF 101, Jordi Palet Martinez presented draft-palet-v6ops-transition-ipv4aas. The draft is at https://tools.ietf.org/html/draft-palet-v6ops-transition-ipv4aas, and his presentation deck is at https://datatracker.ietf.org/meeting/101/materials/slides-101-v6ops-transition-requirements-for-ipv6-ce-routers-to-support-ipv4-as-a-service-00.

I would like to invite discussion.

In particular, this draft derives from draft-ietf-v6ops-rfc7084-bis, and the chairs wonder if it should be reposted as the next version of draft-ietf-v6ops-rfc7084-bis. That should happen if an only if the working group thinks it should be published as an RFC (now or at some point) adding considerations for implementors of RFC 7084 and also implementing transition services.

A key comment at IETF 101 was that there remain far too many transition mechanisms listed. It would be helpful, if you hold that opinion, if you could give that advice, identify the mechanism or mechanisms you think should be listed, and indicate the reasoning behind your viewpoint. For example, if you think MAP-T should be listed, it would be helpful to know what operators are implementing MAP-T and are looking for CE Routers that support it. The same comment applies to any such mechanism or service.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Sun, 15 Apr 2018 11:16:39 +0200

Hi Fred, all,

My comments regarding this.

RFC7084 had only 2 transition mechanisms, DS-Lite and 6RD.

draft-palet-v6ops-transition-ipv4aas has 4:
1) lw4o6: Basically, in terms of code, this is a "subset of DS-LITE", so if DS-Lite and IPv4 NAT support is already implemented, lw4o6 is also "there".
2) 464XLAT MAP-T and MAP-E. They also share most of the code already implemented for the previous ones.

This is explained in section 7 of the document, as it was requested during previous discussions in the draft-ietf-v6ops-rfc7084-bis and "follow-up" docs.

Last, but not least, because this document follow the same structure regarding the transitions mechanisms as RFC7084, the document doesn't mandate any of them. It is just saying, "if you want to implement this transition, remember that in addition to RFCxxx, you need to do this and that".

>From that perspective, I don't think the comment "too many" is a valid one. In fact we could add more, and be in the same situation: the document is not mandating any of them. I recall I responded to that question in the last meeting and was not "contra-argued" on that.

Regarding the question of if there are deployments on each of those, yes, probably fewer on MAP-E/T that the other two, but they are big.

During the discussion on draft-ietf-v6ops-rfc7084-bis, it was confirmed in the list by several voices, hopefully they can confirm again and I'm sure there are many others, for example for the case of lw4o6, I recall this email from DT group:

https://www.ietf.org/mail-archive/web/v6ops/current/msg25227.html, which mentions 1.5 million users.

I'm aware of similar other cases with each of those mechanisms, even with several millions users.

What we, unfortunately, aren't going to get here, is the voices of small ISPs (500-10.000 customers), which I know a few of them as well, which are asking their CE vendors for this support, and the response is "not in RFC7084") and they aren't "big" enough (each of them), to ask for that in a tender, specially because in most of the cases, they just go to the retail market and buy 10 units each week (last week I got a couple of cases on that in Spain, during the ESNOG, considering lw4o6 or 464XLAT).

Another example is:
https://mailarchive.ietf.org/arch/msg/v6ops/GvBFbzn32pP5x02UbB_7E3B12SQ

In my survey about IPv6 deployment (only residential, no corporate, no cellular), with over 1.520 responses up to now, I got 3% with 464XLAT, 1% for lw4o6, 1% for MAP-E, 1% for MAP-T. For comparision, 6rd was 3%, softwires 1%, tunnel broker 3%, dual-stack with CGN 8%, DS-LITE 3%, dual-stack with public IPv4 71%.

Just comparing a single "pair", 6rd with 464XLAT, I think it is easy to conclude that they are at the same level. There was a time for 6rd and DS-Lite, time is now for successors which allow "IPv6-only" access.

I'm sure my co-author, a CE vendor, can also provide more details on all this from a vendors perspective and what they heard from customers/market.

So clearly, I think that being this document a "follow-up", as instructed by the v6ops WG, after having adopted as WG item RFC7084-bis, we should do the same with this document.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Fred Baker <[email-masked]>
Fecha: domingo, 15 de abril de 2018, 7:00
Para: V6 Ops List <[email-masked]>
Asunto: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion

    

    _______________________________________________
    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: Richard Patterson <[email-masked]>
Date: Tue, 17 Apr 2018 20:20:24 +0100

Hi Fred, et al.

Speaking as an Operator who is currently validating MAP-T as a
solution, I'm in favour of making sure it itself is included in future
versions of this draft.

There are multiple vendors offering MAP-T Border Relays, and we've
been testing both OpenWRT-based CPEs as well as a custom CPE based on
the Broadcom BCM63138 SoC.
The Broadcom reference SDK comes with the CERNET kernel module and
userland tool, and supports hardware acceleration of MAP-T translated
flows with Broadcom's Runner fastpath.

I was also quite impressed with OpenWRT's implementation; aside from
initially needing internet connectivity to install the map-t module
after a fresh install, no further configuration is required to have
the CPE dynamically configure itself with MAP-T, given the appropriate
DHCPv6 options.  Kudos to the OpenWRT/LEDE devs on their support.

Re: the draft's §5.3.4.  It's succinct enough, whilst still directing
implementors to the relevant RFCs, however I'm still mulling over the
NAT44 and iptables/netfilter concerns that I raised in softwires a few
months back.[1]   The address-sharing mode's algorithm for port
allocations, isn't easily implementable with the current
iptables/netfilter behaviour.  OpenWRT's approach creates rule
shadowing and port ranges that never get utilised.

-Richard

[1] https://www.ietf.org/mail-archive/web/softwires/current/msg06832.html

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 17 Apr 2018 21:29:57 +0200

Hi Richard,

Thanks for the input!

Regarding your comment on the NAT44 iptables/netfilter ... Do you think this is something that can be mention/sorted out by some specific text in my ID ?

I'm guessing it will apply to both MAP-T and MAP-E, not sure if in the same way, but we can have some text to at least make sure implementors sort it out, without the need to update the relevant RFCs. Or do you think they should be updated (which open a another can of worms maybe ...).

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Richard Patterson <[email-masked]>
Fecha: martes, 17 de abril de 2018, 21:21
Para: V6 Ops List <[email-masked]>
Asunto: Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion

    Hi Fred, et al.

    

    -Richard

---

From: Fred Baker <[email-masked]>
Date: Tue, 17 Apr 2018 13:32:03 -0700

Let me ask an additional question. We have had at least one operator speak against adoption of this draft as a working group draft, because she doesn't want to add requirements to customer-edge (CE) routers, which potentially make them more complex and therefore expensive (every line of code costs something and has some probability of containing a bug or attack). It sounds like you would support adoption of the draft if it contains the right set of features and doesn't contain anything else, and if (as it is currently written) that it would be implemented in addition to RFC 7084. "The right set of features", from your perspective, includes MAP-T.

Is that a correct deduction?

> On Apr 17, 2018, at 12:20 PM, Richard Patterson <[email-masked]> wrote:
> 
> Hi Fred, et al.
>

---

From: Richard Patterson <[email-masked]>
Date: Tue, 17 Apr 2018 21:58:41 +0100

Yes that's a fair assessment.

I believe the current use of SHOULD for the transition technologies
allows flexibility to those with the aforementioned concerns that
would be OK with a limited sub-set, whilst still providing overall
guidance to those wishing for complete compliance.
Although does this also mean that it's possible for a CE to comply
with this draft, yet not implement any method under §5.3?

-Richard

---

From: Fred Baker <[email-masked]>
Date: Tue, 17 Apr 2018 16:01:46 -0700

> On Apr 17, 2018, at 1:58 PM, Richard Patterson <[email-masked]> wrote:
> 

You're correct. There is more than one way people use "SHOULD"; "MUST" is a lot like its dictionary definition. I use "SHOULD" to mean "I'd like to say 'MUST', but I think there is a case in which the implementer might legitimately choose not to", which is pretty much what the RFC says. What an implementer often does, though, is decide that "SHOULD" makes something optional, and does only what MUST be done.

That said, this kind of RFC is commenting on market requirements. In the final analysis, each company or implementer has to determine what market they are trying to address, and what its requirements are; they are going to read this document, but it's one of many inputs they will consider. If they are designing a product for the MAP-T market, they're going to do what 5.3 says. If they are designing for ONLY the MAP-E market (which basically differs from MAP-T in a subroutine call), they could probably convince themselves to leave MAP-T out entirely. I tend to think the document should be very explicit about claims of compliance to it - something like "if an implementation claims compliance with this document, it must implement every MUST, and either implement every SHOULD or say which ones it does not implement, and why." "That feature is in the next release, assuming of course someone offers to pay for its development" is a common dodge from vendors, and needs to be explicitly not OK.

Of course, you've never heard a vendor say that. Neither have I. But I have heard rumors...

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 18 Apr 2018 08:49:01 +0200

Hi Fred,

I'm happy to do that way in a new version.

Maybe we should do that already as WG item, unless there are major objections for that?

Regards,
Jordi

---

From: Lee Howard <[email-masked]>
Date: Wed, 18 Apr 2018 14:17:31 -0400

I think this document is needed.

When ISPs buy equipment for customers, they can specify which set of 
features they want.

When customers buy their own equipment, they can choose from whatever is 
on the shelf.

In order to effect a transition to IPv6, customer edge routers will need 
to support transition mechanisms. Since a CE router manufacturer can't 
know which transition mechanism will be used by any/all ISPs in the 
market where it will need to be sold, they will need to support the most 
likely mechanisms.

So, this document specifies behavior for retail-marketed devices, not 
buyer-specified devices. If an ISP wants fewer features to save cost or 
for security, she may specify that. It means that CE router is less 
likely to work if the consumer takes it to a competitor ISP, but I can 
live with that.

Comments on the document:

Introduction, Paragraph 3:

It's a run-on sentence that makes the features sound unnecessary until 
there is an IPv6-only network in place. Since CE routers have a lifetime 
of 7-15 years, I think that's too late. Suggest rewording it to:

This document covers the IP transition technologies required when
    ISPs have an IPv6-only access network. This is a
    common situation in a world where IPv4 addresses are no longer
    available, so the service providers need to provision IPv6-only WAN
    access. At the same time, they need to ensure that both IPv4-only and
    IPv6-only devices or applications in the customer networks, can still
    reach IPv4-only devices or applications in the Internet.

Paragraph 7:
Based on my comments above, I would like to reword this paragraph to:

    Service providers who specify feature sets for CE routers may specify
    a different set of features than those included in this document.
    Since it is impossible to know prior to sale which transition
    mechanism a device will need over the lifetime of the device, IPv6 CE
    transition routers intended for the retail market must support all
    of them.

I agree with the note in 1.1 Requirements Language, but almost glossed 
over it because it looks at first like RFC2119 boilerplate. Maybe revise 
the heading to "Requirements Language - Special Note"? Also, 
"preferable" should be "preferably."

I'm using the same language in comments that you do in the document, but 
"IPv6 transition Customer Edge Router with IPv4aaS" is long, and even 
the shortened version is cumbersome. Can we revise the terminology to 
say that "CE Router" used in this document means "a Customer Edge router 
with support for IPv6 transition mechanisms," unless specified as "a CE 
Router without transition mechanism support"? Also, need to expand the 
acronym "IPv4aaS" and define it.

3. Usage Scenarios
I'm not sure this section is needed; I think you've successfully made 
this argument earlier in the document, and I think anyone with even a 
faint familiarity with the transition understand the points being made 
here. If you disagree and want to keep it:

Paragraph 1 nit:  "situation before described" -> "situation previously 
described" or "situation described above".

Paragraph 2 nit: "may be" -> "it may be that"

"customer churn. . . " would read better as:

    consumers may switch ISPs and use the same CE router with an ISP that
    provides IPv4-only and an ISP that provides IPv6 plus IPv4aaS.

Paragraph 3 nit: "it is required an IPv6 transition CE" -> "an IPv6 
transition CE is required that"

"accommodating to" -> "accommodate"

Remove "as it may be or not provided by the service provider"

I'd remove the sentence "Even may be a point..." Not only is it 
grammatically impenetrable, increasing competition isn't a goal of this 
document (or of the IETF, or operators, or CE vendors).

The "Moreover" paragraph:

    Moreover, because some services will remain IPv4-only for an
    undetermined time, and some service providers will remain IPv4-only
    for an undetermined period of time, IPv4 will be needed for an
    undetermined period of time. There will be a need for CEs
    with support "IPv4 as a Service" for an undetermined period of time.

As I said above, I don't think the numbered list is needed, especially 
when four of them are the same, and two others are the same. I don't 
know what "exporting services to the WAN" means. Does this just mean 
"allowing inbound connections"?

The "The main difference" paragraph seems to say that, but it doesn't 
quite. I think if you're going to sidestep the issue of allowing inbound 
connections, you need to be much more explicit about it. For instance:

    An IPv6 transition CE might allow inbound connections over IPv6,
    with appropriate firewall rules and DNS entries. Several IPv4aaS
    implementations do not allow for port forwarding to CE routers,
    and the configuration and troubleshooting of port forwarding may
    be complicated.

The "For example" paragraph adds no clarity. The number of users has no 
bearing on the functionality, at least as far as you've described.

Second-to-last paragraph: "aspects" should be "features"

I'd rewrite the sentence "In fact, in many cases" to:

    In fact, in many cases, the user must supply or may replace
    the IPv6 Transition CE router; this makes even more
    relevant that all the IPv6 Transition CE routers support the same
    requirements defined in this document.

Last paragraph of Section 3: "may have" -> "they may have"

Section 4. End-User Network Architecture
"precedent" -> "preceding"

"behind it" -> "upstream"

4th paragraph: "the latest" -> "that"
Although I'm not sure why PCP isn't part of the sentence with UPnP-IGD, 
and from the previous section, I thought you weren't going to discuss this.

The "Another consequence" paragraph seems to say that IPv4+NAT is a 
feature for address stability, but then falls silent on address 
stability in IPv6. I know you don't want to say ULA (and I don't want to 
make it a target for Lorenzo), but if you're going to say anything, you 
have to be honest about it.

"Many existing routers support dynamic routing."  What? Consumer Edge 
routers? That is not my experience at all, and if it were common, we 
could have avoided two years of fighting in Homenet.

In the requirements section, I would like to see every instance of an 
RFC number accompanied by the title of that RFC. It helps with context. 
Plus, every requirement needs text explaining why it is a requirement. 
Sections 5.1 and 5.2 do neither of those.

The first two sentences of 5.3 Transition Technologies Support... are 
broken up poorly. Suggest:

    The main target of this document is the support of IPv6-only WAN
    access. To enable legacy IPv4 functionality, this document also
    includes the support of IPv4-only devices and
    applications in the customers LANs, as well as IPv4-only services
    on the Internet. Thus, both IPv4-only and the IPv6-only devices
    inside the CE are able to reach the IPv4-only services.

It makes me wonder that we don't need a solution for IPv4-only devices 
to reach IPv6-only services/content on the Internet. I suppose the 
market means that's not required, and frankly I'm satisfied with EOLing 
IPv4-only devices as content moves to IPv4-meh. We could in theory 
include CLAT by itself?

I don't think IPv6 "Service Continuity" should be capitalized.

464XLAT-1

unless there is a match with a valid
                OPTION_S46_PRIORITY

Shouldn't the CE Router process those options in order, and once one 
works, stop? Wouldn't it be clearer to say it that was in TRANS-1, and 
not have to repeat it later?

464XLAT-3

In environments with PCP support

How do you know if there's PCP support?

Section 5.3.2 says "If DS-Lite is implemented, lw4o6 MUST be supported 
as well." Why?

I like sections 7 Code Considerations and 8 Security Considerations. You 
might mention the Security Considerations sections of each of the 
transition mechanism RFCs, too.

I would be in favor of removing the 6rd requirement implied by RFC7048. 
If anyone is planning 6rd deployments, I'd be very surprised.

Lee

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 18 Apr 2018 21:34:26 +0200

Hi Lee,

Thanks a lot for your comments.

I will review them in detail in a couple of days, in case there are other inputs, so we can work out a new version and hopefully publish already as WG item.

Anyway, I’ve read all them and I think I agree in most of them.

I’ve now only a few quick comments/question, in order to help with a good review of our actual text:
I think this document is also for small and medium ISPs, only big ones have the power to specify the set of features they need. Not sure if your second sentence disagree with that.
1.1 was taken from RFC7084. Do you think it will be better to use the standard RFC2119 boilerplate?
I think the usage scenarios is important to readers that may be don’t have a clear view on what is the CE we are talking about, and in fact it was requested in one of the previous v6ops presentations. Anyway, I will try to make it more “compressed”.
The “dynamic routing” comes from the original rfc7084, which turned into the rfc7084-bis. I will check that from all my version history on this document … and clarify or delete it.
I’m not 100% sure to understand your comment on the CLAT. I think one of the keys is to allow deploying IPv6-only access while users still can use devices in their LANs until they have incentives to replace them, otherwise, customers will complain when they get IPv6-only services (if using CLAT it is transparent for them). CLAT can provide a NAT46, but then we need a also DNS46 ? If I got you correctly, it is good that there is an incentive for replacing IPv4-only devices because at some point there may be IPv6-only services … so I think we should not make any new transition mechanism to solve that problem?
I think you mean “IPv4 service continuity” (not capitalized)
Regarding 6rd, you mean this document should update RFC7084 and remove 6rd requirements? I will agree on that …

Thanks!

Regards,

Jordi

De: v6ops <[email-masked]> en nombre de Lee Howard <[email-masked]>
Fecha: miércoles, 18 de abril de 2018, 20:18
Para: <[email-masked]>
Asunto: Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion

When ISPs buy equipment for customers, they can specify which set of features they want.

When customers buy their own equipment, they can choose from whatever is on the shelf.

In order to effect a transition to IPv6, customer edge routers will need to support transition mechanisms. Since a CE router manufacturer can't know which transition mechanism will be used by any/all ISPs in the market where it will need to be sold, they will need to support the most likely mechanisms.

So, this document specifies behavior for retail-marketed devices, not buyer-specified devices. If an ISP wants fewer features to save cost or for security, she may specify that. It means that CE router is less likely to work if the consumer takes it to a competitor ISP, but I can live with that.

It's a run-on sentence that makes the features sound unnecessary until there is an IPv6-only network in place. Since CE routers have a lifetime of 7-15 years, I think that's too late. Suggest rewording it to:
 
Paragraph 7:

I agree with the note in 1.1 Requirements Language, but almost glossed over it because it looks at first like RFC2119 boilerplate. Maybe revise the heading to "Requirements Language - Special Note"? Also, "preferable" should be "preferably."

I'm using the same language in comments that you do in the document, but "IPv6 transition Customer Edge Router with IPv4aaS" is long, and even the shortened version is cumbersome. Can we revise the terminology to say that "CE Router" used in this document means "a Customer Edge router with support for IPv6 transition mechanisms," unless specified as "a CE Router without transition mechanism support"? Also, need to expand the acronym "IPv4aaS" and define it.

3. Usage Scenarios
I'm not sure this section is needed; I think you've successfully made this argument earlier in the document, and I think anyone with even a faint familiarity with the transition understand the points being made here. If you disagree and want to keep it:

Paragraph 1 nit:  "situation before described" -> "situation previously described" or "situation described above".

Paragraph 3 nit: "it is required an IPv6 transition CE" -> "an IPv6 transition CE is required that"

I'd remove the sentence "Even may be a point..." Not only is it grammatically impenetrable, increasing competition isn't a goal of this document (or of the IETF, or operators, or CE vendors).

As I said above, I don't think the numbered list is needed, especially when four of them are the same, and two others are the same. I don't know what "exporting services to the WAN" means. Does this just mean "allowing inbound connections"?

The "The main difference" paragraph seems to say that, but it doesn't quite. I think if you're going to sidestep the issue of allowing inbound connections, you need to be much more explicit about it. For instance:

The "For example" paragraph adds no clarity. The number of users has no bearing on the functionality, at least as far as you've described.

4th paragraph: "the latest" -> "that"
Although I'm not sure why PCP isn't part of the sentence with UPnP-IGD, and from the previous section, I thought you weren't going to discuss this.

The "Another consequence" paragraph seems to say that IPv4+NAT is a feature for address stability, but then falls silent on address stability in IPv6. I know you don't want to say ULA (and I don't want to make it a target for Lorenzo), but if you're going to say anything, you have to be honest about it.

"Many existing routers support dynamic routing."  What? Consumer Edge routers? That is not my experience at all, and if it were common, we could have avoided two years of fighting in Homenet. 

In the requirements section, I would like to see every instance of an RFC number accompanied by the title of that RFC. It helps with context. Plus, every requirement needs text explaining why it is a requirement. Sections 5.1 and 5.2 do neither of those.

The first two sentences of 5.3 Transition Technologies Support... are broken up poorly. Suggest:

It makes me wonder that we don't need a solution for IPv4-only devices to reach IPv6-only services/content on the Internet. I suppose the market means that's not required, and frankly I'm satisfied with EOLing IPv4-only devices as content moves to IPv4-meh. We could in theory include CLAT by itself?

464XLAT-1  

unless there is a match with a valid
               OPTION_S46_PRIORITY
Shouldn't the CE Router process those options in order, and once one works, stop? Wouldn't it be clearer to say it that was in TRANS-1, and not have to repeat it later?

464XLAT-3 

Section 5.3.2 says "If DS-Lite is implemented, lw4o6 MUST be supported as well." Why?

I like sections 7 Code Considerations and 8 Security Considerations. You might mention the Security Considerations sections of each of the transition mechanism RFCs, too. 
 
I would be in favor of removing the 6rd requirement implied by RFC7048. If anyone is planning 6rd deployments, I'd be very surprised.

Lee

 

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

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 18 Apr 2018 22:01:27 +0200 (CEST)

> flows with Broadcom's Runner fastpath.

Just as a FYI, LW4o6 HW acceleration is now also supported on BCM63138.
This is a fairly recent addition but we have this working.

This is supported with regular Linux kernel userland tools such as 
iptables and the ip command to set up the tunneling.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Fred Baker <[email-masked]>
Date: Wed, 18 Apr 2018 15:40:22 -0700

> On Apr 18, 2018, at 11:17 AM, Lee Howard <[email-masked]> wrote:
> 

So, in addition to the authors, we have three people (Richard, Barbara, and Lee) that have said to the list that this document "is needed", by which I infer that they want it to be adopted as a working group document. That said, as I said to Fred Templin a few weeks ago, that isn't proof of a consensus.

The chairs would be interested to know how many do, and how many do not, want that to happen. If you have specific arguments, relevance to your part of the world, and so on, that's important too.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Thu, 19 Apr 2018 03:34:12 +0000

This is good work and will be helpful/beneficial  to organizations transitioning to IPv6.   

I am wondering why large enterprises are expressly excluded from the scope of the document.  

I support this as a WG document.  

Thanks

Mike

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Fred Baker
Sent: Wednesday, April 18, 2018 6:40 PM
To: V6 Ops List <[email-masked]>
Subject: Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion

The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.

---

From: Hans Liu <[email-masked]>
Date: Thu, 19 Apr 2018 12:13:40 +0800

Despite of the author role, I sincerely support this document as a product
manager of a CE router vendor.  Experience tells me it is almost impossible
to ask the programmers in my OEM vendors to read all related RFCs when I
want them to implement a new feature.  They are not IETFer so they may not
voice in the mailing list how useful and helpful a summary can facilitate
their works.  But I know they do appreciate summarized guidelines like RFC
7084. I don't think I could have had all my OEM vendorss to make qualified
IPv6 CE routers for IPv6 world launch without RFC 6204.

Sincerely,
Hans

On Thu, Apr 19, 2018 at 6:40 AM, Fred Baker <[email-masked]>
wrote:

> So, in addition to the authors, we have three people (Richard, Barbara,
> and Lee) that have said to the list that this document "is needed", by
> which I infer that they want it to be adopted as a working group document.
> That said, as I said to Fred Templin a few weeks ago, that isn't proof of a
> consensus.
>
> The chairs would be interested to know how many do, and how many do not,
> want that to happen. If you have specific arguments, relevance to your part
> of the world, and so on, that's important too.
>

-- 
Instead of following the fashion, we lead it through.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 19 Apr 2018 06:25:10 +0200 (CEST)

On Wed, 18 Apr 2018, Fred Baker wrote:

> want that to happen. If you have specific arguments, relevance to your 
> part of the world, and so on, that's important too.

I support this document to be adopted and just the way I think RFC7084 
helps ISPs formulate requirements and also get an overview of what's 
available and what behaviour the device should have in an easy all-in-one 
document, I think ipv4aas document would we worthwhile in this area.

I point to RFC7084 quite often in discussions, I imagine I will use the 
end product of this document in the same way.

---

From: Sander Steffann <[email-masked]>
Date: Thu, 19 Apr 2018 08:48:02 +0200

Hi,

> The chairs would be interested to know how many do, and how many do not, want that to happen. If you have specific arguments, relevance to your part of the world, and so on, that's important too.

I would like to see this draft adopted as a working group document. I recognise Hans' arguments from my discussions with other vendors.

Cheers,
Sander

---

From: Masanobu Kawashima <[email-masked]>
Date: Thu, 19 Apr 2018 13:14:51 +0000

Hi, 

I support this document as a working group document. 

Our company is already providing DS-Lite and MAP-E CE router. 
However, this document will help CE router vendors as nice guideline like RFC 7084. 
I'm co-chair of IPv6 home router SWG in IPv6 promotion counsil in Japan. 
This will also help our local guideline for ISP's and CE router vendors. 

I'd also like to discuss about RFC8026 DHCPv6 S46 priority option in this document. 
Because we can't use DHCPv6 option in actual situation. 

Regards, 
Masanobu 

==================================== 
 NEC Platforms, Ltd.                 
 KAWASHIMA Masanobu                  
 [email-masked]            
 https://www.necplatforms.co.jp/en/  
==================================== 

> Sent: Thursday, April 19, 2018 7:40 AM
> So, in addition to the authors, we have three people (Richard, Barbara, and Lee) that have said to the list that this
> document "is needed", by which I infer that they want it to be adopted as a working group document. That said, as
> I said to Fred Templin a few weeks ago, that isn't proof of a consensus.
> 
> The chairs would be interested to know how many do, and how many do not, want that to happen. If you have specific
> arguments, relevance to your part of the world, and so on, that's important too.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 19 Apr 2018 15:46:29 +0200

Hi Masanobu,

Thanks for your input. I also recall that you had 464XLAT, MAP-T and lw4o6 implemented. May be not in the "regular" firmware?

Regarding RFC8026, can you describe what is the issue that you have?

May be this document could be used to update RFC8026 if something is missing, or alternatively we will need to look into amending whatever is wrong in RFC8026, but in any case, we need to understand very well the issue.

Or do you mean that we need a more detailed description in draft-palet-v6ops-transition-ipv4aas about how to use RFC8026?

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Masanobu Kawashima <[email-masked]>
Fecha: jueves, 19 de abril de 2018, 15:15
Para: V6 Ops List <[email-masked]>
Asunto: Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion

    Hi, 

    
    
    Regards, 
    Masanobu

---

From: Fred Baker <[email-masked]>
Date: Thu, 19 Apr 2018 07:25:10 -0700

> The chairs would be interested to know how many do, and how many do not, want that to happen. If you have specific arguments, relevance to your part of the world, and so on, that's important too.

So using all of my fingers and thumbs, Ron and I see a vendor and seven operators that want to see this as a working group document; we see enough of a consensus in that regard. During May, we invite Jordi to repost as draft-ietf-v6ops-transition-ipv4aas, a working group document. I obviously expect Jordi to work with the operators that commented on the requirements, and to discuss it at IETF 102. In my dreams, I'd like to reach consensus then on the features in question.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 19 Apr 2018 16:32:20 +0200

Thanks Fred,

My hope is that I can get new inputs during the next few days, together with clarifications to those already received, and then we can try to have ready a WG-00 version by end of next week or early following one.

Regards,
Jordi

---

From: <[email-masked]>
Date: Fri, 20 Apr 2018 06:33:26 +0000

Hi Jordi, 

As you are waiting for some inputs, you may find some at, fwiw: 

https://github.com/boucadair/IETF-Drafts-Reviews/raw/master/draft-palet-v6ops-transition-ipv4aas-00-rev%20Med.doc 

Cheers,
Med 

> -----Message d'origine-----
> De : v6ops [mailto:[email-masked]] De la part de JORDI PALET MARTINEZ
> Envoyé : jeudi 19 avril 2018 16:32
> À : V6 Ops List
> Objet : Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion
> 
> Thanks Fred,
> 
> My hope is that I can get new inputs during the next few days, together with
> clarifications to those already received, and then we can try to have ready a
> WG-00 version by end of next week or early following one.
> 
> Regards,
> Jordi
> 
> 
>     > The chairs would be interested to know how many do, and how many do
> not, want that to happen. If you have specific arguments, relevance to your
>     So using all of my fingers and thumbs, Ron and I see a vendor and seven
> operators that want to see this as a working group document; we see enough of
> a consensus in that regard. During May, we invite Jordi to repost as draft-
> ietf-v6ops-transition-ipv4aas, a working group document. I obviously expect
> Jordi to work with the operators that commented on the requirements, and to
> discuss it at IETF 102. In my dreams, I'd like to reach consensus then on the
> features in question.
> 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: Fri, 20 Apr 2018 08:54:17 +0200

Hi Med,

Thanks a lot, definitively will look into them.

Regards,
Jordi

-----Mensaje original-----
De: <[email-masked]>
Fecha: viernes, 20 de abril de 2018, 8:33
Para: JORDI PALET MARTINEZ <[email-masked]>, V6 Ops List <[email-masked]>
Asunto: RE: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion

    Hi Jordi, 

    
    Cheers,
    Med

---

From: Lee Howard <[email-masked]>
Date: Mon, 23 Apr 2018 10:58:03 -0400

On 04/18/2018 03:34 PM, JORDI PALET MARTINEZ wrote:
> I will review them in detail in a couple of days, in case there are 
> other inputs, so we can work out a new version and hopefully publish 
> already as WG item.
>
>  1. I think this document is also for small and medium ISPs, only big
>     ones have the power to specify the set of features they need. Not
>     sure if your second sentence disagree with that.
>

Yes, I agree. If it sounded like I didn't agree, I misspoke. Small ISPs 
can select vendors who provide the features they want, but because of 
their small purchases, they cannot specify new features.

>  1. 1.1 was taken from RFC7084. Do you think it will be better to use
>     the standard RFC2119 boilerplate?
>

No, I agree with the wording. I just think it's important to note the 
difference for people who read a lot of RFCs.
>
>  1. I think the usage scenarios is important to readers that may be
>     don’t have a clear view on what is the CE we are talking about,
>     and in fact it was requested in one of the previous v6ops
>     presentations. Anyway, I will try to make it more “compressed”.
>  2. The “dynamic routing” comes from the original rfc7084, which
>     turned into the rfc7084-bis. I will check that from all my version
>     history on this document … and clarify or delete it.
>  3. I’m not 100% sure to understand your comment on the CLAT. I think
>     one of the keys is to allow deploying IPv6-only access while users
>     still can use devices in their LANs until they have incentives to
>     replace them, otherwise, customers will complain when they get
>     IPv6-only services (if using CLAT it is transparent for them).
>     CLAT can provide a NAT46, but then we need a also DNS46 ? If I got
>     you correctly, it is good that there is an incentive for replacing
>     IPv4-only devices because at some point there may be IPv6-only
>     services … so I think we should not make any new transition
>     mechanism to solve that problem?
>

Yes, you're right. Nevermind.
>
>  1. I think you mean “IPv4 service continuity” (not capitalized)
>

Yes.

>  1. Regarding 6rd, you mean this document should update RFC7084 and
>     remove 6rd requirements? I will agree on that …
>

Yes.

Lee

> Thanks!
>
>
> Regards,
>
> Jordi
>
> *De: *v6ops <[email-masked]> en nombre de Lee Howard 
> <lee@asgard..org>
> *Fecha: *miércoles, 18 de abril de 2018, 20:18
> *Para: *<[email-masked]>
> *Asunto: *Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion
>
> In order to effect a transition to IPv6, customer edge routers will 
> need to support transition mechanisms. Since a CE router manufacturer 
> can't know which transition mechanism will be used by any/all ISPs in 
> the market where it will need to be sold, they will need to support 
> the most likely mechanisms.
>
> buyer-specified devices. If an ISP wants fewer features to save cost 
> or for security, she may specify that. It means that CE router is less 
> there is an IPv6-only network in place. Since CE routers have a 
> lifetime of 7-15 years, I think that's too late. Suggest rewording it to:
>
> over it because it looks at first like RFC2119 boilerplate. Maybe 
> revise the heading to "Requirements Language - Special Note"? Also, 
> "preferable" should be "preferably.."
>
> I'm using the same language in comments that you do in the document, 
> but "IPv6 transition Customer Edge Router with IPv4aaS" is long, and 
> even the shortened version is cumbersome. Can we revise the 
> terminology to say that "CE Router" used in this document means "a 
> Customer Edge router with support for IPv6 transition mechanisms," 
> unless specified as "a CE Router without transition mechanism 
> support"? Also, need to expand the acronym "IPv4aaS" and define it..
>
> 3. Usage Scenarios
> Paragraph 1 nit:  "situation before described" -> "situation 
> previously described" or "situation described above".
>
> grammatically impenetrable, increasing competition isn't a goal of 
> this document (or of the IETF, or operators, or CE vendors).
>
> quite. I think if you're going to sidestep the issue of allowing 
> inbound connections, you need to be much more explicit about it. For 
> instance:
>
> The "For example" paragraph adds no clarity. The number of users has 
> no bearing on the functionality, at least as far as you've described.
>
> Although I'm not sure why PCP isn't part of the sentence with 
> UPnP-IGD, and from the previous section, I thought you weren't going 
> to discuss this.
>
> stability in IPv6. I know you don't want to say ULA (and I don't want 
> to make it a target for Lorenzo), but if you're going to say anything, 
> you have to be honest about it.
>
> RFC number accompanied by the title of that RFC. It helps with 
> context. Plus, every requirement needs text explaining why it is a 
> requirement. Sections 5.1 and 5.2 do neither of those.
>
> market means that's not required, and frankly I'm satisfied with 
> EOLing IPv4-only devices as content moves to IPv4-meh. We could in 
> theory include CLAT by itself?
>
> I like sections 7 Code Considerations and 8 Security Considerations. 
> You might mention the Security Considerations sections of each of the 
> I would be in favor of removing the 6rd requirement implied by 
> RFC7048. If anyone is planning 6rd deployments, I'd be very surprised.
>
> Lee
>
>
>     At IETF 101, Jordi Palet Martinez presented
>     draft-palet-v6ops-transition-ipv4aas. The draft is at
>     https://tools.ietf.org/html/draft-palet-v6ops-transition-ipv4aas,
>     and his presentation deck is at
>     https://datatracker.ietf.org/meeting/101/materials/slides-101-v6ops-transition-requirements-for-ipv6-ce-routers-to-support-ipv4-as-a-service-00.
>
>     In particular, this draft derives from
>     draft-ietf-v6ops-rfc7084-bis, and the chairs wonder if it should
>     be reposted as the next version of draft-ietf-v6ops-rfc7084-bis.
>     That should happen if an only if the working group thinks it
>     should be published as an RFC (now or at some point) adding
>     considerations for implementors of RFC 7084 and also implementing
>     transition services.
>
>     A key comment at IETF 101 was that there remain far too many
>     transition mechanisms listed. It would be helpful, if you hold
>     that opinion, if you could give that advice, identify the
>     mechanism or mechanisms you think should be listed, and indicate
>     the reasoning behind your viewpoint. For example, if you think
>     MAP-T should be listed, it would be helpful to know what operators
>     are implementing MAP-T and are looking for CE Routers that support
>     it. The same comment applies to any such mechanism or service.
>
>
>
>
>     [email-masked]<mailto:[email-masked]>
>
> _______________________________________________ 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: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 24 Apr 2018 19:13:17 +0000

> Let me ask an additional question. We have had at least one operator speak
> against adoption of this draft as a working group draft, because she doesn't
> want to add requirements to customer-edge (CE) routers, which potentially
> make them more complex and therefore expensive (every line of code costs
> something and has some probability of containing a bug or attack). It sounds
> like you would support adoption of the draft if it contains the right set of
> features and doesn't contain anything else, and if (as it is currently written)
> that it would be implemented in addition to RFC 7084. "The right set of
> features", from your perspective, includes MAP-T.
> 

Coming back from vacation and finally responding...

I support adoption of this draft by the WG. 
I believe it will be useful to many operators in driving CE router feature implementation that is needed by several operators today. Operators implementing dual stack today will be glad this document exists when they get ready to shut down IPv4, and I think it's better for them that the document exists sooner rather than later.

But that doesn't mean I believe the draft has exactly the right set of features included. My understanding of "adoption" is that it is still possible post-adoption to discuss whether specific features / requirements do or don't belong. If the precise set of features and requirements must be agreed upon prior to adoption, then I would not be in support of adoption. Hopefully we aren't setting the bar that high?

Here are some items I'd like to discuss (hopefully post-adoption and not as a pre-condition to adoption):
 - Each mechanism included needs to be carefully considered whether it is in or out. Is there significant (multiple providers) deployment support (not just lab trials) for each and every one of the mechanisms listed? [I think the current list looks pretty good, and see support expressed for most of these, but still believe we need additional discussion.]
 - Positioning against RFC7084. Should we bring DS-Lite into this document so there is one place to see all transition technology requirements? What to say about 6rd (I saw other comments on this)? Does this really update RFC7084? Or is it simply a nice companion to it?
 - IPv4 Multicast Support. Most retail routers do a pretty bad job of dealing with IPv4 multicast (especially wrt IPTV) without tunneling it over IPv6. I disagree that we should be encouraging all CE routers to support tunneling of IPv4 multicast over IPv6, when they often don't get native IPv4 multicast right.

So as long as we can still discuss these items post-adoption, I support adoption.
Barbara

> > [1]
> > https://www.ietf.org/mail-archive/web/softwires/current/msg06832.html
> >
> >> At IETF 101, Jordi Palet Martinez presented draft-palet-v6ops-transition-
> ipv4aas. The draft is at https://tools.ietf.org/html/draft-palet-v6ops-
> transition-ipv4aas, and his presentation deck is at
> https://datatracker.ietf.org/meeting/101/materials/slides-101-v6ops-
> transition-requirements-for-ipv6-ce-routers-to-support-ipv4-as-a-service-
> 00.
> >>
> >> In particular, this draft derives from draft-ietf-v6ops-rfc7084-bis, and the
> chairs wonder if it should be reposted as the next version of draft-ietf-v6ops-
> rfc7084-bis. That should happen if an only if the working group thinks it
> should be published as an RFC (now or at some point) adding considerations
> for implementors of RFC 7084 and also implementing transition services.
> >>
> >> A key comment at IETF 101 was that there remain far too many transition
> mechanisms listed. It would be helpful, if you hold that opinion, if you could
> give that advice, identify the mechanism or mechanisms you think should be
> listed, and indicate the reasoning behind your viewpoint. For example, if you
> think MAP-T should be listed, it would be helpful to know what operators are
> implementing MAP-T and are looking for CE Routers that support it. The
> same comment applies to any such mechanism or service.
> >>
> >>
> >>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 24 Apr 2018 21:26:29 +0200

Hi Barbara,

Thanks for your inputs and support :-)

I fully understand that WG adoption doesn't mean last-call, so we have a lot to do after WG adoption!

In my view, and I think it has been supported by operators speaking about it, the 4 mechanisms are being used and will be more often used.

Regarding DS-Lite/6RD vs RFC7084. Do you mean that we should, with this document, update RFC7084 to delete from there the section about transition, and then include the DS-LITE support here and remove 6RD ?

Lee did a similar comment and I will be in favor of that. Just want to make sure that you will support that as well, in case I didn't got you correctly.

Otherwise, duplicating DS-Lite in this document without updating RFC7084 in this specific point seems to me like a "no-sense-duplication" ... anyway, I will be happy either way.

IPv4 multicast support. Was requested by one of the operators and has been supported by others when talking to them about this document, but again, happy to have that discussion as well.

Regards,
Jordi

---

From: Fred Baker <[email-masked]>
Date: Tue, 24 Apr 2018 17:38:07 -0700

> On Apr 24, 2018, at 12:13 PM, STARK, BARBARA H <[email-masked]> wrote:
> 

I understand "adoption as a working group draft" to mean that the working group has agreed to work on the draft. There are some working groups that seem to confuse "adoption as a work group draft" with "agreement to send it to the IESG"; I don't, but expect conversation in between those two events.

That said, I'd like to believe that the draft is pretty close, and that changes that need to be made to it will have text offered by the people that want them. So - keep your cards and letters coming...

---

From: Richard Patterson <[email-masked]>
Date: Wed, 25 Apr 2018 10:15:51 +0100

Section 4 only briefly touches on UPnP, I'd like to propose that we
make a recommendation around its behaviour if it is enabled.

UPnP MAY be enabled on the IPv6 transition CE, for stateless
mechanisms that forward unsolicited inbound packets through to the CE.
If UPnP is enabled, the agent MUST reject any port mapping requests
for ports outside of the range(s) allocated to the IPv6 transition CE.

UPnP SHOULD be disabled for stateful mechanisms that do not forward
unsolicited inbound packets to the CE, unless implemented in
conjunction with a method to control the external port mapping, such
as IGD-PCP IWF [RFC6970].

-Richard

---

From: Ole Troan <[email-masked]>
Date: Thu, 26 Apr 2018 09:01:01 +0200

For the IPv4aaS mechanisms, the IETF could not come to consensus and ended up standardizing all the proposed solutions. This is failure.
This same thing happened with the IPv6aaS (6to4, 6over4, 6rd, L2TP, Teredo...) mechanisms. Where the IETF tried to "fix" that by e.g. shutting down the ngtrans working group.

For the IPv6aaS, history declared a few winners (6rd, NAT64), but it led to a lot of pain on the way (6to4 / Teredo / NAT-PT).
I don't think the IPv4aaS mechanisms have equal risk of damage as what 6to4/Teredo had.

Still, is there anything we have learnt from the last 3-5 years?
Does it help or harm, that the IETF publishes a document perpetuating the failure?

Ole

> On 15 Apr 2018, at 07:00, Fred Baker <[email-masked]> wrote:
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 26 Apr 2018 09:16:52 +0200

Hi Ole,

I agree in part with you. We defined too many transition mechanisms, but we are only engineers, not fortune tellers with a crystal ball, so we needed to "learn" from our own mistakes and enhance the earlier transitions techniques.

Also, we need to understand that not all the networks have the same way to do things, not same requirements, etc.

For example, MAP is fantastic if you have a broadband network only, but if you have also a cellular network, or you want to offer LTE backup to your broadband network, it makes more sense 464XLAT.

Looking into that, I think it help to have a document that summarizes those mechanisms that, after few years, look like the winners, so implementors and ISPs have an easier "single document" to follow and converge. If we look at all the options that we have for IPv4aaS, I think this document is reducing them to the half, which I think is a very good step.

I wish we can for example say "the best option is 464XLAT", is the only one supported in both broadband and cellular, and list only that one, but I think this is difficult to happen.

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Ole Troan <[email-masked]>
Fecha: jueves, 26 de abril de 2018, 9:01
Para: V6 Ops List <[email-masked]>
Asunto: Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion

    
    
    Ole

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 26 Apr 2018 21:40:52 +0200

Hi Richard,

As I've moved sections 3 & 4 to the end of the document as annexes, I've added a new small section for UPnP with your text. I think this also helps to clarify one of the issues raised by Lee.

I'm working on all this changes with my co-authors, and if we are good with them, we probably will submit the new version in a couple of days or so.

Thanks!

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Richard Patterson <[email-masked]>
Fecha: miércoles, 25 de abril de 2018, 11:16
Para: V6 Ops List <[email-masked]>
Asunto: Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion

    
    
    -Richard

---

From: <[email-masked]>
Date: Fri, 27 Apr 2018 05:26:25 +0000

Hi Jordi, 

As you are on it, and given the IETF recommendation in RFC6888:

   REQ-9:  A CGN MUST implement a protocol giving subscribers explicit
      control over NAT mappings.  That protocol SHOULD be the Port
      Control Protocol [RFC6887].

which would apply also to the PLAT, I suggest you add an item in the 464lat section to support RFC6970. 

Cheers,
Med

> Envoyé : jeudi 26 avril 2018 21:41
> À : V6 Ops List
> As I've moved sections 3 & 4 to the end of the document as annexes, I've
> added a new small section for UPnP with your text. I think this also helps to
> clarify one of the issues raised by Lee.
> 
> I'm working on all this changes with my co-authors, and if we are good with
> them, we probably will submit the new version in a couple of days or so.
> 
> Thanks!
> 
> Regards,
> Jordi
> 
> 
>     >> But that doesn't mean I believe the draft has exactly the right set of
> features included. My understanding of "adoption" is that it is still
> possible post-adoption to discuss whether specific features / requirements do
> or don't belong. If the precise set of features and requirements must be
> agreed upon prior to adoption, then I would not be in support of adoption.
> Hopefully we aren't setting the bar that high?
>     >
>     > I understand "adoption as a working group draft" to mean that the
> working group has agreed to work on the draft. There are some working groups
> that seem to confuse "adoption as a work group draft" with "agreement to send
> it to the IESG"; I don't, but expect conversation in between those two
> events.
>     >
>     > That said, I'd like to believe that the draft is pretty close, and that
> changes that need to be made to it will have text offered by the people that
> want them. So - keep your cards and letters coming...
>     >

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 27 Apr 2018 08:27:14 +0200

Hi Med,

In the document I'm editing right now, I've it already support for RFC6887 (464XLAT-2):

   464XLAT requirements:

   464XLAT-1:  The CE Router MUST perform IPv4 Network Address
               Translation (NAT) on IPv4 traffic translated using the
               CLAT, unless a dedicated /64 prefix has been acquired
               using DHCPv6-PD [RFC3633] (IPv6 Prefix Options for
               DHCPv6).

   464XLAT-2:  The CE Router MUST support PCP [RFC6887] (Port Control
               Protocol), for explicit control over NAT64 mappings.

   464XLAT-3:  The CE Router MUST implement [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).  The CE Router MUST follow
               [RFC7225] (Discovering NAT64 IPv6 Prefixes Using the
               PCP), in order to learn the PLAT-side translation IPv4
               and IPv6 prefix(es)/suffix(es) used by an upstream PCP-
               controlled NAT64 device.

But I now realice that it should be added as well to the DS-Lite section, as it was not present in RFC7084. This is what I've right now:

  DS-Lite requirements:

   DSLITE-1:  The IPv6 CE router MUST support configuration of DS-Lite
              via the DS-Lite DHCPv6 option [RFC6334] (DHCPv6 Option for
              Dual-Stack Lite).  The IPv6 CE router MAY use other
              mechanisms to configure DS-Lite parameters.  Such
              mechanisms are outside the scope of this document.

   DSLITE-2:  The IPv6 CE router MUST NOT perform IPv4 Network Address
              Translation (NAT) on IPv4 traffic encapsulated using DS-
              Lite.

So just to make sure, you mean to add also to both, 464LAT and DS-LITE also a MUST for RFC6970 ?

We have a new section with this text suggested by Richard:

5.  UPnP IGD-PCP IWF Support

   UPnP MAY be enabled on the CE Router for stateless mechanisms that
   forward unsolicited inbound packets through to the CE.  If UPnP is
   enabled, the agent MUST reject any port mapping requests for ports
   outside of the range(s) allocated to the CE Router.

   UPnP SHOULD be disabled for stateful mechanisms that do not forward
   unsolicited inbound packets to the CE Router, unless implemented in
   conjunction with a method to control the external port mapping, such
   as IGD-PCP IWF [RFC6970] (UPnP Internet Gateway Device - Port Control
   Protocol Interworking Function).

Regards,
Jordi

-----Mensaje original-----
De: <[email-masked]>
Fecha: viernes, 27 de abril de 2018, 7:26
Para: JORDI PALET MARTINEZ <[email-masked]>, V6 Ops List <[email-masked]>
Asunto: RE: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion

    Hi Jordi, 

    
    
    Cheers,
    Med

---

From: Ole Troan <[email-masked]>
Date: Fri, 27 Apr 2018 08:34:26 +0200

> which would apply also to the PLAT, I suggest you add an item in the 464lat section to support RFC6970.

I think that requirement needs to be reality checked.
Has any of the operators of CGNs deployed PCP? Would they allow customers to control NAT mappings at all? Or would that just be a different subscription plan?
For the other IPv4aaS mechanisms it isn't even an option...

From my perspective PCP from customers to control CGNs is not going to be deployed. I'd be happy to hear otherwise.

Ole

---

From: <[email-masked]>
Date: Fri, 27 Apr 2018 07:45:13 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : vendredi 27 avril 2018 08:27
> À : V6 Ops List

[Med] You don't need to add an item for 6887 since this is already covered in 7084:

   W-6:  The WAN interface of the CE router SHOULD support a Port
         Control Protocol (PCP) client as specified in [RFC6887] for use
         by applications on the CE router.  The PCP client SHOULD follow
         the procedure specified in Section 8.1 of [RFC6887] to discover
         its PCP server.  This document takes no position on whether
         such functionality is enabled by default or mechanisms by which
         users would configure the functionality.  Handling PCP requests
         from PCP clients in the LAN side of the CE router is out of
         scope.

My comment is about the IWF which is needed to allow an UPnP Control Point to interact with a PCP server.

>                Protocol), for explicit control over NAT64 mappings.

[Med] This one should be removed since it overlaps with W-6 in 7084.

> But I now realice that it should be added as well to the DS-Lite section, as
> it was not present in RFC7084. This is what I've right now:
> 
>   DS-Lite requirements:
> 

[Med] Yes, I'd like to add an item for the IWF, not the PCP Client functionality.  

>    Protocol Interworking Function).

[Med] this text does not recommend implementing the IWF.

---

From: <[email-masked]>
Date: Fri, 27 Apr 2018 07:54:12 +0000

Hi Ole, 

Please see inline. 

Cheers,
Med

> De : Ole Troan [mailto:[email-masked]]
> Envoyé : vendredi 27 avril 2018 08:34
> À : V6 Ops List
> Cc : JORDI PALET MARTINEZ; BOUCADAIR Mohamed IMT/OLN
> Has any of the operators of CGNs deployed PCP?

[Med] Yes, I confirm. PCP is a deployment reality (DS-Lite context in particular). Please refer to the file shared by Lee about IPv6 deployments. 

 Would they allow customers to
> control NAT mappings at all?

[Med] Yes. 

 Or would that just be a different subscription
> plan?

[Med] This is part of the normal service: 
* a GUI is provided on the CPE to allow creating mappings
* an UPnP IGD/PCP IWF is enabled to allow internal hosts to instantiate mappings on the CGN.  

> From my perspective PCP from customers to control CGNs is not going to be
> deployed.

[Med] You lose! This is already deployed.

 I'd be happy to hear otherwise.
[Med] Now you are :)

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 27 Apr 2018 10:27:21 +0200

The difference is in RFC7084 is a SHOULD for RFC6887, while here I'm suggesting a MUST when DS-LITE or 464XLAT are implemented.

Asking a MUST for RFC6970, and not having a MUST in RFC6887 seems weird ...

Regards,
Jordi

-----Mensaje original-----
De: <[email-masked]>
Fecha: viernes, 27 de abril de 2018, 9:45
Para: JORDI PALET MARTINEZ <[email-masked]>, V6 Ops List <[email-masked]>
Asunto: RE: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion

    Re-,
    
    Please see inline. 
    
    Cheers,
    Med

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 27 Apr 2018 10:31:48 +0200

Responding to myself ... The alternative maybe to not say anything about RFC6887, so the SHOULD in RFC7084 is in effect and add a SHOULD for RFC6970.

Regards,
Jordi

-----Mensaje original-----
De: JORDI PALET MARTINEZ <[email-masked]>
Fecha: viernes, 27 de abril de 2018, 10:27
Para: V6 Ops List <[email-masked]>
Asunto: Re: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion

    
    Regards,
    Jordi

    -----Mensaje original-----
    De: <[email-masked]>
    Fecha: viernes, 27 de abril de 2018, 9:45
    Para: JORDI PALET MARTINEZ <[email-masked]>, V6 Ops List <[email-masked]>
    Asunto: RE: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion
    
        Re-,
        
        Please see inline. 
        
        Cheers,
        Med

---

From: <[email-masked]>
Date: Fri, 27 Apr 2018 08:37:06 +0000

Jordi, 

That is what I was suggesting. 

Cheers,
Med

> Envoyé : vendredi 27 avril 2018 10:32
> À : V6 Ops List
> Responding to myself ... The alternative maybe to not say anything about
> RFC6887, so the SHOULD in RFC7084 is in effect and add a SHOULD for RFC6970.
> 
> Regards,
> Jordi
> 
> 
>     The difference is in RFC7084 is a SHOULD for RFC6887, while here I'm
> suggesting a MUST when DS-LITE or 464XLAT are implemented.
> 
>         > In the document I'm editing right now, I've it already support for
> RFC6887
>         > (464XLAT-2):
> 
>         > So just to make sure, you mean to add also to both, 464LAT and DS-
> LITE also a
>         > MUST for RFC6970 ?
> 
>         > Para: JORDI PALET MARTINEZ <[email-masked]>, V6 Ops
> List
>         > <[email-masked]>
>         >     which would apply also to the PLAT, I suggest you add an item
> in the
>         > 464lat section to support RFC6970.
>         >
>         >     Cheers,
>         >     Med
>         >
>         >     > De : v6ops [mailto:[email-masked]] De la part de
> JORDI PALET
>         > MARTINEZ
>         >     > As I've moved sections 3 & 4 to the end of the document as
> annexes,
>         > I've
>         >     > added a new small section for UPnP with your text. I think
> this also
>         > helps to
>         >     > I'm working on all this changes with my co-authors, and if we
> are good
>         > with
>         >     > them, we probably will submit the new version in a couple of
> days or
>         > so.
>         >     >
>         >     > Thanks!
>         >     >
>         >     > Regards,
>         >     > Jordi
>         >     >
>         >     >
>         >     > De: v6ops <[email-masked]> en nombre de Richard
> Patterson
>         >     > <[email-masked]>
>         >     >     mechanisms that forward unsolicited inbound packets
> through to the
>         > CE.
>         >     >     for ports outside of the range(s) allocated to the IPv6
> transition
>         > CE.
>         >     >
>         >     >     conjunction with a method to control the external port
> mapping,
>         > such
>         >     >     On 25 April 2018 at 01:38, Fred Baker
> <[email-masked]>
>         > wrote:
>         >     >     >
>         >     >     >
>         >     >     >> On Apr 24, 2018, at 12:13 PM, STARK, BARBARA H
> <[email-masked]>
>         > wrote:
>         >     >     >>
>         >     >     >> But that doesn't mean I believe the draft has exactly
> the right
>         > set of
>         >     > or don't belong. If the precise set of features and
> requirements must
>         > be
>         >     > agreed upon prior to adoption, then I would not be in support
> of
>         > adoption.
>         >     > working group has agreed to work on the draft. There are some
> working
>         > groups
>         >     > that seem to confuse "adoption as a work group draft" with
> "agreement
>         > to send
>         >     >     > That said, I'd like to believe that the draft is pretty
> close,
>         > and that
>         >     > changes that need to be made to it will have text offered by
> the people
>         > that
>         >     > 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: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 27 Apr 2018 11:04:10 +0200

Done, thanks!

So, I removed the SHOULD for PCP, as it is already in RFC7084, but added (DS-LITE and 464XLAT):

	The CE Router SHOULD support IGD-PCP IWF [RFC6970] (UPnP
               Internet Gateway Device - Port Control Protocol
               Interworking Function).

Regards,
Jordi

-----Mensaje original-----
De: <[email-masked]>
Fecha: viernes, 27 de abril de 2018, 10:37
Para: JORDI PALET MARTINEZ <[email-masked]>, V6 Ops List <[email-masked]>
Asunto: RE: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion

    Jordi, 

    Cheers,
    Med
    
    > recipient be aware

---

From: <[email-masked]>
Date: Fri, 27 Apr 2018 09:20:57 +0000

Re-,

Thank you. 

For DS-Lite, you may mention the following :
- when no PCP server is configured, the CPE assumes by default that the AFTR is the PCP server. 
- a plain IPv6 mode is used to send PCP requests to the server.

This is how PCP is deployed today for DS-lite. It is worth to have it documented. 

Cheers,
Med

> Envoyé : vendredi 27 avril 2018 11:04
> À : V6 Ops List
>     >     Asking a MUST for RFC6970, and not having a MUST in RFC6887 seems
> weird
>     > ...
>     >
>     >     Regards,
>     >     Jordi
>     >
>     >
> JORDI
>     > PALET MARTINEZ
>     >         [Med] You don't need to add an item for 6887 since this is
> already
>     > covered in 7084:
>     >
>     >                  Control Protocol (PCP) client as specified in
> [RFC6887] for
>     > use
>     >                  by applications on the CE router.  The PCP client
> SHOULD
>     > follow
>     >                  such functionality is enabled by default or mechanisms
> by
>     > which
>     >         My comment is about the IWF which is needed to allow an UPnP
> Control
>     > Point to interact with a PCP server.
>     >
>     >         >
>     >         >    464XLAT requirements:
>     >         >
>     >         >                Translation (NAT) on IPv4 traffic translated
> using
>     > the
>     >         >    464XLAT-3:  The CE Router MUST implement [RFC7050]
> (Discovery of
>     > the
>     >         >                IPv6 Prefix Used for IPv6 Address Synthesis)
> in
>     > order to
>     >         >                PCP), in order to learn the PLAT-side
> translation
>     > IPv4
>     >         >                and IPv6 prefix(es)/suffix(es) used by an
> upstream
>     > PCP-
>     >         >                controlled NAT64 device.
>     >         >
>     >         >
>     >         > But I now realice that it should be added as well to the DS-
> Lite
>     > section, as
>     >         >    DSLITE-1:  The IPv6 CE router MUST support configuration
> of DS-
>     > Lite
>     >         >    DSLITE-2:  The IPv6 CE router MUST NOT perform IPv4
> Network
>     > Address
>     >         >               Translation (NAT) on IPv4 traffic encapsulated
> using
>     > DS-
>     >         >               Lite.
>     >         >
>     >         >
>     >         [Med] Yes, I'd like to add an item for the IWF, not the PCP
> Client
>     > functionality.
>     >
>     >         >
>     >         >    UPnP MAY be enabled on the CE Router for stateless
> mechanisms
>     > that
>     >         >    forward unsolicited inbound packets through to the CE.  If
> UPnP
>     > is
>     >         >    enabled, the agent MUST reject any port mapping requests
> for
>     > ports
>     >         >    UPnP SHOULD be disabled for stateful mechanisms that do
> not
>     > forward
>     >         >    unsolicited inbound packets to the CE Router, unless
> implemented
>     > in
>     >         >    as IGD-PCP IWF [RFC6970] (UPnP Internet Gateway Device -
> Port
>     > Control
>     >         >        REQ-9:  A CGN MUST implement a protocol giving
> subscribers
>     > explicit
>     >         >           control over NAT mappings.  That protocol SHOULD be
> the
>     > Port
>     >         >     > Objet : Re: [v6ops] draft-palet-v6ops-transition-
> ipv4aas
>     > discussion
>     >         >     >
>     >         >     > Hi Richard,
>     >         >     >
>     >         >     > Asunto: Re: [v6ops] draft-palet-v6ops-transition-
> ipv4aas
>     > discussion
>     >         >     >
>     >         >     >     UPnP SHOULD be disabled for stateful mechanisms
> that do
>     > not forward
>     >         >     >     unsolicited inbound packets to the CE, unless
> implemented
>     > in
>     >         >     > features included. My understanding of "adoption" is
> that it
>     > is still
>     >         >     > possible post-adoption to discuss whether specific
> features /
>     >         > requirements do
>     >         >     >     > I understand "adoption as a working group draft"
> to
>     > mean that the
>     >         >     > it to the IESG"; I don't, but expect conversation in
> between
>     > those two
>     >         >     > events.
>     >         >     >     >
>     >         >     > This electronic message contains information which may
> be
>     > privileged or
>     >         >     > partially, including attached files, is strictly
> prohibited
>     > and will be
>     >         >     > information, even if partially, including attached
> files, is
>     > strictly
>     >         >     > original sender to inform about this communication and
> delete
>     > it.
>     >         >     >
>     >         >     >
>     >         >     >
> exclusive
>     > use of the
> information,
>     > even if
>     >         > partially, including attached files, is strictly prohibited
> and
>     > will be
> contents
>     > of this
> must
>     > reply to the

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 27 Apr 2018 12:25:55 +0200

Agree, it makes sense.

I don't know if other operators are using also the same approach when using NAT64. May be nobody considered, but I think it will make sense to have the same text as well?

Regards,
Jordi

-----Mensaje original-----
De: <[email-masked]>
Fecha: viernes, 27 de abril de 2018, 11:21
Para: JORDI PALET MARTINEZ <[email-masked]>, V6 Ops List <[email-masked]>
Asunto: RE: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion

    Re-,
    
    Thank you. 

    
    Cheers,
    Med

---

From: <[email-masked]>
Date: Fri, 27 Apr 2018 10:52:04 +0000

Re-,

It does not make sense to use the same text for the following reasons:

* NAT64 deployments do not require explicit configuration of the NAT64 instance to use at the CPE/host side, while in DS-Lite the configuration of the AFTR is required.
* Packets from the host embedding the CLAT are native IPv6 packets, so PCP requests will just fly as native IPv6 packets. The situation is different for DS-Lite because IPv4 user traffic is encapsulated over IPv6 to the AFTR.  

Cheers,
Med

> Envoyé : vendredi 27 avril 2018 12:26
> À : V6 Ops List
> I don't know if other operators are using also the same approach when using
> NAT64. May be nobody considered, but I think it will make sense to have the
> same text as well?
> 
> Regards,
> Jordi
> 
> 
>     > So, I removed the SHOULD for PCP, as it is already in RFC7084, but
> added (DS-
>     > LITE and 464XLAT):
>     >
>     >     > De : v6ops [mailto:[email-masked]] De la part de JORDI
> PALET
>     > MARTINEZ
>     >     > Responding to myself ... The alternative maybe to not say
> anything
>     > about
>     >     > RFC6887, so the SHOULD in RFC7084 is in effect and add a SHOULD
> for
>     > RFC6970.
>     >     >
>     >     > Regards,
>     >     > Jordi
>     >     >
>     >     >
>     >     >     The difference is in RFC7084 is a SHOULD for RFC6887, while
> here
>     > I'm
>     >     >            W-6:  The WAN interface of the CE router SHOULD
> support a
>     > Port
>     >     >                  the procedure specified in Section 8.1 of
> [RFC6887] to
>     >     > discover
>     >     >                  its PCP server.  This document takes no position
> on
>     > whether
>     >     >                  users would configure the functionality.
> Handling PCP
>     >     > requests
>     >     >                  from PCP clients in the LAN side of the CE
> router is
>     > out of
>     >     >                  scope.
>     >     >
>     >     >         >                CLAT, unless a dedicated /64 prefix has
> been
>     >     > acquired
>     >     >         >                using DHCPv6-PD [RFC3633] (IPv6 Prefix
> Options
>     > for
>     >     >         >                DHCPv6).
>     >     >         >
>     >     >         >    464XLAT-2:  The CE Router MUST support PCP [RFC6887]
> (Port
>     >     > Control
>     >     >         >                Protocol), for explicit control over
> NAT64
>     > mappings.
>     >     >
>     >     >         [Med] This one should be removed since it overlaps with
> W-6 in
>     > 7084.
>     >     >
>     >     >         >
>     >     >         >                discover the PLAT-side translation IPv4
> and
>     > IPv6
>     >     >         >                prefix(es)/suffix(es).  The CE Router
> MUST
>     > follow
>     >     >         >                [RFC7225] (Discovering NAT64 IPv6
> Prefixes
>     > Using the
>     >     >         >               via the DS-Lite DHCPv6 option [RFC6334]
> (DHCPv6
>     >     > Option for
>     >     >         >               Dual-Stack Lite).  The IPv6 CE router MAY
> use
>     > other
>     >     >         >               mechanisms to configure DS-Lite
> parameters.
>     > Such
>     >     >         > So just to make sure, you mean to add also to both,
> 464LAT
>     > and DS-
>     >     > LITE also a
>     >     >         > MUST for RFC6970 ?
>     >     >
>     >     >         > Para: JORDI PALET MARTINEZ
> <[email-masked]>, V6
>     > Ops
>     >     > List
>     >     >         > <[email-masked]>
>     >     >         > Asunto: RE: [v6ops] draft-palet-v6ops-transition-
> ipv4aas
>     > discussion
>     >     >         >
>     >     >         >     Hi Jordi,
>     >     >         >
>     >     >         >     As you are on it, and given the IETF recommendation
> in
>     > RFC6888:
>     >     >         >
>     >     >         >     which would apply also to the PLAT, I suggest you
> add an
>     > item
>     >     > in the
>     >     >         >     > De : v6ops [mailto:[email-masked]] De la
> part
>     > de
>     >     > JORDI PALET
>     >     >         > MARTINEZ
>     >     >         >     > As I've moved sections 3 & 4 to the end of the
> document
>     > as
>     >     > annexes,
>     >     >         > I've
>     >     >         >     > added a new small section for UPnP with your
> text. I
>     > think
>     >     > this also
>     >     >         > helps to
>     >     >         >     > I'm working on all this changes with my co-
> authors, and
>     > if we
>     >     > are good
>     >     >         > with
>     >     >         >     > them, we probably will submit the new version in
> a
>     > couple of
>     >     > days or
>     >     >         > so.
>     >     >         >     >
>     >     >         >     > Thanks!
>     >     >         >     >
>     >     >         >     > Regards,
>     >     >         >     > Jordi
>     >     >         >     >
>     >     >         >     >
>     >     >         >     >     Section 4 only briefly touches on UPnP, I'd
> like to
>     >     > propose that we
>     >     >         >     >     make a recommendation around its behaviour if
> it is
>     >     > enabled.
>     >     >         >     >
>     >     >         >     >     UPnP MAY be enabled on the IPv6 transition
> CE, for
>     >     > stateless
>     >     >         >     >     If UPnP is enabled, the agent MUST reject any
> port
>     >     > mapping requests
>     >     >         >     >     for ports outside of the range(s) allocated
> to the
>     > IPv6
>     >     > transition
>     >     >         > CE.
>     >     >         >     >
>     >     >         >     >     conjunction with a method to control the
> external
>     > port
>     >     > mapping,
>     >     >         > such
>     >     >         >     >     >> But that doesn't mean I believe the draft
> has
>     > exactly
>     >     > the right
>     >     >         > set of
>     >     >         >     > agreed upon prior to adoption, then I would not
> be in
>     > support
>     >     > of
>     >     >         > adoption.
>     >     >         >     > working group has agreed to work on the draft.
> There
>     > are some
>     >     > working
>     >     >         > groups
>     >     >         >     > that seem to confuse "adoption as a work group
> draft"
>     > with
>     >     > "agreement
>     >     >         > to send
>     >     >         >     >     > That said, I'd like to believe that the
> draft is
>     > pretty
>     >     > close,
>     >     >         > and that
>     >     >         >     > 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
>     >     > confidential. The information is intended to be for the exclusive
> use
>     > of the
>     >     > copying, distribution or use of the contents of this information,
> even
>     > if
>     >     > 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: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 27 Apr 2018 13:03:11 +0200

I mean in the scenario when a CE or host behind a NAT64 want to ask the NAT64 for specific IPv4 incoming traffic. I thought you can do that as well if the NAT64 supports PCP, and if that's the case, the CE/host will need to tell the PCP server (so again, if no PCP server is configured, the CE could assume, by default, that the NAT64 is the PCP server).

Regards,
Jordi

-----Mensaje original-----
De: <[email-masked]>
Fecha: viernes, 27 de abril de 2018, 12:52
Para: JORDI PALET MARTINEZ <[email-masked]>, V6 Ops List <[email-masked]>
Asunto: RE: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion

    Re-,

    
    Cheers,
    Med

---

From: <[email-masked]>
Date: Fri, 27 Apr 2018 11:15:39 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : vendredi 27 avril 2018 13:03
> À : V6 Ops List
> I mean in the scenario when a CE or host behind a NAT64 want to ask the NAT64
> for specific IPv4 incoming traffic.

[Med] Yes. See for example the experiments we did using an Android Phone: https://www.ietf.org/proceedings/85/slides/slides-85-pcp-6.pdf 

 I thought you can do that as well if the
> NAT64 supports PCP, and if that's the case, the CE/host will need to tell the
> PCP server (so again, if no PCP server is configured, the CE could assume, by
> default, that the NAT64 is the PCP server).

[Med] Yeah, but the CE is not aware of the NAT64. This is why it is needed to configure explicitly the PCP server on the CE for 464xlat case: RFC 7291. 

>     * NAT64 deployments do not require explicit configuration of the NAT64
> instance to use at the CPE/host side, while in DS-Lite the configuration of
> the AFTR is required.
>     * Packets from the host embedding the CLAT are native IPv6 packets, so
> PCP requests will just fly as native IPv6 packets. The situation is different
> for DS-Lite because IPv4 user traffic is encapsulated over IPv6 to the AFTR.
> 
>     Cheers,
>     Med
> 
>     >     - when no PCP server is configured, the CPE assumes by default that
> the
>     > AFTR is the PCP server.
>     >     This is how PCP is deployed today for DS-lite. It is worth to have
> it
>     > documented.
>     >
>     >     Cheers,
>     >     Med
>     >
>     >     >     >     Asking a MUST for RFC6970, and not having a MUST in
> RFC6887
>     > seems
>     >     > weird
>     >     >     > ...
>     >     >     >
>     >     >     >     Regards,
>     >     >     >     Jordi
>     >     >     >
>     >     >     >
>     >     >     >         > In the document I'm editing right now, I've it
> already
>     >     > support for
>     >     >     > RFC6887
>     >     >     >         > (464XLAT-2):
>     >     >     >
>     >     >     >         [Med] You don't need to add an item for 6887 since
> this
>     > is
>     >     > already
>     >     >     > covered in 7084:
>     >     >     >
>     >     >     >                  such functionality is enabled by default
> or
>     > mechanisms
>     >     > by
>     >     >     > which
>     >     >     >         My comment is about the IWF which is needed to
> allow an
>     > UPnP
>     >     > Control
>     >     >     >         >    464XLAT-1:  The CE Router MUST perform IPv4
> Network
>     >     > Address
>     >     >     >         >                and IPv6 prefix(es)/suffix(es)
> used by
>     > an
>     >     > upstream
>     >     >     > PCP-
>     >     >     >         >                controlled NAT64 device.
>     >     >     >         >
>     >     >     >         >
>     >     >     >         > But I now realice that it should be added as well
> to
>     > the DS-
>     >     > Lite
>     >     >     > section, as
>     >     >     >         > it was not present in RFC7084. This is what I've
> right
>     > now:
>     >     >     >         >
>     >     >     >         >   DS-Lite requirements:
>     >     >     >         >
>     >     >     >         >               mechanisms are outside the scope of
> this
>     >     > document.
>     >     >     >         >
>     >     >     >         [Med] Yes, I'd like to add an item for the IWF, not
> the
>     > PCP
>     >     > Client
>     >     >     > functionality.
>     >     >     >
>     >     >     >         >
>     >     >     >         >    forward unsolicited inbound packets through to
> the
>     > CE.  If
>     >     > UPnP
>     >     >     > is
>     >     >     >         >    enabled, the agent MUST reject any port
> mapping
>     > requests
>     >     > for
>     >     >     > ports
>     >     >     >         >    UPnP SHOULD be disabled for stateful
> mechanisms that
>     > do
>     >     > not
>     >     >     > forward
>     >     >     >         >    as IGD-PCP IWF [RFC6970] (UPnP Internet
> Gateway
>     > Device -
>     >     > Port
>     >     >     > Control
>     >     >     >         >           control over NAT mappings.  That
> protocol
>     > SHOULD be
>     >     > the
>     >     >     > Port
>     >     >     >         >     > De: v6ops <[email-masked]> en
> nombre de
>     > Richard
>     >     >     > Patterson
>     >     >     >         >     > <[email-masked]>
>     >     >     >         >     >     mechanisms that forward unsolicited
> inbound
>     > packets
>     >     >     > through to the
>     >     >     >         > CE.
>     >     >     >         >     > features included. My understanding of
> "adoption"
>     > is
>     >     > that it
>     >     >     > is still
>     >     >     >         >     > or don't belong. If the precise set of
> features
>     > and
>     >     >     > requirements must
>     >     >     >         > be
>     >     >     >         >     >     > I understand "adoption as a working
> group
>     > draft"
>     >     > to
>     >     >     > mean that the
>     >     >     >         >     > it to the IESG"; I don't, but expect
> conversation
>     > in
>     >     > between
>     >     >     > those two
>     >     >     >         >     > events.
>     >     >     >         >     >     >
>     >     >     >         >     > changes that need to be made to it will
> have text
>     >     > offered by
>     >     >     > the people
>     >     >     >         > that
>     >     >     >         >     > This electronic message contains
> information
>     > which may
>     >     > be
>     >     >     > privileged or
>     >     >     >         >     > confidential. The information is intended
> to be
>     > for the
>     >     >     > exclusive use
>     >     >     >         > of the
>     >     >     >         >     > 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
>     >     >     > information, even if partially, including attached files,
> is
>     > strictly
> delete it.

---

From: Richard Patterson <[email-masked]>
Date: Fri, 27 Apr 2018 11:30:05 +0000

Hi Ole, apologies for the indirect reply, but Gmail appears to have
filtered your email.

>  From my perspective PCP from customers to control CGNs is not going to be
deployed. I'd be happy to hear otherwise.

I'm in two minds about this.  On one hand it may help existing applications
when used alongside the UPnP IWF, but on the other it would be at best,
intermittent.
This intermittent-ness could allow an Xbox to successfully open up port
3074 on Monday during the day, when no other customers sharing the IPv4
address have already taken it, but would fail on Friday night when another
customer turned their Xbox on first and already mapped the port.
Intermittent faults like this could drive more inbound calls to our call
centre, which have a tangible cost impact on the business, not to mention
arguably a worse customer experience.  I'm inclined to prefer reproducible
and predictable failures so the fault can be more reliable identified.

We did trial PCP with the RFC6970 IWF on our CPEs using NAT444, but only as
a staff trial, we never deployed it (NAT444) to production customers.

-Rich

> > > which would apply also to the PLAT, I suggest you add an item in the
464lat
> > section to support RFC6970.
> >

> [Med] Yes, I confirm. PCP is a deployment reality (DS-Lite context in
particular). Please refer to the file shared by Lee about IPv6 deployments.

> > >> added a new small section for UPnP with your text. I think this also
helps
> > >> I'm working on all this changes with my co-authors, and if we are
good
> > >>    for ports outside of the range(s) allocated to the IPv6
transition CE.
> > >> possible post-adoption to discuss whether specific features /
requirements
> > >> that seem to confuse "adoption as a work group draft" with
"agreement to
> > send
> > >> changes that need to be made to it will have text offered by the
people
or
> > >> confidential. The information is intended to be for the exclusive
use of
even if
> > >> considered a criminal offense. If you are not the intended recipient
be
> > >> prohibited, will be considered a criminal offense, so you must reply
to

---

From: <[email-masked]>
Date: Fri, 27 Apr 2018 12:03:37 +0000

Hi Richard, 

Thank you for sharing this information. 

As you know, this a problem of UPnP IGD:1 not UPnP IGD:2 and the behavior adopted by applications, e.g., 

* An app calls GetSpecificPortMapping until it finds an external available port, and then calls AddPortMapping(). This one will work just fine.
* An app calls AddPortMapping, after it finds the external port is not available, then it tries the same port 5 more times by calling AddPortMapping, then it returns an error. This behavior increases the chance to get a port. 
* An app calls GetSpecificPortMapping, after finding the external port not available, returns an error without issuing AddPortMapping. This one is broken.
* An appl calls AddPortMapping, after it finds the external port is not available, then it returns an error. This one is borken 
* etc. 

I know some applications are still using IGD:1, but I hope they will move to the IGD:2.

Please note that PCP addresses both the interworking with UPnP (which is one part of the problem), but also mappings that can be instantiated directly by a customer from a GUI exposed by the CPE. People running servers or want to access their CPE when outside are happy with the PCP feature. 

Cheers,
Med

> De : v6ops [mailto:[email-masked]] De la part de Richard Patterson
> Envoyé : vendredi 27 avril 2018 13:30
> À : [email-masked] list

---

From: Richard Patterson <[email-masked]>
Date: Fri, 27 Apr 2018 12:46:06 +0000

> I know some applications are still using IGD:1, but I hope they will move
to the IGD:2.

When I was testing this nearly 4 years ago, I struggled to find CPEs with
IGD:2 support.  Hopefully the landscape has changed now that IGD:1 has been
deprecated.
But then as you say, we still need the applications to update their
behaviour and adopt the looser AddAnyPortMapping() instead of the more
specific AddPortMapping()

I'd be more confident in RFC6970 as a useful mitigation then.

-Rich

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 27 Apr 2018 15:54:40 +0200

Typically, the NAT64 will be the default GW ... but it is true that you may have also installed a more specific route for the NAT64 prefix/suffix (in addition to the default one).

Maybe what it makes sense anyway, is to have also a MUST for the RFC7291 y PCP is implemented by the CE.

Regards,
Jordi

-----Mensaje original-----
De: <[email-masked]>
Fecha: viernes, 27 de abril de 2018, 13:15
Para: JORDI PALET MARTINEZ <[email-masked]>, V6 Ops List <[email-masked]>
Asunto: RE: [v6ops] draft-palet-v6ops-transition-ipv4aas discussion

    Re-,
    
    Please see inline. 
    
    Cheers,
    Med

---

From: <[email-masked]>
Date: Fri, 27 Apr 2018 14:01:23 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : vendredi 27 avril 2018 15:55
> À : V6 Ops List
> Typically, the NAT64 will be the default GW ... 

[Med] Not sure to understand what you meant. 

FWIW, in the context of current NAT64 deployments (mobile), the NAT64 is located at the Gi interface...that is upstream of the PGW.

but it is true that you may
> have also installed a more specific route for the NAT64 prefix/suffix (in
> addition to the default one).
> 

[Med] Agree. 

>     [Med] Yes. See for example the experiments we did using an Android Phone:
> https://www.ietf.org/proceedings/85/slides/slides-85-pcp-6.pdf
> 
>     [Med] Yeah, but the CE is not aware of the NAT64. This is why it is
> needed to configure explicitly the PCP server on the CE for 464xlat case: RFC
> 7291.
> 
>     >
>     > Regards,
>     > Jordi
>     >
>     >
>     >     > I don't know if other operators are using also the same approach
> when
>     > using
>     >     > NAT64. May be nobody considered, but I think it will make sense
> to have
>     > the
>     >     > same text as well?
>     >     >
>     >     > Regards,
>     >     > Jordi
>     >     >
>     >     >
>     >     >     > So, I removed the SHOULD for PCP, as it is already in
> RFC7084,
>     > but
>     >     > added (DS-
>     >     >     > LITE and 464XLAT):
>     >     >     >
>     >     >     >     > RFC6887, so the SHOULD in RFC7084 is in effect and
> add a
>     > SHOULD
>     >     > for
>     >     >     > RFC6970.
>     >     >     >     >
>     >     >     >     > Regards,
>     >     >     >     > Jordi
>     >     >     >     >
>     >     >     >     >
>     >     >     >     >     The difference is in RFC7084 is a SHOULD for
> RFC6887,
>     > while
>     >     > here
>     >     >     > I'm
>     >     >     >     >                  Control Protocol (PCP) client as
> specified
>     > in
>     >     >     > [RFC6887] for
>     >     >     >     > use
>     >     >     >     >                  by applications on the CE router.
> The PCP
>     >     > client
>     >     >     > SHOULD
>     >     >     >     > follow
>     >     >     >     >                  its PCP server.  This document takes
> no
>     > position
>     >     > on
>     >     >     > whether
>     >     >     >     >         >                Translation (NAT) on IPv4
> traffic
>     >     > translated
>     >     >     > using
>     >     >     >     > the
>     >     >     >     >         >                using DHCPv6-PD [RFC3633]
> (IPv6
>     > Prefix
>     >     > Options
>     >     >     > for
>     >     >     >     >         >                DHCPv6).
>     >     >     >     >         >
>     >     >     >     >         >    464XLAT-2:  The CE Router MUST support
> PCP
>     > [RFC6887]
>     >     > (Port
>     >     >     >     > Control
>     >     >     >     >         >                Protocol), for explicit
> control
>     > over
>     >     > NAT64
>     >     >     > mappings.
>     >     >     >     >
>     >     >     >     >         [Med] This one should be removed since it
> overlaps
>     > with
>     >     > W-6 in
>     >     >     > 7084.
>     >     >     >     >
>     >     >     >     >         >
>     >     >     >     >         >                IPv6 Prefix Used for IPv6
> Address
>     >     > Synthesis)
>     >     >     > in
>     >     >     >     > order to
>     >     >     >     >         >                discover the PLAT-side
> translation
>     > IPv4
>     >     > and
>     >     >     > IPv6
>     >     >     >     >         >                prefix(es)/suffix(es).  The
> CE
>     > Router
>     >     > MUST
>     >     >     > follow
>     >     >     >     >         >                PCP), in order to learn the
> PLAT-
>     > side
>     >     >     > translation
>     >     >     >     > IPv4
>     >     >     >     >         >                and IPv6
> prefix(es)/suffix(es)
>     > used by
>     >     > an
>     >     >     > upstream
>     >     >     >     > PCP-
>     >     >     >     >         >                controlled NAT64 device.
>     >     >     >     >         >
>     >     >     >     >         >
>     >     >     >     >         >    DSLITE-1:  The IPv6 CE router MUST
> support
>     >     > configuration
>     >     >     > of DS-
>     >     >     >     > Lite
>     >     >     >     >         >               Dual-Stack Lite).  The IPv6
> CE
>     > router MAY
>     >     > use
>     >     >     > other
>     >     >     >     >         >    DSLITE-2:  The IPv6 CE router MUST NOT
> perform
>     > IPv4
>     >     >     > Network
>     >     >     >     > Address
>     >     >     >     >         >               Translation (NAT) on IPv4
> traffic
>     >     > encapsulated
>     >     >     > using
>     >     >     >     > DS-
>     >     >     >     >         >               Lite.
>     >     >     >     >         >
>     >     >     >     >         >
>     >     >     >     >         > So just to make sure, you mean to add also
> to
>     > both,
>     >     > 464LAT
>     >     >     > and DS-
>     >     >     >     > LITE also a
>     >     >     >     >         > MUST for RFC6970 ?
>     >     >     >     >
>     >     >     >     >         > We have a new section with this text
> suggested by
>     >     > Richard:
>     >     >     >     >         >
>     >     >     >     >         >    outside of the range(s) allocated to the
> CE
>     > Router.
>     >     >     >     >         >
>     >     >     >     >         >    unsolicited inbound packets to the CE
> Router,
>     > unless
>     >     >     > implemented
>     >     >     >     > in
>     >     >     >     >         [Med] this text does not recommend
> implementing the
>     > IWF.
>     >     >     >     >
>     >     >     >     >         >
>     >     >     >     >         > Regards,
>     >     >     >     >         > Jordi
>     >     >     >     >         >
>     >     >     >     >         >
>     >     >     >     >         >        REQ-9:  A CGN MUST implement a
> protocol
>     > giving
>     >     >     > subscribers
>     >     >     >     > explicit
>     >     >     >     >         >     which would apply also to the PLAT, I
> suggest
>     > you
>     >     > add an
>     >     >     > item
>     >     >     >     > in the
>     >     >     >     >         >     > De : v6ops [mailto:v6ops-
> [email-masked]]
>     > De la
>     >     > part
>     >     >     > de
>     >     >     >     > JORDI PALET
>     >     >     >     >         > MARTINEZ
>     >     >     >     >         >     > Objet : Re: [v6ops] draft-palet-
> v6ops-
>     > transition-
>     >     >     > ipv4aas
>     >     >     >     > discussion
>     >     >     >     >         >     >
>     >     >     >     >         >     > Hi Richard,
>     >     >     >     >         >     >
>     >     >     >     >         >     > As I've moved sections 3 & 4 to the
> end of
>     > the
>     >     > document
>     >     >     > as
>     >     >     >     > annexes,
>     >     >     >     >         > I've
>     >     >     >     >         >     > added a new small section for UPnP
> with
>     > your
>     >     > text. I
>     >     >     > think
>     >     >     >     > this also
>     >     >     >     >         > helps to
>     >     >     >     >         >     > Fecha: miércoles, 25 de abril de
> 2018,
>     > 11:16
>     >     >     >     >         >     > Asunto: Re: [v6ops] draft-palet-
> v6ops-
>     > transition-
>     >     >     > ipv4aas
>     >     >     >     > discussion
>     >     >     >     >         >     >
>     >     >     >     >         >     >     Section 4 only briefly touches on
> UPnP,
>     > I'd
>     >     > like to
>     >     >     >     > propose that we
>     >     >     >     >         >     >     If UPnP is enabled, the agent
> MUST
>     > reject any
>     >     > port
>     >     >     >     > mapping requests
>     >     >     >     >         >     >     unsolicited inbound packets to
> the CE,
>     > unless
>     >     >     > implemented
>     >     >     >     > in
>     >     >     >     >         >     >     conjunction with a method to
> control
>     > the
>     >     > external
>     >     >     > port
>     >     >     >     > mapping,
>     >     >     >     >         > such
>     >     >     >     >         >     >     >> On Apr 24, 2018, at 12:13 PM,
> STARK,
>     >     > BARBARA H
>     >     >     >     > <[email-masked]>
>     >     >     >     >         > wrote:
>     >     >     >     >         >     >     >>
>     >     >     >     >         >     >     >> But that doesn't mean I
> believe the
>     > draft
>     >     > has
>     >     >     > exactly
>     >     >     >     > the right
>     >     >     >     >         > set of
>     >     >     >     >         >     > possible post-adoption to discuss
> whether
>     >     > specific
>     >     >     > features /
>     >     >     >     >         > requirements do
>     >     >     >     >         >     > agreed upon prior to adoption, then I
> would
>     > not
>     >     > be in
>     >     >     > support
>     >     >     >     > of
>     >     >     >     >         > adoption.
>     >     >     >     >         >     > Hopefully we aren't setting the bar
> that
>     > high?
>     >     >     >     >         >     >     >
>     >     >     >     >         >     > working group has agreed to work on
> the
>     > draft.
>     >     > There
>     >     >     > are some
>     >     >     >     > working
>     >     >     >     >         > groups
>     >     >     >     >         >     > that seem to confuse "adoption as a
> work
>     > group
>     >     > draft"
>     >     >     > with
>     >     >     >     > "agreement
>     >     >     >     >         > to send
>     >     >     >     >         >     >     > That said, I'd like to believe
> that
>     > the
>     >     > draft is
>     >     >     > pretty
>     >     >     >     > close,
>     >     >     >     >         > and that
>     >     >     >     >         >     > want them. So - keep your cards and
> letters
>     >     > coming...
>     >     >     >     >         >     >     >
>     >     >     >     >         >     >     >
>     >     >     >     >         >     > individual(s) named above and further
> non-
>     >     > explicilty
>     >     >     >     > authorized
>     >     >     >     >         > disclosure,
>     >     >     >     >         >     > partially, including attached files,
> is
>     > strictly
>     >     >     > prohibited
>     >     >     >     > and will be
>     >     >     >     >         >     > that any disclosure, copying,
> distribution
>     > or use
>     >     > of
>     >     >     > the
>     >     >     >     > contents of
>     >     >     >     >         > this
>     >     >     >     >         >     > information, even if partially,
> including
>     >     > attached
>     >     >     > files, is
>     >     >     >     > strictly
>     >     >     >     > This electronic message contains information which
> may be
>     >     > privileged or
> files,

---

From: joel jaeggli <[email-masked]>
Date: Sun, 29 Apr 2018 15:03:28 -0700

> From my perspective PCP from customers to control CGNs is not going to be deployed. I'd be happy to hear otherwise.

Accumulating state in the form of instructions from customers for of
durable port bindings is expensive forwarding state to accumulate,  It
is also expensive in the form of control-plane signalling. both of these
are DOS risks. I would think that they have similar shortcomings
respecting state as for example do multicast shared trees and would
likewise be viewed as an undesirable cost.

Joel

---

From: Richard Patterson <[email-masked]>
Date: Mon, 30 Apr 2018 08:58:35 +0000

I'd like to reword the UPnP section to shift the focus a bit.  The content
is largely the same, but it should now highlight that UPnP SHOULD be
disabled when implementing an IPv4aaS mechanism, with exceptions for the
stateless methods, and when configured with an address sharing ratio of 1.

I also received some off-list comments about how the CE landscape hasn't
really changed and embraced the IGD:2 specs yet.  This is unfortunate as it
means they also lack the AddPinhole() function to manipulate the native
IPv6 firewall, although that's off topic for this draft.
So with that in mind, and following on from Med's comments, I'd like to
also add a SHOULD support the IGD:2 specs, if a CE chooses to implement
UPnP.

New proposed wording for §5:

"""
5. UPnP Support   (Removed "IGD-PCP IWF")

UPnP SHOULD be disabled by default on the CE Router when using an IPv4aaS
transition mechanism.

UPnP MAY be enabled when a CE is configured to use a stateless IPv4aaS
mechanism that allows unsolicited inbound packets through to the CE, such
as MAP or LW4o6, or when configured with a port set containing all 65535
ports, e.g. with an IPv4 address sharing ratio of 1.

If UPnP is enabled on a CE, the UPnP agent MUST reject any port mapping
requests for ports outside of the port set allocated to the CE Router.

UPnP MAY also be enabled on a CE configured for IPv4aaS mechanisms that
support PCP [RFC6887], if implemented in conjunction with a method to
control the external port mapping, such as IGD-PCP IWF [RFC6970].

A CE that implements a UPnP agent, SHOULD support the Open Connectivity
Foundation's IGD:2 specification, including the AddAnyPortMapping()
function.
"""
On Fri, 27 Apr 2018 at 13:46, Richard Patterson <[email-masked]>

> > I know some applications are still using IGD:1, but I hope they will
move