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

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 26 Apr 2012 13:55:10 +0000

I'm feeling at a real disadvantage, not knowing what really happened at the IETF meeting, and with trying to decipher everything I'm reading, some of which was sent in private emails. I thought there used to be attempts to confirm on the list agreements that were reached at IETF meetings. I guess not this time. And with every passing email, it's becoming more and more unclear to me exactly what that agreement was.

Since I don't know exactly what was or wasn't said or agreed to at the last IETF, let me start by expressing my general philosophy around this document and specifically around 6rd:

1.       I need for this document to express CE Router requirements that will be sufficient to allow end users to establish IPv6 connectivity, both by "native" IPv6 and 6rd.

2.       This doesn't mean everything has to be automated. Requiring end users to follow simple configuration instructions is acceptable. For example, end users that have PPPoE connections are often provided instructions for getting PPPoE up and running.

3.       If omitting requirements for a piece of functionality means that the IPv6 connection might not work (either at all, or even not quite correctly), ever, no matter what configuration options exist, then that's a showstopper and needs to be remedied.

4.       If omitting requirements for a piece of functionality means that the user might have to manually do something to the configuration, this is less than desirable but not a showstopper. Some number of calls to the help desk are always to be expected when manual configuration is needed, and that's not a wonderful thing. But loading up the CE router with potentially costly, complex, and half-baked functionality that isn't absolutely necessary to achieving connectivity (and not necessary for a reasonable migration experience, IMO) may also be less than desirable. As a technology person who has recommended such useful features internally to my own company, only to have them stripped out of the product when negotiations around pricing and timeline occur, I truly do understand the desire to "gold plate" these devices. It's easy for us technology people, because we can throw the recommendation out there without having to bear the cost.

5.       Requiring support for simultaneous 6rd and native IPv6 connections, and all that goes with that, may not be all that easy. It certainly seems to me to add a fair amount of complexity. And the experience of the user who might have to go into the CE router UI at some point in time, say 5 years from now, and spend 5 minutes turning off 6rd and bringing native IPv6 up, and waiting another minute for the home network to renumber itself if necessary, just doesn't seem worthy of a "MUST" requirement to prevent such a "horrible" experience.

6.        I need 6rd support, so customers can use these CE routers to get IPv6 connectivity on a 6rd-enabled access network. Now.

7.       If we must have these transition statements, I would prefer that this simultaneous 6rd/native operation not be mandated. If the CE router does it, then, yes, it needs to do all the rest, too. But *forcing* support for automated transition into a low-end CE router in order to save the user 6 minutes of effort 5 years from now strikes me as the wrong thing to do. It isn't *necessary*. What Remi suggests is also reasonable to me. Beautiful, automated transition would certainly provide a lovelier user experience. But it's not core to giving the user IPv6 connectivity. Providing the user the ability to only have either 6rd or native IPv6 operational at any given time is acceptable. IMO. I would even be happy if transition were addressed by a requirement that says something like "In the absence of a robust 6rd to native IPv6 transition capability, the CE router MUST NOT allow simultaneous 6rd and native IPv6 connections. Detailed requirements for implementing a robust transition capability are not addressed in this document."

I realize some people will be upset by this stance, and I'm really sorry. For me, this isn't personal, and I, for one, believe that absolutely everyone on this thread is acting in good faith and expressing what they believe is right for the industry as a whole. We just happen to disagree as to what is right.
Barbara

---

From: Ole Trøan <[email-masked]>
Date: Thu, 26 Apr 2012 20:01:49 +0200

Barbara,

[...]

did you see the v6ops presentation at http://tools.ietf.org/agenda/83/slides/slides-83-v6ops-13.pdf

>  IMO. I would even be happy if transition were addressed by a requirement that says something like “In the absence of a robust 6rd to native IPv6 transition capability, the CE router MUST NOT allow simultaneous 6rd and native IPv6 connections. Detailed requirements for implementing a robust transition capability are not addressed in this document.”

you are proposing "Forced single homing". that is quite complex to implement. you are creating a dependency between IPv4 and IPv6 on the interface. how long do you try initiating native IPv6 before allowing 6rd to come up?
what do you do when native IPv6 appears on the WAN?

I think the opposite is the case, that implementing the simple multi-homing solution (choose exit based on source) is much simpler than trying to get "forced single homing" correctly.

in addition this scheme is much more generic, it works with multiple native IPv6 connections too.

cheers,
Ole

---

From: Ole Trøan <[email-masked]>
Date: Thu, 26 Apr 2012 20:02:43 +0200

Barbara,

> 6.        I need 6rd support, so customers can use these CE routers to get IPv6 connectivity on a 6rd-enabled access network. Now.

don't you have that already? or how is that not RFC6204 + RFC5969?

cheers,
Ole

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 26 Apr 2012 18:07:37 +0000

> Barbara,
> 
> > 6.        I need 6rd support, so customers can use these CE routers to get IPv6
> connectivity on a 6rd-enabled access network. Now.
> 

No, it's not RFC6204 + RFC5969. I need:
   6RD-2:  If the IPv6 CE router is capable of automated configuration
           of IPv4 through IPCP (i.e., over a PPP connection), it MUST
           support user-entered configuration of 6rd.

   6RD-3:  If the CE router supports configuration mechanisms other than
           the 6rd DHCPv4 Option 212 (user-entered, TR-69, etc.), the CE
           router MUST support 6rd in "hub and spoke" mode. 6rd in "hub
           and spoke" requires all IPv6 traffic to go to the 6rd Border
           Relay.  In effect, this requirement removes the "direct
           connect to 6rd" route defined in Section 7.1.1 of [RFC5969].

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 26 Apr 2012 18:29:30 +0000

