Subject: [v6ops] On 6204-bis

From: Mark Townsley <[email-masked]>
Date: Thu, 20 Oct 2011 15:02:45 +0200

We have several independent implementations on the market based on the recommendations of RFC 6204 today. It has been very successful in this regard. 

Despite RFC 6204 being informational, we are talking about making an incremental revision to a very successful document that has been implemented in multiple commercially available products. As such, I think we should take a cue from the normal IETF Standards Track progression that requires at least two examples of working implementations, as well as a "sufficient level of successful operational experience" to advance [RFC2026].

We now have the luxury of running code. If there are items that are not in RFC 6204 but which have appeared in multiple CPE routers for which we also have "sufficient successful operational experience", we should add them to RFC 6204-bis. If there are items we put in RFC-6204 that implementations refused to incorporate despite what is in the document, we should consider removing them. If there are mistakes that operational experience has informed us about, we should fix them. We clearly have sufficient operational experience for and multiple implementations of 6rd, meeting an RFC 2026 inspired bar quite handily. I think it is much more difficult to show that for DS-Lite today, and certainly is for DS-Lite+PCP or DS-Lite+PCP+UPnP. 

Finally, DS-Lite is not about delivering IPv6, but about delivering IPv4 and CGN within an IPv6 deployment. I would much rather see this as part of a document that defines how to sensibly disable IPv4, including operational tradeoffs of IPv6-only service to the user (possibly supported by IPv4 translation), rather than in 6204-bis that has been scoped thus far to simply get IPv6 off the ground and running.

- Mark

PS. The "Home Facing" side of any v6 firewall control protocol I would argue is within the scope of the homenet WG to reference within the context of the overall homenet architecture. If it makes sense for one instance of this protocol to operate on v4 and v6 together (and I think it probably does), we probably don't want to make these decisions independently.

---

From: <[email-masked]>
Date: Fri, 21 Oct 2011 15:37:03 +0200

Mark,

A couple of comments from my side inline. 

[snip]

Despite RFC 6204 being informational, we are talking about making an incremental revision to a very successful document that has been implemented in multiple commercially available products.

CJ: RFC 6204 documents requirements. I'm not sure how its informational status should be seen as some kind of drawback, given the nature of a requirements document - most of the RFCs that document requirements have the informational status (see http://datatracker.ietf.org/doc/search/?name=requirements&activeDrafts=on&rfcs=on), while most of them have yielded successful implementations, let alone operational experience. 

As such, I think we should take a cue from the normal IETF Standards Track progression that requires at least two examples of working implementations, as well as a "sufficient level of successful operational experience" to advance [RFC2026].

CJ: again, I don't see the need for that kind of procedural consideration at this stage of IPv6 deployment and specification effort. On the contrary, requirements of RFC 6204 are (rightfully) said to be "basic", and I guess I'm not the only one to think that the 6204bis draft is a natural opportunity to complement these requirements in light of the IPv6 strategies that are being enforced worldwide by several service providers.

We now have the luxury of running code. If there are items that are not in RFC 6204 but which have appeared in multiple CPE routers for which we also have "sufficient successful operational experience", we should add them to RFC 6204-bis. If there are items we put in RFC-6204 that implementations refused to incorporate despite what is in the document, we should consider removing them.

CJ: I don't think the situation is that black and white, precisely because of the very nature of a requirements document, which is meant to reflect the functional expectations of the community in a broader sense. This means that this extended version of RFC 6204 should take into account the expectations of various service providers, whatever their IPv6 strategy as long as the functional behaviour of the CPE is impacted by the enforcement of such strategies. This is true for the support of 6rd-related capabilities. This is also true for DS-Lite-related capabilities, because the forwarding of privately-addressed IPv4 traffic relies upon IPv6-specific capabilities, such as the AFTR_NAME DHCPv6 option defined in RFC 6334. 

If there are mistakes that operational experience has informed us about, we should fix them.

CJ: agreed, but I think this is what a Best Current Practice document is all about. I'm not convinced that a requirements document is a privileged placeholder to reflect operational experience (by definition).  

We clearly have sufficient operational experience for and multiple implementations of 6rd, meeting an RFC 2026 inspired bar quite handily.

CJ: this reads like a rather speculative argument to me. I do not question the existence of 6rd implementations and operation, but I would encourage more elaboration on scalability and performance considerations before making the aforementioned statement. The somewhat recent 6to4-related discussions is the kind of example I have in mind.  

I think it is much more difficult to show that for DS-Lite today, and certainly is for DS-Lite+PCP or DS-Lite+PCP+UPnP. 

CJ: There has been DS-Lite implementations of CPE for more than a year, and I'm aware of at least two of them that have been deployed in the field. But again, I'm not convinced by the reasoning that basically mandates the 6204bis draft to become a standards track document as per RFC 2026. 

I don't think this is the point at this stage of the discussion and the specification effort - I'm way more concerned by making sure that every IPv6-inferred CPE requirement is adequately documented in this draft, according to the different WG members that have voiced so far, including those who include DS-Lite as part as their global IPV6 strategy. 

The IETF has always been asking for the positions of operators in various contexts - now that such opinions have circulated on the v6ops mailing list, I think they must be taken into account, whatever your perception of what's currently deployed, what works and what doesn't. And BTW, I'm also aware of at least one DS-Lite+PCP+IGD/PCP Proxy CPE implementation.

Finally, DS-Lite is not about delivering IPv6, but about delivering IPv4 and CGN within an IPv6 deployment.

CJ: right. But DS-Lite design has IPv6 implications on the CPE, as stated above and as I'm sure you know perfectly well. 

I would much rather see this as part of a document that defines how to sensibly disable IPv4, including operational tradeoffs of IPv6-only service to the user (possibly supported by IPv4 translation), rather than in 6204-bis that has been scoped thus far to simply get IPv6 off the ground and running.

CJ: you seem to oppose DS-Lite "proponents" to IPv6 deployment proponents, and I have to respectfully disagree with that argument. DS-Lite is one of the approaches that address the inevitable need for IPv4 service continuity (which is dramatically different from the global IPv4 address depletion issue). 

FT/Orange, among other service providers, has chosen DS-Lite (among other approaches like NAT444) because we think this is a lesser evil BUT also because DS-Lite does NOT question IPv6 deployment and rather *encourages* it. 

DS-Lite-inferred requirements have therefore a perfectly legitimate place in the 6204bis draft.

Cheers,

Christian.

********************************************************************************
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: Lorenzo Colitti <[email-masked]>
Date: Sat, 22 Oct 2011 13:18:07 +0900

On Fri, Oct 21, 2011 at 22:37, <[email-masked]> wrote:

> We clearly have sufficient operational experience for and multiple
> implementations of 6rd, meeting an RFC 2026 inspired bar quite handily.
>
> CJ: this reads like a rather speculative argument to me. I do not question
> the existence of 6rd implementations and operation, but I would encourage
> more elaboration on scalability and performance considerations before making
> the aforementioned statement. The somewhat recent 6to4-related discussions
> is the kind of example I have in mind.
>

Please don't lump 6to4 with 6rd. 6rd is literally orders of magnitude more
reliable than 6to4.

> CJ: you seem to oppose DS-Lite "proponents" to IPv6 deployment proponents,
> and I have to respectfully disagree with that argument. DS-Lite is one of
> the approaches that address the inevitable need for IPv4 service continuity
> (which is dramatically different from the global IPv4 address depletion
> issue).
>
> FT/Orange, among other service providers, has chosen DS-Lite (among other
> approaches like NAT444) because we think this is a lesser evil BUT also
> because DS-Lite does NOT question IPv6 deployment and rather *encourages*
> it.
>

I don't think Mark opposes the two - I think he's simply saying (and, FWIW,
I agree) that DS-lite is not about providing IPv6, it's about providing
IPv4. So it doesn't necessarily belong in a document that describes what an
IPv6 CE router should do.

---

From: Randy Bush <[email-masked]>
Date: Fri, 21 Oct 2011 21:54:57 -0700

> DS-lite is not about providing IPv6, it's about providing IPv4.

i just love when they say

> IPv4 service continuity

and mean "we are not deploying ipv6."

randy

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 22 Oct 2011 07:15:53 -0500

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Lorenzo Colitti
Sent: Saturday, October 22, 2011 12:18 AM
To: [email-masked]
Cc: IPv6 Operations
Subject: Re: [v6ops] On 6204-bis

>I don't think Mark opposes the two - I think he's simply saying (and,
FWIW, I agree) that DS-lite is not about providing IPv6, it's about
providing IPv4. So it doesn't necessarily belong in a >document that
describes what an IPv6 CE router should do.

It's totally subjective that DS-Lite is labeled as an IPv4 technology
while 6rd is not.  I would just as well say 6rd carries data from the
home in an IPv4 tunnel, so 6rd is also IPv4 technology.   A DS-Lite
deployment already has IPv6 at the subscriber edge and the SP edge to
the Internet backbone.    I would argue that for 6rd the SP network is
less IPv6 ready since IPv6 data from the subscriber edge is heading to
the SP IPv4 network.  

Hemant

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 22 Oct 2011 08:56:14 -0700

>
> It’s totally subjective that DS-Lite is labeled as an IPv4 technology
while 6rd is not.  I would just as well say 6rd carries data from the home
in an IPv4 tunnel, so 6rd is also IPv4 technology.   A DS-Lite deployment
already has IPv6 at the subscriber edge and the SP edge to the Internet
backbone.    I would argue that for 6rd the SP network is less IPv6 ready
since IPv6 data from the subscriber edge is heading to the SP IPv4 network.

6rd is a technology to deliver IPv6 to users. DS-Lite is a technology to
deliver IPv4 to users. If you wanted to, you could perfectly well implement
DS-Lite on the WAN interface without ever providing IPv6 connectivity to the
user at all.

If you accept that an IPv6 CE router is a device that brings IPv6
connectivity to users, then DS-Lite does not necessarily belong in there,
because it does not provide the user with IPv6 connectivity.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Sat, 22 Oct 2011 17:42:42 -0500

From: Lorenzo Colitti [mailto:[email-masked]] 
Sent: Saturday, October 22, 2011 11:56 AM
To: Hemant Singh (shemant)
Cc: [email-masked] WG; [email-masked]
Subject: RE: [v6ops] On 6204-bis

>6rd is a technology to deliver IPv6 to users. DS-Lite is a technology
to deliver IPv4 to users. If you wanted to, you could perfectly well
implement DS-Lite on the WAN interface without ever >providing IPv6
connectivity to the user at all.

>If you accept that an IPv6 CE router is a device that brings IPv6
connectivity to users, then DS-Lite does not necessarily belong in
there, because it does not provide the user with IPv6 >connectivity.

As I said before it's a subjective debate for what is IPv6 vs. not.
DS-Lite has the home definitely use an IPv6 address which is the tunnel
source IPv6 address.   I don't take into consideration just the CE in
the home for decide what is IPv6 or not.  I am seeing the end to end
architecture and say the DS-Lite deployment has IPv6 in the SP-edge (WAN
to the backbone) and the SP backbone.   Soon as apps and other content
is primarily available as IPv6, DS-Lite home already has IPv6 which will
sunset DS-Lite.   Specifically for the CE router document, it's the SP's
who contacted this mailer to include DS-Lite in rfc6204bis and we go by
that feedback.  The Chair also recommended to us to ping the SPs who'd
like to include DS-Lite and when we did, Telecom Italia, FT Orange and
others have said yes.  Germany already has a DS-Lite deployment in trial
for over few months now.

BTW, on the content front, thank you, Google, for ipv6 search and also
the DNS white listing that you guys did quite some time back.   Thank
you also for sponsoring the Minneapolis IETF and the upcoming IETF in
Vancouver.

Hemant

---

From: Mark Townsley <[email-masked]>
Date: Sun, 23 Oct 2011 01:08:24 +0200

On Oct 22, 2011, at 5:56 PM, Lorenzo Colitti wrote:

> > >I don't think Mark opposes the two - I think he's simply saying (and, FWIW, I agree) that DS-lite is not about providing IPv6, it's about providing IPv4. So it doesn't necessarily belong in a >document that describes what an IPv6 CE router should do.
> >
> > It’s totally subjective that DS-Lite is labeled as an IPv4 technology while 6rd is not.  I would just as well say 6rd carries data from the home in an IPv4 tunnel, so 6rd is also IPv4 technology.   A DS-Lite deployment already has IPv6 at the subscriber edge and the SP edge to the Internet backbone.    I would argue that for 6rd the SP network is less IPv6 ready since IPv6 data from the subscriber edge is heading to the SP IPv4 network. 
> 
> 6rd is a technology to deliver IPv6 to users. DS-Lite is a technology to deliver IPv4 to users. If you wanted to, you could perfectly well implement DS-Lite on the WAN interface without ever providing IPv6 connectivity to the user at all.
> 
> If you accept that an IPv6 CE router is a device that brings IPv6 connectivity to users, then DS-Lite does not necessarily belong in there, because it does not provide the user with IPv6 connectivity
> 
Precisely. 

- Mark

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

---

From: Maglione Roberta <[email-masked]>
Date: Mon, 24 Oct 2011 10:19:47 +0200

Mark and All,
   I don't quite understand why we are iterating this discussion over and over again: if I remember correctly we have already agreed that 6rd and Ds-Lite solve two different problems and it is up to the Service Provider to choose one of the other according to his scenario and requirements, thus both technologies belong to this document.

When you say DS-Lite is not about delivering IPv6, while 6rd is a technology to deliver IPv6 to users, you seem to forget that DS-Lite requires IPv6 native connectivity on the CPE, IP Edge and backbone network: thus a Service Provider that selected DS-Lite is really already moving toward IPv6 because it has already IPv6 in place not only in the Backbone network but also at the BNG and at the CPE level.
Instead with 6rd, IPv6 is delivered to the users but every thing else in the network stays IPv4, in my opinion this scenario does not look about moving toward IPv6, it is more try to keep in IPv4 as many network elements as possible.

Again we need DS-Lite requirements in this document because we would like to deploy IPv6 as soon as possible.

Best regards,
Roberta

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Townsley
Sent: giovedì 20 ottobre 2011 15.03
To: IPv6 Operations
Subject: [v6ops] On 6204-bis

- Mark

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: Ole Troan <[email-masked]>
Date: Mon, 24 Oct 2011 13:32:44 +0200

Roberta,

> Again we need DS-Lite requirements in this document because we would like to deploy IPv6 as soon as possible.

I certainly also want to see DS-lite support in CPEs. for SP managed CPEs that requirement is already taken care of in the BBF.
why do you think having a new RFC number for 6204 including a reference to RFC6333 is better than
stating a requirement for RFC6204 + RFC6333. RFC6204 is never going to be a complete device profile for everything a CPE has to do.

you know my view, I don't think it is worth updating 6204 just for a couple of requirements. that's just going to create confusion among the CPE implementors, require re-doing certification tests and what not. I know I repeat myself, but let's just shelf 6204bis for now.

