Subject: [v6ops] FW: 6rd sunsetting requirements for 6204-bis

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

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Simon Perreault
Sent: Monday, April 23, 2012 2:37 PM
To: [email-masked]
Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis

>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.

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.  

Hemant

---

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

On 2012-04-23 14:42, Hemant Singh (shemant) wrote:
> Sorry, still does not cut it for me. Fix the bug in the CPE router.

It's a bug according to which RFC?

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: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 23 Apr 2012 14:15:26 -0500

-----Original Message-----
From: Simon Perreault [mailto:[email-masked]] 
Sent: Monday, April 23, 2012 2:48 PM
To: Hemant Singh (shemant)
Cc: [email-masked]
Subject: Re: FW: [v6ops] 6rd sunsetting requirements for 6204-bis

>It's a bug according to which RFC?

Do you really think an RFC would specify router behavior for concurrent
operation of a GRE tunnel, native IPv6, and native IPv4 operations on a
router?  There are Enterprise and network access edge routers shipping
for ages where concurrent tunneled and native IP on the router works
just fine with specific configuration on the router.  

The bigger question for the CPE router is, soon as the CPE supports
concurrent operation of native IPv6 and 6rd, how is the CPE FIB and RIB
supposed to work?  There is no specification out there in RFC form that
covers the operations insides the CPE for the FIB and the RIB.  MarkT
and Ole have a draft (draft-townsley-troan-ipv6-ce-transitioning-02)
that has started the work with a SourcreRIB and DestRIB.  However, this
work is incomplete. See an email I sent to v6ops on 03/24/2012 with my
review of draft-townsley-troan-ipv6-ce-transitioning-02.

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

We are putting the cart before the horse if we include Mark's new
requirements from today into rfc6204bis.

Hemant

---

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

> just fine with specific configuration on the router.

Agreed, I don't think this should be specified.

But Mark's argument is, if I understand correctly, that not supporting 
native alongside 6rd *harms the Internet* because it prevents graceful 
transitioning from 6rd to native. That argument is specific to 6rd, not 
generic to all tunnel interfaces.

Simon

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 23 Apr 2012 14:31:21 -0500

-----Original Message-----
From: Simon Perreault [mailto:[email-masked]] 
Sent: Monday, April 23, 2012 3:21 PM
To: Hemant Singh (shemant)
Cc: [email-masked]
Subject: Re: FW: [v6ops] 6rd sunsetting requirements for 6204-bis

>generic to all tunnel interfaces.

Fine for an argument.  But again, the CPE router is consumer device that
needs a specification for automata related to concurrent operation of
native IPv6 and 6rd including specifying the transition from native IPv6
6rd or vice versa.  Such a specification does not exist in RFC form.
Rfc6204bis only accepts technology in RFC form or in rare exceptions,
technology where the draft is in the IESG.  

Hemant

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 24 Apr 2012 08:31:23 -0500

V6ops Chairs,

I'd like to defer to you on this one.  We have been down this road
during the past two months where the
draft-townsley-troan-ipv6-ce-transitioning-02 is trying to add
requirements to rfc6204bis but the
draft-townsley-troan-ipv6-ce-transitioning-02 is clearly not completed
work.    The draft-townsley-troan-ipv6-ce-transitioning-02 seems to be
boiling the ocean and is not going to be an RFC even in one year.   So
could we stop the 6rd thrashing and just ship rfc6204bis with basic 6rd
requirements?  Further, we are also going in circles.  6rd folks gave
Chris some text to add to rfc6304bis at Paris but when Chris adds the
text to rfc6204bis we are thrashing with that text too.    I don't think
any advanced 6rd requirement has gestated for text in the past two
months.    

My humble recommendation is to ship rfc6204bis right now.  I am happy to
back out the Paris text added for 6rd in the -08 version.

Hemant

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hemant Singh (shemant)
Sent: Monday, April 23, 2012 3:31 PM
To: Simon Perreault
Cc: [email-masked]
Subject: Re: [v6ops] FW: 6rd sunsetting requirements for 6204-bis

-----Original Message-----
From: Simon Perreault [mailto:[email-masked]] 
Sent: Monday, April 23, 2012 3:21 PM
To: Hemant Singh (shemant)
Cc: [email-masked]
Subject: Re: FW: [v6ops] 6rd sunsetting requirements for 6204-bis

Hemant

---

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

On Apr 24, 2012, at 3:31 PM, Hemant Singh (shemant) wrote:

> V6ops Chairs,
>  
> I’d like to defer to you on this one. 

I think the chairs would expect that.

For this case, the chairs already made their call. The reason we are here is that you and Chris didn't follow what was asked by them.

What was asked was to Include the three basic requirements based on my presentation. I sent those to Chris one week after the IETF. He decided to throw them in the trash, instead giving you a different set to publish. 

The best way to end this, is to just take the advice from the people who have actually built and deployed 6rd for some time, and have planned out the CPE requirements for how to transition to native and include that text. Before you didn't have that text, because Chris threw it away. Now you do. 

- Mark

> We have been down this road during the past two months where the draft-townsley-troan-ipv6-ce-transitioning-02 is trying to add requirements to rfc6204bis but the draft-townsley-troan-ipv6-ce-transitioning-02 is clearly not completed work.    The draft-townsley-troan-ipv6-ce-transitioning-02 seems to be boiling the ocean and is not going to be an RFC even in one year.   So could we stop the 6rd thrashing and just ship rfc6204bis with basic 6rd requirements?  Further, we are also going in circles.  6rd folks gave Chris some text to add to rfc6304bis at Paris but when Chris adds the text to rfc6204bis we are thrashing with that text too.    I don’t think any advanced 6rd requirement has gestated for text in the past two months.    
>  
> My humble recommendation is to ship rfc6204bis right now.  I am happy to back out the Paris text added for 6rd in the -08 version.
>  
> Hemant
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hemant Singh (shemant)
> Fine for an argument.  But again, the CPE router is consumer device that needs a specification for automata related to concurrent operation of native IPv6 and 6rd including specifying the transition from native IPv6 6rd or vice versa.  Such a specification does not exist in RFC form.  Rfc6204bis only accepts technology in RFC form or in rare exceptions, technology where the draft is in the IESG.  
>  
> Hemant
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Fred Baker <[email-masked]>
Date: Tue, 24 Apr 2012 23:33:10 +0200

