Subject: [v6ops] new draft: draft-ietf-v6ops-6204bis

From: <[email-masked]>
Date: Tue, 11 Oct 2011 06:55:01 -0700 (PDT)

A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-6204bis. Please take a look at it and comment.

---

From: Maglione Roberta <[email-masked]>
Date: Tue, 11 Oct 2011 16:23:02 +0200

Hello,
a question for the authors:
 Do you have any plan to include the requirements for PCP in this draft?

Thanks,
Regards,
Roberta

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: martedì 11 ottobre 2011 15.55
To: [email-masked]
Cc: [email-masked]
Subject: [v6ops] new draft: draft-ietf-v6ops-6204bis

A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-6204bis. Please take a look at it and comment.
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: Fred Baker <[email-masked]>
Date: Tue, 11 Oct 2011 10:32:42 -0400

> Do you have any plan to include the requirements for PCP in this draft?

wearing the chair hat.

I'm not sure I detect a consensus behind the requirement for PCP. I personally would like to see it there, but I haven't heard a lot of commentary on that besides your request.

PCP is a protocol that would be used within the home to enable applications within the home to open holes in the firewall. The discussion at IETF-81 was that the characteristics of the LAN are now the province of homenet, and as such don't belong in this draft. This draft describes the characteristics of the CPE Router's WAN-facing side.

There is also an issue with PCP; it is currently a draft, and has not been sent to the IESG. Several operators have expressed some urgency for getting an RFC number on this so that they can include it in RFPs for managed routers. If we insert a normative reference to an internet draft, this cannot be published as an RFC until that draft is also published.

The working group can override me - if we see a number of operators asking for PCP to be mentioned in the draft, the authors will review that decision. But right now, that seems like a question for homenet.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 11 Oct 2011 11:01:23 -0400

Where I think we were was:
PCP as a LAN technology (from hosts to CE router) will not be included
in the draft. There's a lot of open issues and discussion around PCP vs.
UPnP, lack of host adoption, let the marketplace decide, etc.
PCP as a WAN technology (proxying UPnP IGD Port Forwarding, *if* the CE
router supports UPnP IGD) would be in scope of what we're trying to do,
but there's concern that the unpublished nature of PCP might hold things
up.

Barbara

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Fred Baker
> Sent: Tuesday, October 11, 2011 10:33 AM
> To: Maglione Roberta
> Cc: [email-masked]; [email-masked]
> Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis
> 
> 
> I'm not sure I detect a consensus behind the requirement for PCP. I
> personally would like to see it there, but I haven't heard a lot of
> commentary on that besides your request.
> 
> PCP is a protocol that would be used within the home to enable
> applications within the home to open holes in the firewall. The
> discussion at IETF-81 was that the characteristics of the LAN are now
> the province of homenet, and as such don't belong in this draft. This
> draft describes the characteristics of the CPE Router's WAN-facing
> side.
> 
> There is also an issue with PCP; it is currently a draft, and has not
> been sent to the IESG. Several operators have expressed some urgency
> for getting an RFC number on this so that they can include it in RFPs
> for managed routers. If we insert a normative reference to an internet
> draft, this cannot be published as an RFC until that draft is also
> published.
> 
> The working group can override me - if we see a number of operators
> asking for PCP to be mentioned in the draft, the authors will review
> that decision. But right now, that seems like a question for homenet.
> 
> > Thanks,
> > Regards,
> > Roberta

---

From: Maglione Roberta <[email-masked]>
Date: Wed, 12 Oct 2011 10:21:52 +0200

Hello Fred and Barbara,
  When a Carrier Grade NAT is deployed in the Service Provider's network PCP could be seen as the geographic extension of UPnP as it may be used in order to control how incoming packets are forwarded by the upstream device.

In my opinion PCP is not a topic strictly restricted to the homenet WG, but it may belong to this document as this draft already contains DS-Lite and PCP and DS-Lite could be use together in the Service Provider's network.

I understand the issue about the normative reference and I really would like to see an RFC number for it soon, as we are one the operator that expressed some urgency for that for the reasons you mentioned.

Regards,
Roberta

-----Original Message-----
From: STARK, BARBARA H [mailto:[email-masked]]
Sent: martedì 11 ottobre 2011 17.01
To: Fred Baker; Maglione Roberta
Cc: [email-masked]; [email-masked]
Subject: RE: [v6ops] new draft: draft-ietf-v6ops-6204bis

Barbara

---

From: Fred Baker <[email-masked]>
Date: Wed, 12 Oct 2011 04:45:58 -0400

Adding the PCP chairs and the authors of http://datatracker.ietf.org/doc/draft-ietf-pcp-base; folks, what is your plan for PCP?

Roberta, I understand now that you're looking at a WAN-side solution. Again, I'm looking for comment from other operators. But if we add it to this spec, I would like to see PCP in the IESG's hands as we send 6204bis in. I will note that this is about IPv4 life extension, not IPv6 deployment.

---

From: Fred Baker <[email-masked]>
Date: Wed, 12 Oct 2011 05:08:41 -0400

On Oct 12, 2011, at 4:45 AM, Fred Baker wrote:

> I will note that this is about IPv4 life extension, not IPv6 deployment.

I should take the time to explain that comment. The abstract of 6204bis reads

   This document specifies requirements for an IPv6 Customer Edge (CE)
   router.  Specifically, the current version of this document focuses
   on the basic provisioning of an IPv6 CE router and the provisioning
   of IPv6 hosts attached to it.

The draft is not about IPv4 CPE Routers, and I would not expect SP networks to implement CGN for IPv6 apart from short-term transitional mechanisms such as NAT64. So a discussion of PCP seems misplaced. Maybe you would like to contribute a draft on CPE Router implications for IPv4 CGN Networks...

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 12 Oct 2011 09:16:46 -0400

Hey Roberta,
Could you help us understand the timeframe of DS-Lite (and PCP)? I have
little visibility into DS-Lite deployments. I've been pushing for
DS-Lite support in the 6204bis draft, because I see a lot of interest in
it from European providers; so maybe you're in a better position to know
where it's at. Do you see deployments happening now, a year from now, 2
years from now? I'm trying to "bully" others into making sure we have
something published for technologies being deployed now, by insisting
that the "now" technologies must not be held back by the "next year"
technologies.
Thanks,
Barbara

---

From: Maglione Roberta <[email-masked]>
Date: Wed, 12 Oct 2011 15:57:07 +0200

Hi Barbara,
   the main issue we see today  for the DS-Lite deployment is exactly the DS-Lite support on the CPE.
We only have some prototypes CPE's with DS-Lite at the moment and that's why we are struggling to start with a deployment now.
You say you would prefer adding in the document "now" technologies and I understand that, but to me this sounds like a chicken and egg problem because CPE's vendors are reluctant to implement features if they don't have a RFC number.
So coming back to your question about the timeframe for DS-Lite deployment, I would say next year, but in my opinion if we want a deployment for next year we need an RFC now.
Thanks,
Best regards,
Roberta

-----Original Message-----
From: STARK, BARBARA H [mailto:[email-masked]]
Sent: mercoledì 12 ottobre 2011 15.17
To: Maglione Roberta; Fred Baker
Cc: [email-masked]; Ullio Mario
Subject: RE: [v6ops] new draft: draft-ietf-v6ops-6204bis

Hey Roberta,

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 12 Oct 2011 10:15:16 -0500

Roberta,

Note when you first asked for PCP in the CE rtr document two IETF's
back, we could not add the PCP because it was still not far from being
an RFC.  The CE rtr document is a Requirements document that does not
generally add an I-D reference.   Then during the last IETF you again
asked for PCP and during and after the IETF I contacted all relevant
people (authors of DS-Lite RFC) and vendors of commercial host operating
systems such as Microsoft and Apple.

Note, the WAN of the CE rtr has no use for a PCP client unless a host in
the LAN of the CE rtr initiates a PCP client request.  So I pinged host
vendors at Microsoft and Apple and one reply I got was no commercial
host OS currently supports a PCP client.  I suspect even host vendors
are waiting for PCP to become an RFC.  The PCP I-D did not pass two
LastCalls and I heard last from the Alain Durand that a 3rd LastCall
will be initiated.   This is a clear reason, why the CE rtr does not
include I-Ds and waits till an RFC.  

Further, when you say PCP, do you mean PCP Proxy or PCP server in the CE
rtr LAN?  PCP Proxy is not an RFC either.  The PCP client in the WAN of
the CE rtr is waiting for the PCP base document.  Thus, I would first
get both of PCP base and PCP Proxy to be RFCs.

Please let me know if we can do anything else that I may have missed.

Regards,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Maglione Roberta
Sent: Wednesday, October 12, 2011 9:57 AM
To: 'STARK, BARBARA H'; Fred Baker (fred)
Cc: [email-masked]; Ullio Mario
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

Hi Barbara,
   the main issue we see today  for the DS-Lite deployment is exactly
the DS-Lite support on the CPE.
We only have some prototypes CPE's with DS-Lite at the moment and that's
why we are struggling to start with a deployment now.
You say you would prefer adding in the document "now" technologies and I
understand that, but to me this sounds like a chicken and egg problem
because CPE's vendors are reluctant to implement features if they don't
have a RFC number.
So coming back to your question about the timeframe for DS-Lite
deployment, I would say next year, but in my opinion if we want a
deployment for next year we need an RFC now.
Thanks,
Best regards,
Roberta

