Re: [v6ops] Up-leveling Transition Coexistence

[Mark Townsley <[e-mail]>]

On Dec 18, 2011, at 1:34 AM, Tina TSOU wrote:

> Mark,
> 
> Sent from my iPad
> 
> On Dec 17, 2011, at 1:53 AM, "Mark Townsley" <[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
> I read this draft, it is well written.

Thank you.

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

It is assumed the CE naturally knows which interface types it supports because it had to implement them. The "forwarding-oriented" model followed in the document assumes that any can be configured at any time. If the CE supports 4over6, it will fit that into the policy table based on the main principles we outline in the draft. The example table is just that, an example of some technologies available today based on a set of base principles. If we agree on the principles, I think we can classify just about any new technology that we have now or comes along. In the case of 4over6, since the default policy we proposed ranks use of IPv6 transport very high, 4over6 would also be weighted very high. 

In terms of 6204-bis, we would only need to "rank" DS-Lite vs. Native IPv4. Based on the principles in the draft, the use of IPv6 as a transport would place DS-lite on a preferred path vs. Native IPv4. So, when DS-Lite comes up, if Native IPv4 remains, new NAPT entries appear in the AFTR, while existing local NAPT entries time out or shut down naturally. It should be fairly seamless to the user, and allows for active failover as well in case the DS-Lite tunnel goes down for whatever reason. 

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

The policy is essentially a global preference in terms of v6 transport and NAPT state boiled down to a single point of default configuration. Follow the defaults, and there will be no need for CLI or otherwise. If you want to override the defaults, there is a single place to do so. 

- Mark


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