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

From: Fred Baker <[email-masked]>
Date: Sun, 15 Apr 2012 13:54:00 -0700

This is to initiate a ONE week working group last call of draft-ietf-v6ops-6204bis, seeing as we just completed a two week event and finished some comments at IETF 83. Please read it now, or at least the diff from the previous version. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list.

---

From: Francis Dupont <[email-masked]>
Date: Mon, 16 Apr 2012 13:57:22 +0200

In your previous mail you wrote:

> This is to initiate a ONE week working group last call of
> draft-ietf-v6ops-6204bis

=> I have still a concern about W-6:

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

for at least two reasons:
 - there are other protocols than PCP which provides the function,
  for instance UPnP IGD v2.

 - there is no known example of a router application which needs the
   function

So I propose to step back to what was in RFC 6204, i.e., simply
remove W-6 (and the PCP reference).

Note if the last sentence about the LAN side changes of course
W-6 (with another wording) could make sense again.

Regards

[email-masked]

PS: the draft should be written in US English so without the 'e'
in Acknowledgements.
             ^

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 16 Apr 2012 13:43:34 +0000

>   for instance UPnP IGD v2.

For any protocol like this to be effective, the server side must exist. Since this is a CE router spec that is focusing just on changes to the 6204-defined WAN interface, the server side must exist in the access network. A number of European service providers have stated that they intend to provide a PCP server in conjunction with DS-Lite. I have heard no service providers say that there is an intention to support any other protocol. I will not support any recommendation to CE router vendors to include functionality that will be useless, due to lack of existence of the server function in the access network. Please note, that I fully support the CE router having a LAN-facing UPnP IGD:2 server in it -- but I consider that to be outside the scope of 6204bis. As someone who is very much involved (and has put a lot of time and effort) in trying to get IPv6 into UPnP, I believe strongly in UPnP -- inside the LAN.

>  - there is no known example of a router application which needs the

I believe FT-Orange and Telecom Italia have both spoken about their need for this function. Perhaps they could do so again, to refresh our memories.

> So I propose to step back to what was in RFC 6204, i.e., simply remove W-6
> (and the PCP reference).

When it was suggested that PCP be mentioned in this draft, I stated that I would only be in favor if it did not cause problems with getting 6204bis approved. If multiple people have problems with the PCP, then it does needs to go. And I absolutely will not support including requirements around LAN-side functionality or inter-working functions, as I consider that to be the realm of homenet. This is focused on the WAN.

Barbara

---

From: Tom Taylor <[email-masked]>
Date: Mon, 16 Apr 2012 10:31:52 -0400

This point was discussed in the PCP meeting. While Francis's view seemed 
to be in the minority, I found it logically compelling. The applications 
that were described in the meeting that would find it useful were really 
host functions that happened to be resident on the CPE. Hence 
implementation of a PCP client would be the task of the people 
implementing those functions, rather than of the CE Router developers.

On the other hand, Barbara mentions interest in its application for 
DS-Lite. Delving into the PCP-related documents, I note 
draft-dupont-pcp-dslite, which advocates implementation of a PCP proxy 
rather than PCP client function in the CE Router.

In the PCP base document itself, the main discussion of DS-Lite usage 
comes in the Security Considerations section, in association with the 
use of the THIRD_PARTY option. Security issues surrounding use of the 
THIRD_PARTY option are holding up approval of the PCP base document. The 
main thrust of the existing DS-Lite discussion in the PCP base document 
is to say that use of THIRD_PARTY is safe in the DS-Lite case.

I'm sure there are earnest discussions going on behind the scenes to get 
the concerns about THIRD_PARTY resolved. As an outside observer, 
however, I see various issues around inclusion of a reference to PCP in 
6204bis at this time, in terms both of the appropriate technical 
approach and approval of the specifications.

Tom Taylor

On 16/04/2012 7:57 AM, Francis Dupont wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Simon Perreault <[email-masked]>
Date: Mon, 16 Apr 2012 10:49:46 -0400

> implementing those functions, rather than of the CE Router developers.

Isn't the set of "people implementing those functions" a subset of "CE 
Router developers"?

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: Francis Dupont <[email-masked]>
Date: Mon, 16 Apr 2012 17:30:14 +0200

In your previous mail you wrote:

> When it was suggested that PCP be mentioned in this draft, I stated
> that I would only be in favor if it did not cause problems with
> getting 6204bis approved. If multiple people have problems with the
> PCP, then it does needs to go. And I absolutely will not support
> including requirements around LAN-side functionality or
> inter-working functions, as I consider that to be the realm of
> homenet. This is focused on the WAN.

=> without something on the LAN side a PCP client on the WAN side
doesn't make sense. And as I argued there is no router application
using it. And a normative reference to PCP could delay 6204bis,
so again I propose:
 - remove W-6 and the reference
 - wait for 6204ter and homenet to see what to put for this.

Thanks

---

From: Tom Taylor <[email-masked]>
Date: Mon, 16 Apr 2012 13:34:28 -0400

That's my point: leaving aside the DS-Lite application, not all CE 
Router developers should be required to implement PCP clients. And for 
DS-Lite, there are open questions:
  -- client vs. proxy
  -- security issues with THIRD_PARTY
  -- the fact that neither the PCP base specification nor W-6 requires
     the implementation of the THIRD_PARTY option

---

From: Francis Dupont <[email-masked]>
Date: Tue, 17 Apr 2012 00:14:32 +0200

>  rather than PCP client function in the CE Router.