---

From: Simon Perreault <[email-masked]>
Date: Wed, 12 Oct 2011 15:40:54 -0400

On 2011-10-11 10:32, Fred Baker wrote:
> for managed routers. If we insert a normative reference to an
> internet draft, this cannot be published as an RFC until that draft
> is also published.

On this point: we already have consensus in BEHAVE to make PCP a
requirement for the CGN requirements draft, even though the situation is
pretty much the same (operators wanting to quote an RFC number in RFPs).
So there's precedent.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Fred Baker <[email-masked]>
Date: Wed, 12 Oct 2011 16:59:26 -0400

> pretty much the same (operators wanting to quote an RFC number in RFPs).

Hmm. If there's a CGM requirements draft, does that extend to IPv4 CPE Routers appropriate in a CGN environment? If so, that might be the "IPv4 CGN" document I suggested Roberta write.

I'm not certain that an IPv6 CPE Routers document should be giving instructions for IPv4 CPE Routers... I'd personally rather keep this one clean and pull the rest into an IPv4-related draft. Color me biased.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 12 Oct 2011 17:17:40 -0400

> I'm not certain that an IPv6 CPE Routers document should be giving
> instructions for IPv4 CPE Routers... I'd personally rather keep this
> one clean and pull the rest into an IPv4-related draft. Color me
> biased.

That's ok. I'm biased too. Just differently. 

My bias is:
Extending the life of IPv4 and deploying IPv6 are not separate topics.
The same people are working on both, simultaneously, in order to provide
a holistic solution. While the access network may have many physical
components, and support connecting to different customers in a variety
of ways, it is engineered and designed as a whole. The vast majority of
consumer-grade customers aren't asking for IPv6 or IPv4. They want their
Internet connection to work. A single CE router must be able to provide
them with this working Internet connection. And since it all goes into
one CE router, it would be better if the CE router vendor could find it
in one document. The more places they have to look, the more likely it
is they'll miss something.

My preference is one document to describe all the stuff needed to
provide that working Internet connection.
We didn't need all the other IPv4 stuff, because we were working off an
assumption that CE router vendors already had that working, and weren't
looking for guidance.
I'd rather change the document scope than not provide guidance on new
capabilities that are critical for having a functioning Internet
connection.
Barbara

---

From: Fred Baker <[email-masked]>
Date: Wed, 12 Oct 2011 23:41:01 -0700

On Oct 12, 2011, at 9:39 PM, Stuart Cheshire wrote:

> On 12 Oct 2011, at 1:45, Fred Baker wrote:
> 
> From the beginning PCP has been designed as a protocol for managing port mappings in *all* NATs, both small-scale home NATs and large-scale carrier NATs.
> 
> I believe the protocol as we currently have it designed meets both those needs very well.
> 
> I don't see any need for different LAN and WAN protocols -- just as we don't have a LAN version and a WAN version of HTTP.

And the plan for the draft->IESG is... 2011? 2012? 2020? What?

> Stuart Cheshire <[email-masked]>
> * Wizard Without Portfolio, Apple Inc.
> * www.stuartcheshire.org
>

---

From: Maglione Roberta <[email-masked]>
Date: Thu, 13 Oct 2011 09:42:11 +0200

I agree with Barbara: it would be better to have all the requirements related to IPv4/IPv6 migration in a single document.
When we talk about IPv6 migration we always consider also the phase of IPv4/IPv6 co-existence in order to make the transition happening. I mentioned CGN, but what I had in mind is the DS-Lite case where CGN is embedded in the AFTR and PCP fits in this scenario.

Roberta

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of STARK, BARBARA H
Sent: mercoledì 12 ottobre 2011 23.18
To: Fred Baker; Simon Perreault
Cc: [email-masked]
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

My bias is:

---

From: Ole Troan <[email-masked]>
Date: Thu, 13 Oct 2011 09:52:14 +0200

Roberta,

> When we talk about IPv6 migration we always consider also the phase of IPv4/IPv6 co-existence in order to make the transition happening. I mentioned CGN, but what I had in mind is the DS-Lite case…

"Basic requirements for IPv4/IPv6 transition for CE routers"?

cheers,
Ole

---

From: Maglione Roberta <[email-masked]>
Date: Thu, 13 Oct 2011 09:56:08 +0200

It sounds good.

Roberta

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: giovedì 13 ottobre 2011 9.52
To: Maglione Roberta
Cc: 'STARK, BARBARA H'; Fred Baker; [email-masked]
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

Roberta,

cheers,
Ole

---

From: <[email-masked]>
Date: Thu, 13 Oct 2011 11:27:25 +0200

Dear all,

FT Group's IPv6 program recommends DS-Lite to address the need for IPV4 service continuity. From that standpoint, DS-Lite CGN deployments will ignite as soon as the end of this year for  some of the Group affiliates - including France, Poland and a couple of other countries of the AMEA zone. DS-Lite CGN deployment will be pursued over the next 2/3 years in the other Group affiliates - please note we co-authored the http://datatracker.ietf.org/doc/draft-lee-softwire-dslite-deployment/ draft to share operational experience and document best practice as far as Ds-Lite CGN design and operation are concerned.

DS-Lite-related capabilities (namely the support of RFC 2473 and 6334) as well as PCP capabilities (namely PCP Client and IGD/PCP proxy capabilities) are now *mandatory* features to be supported by the CPE devices we provide to our residential (fixed) customers.

We therefore strongly support the need to document DS-Lite requirements in the 6204bis draft, as per current Section 4.4.2.

Cheers,

Christian. 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de STARK, BARBARA H
Envoyé : mercredi 12 octobre 2011 15:17
À : Maglione Roberta; Fred Baker
Cc : [email-masked]; Ullio Mario
Objet : Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

Hey Roberta,
Could you help us understand the timeframe of DS-Lite (and PCP)? I have little visibility into DS-Lite deployments. I've been pushing for DS-Lite support in the 6204bis draft, because I see a lot of interest in it from European providers; so maybe you're in a better position to know where it's at. Do you see deployments happening now, a year from now, 2 years from now? I'm trying to "bully" others into making sure we have something published for technologies being deployed now, by insisting that the "now" technologies must not be held back by the "next year"
technologies.
Thanks,
Barbara
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

********************************************************************************
IMPORTANT.Les informations contenues dans ce message electronique y compris les fichiers attaches sont strictement confidentielles
et peuvent etre protegees par la loi.
Ce message electronique est destine exclusivement au(x) destinataire(s) mentionne(s) ci-dessus.
Si vous avez recu ce message par erreur ou s il ne vous est pas destine, veuillez immediatement le signaler  a l expediteur et effacer ce message 
et tous les fichiers eventuellement attaches.
Toute lecture, exploitation ou transmission des informations contenues dans ce message est interdite.
Tout message electronique est susceptible d alteration.
A ce titre, le Groupe France Telecom decline toute responsabilite notamment s il a ete altere, deforme ou falsifie.
De meme, il appartient au destinataire de s assurer de l absence de tout virus.

IMPORTANT.This e-mail message and any attachments are strictly confidential and may be protected by law. This message is
intended only for the named recipient(s) above.
If you have received this message in error, or are not the named recipient(s), please immediately notify the sender and delete this e-mail message.
Any unauthorized view, usage or disclosure ofthis message is prohibited.
Since e-mail messages may not be reliable, France Telecom Group shall not be liable for any message if modified, changed or falsified.
Additionally the recipient should ensure they are actually virus free.
********************************************************************************

---

From: Simon Perreault <[email-masked]>
Date: Thu, 13 Oct 2011 07:57:34 -0400

On 2011-10-12 16:59, Fred Baker wrote:
>> requirement for the CGN requirements draft, even though the
>> situation is pretty much the same (operators wanting to quote an
>> RFC number in RFPs). So there's precedent.
> 
> Hmm. If there's a CGM requirements draft, does that extend to IPv4
> CPE Routers appropriate in a CGN environment? If so, that might be
> the "IPv4 CGN" document I suggested Roberta write.

I'm talking about draft-ietf-behave-lsn-requirements, specifically this
part:

   REQ-9:  A CGN SHOULD include a Port Control Protocol server
           [I-D.ietf-pcp-base].

   Justification:  Allowing subscribers to manipulate the NAT state
      table with PCP greatly increases the likelihood that applications
      will function properly.

Since we're requiring PCP on the CGN, it might make sense to have a
matching requirement on the CPE side. Note that this document only
applies to IPv4 CGNs (and DS-Lite), not NAT64 nor NAT66.

> one clean and pull the rest into an IPv4-related draft. Color me

I for one don't see the point of a WAN-facing PCP client on an IPv6 CPE.
I do however see a lot of value in a LAN-facing PCP server, for firewall
control.

Simon

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 12 Oct 2011 21:39:39 -0700

---

From: <[email-masked]>
Date: Thu, 13 Oct 2011 11:21:59 +0200

Dear all,

Cheers,

Christian. 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de STARK, BARBARA H
Envoyé : mercredi 12 octobre 2011 15:17
À : Maglione Roberta; Fred Baker
Cc : [email-masked]; Ullio Mario
Objet : Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

Hey Roberta,

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 13 Oct 2011 12:03:13 -0700

> And the plan for the draft->IESG is... 2011? 2012? 2020? What?