We discussed this at IETF 83, and you will find it in the minutes when they come out. Mark and Ole asked for two things (statements regarding 6rd and ds-lite), and the working group agreed to one of them. We are not discussing a "boiling of the ocean", nor are we discussing an infinite succession of new requirements. We are discussing getting three no-brainer-class statements into the draft in a manner that the discussants all recognize and agree to. The three statements were clarified by hum in the meeting, and were each able to be stated in a single sentence.

I would ask the different actors in this discussion to please behave in a courteous manner toward each other, and work together on this as requested by the chairs at IETF 83.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 24 Apr 2012 22:05:42 -0500

Fred,

Appreciate the quick reply.  In MarkT's comments to Chris that Chris did
not follow the Chairs' recommendation, the statement is not quite
correct.  Additionally MarkT saying to the mailer that  "He (Chris)
decided to throw them in the trash" is not correct either.  See the URL
below where Chris clearly said, he has guidance from the IETF and WG in
the past to not include more than one normative statement per
requirement.  Thus Chris broke up the MarkT recommendations and the
break up has to stay.  Thus it would help if Mark revisits Chris' text
and fills in holes Mark thinks the text has because we just cannot go
back to Mark's original text that combines multiple normative statements
in one requirement.

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

Moving on, the requirements provided by MarkT could use tighter text.
For example here is a portion of text provided to us to add.

"6RD-5: The CE router MUST associate delegated prefixes with the WAN

interface(s)"

The CPE WAN interface can be unnumbered with only an IPv6 link-local
address and thus the CPE WAN does not have a global IPv6 address.  In
such an unnumbered model, the CPE uses an address from the PD on a
virtual network interface to source packets out the WAN such as ICMPv6
errors.  I am away from work tomorrow but we can certainly try and close
any text two days from now including any WebEx phone call between Mark
and us authors of rfc6204bis.  

Another example for tighter text is related to 6RD-4.  Why does 6RD-4
only say "during an incremental migration period from 6rd to native
IPv6."    The SP could encounter a problem moving from 6rd to native
IPv6 and may want to revert back to 6rd.  Thus the 6RD-4 bullet should
cater to any migration from 6rd to native IPv6 or vice versa.

Further, when the CPE has different prefixes being used by native IPV6
and 6rd, a host behind the CPE router has concurrent IPv6 addresses
being used (one IPv6 address from native IPv6 and another from the 6rd
prefix).  So what source-address does the host pick to send a packet to
a destination that is totally disjoint with the two prefixes assigned to
the CPE router?  Let's say the host picked a source address from the 6rd
prefix, then the CPE router ships the packet out the 6rd tunnel instead
of the higher preferred native IPv6 network.  So how is the native IPv6
preference enforced by the CPE router?   

We also do not have consensus with the "MUST" in 6RD-4.  Current
consensus is mostly towards changing the MUST to a SHOULD.  I also do
not see any SP clamoring for 6rd sunsetting.  One SP in France or France
that has roughly million 6rd customers does not impress me.  I am a
person who gets impressed with 200 million customers which is roughly
what the cable broadband industry is deploying native IPv6 for.  

Hemant

-----Original Message-----

Of Fred Baker (fred)

Sent: Tuesday, April 24, 2012 5:33 PM

To: IPv6 Operations

We discussed this at IETF 83, and you will find it in the minutes when
they come out. Mark and Ole asked for two things (statements regarding
6rd and ds-lite), and the working group agreed to one of them. We are
not discussing a "boiling of the ocean", nor are we discussing an
infinite succession of new requirements. We are discussing getting three
no-brainer-class statements into the draft in a manner that the
discussants all recognize and agree to. The three statements were
clarified by hum in the meeting, and were each able to be stated in a
single sentence.

I would ask the different actors in this discussion to please behave in
a courteous manner toward each other, and work together on this as
requested by the chairs at IETF 83.

v6ops mailing list

[email-masked]

---

From: Fred Baker <[email-masked]>
Date: Wed, 25 Apr 2012 05:23:07 +0200

On Apr 25, 2012, at 5:05 AM, Hemant Singh (shemant) wrote:

> Fred,
>  
> Appreciate the quick reply.  In MarkT's comments to Chris that Chris did not follow the Chairs' recommendation, the statement is not quite correct.  Additionally MarkT saying to the mailer that  "He (Chris) decided to throw them in the trash" is not correct either.  See the URL below where Chris clearly said, he has guidance from the IETF and WG in the past to not include more than one normative statement per requirement.  Thus Chris broke up the MarkT recommendations and the break up has to stay.  Thus it would help if Mark revisits Chris’ text and fills in holes Mark thinks the text has because we just cannot go back to Mark’s original text that combines multiple normative statements in one requirement.

I would like you to please work with Mark, on the mailer, to accomplish that. 

> Moving on, the requirements provided by MarkT could use tighter text.  For example here is a portion of text provided to us to add.
>  
> interface(s)”
> The CPE WAN interface can be unnumbered with only an IPv6 link-local address and thus the CPE WAN does not have a global IPv6 address.  In such an unnumbered model, the CPE uses an address from the PD on a virtual network interface to source packets out the WAN such as ICMPv6 errors.  I am away from work tomorrow but we can certainly try and close any text two days from now including any WebEx phone call between Mark and us authors of rfc6204bis. 

I suspect that you misunderstand Mark's text, which says that the text he suggested was inadequate. 