=> yes, it is the homenet/out-of-scope for the benefit of hosts on
the LAN part.

>  use of the THIRD_PARTY option.

=> independently of the THIRD_PARTY issue this whole text should move
to the DS-Lite document (and its authors joined the DS-Lite document team so
I can use shall :-).

>  I see various issues around inclusion of a reference to PCP in 

=> yes, it is too soon.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Tue, 17 Apr 2012 00:18:13 +0200

>  Isn't the set of "people implementing those functions" a subset of "CE 

=> it is the opposite: "CE Router developers" are a subset of "people
implementing stuff" (:-). Note there is perhaps something else in Tom's
message: there is no definition of a PCP client as an independent piece
of code, i.e., each "application" can embed a PCP client...

Regards

---

From: Mark Townsley <[email-masked]>
Date: Mon, 23 Apr 2012 19:27:36 +0200

v6ops,

In Paris, Fred asked Chris and I to work on text describing the three 6rd sunsetting requirements discussed during the meeting. Instead, a few folks pulled together text without as much as a sanity check or heads up in my inbox. Meanwhile, not knowing anyone else had taken on the project of adapting their own version of 6rd sunsetting requirements for 6294-bis, I was working in parallel based on feedback received at the WG meeting, in the hall, etc. I sent this to Chris and the chairs one week after the Paris meeting (April 6) for review. 

I'm sure everyone has the best of intentions here, but what made it into the document is not only flawed technically, it didn't include all WG feedback because some of that was directly to me… and being left out of the process of writing the requirements that are in the document, means that this feedback obviously didn't get incorporated. 

In any case, here's what I believe the additional 6rd requirements should be based on what was in my presentation to the group and the feedback I have received. These are for section 4.4.1, which is already surrounded by an "if 6rd is supported" clause:

6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces to be
active simultaneously in order to support coexistence of the two
technologies during an incremental migration period from 6rd to native
IPv6. 

6RD-5: The CE router MUST associate delegated prefixes with the WAN
interface(s) they were learned from (e.g., DHCPv6-PD, 6rd, etc). Each
packet sent out a WAN interface MUST have a source address that
corresponds to a delegated prefix associated with the given WAN
interface, consistent with what is described in section 4.3 of BCP
84 (RFC 3704).

6RD-6: The IPv6 CE router MUST allow different or identical delegated prefixes
on 6rd and native interfaces. A 6rd virtual interface MUST be assigned a 
higher routing cost than a native IPv6 interface. This is done so that native 
traffic will be preferred over 6rd in the event normal IP longest matching 
and BCP 84 rules would have otherwise allowed a packet to be equally sent 
via 6rd or native IPv6.

These would be instead of the four requirements, 6RD-4 through 6RD-7, in -08. 

- Mark

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 23 Apr 2012 13:26:01 -0500

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mark Townsley
Sent: Monday, April 23, 2012 1:28 PM
To: [email-masked]
Subject: [v6ops] 6rd sunsetting requirements for 6204-bis

>IPv6. 

I don't think such a requirement is needed, especially with a strong
text such as the "MUST" in the requirement.   The reason is the device
is a  CPE router and a router, by default, has no issue with supporting
two concurrently IP technologies on the network interfaces  of the
router.   

Thanks,

Hemant

---

From: Simon Perreault <[email-masked]>
Date: Mon, 23 Apr 2012 14:37:21 -0400

On 2012-04-23 14:26, Hemant Singh (shemant) wrote:
> I don’t think such a requirement is needed, especially with a strong
> text such as the “MUST” in the requirement. The reason is the device is
> a CPE router and a router, by default, has no issue with supporting two
> concurrently IP technologies on the network interfaces of the router.

I know of at least one popular home router model currently in stores 
that doesn't allow native IPv6 simultaneously with 6rd. So this 
requirement looks necessary to me.

Simon

---

From: Chris Donley <[email-masked]>
Date: Mon, 23 Apr 2012 17:03:38 -0600

Mark,

Please see in-line.

Chris

From: Mark Townsley <[email-masked]<mailto:[email-masked]>>
Date: Mon, 23 Apr 2012 11:27:36 -0600
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [v6ops] 6rd sunsetting requirements for 6204-bis

 1.  I think this is covered in 6rd-5 and 6rd-7.
 2.  I don't think this specific requirement was agreed to in Paris.  It's not on your slide 4 or Slide 15, bullet 1, which were the 'hum's I captured in my notes.
 3.  +1 to Hemant's comment – I don't think this is needed as a MUST.

 1.  We've been advised by the WG in the past to only include a single normative statement per requirement.
 2.  This is covered in the existing 6rd-4.

 1.  I think this language (…MUST allow different or identical delegated prefixes…) is confusing for people not intimately familiar with your other CE transitioning draft.
 2.  If I read this correctly, you want to require two operational states – one where 6rd and native IPv6 use the same prefix and a second where they use different prefixes. That requirement is captured in 6rd-5.
 3.  As I mentioned above, we have been advised to keep requirements to a single normative statement, so the part about the routing cost is in 6rd-6.
 4.  I've heard from some CPE vendors that specifying routing "cost" may be too implementation specific – I think it's more neutral to speak of preference – e.g. prefer native to 6rd.

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 24 Apr 2012 07:59:45 +0200

+1 on Hemants comment.