Well, we're trying to wrap it up, but people keep adding new ideas, some of which are not good, so then it opens up whole new rounds of debate about whether to keep those new things or not.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 13 Oct 2011 12:39:26 -0700

On Wed, Oct 12, 2011 at 16:59, Fred Baker <[email-masked]> wrote:

> instructions for IPv4 CPE Routers... I'd personally rather keep this one
> clean and pull the rest into an IPv4-related draft. Color me biased.
>

Agreed. If I recall correctly, in Quebec consensus was that we should take
the 6204bis draft and split out a small, lightweight document that was close
to being done and only specified WAN side behaviour. That way we could
publish the document quickly, so as to unblock the deployments waiting on
it.

Holding this document writing new text about how PCP works is just going to
slow it down with no benefit. Why can't we just have this document go out
and put the PCP text, when it gets written, into a future document?

We already don't have a single document that explains what a CE router
manufacturer needs to do to implement a dual-stack gateway, but that's OK. I
think we all understand that in order for any device on the Internet to
work, any device needs to support more than one RFC.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 13 Oct 2011 18:28:40 -0700

...
> I for one don't see the point of a WAN-facing PCP client on an IPv6

If the IPv6 CPE is connected to a bandwidth-limited access link or 
a costly access link (e.g., wireless, satellite, dialup), there is 
benefit to have a firewall function 'upstream' of the access link.
Such a firewall function is already effectively deployed all 
of the world's 3G networks explicitly (as a firewall function) 
or implicitly (as a side-effect of how NAPT44 works), to protect
the network's air interface and avoid needless consumption of
subscriber's battery (to wake up, receive packet, and discard
it).

It's obvious if the CPE includes a wireless modem that it is
connected to such a link.  But any CPE could be connected to
such a link using a bridge or router.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 13 Oct 2011 21:51:27 -0700

> Of Lorenzo Colitti
> Sent: Thursday, October 13, 2011 12:39 PM
> To: Fred Baker
> 	I'm not certain that an IPv6 CPE Routers document should be
> giving instructions for IPv4 CPE Routers... I'd personally rather keep
> this one clean and pull the rest into an IPv4-related draft. Color me
> biased.
> 
> 
> Agreed. If I recall correctly, in Quebec consensus was that we should
> take the 6204bis draft and split out a small, lightweight document that
> was close to being done and only specified WAN side behaviour. That way
> we could publish the document quickly, so as to unblock the deployments
> waiting on it.

Agreed -- IPv4 doesn't belong.

> Holding this document writing new text about how PCP works is just
> going to slow it down with no benefit. Why can't we just have this
> document go out and put the PCP text, when it gets written, into a
> future document?

Er, but PCP is not just about IPv4 and PCP has never has been solely 
about IPv4.  See my other post at
http://www.ietf.org/mail-archive/web/v6ops/current/msg10665.html

> manufacturer needs to do to implement a dual-stack gateway, but that's
> OK. I think we all understand that in order for any device on the
> Internet to work, any device needs to support more than one RFC.

-d

---

From: <[email-masked]>
Date: Tue, 18 Oct 2011 17:40:37 +0200

Dear Fred, all,

As part of our DS-Lite deployment, PCP is a requirements for us. I strongly support including PCP in 6204bis.

Note that PCP is not only about IPv4 service continuity but also about IPv6... 

Cheers,
Med

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 18 Oct 2011 11:25:08 -0500

Mohamed,

Thanks for your feedback.  Please see this message I sent earlier on the PCP subject.

http://www.ietf.org/mail-archive/web/v6ops/current/msg10643.html

Fred as Chair has one suggestion.  During the IESG stage for the rfc6204bis document, we can consider adding PCP if PCP becomes an RFC by that timeframe.   The IPv6 CE router document has its hands tied.  I would work with the PCP and PCP proxy folks to get them to be RFC's ASAP.