RFC 3704, resolving a number of pages into a single sentence, recommends that if a packet uses a stated source address and that source address was derived from a stated upstream network, the packet should be directed to said upstream network. The reason it would do so is that the upstream networks presumably implement BCP 38, meaning that if it is directed to a different upstream network it is likely to be dropped. 3704 goes on to make suggestions regarding the implementation of exit routing. What Mark is driving at is "implement exit routing; if one is given multiple prefixes on different interfaces, physical or virtual, associate each such prefix with its source interface in routing for the purposes of source-address directed exit routing."

Explanations and dialog such as this are the reason I am asking you to TALK WITH MARK about issues you see rather than talking with the chairs or simply presuming that the working group outcome in Paris is brain-dead. The outcome was, as near as I could tell, very sensible to the operators.

> Another example for tighter text is related to 6RD-4.  Why does 6RD-4 only say “during an incremental migration period from 6rd to native IPv6.”    The SP could encounter a problem moving from 6rd to native IPv6 and may want to revert back to 6rd.  Thus the 6RD-4 bullet should cater to any migration from 6rd to native IPv6 or vice versa.
>  
> Further, when the CPE has different prefixes being used by native IPV6 and 6rd, a host behind the CPE router has concurrent IPv6 addresses being used (one IPv6 address from native IPv6 and another from the 6rd prefix).  So what source-address does the host pick to send a packet to a destination that is totally disjoint with the two prefixes assigned to the CPE router?  Let’s say the host picked a source address from the 6rd prefix, then the CPE router ships the packet out the 6rd tunnel instead of the higher preferred native IPv6 network.  So how is the native IPv6 preference enforced by the CPE router?  
>  
> We also do not have consensus with the “MUST” in 6RD-4.  Current consensus is mostly towards changing the MUST to a SHOULD.  I also do not see any SP clamoring for 6rd sunsetting.  One SP in France or France that has roughly million 6rd customers does not impress me.  I am a person who gets impressed with 200 million customers which is roughly what the cable broadband industry is deploying native IPv6 for.  
>  
> Hemant
>  
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred Baker (fred)

---

From: Mark Townsley <[email-masked]>
Date: Wed, 25 Apr 2012 12:10:08 +0200

Whittled down to one sentence each, here are three requirements necessary in order to support incremental migration from 6rd to native IPv6: 

6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces to be active simultaneously. 

6RD-5: Each packet sent on a 6rd or native WAN interface MUST be directed such that its source IP address is derived from the delegated prefix associated with the upstream network the WAN interface is connected to [section 4.3 of BCP 84, RFC 3704].

6RD-6: The CE router MUST allow identical or overlapping delegated prefixes for each WAN interface with a preference for native IPv6 in the event forwarding rules would have otherwise directed a packet to be sent equally via 6rd or native IPv6.

Summary: The first requirement says 6rd and native must coexist, the second ensures that packets are directed such that they are not dropped by the upstream network, and the third ensures native is chosen over 6rd in the event the paths are otherwise equal. 

- Mark

---

From: Sander Steffann <[email-masked]>
Date: Wed, 25 Apr 2012 14:14:55 +0400

Hi Mark,

> Summary: The first requirement says 6rd and native must coexist, the second ensures that packets are directed such that they are not dropped by the upstream network, and the third ensures native is…

+1

- Sander

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 25 Apr 2012 06:08:36 -0500

One question.  Which RFC specifies the technology for the procedure to
sunset 6rd to native IPv6 or vice versa between the SP and the CPE
router?  

Hemant

---

From: Shane Amante <[email-masked]>
Date: Wed, 25 Apr 2012 07:52:32 -0600

>> Summary: The first requirement says 6rd and native must coexist, the second ensures that packets are directed such that they are not dropped by the upstream network, and the third ensures native i…

The above are all logical & straightforward, so an addt'l +1.

-shane

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 25 Apr 2012 10:08:35 -0500

We are glossing over lot of unspecified technology with the MarkT 6rd
sunsetting reqs, but if the WG so deems, I'd be happy to put the MarkT
text into rfc6204bis and move rfc6204bis forward.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Hemant Singh (shemant)
Sent: Wednesday, April 25, 2012 7:09 AM
To: Fred Baker (fred); IPv6 Operations
Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis

Hemant

---

From: Chris Donley <[email-masked]>
Date: Wed, 25 Apr 2012 10:19:35 -0600

I'm OK with 6rd-5.

I'm OK in principle with 6rd-4, but I am concerned that as written, it might be interpreted that both 6rd and native always need to be active simultaneously, and I think that could cause problems when it's not the intent of the ISP.  Perhaps the following would clarify:
6RD-4: A CE router MUST support simultaneous operation of 6rd virtual and IPv6 native WAN interfaces.  However, 6rd and native IPv6 can be configured independently; in many cases, only a single IPv6 WAN interface (native or 6rd) needs to be active.

6rd-6 is really two requirements.  I am concerned that its current form is ambiguous.  I would prefer:
6rd-6: The IPv6 CE Router MUST allow the 6rd virtual interface and IPv6 native interface to use identical or overlapping prefixes. This requirement does not preclude the IPv6 CE Router from using different prefixes for the 6rd virtual interface and IPv6 native interface.
6rd-7: In the event that forwarding rules produce a tie between 6rd and native IPv6, by default, the IPv6 CE Router MUST prefer native IPv6.

Chris

From: Mark Townsley <[email-masked]<mailto:[email-masked]>>
Date: Wed, 25 Apr 2012 04:10:08 -0600
To: IPv6 Operations <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis

- Mark

Fred,

Hemant

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Fred Baker (fred)
Sent: Tuesday, April 24, 2012 5:33 PM
To: IPv6 Operations
Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis

I would ask the different actors in this discussion to please behave in a courteous manner toward each other, and work together on this as requested by the chairs at IETF 83.
_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

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

---

From: Alexandre Cassen <[email-masked]>
Date: Wed, 25 Apr 2012 18:49:32 +0200 (CEST)

On Wed, 25 Apr 2012, Sander Steffann wrote:
> Date: Wed, 25 Apr 2012 14:14:55 +0400
> From: Sander Steffann <[email-masked]>
> To: Mark Townsley <[email-masked]>
> Cc: IPv6 Operations <[email-masked]>

+1

regs,
Alexandre

---

From: Rémi Després <[email-masked]>
Date: Wed, 25 Apr 2012 19:09:01 +0200

Mark,

While it is important that 6204bis includes 6rd, and while it is also important to specify a 6rd sunsetting plan (good that you took the initiative), I don't think it is right to include 6RD-4 to 6RD-6 at this stage.

Reasons:
- Proof that no sunsetting solution is possible without these requirements hasn't been given.
- I even think that, in a node supporting both IPv6 via IPv4 (6rd) and IPv4 via IPv6 with public IPv4 addresses (MAP or 4rd), the IPv4 and IPv4 and IPv6 routers can each see only one interface. (The fact that it uses link layer interfaces natively or with some tunneling can AFAIK be kept invisible to the router.)

Until a complete solution is described, doubt remains, but freezing now the idea that this would be impossible isn't needed.

Suggestion: keep 6RD-1 to 6RD-4, replace the others by a note warning that a specification needs to be added to handle 6RD sunsetting.

Regards,
RD

---

From: Wes Beebee <[email-masked]>
Date: Wed, 25 Apr 2012 13:57:22 -0400

> Whittled down to one sentence each, here are three requirements necessary in
> order to support incremental migration from 6rd to native IPv6:
> 
> 
> 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be directed such
> that its source IP address is derived from the delegated prefix associated
> with the upstream network the WAN interface is connected to [section 4.3 of
> BCP 84, RFC 3704].
> 
> 6RD-6: The CE router MUST allow identical or overlapping delegated prefixes
> for each WAN interface with a preference for native IPv6 in the event
> forwarding rules would have otherwise directed a packet to be sent equally via
> 6rd or native IPv6.

I see no problem with replacing the existing 6RD requirements in 6204bis
with this text.  Note that this text is sufficiently abstracted to the point
where my previous suggested implementation of 6rd/native co-existance AND
Mark's suggested implementation can both be accomodated by this text - so
that's proof enough that it gives implementers enough "wiggle room" to
figure out the best way of interpreting these bullets.

- Wes

---

From: Mark Townsley <[email-masked]>
Date: Wed, 25 Apr 2012 20:17:22 +0200

> Until a complete solution is described, doubt remains, but freezing now the idea that this would be impossible isn't needed.

Renaming the thread as this is taking a direction towards inclusion of 4rd as well as 6rd.

Remi - we agree in that I absolutely do think that 6204-bis has stepped in the wrong direction by recommending DS-Lite without considering the stateless alternatives as well as how to handle deployment alongside native IPv4 in a consistent and predictable manner. I tried, and failed, to sway the WG here though. The idea of a note saying that this is "still as of yet undefined" I think would be quite appropriate in this space. I would definitely support that, but the WG seems to not be open to much change at all right now. Regarding 6rd and native IPv6, the solution space is far more straightforward in terms of their coexistence as well as the fact that 6rd is clearly dominant in terms of transition solution deployment today. It's a big win to go ahead and get this defined now, and the idea that we don't understand it well enough after nearly 5 years of deployed 6rd, would seem a rather weak statement. 

Referring back to Fred's email, the chairs have decided to take the three requirements that outline how 6rd and and native IPv6 can coexist in a way that allows both to be deployed at the same time, while giving proper preference to native vs. 6rd when the routing decision would otherwise have found them equal. Let's please focus on whether or not the requirements are worded properly for that case, without inclusion of 4rd, MAP-T, MAP-E, MAP-U, Stateless DS-Lite, SD-NAT, CGN, DS-Lite with Global IPv4 addresses, 464xlat, or any of the other IPv4 delivery options. 6rd is quietly enjoying quite a bit of success here in terms of getting users connected to the IPv6 internet, trying to couple it with any or all of the v4-exit alternatives has clearly shown the ability to be a considerable distraction.

- Mark

---

From: Rémi Després <[email-masked]>
Date: Wed, 25 Apr 2012 22:14:43 +0200

Le 2012-04-25 à 20:17, Mark Townsley a écrit :

> Referring back to Fred's email, the chairs have decided to take the three requirements that outline how 6rd and and native IPv6 can coexist in a way that allows both to be deployed at the same time, while giving proper preference to native vs. 6rd when the routing decision would otherwise have found them equal. Let's please focus on whether or not the requirements are worded properly for that case,

> without inclusion of 4rd, MAP-T, MAP-E, MAP-U, Stateless DS-Lite, SD-NAT, CGN, DS-Lite with Global IPv4 addresses, 464xlat, or any of the other IPv4 delivery options.

Full agreement to not include any of these.

If, in my explanation above, there is a reference to tools that assign public IPv4 addresses across IPv6-only networks, it is only  because at least one such tool is needed for an ISP to eliminate 6rd (and the IPv4-only network that goes with it) without waiting for customers to no longer need their IPv4 addresses. 

Note that my proposal (*) below has purposely none of the acronyms that neither of us want to include in 6204bis.
As such, I hope it is acceptable. 

> 6rd is quietly enjoying quite a bit of success here in terms of getting users connected to the IPv6 internet, trying to couple it with any or all of the v4-exit alternatives has clearly shown the ability to be a considerable distraction.
> 
> - Mark
> 
>> Suggestion: keep 6RD-1 to 6RD-4,

(*)
>> replace the others by a note warning that a specification needs to be added to handle 6RD sunsetting.

Regards,
RD

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 25 Apr 2012 20:16:01 -0500

Mark,

Sorry, it's hard to read the formatting of your emails to v6ops  to catch what you said vs. what any other person said.   Could you please do me a favor and use the "> bla bla" formatting to show the Remi statements and then yours without any ">".   This is a format you use is some private emails I have received from you. 

Secondly, my humble apologies, but  it's gets to be a non-starter, if each time we discuss your 6rd requirements you bring up DS-Lite.   Can we leave DS-Lite out of the 6rd discussion.   After all, DS-Lite is one stateful protocol and the nature of a stateful protocol over a stateless protocol is that stateful protocol incurs additionally complexity.   However, the benefits of a stateful protocol such as DS-Lite are clear too.    DS-Lite was an RFC when rfc6204bis was getting authored and stateless 4rd or the slew of other protocols were not.    Take this use case that 6rd or any stateless protocol fails for that a stateful protocol will not fail for.  Victor raised something similar last time 6rd sunsetting was discussed.    

A user is involved in a VoIP call from the user's PC behind a CPE router using 6rd.   Midway through the call, the other end of the phone call switches to native IPv6.   The phone call breaks down.    How can an SP really deploy VoIP phone service with such a stateless protocol?  

Thank you Remi for agreeing with me since I have been asking for over 24 hours to this mailer as to how can requirements for 6rd sunsetting be added to rfc6204bis when no RFC exists that specifies the technology for how to sunset 6rd or reverting back to 6rd.   I have been also catching the fact that not only does one consider sunsetting 6rd but also consider reverting the sunsetting.

Also, Remi, for the record,  it was rfc6204bis which first wrote up the 6rd sunsetting and revert procedure, including concurrent operation of 6rd and native IPv6.   However,  some folks pointed out that our procedure was specifying technology that a v6ops can't do.  So our text was taken out of rfc6204bis and actually incorporated into another draft.

Hemant

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Townsley
Sent: Wednesday, April 25, 2012 2:17 PM
To: Rémi Després
Cc: IPv6 Operations
Subject: Re: [v6ops] 6rd (and 4rd) sunsetting requirements for 6204-bis

Mark,

Reasons:

- Mark

---

From: Fred Baker <[email-masked]>
Date: Wed, 25 Apr 2012 21:05:31 -0700

> text into rfc6204bis and move rfc6204bis forward.

That decision was made a few weeks ago, face to face, at IETF 83.

---

From: Wuyts Carl <[email-masked]>
Date: Thu, 26 Apr 2012 07:51:03 +0200

+1 on Remi's suggestion below.

I agree with Mark that stateless is often, not always (e.g. some stateless mechanisms are defined too complex) a better solution over stateful, however, we should not be blind for the DSLite story so should indeed not be taken into this discussion.

Regs
Carl

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rémi Després
Sent: woensdag 25 april 2012 19:09
To: Mark Townsley
Cc: IPv6 Operations
Subject: Re: [v6ops] 6rd sunsetting requirements for 6204-bis

Mark,

Reasons:

Regards,
RD

- Mark

Fred,

Appreciate the quick reply.  In MarkT's comments to Chris that Chris did not follow the Chairs' recommendation, the statement is not quite correct.  Additionally MarkT saying to the mailer that  "He (Chris) decided to throw them in the trash" is not correct either.  See the URL below where Chris clearly said, he has guidance from the IETF and WG in the past to not include more than one normative statement per requirement.  Thus Chris broke up the MarkT recommendations and the break up has to stay.  Thus it would help if Mark revisits Chris' text and fills in holes Mark thinks the text has because we just cannot go back to Mark's original text that combines multiple normative statements in one requirement.

Another example for tighter text is related to 6RD-4.  Why does 6RD-4 only say "during an incremental migration period from 6rd to native IPv6."    The SP could encounter a problem moving from 6rd to native IPv6 and may want to revert back to 6rd.  Thus the 6RD-4 bullet should cater to any migration from 6rd to native IPv6 or vice versa.

Further, when the CPE has different prefixes being used by native IPV6 and 6rd, a host behind the CPE router has concurrent IPv6 addresses being used (one IPv6 address from native IPv6 and another from the 6rd prefix).  So what source-address does the host pick to send a packet to a destination that is totally disjoint with the two prefixes assigned to the CPE router?  Let's say the host picked a source address from the 6rd prefix, then the CPE router ships the packet out the 6rd tunnel instead of the higher preferred native IPv6 network.  So how is the native IPv6 preference enforced by the CPE router?

We also do not have consensus with the "MUST" in 6RD-4.  Current consensus is mostly towards changing the MUST to a SHOULD.  I also do not see any SP clamoring for 6rd sunsetting.  One SP in France or France that has roughly million 6rd customers does not impress me.  I am a person who gets impressed with 200 million customers which is roughly what the cable broadband industry is deploying native IPv6 for.

Hemant

---

From: Ole Trøan <[email-masked]>
Date: Thu, 26 Apr 2012 11:17:44 +0200

> +1 on Remi’s suggestion below.

disagree. either we include 6rd and define completely how it is going to work.
or we do not include it at all. 6rd is a transitioning mechanism, i.e. it is going to go away to be replaced by native IPv6 at some point. hand-waving that issue now, is like peeing in your trousers to keep warm. ;-)
assuming we're defining this for devices that will not readily be firmware upgradable.

(Remi's proposal can be expressed as {RFC6204 + RFC5969}, so if we were to do that, I don't think that needs any text at all in 6204.)

> I agree with Mark that stateless is often, not always (e.g. some stateless mechanisms are defined too complex) a better solution over stateful, however, we should not be blind for the DSLite story…

agree. DS-lite provides IPv4 service. it is independently of everything else in 6204.

cheers,
Ole

---

From: Mark Townsley <[email-masked]>
Date: Thu, 26 Apr 2012 14:25:38 +0200

On Apr 25, 2012, at 6:19 PM, Chris Donley wrote:

> I'm OK with 6rd-5.  
> 
> I'm OK in principle with 6rd-4, but I am concerned that as written, it might be interpreted that both 6rd and native always need to be active simultaneously, and I think that could cause problems when it's not the intent of the ISP.  

