Subject: Re: [v6ops] 6rd sunsetting requirements (version 3)

From: Mark Townsley <[email-masked]>
Date: Thu, 3 May 2012 08:17:51 +0200

Thanks everyone for the comments. 

After some additional word-smithing offline between Chris, Hemant, Wes, and I, the four of us are _finally_ in agreement on the following text. I think we'd all like to put this one to rest now, and at least as far as the four of us are concerned, we can if this is what goes into the next rev of the document. 

6RD-4:  A CE router MUST allow 6rd and native IPv6 WAN interfaces to be active alone as well as simultaneously in order to support coexistence of the two technologies during an incremental migration period 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 [RFC3704]].

6RD-6: The CE router MUST allow different as well as identical delegated prefixes to be configured via each (6rd or native) 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.

Thank you,

- Mark

On May 1, 2012, at 12:27 AM, Hans Liu wrote:

> 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.
> 
> On Tue, May 1, 2012 at 5:28 AM, Mark Townsley <[email-masked]> wrote:
>> 
>> On Apr 27, 2012, at 6:37 PM, STARK, BARBARA H wrote:
>> 
>>>>>> 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 :-)
>>>> 
>>>> 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.
>> 
>> 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
>> 
>>> Barbara
>>> _______________________________________________
>>> v6ops mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>> 
>> _______________________________________________
>> v6ops mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> 
> -- 
> Instead of following the fashion, we lead it through.

---

From: Gert Doering <[email-masked]>
Date: Thu, 3 May 2012 08:50:46 +0200

Hi,

> 6RD-4:  A CE router MUST allow 6rd and native IPv6 WAN interfaces to be active alone as well as simultaneously in order to support coexistence of the two technologies during an incremental migratio…

ACK.

> 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 interfac…

I still disagree with the wording "the WAN interface is connected to" - in
the first half of the sentence, you have "the 6rd" and "the WAN" interface,
while the second half only talks about "the WAN".  So which addresses is
the 6rd interface to forward?  Why is the 6rd interface tied to
"the upstream network the WAN interface is connected to"?

My suggestion:

"... the delegated prefix associated with this particular interface 
[Section 4.3 [RFC3704]]".

shorter, not tied to "WAN", and the reference to "upstream network" is
not needed anyway.

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

ACK.

Gert Doering
        -- NetMaster
-- 
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: Ole Trøan <[email-masked]>
Date: Thu, 3 May 2012 09:15:14 +0200

Mark, et, al,

[...]

> 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 a few nitpicks with the language above. e.g. the use of "derived". I'll send those privately. generally I'm OK with the above.

I think adding these paragraphs in the section introduction, would set the context for these
requirements better:
 
   A multihomed, multiprefix, IPv6 CE router has multiple WAN interfaces
   connecting it to one or more Service Providers.  The interfaces may
   be "real" or "virtual" in the case of tunneling technology such as
   6rd [RFC5969].  The CE router receives one or more delegated
   prefixes, each associated with one or more WAN interfaces.

   WAN interfaces are used to send Ingress traffic from the Internet to
   the End-User, and Egress traffic from the End-User network to the
   Internet.  Ingress traffic may be received on any active interface at
   any time.  Egress traffic follows a set of rules within the CE in
   order to choose the proper WAN interface.  This is important not only
   in order to choose the best path, but also because the networks that
   the CE are connected to typically employ source address verification
   mechanisms.

   Packets arriving at the CE have an IPv6 source address chosen by the
   host [RFC3484]. The CE router performs source address dependent routing (SAD),
   such that the egress WAN interface is chosen based on the packet's source
   address matching the delegated prefix associate with the egress WAN
   interface.

cheers,
Ole

---

From: Gert Doering <[email-masked]>
Date: Thu, 3 May 2012 09:19:56 +0200

Hi,

>    address matching the delegated prefix associate with the egress WAN

+1 :-)

(Given that the first paragraph considers all "outside" interfaces to be
"WAN interfaces", and doesn't differenciate between "the 6rd" and "the WAN"
interface, generic usage of "WAN interface" in the following text is 
perfectly fine with me).

Gert Doering
        -- NetMaster

---

From: Mark Townsley <[email-masked]>
Date: Thu, 3 May 2012 09:41:18 +0200

> interface, generic usage of "WAN interface" in the following text is 

Yes, 6rd, native, and any other data link that can carry IPv6 packet to/from an ISP is a "WAN Interface" in the context of the requirements.

I agree that the above descriptive text would be helpful to the reader/implementor. 

- Mark

---

From: Ray Hunter <[email-masked]>
Date: Thu, 03 May 2012 11:03:36 +0200

Sorry. 6204bis is in danger of rat-holing. 6204bis is not multihomed IMHO.

Section 3.2. "The end-user network is a stub network"

Section 2 states "The IPv6 CE router connects the end-user network to a 
[singular] service provider network."

Section 2 also talks about "WAN Interface             an IPv6 CE 
router's attachment to a [singular] link "

Section 3.2 the document also talks about "Provisioning of the 
[singular] WAN interface connecting to the [singular] service provider"

W1 "When the router is attached to the [singular] WAN interface link"

If we're going to get picky about one or more WAN interfaces on the CPE 
router, one or more active links per WAN interface, or one or more 
service provider networks per router, there's plenty more places that 
need to be changed in the text if we want to be entirely consistent.

regards,
RayH

---

From: Ole Trøan <[email-masked]>
Date: Thu, 3 May 2012 11:13:11 +0200

> Sorry. 6204bis is in danger of rat-holing. 6204bis is not multihomed IMHO.

been ratholed for a long time. ;-)

the introduction of transition mechanisms implies multi-homing. we went over this in Paris.
I just don't see a way around that.

cheers,
Ole

> Section 2 states "The IPv6 CE router connects the end-user network to a [singular] service provider network."
> 
> Section 2 also talks about "WAN Interface             an IPv6 CE router's attachment to a [singular] link "
> 
> Section 3.2 the document also talks about "Provisioning of the [singular] WAN interface connecting to the [singular] service provider"
> 
> If we're going to get picky about one or more WAN interfaces on the CPE router, one or more active links per WAN interface, or one or more service provider networks per router, there's plenty more places that need to be changed in the text if we want to be entirely consistent.
> 
> regards,
> RayH
> 
> 
> Ole Trøan wrote:
>> Mark, et, al,
>> 
>> [...]
>>

---

From: [email-masked]
Date: Thu, 3 May 2012 10:22:44 -0400

> been ratholed for a long time. ;-)
A very deep hole indeed. My apologies for adding depth to it, below. 

> the introduction of transition mechanisms implies multi-homing. we went 
over this in Paris.

I wasn't in Paris, so I might be missing something here (I did read 
slides-83-v6ops-13), but allow me to disagree partially with your 
statement above. 

Transition mechanisms only imply multihoming if both native and transition 
are 
run in parallel for a given address family (as stated in your 
presentation). 
Running them in parallel is only desirable if the same prefix has to be 
used 
internally (this is 6RD sunsetting requirement #2, page 4 of the slides). 
What is the applicability of that requirement? 

In my humble opinion as an operator running both 6RD and native IPv6, it's 

perfectly fine to toggle between native IPv6 and 6RD without having both 
enabled at the same time. Ever. Yes, this means the delegated prefix will 
change, but I am perfectly fine with this and I suspect many operators 
will 
be too. How many operators who will sunset 6RD one day will really in a 
position to 1) keep the same prefix and 2) really need the prefix to 
remain 
the same at all cost? I suspect 1) is a fairly small number and 2) is an 
even 
smaller subset (equal to 1?). 

6RD sunsetting can be done automatically easily and cheaply. Send option 
212 
in DHCPv4 and if DHCPv6 fails, start 6RD after DHCPv4 has completed. Call 
this 
"poor-man's 6RD sunsetting", but it works and is probably in line 
with most operators needs. 

I agree with Barbara here, what we need is working IPv6 implementations 
that 
include 6RD. Adding any kind of multihoming requirement such as 6RD-[4-7] 
is 
counterproductive to timely and widespread implementations of 6204bis in 
home 
routeurs. It took years of work to get DHCPv6-PD implementations right, 
adding 
multihoming will likely add more years to that. 

I understand this comment comes late in an argument that seems alredy 
lost, but 
I felt it needed to be said. As Barbara pointed out, we haven't seen the 
6RD sunsetting requirements being discussed on the list. IMHO any form 
of multihoming, including 6RD sunsetting, shouldn't be in 6204bis at all. 
This was agreed initially when work on 'bis' began and the current text 
still reflects it (Ray just pointed it out). 

JF Tremblay
</operator hat>

---

From: Ole Trøan <[email-masked]>
Date: Thu, 3 May 2012 16:52:10 +0200

> 6RD sunsetting can be done automatically easily and cheaply. Send option 212 
> in DHCPv4 and if DHCPv6 fails, start 6RD after DHCPv4 has completed. Call this 
> [VK] Agree. This is the way I want my vendors to do it (and what I will demand).  Only do 6RD if IPv6 fails (if I can figure out how to only offer Option 212 when desired – is even better, but may not be possible).  I have no production need to have everything turned on and run complex code to sort out the details.  At this point, my opinion remains the same.  Keep it simple.  The small delay in activation is well worth the operational benefits of simpler code and more deterministic behaviours (IMHO).

yes, you _can_ do it this way.
iff we were to do this, someone would have to describe what the time-outs are going to be, and how a CPE should behave when this is 'changed on the fly'. the same thing has to be described in reverse for the DS-lite case. basically 6rd has to wait for IPv4 to be provisioned, and IPv4 has to wait for IPv6 to be provisioned (to determine if it should do DS-lite for IPv4 or not). I claim this is more complicated than simply specifying how they can operate independently of each other.

cheers,
Ole

---

From: Victor Kuarsingh <[email-masked]>
Date: Thu, 03 May 2012 10:47:34 -0400

From:  <[email-masked]> wrote:

Transition mechanisms only imply multihoming if both native and transition
are 
run in parallel for a given address family (as stated in your presentation).
Running them in parallel is only desirable if the same prefix has to be used
internally (this is 6RD sunsetting requirement #2, page 4 of the slides).
What is the applicability of that requirement?

[VK] We do not plan on running them in parallel

In my humble opinion as an operator running both 6RD and native IPv6, it's
perfectly fine to toggle between native IPv6 and 6RD without having both
enabled at the same time. Ever. Yes, this means the delegated prefix will
change, but I am perfectly fine with this and I suspect many operators will
be too. How many operators who will sunset 6RD one day will really in a
position to 1) keep the same prefix and 2) really need the prefix to remain
the same at all cost? I suspect 1) is a fairly small number and 2) is an
even 
smaller subset (equal to 1?).

[VK] Toggle, yes, both active simultaneously? - No.  One or the other seems
the most operationally sound.  I don't have IETFers troubleshooting
connectivity issues for the millions of endpoints in the network, so complex
flow patterns will likely result in long and complex troubleshooting (which
is the worst thing for my IPv6 deployment).

[VK] Agree. This is the way I want my vendors to do it (and what I will
demand).  Only do 6RD if IPv6 fails (if I can figure out how to only offer
Option 212 when desired  is even better, but may not be possible).  I have
no production need to have everything turned on and run complex code to sort
out the details.  At this point, my opinion remains the same.  Keep it
simple.  The small delay in activation is well worth the operational
benefits of simpler code and more deterministic behaviours (IMHO).