However.  Again new requirements are added to the RFC6204, so again more pressure is put upon the CPE vendors to be "IPv6-ready", to be "IPv6-compliant".
I don't get it.  At the v6 world congress in Paris last February (panel 'can we get an IPV6 CPE please') I think it was clear from all present CPE vendors in the panel that it's time to STOP adding requirements over and over again to the RFC6204, so to finally have a basic set of requirements. But again, reqs are added, so again it will not be possible to have compliancy within a decent time frame.

I've been present on the last 2 v6 world congresses in Paris and the general statements there were always "the CPE is the problem".  Well, guess what, it still is, and it still will be if you don't stop adding requirements.  Please draw a line NOW, and take changes and added requirements into a later version so the CPE vendor has the time to cope with all of this!!!  I repeat my statement from the panel: if we don't stop adding requirements onto the (nearly free-of-charge) CPE, the next v6 congress will have again several presentations claiming "The CPE is the problem".

Just on these specific ones: there is the claim that CPE devices are not "ready" (whatever that may mean").  Today, IPv6 roll-out is, unfortunately, still very (too) limited, but already "6rd sunsetting" requirements are being added to the basic CPE IPV6 reqs, why ?  I don't doubt this issue will present itself, but for sure not "tomorrow".

Regs
Carl

From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Donley
Sent: dinsdag 24 april 2012 1:04
To: Mark Townsley; [email-masked]
Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis

Mark,

Please see in-line.

Chris

 1.  I think this is covered in 6rd-5 and 6rd-7.
 2.  I don't think this specific requirement was agreed to in Paris.  It's not on your slide 4 or Slide 15, bullet 1, which were the 'hum's I captured in my notes.
 3.  +1 to Hemant's comment - I don't think this is needed as a MUST.

 1.  I think this language (...MUST allow different or identical delegated prefixes...) is confusing for people not intimately familiar with your other CE transitioning draft.
 2.  If I read this correctly, you want to require two operational states - one where 6rd and native IPv6 use the same prefix and a second where they use different prefixes. That requirement is captured in 6rd-5.
 3.  As I mentioned above, we have been advised to keep requirements to a single normative statement, so the part about the routing cost is in 6rd-6.
 4.  I've heard from some CPE vendors that specifying routing "cost" may be too implementation specific - I think it's more neutral to speak of preference - e.g. prefer native to 6rd.

---

From: Mark Townsley <[email-masked]>
Date: Tue, 24 Apr 2012 08:09:23 +0200

Chris, 

Here are the requirements you put in -08, and why they are lacking:

>  6RD-4:  Per [RFC3704], Section 4.3, the CE router MUST send traffic	
>  	         using a prefix learned via 6rd over the 6rd tunnel.	

You must also make sure that traffic sent over native IPv6 has a source address learned from DHCPv6 PD for that interface. Doing it for 6rd alone isn't enough for RFC 3704 behavior.

>  		
>   6RD-5:  The IPv6 CE router MUST support two operational modes:	
>  	           different prefixes on 6rd and native interfaces or identical	
>  	           prefixes on 6rd and native interfaces.	

I'm not sure why you introduced "operational modes" here. What needs to be said is simply that interfaces receive delegated prefixes from somewhere (6rd, DHCv6-PD, etc). They might end up being the same, and that should not be interpreted as an error condition. It's not like the CE has to "change mode" for this. 

>  		
>   6RD-6:  By default, the IPv6 CE router MUST prefer a native IPv6	
>  	          interface over a 6rd virtual interface.	

The CE router must not prefer native over 6rd blindly. The preference is only used as a "tie breaker" in the event that normal routing fails to give you the right WAN egress to use. So, first you do normal IP longest-match and RFC 3704 source-match, and *if and only if* that results in an ambiguous choice do you select native over 6rd. It's a simple routing metric.

I think when you separated this single requirement into two, you lost the sense of it in the process. 

>  		
>   6RD-7:  The IPv6 CE router SHOULD support independent WAN interface	
>  	           configuration for 6rd and native IPv6.	
>  	                                                    

"Independent" does not mean the same thing as "simultaneously active." 6rd and native must be active at the same time during the period an operator is moving from 6rd to native, otherwise the operator loses flexibility in doing so incrementally (e.g., user traffic may be dropped as it is tunneled directly to a CPE that has disabled 6rd because it detected an active native link).

Also, you have three MUST requirements that are incumbent upon some form of 6RD-7 being true, but for some reason you are making this one a SHOULD.

In sum, it seems you have taken the whole concept of 6rd and native IPv6 operating at the same time to allow a smooth migration (e.g., multihoming), and neutered it to a form that fits within the confines of what you think a CPE should do.

- Mark

On Apr 24, 2012, at 1:03 AM, Chris Donley wrote:

> Mark,
> 
> Please see in-line.
> 
> Chris
> 
> From: Mark Townsley <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> I think this is covered in 6rd-5 and 6rd-7.  
> I don't think this specific requirement was agreed to in Paris.  It's not on your slide 4 or Slide 15, bullet 1, which were the 'hum's I captured in my notes.
> +1 to Hemant's comment – I don't think this is needed as a MUST.
> 
> We've been advised by the WG in the past to only include a single normative statement per requirement.
> This is covered in the existing 6rd-4.
> 
> I think this language (…MUST allow different or identical delegated prefixes…) is confusing for people not intimately familiar with your other CE transitioning draft. 
> If I read this correctly, you want to require two operational states – one where 6rd and native IPv6 use the same prefix and a second where they use different prefixes. That requirement is captured in 6rd-5.
> As I mentioned above, we have been advised to keep requirements to a single normative statement, so the part about the routing cost is in 6rd-6.
> I've heard from some CPE vendors that specifying routing "cost" may be too implementation specific – I think it's more neutral to speak of preference – e.g. prefer native to 6rd.

---

From: Mark Townsley <[email-masked]>
Date: Tue, 24 Apr 2012 08:31:55 +0200

> +1 on Hemants comment.

You mean this comment?

Hemant:

"Sorry, still does not cut it for me.  Fix the bug in the CPE router.  We cannot add every bug found in the CPE router for a requirement to the document.  This is extremely basic router functionality where a router should support concurrent tunneled and native IP interfaces."

I really don't think that lack of support of IPv6 multihoming in a CPE router is a simple bug that should obviously be fixed by every CPE vendor. I wish that were true, but its not.

> 
> However.  Again new requirements are added to the RFC6204, so again more pressure is put upon the CPE vendors to be “IPv6-ready”, to be “IPv6-compliant”.
> I don’t get it.  At the v6 world congress in Paris last February (panel ‘can we get an IPV6 CPE please’) I think it was clear from all present CPE vendors in the panel that it’s time to STOP adding requirements over and over again to the RFC6204, so to finally have a basic set of requirements. But again, reqs are added, so again it will not be possible to have compliancy within a decent time frame. 

It seems the real scope-creep you are talking about is the addition of 6rd and DS-Lite to begin with. 

All I am trying to do is make sure that *if* 6rd is in the document, it is done correctly so we don't paint ourselves into a corner. 

I was also trying to do the same with DS-Lite, but have decided to give up. DS-Lite has become an enormous distraction to the deployment of IPv6 service to internet users, so I'm going to stop investing energy into trying to fix it here. Maybe v4-exit can do better in 6204-ter (sigh). 

As I have said before, I am equally happy with the entire "Transition" section to be removed from 6204-bis. But, if we step off the cliff, we're going to get it right, at least for 6rd. Otherwise, it does more harm than good.

> I’ve been present on the last 2 v6 world congresses in Paris and the general statements there were always “the CPE is the problem”.  Well, guess what, it still is, and it still will be if you don’t stop adding requirements. 
> Please draw a line NOW, and take changes and added requirements into a later version so the CPE vendor has the time to cope with all of this!!!  I repeat my statement from the panel: if we don’t stop adding requirements onto the (nearly free-of-charge) CPE, the next v6 congress will have again several presentations claiming “The CPE is the problem”.
>  
> Just on these specific ones: there is the claim that CPE devices are not “ready” (whatever that may mean”).  Today, IPv6 roll-out is, unfortunately, still very (too) limited, but already “6rd sunsetting” requirements are being added to the basic CPE IPV6 reqs, why ?  I don’t doubt this issue will present itself, but for sure not “tomorrow”.

That's why:

- Mark

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 24 Apr 2012 08:45:26 +0200

Inline

Regs
Carl
From: Mark Townsley [mailto:[email-masked]]
Sent: dinsdag 24 april 2012 8:32
To: Wuyts Carl
Cc: Chris Donley; [email-masked]
Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis

+1 on Hemants comment.

You mean this comment?

Hemant:

[Carl] Yes.  A CPE is a router, hence should be capable of making routing decisions, taking into account multiple paths, metrics, .... .  Load balancing for instance might not be supported, so in case of multiple equal cost paths, it will take one of the available routes, but this is a known "issue" at that moment.  Lots of things can be set via TR-069 these days, so ISP can influence e.g. metrics when having native/tunneled combination and wanting to enforce a specific route.

It seems the real scope-creep you are talking about is the addition of 6rd and DS-Lite to begin with.
[Carl] Not at all.  Our CPE supports both 6rd, static as well as using the DHCP option 212.  But when looking today at our customers, there for sure not hitting a 6rd move to native .

All I am trying to do is make sure that *if* 6rd is in the document, it is done correctly so we don't paint ourselves into a corner.
[Carl] Saw the picture, see what you mean, but again, should be tackled, however not today.  Allow some time.

I was also trying to do the same with DS-Lite, but have decided to give up. DS-Lite has become an enormous distraction to the deployment of IPv6 service to internet users, so I'm going to stop investing energy into trying to fix it here. Maybe v4-exit can do better in 6204-ter (sigh).
[Carl] Same applies here as for 6rd.  To start off, we do support it, again static and dynamic through dhcp option 64, so no issue on that part.  But proper deployment most likely will require some extra's on the CPE, PCP, UPNP-IGD2, something else....  Similar applies here: people starting today to look at it (in Residential CPE world), but for sure not (yet) targeting the move to native-only, too soon (unfortunately).

As I have said before, I am equally happy with the entire "Transition" section to be removed from 6204-bis. But, if we step off the cliff, we're going to get it right, at least for 6rd. Otherwise, it does more harm than good.
[Carl] Don't fully agree :).  I see 6rd being used in various ways at our customers today.  I must say it's working rather smooth, using the features they have available today, so I'd encourage to keep both 6rd and DSLite in the doc as is, but not start adding more requirements which are to be applied in later phases.

I've been present on the last 2 v6 world congresses in Paris and the general statements there were always "the CPE is the problem".  Well, guess what, it still is, and it still will be if you don't stop adding requirements.
Please draw a line NOW, and take changes and added requirements into a later version so the CPE vendor has the time to cope with all of this!!!  I repeat my statement from the panel: if we don't stop adding requirements onto the (nearly free-of-charge) CPE, the next v6 congress will have again several presentations claiming "The CPE is the problem".

That's why:

[http://www.randexpainting.com/corner-web1.jpg]

[Carl] I usually start from the other end @ home :)

- Mark

Regs
Carl

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Chris Donley
Sent: dinsdag 24 april 2012 1:04
To: Mark Townsley; [email-masked]<mailto:[email-masked]>
Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis

Mark,

Please see in-line.

Chris

---

From: Mark Townsley <[email-masked]>
Date: Tue, 24 Apr 2012 09:34:22 +0200

On Apr 24, 2012, at 8:45 AM, Wuyts Carl wrote:

> 
> [Carl] Yes.  A CPE is a router, hence should be capable of making routing decisions, taking into account multiple paths, metrics, …. .  Load balancing for instance might not be supported, so in case of multiple equal cost paths, it will take one of the available routes, but this is a known “issue” at that moment.  Lots of things can be set via TR-069 these days, so ISP can influence e.g. metrics when having native/tunneled combination and wanting to enforce a specific route.

We cannot assume all CPE have a TR-69 interface.

> [Carl] Not at all.  Our CPE supports both 6rd, static as well as using the DHCP option 212.  But when looking today at our customers, there for sure not hitting a 6rd move to native .

Not sure I understand that sentence.

But, let's just say I am looking at the largest  6rd deployments in the world, and working out how to migrate them to native. That's the basis behind the three requirements, and the reason they are being introduced in 6204-bis is that this is the first document that considers both native IPv6 and 6rd at the same time. 

I gather your primary customer set is a managed CPE with TR-69. WIth this model, you can of course leave all this up to configuration, and customize everything for each and every ISP in the world. Retail CPE are different, and the burden on the RFC greater, in order to achieve the level of consistency across the market that is needed for the model to work at all.

> [Carl] Saw the picture, see what you mean, but again, should be tackled, however not today.  Allow some time.

6rd has been deployed since 2007, how much longer do we need to get this right?

> [Carl] Same applies here as for 6rd. 

No. 6rd and DS-Lite are not the same, and do not solve the same problems. They are night and day different, and every time we lump them together it causes confusion and trouble. Please stop. 

> To start off, we do support it, again static and dynamic through dhcp option 64, so no issue on that part.  But proper deployment most likely will require some extra’s on the CPE, PCP, UPNP-IGD2, something else….  Similar applies here: people starting today to look at it (in Residential CPE world), but for sure not (yet) targeting the move to native-only, too soon (unfortunately).

The real scope creep is the inclusion of IPv4 delivery in an IPv6 CPE document to start with. If you want to draw a line, draw it before the inclusion of DS-Lite. Here in v6ops, we need to get IPv6 Internet service off the ground, and that's already taking plenty of energy as it is. 

> [Carl] Don’t fully agree J.  I see 6rd being used in various ways at our customers today.  I must say it’s working rather smooth, using the features they have available today, so I’d encourage to keep both 6rd and DSLite in the doc as is, but not start adding more requirements which are to be applied in later phases.

Yes, 6rd is working quite well, I cannot argue with you there. 

But, I also want my customers to be able to turn off 6rd, and for that to happen smoothly. Including the requirements for that in 6204-bis won't hurt that. As you have said, its all just what a "real router" would do anyway.

- Mark

> [Carl] I usually start from the other end @ home J
>  
> - Mark
> 
> 
>  
> Regs
> Carl
>

---

From: Maglione Roberta <[email-masked]>
Date: Tue, 24 Apr 2012 09:54:29 +0200

Hello,
 I agree with Carl: main issue delaying our IPv6 deployment is the IPv6 support on the CPE that's why we have been working hard with the editors to try to finalize 6204-bis ASAP.
We need an RFC for this document: I keep saying that, but people keep trying to add new things and delay this work.
This document was fine and stable before the addition of 6rd sunsetting requirements: this discussion just shows that 6rd sunsetting requirements are NOT mature enough to be added to 6204-bis.
As there is already a dedicated draft for 6rd sunsetting (draft-townsley-v6ops-6rd-sunsetting-00) I would suggest to keep the requirements there and let 6204-bis to be published as RFC.

Best regards,
Roberta

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wuyts Carl
Sent: martedì 24 aprile 2012 8.00
To: Chris Donley; Mark Townsley; [email-masked]
Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis

+1 on Hemants comment.

Regs
Carl

Mark,

Please see in-line.

Chris

1. I think this language (.MUST allow different or identical delegated prefixes.) is confusing for people not intimately familiar with your other CE transitioning draft.

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: Wuyts Carl <[email-masked]>
Date: Tue, 24 Apr 2012 11:23:39 +0200

@ Mark.

1.        Indeed we are deploying managed CPEs, so have a bit more flexibility in controlling the config vs retail.  Indeed, not all CPEs are TR-069 capable, but most of our customers do deploy it (quite typical for managed CPE).

2.       6rd and DSlite or indeed far from equal, I know.  What I meant is that the same principal applies, i.e. one is not rolling it out today, to decide tomorrow to go fully native all of a sudden.  Investments are being made, either 6rd or DSLite, or even both, which will not be thrown away the day after.   So the 6rd sunsetting indeed is something to become useful in later stages, but no urgency to include them as reqs today.

3.       6rd indeed exists for some time, you probably know a lot better than me :), but I've a pretty good view on what our customers are doing today with IPv6 in general 9so also with 6rd), and can assure you they are not looking at any 6rd sunsetting today.