"6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces to be active simultaneously."

I find it hard to believe that someone would interpret "allow" as "always". 

> Perhaps the following would clarify:

No, you have added a subjective "in many cases" here that unnecessarily dates the document. The whole idea is that in the future it will be far more than "in many cases" as 6rd transitions to native. 

> 6rd-6 is really two requirements.  I am concerned that its current form is ambiguous.  I would prefer:

The case where the 6rd path and native path need the tie-breaker will not happen when the WAN prefixes are different. That's why it's worded as one requirement, its only applicable when the prefixes are the same.  

> 6rd-7: In the event that forwarding rules produce a tie between 6rd and native IPv6, by default, the IPv6 CE Router MUST prefer native IPv6.

I have no technical objection with the above. I think it is back to being too wordy, which was the original complaint with my text I offered you and Hemant. 

And, Fred gave clear guidance, one sentence per requirement, and 3 requirements. 

I'll work up a new set and see if the WG prefers it. 

- Mark

> 
> Chris
> 
> From: Mark Townsley <[email-masked]>
> To: IPv6 Operations <[email-masked]>

---

From: Mark Townsley <[email-masked]>
Date: Thu, 26 Apr 2012 14:49:04 +0200

Chris,

Here is a new set of requirements based on your feedback. In this version, I adopted some but not all of what you were asking for. Specifically,

- I adopted your 6RD-7 text verbatim (though I still personally prefer using the term "equal" vs. "tie") 

- I changed my text that specified only that delegated prefixes could be identical, to say that they could be identical as well as different.

- I couldn't come up with any other way to clarify "allow" not meaning "always" without complicating the text in 6RD-4. 

- I did not include text that suggested whether having one active interface vs. two would be more or less a common case.

We now have 4 requirements instead of 3. I am still OK with my original 3, but if you and the WG prefer these 4 that is fine by me as well. 

- Mark

6RD-6: The CE router MUST allow different or identical delegated prefixes to be configured via each WAN interface.

6RD-7 In the event that forwarding rules produce a tie between 6rd and native IPv6, by default, the IPv6 CE Router MUST prefer native IPv6.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 26 Apr 2012 14:40:21 -0500

I did like the context of 6rd sunsetting with the original 6RD-4 because
if we do not provide context, folks may ask to the mailer 6 months or
two years from now as to why two concurrent tech?

6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces
to be active simultaneously such as when the CPE router is sunsetting
6rd or reverting the 6rd sunsetting.

Tweaked 6RD-5 a little.

6RD-5: Each packet sent out the WAN interface via a 6rd or native IPv6
interface MUST be directed such that its source IPv6 address is derived
from the delegated prefix associated with the egress interface. [section
4.3 of BCP 84, RFC 3704].

Hemant

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Mark Townsley
Sent: Thursday, April 26, 2012 8:49 AM
To: Chris Donley; IPv6 Operations
Subject: [v6ops] 6rd sunsetting requirements (version 2)

Chris,

Here is a new set of requirements based on your feedback. In this
version, I adopted some but not all of what you were asking for.
Specifically,

- I adopted your 6RD-7 text verbatim (though I still personally prefer
using the term "equal" vs. "tie") 

- I changed my text that specified only that delegated prefixes could be
identical, to say that they could be identical as well as different.

- I couldn't come up with any other way to clarify "allow" not meaning
"always" without complicating the text in 6RD-4. 

- I did not include text that suggested whether having one active
interface vs. two would be more or less a common case.

We now have 4 requirements instead of 3. I am still OK with my original
3, but if you and the WG prefer these 4 that is fine by me as well. 

- Mark

6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces
to be active simultaneously. 

6RD-5: Each packet sent on a 6rd or native WAN interface MUST be
directed such that its source IP address is derived from the delegated
prefix associated with the upstream network the WAN interface is
connected to [section 4.3 of BCP 84, RFC 3704].

6RD-6: The CE router MUST allow different or identical delegated
prefixes to be configured via each WAN interface.

6RD-7 In the event that forwarding rules produce a tie between 6rd and
native IPv6, by default, the IPv6 CE Router MUST prefer native IPv6.

 

Whittled down to one sentence each, here are three requirements
necessary in order to support incremental migration from 6rd to native
IPv6: 

6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces
to be active simultaneously. 

6RD-5: Each packet sent on a 6rd or native WAN interface MUST be
directed such that its source IP address is derived from the delegated
prefix associated with the upstream network the WAN interface is
connected to [section 4.3 of BCP 84, RFC 3704].

6RD-6: The CE router MUST allow identical or overlapping delegated
prefixes for each WAN interface with a preference for native IPv6 in the
event forwarding rules would have otherwise directed a packet to be sent
equally via 6rd or native IPv6.

Summary: The first requirement says 6rd and native must coexist, the
second ensures that packets are directed such that they are not dropped
by the upstream network, and the third ensures native is chosen over 6rd
in the event the paths are otherwise equal. 

- Mark

 

Fred,

I would like you to please work with Mark, on the mailer, to accomplish
that. 

	Moving on, the requirements provided by MarkT could use tighter
text.  For example here is a portion of text provided to us to add.

	"6RD-5: The CE router MUST associate delegated prefixes with the
WAN

	interface(s)"

	The CPE WAN interface can be unnumbered with only an IPv6
link-local address and thus the CPE WAN does not have a global IPv6
address.  In such an unnumbered model, the CPE uses an address from the
PD on a virtual network interface to source packets out the WAN such as
ICMPv6 errors.  I am away from work tomorrow but we can certainly try
and close any text two days from now including any WebEx phone call
between Mark and us authors of rfc6204bis. 

I suspect that you misunderstand Mark's text, which says that the text
he suggested was inadequate. 

RFC 3704, resolving a number of pages into a single sentence, recommends
that if a packet uses a stated source address and that source address
was derived from a stated upstream network, the packet should be
directed to said upstream network. The reason it would do so is that the
upstream networks presumably implement BCP 38, meaning that if it is
directed to a different upstream network it is likely to be dropped.
3704 goes on to make suggestions regarding the implementation of exit
routing. What Mark is driving at is "implement exit routing; if one is
given multiple prefixes on different interfaces, physical or virtual,
associate each such prefix with its source interface in routing for the
purposes of source-address directed exit routing."

Explanations and dialog such as this are the reason I am asking you to
TALK WITH MARK about issues you see rather than talking with the chairs
or simply presuming that the working group outcome in Paris is
brain-dead. The outcome was, as near as I could tell, very sensible to
the operators.

	Another example for tighter text is related to 6RD-4.  Why does
6RD-4 only say "during an incremental migration period from 6rd to
native IPv6."    The SP could encounter a problem moving from 6rd to
native IPv6 and may want to revert back to 6rd.  Thus the 6RD-4 bullet
should cater to any migration from 6rd to native IPv6 or vice versa.

	Further, when the CPE has different prefixes being used by
native IPV6 and 6rd, a host behind the CPE router has concurrent IPv6
addresses being used (one IPv6 address from native IPv6 and another from
the 6rd prefix).  So what source-address does the host pick to send a
packet to a destination that is totally disjoint with the two prefixes
assigned to the CPE router?  Let's say the host picked a source address
from the 6rd prefix, then the CPE router ships the packet out the 6rd
tunnel instead of the higher preferred native IPv6 network.  So how is
the native IPv6 preference enforced by the CPE router?  

	Hemant

	-----Original Message-----

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Fred Baker (fred)

	To: IPv6 Operations

	We discussed this at IETF 83, and you will find it in the
minutes when they come out. Mark and Ole asked for two things
(statements regarding 6rd and ds-lite), and the working group agreed to
one of them. We are not discussing a "boiling of the ocean", nor are we
discussing an infinite succession of new requirements. We are discussing
getting three no-brainer-class statements into the draft in a manner
that the discussants all recognize and agree to. The three statements
were clarified by hum in the meeting, and were each able to be stated in
a single sentence.

	I would ask the different actors in this discussion to please
behave in a courteous manner toward each other, and work together on
this as requested by the chairs at IETF 83.

	v6ops mailing list

	[email-masked]

---

From: Mark Townsley <[email-masked]>
Date: Thu, 26 Apr 2012 22:16:46 +0200

On Apr 26, 2012, at 9:40 PM, Hemant Singh (shemant) wrote:

> I did like the context of 6rd sunsetting with the original 6RD-4 because if we do not provide context, folks may ask to the mailer 6 months or two years from now as to why two concurrent tech?
>  
> 6RD-4: A CE router MUST allow 6rd virtual and IPv6 native WAN interfaces to be active simultaneously such as when the CPE router is sunsetting 6rd or reverting the 6rd sunsetting.

OK, I had removed that text only since you had complained about the text not being "tight" enough before. 

I'd rather not use "sunsetting" once, much less twice, in the same sentence though. I'd like to avoid the term altogether in any sort of normative text. How about this?

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. 

>  
> Tweaked 6RD-5 a little.
>  
> 6RD-5: Each packet sent out the WAN interface via a 6rd or native IPv6 interface MUST be directed such that its source IPv6 address is derived from the delegated prefix associated with the egress interface. [section 4.3 of BCP 84, RFC 3704].

This tweak is inconsistent with the rest of the requirements though. For starters, it says "_the_ WAN interface" and "_the_ egress interface" when clearly there may be more than one WAN (or is it "egress" now?) interface active. 

If you look back to how Fred paraphrased RFC 3704 in his email on this thread, you'll find that the 6RD-5 I proposed is highly influenced by what he wrote. Let's not mess with it.

- Mark

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 26 Apr 2012 15:33:15 -0500

From: Mark Townsley [mailto:[email-masked]] 
Sent: Thursday, April 26, 2012 4:17 PM
To: Hemant Singh (shemant)
Cc: IPv6 Operations; Chris Donley
Subject: Re: [v6ops] 6rd sunsetting requirements (version 2)

>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-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 or vice versa.

Hemant

---

From: Gert Doering <[email-masked]>
Date: Fri, 27 Apr 2012 13:54:55 +0200

Hi,

+1

> 6RD-5: Each packet sent on a 6rd or native WAN interface MUST be directed such that its source IP address is derived from the delegated prefix associated with the upstream network the WAN interface…

I'm a bit unhappy with the wording, but support the idea.  Maybe change the
"the WAN interface is connected to" bit to "the corresponding interface is
connected to" - to make clear that this does applies to 6rd as well.

+1

(Maybe change the wording to "... in the event forwarding rules would result 
in equal preference for 6rd and native interface" - less words, and hopefully
more clear)

> Summary: The first requirement says 6rd and native must coexist, the second ensures that packets are directed such that they are not dropped by the upstream network, and the third ensures native is…

what he said :)

Gert Doering
        -- operator, fighting with existing CPE devices right now
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Gert Doering <[email-masked]>
Date: Fri, 27 Apr 2012 14:28:09 +0200

Hi,

On Wed, Apr 25, 2012 at 10:14:43PM +0200, Rémi Després wrote:
> If, in my explanation above, there is a reference to tools that
> assign public IPv4 addresses across IPv6-only networks, it is only
> because at least one such tool is needed for an ISP to eliminate
> 6rd (and the IPv4-only network that goes with it) without waiting
> for customers to no longer need their IPv4 addresses.

I can't see why "sunsetting 6rd" has to be tied in any way to "turning off
IPv4".  The ISP might just want to migrate to native dual-stack to get
rid of the tunneling overhead, get rid of the 6rd relay boxes, or for
a myriard of other reasons - and the focus of Mark's new bullets is
on "make sure that moving from 6rd to native IPv6 is going smoothly".

This is not related to sunsetting IPv4 (and/or moving to ds-lite or 4rd) 
- it might be done at the same time, or not.

Gert Doering
        -- Operator

---

From: Rémi Després <[email-masked]>
Date: Fri, 27 Apr 2012 15:03:55 +0200

> on "make sure that moving from 6rd to native IPv6 is going smoothly".

Right.

My comment was indeed about *a particular* 6rd sunsetting, that which goes from IPv4-only routing to IPv6-routing routing. (This was implicitly referring to the goal to progress toward less and less IPv4 functions, provided user experience isn't impacted.)

> - it might be done at the same time, or not.

Actually, all realistic plans from 6rd to IPv6-only routing I can imagine do include a phase where DS routing is needed. This is one more reason to agree with your remark. 
Thanks for the clarification.

Note that my suggestion concerning the draft was to just mention that 6rd sunsetting is likely to lead to additional constraints, thus avoiding to  specify these constraints without better knowledge of what is actually needed. 
I don't plan to insist on this if the WG thinks differently.

Regards,
RD

---

From: Gert Doering <[email-masked]>
Date: Fri, 27 Apr 2012 16:41:39 +0200

Hi,

On Wed, Apr 25, 2012 at 08:16:01PM -0500, Hemant Singh (shemant) wrote:
> A user is involved in a VoIP call from the user's PC behind a CPE
> router using 6rd.   Midway through the call, the other end of the
> phone call switches to native IPv6.   The phone call breaks down.

Why would anyone do that?  This is not "6rd sunsetting", this is just
"broken voip setup".

> How can an SP really deploy VoIP phone service with such a stateless
> protocol?

The point is not how a specific service on top of IPv6 is deployed, but
how the IPv6 connectivity *itself* is migrated from technology A to 
technology B without a hard cut-off "break all existing sessions, force
users to reload their routers and re-establish the link to their ISP".

Being able to run 6rd and native in parallel for a while establishes
just that:

  - start with 6rd
  - add native
  - move services from 6rd to native (like your voip service) - of course
    this would not be done "in the middle of the call" but for example at
    the next time the client sends a SIP REGISTER, or at the next time
    a call is setup
  - when all services have cut over, depreciate 6rd
  - turn off 6rd
  - end with native

this is really very obvious from an operator perspective.

Gert Doering
        -- Operator

---

From: Sander Steffann <[email-masked]>
Date: Fri, 27 Apr 2012 19:02:36 +0400

Hi,

> 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 or vice versa.

I can't really see anyone who has a native IPv6 network migrate to 6rd, but that might be a limit of my imagination :-)

- Sander

---

From: Gert Doering <[email-masked]>
Date: Fri, 27 Apr 2012 17:25:24 +0200

Hi,

> sunset 6rd to native IPv6 or vice versa between the SP and the CPE

I don't think you need a RFC for that (and there isn't).  This is just
normal ISP operations.

The point is that this should not lead to avoidable outages on the client
side - and with some operational and implementational experience, one can
easily foresee problem spots with multiple active interfaces plus BCP38.

... and with some forethought, one can give advice to implementors how
to avoid these problem spots before they hit.

Gert Doering
        -- Operator

---

From: Randy Bush <[email-masked]>
Date: Fri, 27 Apr 2012 08:58:37 -0700

>> interfaces to be active simultaneously in order to support
>> coexistence of the two technologies during an incremental migration
>> period from 6rd to native IPv6 or vice versa.
> I can't really see anyone who has a native IPv6 network migrate to
> 6rd, but that might be a limit of my imagination :-)

didn't you know that corner cases allow us to complicate things, which
makes us more famous and gets more brownie points?

Mark Townsley wrote:
> interfaces to be active simultaneously.
> 

wfm

randy

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 27 Apr 2012 16:37:38 +0000

> didn't you know that corner cases allow us to complicate things, which makes
> us more famous and gets more brownie points?

It's been suggested that a provider might find themselves needing to back out of a migration from 6rd to native IPv6, if the native deployment starts running into problems. In effect, this would look like a migration from native IPv6 (back) to 6rd.
Barbara

---

From: Randy Bush <[email-masked]>
Date: Fri, 27 Apr 2012 10:28:17 -0700

> It's been suggested that a provider might find themselves needing to
> back out of a migration from 6rd to native IPv6, if the native
> deployment starts running into problems. In effect, this would look
> like a migration from native IPv6 (back) to 6rd.

we should also think about migration to decnet-2

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 27 Apr 2012 10:38:02 -0700

> we should also think about migration to decnet-2

sorry, my terseness came out a bit more rude than intended

my point, meant generally, not just for this particular issue, is that
we should design for the simple, common, clearly 'must have' cases.
designing for corner cases gets us way too much complexity.  we are very
good at saying "what if cosmic rays strike" and not good at saying
"damned unlikely, forget it."

randy

---

From: Mark Townsley <[email-masked]>
Date: Mon, 30 Apr 2012 23:28:54 +0200

> It's been suggested that a provider might find themselves needing to back out of a migration from 6rd to native IPv6, if the native deployment starts running into problems. In effect, this would lo…

The nifty thing is that by making the 6rd and native interfaces operate independently as we do here, you could do this in reverse and it would "just work". The CPE operates as a slave to whatever the ISP wants to send configuration for, in whatever timeline and order it likes. 

- Mark

---

From: Hans Liu <[email-masked]>
Date: Tue, 1 May 2012 06:27:47 +0800

It looks like a lot of discussions were going on last week during my absence.
I'm good with the idea in general while I believe Mark and Chris are
working on the text.
If a operator chooses to provision both 6rd and native IPv6, a CE
router needs to have the capability to support them simultaneously. In
terms, CPE has the capability while operators have the privilege
whether they would like to do that in their networks. And I will
implement the requirements in boxes of my company.

Cheers,
Hans

and I will have it implemented in products of my company.

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