Subject: [v6ops] Up-leveling Transition Coexistence

From: Mark Townsley <[email-masked]>
Date: Wed, 14 Dec 2011 18:27:20 +0100

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 14 Dec 2011 10:26:21 -0800

On Wed, Dec 14, 2011 at 09:27, Mark Townsley <[email-masked]> wrote:

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

Since you forgot to put your homenet chair hat on, I'll note that homenet
has at least expressed a desire (if not a requirement) to be able to
support multihoming, and for multihoming to function properly, routers need
to be able to do source-based forwarding. So going with the forwarding
strategy will help homenet achieve its goals too.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Dec 2011 09:05:55 +1300

> strategy will help homenet achieve its goals too.

Agreed, and also

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

This overlooks the fact that multiple PA prefixes are by design a normal
way of doing business for a small IPv6 site that wants multihoming.
(Where 'small' means too small to justify a PI prefix.) That's not a bad
assumption for 6204 or even 6204bis, but 6204ter may need to deal with
this, and with the MIF/HOMENET/6RENUM/ipv6-multihoming-without-ipv6nat
scenarios.

    Brian

---

From: Tina TSOU <[email-masked]>
Date: Thu, 15 Dec 2011 22:29:58 +0000

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?

- Tina

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

Folks,

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

---

From: Mark Townsley <[email-masked]>
Date: Fri, 16 Dec 2011 09:26:49 +0100

> this, and with the MIF/HOMENET/6RENUM/ipv6-multihoming-without-ipv6nat

It is not a bad assumption for 6204, as 6204 didn't step into the use of transition mechanisms. 6204 could have even gone as far as defining basic IPv6 via 6rd on a Native IPv4-only network, or IPv4 via DS-Lite on a Native IPv6-only network, without breaking the basic forwarding model. As long as there is only one way for the CE to do IPv4, and only one way to do IPv6, it all works. 

The moment you have the potential for more than one way to deliver IPv6 or more than one way to deliver IPv4 from a given CE, all bets are off. That's precisely what you get when enabling DS-Lite on a Dual-Stack network, or Native IPv6 on a 6rd network. To address these (arguably important) cases,  you either have to force yourself back into single-homed forwarding by one of the four "configuration-oriented" methods I outlined, or go ahead and tackle multihoming via the (I'd argue more robust) forwarding-oriented design. 

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Fri, 16 Dec 2011 09:41:44 +0100

> 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

---

From: "George, Wes" <[email-masked]>
Date: Fri, 16 Dec 2011 08:18:22 -0500

> Sent: Wednesday, December 14, 2011 12:27 PM

[WEG] I think you missed one...
(4) no IPv4 and one Native IPv6 interface

Yes, this is a longer way off, but that's the complete end of the transition, so we shouldn't pretend that the story ends with dual stack, even if it's dual-stack with IPv6 the more native and emphasized protocol. We don't have to come to consensus on *when* it might happen, because it's likely that it'll be different for different networks and applications. I think we can agree that it will, and given that, we should plan for it for completeness when discussing things in these rough categories. The last thing that we want is to have to expend resources maintaining vestigial support for IPv4 not because we actually need it for services anymore, but because we forgot to mention that (and figure out how) we might want to turn it off in the CPE router someday.

For example a transition/technical consideration here is that the CPE router would need to have a hook to know when it's supposed to operate in IPv6-only mode (perhaps simply that it does not receive an IPv4 address when it asks for one, or gets some sort of NACK from the DHCP server) and stop providing IPv4 addresses to its local hosts, stop making queries for A records, etc - or possibly running in some sort of hybrid mode where IPv4 can be used for local services (printers, uPnP, etc) but external IPv4 connection attempts result in the box sending a RST to the sending host, or providing a new flag in DHCP that these addresses are for local connectivity only.

I'd rather consider this now so that we can provide the right guidance up-front for when we need it, rather than having to write YAB (Yet another BIS) to correct the oversight.

Thanks
Wes George

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: Cameron Byrne <[email-masked]>
Date: Fri, 16 Dec 2011 05:45:58 -0800