I agree with Barbara here, what we need is working IPv6 implementations that
include 6RD. Adding any kind of multihoming requirement such as 6RD-[4-7] is
counterproductive to timely and widespread implementations of 6204bis in
home 
routeurs. It took years of work to get DHCPv6-PD implementations right,
adding 
multihoming will likely add more years to that.

[VK] Agree. My biggest issue is basic code not running well in production.
Having solid IPv6 is mission #1.

All these points were the ones I made at the MIC in paris.

Also, Operator Hat.

Regards,

Victor

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

---

From: Simon Perreault <[email-masked]>
Date: Thu, 03 May 2012 11:04:09 -0400

On 2012-05-03 10:47, Victor Kuarsingh wrote:
> Only do 6RD if IPv6 fails (if I can figure out how to only
> offer Option 212 when desired – is even better, but may not be
> possible).

Why not unconditionally ask for option 212 and only activate the 6RD 
interface after DHCPv6 fails?

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: [email-masked]
Date: Thu, 3 May 2012 11:18:13 -0400

> basically 6rd has to wait for IPv4 to be provisioned, and IPv4 has to 
wait 
> for IPv6 to be provisioned (to determine if it should do DS-lite for 
IPv4 or not). 
> I claim this is more complicated than simply specifying how they can 
operate 
> independently of each other.
> Ole

Agreed. But I claim the "alternate-on" approach, even given timers and a 
proper 
(small) state machine is less complex for an implementer to put together
than introducing multihoming at this point. I would love to hear from 
implementers such as Hans on this. 

Even on the long term, although the multi-homed approach seems great 
engineering idea for 6RD, I'm not sure the requirement of keeping 
the same IPv6 prefix needs to be there. It looks hardly feasible to keep 
the same prefix length between 6RD and native, as the first tends to be
much longer (smaller) in most deployments. It also ties together the IPv6 
and IPv4 topologies, which is not especially desirable in most networks. 
Again, feedback from those who consider 6RD sunset would be desirable. 

/JF

---

From: Mark Townsley <[email-masked]>
Date: Thu, 3 May 2012 17:40:00 +0200

And there is nothing stopping you from toggling your users with the model we have described.  

But, if you happen to be an operator with no ability to control your CPE, or to detect whether the CPE connected is has only 6rd or native (or if there is a local switch on the CPE, what position it is in), there is a problem.  

What we don't want to develop is something that will work on one network when set in one mode, and another network only when set in another mode. We don't want to care what network we are connected to. We want to let the ISP send whatever configuration it wants, in whatever order it wants, and we'll make it work rather than trying to guess what you are trying to do -- or, force our home-user customers to step through some manual configuration process… "Check with your Operator to see if they are a 6rd or Native IPv6 operator and set this value accordingly" 

The "Poor man's 6rd sunsetting" you refer to is what I called "forced single-homing" in the presentation. This is begging for a race-condition issue to crop up, ties together the v4 and v6 state machines, and eliminates the ability to transition a user without renumbering. 

- Mark

On May 3, 2012, at 4:22 PM, [email-masked] wrote:

> Transition mechanisms only imply multihoming if both native and transition are 
> the same at all cost? I suspect 1) is a fairly small number and 2) is an even 
> counterproductive to timely and widespread implementations of 6204bis in home 
> routeurs. It took years of work to get DHCPv6-PD implementations right, adding 
> I understand this comment comes late in an argument that seems alredy lost, but

---

From: Mark Townsley <[email-masked]>
Date: Thu, 3 May 2012 17:43:33 +0200

On May 3, 2012, at 5:18 PM, [email-masked] wrote:

> 
> > basically 6rd has to wait for IPv4 to be provisioned, and IPv4 has to wait 
> > for IPv6 to be provisioned (to determine if it should do DS-lite for IPv4 or not). 
> > I claim this is more complicated than simply specifying how they can operate 
> Agreed. But I claim the "alternate-on" approach, even given timers and a proper 

Begin forwarded message:

> From: Hans Liu <[email-masked]>
> Subject: Re: [v6ops] 6rd sunsetting requirements (version 2)
> Date: May 1, 2012 12:27:47 AM GMT+02:00
> To: Mark Townsley <[email-masked]>
> Cc: IPv6 Operations <[email-masked]>, Claire Cheng <[email-masked]>
>

---

From: [email-masked]
Date: Thu, 3 May 2012 12:09:51 -0400

Hi Mark. 

> And there is nothing stopping you from toggling your users with the 
model we have described. 

Agreed, but this is not my point. My point is that introducing multihoming 
in 'bis' 
based on 6RD sunsetting requirements is very likely to slow down 
implementers. Whether 
this slowdown is tangible or not remains to be confirmed, but a non-empty 
group 
of concerned operators definitely exists here. 

> But, if you happen to be an operator with no ability to control your 
CPE, or to detect 
> whether the CPE connected is has only 6rd or native (or if there is a 
local switch 
> on the CPE, what position it is in), there is a problem. 

Would you be kind enough to point a scenario where this is any more 
dangerous than 
having the user choosing "6RD" statically from a drop-down menu? This is 
what we 
have now and there are certainly home users who stick to 6RD even if 
native is 
available because they're not aware it's there. This is why 'bis' has to 
be published ASAP with requirements that can be met on a short timeframe. 

> What we don't want to develop is something that will work on one network 
when 
> set in one mode, and another network only when set in another mode. 
Agreed. 

> We don't 
> want to care what network we are connected to. We want to let the ISP 
send 
> whatever configuration it wants, in whatever order it wants, and we'll 
> make it work rather than trying to guess what you are trying to do -- 
> or, force our home-user customers to step through some manual 
configuration 
> process… "Check with your Operator to see if they are a 6rd or 
> Native IPv6 operator and set this value accordingly" 
Agreed. 

> The "Poor man's 6rd sunsetting" you refer to is what I called 
> "forced single-homing" in the presentation. This is begging for a 
race-condition 
> issue to crop up, ties together the v4 and v6 state machines, and 
eliminates 
> the ability to transition a user without renumbering. 

I understand your point, but again, I believe this state machine can be 
made 
so simple that I simply don't foresee a scenario where it could fail. And 
yes you can quote me for proposing an idea that I believe we can 
engineered to be "too simple to fail". 

I'm looking forward to hear scenarios where this would lead to a 
significant failure. 
If these scenarios do exist and have a significant chance of happening 
in a correctly configured network, then the "simple-sunset" idea should be 
retracted, I agree. 

/JF

---

From: "Weil, Jason" <[email-masked]>
Date: Thu, 3 May 2012 12:25:34 -0400

How does source address verification come into play in this picture? For
those brave enough to try this, my understanding of the use case is to
offer 6rd and native IPv6 on the same WAN interface terminating at the
same edge router. You will have both the native IPv6 prefix and the IPv4
prefix for the 6rd tunnel configured on the edge router's interface. I am
not seeing how you would trigger any source verification drops in this
scenario.

I also believe the use of multihoming in this text is way too liberal for
this section.

Multihoming to a single edge router != Multihoming to 2 edge routers !=
Multihoming to two providers. We need to be more specific in our
multihoming definitions.

On 5/3/12 3:15 AM, "Ole Trøan" <[email-masked]> wrote:

>Mark, et, al,
>
>[...]
>
>> 6RD-4:  A CE router MUST allow 6rd and native IPv6 WAN interfaces to be
>>active alone as well as simultaneously in order to support coexistence
>>of the two technologies during an incremental migration period 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 [RFC3704]].
>>
>> 6RD-6: The CE router MUST allow different as well as identical
>>delegated prefixes to be configured via each (6rd or native) 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.
>
>I have a few nitpicks with the language above. e.g. the use of "derived".
>I'll send those privately. generally I'm OK with the above.
>

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

---

From: [email-masked]
Date: Thu, 3 May 2012 12:30:00 -0400

Mark, 
Hans stated that multihoming is possible and he'll be willing 
to do it if there's a strong requirement from his client. Not that 
it's easy or feasible within a reasonable timeframe. 

And we definitely have some history when it comes to IPv6 implementations 
timeframes: 
http://www.videotron.com/service/internet-services/internet-access/wifi-router
Features: 
    IPv6-compatible

John B. and others people on this list who work actively on deploying IPv6 
also 
have their stories. It all boils down to the fact complexity costs 
deployment time. 
By keeping complexity down, we can hope to have better IPv6 in home 
routers within 
a reasonable timeframe. Multihoming in 'bis' is undue complexity IMHO. 

/JF

wait 
IPv4 or not). 
operate 

Begin forwarded message:

From: Hans Liu <[email-masked]>
Subject: Re: [v6ops] 6rd sunsetting requirements (version 2)
Date: May 1, 2012 12:27:47 AM GMT+02:00
To: Mark Townsley <[email-masked]>
Cc: IPv6 Operations <[email-masked]>, Claire Cheng <
[email-masked]>

It looks like a lot of discussions were going on last week during my 
absence.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 3 May 2012 16:47:52 +0000

> interface after DHCPv6 fails?

Not all 6rd will be configured via option 212. On PPPoE, we're configuring our routers through TR-069, and have requested retail CE routers that do PPPoE and 6rd support manual entry of 6rd config parameters (6204bis 6RD-2).

But as I've said, we have no problem toggling native IPv6 and 6rd in our TR-069 managed routers, and have no objection to having the user manually toggle in CE routers where they have manually configured 6rd. So I'm not opposed to the sentiment expressed, I would just want to be careful to make sure that we appropriately define behavior for devices not configured through option 212.
Barbara

---

From: Simon Perreault <[email-masked]>
Date: Thu, 03 May 2012 12:54:16 -0400

> Not all 6rd will be configured via option 212. On PPPoE, we're configuring our routers through TR-069, and have requested retail CE routers that do PPPoE and 6rd support manual entry of 6rd config…

Right. Then the algorithm becomes something like this:

1. If the CPE has no 6rd config (either static config or from TR-69) 
then do a DHCPv4 request with option 212.

2. Do a DHCPv6 request.

3. If the DHCPv6 request fails, wait until we have 6rd config, then 
bring up the 6rd interface.

> But as I've said, we have no problem toggling native IPv6 and 6rd in our TR-069 managed routers, and have no objection to having the user manually toggle in CE routers where they have manually conf…

Absolutely. And TR-69 will be used alongside option 212 in some 
deployments too.

Simon

---

From: Gert Doering <[email-masked]>
Date: Thu, 3 May 2012 19:29:37 +0200

Hi,

> not seeing how you would trigger any source verification drops in this

This has been explained a number of times on this list.

Typically, the 6rd and the "regular" ISP PE router are not the same box,
and the "regular" PE router does not know anything about the 6rd addresses
on the client.

BCP38 strongly recommends to do source address verification - this is 
typically implemented similar to Cisco's "uRPF", as in "the PE router
will accept packets with a source address only if it would route that
source address to *this* customer".

Since the "WAN" PE doesn't *know* about the 6rd prefix at this customer
site, it will automatically drop all packets sourced from 6rd-derived
addresses if those arrive on the "regular WAN" link.

(Someone stated that we're ratholing.  And indeed we are, if questions
are asked again that have been answered and discused quite in depth 
months ago already.  And where those answers are really obvious to
anyone who bothered to fully think through an ISP deployment with 6rd
and native IPv6, and BCP38 deployed).

> Multihoming to two providers. We need to be more specific in our

The specific style of multihoming is fully irrelevant to the text bits
proposed by Mark and Ole (and applies to all of them).  This is not about
defining multihoming, but about a few specific caveats that will show
up as soon as you have more than one "WAN-style" interface.

Gert Doering
        -- Operator

---

From: "Weil, Jason" <[email-masked]>
Date: Thu, 3 May 2012 17:04:12 -0400

I guess I need to 2nd Ray's comment. What you are describing now (and
apparently I have filtered due to complexity filter) is a variant of the
Two ISP, One CER topology from the Homene-archictecture draft but what the
current draft bis describes is a single Service Provider router topology.
I fail to see how this falls in scope of the current draft and seems more
in-line with Homenet problem statements.

3.1.3
<http://tools.ietf.org/html/draft-ietf-homenet-arch-02#section-3.1.3>.  C:
Two ISPs, One CER, Shared subnet

           +-------+-------+     +-------+-------+         \
           |   Service     |     |   Service     |          \
           |  Provider A   |     |  Provider B   |           | Service
           |    Router     |     |    Router     |           | Provider
           +-------+-------+     +-------+-------+           | network
                    |                 |                     /
                    |    Customer     |                   /
                    |    Internet     |                  /
                    |   connections   |                 |
                   +---------+---------+                 \
                   |       IPv6        |                   \
                   |   Customer Edge   |                    \
                   |      Router       |                    /
                   +---------+---------+                   /
                             |                            /
                             |                            | End-User
     ---+------------+-------+--------+-------------+---  | network(s)
        |            |                |             |      \
   +----+-----+ +----+-----+     +----+-----+ +-----+----+  \
   |IPv6 Host | |IPv6 Host |     | IPv6 Host| |IPv6 Host |  /
   |          | |          |     |          | |          | /
   +----------+ +----------+     +----------+ +----------+

What is in the 6204bis draft is this:
http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-08#section-3.2

   The end-user network is a stub network.  Figure 1 illustrates the
   model topology for the end-user network.

                     +-------+-------+                      \
                     |   Service     |                       \
                     |   Provider    |                        | Service
                     |    Router     |                        | Provider
                     +-------+-------+                        | network
                             |                               /
                             | Customer                     /
                             | Internet connection         /
                             |
                      +------+--------+                    \
                      |     IPv6      |                     \
                      | Customer Edge |                      \
                      |    Router     |                      /
                      +---+-------+-+-+                     /
          Network A       |       |   Network B            | End-User
    ---+-------------+----+-    --+--+-------------+---    | network(s)
       |             |               |             |        \
   +----+-----+ +-----+----+     +----+-----+ +-----+----+   \
   |IPv6 Host | |IPv6 Host |     | IPv6 Host| |IPv6 Host |   /
   |          | |          |     |          | |          |  /
   +----------+ +-----+----+     +----------+ +----------+ /

Jason

---

From: Mark Townsley <[email-masked]>
Date: Fri, 4 May 2012 00:34:25 +0200

On May 3, 2012, at 6:09 PM, [email-masked] wrote:

> Agreed, but this is not my point. My point is that introducing multihoming in 'bis' 
> based on 6RD sunsetting requirements is very likely to slow down implementers. Whether 
> this slowdown is tangible or not remains to be confirmed, but a non-empty group 

6rd began appearing in CPE with RFC 5969. It didn't need v6ops to become fairly widely deployed already, and CPE vendors have either implemented it, or made a conscious decision to not to, by now. I don't see how RFC-6204 bis is going to speed that up or slow it down. 6rd is not even a MUST in 6204-bis. 

What is new in 6204-bis is a set of Native IPv6 requirements (that are indeed MUSTs) and 6rd mentioned together. I think it is incumbent upon us to make sure that the two work well together, and put us on a path towards moving to native IPv6 with as few barriers as possible. Remove this, and the delta between the status quo and -bis gets pretty darn small. 

- Mark

> 
> > But, if you happen to be an operator with no ability to control your CPE, or to detect 
> > whether the CPE connected is has only 6rd or native (or if there is a local switch 
> Would you be kind enough to point a scenario where this is any more dangerous than 
> having the user choosing "6RD" statically from a drop-down menu? This is what we 
> have now and there are certainly home users who stick to 6RD even if native is 
> > What we don't want to develop is something that will work on one network when 
> > want to care what network we are connected to. We want to let the ISP send 
> > or, force our home-user customers to step through some manual configuration 
> > "forced single-homing" in the presentation. This is begging for a race-condition 
> > issue to crop up, ties together the v4 and v6 state machines, and eliminates 
> I understand your point, but again, I believe this state machine can be made 
> yes you can quote me for proposing an idea that I believe we can engineered to be "too simple to fail". 
> 
> I'm looking forward to hear scenarios where this would lead to a significant failure. 
> in a correctly configured network, then the "simple-sunset" idea should be retracted, I agree. 
> 
> /JF 
> 
> 
> 
> 
> 
> 
>

---

From: Mark Townsley <[email-masked]>
Date: Fri, 4 May 2012 00:48:02 +0200

On May 3, 2012, at 6:54 PM, Simon Perreault wrote:

> 1. If the CPE has no 6rd config (either static config or from TR-69) then do a DHCPv4 request with option 212.

Except TR-69 doesn't operate without IP, which means DHCPv4 (or is it DHCPv6?) goes first of course.

> 
> 2. Do a DHCPv6 request.
> 
> 3. If the DHCPv6 request fails, wait until we have 6rd config, then bring up the 6rd interface.

How long do you wait for DHCPv6 to fail before you bring up 6rd? 15 seconds? 30? A minute? Would my 6rd-provider like that v6 bringup is delayed by that long for *all* their users? 

Do we really want v6 to take a minute longer to come up than v4? I honestly had a power breaker flip just today (two, actually) - the DSL gateway came back pretty quickly, the VPN router took quite a bit longer.. .I was not at all happy with the VPN router.  

We've even had operators say on this list that they want to have the alternative to move from v6 back to 6rd, so perhaps the order of your state machine should be reversed? 

Bottom line: you probably are not going to agree on what to do here, and as a retail CPE vendor, I want to be sure that what comes out works with all operational cases, and without bugging the users for config (even if you tell me it is OK to have manual config for your customers, that's not OK for me as a CPE vendor). 

What Ole and I proposed, defended in Paris, and have been asked by the chairs to formulate simple requirements for, is the only option that hits *all* cases you can throw at the problem… and, it's really not as hard as it sounds to make happen. RFC 3704 has been around since 2004, let's not pretend it is rocket science today. 

- Mark

> Absolutely. And TR-69 will be used alongside option 212 in some deployments too.
> 
> Simon
> --

---

From: Mark Townsley <[email-masked]>
Date: Fri, 4 May 2012 00:54:24 +0200

> in-line with Homenet problem statements.

When we divided up the work between homenet and v6ops, v6ops kept the "WAN" side, hence why it lands here and now Homenet scope doesn't include, for example, 6rd, DS-Lite, etc. at all. Your observation that what we are proposing is in line with the homenet architecture is correct, and I'd hope that is considered a good thing. 

- Mark

---

From: Hans Liu <[email-masked]>
Date: Fri, 4 May 2012 08:57:03 +0800

I don't normally speak my implementation in public, but let's do it!  :P

My current "AutoDetection" implementation supports 6rd (DHCPv4 Option
212) and native IPv6 (Autoconfiguration). It doesn't take multihoming
into account but it is sort of taking care of the goal toward native
IPv6. It starts IPv4 and IPv6 provisioning in parallel, and I expects
that it ends up with a native dual stack.  If both 6rd and native IPv6
are provisioned, it will only bring up native IPv6.

The problem of it is above procedure only does once, when the device
boots up. And the question will be if a power cycle or reboot is ok to
everyone.  I made a quick survey when I first designed above flow. It
seems most people have pretty good sense (or are pretty well-educated)
to power cycle their device when it doesn't work well.  (I know I'm
one of the blame for)

For the sunset requirements we discussed here, I don't have much to
share since I don't yet start my development. I will develop it when
we have the final text, and I might be able to share more when I meet
a problem during my development.

Best regards,
Hans

---

From: Mark Townsley <[email-masked]>
Date: Fri, 4 May 2012 09:42:02 +0200

> I still disagree with the wording "the WAN interface is connected to" - in

Yes, I remember you mentioning that before but didn't manage to incorporate it. 

> [Section 4.3 [RFC3704]]".

So, something like:

6RD-5:  Each packet sent on a 6rd or native WAN interface MUST be directed such that the packet's source IP address is derived from a delegated prefix associated with the particular interface the packet is being sent on [Section 4.3 [RFC3704]].

I'm OK with that if you are.

- Mark

---

From: Ole Trøan <[email-masked]>
Date: Fri, 4 May 2012 11:40:07 +0200

Jason,

RFC6204 specifies an IPv6 CE router. it only considers IPv6. any IPv4 considerations where out of scope.

with the introduction of IPv4 in RFC6204bis, you at least are dual stacked multi-homed to the
same ISP:

              +------------+------------+                  \
              |        Service          |                   \
              |       Provider A        |                   | Service
              |         Router          |                   | Provider
              +------------+------------+                   | network
                   |                 |                     /
                   |    Customer     |                   /
              IPv6 |    Internet     | IPv4             /
                   |   connections   |                 |
                  +---------+---------+                 \
                  |       IPv6        |                   \
                  |   Customer Edge   |                    \
                  |      Router       |                    /
                  +---------+---------+                   /
                            |                            /
                            |                            | End-User
    ---+------------+-------+--------+-------------+---  | network(s)
       |            |                |             |      \
  +----+-----+ +----+-----+     +----+-----+ +-----+----+  \
  |IPv6 Host | |IPv6 Host |     | IPv6 Host| |IPv6 Host |  /
  |          | |          |     |          | |          | /
  +----------+ +----------+     +----------+ +----------+

with a mechanism for IPv4 sunsetting and a mechanism for IPv6 transition, you have 4 "WAN interfaces",
that have interdependencies between each other. this document is describing the behaviour of a retail router,
_without_ a management interface available to the ISP. (so can we please agree that "how this can be solved with TR-69" is irrelevant for this discussion?)

cheers,
Ole

---

From: Simon Perreault <[email-masked]>
Date: Fri, 04 May 2012 09:15:15 -0400

On 2012-05-03 18:48, Mark Townsley wrote:
>> 1. If the CPE has no 6rd config (either static config or from
>> TR-69) then do a DHCPv4 request with option 212.
>

Right, but that's not the important part. Let's not get distracted by
TR-69, it's not a hard problem to fix.

> How long do you wait for DHCPv6 to fail before you bring up 6rd? 15
> seconds? 30? A minute?

I'm sure we can suggest something reasonable. 10 seconds looks fine to 
me. If DHCPv6 succeeds later on (it could even be several days later, 
when e.g. the ISP turns on DHCPv6), you just turn off the 6rd interface.

> Would my 6rd-provider like that v6 bringup is
> delayed by that long for *all* their users?

It's acceptable. It only affects 6rd. IPv4 is still instantaneous. IPv6 
native is still instantaneous.

> Do we really want v6 to take a minute longer to come up than v4?

s/v6/6rd/

So far it looks like an acceptable trade-off vs simplicity.

> I honestly had a power breaker flip just today (two, actually) - the
> DSL gateway came back pretty quickly, the VPN router took quite a bit
> longer.. .I was not at all happy with the VPN router.

The vast majority of users don't care about 6rd and won't notice.

> We've even had operators say on this list that they want to have the
> alternative to move from v6 back to 6rd, so perhaps the order of your
> state machine should be reversed?

Sure.

DHCPv6 goes down --> activate 6rd
DHCPv6 goes up --> deactivate 6rd

> Bottom line: you probably are not going to agree on what to do here,
> and as a retail CPE vendor, I want to be sure that what comes out
> works with all operational cases, and without bugging the users for
> config (even if you tell me it is OK to have manual config for your
> customers, that's not OK for me as a CPE vendor).
>
> What Ole and I proposed, defended in Paris, and have been asked by
> the chairs to formulate simple requirements for, is the only option
> that hits *all* cases you can throw at the problem… and, it's really
> not as hard as it sounds to make happen. RFC 3704 has been around
> since 2004, let's not pretend it is rocket science today.

Brain surgery isn't rocket science either.

So far the "poor man's sunsetting" proposal seems very simple and I 
can't find holes in it.

Simon

---

From: Wuyts Carl <[email-masked]>
Date: Fri, 4 May 2012 15:27:02 +0200

I read:

""
""

Seems a recurring event to link different protocols to each other.  6rd, i.e. IPv4 with optional DHCPv4 has no real link with IPv6/DHCPv6, so please let's avoid (again) to link things to each other and ask from the CPE to bring A up when B goes down and/or vice versa.  No matter how long you will wait, you'll need some daemon to listen and push some action to the other protocol, or some eventing between the 2, while they in fact have nothing to do with each other, so should not be linked and only increases complexity.  Use the "normal" routing to enforce something, i.e. give better metric for one (native) vs the other or something, a simple mechanism where normal/standard routing decisions are in place do to their job, so just select the 'best route', but please don't link them up.  If both native v6 and 6rd routes are in place, the metric can be used to select the best route, if one of the 2 is not present it's no issue.  It should not be different from any other routing decision.
I've seen before similar suggestions (linking protocols up) to ask for option X if option Y or if Z is not set or ... is not answered and things like that, please avoid this.

Thx and regs
Carl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Perreault
Sent: vrijdag 4 mei 2012 15:15
To: Mark Townsley
Cc: [email-masked]
Subject: Re: [v6ops] 6rd sunsetting requirements (version 3)

> DHCPv6?) goes first of course.

Right, but that's not the important part. Let's not get distracted by TR-69, it's not a hard problem to fix.

> How long do you wait for DHCPv6 to fail before you bring up 6rd? 15 

I'm sure we can suggest something reasonable. 10 seconds looks fine to me. If DHCPv6 succeeds later on (it could even be several days later, when e.g. the ISP turns on DHCPv6), you just turn off the 6rd interface.

> Would my 6rd-provider like that v6 bringup is delayed by that long for 
> *all* their users?

It's acceptable. It only affects 6rd. IPv4 is still instantaneous. IPv6 native is still instantaneous.

s/v6/6rd/

Sure.

> What Ole and I proposed, defended in Paris, and have been asked by the 
> chairs to formulate simple requirements for, is the only option that 
> hits *all* cases you can throw at the problem... and, it's really not as 
> hard as it sounds to make happen. RFC 3704 has been around since 2004, 
> let's not pretend it is rocket science today.

So far the "poor man's sunsetting" proposal seems very simple and I can't find holes in it.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Fri, 04 May 2012 09:40:12 -0400

On 2012-05-04 09:27, Wuyts Carl wrote:
> Seems a recurring event to link different protocols to each other.  6rd, i.e. IPv4 with optional DHCPv4 has no real link with IPv6/DHCPv6, so please let's avoid (again) to link things to each other and ask from the CPE to bring A up when B goes down and/or vice versa.  No matter how long you will wait, you'll need some daemon to listen and push some action to the other protocol, or some eventing between the 2, while they in fact have nothing to do with each other, so should not be linked and only increases complexity.

The goal here is to actually *reduce* complexity. If you let DHCPv6 and 
6rd be up simultaneously, you end up having to do source-based routing.

> Use the "normal" routing to enforce something, i.e. give better metric for one (native) vs the other or something, a simple mechanism where normal/standard routing decisions are in place do to their job, so just select the 'best route', but please don't link them up.  If both native v6 and 6rd routes are in place, the metric can be used to select the best route, if one of the 2 is not present it's no issue.  It should not be different from any other routing decision.

This won't work because of the ISP's ingress filtering. You have to send 
packets to the interface where the ISP's routers doing RPF check will 
not drop them. So we're talking about source-based routing on the CPE. 
This has been discussed many times. It's the only reason we're having 
this discussion, otherwise your suggestion would have been adopted a 
long time ago. ;)

