Re: [v6ops] Up-leveling Transition Coexistence

[Tina TSOU <[e-mail]>]

Mark,

Sent from my iPad

On Dec 17, 2011, at 1:53 AM, "Mark Townsley" <[e-mail]<mailto:[e-mail]>> wrote:


On Dec 15, 2011, at 11:29 PM, Tina TSOU wrote:

Mark,
Thanks. It is very useful.
(3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, etc)
How to do "forwarding-oriented" in CPE to distinguish among the techniques such as classical DS-Lite and Light Weight 4over6?

Our latest version attempts to tackle this:

<http://tools.ietf.org/html/draft-townsley-troan-ipv6-ce-transitioning-02>http://tools.ietf.org/html/draft-townsley-troan-ipv6-ce-transitioning-02
I read this draft, it is well written. In table one, we have used all 3 bits. Light Weight 4over6 is not on the list. How does the CE know it is going to be operated in which mechanism, if it is only forwarding-oriented? Then, do we have to to change this value by re-coding if each mechanism is added? Or make a CLI to change this value?

- Mark


- Tina


-----Original Message-----
From: <mailto:[e-mail]> [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Mark Townsley
Sent: Wednesday, December 14, 2011 9:27 AM
To: <mailto:[e-mail]> [e-mail]<mailto:[e-mail]> Operations
Subject: [v6ops] Up-leveling Transition Coexistence


Folks,

We have had a lot of lively discussion of late on the new sections in 6204-bis that describe how 6rd, Dual-Stack, and DS-Lite  are to work together on a residential CE router. I'd like to summarize what I think the main architectural issue is alongside a possible solution framework. Technical comments are very welcome, but let's also try and keep them thoughtful and at a pace that everyone can keep up amidst their day-jobs.

The requirements in RFC 6204 are based on a fundamental assumption that a CE router has a single active WAN interface for forwarding IPv4 and IPv6 traffic towards an ISP. The inclusion of IPv6 via 6rd, IPv6 via Native, IPv4 via DS-lite and IPv4 via Native together forces us to at least reconsider this basic assumption.  Breaking this down at bit, there are three possible steady-state combinations of "native" and "virtual" (tunneled) dual-stack connectivity methods that do not break the basic forwarding model of a single WAN egress per IP version:

(1) One Native IPv4 and IPv6 interface (Classic Dual-Stack)
(2) One Native IPv4 and one Virtual IPv6 interface (6rd, Softwires H&S via L2TP, TSP, etc)
(3) One Virtual IPv4 and one Native IPv6 interface (DS-Lite, 4rd, etc)

Digging deeper into transition between these states:

For (1), IPv4 and IPv6 each share a single WAN interface, so there is no problem when enabling one vs. the other.

For (2), when enabling tunneled IPv6 on an existing IPv4-only network there is no significant change in the basic model as each IP version still has its own distinct single WAN interface. Multihoming issues arise when enabling native IPv6 alongside tunneled IPv6 (needed for "6rd sunsetting") as IPv6 may be enabled on two distinct interfaces at the same time.

For (3) there similarly is no problem when enabling tunneled IPv4 on an existing IPv6-only network, and I have been told that there are greenfield deployments just like this happening. The multihoming issues arise when enabling tunneled IPv4 on a network that has native IPv4 available at the same time.

I'd like to identify two strategies to deal with these situations.

The first I will call "configuration-oriented". For this to work, one of the following assumptions must hold. None are pretty, but you MUST pick one to avoid solving how to forward traffic when multiple interfaces are enabled at the same time for a given IP version.

(a) From the perspective of the CE router, the network supports only one type of interface for a given IP version, or

(b) The CE router is configured in advance of any IP configuration to support only one type of interface for a given IP version, or

(c) The CE router goes through an ordered set of configuration attempts in series, each requiring a timeout before moving to the next. Transition-oriented changes after steady-state is reached will require "reboot" to go through the ordered process from scratch.

(d) The CE router chooses one type of interface and shuts down all others based on a predetermined priority when more than one interface with the same IP version is configured. This allows parallel configuration attempts and changes after reaching steady-state, but requires the CE router and network to manage a "flash cut" from one configured interface to the other and may be prone to tricky race-conditions.

The second strategy I will call "forwarding-oriented." In this model, configuration of any WAN interface method at any time is accepted. The CE follows forwarding rules in order to ensure packets make it out the right interface on WAN egress, and liberally accepts packets on WAN ingress. This is "classic multihoming" and should work for any order of planned incremental transition steps, as well as failover and/or transient situations.

After publishing draft-townsley-v6ops-6rd-sunsetting-00, 6204-bis began adopting some of the "forwarding-based" requirements for IPv6, though DS-Lite remained in the "configuration-based" role for IPv4.

Ole and I also just published draft-townsley-troan-ipv6-ce-transitioning-01.txt, which is a general set of IPv6 requirements for multihoming with 6rd-specifics (i.e., it is a "forwarding-based" solution for IPv6). We'll be publishing the same for IPv4 in order to support DS-Lite. Neither are rocket science, but teaching the CE to properly forward when faced with more than one alternative egress interface has been labeled "hard" (though as an interesting data point I have found IPv4 routers that support multiple WAN interfaces at the same time for less than $50). In my mind, the "configuration-oriented" alternative seems at least as hard as the "forwarding-oriented" alternative, is less robust, and certainly less flexible in terms of letting the operator decide its fate in terms of how to perform each transition step.

Again, technical comments are very welcome. Mostly I would like to know if people understand and agree with the basic premise here, and if so whether "configuration-oriented" or "forwarding-oriented" is the best way forward. So far, I think the forwarding-oriented approach wins hands down, but then again I'm used to building routers that have lots of interfaces and operators that ask them to do all sorts of crazy things :-)

Thanks, and Happy Holidays in advance to those who will be celebrating soon,

- Mark
_______________________________________________
v6ops mailing list
<mailto:[e-mail]>[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/v6ops