So, as Roberta also says in her latest reply.  Please draw a line.  You say before DSLite, maybe, maybe not, I'd say, looking at millions of CPEs in the field, the 6rd sunsetting for sure are not needed today.  Wrt DSLite.  I don't think we can avoid it (unfortunately), but also here applies that the CPE should be able to handle those tunnels, but not yet to also include full PCP support or some other UPnP-kind of mechanism, it's too early for that (looking at them being mainly all draft stuff).  Of course CPE vendors should look into it today and judge upon its impact, but one cannot expect from the CPE vendor (you know, the very low cost device) to support all of it in 1 go.

I can even go 1 step further: RFC6106 support.  For the record: we do support it, however, I see lack of support in the LAN for it, hence not very usable today.  OK for CPE to have some basic support for it, but not "all the way" for simple reason that lots of hosts are not ready + the fact that no clear view on what should happen in case of both RA and DHCPv6 stateless, what is "best", what if different content, ....  This one however is only limited present in RFC6204, which is fine I guess.

Best regards
Carl

From: Mark Townsley [mailto:[email-masked]]
Sent: dinsdag 24 april 2012 9:34
To: Wuyts Carl
Cc: Chris Donley; [email-masked]
Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis

To start off, we do support it, again static and dynamic through dhcp option 64, so no issue on that part.  But proper deployment most likely will require some extra's on the CPE, PCP, UPNP-IGD2, something else....  Similar applies here: people starting today to look at it (in Residential CPE world), but for sure not (yet) targeting the move to native-only, too soon (unfortunately).

- Mark

That's why:

- Mark

Regs
Carl

Mark,

Please see in-line.

Chris

---

From: Alexandre Cassen <[email-masked]>
Date: Tue, 24 Apr 2012 21:10:10 +0200 (CEST)

Hi,

I can give you our perspective if usefull.

While we are not planning to turn off 6rd tomorow, we have been looking at 
how to do so. That is the reason why we are supporting this work.

regs,
Alexandre

> From: Wuyts Carl <[email-masked]>
> Subject: RE: [v6ops] 6rd sunsetting requirements for 6204-bis
> Date: April 24, 2012 11:23:39 AM GMT+02:00
> To: Mark Townsley <[email-masked]>
> Cc: Chris Donley <[email-masked]>, "[email-masked]" <[email-masked]>
> 
> @ Mark.
>  
> 1.        Indeed we are deploying managed CPEs, so have a bit more flexibility in controlling the config vs retail.  Indeed, not all CPEs are TR-069 capable, but most
> of our customers do deploy it (quite typical for managed CPE).
> 2.       6rd and DSlite or indeed far from equal, I know.  What I meant is that the same principal applies, i.e. one is not rolling it out today, to decide tomorrow to
> go fully native all of a sudden.  Investments are being made, either 6rd or DSLite, or even both, which will not be thrown away the day after.   So the 6rd sunsetting
> indeed is something to become useful in later stages, but no urgency to include them as reqs today.
>   
> 3.       6rd indeed exists for some time, you probably know a lot better than me J, but I?ve a pretty good view on what our customers are doing today with IPv6 in general
> 9so also with 6rd), and can assure you they are not looking at any 6rd sunsetting today.
>  
> So, as Roberta also says in her latest reply.  Please draw a line.  You say before DSLite, maybe, maybe not, I?d say, looking at millions of CPEs in the field, the 6rd
> sunsetting for sure are not needed today.  Wrt DSLite.  I don?t think we can avoid it (unfortunately), but also here applies that the CPE should be able to handle those
> tunnels, but not yet to also include full PCP support or some other UPnP-kind of mechanism, it?s too early for that (looking at them being mainly all draft stuff).  Of
> course CPE vendors should look into it today and judge upon its impact, but one cannot expect from the CPE vendor (you know, the very low cost device) to support all of
> it in 1 go.
>  
> I can even go 1 step further: RFC6106 support.  For the record: we do support it, however, I see lack of support in the LAN for it, hence not very usable today.  OK for
> CPE to have some basic support for it, but not ?all the way? for simple reason that lots of hosts are not ready + the fact that no clear view on what should happen in case
> of both RA and DHCPv6 stateless, what is ?best?, what if different content, ?.  This one however is only limited present in RFC6204, which is fine I guess.
>  
> Best regards
> Carl
>  
> [Carl] Yes.  A CPE is a router, hence should be capable of making routing decisions, taking into account multiple paths, metrics, ?..  Load balancing for instance might
> not be supported, so in case of multiple equal cost paths, it will take one of the available routes, but this is a known ?issue? at that moment.  Lots of things can be set
> via TR-069 these days, so ISP can influence e.g. metrics when having native/tunneled combination and wanting to enforce a specific route.
>  
> But, let's just say I am looking at the largest  6rd deployments in the world, and working out how to migrate them to native. That's the basis behind the three
> requirements, and the reason they are being introduced in 6204-bis is that this is the first document that considers both native IPv6 and 6rd at the same time. 
>  
> I gather your primary customer set is a managed CPE with TR-69. WIth this model, you can of course leave all this up to configuration, and customize everything for each
> and every ISP in the world. Retail CPE are different, and the burden on the RFC greater, in order to achieve the level of consistency across the market that is needed
> for the model to work at all.
> 
> 
>  
> I was also trying to do the same with DS-Lite, but have decided to give up. DS-Lite has become an enormous distraction to the deployment of IPv6 service to
> internet users, so I'm going to stop investing energy into trying to fix it here. Maybe v4-exit can do better in 6204-ter (sigh). 
> To start off, we do support it, again static and dynamic through dhcp option 64, so no issue on that part.  But proper deployment most likely will require some extra?s on
> the CPE, PCP, UPNP-IGD2, something else?.  Similar applies here: people starting today to look at it (in Residential CPE world), but for sure not (yet) targeting the move
> to native-only, too soon (unfortunately).
>  
> The real scope creep is the inclusion of IPv4 delivery in an IPv6 CPE document to start with. If you want to draw a line, draw it before the inclusion of DS-Lite. Here
> in v6ops, we need to get IPv6 Internet service off the ground, and that's already taking plenty of energy as it is. 
> 
> 
>  
> As I have said before, I am equally happy with the entire "Transition" section to be removed from 6204-bis. But, if we step off the cliff, we're going to get it right,
> at least for 6rd. Otherwise, it does more harm than good.
> [Carl] Don?t fully agree J.  I see 6rd being used in various ways at our customers today.  I must say it?s working rather smooth, using the features they have available
> today, so I?d encourage to keep both 6rd and DSLite in the doc as is, but not start adding more requirements which are to be applied in later phases.
>  
> But, I also want my customers to be able to turn off 6rd, and for that to happen smoothly. Including the requirements for that in 6204-bis won't hurt that. As you have
> said, its all just what a "real router" would do anyway.
>  
> - Mark
> 
> 
> I?ve been present on the last 2 v6 world congresses in Paris and the general statements there were always ?the CPE is the problem?.  Well, guess what, it still is, and it
> still will be if you don?t stop adding requirements. 
>       Please draw a line NOW, and take changes and added requirements into a later version so the CPE vendor has the time to cope with all of this!!!  I repeat my
>       statement from the panel: if we don?t stop adding requirements onto the (nearly free-of-charge) CPE, the next v6 congress will have again several
>       presentations claiming ?The CPE is the problem?.
>  
> Just on these specific ones: there is the claim that CPE devices are not ?ready? (whatever that may mean?).  Today, IPv6 roll-out is, unfortunately, still very (too)
> limited, but already ?6rd sunsetting? requirements are being added to the basic CPE IPV6 reqs, why ?  I don?t doubt this issue will present itself, but for sure not
> ?tomorrow?.
> 
>  
> That's why:
>  
>  
>  3. +1 to Hemant's comment ? I don't think this is needed as a MUST.
>  
>  1. I think this language (?MUST allow different or identical delegated prefixes?) is confusing for people not intimately familiar with your other CE transitioning draft. 
>  2. If I read this correctly, you want to require two operational states ? one where 6rd and native IPv6 use the same prefix and a second where they use different
>     prefixes. That requirement is captured in 6rd-5.
>  4. I've heard from some CPE vendors that specifying routing "cost" may be too implementation specific ? I think it's more neutral to speak of preference ? e.g. prefer
>     native to 6rd.
>  
>  
> 
> 
> 
> 
>

---

From: Wuyts Carl <[email-masked]>
Date: Wed, 25 Apr 2012 08:45:46 +0200

Hi Alexandre,

Every opinion counts, no doubt about that one.  Much appreciate your input.

I know that Free is one of the frontrunners on 6rd usage, which already differentiates you from a lot of others (I think).  Apart from that, I also do support the draft, which does not mean that it should be included in today's CPEs 6204 reqs, but it probably should in (one of) the next "release(s)/version(s)".

regs

Carl Wuyts
GCD System Architect Networking
CONNECT DIVISION
[email-masked]
tel.: +32 3 443 65 90

Prins Boudewijnlaan 47  -  2650 Edegem  -  Belgium
Technicolor Delivery Technologies Belgium NV
Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Edegem, Belgium
Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpen

Help preserve the color of our world - Think before you print.

-----Original Message-----
From: Alexandre Cassen [mailto:[email-masked]] 
Sent: dinsdag 24 april 2012 21:10
To: Wuyts Carl
Cc: Mark Townsley; Chris Donley; [email-masked]
Subject: Re: Fwd: [v6ops] 6rd sunsetting requirements for 6204-bis

Hi,

While we are not planning to turn off 6rd tomorow, we have been looking at how to do so. That is the reason why we are supporting this work.

regs,
Alexandre

> 1.        Indeed we are deploying managed CPEs, so have a bit more 
> flexibility in controlling the config vs retail.  Indeed, not all CPEs are TR-069 capable, but most of our customers do deploy it (quite typical for managed CPE).
> 2.       6rd and DSlite or indeed far from equal, I know.  What I 
> meant is that the same principal applies, i.e. one is not rolling it 
> out today, to decide tomorrow to go fully native all of a sudden.  Investments are being made, either 6rd or DSLite, or even both, which will not be thrown away the day after.   So the 6rd sunsetting indeed is something to become useful in later stages, but no urgency to include them as reqs today.
>   
> 3.       6rd indeed exists for some time, you probably know a lot 
> better than me J, but I?ve a pretty good view on what our customers are doing today with IPv6 in general 9so also with 6rd), and can assure you they are not looking at any 6rd sunsetting today.
>  
> So, as Roberta also says in her latest reply.  Please draw a line.  
> You say before DSLite, maybe, maybe not, I?d say, looking at millions 
> of CPEs in the field, the 6rd sunsetting for sure are not needed 
> today.  Wrt DSLite.  I don?t think we can avoid it (unfortunately), 
> but also here applies that the CPE should be able to handle those tunnels, but not yet to also include full PCP support or some other UPnP-kind of mechanism, it?s too early for that (looking at them being mainly all draft stuff).  Of course CPE vendors should look into it today and judge upon its impact, but one cannot expect from the CPE vendor (you know, the very low cost device) to support all of it in 1 go.
>  
> I can even go 1 step further: RFC6106 support.  For the record: we do 
> support it, however, I see lack of support in the LAN for it, hence 
> not very usable today.  OK for CPE to have some basic support for it, but not ?all the way? for simple reason that lots of hosts are not ready + the fact that no clear view on what should happen in case of both RA and DHCPv6 stateless, what is ?best?, what if different content, ?.  This one however is only limited present in RFC6204, which is fine I guess.
>  
> Best regards
> Carl
>  
> [Carl] Yes.  A CPE is a router, hence should be capable of making 
> routing decisions, taking into account multiple paths, metrics, ?..  
> Load balancing for instance might not be supported, so in case of multiple equal cost paths, it will take one of the available routes, but this is a known ?issue? at that moment.  Lots of things can be set via TR-069 these days, so ISP can influence e.g. metrics when having native/tunneled combination and wanting to enforce a specific route.
>  
> [Carl] Not at all.  Our CPE supports both 6rd, static as well as using 
> the DHCP option 212.  But when looking today at our customers, there for sure not hitting a 6rd move to native .
>  
> But, let's just say I am looking at the largest  6rd deployments in 
> the world, and working out how to migrate them to native. That's the basis behind the three requirements, and the reason they are being introduced in 6204-bis is that this is the first document that considers both native IPv6 and 6rd at the same time.
>  
> I gather your primary customer set is a managed CPE with TR-69. WIth 
> this model, you can of course leave all this up to configuration, and 
> customize everything for each and every ISP in the world. Retail CPE are different, and the burden on the RFC greater, in order to achieve the level of consistency across the market that is needed for the model to work at all.
> 
> 
>  
> All I am trying to do is make sure that *if* 6rd is in the document, 
> it is done correctly so we don't paint ourselves into a corner. [Carl] Saw the picture, see what you mean, but again, should be tackled, however not today.  Allow some time.
>  
> I was also trying to do the same with DS-Lite, but have decided to 
> give up. DS-Lite has become an enormous distraction to the deployment of IPv6 service to internet users, so I'm going to stop investing energy into trying to fix it here. Maybe v4-exit can do better in 6204-ter (sigh).
> No. 6rd and DS-Lite are not the same, and do not solve the same 
> problems. They are night and day different, and every time we lump them together it causes confusion and trouble. Please stop.
> 
> 
> To start off, we do support it, again static and dynamic through dhcp 
> option 64, so no issue on that part.  But proper deployment most 
> likely will require some extra?s on the CPE, PCP, UPNP-IGD2, something else?.  Similar applies here: people starting today to look at it (in Residential CPE world), but for sure not (yet) targeting the move to native-only, too soon (unfortunately).
>  
> The real scope creep is the inclusion of IPv4 delivery in an IPv6 CPE 
> document to start with. If you want to draw a line, draw it before the inclusion of DS-Lite. Here in v6ops, we need to get IPv6 Internet service off the ground, and that's already taking plenty of energy as it is.
> 
> 
>  
> As I have said before, I am equally happy with the entire "Transition" 
> section to be removed from 6204-bis. But, if we step off the cliff, we're going to get it right, at least for 6rd. Otherwise, it does more harm than good.
> [Carl] Don?t fully agree J.  I see 6rd being used in various ways at 
> our customers today.  I must say it?s working rather smooth, using the features they have available today, so I?d encourage to keep both 6rd and DSLite in the doc as is, but not start adding more requirements which are to be applied in later phases.
>  
> But, I also want my customers to be able to turn off 6rd, and for that 
> to happen smoothly. Including the requirements for that in 6204-bis won't hurt that. As you have said, its all just what a "real router" would do anyway.
>  
> - Mark
> 
> 
> I?ve been present on the last 2 v6 world congresses in Paris and the 
> general statements there were always ?the CPE is the problem?.  Well, guess what, it still is, and it still will be if you don?t stop adding requirements.
> Just on these specific ones: there is the claim that CPE devices are 
> not ?ready? (whatever that may mean?).  Today, IPv6 roll-out is, 
> unfortunately, still very (too) limited, but already ?6rd sunsetting? requirements are being added to the basic CPE IPV6 reqs, why ?  I don?t doubt this issue will present itself, but for sure not ?tomorrow?.
> 
>  
> That's why:
>  
>  
> Of Chris Donley
> 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN 
> interfaces to be active simultaneously in order to support coexistence 
> of the two technologies during an incremental migration period from 
> 6rd to native IPv6.
>  1. I think this is covered in 6rd-5 and 6rd-7.  2. I don't think this 
> specific requirement was agreed to in Paris.  It's not on your slide 4 or Slide 15, bullet 1, which were the 'hum's I captured in my notes.
> 6RD-6: The IPv6 CE router MUST allow different or identical delegated 
> prefixes on 6rd and native interfaces. A 6rd virtual interface MUST be 
> assigned a higher routing cost than a native IPv6 interface. This is 
> done so that native traffic will be preferred over 6rd in the event 
> normal IP longest matching and BCP 84 rules would have otherwise 
> allowed a packet to be equally sent via 6rd or native IPv6.
>  1. I think this language (?MUST allow different or identical 
> delegated prefixes?) is confusing for people not intimately familiar with your other CE transitioning draft.  2. If I read this correctly, you want to require two operational states ? one where 6rd and native IPv6 use the same prefix and a second where they use different