Simon

---

From: Tina TSOU <[email-masked]>
Date: Fri, 4 May 2012 15:39:15 +0000

Sent from my iPad

On May 4, 2012, at 6:40 AM, "Simon Perreault" <[email-masked]> wrote:

> The goal here is to actually *reduce* complexity. If you let DHCPv6 and 6rd be up simultaneously, you end up having to do source-based routing.
It is not pretty. But it seems the only way for efficiency.
> This won't work because of the ISP's ingress filtering. You have to send packets to the interface where the ISP's routers doing RPF check will not drop them. So we're talking about source-based routing on the CPE. This has been discussed many times. It's the only reason we're having this discussion, otherwise your suggestion would have been adopted a long time ago. ;)
> 
> Simon
> --

---

From: "Weil, Jason" <[email-masked]>
Date: Fri, 4 May 2012 14:10:14 -0400

So we are very close to a gray area in which you are trying to solve for
an arbitrary upstream topology based on lack of detail in the current
test. I have no doubt the solution is doable given enough iterations and a
year or two of trial and error in the field. All I am asking is we do our
best not to overly engineer the "best" solution for the minority use cases
that results in negative impact to the majority of use cases.

Thanks,

Jason

On 5/4/12 5:40 AM, "Ole Trøan" <[email-masked]> wrote:

>that have interdependencies between each other. this document is
>describing the behaviour of a retail router,
>_without_ a management interface available to the ISP. (so can we please
>agree that "how this can be solved with TR-69" is irrelevant for this
>discussion?)
>
>cheers,
>Ole

---

From: Ole Trøan <[email-masked]>
Date: Fri, 4 May 2012 20:26:24 +0200

Jason,

> that results in negative impact to the majority of use cases.

you claim complexity, complex for whom?

for ISPs, having CPEs work in a consistent with regards to 6rd/native IPv6 means they can transition from one to the other without a flag day. it is also simpler to provision as the CPE would do the right thing (tm) regardless of how it was provisioned.

for the end user, the CPE comes from the shop with the right defaults, being able to handle both native IPv6 and 6rd (we obviously need that for IPv4 sunset as well), with no need to reboot the CPE, or manually configure it, or call the ISP help desk.

for the CPE implementor, there is no need to create dependencies between IPv4 and IPv6 provisioning, but we need to implement SAD. sitting here looking at our PBR code right now... well, it isn't particularly hard.

cheers,
Ole

---

From: [email-masked]
Date: Fri, 4 May 2012 15:52:02 -0400

> All I am asking is we do our

+1 
Keeping the same prefix in 6RD sunset and therefore requiring multihoming 
seems to be the need of a very small minority. Let's not overengineer 
(is that even a verb?) solutions for the whole industry based on 
the need of very few. 

/JF

---

From: [email-masked]
Date: Fri, 4 May 2012 16:01:54 -0400

Ole, 
> for the CPE implementor, there is no need to create dependencies between 

> IPv4 and IPv6 provisioning, but we need to implement SAD. 

The claim here is that these 'dependancies' are significantly easier and 
faster 
to implement than SAD, altough the latter is probably more elegant on the 
long term. 
Time is the essence here. As Hans mentioned, this is already implemented, 
so we even have running code proving it works without significant impacts. 

> sitting here looking at our PBR code right now... well, it isn't 
particularly hard.

This is not the feedback I received from implementors. They claim this is 
a 
significant challenge and will impact the delivery of IPv6 features. 
I can't speak for them here, but this is actual feedback from the field, 
verified by experience in the past years. 

/JF

---

From: Ole Trøan <[email-masked]>
Date: Fri, 4 May 2012 22:08:35 +0200

JF,

> (is that even a verb?) solutions for the whole industry based on 

it isn't the "same prefix requirement" that is driving multi-homing.
what is driving it is that otherwise you'd require a "flag day" what Mark calls "forced single homing".

cheers,
Ole

---

From: Ole Trøan <[email-masked]>
Date: Fri, 4 May 2012 22:09:16 +0200

> This is not the feedback I received from implementors. They claim this is a 

could you ask those implementors to speak up themselves?

Ole

---

From: [email-masked]
Date: Fri, 4 May 2012 16:24:16 -0400

> could you ask those implementors to speak up themselves?

Of course I did. Publicly on this list for one of them.

/JF

---

From: Wuyts Carl <[email-masked]>
Date: Mon, 7 May 2012 08:00:20 +0200