(and let's get RFC6333 tests into the IPv6 Ready CPE logo programme).

cheers,
Ole

---

From: Maglione Roberta <[email-masked]>
Date: Mon, 24 Oct 2011 14:02:37 +0200

> why do you think having a new RFC number for 6204 including a reference to > RFC6333 is better than stating a requirement for RFC6204 + RFC6333.

Because it is easier to have just a single RFC with all the requirements for CPE's to give to the CPE's vendors as a reference point.

Best regards,
Roberta

-----Original Message-----
From: Ole Troan [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: lunedì 24 ottobre 2011 13.33
To: Maglione Roberta
Cc: Mark Townsley; IPv6 Operations; Ullio Mario
Subject: Re: [v6ops] On 6204-bis

Roberta,

cheers,
Ole

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 24 Oct 2011 14:29:27 +0200

On 2011-10-24 14:02 , Maglione Roberta wrote:
>> why do you think having a new RFC number for 6204 including a
>> reference to > RFC6333 is better than stating a requirement for
>> RFC6204 + RFC6333.
> 
> Because it is easier to have just a single RFC with all the
> requirements for CPE's to give to the CPE's vendors as a reference
> point.

To adjust that subject, in the IETF it is common to know where to find
all current documents. http://tools.ietf.org is helping a lot here btw.

But still, it is a HUGE mess if you are not used to the IETF.

As such, would it not be a great idea for 'common folks' aka the ones
who do not follow the IETF on a daily basis, to have a single page on
the IETF site (nicely referenced from Wikipedia and properly indexed in
the search engines ;) which lists the current documents for each subject?

http://www.rfc-editor.org/cgi-bin/rfcsearch.pl helps only half way, as
if I type there "IPv6 CPE" I only get 6092 + 4241, no 6204 anywhere in
sight.

(Googling(ipv6 cpe site:ietf.org) just returns an enormous pile of
drafts, which is not useful either)

As such, for those people and folks who want to catch up on things, it
would be awesome if in that big bar on the right of www.ietf.org there
was a link "Current Documents" that would allow people to search for
them easily (having 'tags' in there and letting people tag them would be
even nicer of course).

Greets,
 Jeroen

---

From: Sander Steffann <[email-masked]>
Date: Mon, 24 Oct 2011 14:36:31 +0200

Hi,

> Because it is easier to have just a single RFC with all the requirements for CPE's to give to the CPE's vendors as a reference point.

But Ole explicitly said: 'RFC6204 is never going to be a complete device profile for everything a CPE has to do.' and I agree with him. Creating a new RFC just to add a few references will not help much if the end result is still not a complete list of everything the CPE needs to do...

- Sander

---

From: Maglione Roberta <[email-masked]>
Date: Mon, 24 Oct 2011 14:54:45 +0200

> Creating a new RFC just to add a few references will not help much if the > end result is still not a complete list of everything the CPE needs to
> do...

The support for IPv4/IPv6 Transition Technologies is missing in RFC6204: the new requirements about 6rd and DS-Lite we are talking about here fill this gap in 6204 bis.

Best regards,
Roberta

-----Original Message-----
From: Sander Steffann [mailto:[email-masked]]
Sent: lunedì 24 ottobre 2011 14.37
To: Maglione Roberta
Cc: Ole Troan; IPv6 Operations
Subject: Re: [v6ops] On 6204-bis

Hi,

- Sander

---

From: Sander Steffann <[email-masked]>
Date: Mon, 24 Oct 2011 15:05:01 +0200

Hi,

> The support for IPv4/IPv6 Transition Technologies is missing in RFC6204: the new requirements about 6rd and DS-Lite we are talking about here fill this gap in 6204 bis.

I know, but there will always be gaps in 6204 depending on the deployment scenario. We could also add RFC6346 and everything based on it. We are deploying 6rd here in The Netherlands, and we specify that the CPE needs to conform to RFC6204 with Ethernet encapsulation on the WAN interface + RFC5969 with support for the DHCP provisioning option. That is fairly easy to specify to a CPE manufacturer. And as you can see: just specifying RFC6204 is not enough, you still need to think about the SHOULDs and options like the WAN interface. Adding a second RFC is not a big deal for us.

- Sander

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Oct 2011 09:21:42 +1300

Jeroen,

I'm not sure there is an agreed definition of what is current, but
isn't the documents page for each WG what you want? e.g.
http://datatracker.ietf.org/wg/v6ops/

I use http://www.ietf.org/content.html as my home page because
it is only one click to the list of WGs and two clicks to
the above documents pages. You need three clicks from the marketing
home page at www.ietf.org.

We can't do much about the mysteries of the Google search algorithm.

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Oct 2011 09:23:52 +1300

> But Ole explicitly said: 'RFC6204 is never going to be a complete device profile for everything a CPE has to do.' and I agree with him. Creating a new RFC just to add a few references will not help…

It is not the IETF's job to write procurement specifications. That way lies madness.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 24 Oct 2011 14:27:23 -0700

On Mon, Oct 24, 2011 at 05:02, Maglione Roberta <
[email-masked]> wrote:

> > why do you think having a new RFC number for 6204 including a reference
> to > RFC6333 is better than stating a requirement for RFC6204 + RFC6333.
>
> Because it is easier to have just a single RFC with all the requirements
> for CPE's to give to the CPE's vendors as a reference point.

There is no RFC containing all the IPv4 requirements for CPE vendors. Why do
we need one for IPv6?

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 25 Oct 2011 00:07:12 +0200

> http://datatracker.ietf.org/wg/v6ops/

The question then becomes which WG? There is also 6man (formerly ipv6) and then the DNS ones etc. thus having a clear overview pointing where one could find these things would be useful IMHO (and quite a bit of work too, but that is why there is a secretariat, right ;)

Maybe having this kind of page on wikipedia would be a better place, though I think the main page of ietf.org would be better

Greets,
 Jeroen

---

From: Joel jaeggli <[email-masked]>
Date: Tue, 25 Oct 2011 00:02:35 -0700

> It is not the IETF's job to write procurement specifications. That way lies madness.

We've chartered working groups to do that, it turned out to not be such
a good idea for security capabilities...

joel