> you are proposing "Forced single homing". that is quite complex to
> implement. you are creating a dependency between IPv4 and IPv6 on the
> interface. how long do you try initiating native IPv6 before allowing 6rd to
> come up?
> I think the opposite is the case, that implementing the simple multi-homing
> solution (choose exit based on source) is much simpler than trying to get
> "forced single homing" correctly.
> 

If 6rd is enabled, then don't even try native IPv6. Disable it. If native IPv6 is enabled, then 6rd is not enabled. There is no "try initiating IPv6 before allowing 6rd to come up". If 6rd is enabled, and not configured or the BR isn't there, then there is no IPv6. When native IPv6 appears on the WAN, nothing happens until 6rd is disabled and native IPv6 is enabled. This scheme works across all devices that are not designed to support multiple IPv6 connections. It's very simple. Very Boolean.

I'm not saying CE routers should have to do this and be precluded from implementing auto-migration. I'm saying exactly the opposite -- CE routers should not be required to support multiple WAN IPv6 interfaces. Auto-migration is great. But manual config isn't so horrible that it needs to be forbidden.

And yes, I know all about parents, friends and relatives who can't even do this simple a configuration change. But I don't need 100% of CE routers to be designed to meet the needs of those people. TR-069 management exists on most of the CE routers my company ships. We can do that configuration toggle remotely, so it looks auto-migrated to the customer. This would allow us great flexibility in rolling out the native IPv6, by enabling a few at a time. Simultaneous 6rd and native IPv6 is not required for appearing-to-the-user-to-be-auto-migrated 6rd to IPv6 in TR-069-managed CE routers.  The people who don't choose to go with our routers tend to be more tech savvy, and understand that with freedom from SP-management comes a requirement to be willing to do some of your own configuration. I'm not going to tell these tech savvy people that their CE router must support auto-migration in order to work with our 6rd service and subsequently with our native IPv6 service. That would be inaccurate. The CE router needs to support IPv6 (and, yes, RFC 6204 does a great job describing that). And it needs to support 6rd, including 6RD-2 and 6RD-3, which are not covered in RFC 5969.
Barbara

---

From: Ole Trøan <[email-masked]>
Date: Thu, 26 Apr 2012 22:37:32 +0200

Barbara,

> If 6rd is enabled, then don't even try native IPv6. Disable it. If native IPv6 is enabled, then 6rd is not enabled. There is no "try initiating IPv6 before allowing 6rd to come up". If 6rd is enabl…

in the managed CPE environments this certainly would work. the environment I thought we were writing 6204 for, was the retail routers. those that were not managed by the ISP.

where we have the following text in the introduction:

   This document specifies how an IPv6 CE router automatically
   provisions its WAN interface, acquires address space for provisioning
   of its LAN interfaces, and fetches other configuration information
   from the service provider network.  Automatic provisioning of more
   complex topology than a single router with multiple LAN interfaces is
   out of scope for this document.

as far as I recall we started this effort off with the goal of being able to specify a retail router, that could be plugged into an access network, as specified by BBF or CableLabs and that it would work without requiring any manual configuration.

> I'm not saying CE routers should have to do this and be precluded from implementing auto-migration. I'm saying exactly the opposite -- CE routers should not be required to support multiple WAN IPv6…

it certainly isn't, but it is out of scope for this document.

> And yes, I know all about parents, friends and relatives who can't even do this simple a configuration change. But I don't need 100% of CE routers to be designed to meet the needs of those people.…

but this document isn't for the managed CPE router case. we have TR-124 and eRouter for that.

I just don't understand how the manual configuration option can work... my ISP offers me a L2 service. I plug in my own CPE. if the ISP uses 6rd, I will have to manually enable 6rd (assuming the CPE I bought defaulted to native IPv4 and native IPv6. say I did that (why would I?), a year later the ISP stops doing 6rd, and offers native IPv6. what do I then do? buy a new router? or does the ISP call me and ask me to change setup (for 100s of different CPE models) or most likely I don't ever notice, and I'm back to having an IPv4 only home.

so no, in the case where the end user buys his own CPE, I just cannot see how your scheme will work.

cheers,
Ole

---

From: Ole Trøan <[email-masked]>
Date: Thu, 26 Apr 2012 22:45:21 +0200

Barbara,

>           support user-entered configuration of 6rd.

if we absolutely need this requirement, I'd much rather have something like:

6RD-2: The 6rd configuration parameters MUST be user-configurable.

>           connect to 6rd" route defined in Section 7.1.1 of [RFC5969].

right. not wanting to sound like Hemant, which RFC is this defined in? ;-)

RFC6204bis is going to be the normative reference for this, as it is not described elsewhere.
this truly belongs in an update to 5969.

if we must include this requirement, I'd suggest we simplify it to:

6RD-3: The CE router MUST support 6rd in "hub and spoke" mode. 6rd in "hub
       and spoke" requires all IPv6 traffic to go the 6rd Border
       Relay. In effect, this requirement removes the "direct
       connect to 6rd" route defined in Section 7.1.1 of [RFC5969].

cheers,
Ole