So, the ISP has a problem with the ingress filtering, hence just add a few extra reqs to the CPE to "glue" some stuff together ?  Great! What's next ?
:-(

As CPE vendor, our customers are deploying the managed model, so potentially less issues compared to retail (as we have firmware upgrades, tr069, ...).  I was always told to not fix to hard on this model, but to take into account that this RFC must, for starters, apply on the retail ones.  Well, if you want something in short term (like everyone seems to want, although reality speaks against it) then I think you've to stop adding these kind of requirements as you're making your own rules, overruling protocol independency, ... just for the sake of getting things added.

Regs
Carl

-----Original Message-----
From: Tina TSOU [mailto:[email-masked]] 
Sent: vrijdag 4 mei 2012 17:39
To: Simon Perreault
Cc: Wuyts Carl; [email-masked]
Subject: Re: [v6ops] 6rd sunsetting requirements (version 3)

Sent from my iPad

---

From: Gert Doering <[email-masked]>
Date: Mon, 7 May 2012 11:38:34 +0200

Hi,

> So, the ISP has a problem with the ingress filtering, hence just add a few extra reqs to the CPE to "glue" some stuff together ?  Great! What's next ?

It's not "the ISP has a problem".

The ISP is a *good guy* and following BCP38 - and there is no easy way 
a large-scale ISP can configure their access gear to do exceptions for
"oh, that customer on a native link also has 6rd with *that* subnet,
so make an exception for those source packets".

This topic will come back anyway as soon as multi-ISP is considered -
this is out of scope for 6204bis, but you need to be handle it in the
CPEs anyway.  Even if you could make the ISP case work for 6rd + native
(which might be possible with some hackery, as the access router knows
the ipv4 address and could theoretically be taught to recognize the
corresponding 6rd address), there is no way ever you can get a large-scale
ISP A to add exceptions for source addresses belonging to ISP B.

So if we want ISPs to follow BCP38 *and* support multi-ISP CPEs - then
there is no way around proper source-address dependend routing.

Gert Doering
        -- NetMaster

---

From: Wuyts Carl <[email-masked]>
Date: Mon, 7 May 2012 13:05:54 +0200

Well, I've mentioned earlier that I'm not against this, just against adding it in today's req list, while you clearly confirm that multi-homed is out of scope for this document.  I don't see an issue today if an ISP provides 6rd and the same ISP decides to move to native at a certain moment in time.  This is perfectly possible today without using any "specials", like glueing protocols to each other or whatever.  It in fact can even be done in both directions (although it's probably not the target to switch form native to 6rd anyway :-)).  Indeed, to switch to native, the CPE must be dual stack, support DHCPv6 client, etc, but this is mandatory and covered in RFC6204 anyway.  And, depending on the roll-out model, it might need some (small) re-configuration (although this is not certain, lots of things can be pre-configured upfront but inactive due to v6 not enabled on the link to ISP), which is of course a pain.

Anyway, I'll leave this discussion as is today.  I can only speak from (residential) CPE's perspective and do want to see some progress in v6 deployment.  If the society however decides pro this kind of approach, democracy will be applied, but keep in mind you might put quite a few CPEs out of the game with this.  And, sadly enough, you'll hear the same old story on the v6 events : "The CPE is not ready".  Don't forget the CPE is that edge device, nearly free-of-charge ....

Regs
Carl

-----Original Message-----
From: Gert Doering [mailto:[email-masked]] 
Sent: maandag 7 mei 2012 11:39
To: Wuyts Carl
Cc: Tina TSOU; Simon Perreault; [email-masked]
Subject: Re: [v6ops] 6rd sunsetting requirements (version 3)

Hi,

The ISP is a *good guy* and following BCP38 - and there is no easy way a large-scale ISP can configure their access gear to do exceptions for "oh, that customer on a native link also has 6rd with *that* subnet, so make an exception for those source packets".

This topic will come back anyway as soon as multi-ISP is considered - this is out of scope for 6204bis, but you need to be handle it in the CPEs anyway.  Even if you could make the ISP case work for 6rd + native (which might be possible with some hackery, as the access router knows the ipv4 address and could theoretically be taught to recognize the corresponding 6rd address), there is no way ever you can get a large-scale ISP A to add exceptions for source addresses belonging to ISP B.

So if we want ISPs to follow BCP38 *and* support multi-ISP CPEs - then there is no way around proper source-address dependend routing.

Gert Doering
        -- NetMaster

---

From: Simon Perreault <[email-masked]>
Date: Mon, 07 May 2012 09:39:28 -0400

Agreed.

And IMHO we should leave multihoming for homenet, and avoid source 
routing in 6204bis.

Simon

---

From: [email-masked]
Date: Mon, 7 May 2012 10:52:55 -0400

> Well, if you want something in short term (like everyone seems to want, 
> although reality speaks against it) then I think you've to stop adding 
> these kind of requirements as you're making your own rules, overruling 
> protocol independency, ... just for the sake of getting things added.
> Carl

Hum... not sure I follow you Carl. You're arguing against adding a 
"simple 6RD sunset" requirement that would start 6RD only if DHCPv6
fails, but you're also against multihoming in the CPE. What do you 
suggest we do with the 6RD requirements as stated in "version 3" ? 

As a reminder, here's the latest version of 6RD-[4-7] (version 3): 

> 6RD-4:  A CE router MUST allow 6rd and native IPv6 WAN interfaces 
> to be active alone as well as simultaneously in order to support 
> coexistence of the two technologies during an incremental 
> migration period 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 [RFC3704]].
> 
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.

Reading this with implementor eyes, it looks like support for multihoming 
native IPv6 and 6RD is required, with some form of source routing. 
This has significant impacts on an implementor because it implies 
running multiple routing tables. This is basically 
importing ipv6-ce-transitioning requirements in 6204bis. 

The choices as I see them are:
1. Leave requirements 6RD-[4-7] as they were in -08
   (I'm fine with it, they're vague enough to allow 6RD single-homed)
2. Adopt requirements 6RD-[4-7] like they are in v3
   (with multihoming and source adress routing) 
3. Drop these reqs and add new simple 6rd sunsets requirements (more 
delays)
4. Drop these reqs and approve 6204bis without any sunsetting 
requirements. 

Choice 2 involves some form of multihoming in the CPE. As an implementor, 
how do you feel implementing this? (I am asking Carl here) This basically 
implies adding virtual routing tables support to the CPE (VRFs in 
Cisco-speak) 
and source-routing capabilities. Not rocket science, but it is a 
significantly new concept to introduce in CPEs for a specification 
that was meant to be a short-term and incremental change to 6204. 
On the flip-side, as Gert just mentioned, we're likely to need it 
in future versions of the specs anyways. 

Personnally, I would be fine with option 1 and leave the requirements as 
they were. 
This is vague enough to mandate 6RD without requiring multi-homing with 
native and 
6RD on at the same time. My second choice is 3, as it fits better my needs 
as an ISP, 
but it does add delays. I'd also be fine with a version of the 
requirements
that do not mandate multihoming, but it sounds like what's already in -08. 

/JF

---

From: Rémi Després <[email-masked]>
Date: Mon, 7 May 2012 17:29:55 +0200

Hi, Jean-Francois,

Le 2012-05-07 à 16:52, [email-masked] a écrit :
> ...
> 3. Drop these reqs and add new simple 6rd sunsets requirements (more delays)

> 
> 4. Drop these reqs and approve 6204bis without any sunsetting requirements.

Preferred choice,.
When approaches for 6rd sunsetting are well enough understood, it will be time to add whatever is appropriate.

Haste while the subject is still confusing is IMHO bound to deteriorate the otherwise good quality of 6204bis.

RD

> implies adding virtual routing tables support to the CPE (VRFs in Cisco-speak) 
> Personnally, I would be fine with option 1 and leave the requirements as they were. 
> This is vague enough to mandate 6RD without requiring multi-homing with native and 
> 6RD on at the same time. My second choice is 3, as it fits better my needs as an ISP, 
> but it does add delays. I'd also be fine with a version of the requirements

---

From: Mark Townsley <[email-masked]>
Date: Mon, 7 May 2012 19:55:48 +0200

There are not a lot of Retail CPE implementers on list here, but those that are speaking up seem to have committed to implementing multihoming between 6rd and native (at least Linksys + D-Link). We have two BCPs (38, 84) that have been around for quite a while that we are basing these requirements on. Even Carl whose customers really do not have the same issue as they mostly use non-retail routers cannot say the multihoming-based solution is wrong technically, just that he is worried that it will somehow delay general IPv6 availability in products. 

With respect to 6rd and IPv6 together, RFC6204 + RFC5969 was phase one as they defined each technology separately. By including 6rd in the Native IPv6 CPE document, we naturally bring ourselves to phase two where we describe how the two methods work together best. Otherwise, we might as well just publish an update to RFC5969 for any additional 6rd requirements, and leave 6rd out of 6204-bis entirely. 

We're back to moving in circles though. IIRC, the Chairs already made a consensus call on the list, and I've been posting the text they asked me to work on here. 3 versions later plus a privately-sent tweak from Randy Bush saying I should write "from which the packet is being sent" vs. "the packet is being sent on" and we will have done that. At this point, we either move forward with what the chairs asked, or continue to beat this horse and try to get them to reverse their decision. 

- Mark

---

From: Joel jaeggli <[email-masked]>
Date: Mon, 07 May 2012 18:15:19 +0000

On 5/7/12 17:55 , Mark Townsley wrote:
> 
> There are not a lot of Retail CPE implementers on list here, but
> those that are speaking up seem to have committed to implementing
> multihoming between 6rd and native (at least Linksys + D-Link). We
> have two BCPs (38, 84) that have been around for quite a while that
> we are basing these requirements on. Even Carl whose customers really
> do not have the same issue as they mostly use non-retail routers
> cannot say the multihoming-based solution is wrong technically, just
> that he is worried that it will somehow delay general IPv6
> availability in products.
> 
> With respect to 6rd and IPv6 together, RFC6204 + RFC5969 was phase
> one as they defined each technology separately. By including 6rd in
> the Native IPv6 CPE document, we naturally bring ourselves to phase
> two where we describe how the two methods work together best.
> Otherwise, we might as well just publish an update to RFC5969 for any
> additional 6rd requirements, and leave 6rd out of 6204-bis entirely.
> 
> 
> We're back to moving in circles though. IIRC, the Chairs already made
> a consensus call on the list, and I've been posting the text they
> asked me to work on here. 3 versions later plus a privately-sent
> tweak from Randy Bush saying I should write "from which the packet is
> being sent" vs. "the packet is being sent on" and we will have done
> that. At this point, we either move forward with what the chairs
> asked, or continue to beat this horse and try to get them to reverse
> their decision.

I'm sitting here waiting for an 09 version of the draft so that I can
expose the diffs to the list, test whether we need to need to reconsider
the WGLC, and send a shepherds report to the IESG if not. The longer
temporally and the more diveregent the document gets the more likely it
is imho that we need to reconsider the wg consensus on publication, but
we don't know because it's not in the tool yet.

---

From: Gert Doering <[email-masked]>
Date: Mon, 7 May 2012 20:26:05 +0200

Hi,

> And IMHO we should leave multihoming for homenet, and avoid source 

With 6rd included, and 6rd + native potentially running in parallel,
there is no way to avoid this particular issue.

(And the WG already reached consensus on this in Paris, so I wonder why
this is even discussed again)

Gert Doering
        -- Voice of Reason

---

From: "Brzozowski, John" <[email-masked]>
Date: Mon, 7 May 2012 18:40:35 +0000

Is the below really a requirement or a deployment choice that an operator must individually manage?

John
From: Mark Townsley <[email-masked]<mailto:[email-masked]>>
Date: Thu, 3 May 2012 08:17:51 +0200
To: IPv6 Operations <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] 6rd sunsetting requirements (version 3)

---

From: Mark Townsley <[email-masked]>
Date: Mon, 7 May 2012 20:43:19 +0200

It is a requirement that allows a choice.

- Mark

On May 7, 2012, at 8:40 PM, Brzozowski, John wrote:

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

---

From: "Brzozowski, John" <[email-masked]>
Date: Mon, 7 May 2012 18:46:31 +0000

Does anyone know if this a popular deployment model for 6rd adopters?

=========================================
John Jason Brzozowski
Comcast Cable
m) +1-609-377-6594
e) mailto:[email-masked]
o) +1-484-962-0060
w) http://www.comcast6.net
=========================================

From: Mark Townsley <[email-masked]<mailto:[email-masked]>>
Date: Mon, 7 May 2012 20:43:19 +0200
To: John Jason Brzozowski <[email-masked]<mailto:[email-masked]>>
Cc: IPv6 Operations <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] 6rd sunsetting requirements (version 3)

- Mark

John

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Mon, 7 May 2012 19:00:03 +0000

I'm not clear as to which of the two options you're asking about. But it's moot; the options are not for 6rd deployment models. They're for "6rd to native IPv6" transition models. To the best of my knowledge, nobody has deployed either such transition. I would guess that transition is far enough out that both options are being assessed to determine which has the lesser operational complexity. Operational complexity includes the amount of network coordination needed, complexity of network element software, as well as the potential call volume if customers find the transition to be noticeable. I don't think operational complexity of either option has been fully determined yet.

But we might be able to influence an answer to the operational complexity question, by not including support for one or the other option in the CE router. Based, hopefully, on what is easier for the CE router.
Barbara

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brzozowski, John
Sent: Monday, May 07, 2012 2:47 PM
To: Mark Townsley
Cc: IPv6 Operations
Subject: Re: [v6ops] 6rd sunsetting requirements (version 3)

- Mark

John

---

From: [email-masked]
Date: Mon, 7 May 2012 15:07:55 -0400

Mark, 
I agree that: 
- Multihoming is probably the desirable long-term solution
- This needs to move forward

We seem to disagree on : 
- the committment of D-Link 
- the consensus on the list. Many participants on this list 
asked for the consensus to be verified for the new "version 3"
text, the version in which multi-homing suddenly became a MUST. 
The verification of this consensus hasn't been done yet. 

Again, I am not willing to beat an already dead horse more than 
needed. However 4 ISPs have already stated they have reserves about 
this new text. In my opinion this is a significant challenge. 
That said, I have stated my arguments, I'll now wait for the 
consensus call (or the lack of). 

/JF

> There are not a lot of Retail CPE implementers on list here, 
> but those that are speaking up seem to have committed to 
> implementing multihoming between 6rd and native (at least 
> Linksys + D-Link). We have two BCPs (38, 84) that have been 
> around for quite a while that we are basing these requirements 
> on. Even Carl whose customers really do not have the same issue 
> as they mostly use non-retail routers cannot say the 
> multihoming-based solution is wrong technically, just that he 
> is worried that it will somehow delay general IPv6 availability in 
products. 
> 
> With respect to 6rd and IPv6 together, RFC6204 + RFC5969 was 
> phase one as they defined each technology separately. By including 
> 6rd in the Native IPv6 CPE document, we naturally bring ourselves 
> to phase two where we describe how the two methods work together 
> best. Otherwise, we might as well just publish an update to 
> RFC5969 for any additional 6rd requirements, and leave 6rd out 
> of 6204-bis entirely. 
> 
> a consensus call on the list, and I've been posting the text 
> they asked me to work on here. 3 versions later plus a 
> privately-sent tweak from Randy Bush saying I should write 
> "from which the packet is being sent" vs. "the packet is being
> sent on" and we will have done that. At this point, we either 
> move forward with what the chairs asked, or continue to beat 
> this horse and try to get them to reverse their decision. 
> 
> - Mark

---

From: Simon Perreault <[email-masked]>
Date: Mon, 07 May 2012 15:23:28 -0400

> there is no way to avoid this particular issue.

The point here is to not run 6rd and native in parallel. The "poor man's 
sunsetting" is to run 6rd only when native is unavailable.

> this is even discussed again)

I didn't remember any discussion on this issue in Paris, so I went and 
looked at the minutes. Seems like it was not discussed in Paris. Here 
are the full minutes:

>           Second presentation - RFC 6204 bis
>           http://www.ietf.org/proceedings/83/slides/slides-83-v6ops-11.pdf
>
>                   Ole T - DHCP fix going on in dhc WG
>
>
>           Fred B - regarding M/O bits read all discussion and take it up in 3315bis
>
>                   Francis D - w 6/7 remove them.
>
>           Question, ready for last call?
>
>           Answer - hum, (some in favor) (no opposed)
>
>           Question - no one prefers 6rd to native?
>
>           Answer - native prefered
>
>           Fred B - My perception is that we await an updated draft that deals with
>           the issues highlighted and we can run through a last call and be ready
>           to ship.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: "Brzozowski, John" <[email-masked]>
Date: Mon, 7 May 2012 21:04:32 +0000

Barbara,

My original email pertained to the following:
6RD-6: The CE router MUST allow different as well as identical delegated prefixes to be configured via each (6rd or native) WAN interface.
>From someone who has not adopted 6rd, has no plans to, but has used the same for trial this seems like it could add complexity.

John

From: Barbara Stark <[email-masked]<mailto:[email-masked]>>
Date: Mon, 7 May 2012 19:00:03 +0000
To: John Jason Brzozowski <[email-masked]<mailto:[email-masked]>>, Mark Townsley <[email-masked]<mailto:[email-masked]>>
Cc: IPv6 Operations <[email-masked]<mailto:[email-masked]>>
Subject: RE: [v6ops] 6rd sunsetting requirements (version 3)

I’m not clear as to which of the two options you’re asking about. But it’s moot; the options are not for 6rd deployment models. They’re for “6rd to native IPv6” transition models. To the best of my knowledge, nobody has deployed either such transition. I would guess that transition is far enough out that both options are being assessed to determine which has the lesser operational complexity. Operational complexity includes the amount of network coordination needed, complexity of network element software, as well as the potential call volume if customers find the transition to be noticeable. I don’t think operational complexity of either option has been fully determined yet.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Brzozowski, John
Sent: Monday, May 07, 2012 2:47 PM
To: Mark Townsley
Cc: IPv6 Operations
Subject: Re: [v6ops] 6rd sunsetting requirements (version 3)

- Mark

John

---

From: Mark Townsley <[email-masked]>
Date: Mon, 7 May 2012 23:59:26 +0200

On May 7, 2012, at 9:23 PM, Simon Perreault wrote:

> The point here is to not run 6rd and native in parallel. The "poor man's sunsetting" is to run 6rd only when native is unavailable.
> 
> I didn't remember any discussion on this issue in Paris, so I went and looked at the minutes. Seems like it was not discussed in Paris. Here are the full minutes:

I spent at least 40 minutes on it at the start of the second meeting, before 6204-bis. 

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Tue, 8 May 2012 01:10:08 +0200

> - Multihoming is probably the desirable long-term solution 

Great! I think we agree more than disagree, at least at this technical level.

So, where we are *right now* in terms of what's out there? - We have RFC 5969 and RFC 6204 implementations on the shelves and more and more coming. There are likely a variety of ways these are implemented side-by-side among various vendors. 

6204-bis gives us a chance such that by the time the 6rd is actually being sunset, we have some level of consistency in the field that gives operators the most flexibility.  If we ignore this, then we haven't really moved the status quo very far at all. Why let CPE vendors off the hook here?

> The verification of this consensus hasn't been done yet. 

version 1 was not intended to be any "lighter" on multihoming that version 3. I was happy with version 1 though, we got to 3 based on list comments and text provided by Chris Donley.

> this new text.
> In my opinion this is a significant challenge. 

What I am hearing are operators that either think it is not necessary because they don't mind a user having to type in configuration, or they have direct CPE management, or they believe forced single-homing is easier for the CPE vendors to implement. I am not hearing it will not work operationally. 

- Mark

> > is worried that it will somehow delay general IPv6 availability in products. 
> >

---

From: Mark Townsley <[email-masked]>
Date: Tue, 8 May 2012 01:29:13 +0200

> we don't know because it's not in the tool yet.

Here are the latest requirements that Chris, Hemant, Wes and I finally agreed upon (posted at "version 3" the other day), plus the specific text changes to 6RD-5 as suggested by Gert and Randy. I believe Hemant has the draft pen. 

6RD-5:  Each packet sent on a 6rd or native WAN interface MUST be directed such that the packet's source IP address is derived from a delegated prefix associated with the particular interface from which the packet is being sent [Section 4.3 [RFC3704]].

---

From: Wuyts Carl <[email-masked]>
Date: Tue, 8 May 2012 08:03:35 +0200

@ Jean-Francois.
Main q seems to be: "what do l want on these "simple" sunsetting requirements/rfc6204bis ?"

1.       I want to avoid reqs are being added over and over again, so draw a line and allow the CPE vendors to become compliant with some set.  I read "delay", but the delay is there because of the adding.

2.       If reqs are added, don't link protocols together.  Avoid having to do X when condition Y is met.  DHCPv6 and 6rd are not linked directly.  Your suggestion below: if DHCPv6 fails, then start 6rd ?  But you in this case even make the assumption that the ISP has something running for 6rd (from my view, some have, some don't, but you refer always to retail, so unknown to what ISP to connect) ?  You also need DHCPv4 for the option 212, or should it launch automatically some static 6rd tunnel (to what destination ?).  This is a generic concern from my end.  The company I work for is not operational in retail, so deploying in a managed model, hence this issue not even presents itself in reality for us, but protocol independency is very important (mainly for simplicity)

3.       6204 targets single home, let's keep it like this TODAY (maybe it needs new attention later on).  Single-homed 6rd "sunsetting" is not an issue at all, so let's stick to the simple requirements initially added, as it will already be hard enough to cope with it.

What about vrf and things like that.  One must be careful to make comparison.  You can hardly compare a Cisco CPE with a standard residential CPE, as this is no fair comparison.  Should/must the CPE be  full VR-capable or something alike it (using some labels or something to mimic it), be able to do some source-routing things, .... In the near future ?   I don't know of course, maybe, maybe not, but fact is that today the crowd is shouting for an IPV6 CPE, supporting dual stack and some popular transition scenario's, so let's try to make sure this one can be made available as soon as possible to allow massive v6 deployment.  Besides that, price of a CPE is always a very delicate subject.  Who needs/wants to pay for it ?  Adding reqs also means adding cost ....
Important thing operators are looking at today, in the v6 area, is things like UPnP/PCP, etc.  Lots of them are not deploying yet, hence not (yet) looking into sunsetting and for sure not in a multi-homed scenario.

This is of course my personal opinion, looked at it from residential CPE's perspective, which seems to be overlooked from time-to-time.   I'm really pro-v6, also IPv6 council co-chair for Belgium, so really trying to get enough attention to IPv6, to make deployment really happen on a large scale as soon as possible.

Regs
Carl

From: [email-masked] [mailto:[email-masked]]
Sent: maandag 7 mei 2012 16:53
To: Wuyts Carl
Cc: [email-masked]; [email-masked]
Subject: Re: [v6ops] 6rd sunsetting requirements (version 3)

As a reminder, here's the latest version of 6RD-[4-7] (version 3):

> delegated prefixes to be configured via each (6rd or native) WAN interface.
>
> 6rd and native IPv6, by default, the IPv6 CE Router MUST prefer native IPv6.

/JF

---

From: Rémi Després <[email-masked]>
Date: Tue, 8 May 2012 09:55:20 +0200

Le 2012-05-07 à 19:55, Mark Townsley a écrit :

> With respect to 6rd and IPv6 together, RFC6204 + RFC5969 was phase one as they defined each technology separately. By including 6rd in the Native IPv6 CPE document,

> we naturally bring ourselves to phase two where we describe how the two methods work together best.

"Working together" is only a temporary requirement since 6rd is no longer needed when DS is available.
It can be done without multihoming in several steps:
1. delegate native IPv6 prefixes that are the same prefixes as 6rd's (=> with ad hoc support in 6rd modules, CPE routers can still work with single IPv6 interfaces).
2. disable 6rd (with DHCP or otherwise)
3. if desired to have IPv6 prefixes independent from IPv4 addresses, replace IPv6 prefixes by new ones (for this, using the IPv6 lifetime mechanism is sufficient? No need for multihoming).

=> The MUST of 6RD-4 is therefore technically wrong if saying "A CE router MUST allow 6rd and native IPv6 WAN interfaces to be active alone as well as simultaneously in order to support coexistence of the two technologies during an incremental migration period from 6rd to native IPv6"). 

> Otherwise, we might as well just publish an update to RFC5969 for any additional 6rd requirements, and leave 6rd out of 6204-bis entirely.

Can't understand why 6rd would be left out ENTIRELY.
This would be a step backward that NOTHING justifies.

> We're back to moving in circles though.

Keeping 6rd as a requirement (6RD-1 to 6RD-3), and leaving out-4 multihoming (6RD-4, and 6RD-5 to 6RD-7 which depend on it)), does break the circle (unless the WG would insist to have NOW something that remains disputable).

RD

> IIRC, the Chairs already made a consensus call on the list, and I've been posting the text they asked me to work on here. 3 versions later plus a privately-sent tweak from Randy Bush saying I should write "from which the packet is being sent" vs. "the packet is being sent on" and we will have done that. At this point, we either move forward with what the chairs asked, or continue to beat this horse and try to get them to reverse their decision. 
> 
> - Mark
>

---

From: Gert Doering <[email-masked]>
Date: Tue, 8 May 2012 10:20:43 +0200

Hi,

> 1. delegate native IPv6 prefixes that are the same prefixes as 6rd's (=> with ad hoc support in 6rd modules, CPE routers can still work with single IPv6 interfaces).

This is something which is not really implementable in a large scale
deployment.

If you have a 100 users, you can manually tie IPv4 assignments (and thus
6rd prefix) and IPv6 prefix assignments together.  

If you have 10 million users, and dynamic IPv4 assignments, I can't see 
any way to make this work, except "special support built into the access 
routers on the ISP side, to correlate IPv6 native prefix assignment with 
IPv4 pool assignment".

Gert Doering
        -- NetMaster

---

From: Rémi Després <[email-masked]>
Date: Tue, 8 May 2012 10:47:49 +0200

> routers on the ISP side, to correlate IPv6 native prefix assignment with 

Automatic scripts to do it seem to me feasible if IPv4 addresses are stable (which is the case of 6rd deployments I know).
Yet, OK, this can be a problem where IPv4 addresses are dynamically assigned.

My remaining objection could be alleviated if 6RD-4 would become (asterisks to be deleted) "*For some anticipated 6rd sunsetting scenarios,* a CE router MUST allow 6rd and native IPv6 WAN interfaces to be active alone as well as simultaneously in order to support coexistence of the two technologies during an incremental migration period from 6rd to native IPv6"

RD

---

From: Ole Trøan <[email-masked]>
Date: Tue, 8 May 2012 10:53:49 +0200

Forced single homing can be done. but at the expense of creating dependencies between IPv4 and IPv6 provisioning.
see the attached flow charts. first one for multi-homing, second for forced single homing.

how a forced single homed CPE is to deal with changes (link failure for one protocol, lease times out for IPv4 address or IPv6 prefix...) is left as an exercise for the reader. ;-)

cheers,
Ole

---

From: Hans Liu <[email-masked]>
Date: Tue, 8 May 2012 17:40:42 +0800

How about run IPv4 and IPv6 provisioning in parallel. Cache 6rd option and
DS-Lite option if there is one. Try bring up the native connections, either
IPv4 or IPv6 or Dual stack, first. then take bring up the virtual
interfaces via the cached 6rd or DS-Lite option.  And again run IPv6/IPv4
provisioning when lease time out of a IPv4/IPv6.

For example, a device gets native IPv4, and 6rd and no native IPv6.  Later
on, ISP may start their deployment of native IPv6. When IPv4 lease time
out, the device re-process IPv6 and IPv4 provisioning, and it may now get
both 6rd option and native IPv6.

Best regards,
Hans

On Tue, May 8, 2012 at 4:53 PM, Ole Trøan <[email-masked]> wrote:

> Forced single homing can be done. but at the expense of creating
> dependencies between IPv4 and IPv6 provisioning.
> how a forced single homed CPE is to deal with changes (link failure for
> one protocol, lease times out for IPv4 address or IPv6 prefix...) is left
> as an exercise for the reader. ;-)
>
> cheers,
> Ole
>
>

---

From: Ole Trøan <[email-masked]>
Date: Tue, 8 May 2012 11:52:14 +0200

> How about run IPv4 and IPv6 provisioning in parallel. Cache 6rd option and DS-Lite option if there is one. Try bring up the native connections, either IPv4 or IPv6 or Dual stack, first. then take bring up the virtual interfaces via the cached 6rd or DS-Lite option.  And again run IPv6/IPv4 provisioning when lease time out of a IPv4/IPv6. 
> 
> For example, a device gets native IPv4, and 6rd and no native IPv6.  Later on, ISP may start their deployment of native IPv6. When IPv4 lease time out, the device re-process IPv6 and IPv4 provisioning, and it may now get both 6rd option and native IPv6.  

yes, how long do you wait until you terminate native IPv4 and IPv6 provisioning?
or do you continue to try native v6/v4 forever and are prepared to tear down the virtual connections?

and by the way, for this to work we all have to agree on which mechanism is preferred.
native IPv6 over 6rd seems fair.
do we all agree that for IPv4, a CPE should prefer a DS-lite connection over a native one?

cheers,
Ole

> <Screen Shot 2012-05-08 at 10.50.04 .png><Screen Shot 2012-05-08 at 10.49.50 .png>
>

---

From: Hans Liu <[email-masked]>
Date: Tue, 8 May 2012 18:21:09 +0800

> or do you continue to try native v6/v4 forever and are prepared to tear down the virtual connections?

[Hans]: I don't know how long a delay it may occur, so far, thanks my
ISP,  my IPv6 provisioning or IPv4 provisioning experience are good.
MOHO, one or two retry. If it fails, it fails. Wait for next run.  How
about that?

> do we all agree that for IPv4, a CPE should prefer a DS-lite connection over a native one?

[Hans]: I thought we agreed to focus on 6rd and native IPv6 first.

---

From: Ole Trøan <[email-masked]>
Date: Tue, 8 May 2012 12:55:10 +0200

> MOHO, one or two retry. If it fails, it fails. Wait for next run.  How

MAX_SOL_RT perhaps (2 minutes) or MAX_RTR_SOLICITATIONS * RTR_SOLICITATION_INTERVAL?

do we require predictable and consistent behaviour from CPEs with regards to this?
if not, we may as well leave it undefined, but then why isn't "MUST support RFC5969" good enough?
I would much prefer that than to specify "forced single homing"; a solution I would not recommend that we implement at least.

> [Hans]: I thought we agreed to focus on 6rd and native IPv6 first.

they are loosely correlated. we don't need to use the same solution, but the same problem exists.

if we rather want to leave this as implementation specific then that's fine. as a CPE vendor I'm certainly going to make sure that my CPE works on all possible access networks with whatever combination of transition mechanism and native protocol available. ISPs will of course have to deal with varying support and behaviour from the CPEs connected to their networks.

*sarcasm mode on*
two requirements then.
6RD-1: An IPv6 CE router MUST support 6rd [RFC5969].
DSW-1: An IPv4 CE router MUST support DS-lite [RFC6333] and the DS-lite DHCP option specified in RFC6334.

cheers,
Ole

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 8 May 2012 13:16:59 +0000

> do we all agree that for IPv4, a CPE should prefer a DS-lite connection over a

Is the native one giving me a CGN NATted IPv4 address, or a public IPv4 address? I think I would prefer public IPv4 over DS-Lite over CGN.
Barbara

---

From: Simon Perreault <[email-masked]>
Date: Tue, 08 May 2012 09:21:42 -0400

> or do you continue to try native v6/v4 forever and are prepared to tear down the virtual connections?

The second option looks good. Take for example the venerable ISC 
dhclient. By default, after trying for 60 seconds it goes to sleep for 5 
minutes, then it tries again for 60 seconds. It does this indefinitely. 
Most DHCP clients and network managers do something similar, never 
actually giving up.

Then you implement the following simple event handlers:

native v4 goes up with 6rd config ==> bring up 6rd if native v6 is down
native v4 goes down ==> bring down 6rd if 6rd is up
native v6 goes up ==> bring down 6rd if 6rd is up
native v6 goes down ==> bring up 6rd if native v4 is up with 6rd config

This can be extended for DS-Lite with either of these:

a) with preference for native IPv4 over DS-Lite:

native v6 goes up with DS-Lite config ==> bring up DS-Lite if native v4 
is down
native v6 goes down ==> bring down DS-Lite if DS-Lite is up
native v4 goes up ==> bring down DS-Lite if DS-Lite is up
native v4 goes down ==> bring up DS-Lite if native v6 is up with DS-Lite 
config

b) with preference for DS-Lite over native IPv4:

native v6 goes up with DS-Lite config ==> bring up DS-Lite, bring down 
native v4 if native v4 is up, and stop DHCPv4 client
native v6 goes down ==> bring down DS-Lite if DS-Lite is up, and start 
DHCPv4 client if it is stopped
native v4 goes up ==> nothing special
native v4 goes down ==> nothing special

A simple state machine...

Simon

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 8 May 2012 13:52:48 +0000

Hi John,
Yes. This is what I was responding to. This is a "sunsetting" requirement. There is a proposal that when introducing native IPv6 for purpose of sunsetting, that the provider provision the DHCPv6 server to hand out the same prefixes as what is being provided via 6rd. The idea, I believe, is that this would make for a "seamless" migration from the customer's perspective. No change in numbering.

Or native IPv6 could be deployed with a distinct prefix from what is being used for 6rd.

I believe Gert did a very good job in an email sent today of weighing in on the operational complexity of trying to do prefix matching.
But you asked which of these options was being deployed. My response was that since they are options for sunsetting (that is, for native IPv6 deployment in the presence of 6rd), and not for actual 6rd deployment, there are no deployments of either. Nobody has sunset any 6rd deployments, yet.

Personally, I agree with Gert that trying to do prefix matching seems very complex to me. But I have no input into what the access network does. I deal with CE routers. I also agree that the CE router requirement adds complexity, though I don't know how much complexity. I usually try to design my routers so that I'm ready for whatever those access network guys finally decide to throw at me. In this case, though, if it's considered too complex in the CE router to support both, then maybe we should help the access network guys make their decision, by only supporting one of the options in the CE router. Of course, there's also the option of not supporting multi-homing at all in the CE router, and requiring the user to enable/disable 6rd. [BTW, in my "poor man's migration", I would disable DHCPv6/RS if 6rd is enabled; I think it would be ok to try DHCPv6 if 6rd was enabled but not manually configured or mgmt.-interface configured and DHCPv4 came back with no option 212; basically this makes 6rd "preferred" if enabled. What I've been told, is that 6rd implementations seen to date all require explicit enabling of the function before the CE router will try to do 6rd. In my experience, users tend to have not so much trouble when told to turn a function on or off. What they tend to have trouble with is fill-in-the-blank configuration, like logins, passwords, POP/SMTP servers, etc., or option overload like we see with privacy settings.]
Barbara

From: Brzozowski, John [mailto:[email-masked]]
Sent: Monday, May 07, 2012 5:05 PM
To: STARK, BARBARA H; Mark Townsley
Cc: IPv6 Operations
Subject: Re: [v6ops] 6rd sunsetting requirements (version 3)

Barbara,

John

- Mark

John

---

From: Randy Bush <[email-masked]>
Date: Tue, 08 May 2012 07:11:09 -0700

> - the committment of D-Link 

they are a vendor.  operators judge their committment when there
is shipping product.  :)

> text, the version in which multi-homing suddenly became a MUST. 

as the sun sets on my 6rd deployment and the beautiful moon of native
ipv6 rises, it seems prudent to allow a time when both are in the sky.
especially if i have a mix of cpe capabilities.  do we have a simpler
way of viewing this than multi-homing?

randy

---