On Dec 16, 2011 8:18 AM, "George, Wes" <[email-masked]> wrote:
> Yes, this is a longer way off, but that's the complete end of the
transition, so we shouldn't pretend that the story ends with dual stack,
even if it's dual-stack with IPv6 the more native and emphasized protocol.
We don't have to come to consensus on *when* it might happen, because it's
likely that it'll be different for different networks and applications. I
think we can agree that it will, and given that, we should plan for it for
completeness when discussing things in these rough categories. The last
thing that we want is to have to expend resources maintaining vestigial
support for IPv4 not because we actually need it for services anymore, but
because we forgot to mention that (and figure out how) we might want to
turn it off in the CPE router someday.
>
> For example a transition/technical consideration here is that the CPE
router would need to have a hook to know when it's supposed to operate in
IPv6-only mode (perhaps simply that it does not receive an IPv4 address
when it asks for one, or gets some sort of NACK from the DHCP server) and
stop providing IPv4 addresses to its local hosts, stop making queries for A
records, etc - or possibly running in some sort of hybrid mode where IPv4
can be used for local services (printers, uPnP, etc) but external IPv4
connection attempts result in the box sending a RST to the sending host, or
providing a new flag in DHCP that these addresses are for local
connectivity only.
>
> I'd rather consider this now so that we can provide the right guidance
up-front for when we need it, rather than having to write YAB (Yet another
BIS) to correct the oversight.

+1 to all of the above. We must focus on the end-state (single stack v6)
and work backwards from there.

The tactic of taking one step forward from our current broken state has yet
to yield much beyond "yet another band aid "

Cb

> Thanks
> Wes George
>
> 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: Tore Anderson <[email-masked]>
Date: Fri, 16 Dec 2011 15:43:22 +0100

* George, Wes

> (4) no IPv4 and one Native IPv6 interface

Fully agreed. That's where the transition needs to end (and the sooner
the better). If that is not the end state, the so-called «transition»,
well, isn't one.

> [...] or possibly running in some sort of hybrid mode where IPv4 can be
> used for local services (printers, uPnP, etc) but external IPv4
> connection attempts result in the box sending a RST to the sending
> host, or providing a new flag in DHCP that these addresses are for
> local connectivity only.

Wouldn't it in this case be much easier to simply omit the router option
from the CE's DHCPv4 response? Also, use of 169.254/16 could provide an
additional hint that the addresses are for local connectivity only.

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/

---

From: Mark Townsley <[email-masked]>
Date: Fri, 16 Dec 2011 16:36:21 +0100

> (4) no IPv4 and one Native IPv6 interface

Agree, but... 6204-bis currently does not enter the realm of v6-only. I was working within the scope of that document in this email. That's why I prefaced these 3 with:

"...steady-state combinations of "native" and "virtual" (tunneled) dual-stack connectivity methods"

> For example a transition/technical consideration here is that the CPE router would need to have a hook to know when it's supposed to operate in IPv6-only mode (perhaps simply that it does not recei…

I do think "sunsetting IPv4" needs work. It's not going to go away without a fight. 

- Mark

---

From: "George, Wes" <[email-masked]>
Date: Fri, 16 Dec 2011 16:52:48 -0500

> From: Mark Townsley [mailto:[email-masked]]
> Sent: Friday, December 16, 2011 10:36 AM
> To: George, Wes
> Cc: [email-masked] Operations
> Subject: Re: [v6ops] Up-leveling Transition Coexistence
>
> Agree, but... 6204-bis currently does not enter the realm of v6-only. I
> was working within the scope of that document in this email. That's why
> I prefaced these 3 with:
>
[WEG] The scope of this whole discussion is a bit unclear to me, for 2 reasons - I haven't been closely following the 6204-bis mega thread, and I saw you make reference to several new drafts in your original message. It sounded to me like you were talking about abstracting transition coexistence a bit from the discussion of 6204-bis that it's currently mired in, which is why I pointed to this as being missing. I'm not saying that it has to be totally covered in 6204-bis, merely that any serious discussion about IPv4/IPv6 transition and coexistence needs to consider this its end state. I'm open for discussion on what the next step is in that regard, but I'm going to continue pointing at places where IPv6-only is not being considered so that it doesn't get missed in the discussion.

Thanks
Wes George

---

From: Mark Townsley <[email-masked]>
Date: Sat, 17 Dec 2011 10:52:37 +0100

> [WEG] The scope of this whole discussion is a bit unclear to me, for 2 reasons - I haven't been closely following the 6204-bis mega thread, and I saw you make reference to several new drafts in you…

Perfectly reasonable, and you'll get no objection from me that IPv6-only needs to be addressed. The practical corollary of course is that we really know what is going to work and break when we try to turn off IPv4. It's not something many people have done :-)

I'm not sure what the fate of 6204-bis is in terms of the transition coexistence section. A the moment, it seems it will still include 6rd and DS-Lite requirements, but there is really no advice on how to make these work with their Native equivalents as you either have to include multihoming or figure out how to enforce only allowing one egress at a time. For 6rd, that means you can turn on IPv6 service over your IPv4 network, but if you turn on Native IPv6 at the same time 6204-bis is insufficient. For DS-Lite, it's a bit worse because it means that you can turn on IPv4 on an IPv6-only network, but turning on DS-Lite on a Dual-Stack 6204-bis will be insufficient.

Ole and I have tried to capture this problem as well as a proposed solution in our latest revision of:

http://tools.ietf.org/html/draft-townsley-troan-ipv6-ce-transitioning-02

Here, the IPv6 multihoming 6rd requirements seems fairly solid. IMHO, it would be an improvement to include them in 6204-bis, then at least it is a complete solution that allows you to turn on IPv6 with 6rd, then Native IPv6, then turn off 6rd. 

The paint is still dry on the the IPv4 DS-Lite+ model we are proposing. The main point though is that once you bring in a new IPv4 delivery model, you can't just wave your hands and expect it to work alongside the IPv4 that's already there, or wave your hands and expect you can turn off Native IPv4 without thinking it through. 

Please have a read and let us know what you think.

Thanks,

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Sat, 17 Dec 2011 10:53:41 +0100

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

- Mark

---

From: Tina TSOU <[email-masked]>
Date: Sun, 18 Dec 2011 00:34:15 +0000

Mark,

Sent from my iPad

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

Mark,

<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:[email-masked]> [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Mark Townsley
Sent: Wednesday, December 14, 2011 9:27 AM
To: <mailto:[email-masked]> [email-masked]<mailto:[email-masked]> Operations
Subject: [v6ops] Up-leveling Transition Coexistence

Folks,

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

---

From: Wuyts Carl <[email-masked]>
Date: Mon, 19 Dec 2011 08:35:48 +0100

Some feedback on the below, being a CPE vendor for residential market.
First note that, although our main deployment is in the residential CPE market, we're not present in retail, so maybe my view is "spoiled" due to this.

I don't believe in this configuration-oriented approach at all as it is mainly to complicated or not really a possible approach.  There are 4 possibilities listed in this scenario, where we would have to pick one from, but none of them are really suitable I think, for sure not the one where you'd have to run a "couple" of configuration attempts with timeouts etc" or "have to shut down intfs based upon ...".
Although some of these can possibly covered through some scripting, this is nothing really one should force upon a CPE, in fact, to no other IP device either.  Let's stick to standard behavior, threating an IP intf as it should be, not try to enforce some "extra's" on top of them.  An IP intf gets enabled, and can start forwarding traffic if the forwarding is allowed upon it (so routes availabe etc).  If you want to accomplish the below, I think you've to force lots of policy on top of the present CPE's capabilities in this area, so a no-go I'd say.  Please don't mix a residential CPE with a full-blown business router.  Again this seems to be an attempt of enforcing some stuff upon the CPE, to be avoided I'd say (again).

I also see some replies on "what if multiple transition scenario's are being used at the same time, combining DSLite with 4over6 or whatever".  This is of course possible in multi-homed scenario's but again here the same applies.  Let's try to keep normal IP behavior in place, read forwarding-oriented approach, not try to enforce all kind of tricky things.  As our customers are operators, not end-users, dual-homed scenario's are not our main target, but I can't see any added value looking into this "configuration-oriented" approach.

My 2 cents
Regs
Carl

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Townsley
Sent: woensdag 14 december 2011 18:27
To: [email-masked] Operations
Subject: [v6ops] Up-leveling Transition Coexistence

Folks,

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Mon, 19 Dec 2011 09:31:29 +0100

> Although some of these can possibly covered through some scripting, this is nothing really one should force upon a CPE, in fact, to no other IP device either.  Let's stick to standard behavior, thr…

Fully agree that the "configuration-oriented" approach is very problematic. Unfortunately, this was the path that 6204-bis seemed to have been headed down. I hope we're changing that course.

> I also see some replies on "what if multiple transition scenario's are being used at the same time, combining DSLite with 4over6 or whatever".  This is of course possible in multi-homed scenario's…

I think you are saying the "forwarding-oriented" approach is preferred, given the alternative being the "configuration-oriented" approach. However, perhaps you are saying you really want to do "none of the above". 

Problem is, you have to choose one or the other if you are going to support DS-Lite or 6rd. Take your pick. Neither is not an option. 

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Mon, 19 Dec 2011 09:49:48 +0100

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" <[email-masked]> wrote:
> 
>> 
> 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

---

From: Wuyts Carl <[email-masked]>
Date: Mon, 19 Dec 2011 10:05:35 +0100

Sorry, indeed, forwarding preferred over configuration-oriented, if any must be chosen :-)

Carl Wuyts
GCD System Architect Networking
CONNECT DIVISION
[email-masked]
tel.: +32 3 443 65 90

Prins Boudewijnlaan 47  -  2650 Edegem  -  Belgium
Technicolor Delivery Technologies Belgium NV
Registered office (maatschappelijke zetel): Prins Boudewijnlaan 47, 2650 Edegem, Belgium
Company registration number (ondernemingsnummer): 0428837295 - RPR Antwerpen

Help preserve the color of our world - Think before you print.

-----Original Message-----
From: Mark Townsley [mailto:[email-masked]] 
Sent: maandag 19 december 2011 9:31
To: Wuyts Carl
Cc: [email-masked] Operations
Subject: Re: [v6ops] Up-leveling Transition Coexistence

- Mark

---

From: Tina TSOU <[email-masked]>
Date: Wed, 21 Dec 2011 02:16:07 +0000

Mark,
After discussing with co-authors of Light Weight 4over6, I think my question is "how the CPE to distinguish AFTR from TC?". You talks about that for the CPE to select the right interface for multi-homing setting. It won't solve the problem I asked.
If it is not in the scope of draft-townsley-troan-ipv6-ce-transitioning-02, that's fine. Thank you for your help anyway.

-Tina

From: Mark Townsley [mailto:[email-masked]]
Sent: Monday, December 19, 2011 12:50 AM
To: Tina TSOU
Cc: [email-masked] Operations
Subject: Re: [v6ops] Up-leveling Transition Coexistence

Mark,

Sent from my iPad

Mark,

Thank you.

- Mark

- Mark

- Tina

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

Folks,

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

---

From: Mark Townsley <[email-masked]>
Date: Wed, 21 Dec 2011 17:22:48 +0100

On Dec 21, 2011, at 3:16 AM, Tina TSOU wrote:

> Mark,
> After discussing with co-authors of Light Weight 4over6, I think my question is “how the CPE to distinguish AFTR from TC?”. You talks about that for the CPE to select the right interface for multi-homing setting. It won't solve the problem I asked.

Well, the our model should be able to fit 4over6 or anything else out there (otherwise its not nearly as robust as we are saying it is!). If I understand what 4over6 is, the key point to the CE here is that an IPv4 address is assigned by the ISP to the CE over the IPv6 tunnel. In our model, this would enable the NAPT function on that 4over6 virtual interface, and packets would be routed there accordingly. Which packets get there depends on policy-based metrics in the RIB, which could be configured by the user, operator, or simply follow default policy. 

- Mark

> If it is not in the scope of draft-townsley-troan-ipv6-ce-transitioning-02, that’s fine. Thank you for your help anyway.
>  
> -Tina
>

---

From: Tina TSOU <[email-masked]>
Date: Thu, 22 Dec 2011 22:05:36 +0000

In line...

- Tina

From: Mark Townsley [mailto:[email-masked]]
Sent: Wednesday, December 21, 2011 8:23 AM
To: Tina TSOU
Cc: [email-masked] Operations
Subject: Re: [v6ops] Up-leveling Transition Coexistence

Mark,

[Tina] it seems like you are trying to explain how to survive the CPE forwarding when there're both DS-Lite and 4over6, or native IPv4 access.
But our problem is the AFTR/TC discovery.

- Mark

-Tina

From: Mark Townsley [mailto:[email-masked]]
Sent: Monday, December 19, 2011 12:50 AM
To: Tina TSOU
Cc: [email-masked]<mailto:[email-masked]> Operations
Subject: Re: [v6ops] Up-leveling Transition Coexistence

Mark,

Sent from my iPad

Mark,

Thank you.

- Mark

- Mark

- Tina

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

Folks,

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Fri, 23 Dec 2011 13:35:54 +0100

> [Tina] it seems like you are trying to explain how to survive the CPE forwarding when there're both DS-Lite and 4over6, or native IPv4 access.

Yes.

> But our problem is the AFTR/TC discovery.

OK. By "discovery" you mean the tunnel endpoint address for sending traffic to an AFTR or TC? Isn't that simply part of a DHCPv6 option?

- Mark

---

From: Tina TSOU <[email-masked]>
Date: Sat, 24 Dec 2011 05:40:13 +0000

From: Mark Townsley [mailto:[email-masked]]
Sent: Friday, December 23, 2011 4:36 AM
To: Tina TSOU
Cc: [email-masked] Operations
Subject: Re: [v6ops] Up-leveling Transition Coexistence

Yes.

That's what I thought. If this is not in the scope of draft-townsley, that's fine. If it is in the scope of draft-townsley, I was curious about how forwarding-oriented can solve it.

Tina

- Mark