Regards,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, October 18, 2011 11:41 AM
To: Fred Baker (fred); Maglione Roberta; [email-masked]; [email-masked]
Cc: [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP; [email-masked]; Ullio Mario
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

Dear Fred, all,

Cheers,
Med

---

From: <[email-masked]>
Date: Tue, 18 Oct 2011 18:55:36 +0200

Dear Hemant,

Because we have the same pressure at the PCP front, including the PCP-requirements in the 6204bis is more safe IMHO. There is a risk to forget inserting appropriate text during the IESG review. 

Cheers,
Med

-----Message d'origine-----
De : Hemant Singh (shemant) [mailto:[email-masked]] 
Envoyé : mardi 18 octobre 2011 18:25
À : BOUCADAIR Mohamed OLNC/NAD/TIP; Fred Baker (fred); Maglione Roberta; [email-masked]; [email-masked]
Cc : [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP; [email-masked]; Ullio Mario
Objet : RE: [v6ops] new draft: draft-ietf-v6ops-6204bis

Mohamed,

Regards,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, October 18, 2011 11:41 AM
To: Fred Baker (fred); Maglione Roberta; [email-masked]; [email-masked]
Cc: [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP; [email-masked]; Ullio Mario
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

Dear Fred, all,

Cheers,
Med

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 18 Oct 2011 12:33:45 -0500

Dear Med,

Sure, I do understand the need.  However, if say Windows hosts from Microsoft do not support a PCP client, then the IPv6 CE router has no client PCP request to proxy/serve to the SP CGN.  So is the CE router sniffing all unicast packets and inspecting ports in the packets to initiate PCP client requests from the CGN?  A use case would be good to articulate.  We will not forget during IESG review.  It's a sentence to add to the IPv6 CE router document such as "The IPv6 CE router SHOULD/MUST support a PCP Proxy/server on LAN interface(s) and a PCP Client in the WAN interface."  But the PCP base document needs to become a RFC ASAP.  Even if we add a normative reference to the PCP-base I-D in the rfc6204bis document, the rfc6204bis will stall in the RFC Editor Queue waiting for PCP-base to become an RFC. I have guidance from the Chairs to try and send the rfc6204bis document to the IESG ASAP.

Regards,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, October 18, 2011 12:56 PM
To: Hemant Singh (shemant); Fred Baker (fred); Maglione Roberta; [email-masked]; [email-masked]
Cc: [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP; [email-masked]; Ullio Mario
Subject: RE: [v6ops] new draft: draft-ietf-v6ops-6204bis

Dear Hemant,

Cheers,
Med

-----Message d'origine-----
De : Hemant Singh (shemant) [mailto:[email-masked]] 
Envoyé : mardi 18 octobre 2011 18:25
À : BOUCADAIR Mohamed OLNC/NAD/TIP; Fred Baker (fred); Maglione Roberta; [email-masked]; [email-masked]
Cc : [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP; [email-masked]; Ullio Mario
Objet : RE: [v6ops] new draft: draft-ietf-v6ops-6204bis

Mohamed,

Regards,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, October 18, 2011 11:41 AM
To: Fred Baker (fred); Maglione Roberta; [email-masked]; [email-masked]
Cc: [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP; [email-masked]; Ullio Mario
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

Dear Fred, all,

Cheers,
Med

---

From: james woodyatt <[email-masked]>
Date: Tue, 18 Oct 2011 11:40:30 -0700

On Oct 18, 2011, at 10:33 AM, Hemant Singh (shemant) wrote:
> 
>  But the PCP base document needs to become a RFC ASAP

The current revision, I-D.ietf-pcp-base-14 is unsuitable for the purposes described in REC-48 of RFC 6092, in my opinion.  I'm hoping that the forthcoming -15 revision will be acceptable, but I don't actually see it on the server yet, and some of the more authoritative participants in the working group are balking at being asked to consider a new revision of the draft.

One of the things that would help here is for the PCP working group to stop thinking that their job is done after they specify how ports are mapped for translation and address amplification with NAT44 and NAT64 and to start remembering that their draft actually purports to explain how PCP can meet REC-48 of RFC 6092 as well.  Every time I bring up a point that shows how their draft falls down on that point, they complain that nobody cares about IPv6 CPE routers, or transports other than TCP and UDP, or this, that or the other thing, and tell me they plan to fix it in the next round of RFC development.  Fortunately, the chair and the technical editor of the draft seem to be paying attention to the problems, but I do *NOT* feel at all comfortable that the community of PCP implementers is ready to consider simple security in IPv6 CPE routers.

I am very concerned that IPv6 CPE router vendors will rush out devices that contain early reference implementations of PCP, because it is standards track, but have simple security functions that are *MUCH* less transparent than the Informational category RFC 6092 recommends.  If this happens, then PCP servers in these ubiquitous and sure-to-never-be-upgraded home gateways will establish a conventional restriction on the transparency of IPv6 residential service that unnecessarily mimics the brokenness of IPv4/NAPT.  We should endeavor to avoid the possibility of a disaster like that, if at all possible, and I'm sensing a significant resistance to that concern among an influential cadre of PCP working group participants and implementers.

Therefore, I'd prefer that any update to RFC 6204 either wait for PCP to be revised appropriately in a second RFC, or that it not contain any recommendation for a PCP server at all.  Alternatively, the stakeholders in RFC 6204 could engage more directly with the PCP working group, so that Keith Moore and I are not the only ones speaking up in the defense of your interests.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Ole Troan <[email-masked]>
Date: Tue, 18 Oct 2011 21:48:36 +0200

James,

> Therefore, I'd prefer that any update to RFC 6204 either wait for PCP to be revised appropriately in a second RFC, or that it not contain any recommendation for a PCP server at all.  Alternatively,…

agree, and I don't see the rush for 6204bis.
asking CPE vendors to do 6204 + 5969 + 6333 isn't any harder than making them learn yet a new RFC number.
let's shelf 6204 until we have something real to put in there.

cheers,
Ole

---

From: "Weil, Jason" <[email-masked]>
Date: Tue, 18 Oct 2011 17:11:28 -0400

Fwiw my only interest in PCP today is to satisfy REC-48 type functionality in a native Dual-stack CPE Router with an IPv6 firewall enabled. We are specifying RFC6092 functionality today for home gateways and the two options on the table to allow applications to signal their requirements to firewall are (I thought) PCP and UPnP.  If PCP isn't ready to do this functionality fairly soon then it is becomes mostly  useless in my book and I will have to look elsewhere for that functionality. If it is close and we can get it included in 6204bis, it would make sense to wait for it.

Thanks,

Jason

From: [email-masked] [mailto:[email-masked]] On Behalf Of james woodyatt
Sent: Tuesday, October 18, 2011 2:41 PM
To: IPv6 Operations
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

--
james woodyatt <[email-masked]<mailto:[email-masked]>>
member of technical staff, core os networking

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 18 Oct 2011 17:42:44 -0400

In the 6204bis document, I'm only willing to consider the UPnP proxy +
WAN-side PCP. There are so many other uses of PCP, that I think it would
drag us down a rat-hole to try to specify all the other places where PCP
would need to be supported. And since there's no indication as to level
of support of PCP in LAN devices, I can't support its recommendation at
this time for LAN-side use. That needs to be a homenet topic. But I'd
only support this PCP requirement if PCP really were ready to become an
RFC. And it sounds like it isn't anywhere near to being ready. It sounds
like there are people who feel like there are a number of issues to
address.

I need 6rd now. If 6204bis is going to be hijacked by those who want to
describe all possible uses of PCP and insist on waiting for all issues
around PCP to be resolved, then let's just forget about it, and let me
figure out some non-IETF way to get out the message for 6rd. If others
want to wait a year or two to do some comprehensive transition
technology document, then y'all have at it. I've got more pressing
matters to deal with (like getting the word out now on 6rd). It sounds
like there's also a need to get out the word out on DS-Lite
requirements. I'm happy to include DS-Lite with 6rd, because DS-Lite has
stable RFCs. But if PCP is an absolute requirement for DS-Lite
(WAN-side? LAN-side? simple-security? NAT46? NAT64? NAT44? - I really
wish proponents of PCP would be extremely specific as to which aspect of
PCP they need, because when they aren't specific, I can only assume they
want it all, which I'm not ready to support), then I'm not happy to
include DS-Lite. Because (1) if there's a need for all LAN clients to
support PCP or UPnP in order for DS-Lite to be usable, then DS-Lite must
be a long way off, and (2) it sounds like publication of a PCP RFC is a
long way off.

My question to the DS-Lite proponents is:

Would you support DS-Lite requirements in a 6204bis without PCP
requirements?

If your answer is "No", then I think it's time for me to get 6rd
requirements published elsewhere. I've wasted too much time with the
expectation that IETF would be a good venue for these 6rd CE router
requirements, so I'd really like for there to be a decision soon.

Barbara

From: Weil, Jason [mailto:[email-masked]] 
Sent: Tuesday, October 18, 2011 5:11 PM
To: james woodyatt; IPv6 Operations
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: RE: [v6ops] new draft: draft-ietf-v6ops-6204bis

Fwiw my only interest in PCP today is to satisfy REC-48 type
functionality in a native Dual-stack CPE Router with an IPv6 firewall
enabled. We are specifying RFC6092 functionality today for home gateways
and the two options on the table to allow applications to signal their
requirements to firewall are (I thought) PCP and UPnP.  If PCP isn't
ready to do this functionality fairly soon then it is becomes mostly
useless in my book and I will have to look elsewhere for that
functionality. If it is close and we can get it included in 6204bis, it
would make sense to wait for it. 

Thanks,

Jason 

From: [email-masked] [mailto:[email-masked]] On Behalf
Of james woodyatt
Sent: Tuesday, October 18, 2011 2:41 PM
To: IPv6 Operations
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

The current revision, I-D.ietf-pcp-base-14 is unsuitable for the
purposes described in REC-48 of RFC 6092, in my opinion.  I'm hoping
that the forthcoming -15 revision will be acceptable, but I don't
actually see it on the server yet, and some of the more authoritative
participants in the working group are balking at being asked to consider
a new revision of the draft.

One of the things that would help here is for the PCP working group to
stop thinking that their job is done after they specify how ports are
mapped for translation and address amplification with NAT44 and NAT64
and to start remembering that their draft actually purports to explain
how PCP can meet REC-48 of RFC 6092 as well.  Every time I bring up a
point that shows how their draft falls down on that point, they complain
that nobody cares about IPv6 CPE routers, or transports other than TCP
and UDP, or this, that or the other thing, and tell me they plan to fix
it in the next round of RFC development.  Fortunately, the chair and the
technical editor of the draft seem to be paying attention to the
problems, but I do *NOT* feel at all comfortable that the community of
PCP implementers is ready to consider simple security in IPv6 CPE
routers.

I am very concerned that IPv6 CPE router vendors will rush out devices
that contain early reference implementations of PCP, because it is
standards track, but have simple security functions that are *MUCH* less
transparent than the Informational category RFC 6092 recommends.  If
this happens, then PCP servers in these ubiquitous and
sure-to-never-be-upgraded home gateways will establish a conventional
restriction on the transparency of IPv6 residential service that
unnecessarily mimics the brokenness of IPv4/NAPT.  We should endeavor to
avoid the possibility of a disaster like that, if at all possible, and
I'm sensing a significant resistance to that concern among an
influential cadre of PCP working group participants and implementers.

Therefore, I'd prefer that any update to RFC 6204 either wait for PCP to
be revised appropriately in a second RFC, or that it not contain any
recommendation for a PCP server at all.  Alternatively, the stakeholders
in RFC 6204 could engage more directly with the PCP working group, so
that Keith Moore and I are not the only ones speaking up in the defense
of your interests.

--

 

This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject
to copyright belonging to Time Warner Cable. This E-mail is intended
solely for the use of the individual or entity to which it is addressed.
If you are not the intended recipient of this E-mail, you are hereby
notified that any dissemination, distribution, copying, or action taken
in relation to the contents of and attachments to this E-mail is
strictly prohibited and may be unlawful. If you have received this
E-mail in error, please notify the sender immediately and permanently
delete the original and any copy of this E-mail and any printout.

---

From: <[email-masked]>
Date: Wed, 19 Oct 2011 10:39:08 +0200

Dear Barbara,

Speaking for our own DS-Lite deployment, PCP is mandatory to have. This is something we made clear to our DS-Lite vendors. Some of them support already PCP (based on version -13).

Cheers,
Med

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de STARK, BARBARA H
Envoyé : mardi 18 octobre 2011 23:43
À : Weil, Jason; james woodyatt; IPv6 Operations
Cc : [email-masked]
Objet : Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

In the 6204bis document, I'm only willing to consider the UPnP proxy + WAN-side PCP. There are so many other uses of PCP, that I think it would drag us down a rat-hole to try to specify all the other places where PCP would need to be supported. And since there's no indication as to level of support of PCP in LAN devices, I can't support its recommendation at this time for LAN-side use. That needs to be a homenet topic. But I'd only support this PCP requirement if PCP really were ready to become an RFC. And it sounds like it isn't anywhere near to being ready. It sounds like there are people who feel like there are a number of issues to address.

I need 6rd now. If 6204bis is going to be hijacked by those who want to describe all possible uses of PCP and insist on waiting for all issues around PCP to be resolved, then let's just forget about it, and let me figure out some non-IETF way to get out the message for 6rd. If others want to wait a year or two to do some comprehensive transition technology document, then y'all have at it. I've got more pressing matters to deal with (like getting the word out now on 6rd). It sounds like there's also a need to get out the word out on DS-Lite requirements. I'm happy to include DS-Lite with 6rd, because DS-Lite has stable RFCs. But if PCP is an absolute requirement for DS-Lite (WAN-side? LAN-side? simple-security? NAT46? NAT64? NAT44? - I really wish proponents of PCP would be extremely specific as to which aspect of PCP they need, because when they aren't specific, I can only assume they want it all, which I'm not ready to support), then I'm not happy to include DS-Lite. Because (1) if there's a need for all LAN clients to support PCP or UPnP in order for DS-Lite to be usable, then DS-Lite must be a long way off, and (2) it sounds like publication of a PCP RFC is a long way off.

My question to the DS-Lite proponents is:
Would you support DS-Lite requirements in a 6204bis without PCP requirements?

If your answer is "No", then I think it's time for me to get 6rd requirements published elsewhere. I've wasted too much time with the expectation that IETF would be a good venue for these 6rd CE router requirements, so I'd really like for there to be a decision soon.
Barbara

Thanks,

Jason

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 19 Oct 2011 07:22:12 -0500

DS-Lite folks,

Both you and Barbara have said rfc6204bis has to be out ASAP including
shooting for an RFC by end of this year.   Cmon, now, Barbara is on PTO
and she's had to reply during her time off!   PCP has issues if PCP does
not support REC-48 from RFC 6092.   I agree with Barbara.  If PCP will
delay rfc6204bis due to DS-Lite, we have no choice but to yank out
DS-Lite too.   We have guidance from the v6ops Chair to send the
document to the IESG ASAP.   We are already one month behind.    What is
it going to be?  DS-Lite included with no PCP or DS-Lite out since PCP
just is not near closure?    This thrashing has to stop. 

Hemant

From: [email-masked] [mailto:[email-masked]] On Behalf
Of STARK, BARBARA H
Sent: Tuesday, October 18, 2011 5:43 PM
To: Weil, Jason; james woodyatt; IPv6 Operations
Cc: [email-masked]
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

Barbara

Thanks,

Jason 

 

--

---

From: Maglione Roberta <[email-masked]>
Date: Wed, 19 Oct 2011 16:51:30 +0200

DS-lite must be included in this document now, we need DS-Lite support on CPE.
I'm ok with your original proposal to add PCP during the IESG review if PCP becomes stable.

Regards,
Roberta

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hemant Singh (shemant)
Sent: mercoledì 19 ottobre 2011 14.22
To: STARK, BARBARA H; Weil, Jason; james woodyatt; IPv6 Operations
Cc: [email-masked]
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

DS-Lite folks,

Both you and Barbara have said rfc6204bis has to be out ASAP including shooting for an RFC by end of this year.   Cmon, now, Barbara is on PTO and she's had to reply during her time off!   PCP has issues if PCP does not support REC-48 from RFC 6092.   I agree with Barbara.  If PCP will delay rfc6204bis due to DS-Lite, we have no choice but to yank out DS-Lite too.   We have guidance from the v6ops Chair to send the document to the IESG ASAP.   We are already one month behind.    What is it going to be?  DS-Lite included with no PCP or DS-Lite out since PCP just is not near closure?    This thrashing has to stop.

Hemant

Thanks,

Jason

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 19 Oct 2011 10:49:31 -0500

Alain, Roberta, Med, and other DS-Lite folks,

Remember I am the primary person who supported you to add DS-Lite to the
CE router document.  Please understand that if the rfc6204bis document
gets delayed to not head out as an RFC by end of this year, there are
other IP transition techs that are itching to get into the document if
the document gets delayed.  These are techs such as 4rd and dIVI.  With
additional transition tech the document will get more complex and get
delayed to end of 2012.  Thus we will be stepping on our own toes if we
delay the document beyond next few weeks to head out to the IESG so that
the document has a chance to be an RFC by end of this year.  Please also
note, we are going to work on another new document after rfc6204bis
heads to the IESG where the new document will cover pending items such
as MLD Proxy, UPnP, any new transition tech, etc. 

Also, Alain or anyone on the PCP-base document, can you please confirm
if the current PCP-15 supports REC-48 from RFC 6092 that James raised
for an issue?  James, I, Wes Beebee and Jason Weil have already said,
the PCP protocol has got to support the REC-48.

Hemant

-----Original Message-----
From: Alain Durand [mailto:[email-masked]] 
Sent: Wednesday, October 19, 2011 10:54 AM
To: Hemant Singh (shemant)
Cc: STARK, BARBARA H; Weil, Jason; james woodyatt; IPv6 Operations;
[email-masked]
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

Hemant,

I believe the issues around PCP not being ready are overstated. We have
a document (-15) ready for another round of wg last call to be started
this week.

Alain.

On Oct 19, 2011, at 8:22 AM, Hemant Singh (shemant) wrote:

DS-Lite folks,

Hemant

From: [email-masked]<mailto:[email-masked]>
[mailto:[email-masked]] On Behalf Of STARK, BARBARA H
Sent: Tuesday, October 18, 2011 5:43 PM
To: Weil, Jason; james woodyatt; IPv6 Operations
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

From: Weil, Jason [mailto:[email-masked]]
Sent: Tuesday, October 18, 2011 5:11 PM
To: james woodyatt; IPv6 Operations
Cc: [email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[email-masked]
.org>;
[email-masked]<mailto:draft-ietf-v6ops-6204bis@
tools.ietf.org>
Subject: RE: [v6ops] new draft: draft-ietf-v6ops-6204bis

Thanks,

Jason

From: [email-masked]<mailto:[email-masked]>
[mailto:[email-masked]] On Behalf Of james woodyatt
Sent: Tuesday, October 18, 2011 2:41 PM
To: IPv6 Operations
Cc: [email-masked]<mailto:[email-masked]>;
[email-masked]<mailto:[email-masked]
.org>;
[email-masked]<mailto:draft-ietf-v6ops-6204bis@
tools.ietf.org>
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

---

From: james woodyatt <[email-masked]>
Date: Wed, 19 Oct 2011 12:36:04 -0700

On Oct 19, 2011, at 7:54 AM, Alain Durand wrote:
> 
> I believe the issues around PCP not being ready are overstated. We have a document (-15) ready for another round of wg last call to be started this week.

If the -15 revision that I've seen previewed goes into WGLC, then I will agree that PCP is ready for meeting REC-48 of RFC 6092.  The -14 revision is not ready.

---

From: Wes Beebee <[email-masked]>
Date: Wed, 19 Oct 2011 15:49:28 -0400

>> I believe the issues around PCP not being ready are overstated. We have a
document (-15) ready for another round of wg last call to be started this week.

> If the -15 revision that I've seen previewed goes into WGLC, then I will agree
that PCP is ready for meeting REC-48 of RFC 6092.  The -14 revision is not
ready.

Congratulations!!!  I await with baited breath...

- Wes

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 19 Oct 2011 15:57:49 -0500

Congratulations from me as well!

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Wes Beebee (wbeebee)
Sent: Wednesday, October 19, 2011 3:49 PM
To: james woodyatt; IPv6 Operations; [email-masked]
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

>> I believe the issues around PCP not being ready are overstated. We
have a
document (-15) ready for another round of wg last call to be started
this week.

> If the -15 revision that I've seen previewed goes into WGLC, then I
will agree
that PCP is ready for meeting REC-48 of RFC 6092.  The -14 revision is
not
ready.

- Wes

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 19 Oct 2011 16:58:29 -0400

Hey Med,

There are many things that service providers make mandatory on routers they procure and provide to customers, that are not necessarily found on retail CE routers. Given your answer, my questions would be (1) Do you expect to allow customers to use their own CE router that they purchase at retail, that is not associated with your service, and (2) if so, would you tell customers that support for PCP in such retail-purchased routers is mandatory - they will not be allowed to connect, or the DS-Lite service won't work right, if there is no PCP support in the CE router.

The 6rd requirements that I'm pushing for are such that the service may not work (i.e., non-functioning or broken IPv6 connectivity via 6rd) if the requirements aren't implemented. That's why they're so important to me. I really have a hard time believing that this is true of PCP (WAN, LAN, or wherever) in the context of DS-Lite.

Barbara

Sent: Wednesday, October 19, 2011 4:39 AM

Dear Barbara,

Cheers,

Med

Barbara

Thanks,

Jason 

 

--

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 18 Oct 2011 14:17:27 -0500

From: james woodyatt [mailto:[email-masked]] 
Sent: Tuesday, October 18, 2011 2:27 PM
To: Hemant Singh (shemant)
Cc: [email-masked]; Fred Baker (fred); Maglione Roberta; [email-masked]; [email-masked]; [email-masked]; Ullio Mario; [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

>One of the things that would help here is for the PCP working group to stop thinking that their job is done after they specify how ports are mapped for translation and address amplification with NAT44 and >NAT64 and to start remembering that their draft actually purports to explain how PCP can meet REC-48 of RFC 6092 as well.  

I am in total agreement with James.   Right now I access my Linux desktop at home from work.  With CGN deployed this important and simple use case breaks.  PCP has got to support REC-48 of RFC 6092.  

Hemant

---

From: Wes Beebee <[email-masked]>
Date: Tue, 18 Oct 2011 15:20:09 -0400

>>> stop thinking that their job is done after they specify how ports are mapped
>>> for translation and address amplification with NAT44 and >NAT64 and to start
>>> remembering that their draft actually purports to explain how PCP can meet
>>> REC-48 of RFC 6092 as well.
>  
>> >I am in total agreement with James.   Right now I access my Linux desktop at
>> home from work.  With CGN deployed this important and simple use case
>> breaks.  PCP has got to support REC-48 of RFC 6092. 
>  
> +1
> 
> I have a similar problem with my Network Attached Storage at home and the CGN
> my service provider may deploy.
>  
> - Wes

---

From: Alain Durand <[email-masked]>
Date: Wed, 19 Oct 2011 07:54:11 -0700

Hemant,

Alain.

DS-Lite folks,

Both you and Barbara have said rfc6204bis has to be out ASAP including shooting for an RFC by end of this year.   Cmon, now, Barbara is on PTO and she’s had to reply during her time off!   PCP has issues if PCP does not support REC-48 from RFC 6092.   I agree with Barbara.  If PCP will delay rfc6204bis due to DS-Lite, we have no choice but to yank out DS-Lite too.   We have guidance from the v6ops Chair to send the document to the IESG ASAP.   We are already one month behind.    What is it going to be?  DS-Lite included with no PCP or DS-Lite out since PCP just is not near closure?    This thrashing has to stop.

Hemant

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of STARK, BARBARA H

In the 6204bis document, I’m only willing to consider the UPnP proxy + WAN-side PCP. There are so many other uses of PCP, that I think it would drag us down a rat-hole to try to specify all the other places where PCP would need to be supported. And since there’s no indication as to level of support of PCP in LAN devices, I can’t support its recommendation at this time for LAN-side use. That needs to be a homenet topic. But I’d only support this PCP requirement if PCP really were ready to become an RFC. And it sounds like it isn’t anywhere near to being ready. It sounds like there are people who feel like there are a number of issues to address.

I need 6rd now. If 6204bis is going to be hijacked by those who want to describe all possible uses of PCP and insist on waiting for all issues around PCP to be resolved, then let’s just forget about it, and let me figure out some non-IETF way to get out the message for 6rd. If others want to wait a year or two to do some comprehensive transition technology document, then y’all have at it. I’ve got more pressing matters to deal with (like getting the word out now on 6rd). It sounds like there’s also a need to get out the word out on DS-Lite requirements. I’m happy to include DS-Lite with 6rd, because DS-Lite has stable RFCs. But if PCP is an absolute requirement for DS-Lite (WAN-side? LAN-side? simple-security? NAT46? NAT64? NAT44? – I really wish proponents of PCP would be extremely specific as to which aspect of PCP they need, because when they aren’t specific, I can only assume they want it all, which I’m not ready to support), then I’m not happy to include DS-Lite. Because (1) if there’s a need for all LAN clients to support PCP or UPnP in order for DS-Lite to be usable, then DS-Lite must be a long way off, and (2) it sounds like publication of a PCP RFC is a long way off.

If your answer is “No”, then I think it’s time for me to get 6rd requirements published elsewhere. I’ve wasted too much time with the expectation that IETF would be a good venue for these 6rd CE router requirements, so I’d really like for there to be a decision soon.
Barbara

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

Fwiw my only interest in PCP today is to satisfy REC-48 type functionality in a native Dual-stack CPE Router with an IPv6 firewall enabled. We are specifying RFC6092 functionality today for home gateways and the two options on the table to allow applications to signal their requirements to firewall are (I thought) PCP and UPnP.  If PCP isn’t ready to do this functionality fairly soon then it is becomes mostly  useless in my book and I will have to look elsewhere for that functionality. If it is close and we can get it included in 6204bis, it would make sense to wait for it.

Thanks,

Jason

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of james woodyatt
Sent: Tuesday, October 18, 2011 2:41 PM
To: IPv6 Operations
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 19 Oct 2011 17:21:41 -0500

Dear Med and other DS-Lite folks,

If someone can answer my use case question below related to PCP I'd appreciate it.  We need a use case so that I can plan specific text related to PCP for the IPv6 CE router document.

Thanks,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hemant Singh (shemant)
Sent: Tuesday, October 18, 2011 1:34 PM
To: [email-masked]; Fred Baker (fred); Maglione Roberta; [email-masked]; [email-masked]
Cc: [email-masked]; Ullio Mario; [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

Dear Med,

Regards,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, October 18, 2011 12:56 PM
To: Hemant Singh (shemant); Fred Baker (fred); Maglione Roberta; [email-masked]; [email-masked]
Cc: [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP; [email-masked]; Ullio Mario
Subject: RE: [v6ops] new draft: draft-ietf-v6ops-6204bis

Dear Hemant,

Cheers,
Med

-----Message d'origine-----
De : Hemant Singh (shemant) [mailto:[email-masked]] 
Envoyé : mardi 18 octobre 2011 18:25
À : BOUCADAIR Mohamed OLNC/NAD/TIP; Fred Baker (fred); Maglione Roberta; [email-masked]; [email-masked]
Cc : [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP; [email-masked]; Ullio Mario
Objet : RE: [v6ops] new draft: draft-ietf-v6ops-6204bis

Mohamed,

Regards,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, October 18, 2011 11:41 AM
To: Fred Baker (fred); Maglione Roberta; [email-masked]; [email-masked]
Cc: [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP; [email-masked]; Ullio Mario
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

Dear Fred, all,

Cheers,
Med

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 19 Oct 2011 18:34:13 -0400

If windows does not implement PCP Client then the option is to implement:

- UPnP/NAT-PMP - PCP IWF

http://tools.ietf.org/html/draft-bpw-pcp-upnp-igd-interworking-02

I mean, assuming there is an application that wants to open ports.

Thanks,

Reinaldo

On 10/19/11 3:21 PM, "Hemant Singh (shemant)" <[email-masked]> wrote:

> If someone can answer my use case question below related to PCP I'd appreciate
> it.  We need a use case so that I can plan specific text related to PCP for
> the IPv6 CE router document.
> 
> Thanks,
> 
> Hemant
> 
> To: [email-masked]; Fred Baker (fred); Maglione Roberta;
> [email-masked]; [email-masked]
> Sure, I do understand the need.  However, if say Windows hosts from Microsoft
> do not support a PCP client, then the IPv6 CE router has no client PCP request
> to proxy/serve to the SP CGN.  So is the CE router sniffing all unicast
> packets and inspecting ports in the packets to initiate PCP client requests
> from the CGN?  A use case would be good to articulate.  We will not forget
> during IESG review.  It's a sentence to add to the IPv6 CE router document
> such as "The IPv6 CE router SHOULD/MUST support a PCP Proxy/server on LAN
> interface(s) and a PCP Client in the WAN interface."  But the PCP base
> document needs to become a RFC ASAP.  Even if we add a normative reference to
> the PCP-base I-D in the rfc6204bis document, the rfc6204bis will stall in the
> RFC Editor Queue waiting for PCP-base to become an RFC. I have guidance from
> the Chairs to try and send the rfc6204bis document to the IESG ASAP.
> 
> Regards,
> 
> Hemant
> 
> To: Hemant Singh (shemant); Fred Baker (fred); Maglione Roberta;
> [email-masked]; [email-masked]
> Cc: [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP;
> [email-masked]; Ullio Mario
> Because we have the same pressure at the PCP front, including the
> PCP-requirements in the 6204bis is more safe IMHO. There is a risk to forget
> inserting appropriate text during the IESG review.
> 
> Cheers,
> Med
> 
> À : BOUCADAIR Mohamed OLNC/NAD/TIP; Fred Baker (fred); Maglione Roberta;
> [email-masked]; [email-masked]
> Cc : [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP;
> [email-masked]; Ullio Mario
> Fred as Chair has one suggestion.  During the IESG stage for the rfc6204bis
> document, we can consider adding PCP if PCP becomes an RFC by that timeframe.
> The IPv6 CE router document has its hands tied.  I would work with the PCP and
> PCP proxy folks to get them to be RFC's ASAP.
> 
> Regards,
> 
> Hemant
> 
> Cc: [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP;
> [email-masked]; Ullio Mario

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 19 Oct 2011 18:13:53 -0500

Reinaldo,

Thanks, understood.  However, my question to the DS-Lite folks is still not answered because I was told by them that DS-Lite needs PCP.  So then I asked what if the Windows host behind the CE router does not support a PCP client, then what is the PCP server/proxy inside the CE router do for DS-Lite?

Thus my question is still un-answered.

Hemant

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]] 
Sent: Wednesday, October 19, 2011 6:34 PM
To: Hemant Singh (shemant); [email-masked]; Fred Baker (fred); Maglione Roberta; [email-masked]; [email-masked]
Cc: [email-masked]; Ullio Mario; [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

- UPnP/NAT-PMP - PCP IWF

Thanks,

Reinaldo

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 19 Oct 2011 19:12:41 -0700

> Sent: Wednesday, October 19, 2011 1:58 PM
> To: [email-masked]; Weil, Jason; james woodyatt; IPv6
> Operations
> There are many things that service providers make mandatory on routers
> they procure and provide to customers, that are not necessarily found
> on retail CE routers. Given your answer, my questions would be (1) Do
> you expect to allow customers to use their own CE router that they
> purchase at retail, that is not associated with your service, and (2)
> if so, would you tell customers that support for PCP in such retail-
> purchased routers is mandatory – they will not be allowed to connect,
> or the DS-Lite service won’t work right, if there is no PCP support in
> the CE router.
> 
> 
> 
> The 6rd requirements that I’m pushing for are such that the service may
> not work (i.e., non-functioning or broken IPv6 connectivity via 6rd) if
> the requirements aren’t implemented. That’s why they’re so important to
> me. I really have a hard time believing that this is true of PCP (WAN,
> LAN, or wherever) in the context of DS-Lite.

A Dual Stack-Lite CPE provides both IPv4 and IPv6 service to subscribers.
RFC6092 recommends that IPv6 service block incoming unsolicited traffic
from the Internet (except allow IKE and IPsec), so that IPv6 service 
functions like today's NAPT44 which filter incoming traffic.  RFC6092 
also suggests a protocol be deployed so that the IPv6 hosts can 
indicate they want to receive incoming unsolicited IPv6 traffic.

If the Dual Stack-Lite CPE do RFC6092-recommended filtering, the CPE
will only work with outgoing (client-initiated) connections.

... So: if we want an IPv6 Internet that provides end-to-end 
addressability and connectivity, users (a) need to deploy no 
IPv6 filtering (which seems a difficult proposition, based on the
deployment experience of both Apple and Linksys) or (b) we need a
protocol to open IPv6 filters.

The only protocols that I'm aware of that allow the host to open
its CPE's IPv6 filters are are PCP and UPnP IGD version 2.

If we don't want an IPv6 Internet that provides end-to-end
addressability and connectivity, we don't need PCP and 
don't need UPnP IGD version 2.

-d

> Speaking for our own DS-Lite deployment, PCP is mandatory to have. This
> is something we made clear to our DS-Lite vendors. Some of them support
> already PCP (based on version -13).
> 
> 
> 
> Cheers,
> 
> Med
> 
> 
> 
> In the 6204bis document, I’m only willing to consider the UPnP proxy +
> WAN-side PCP. There are so many other uses of PCP, that I think it
> would drag us down a rat-hole to try to specify all the other places
> where PCP would need to be supported. And since there’s no indication
> as to level of support of PCP in LAN devices, I can’t support its
> recommendation at this time for LAN-side use. That needs to be a
> homenet topic. But I’d only support this PCP requirement if PCP really
> were ready to become an RFC. And it sounds like it isn’t anywhere near
> to being ready. It sounds like there are people who feel like there are
> a number of issues to address.
> 
> 
> 
> around PCP to be resolved, then let’s just forget about it, and let me
> technology document, then y’all have at it. I’ve got more pressing
> like there’s also a need to get out the word out on DS-Lite
> requirements. I’m happy to include DS-Lite with 6rd, because DS-Lite
> has stable RFCs. But if PCP is an absolute requirement for DS-Lite
> (WAN-side? LAN-side? simple-security? NAT46? NAT64? NAT44? – I really
> wish proponents of PCP would be extremely specific as to which aspect
> of PCP they need, because when they aren’t specific, I can only assume
> they want it all, which I’m not ready to support), then I’m not happy
> to include DS-Lite. Because (1) if there’s a need for all LAN clients
> to support PCP or UPnP in order for DS-Lite to be usable, then DS-Lite
> must be a long way off, and (2) it sounds like publication of a PCP RFC
> is a long way off.
> 
> 
> 
> If your answer is “No”, then I think it’s time for me to get 6rd
> requirements published elsewhere. I’ve wasted too much time with the
> requirements, so I’d really like for there to be a decision soon.
> 
> Barbara
> 
> 
> 
> enabled. We are specifying RFC6092 functionality today for home
> gateways and the two options on the table to allow applications to
> signal their requirements to firewall are (I thought) PCP and UPnP.  If
> PCP isn’t ready to do this functionality fairly soon then it is becomes
> mostly  useless in my book and I will have to look elsewhere for that
> participants in the working group are balking at being asked to
> consider a new revision of the draft.
> 
> 
> 
> point that shows how their draft falls down on that point, they
> complain that nobody cares about IPv6 CPE routers, or transports other
> than TCP and UDP, or this, that or the other thing, and tell me they
> plan to fix it in the next round of RFC development.  Fortunately, the
> chair and the technical editor of the draft seem to be paying attention
> to the problems, but I do *NOT* feel at all comfortable that the
> community of PCP implementers is ready to consider simple security in
> IPv6 CPE routers.
> 
> 
> 
> standards track, but have simple security functions that are *MUCH*
> less transparent than the Informational category RFC 6092 recommends.
> If this happens, then PCP servers in these ubiquitous and sure-to-
> never-be-upgraded home gateways will establish a conventional
> unnecessarily mimics the brokenness of IPv4/NAPT.  We should endeavor
> to avoid the possibility of a disaster like that, if at all possible,
> and I'm sensing a significant resistance to that concern among an
> Therefore, I'd prefer that any update to RFC 6204 either wait for PCP
> to be revised appropriately in a second RFC, or that it not contain any
> recommendation for a PCP server at all.  Alternatively, the
> stakeholders in RFC 6204 could engage more directly with the PCP
> working group, so that Keith Moore and I are not the only ones speaking
> up in the defense of your interests.
> 
> 
> 
> 
> 
> --
> 
> solely for the use of the individual or entity to which it is
> addressed. If you are not the intended recipient of this E-mail, you
> are hereby notified that any dissemination, distribution, copying, or
> action taken in relation to the contents of and attachments to this E-
> mail is strictly prohibited and may be unlawful. If you have received
> this E-mail in error, please notify the sender immediately and
> permanently delete the original and any copy of this E-mail and any
> printout.

---

From: <[email-masked]>
Date: Thu, 20 Oct 2011 09:54:02 +0200

Dear all,

As a response to Barbara's questions:

(1) Customers are indeed allowed to use off-the-shelf CPE devices, as long as these CPE devices comply with what we call the "Service Access Technical Specifications" (STAS in French) which document the features that should/must be supported by a CPE to properly access the services we provide.

(2) Indeed, the support of PCP will be part of these mandatory CPE features. This will be documented with some educational wording about the role of PCP and how PCP will make sure that some of the services provided by FT/Orange can still be accessed, let alone user-generated contents, obviously.

Cheers,

Christian.

________________________________
De : [email-masked] [mailto:[email-masked]] De la part de STARK, BARBARA H
Envoyé : mercredi 19 octobre 2011 22:58
À : BOUCADAIR Mohamed OLNC/NAD/TIP; Weil, Jason; james woodyatt; IPv6 Operations
Objet : Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

Hey Med,

Dear Barbara,

Cheers,
Med

Thanks,

Jason

---

From: Ole Troan <[email-masked]>
Date: Thu, 20 Oct 2011 10:20:56 +0200

Roberta,

> I’m ok with your original proposal to add PCP during the IESG review if PCP becomes stable.

I don't quite understand; why wouldn't you get DS-lite support on CPEs by stating RFC6204 + RFC6333?
would having a new RFC6x04 change how the CPE industry looks at DS-lite?

btw: I've send a comment to the IPv6 CE ready programme (UNH/IPv6 forum) to have both 6rd and DS-lite added as a part of their
logo programme.

cheers,
Ole

> <logo Ambiente_foglia.jpg>Rispetta l'ambiente. Non stampare questa mail se non è necessario.
> 
> <logo Ambiente_foglia.jpg>_______________________________________________
> v6ops mailing list
> [email-masked]

---

From: <[email-masked]>
Date: Thu, 20 Oct 2011 12:02:53 +0200

Dear Hemant,

For that case, we are considering:

* Enable a UPnP IGD/PCP Interworking function as specified for instance in: http://tools.ietf.org/html/draft-bpw-pcp-upnp-igd-interworking-02

* Just like current port forwarding in existing CPEs, we are envisaging to allow the configuration of port mappings using a User Interface. This will trigger PCP messages to be sent to the PCP Server controlling the DS-Lite AFTR.

For those who want to play with the PCP Client UI and IGD/PCP IWF, we made a code available at: http://opensourceaplusp.weebly.com/.

Hope this answers your question.

Cheers
Med 

-----Message d'origine-----
De : Hemant Singh (shemant) [mailto:[email-masked]] 
Envoyé : jeudi 20 octobre 2011 01:14
À : Reinaldo Penno; BOUCADAIR Mohamed OLNC/NAD/TIP; Fred Baker (fred); Maglione Roberta; [email-masked]; [email-masked]
Cc : [email-masked]; Ullio Mario; [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP
Objet : RE: [v6ops] new draft: draft-ietf-v6ops-6204bis

Reinaldo,

Hemant

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]] 
Sent: Wednesday, October 19, 2011 6:34 PM
To: Hemant Singh (shemant); [email-masked]; Fred Baker (fred); Maglione Roberta; [email-masked]; [email-masked]
Cc: [email-masked]; Ullio Mario; [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

- UPnP/NAT-PMP - PCP IWF

Thanks,

Reinaldo

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 20 Oct 2011 07:24:47 -0500

Med,  DanW, and Reinaldo,

Thanks for all your clarifications.  The rfc6204bis document does not support UPnP for a feature and that is why I was wondering what would be the use case for PCP if the host behind the CE router does not support PCP.  Now that I know you all are referring to UPnP, Barbara has already responded that she is willing to consider PCP client on the CE router WAN with UPnP.  I agree with her.  What IPv6 UPnP document is in RFC form right now for the CE router to consider UPnP?

Regards,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 20, 2011 6:01 AM
To: Hemant Singh (shemant); Reinaldo Penno; Fred Baker (fred); Maglione Roberta; [email-masked]; [email-masked]
Cc: [email-masked]; Ullio Mario; [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP
Subject: RE: [v6ops] new draft: draft-ietf-v6ops-6204bis

Dear Hemant,

Cheers
Med 

-----Message d'origine-----
De : Hemant Singh (shemant) [mailto:[email-masked]] 
Envoyé : jeudi 20 octobre 2011 01:14
À : Reinaldo Penno; BOUCADAIR Mohamed OLNC/NAD/TIP; Fred Baker (fred); Maglione Roberta; [email-masked]; [email-masked]
Cc : [email-masked]; Ullio Mario; [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP
Objet : RE: [v6ops] new draft: draft-ietf-v6ops-6204bis

Reinaldo,

Hemant

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]] 
Sent: Wednesday, October 19, 2011 6:34 PM
To: Hemant Singh (shemant); [email-masked]; Fred Baker (fred); Maglione Roberta; [email-masked]; [email-masked]
Cc: [email-masked]; Ullio Mario; [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

- UPnP/NAT-PMP - PCP IWF

Thanks,

Reinaldo

---

From: <[email-masked]>
Date: Thu, 20 Oct 2011 14:32:50 +0200

Re-,

Not all the use cases require UPnP IGD; in particular see what I mentioned earlier:

"* Just like current port forwarding in existing CPEs, we are envisaging to allow the configuration of port mappings using a User Interface. This will trigger PCP messages to be sent to the PCP Server controlling the DS-Lite AFTR."

Cheers,
Med

-----Message d'origine-----
De : Hemant Singh (shemant) [mailto:[email-masked]] 
Envoyé : jeudi 20 octobre 2011 14:25
À : BOUCADAIR Mohamed OLNC/NAD/TIP; Reinaldo Penno; Fred Baker (fred); Maglione Roberta; Alain Durand
Cc : [email-masked]; Ullio Mario; [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP
Objet : RE: [v6ops] new draft: draft-ietf-v6ops-6204bis

Med,  DanW, and Reinaldo,

Regards,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 20, 2011 6:01 AM
To: Hemant Singh (shemant); Reinaldo Penno; Fred Baker (fred); Maglione Roberta; [email-masked]; [email-masked]
Cc: [email-masked]; Ullio Mario; [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP
Subject: RE: [v6ops] new draft: draft-ietf-v6ops-6204bis

Dear Hemant,

Cheers
Med 

-----Message d'origine-----
De : Hemant Singh (shemant) [mailto:[email-masked]] 
Envoyé : jeudi 20 octobre 2011 01:14
À : Reinaldo Penno; BOUCADAIR Mohamed OLNC/NAD/TIP; Fred Baker (fred); Maglione Roberta; [email-masked]; [email-masked]
Cc : [email-masked]; Ullio Mario; [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP
Objet : RE: [v6ops] new draft: draft-ietf-v6ops-6204bis

Reinaldo,

Hemant

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]] 
Sent: Wednesday, October 19, 2011 6:34 PM
To: Hemant Singh (shemant); [email-masked]; Fred Baker (fred); Maglione Roberta; [email-masked]; [email-masked]
Cc: [email-masked]; Ullio Mario; [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

- UPnP/NAT-PMP - PCP IWF

Thanks,

Reinaldo

---

From: Tina TSOU <[email-masked]>
Date: Thu, 20 Oct 2011 13:37:48 +0000

+1
Yes, the Internet Gateway Device (IGD) machinery is used between computer and UPnP/IGD to request the allocation of a port number to the CPE so that a pinhole can be created accordingly to allow access to the content requested by the terminal from the Internet.

Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Thursday, October 20, 2011 2:33 PM
To: Hemant Singh (shemant)
Cc: [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP; [email-masked]; Ullio Mario
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

Re-,

Cheers,
Med

-----Message d'origine-----
De : Hemant Singh (shemant) [mailto:[email-masked]] 
Envoyé : jeudi 20 octobre 2011 14:25
À : BOUCADAIR Mohamed OLNC/NAD/TIP; Reinaldo Penno; Fred Baker (fred); Maglione Roberta; Alain Durand
Cc : [email-masked]; Ullio Mario; [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP
Objet : RE: [v6ops] new draft: draft-ietf-v6ops-6204bis

Med,  DanW, and Reinaldo,

Regards,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 20, 2011 6:01 AM
To: Hemant Singh (shemant); Reinaldo Penno; Fred Baker (fred); Maglione Roberta; [email-masked]; [email-masked]
Cc: [email-masked]; Ullio Mario; [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP
Subject: RE: [v6ops] new draft: draft-ietf-v6ops-6204bis

Dear Hemant,

Cheers
Med 

-----Message d'origine-----
De : Hemant Singh (shemant) [mailto:[email-masked]] 
Envoyé : jeudi 20 octobre 2011 01:14
À : Reinaldo Penno; BOUCADAIR Mohamed OLNC/NAD/TIP; Fred Baker (fred); Maglione Roberta; [email-masked]; [email-masked]
Cc : [email-masked]; Ullio Mario; [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP
Objet : RE: [v6ops] new draft: draft-ietf-v6ops-6204bis

Reinaldo,

Hemant

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]] 
Sent: Wednesday, October 19, 2011 6:34 PM
To: Hemant Singh (shemant); [email-masked]; Fred Baker (fred); Maglione Roberta; [email-masked]; [email-masked]
Cc: [email-masked]; Ullio Mario; [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

- UPnP/NAT-PMP - PCP IWF

Thanks,

Reinaldo

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 20 Oct 2011 08:44:59 -0500

Med,

Sounds good.  If an RFC reference to UPnP does not exist, we could consider a UPnP standards body document and reference that in the rfc6204bis and consider adding very specific text related to the use case described below.

Cheers,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 20, 2011 8:33 AM
To: Hemant Singh (shemant)
Cc: [email-masked]; Ullio Mario; [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP
Subject: RE: [v6ops] new draft: draft-ietf-v6ops-6204bis

Re-,

Cheers,
Med

-----Message d'origine-----
De : Hemant Singh (shemant) [mailto:[email-masked]] 
Envoyé : jeudi 20 octobre 2011 14:25
À : BOUCADAIR Mohamed OLNC/NAD/TIP; Reinaldo Penno; Fred Baker (fred); Maglione Roberta; Alain Durand
Cc : [email-masked]; Ullio Mario; [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP
Objet : RE: [v6ops] new draft: draft-ietf-v6ops-6204bis

Med,  DanW, and Reinaldo,

Regards,

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 20, 2011 6:01 AM
To: Hemant Singh (shemant); Reinaldo Penno; Fred Baker (fred); Maglione Roberta; [email-masked]; [email-masked]
Cc: [email-masked]; Ullio Mario; [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP
Subject: RE: [v6ops] new draft: draft-ietf-v6ops-6204bis

Dear Hemant,

Cheers
Med 

-----Message d'origine-----
De : Hemant Singh (shemant) [mailto:[email-masked]] 
Envoyé : jeudi 20 octobre 2011 01:14
À : Reinaldo Penno; BOUCADAIR Mohamed OLNC/NAD/TIP; Fred Baker (fred); Maglione Roberta; [email-masked]; [email-masked]
Cc : [email-masked]; Ullio Mario; [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP
Objet : RE: [v6ops] new draft: draft-ietf-v6ops-6204bis

Reinaldo,

Hemant

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]] 
Sent: Wednesday, October 19, 2011 6:34 PM
To: Hemant Singh (shemant); [email-masked]; Fred Baker (fred); Maglione Roberta; [email-masked]; [email-masked]
Cc: [email-masked]; Ullio Mario; [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

- UPnP/NAT-PMP - PCP IWF

Thanks,

Reinaldo

---

From: Reinaldo Penno <[email-masked]>
Date: Wed, 19 Oct 2011 19:58:27 -0400

On 10/19/11 4:13 PM, "Hemant Singh (shemant)" <[email-masked]> wrote:

> Reinaldo,
> 
> Thanks, understood.  However, my question to the DS-Lite folks is still not
> answered because I was told by them that DS-Lite needs PCP.
> So then I asked 
> what if the Windows host behind the CE router does not support a PCP client,
> then what is the PCP server/proxy inside the CE router do for DS-Lite?

I believe there are two use cases:

If I understand you correctly, it will do the same thing when napt44 is in
the CPE since DS-Lite since includes napt in the AFTR.

In other words, it will perform a UPnP/NAT-PMP<->PCP IWF where it will take
UPnP message, encap on v6 packets and send to AFTR.

Another use case is IPv6 stateful firewall where dual stack/IPv6 host in the
home wants to manage mappings on the CPE. Other people posted use cases
related to this scenario.

> Thus my question is still un-answered.

Does the above help or maybe would you mind clarifying your question?

> To: Hemant Singh (shemant); [email-masked]; Fred Baker (fred);
> Maglione Roberta; [email-masked];

---

From: <[email-masked]>
Date: Thu, 20 Oct 2011 12:00:59 +0200

Dear Hemant,

Cheers
Med 

-----Message d'origine-----
De : Hemant Singh (shemant) [mailto:[email-masked]] 
Envoyé : jeudi 20 octobre 2011 01:14
À : Reinaldo Penno; BOUCADAIR Mohamed OLNC/NAD/TIP; Fred Baker (fred); Maglione Roberta; [email-masked]; [email-masked]
Cc : [email-masked]; Ullio Mario; [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP
Objet : RE: [v6ops] new draft: draft-ietf-v6ops-6204bis

Reinaldo,

Hemant

-----Original Message-----
From: Reinaldo Penno [mailto:[email-masked]] 
Sent: Wednesday, October 19, 2011 6:34 PM
To: Hemant Singh (shemant); [email-masked]; Fred Baker (fred); Maglione Roberta; [email-masked]; [email-masked]
Cc: [email-masked]; Ullio Mario; [email-masked]; MEILLAREC Loïc OLNC/NAD/TIP
Subject: Re: [v6ops] new draft: draft-ietf-v6ops-6204bis

- UPnP/NAT-PMP - PCP IWF

Thanks,

Reinaldo

---

From: SM <[email-masked]>
Date: Sat, 22 Oct 2011 15:04:56 -0700

Hi Christian,
At 00:54 20-10-2011, [email-masked] wrote:
>(1) Customers are indeed allowed to use off-the-shelf CPE devices, 
>as long as these CPE devices comply with what we call the "Service 
>Access Technical Specifications" (STAS in French) which document the 
>features that should/must be supported by a CPE to properly access 
>the services we provide.

Is there any publicly available documentation about the Service 
Access Technical Specifications?

Regards,
-sm