From: Rémi Després <[email-masked]>
Date: Tue, 8 May 2012 16:17:58 +0200

> way of viewing this than multi-homing?

If native IPv6 prefixes that are delegated are the same as those of 6rd, yes.
If new IPv6 prefixes are preferred, it can be done in a second phase, when 6rd has been disabled, using the lifetime of IPv6 prefixes.
RD

---

From: Chris Donley <[email-masked]>
Date: Tue, 8 May 2012 15:17:54 -0600

Our testing shows that NAT444 offers a better user experience than DS-Lite
(due in part to MTU issues).  Customer hat on - I would strongly prefer
native IPv4 to DS-Lite, even if that native v4 address were behind a CGN.

Chris

On 5/8/12 7:16 AM, "STARK, BARBARA H" <[email-masked]> wrote:

>> do we all agree that for IPv4, a CPE should prefer a DS-lite connection
>>over a
>> native one?
>
>Is the native one giving me a CGN NATted IPv4 address, or a public IPv4
>address? I think I would prefer public IPv4 over DS-Lite over CGN.
>Barbara

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 8 May 2012 21:21:30 +0000

Interesting. I stand corrected. Thx.
Barbara

> (due in part to MTU issues).  Customer hat on - I would strongly prefer native
> IPv4 to DS-Lite, even if that native v4 address were behind a CGN.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 May 2012 10:24:16 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Chris Donley
> Sent: Tuesday, May 08, 2012 2:18 PM
> To: STARK, BARBARA H; Ole Trøan; Hans Liu
> Cc: IPv6 Operations
> Our testing shows that NAT444 offers a better user experience than DS-
> Lite (due in part to MTU issues).  

On the MTU issue, Dual-Stack Lite suggests that ISPs deploy larger
MTU between the subscriber's B4 and the AFTR element.  The same
paragraph admits this may not always be feasible.
http://tools.ietf.org/html/rfc6333#section-5.3  

I assume, without knowing for sure, that your testing did not 
follow RFC6333's recommendation to use a larger MTU over that 
path.

The industry has long experience with PPPoE, which also has a 
shorter MTU, and causes various problems.  The problems are 
generally resolved by CPE routers that rewrite the MSS 
option of outgoing TCP SYNs.  However, such MSS option rewriting 
is frowned upon by many technologists as a layering violation 
and thus is not mentioned in RFC6333.  However, it is effective 
at reducing round trips for servers to discover the smaller MTU
(where ICMP packet too big succeeds) and avoids the delays 
of PMTUD blackhole discovery (when ICMP packet too big fails).

I assume, without knowing for sure, that your testing did not
include TCP MSS rewriting.

-d

> Customer hat on - I would strongly prefer

---

From: Mark Andrews <[email-masked]>
Date: Fri, 11 May 2012 10:06:24 +1000

In message <0a9701cd2ed1$ba0932e0$2e1b98a0$@com>, "Dan Wing" writes:
> > To: STARK, BARBARA H; Ole Tr=F8an; Hans Liu
> > Cc: IPv6 Operations

I hate to say it but we need MTU pain now with IPv4.  With PMTUD
on by default for everything in IPv6 we need to get rid of this
mindset that one can filter out ICMP{v6} messages and have a working
connection.  Do we really want every router with mismatching next
hop MTUs looking at every SYN packet and deciding if it needs to
trim MSS?  That is the way it is heading if we don't stop this
ICMP{v6} filtering idiocy.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 10 May 2012 18:03:17 -0700

> ICMP{v6} filtering idiocy.

A science fiction writer said the answer is 42, but the answer
is 1280.

-d

---

From: Mark Andrews <[email-masked]>
Date: Fri, 11 May 2012 12:48:14 +1000

> A science fiction writer said the answer is 42, but the answer

And RFC 4821 support for at least TCP.

	RFC 4821 - Don't get IPv6 without it!

---

From: Chris Donley <[email-masked]>
Date: Fri, 11 May 2012 08:19:26 -0600

We did our testing on a DOCSIS network, which allows 1522 byte frames.  We
did not enable MSS rewriting.

Chris

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 11 May 2012 08:22:08 -0700

> did not enable MSS rewriting.

If this issue is systemic for DOCSIS, and MSS rewrite is a known and
common solution, should 6204bis include language about MSS rewrite?

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Fri, 11 May 2012 10:58:55 -0500

-----Original Message-----
From: Cameron Byrne [mailto:[email-masked]] 
Sent: Friday, May 11, 2012 11:22 AM
To: Chris Donley
Cc: Dan Wing (dwing); STARK, BARBARA H; Ole Trøan; Hans Liu; IPv6 Operations; [email-masked]
Subject: Re: [v6ops] DS-Lite worse than native IPv4 [was RE: 6rd sunsetting requirements (version 3)]

>common solution, should 6204bis include language about MSS rewrite?

The DS-Lite RFC in RFC 6333 already did not include the MSS rewrite because the rewrite is considered a hack due to a layer violation (as also mentioned by Dan Wing) for this thread.  Thus if RFC 6333 does not mention the MSS rewrite, rfc6204bis should not either.

Hemant

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 11 May 2012 09:08:45 -0700

On Fri, May 11, 2012 at 8:58 AM, Hemant Singh (shemant)
<[email-masked]> wrote:
> Cc: Dan Wing (dwing); STARK, BARBARA H; Ole Trøan; Hans Liu; IPv6
> Operations; [email-masked]
> The DS-Lite RFC in RFC 6333 already did not include the MSS rewrite because
> the rewrite is considered a hack due to a layer violation (as also mentioned
> by Dan Wing) for this thread.  Thus if RFC 6333 does not mention the MSS
> rewrite, rfc6204bis should not either.
>
>
>
> Hemant

Neither of those documents are v6ops, and they do not need to serve
the operator community in the same way v6ops does.

6204bis is a v6ops document.

So, if MSS rewrite is required to "operationalize" DS-lite, perhaps it
should be added.

No?

CB

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 11 May 2012 10:26:14 -0700

> From: Chris Donley [mailto:[email-masked]]
> Sent: Friday, May 11, 2012 7:19 AM
> To: Dan Wing; 'STARK, BARBARA H'; 'Ole Trøan'; 'Hans Liu'
> Cc: 'IPv6 Operations'
> Subject: Re: DS-Lite worse than native IPv4 [was RE: [v6ops] 6rd
> sunsetting requirements (version 3)]
> 
> We did our testing on a DOCSIS network, which allows 1522 byte frames.
> We did not enable MSS rewriting.

Thanks.  That certainly explains why the user experience suffered.

-d

---

From: Daniel Roesen <[email-masked]>
Date: Fri, 11 May 2012 19:34:03 +0200

> Thanks.  That certainly explains why the user experience suffered.

And at the same time is a completely unrealistic testing scenario for
today's Internet. Just as fragmenting the tunnel instead of the payload,
but that's another story. :)

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0

---

From: Chris Donley <[email-masked]>
Date: Fri, 11 May 2012 16:45:54 -0600

I don't support MSS rewrite language in 6204bis.  Most of our members are
considering solutions other than DS-Lite.  I suggest that those who are
planning DS-Lite deployments talk with their vendors if they think they
need MSS rewrite support.

Chris

---

From: Randy Bush <[email-masked]>
Date: Fri, 11 May 2012 13:35:01 -1000

> considering solutions other than DS-Lite.

so you want ds-lite to fail?

and here i thought we tried to engineer things to succeed.  live and
learn.

randy, who is not particularly a ds-lite fan

---

From: Joel jaeggli <[email-masked]>
Date: Sat, 12 May 2012 09:45:32 +0000

> need MSS rewrite support.

While I am unconvinced that we need to address this, I think the
rational expressed here is rather poor.

If requirements for DS-Lite are not germain to cpe router deployment it
wouldn't be represented in 6204bis. It is in fact not a feature of 6204.

joel

---

From: Rémi Després <[email-masked]>
Date: Mon, 14 May 2012 07:28:58 +0200

> rational expressed here is rather poor.

What about having it with a MAY, to document the technical rationale without making it a requirement?

RD

---

From: "Lee Howard" <[email-masked]>
Date: Mon, 14 May 2012 11:34:02 -0400

> > The DS-Lite RFC in RFC 6333 already did not include the MSS rewrite
> > because the rewrite is considered a hack due to a layer violation (as
> > also mentioned by Dan Wing) for this thread.  Thus if RFC 6333 does
> > not mention the MSS rewrite, rfc6204bis should not either.
> >
> Neither of those documents are v6ops, and they do not need to serve the
operator
> community in the same way v6ops does.

Fair enough.  Would the operator who has a problem we need to solve please
raise
their hand?

Lee

---

From: Mark Townsley <[email-masked]>
Date: Thu, 17 May 2012 15:14:52 +0200

FYI: 

6RD-5 in the -09 text out today did not include the clarification requested by Gert and Randy mentioned below:

-09 reads:
"the upstream network the WAN interface is connected to"

It should be:
"the particular interface from which the packet is being sent" 

Seems to just be an editorial oversight. 

- Mark

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 17 May 2012 09:08:30 -0500

Mark,

Will fix it.

Thanks,

Hemant

-----Original Message-----
From: Mark Townsley [mailto:[email-masked]] 
Sent: Thursday, May 17, 2012 9:15 AM
To: Joel jaeggli
Cc: Hemant Singh (shemant); Chris Donley; Gert Doering; Randy Bush; IPv6
Operations
Subject: Re: [v6ops] 6rd sunsetting requirements (for -09)

FYI: 

6RD-5 in the -09 text out today did not include the clarification
requested by Gert and Randy mentioned below:

-09 reads:

It should be:

- Mark

On May 8, 2012, at 1:29 AM, Mark Townsley wrote:

> Here are the latest requirements that Chris, Hemant, Wes and I finally
agreed upon (posted at "version 3" the other day), plus the specific
text changes to 6RD-5 as suggested by Gert and Randy. I believe Hemant
has the draft pen. 
> 
> 6RD-4:  A CE router MUST allow 6rd and native IPv6 WAN interfaces to
be active alone as well as simultaneously in order to support
coexistence of the two technologies during an incremental migration
period from 6rd to native IPv6. 
> 6RD-5:  Each packet sent on a 6rd or native WAN interface MUST be
directed such that the packet's source IP address is derived from a
delegated prefix associated with the particular interface from which the
packet is being sent [Section 4.3 [RFC3704]].

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Thu, 17 May 2012 11:44:59 -0500

Mark,

Please see if this revised text works for you? In the -09 I had
incorporated what was version -03 mailed out by you to v6ops. Once you
approve, I can post a -10.

   6RD-4:  A CE router MUST allow 6rd and native IPv6 WAN interfaces to
           be active alone as well as simultaneously in order to support
           coexistence of the two technologies during an incremental
           migration period such as a 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 particular interface
           from which the packet is being sent[Section 4.3 [RFC3704]].

   6RD-6:  The CE router MUST allow different as well as identical
           delegated prefixes to be configured via each (6rd or native)
           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.

Thanks,

Hemant

-----Original Message-----
From: Mark Townsley [mailto:[email-masked]] 
Sent: Thursday, May 17, 2012 9:15 AM
To: Joel jaeggli
Cc: Hemant Singh (shemant); Chris Donley; Gert Doering; Randy Bush; IPv6
Operations

FYI: 

-09 reads:

It should be:

- Mark