Re: [v6ops] Up-leveling Transition Coexistence

[Mark Townsley <[e-mail]>]

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?

DS-Lite, 4over6, 4rd-U/T/E, dIVI, and Native IPv4, are all methods for delivering IPv4 over some type of transport. Each look like separate interfaces in the NAPT table. When you have more than one active at a time, this is similar in implementation at the CE to a "Dual-WAN" CE router you can buy today.

DS-Lite is a bit special in that as long as the "4over6" feature of it is not enabled, we don't want packets sent over the tunnel to create  NAPT translation entries in the CE. That's a very good thing given that DS-Lite is effectively an unnumbered point to point interface with no ISP-assigned address - i.e., the NAPT entries would be missing a very important bit of information by not having an IPv4 address to translate to :-)

Ole and I have taken a stab at an illustrative model of how this could be implemented, and will be posting it soon. This is all IPv4 technology though, it doesn't really have much to do at all with IPv6 other than most of the tunnels happen to use IPv6 as a transport.

- Mark

> 
> - Tina
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Mark Townsley
> Sent: Wednesday, December 14, 2011 9:27 AM
> To: [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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops