Subject: [v6ops] Feedback on draft-ietf-v6ops-wireline-incremental-ipv6

From: Victor Kuarsingh <[email-masked]>
Date: Tue, 06 Dec 2011 22:09:06 -0500

v6ops group,

To help guide and facilitate feedback, I would like to highlight some of the
discussion points which were made prior and in the last WG meeting (Taipei)
and see where various members of the group sit on a number of subjects to
help improve and guide the document.

1. Document Objective
The document's objective was to provide an operational view as to how to
enable IPv6 by analyzing the main [now] commercial options and show an
incremental way of enabling and improving IPv6 services.  The document also
sets out to explain that not all phases are needed (operator by operator
environment) and calls out some of the main considerations.  The other main
point is that this document is also targeted at "in-servcie" networks which
are IPv4-only today and which need to move to IPv6.  Greenfield is not a
target (which may have very different options and considerations).  This
document is also intended to meet the sprit of the normative referenced
document - draftietf-v6ops-v4v6tran-framework.

2. Updates Since IETF82

The document's text has been improved and made a bit more concise.  I have
also added in more text calling out that not all phases were required
depending on the operator's network conditions.

3. Considered Technologies

Based on previous feedback (pre-IETF82) we added specific explanation for
why NAT64, although a valid technology, was not as viable for in-servie
networks due to the need to support IPv4 devices in the home.  We did not
include many of the other numerous technologies as they are still very much
in discussion.  The point was not to be all things to everybody, but be
valuable to many.

4. Strong Emphasis on IPv6

For obvious reasons there is a strong focus get IPv6 into the network and
optimize the connection over time when possible.

Questions to the Group:

1. Considered Technologies  Are they other technologies to consider are
very important (respondent should be clear why it's so important and should
remember the document's objective  add IPv6, in-service networks, IPv4 is
there now.)
2. Position on IPv4 and IPv6.  Should there be a shift in the document's
tone to be more progressive on movement to IPv6? (I would also ask a
respondent that says yes to this explain how this can be accomplished in a
practical way considering that most services on the Net and in an operators
network are IPv4 now).  We would need to explain how the evolution of tools,
management and other related functions can be moved along and work hand in
hand (since without this an operator has no "service").  I have had some
feedback on this key point and would like to see how others see this point.
Thanks for your feedback,

Regards,

Victor K

---

From: "George, Wes" <[email-masked]>
Date: Wed, 7 Dec 2011 11:02:09 -0500

From: [email-masked] [mailto:[email-masked]] On Behalf Of Victor Kuarsingh

> Position on IPv4 and IPv6. Should there be a shift in the document's tone
> to be more progressive on movement to IPv6?

WEG] I'm reproducing and refining some feedback I've given the authors offline already so that those on-list can agree/disagree.

By the time this document is published as RFCXXXX, I expect that one or more of the planned sequels to World IPv6 Day will have generated a non-trivial deployment in last-mile access, as well as many content providers making the decision to enable IPv6 permanently. Therefore, I disagree with your foundational assertion that "most services/operators are IPv4."
Plenty of IPv6 documents have already been written with that assumption in mind, and IMO it's time to start moving away from that. We should be assuming that IPv6 traffic is likely to be non-trivial on day 1 for those only deploying now, and treat our recommendations and considerations accordingly. We should make it clear that they *are* behind on IPv6 deployment if they haven't started yet, not to browbeat them, but to discuss the ramifications of that delay.
There is a legitimate complaint that SPs and vendors have not taken IPv6 seriously and even when they deploy/implement it, it ends up being a second-class service, either because it's being done using different topology, reduced peering capacity and diversity, on elements that can't scale to "real" levels, it's encapsulated, or the support structure and processes aren't in place yet (supported by a team of 3 people). I think that in a lot of cases, this is being perpetuated by the notion that you can start with "training wheels" on your IPv6 deployment because it isn't carrying enough traffic to matter, and at this point that notion is probably doing more harm than good.

One note of specific feedback on this regard, rather than treating the discussion evenly and saying "avoid using a transition/encaps technology on your primary traffic path..." say something clearer about making sure that your IPv6 traffic path is first-class. That doesn't mean do something to make IPv4 worse, but I think that making IPv6 equivalent or better should be a stated goal.

Second, I think we should tighten the scope of this document to explicitly exclude any consideration of IPv4.
Something equivalent to - "This document makes no recommendation on when (or if) a given network can move away from IPv4. It assumes that the network in question already has a functional IPv4 solution that will coexist with the chosen IPv6 deployment. Further, it does not discuss any methods of IPv4 extension/service continuity, because it is purely focusing on the practical considerations of deploying IPv6 support within an existing network. Other documents exist which discuss and compare options for IPv4 extension technologies in great detail [reference, reference, reference] and this can be evaluated independently of the IPv6 deployment strategy." - it may be that the separation isn't quite that clean, since you may have to note areas where coexistence isn't complete or other interaction considerations, but I think that should be the primary philosophy when determining the scope of any IPv4 discussion in this document.

Put another way, single-stack IPv6 is the end goal, and I don't think that's as outlandish or unreachable as it sounds as a premise for this document. Single-stack IPv6 and dual-stack are not that much different, except for that fact that a single-stack IPv6 network has to ensure that all of its ancillary control-path things (not just data forwarding) are capable of functioning properly without IPv4 configured. Therefore I don't think it's too aggressive to treat this document as a comprehensive recommendation on how to deploy a single-stack IPv6 network, with the acknowledgement that IPv4 may coexist and make it a dual-stack network and nothing (or not much) has to change. This gives the benefit of ensuring that the network itself is ready to move to single-stack whenever there is not an appreciable amount of IPv4 traffic being carried anymore. You could then prioritize the items to IPv6-enable given the assumption that everything except IPv6 forwarding works via the existing IPv4 network, meaning that the network doesn't have to go single-stack all at once.

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: Wed, 7 Dec 2011 08:18:32 -0800

On Dec 7, 2011 8:02 AM, "George, Wes" <[email-masked]> wrote:
> WEG] I'm reproducing and refining some feedback I've given the authors
offline already so that those on-list can agree/disagree.
>
> By the time this document is published as RFCXXXX, I expect that one or
more of the planned sequels to World IPv6 Day will have generated a
non-trivial deployment in last-mile access, as well as many content
providers making the decision to enable IPv6 permanently. Therefore, I
disagree with your foundational assertion that "most services/operators are
IPv4."
> Plenty of IPv6 documents have already been written with that assumption
in mind, and IMO it's time to start moving away from that. We should be
assuming that IPv6 traffic is likely to be non-trivial on day 1 for those
only deploying now, and treat our recommendations and considerations
accordingly. We should make it clear that they *are* behind on IPv6
deployment if they haven't started yet, not to browbeat them, but to
discuss the ramifications of that delay.
> There is a legitimate complaint that SPs and vendors have not taken IPv6
seriously and even when they deploy/implement it, it ends up being a
second-class service, either because it's being done using different
topology, reduced peering capacity and diversity, on elements that can't
scale to "real" levels, it's encapsulated, or the support structure and
processes aren't in place yet (supported by a team of 3 people). I think
that in a lot of cases, this is being perpetuated by the notion that you
can start with "training wheels" on your IPv6 deployment because it isn't
carrying enough traffic to matter, and at this point that notion is
probably doing more harm than good.
>
> One note of specific feedback on this regard, rather than treating the
discussion evenly and saying "avoid using a transition/encaps technology on
your primary traffic path..." say something clearer about making sure that
your IPv6 traffic path is first-class. That doesn't mean do something to
make IPv4 worse, but I think that making IPv6 equivalent or better should
be a stated goal.

+1 to non-trivial potential day one loads and treating the traffic first
class.

> Second, I think we should tighten the scope of this document to
explicitly exclude any consideration of IPv4.
> Something equivalent to - "This document makes no recommendation on when
(or if) a given network can move away from IPv4. It assumes that the
network in question already has a functional IPv4 solution that will
coexist with the chosen IPv6 deployment. Further, it does not discuss any
methods of IPv4 extension/service continuity, because it is purely focusing
on the practical considerations of deploying IPv6 support within an
existing network. Other documents exist which discuss and compare options
for IPv4 extension technologies in great detail [reference, reference,
reference] and this can be evaluated independently of the IPv6 deployment
strategy." - it may be that the separation isn't quite that clean, since
you may have to note areas where coexistence isn't complete or other
interaction considerations, but I think that should be the primary
philosophy when determining the scope of any IPv4 discussion in this
document.
>
> Put another way, single-stack IPv6 is the end goal, and I don't think
that's as outlandish or unreachable as it sounds as a premise for this
document. Single-stack IPv6 and dual-stack are not that much different,
except for that fact that a single-stack IPv6 network has to ensure that
all of its ancillary control-path things (not just data forwarding) are
capable of functioning properly without IPv4 configured. Therefore I don't
think it's too aggressive to treat this document as a comprehensive
recommendation on how to deploy a single-stack IPv6 network, with the
acknowledgement that IPv4 may coexist and make it a dual-stack network and
nothing (or not much) has to change. This gives the benefit of ensuring
that the network itself is ready to move to single-stack whenever there is
not an appreciable amount of IPv4 traffic being carried anymore. You could
then prioritize the items to IPv6-enable given the assumption that
everything except IPv6 forwarding works via the existin
>  g IPv4 network, meaning that the network doesn't have to go single-stack
all at once.

+1 for clearly articulating single stack v6 as the attainable end state
goal.

Cb

> 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.
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 7 Dec 2011 11:44:36 -0500

Wes/Cameron,

To be clear, we can we define what we mean by "single stack" IPv6.  In my
mind this means things like DS-Lite and not NAT64 (as the latter would
define a IPv6 only home network which I don't think is feasible in the
mid-term future).

I am assuming that NAT46 (home gateway) is not in the cards since I see not
drafts or RFCs on that.  Hence NAT64 assumes all IPv6 endpoint/network (to
round out my previous statement).

Further to this, then we would need to beef up the considerations for IPv6
single stack since it's vast.

regards,

Victor K

On Wed, Dec 7, 2011 at 11:18 AM, Cameron Byrne <[email-masked]> wrote:

> >  g IPv4 network, meaning that the network doesn't have to go
> single-stack all at once.
> >
>

---

From: "George, Wes" <[email-masked]>
Date: Wed, 7 Dec 2011 12:20:22 -0500

From: Victor Kuarsingh [mailto:[email-masked]]

To be clear, we can we define what we mean by "single stack" IPv6.  In my mind this means things like DS-Lite and not NAT64 (as the latter would define a IPv6 only home network which I don't think is feasible in the mid-term future).

I am assuming that NAT46 (home gateway) is not in the cards since I see not drafts or RFCs on that.  Hence NAT64 assumes all IPv6 endpoint/network (to round out my previous statement).
[WEG] I think you're conflating a few things that shouldn't be and that's creating confusion. I don't mean single-stack + transition technologies, so let's put DSLite, et. al aside for the moment. At its simplest, what I'm referring to as single-stack IPv6  is a network that is capable of accepting IPv6 packets at one end and pushing them out on the other end *without* requiring IPv4 to serve as a transport layer or control plane (via tunnels/translation/veg-o-matic) anywhere in the middle. That has no bearing on whether there that network *also* is capable of accepting IPv4 packets at one end and pushing them out at the other, nor what method it uses to accomplish moving IPv4 traffic around.
In other words, this is the highest exponent of the "ships in the night" metaphor that is used to describe IPv4 and IPv6 coexistence. A single-stack IPv6 *network* enables devices and endpoints that speak IPv6 to do so. It does not do anything with IPv4. If there is a need to support IPv4 (and I'm agreeing that there is), then the network would be considered dual-stack, but the method for accomplishing such is largely orthogonal to the IPv6 implementation. Yes, something like DSLite might make sense since you would be deploying an IPv6 infrastructure, but since your doc is assuming that this is not a Greenfield deployment, it's easier for us to simply assume that the IPv4 support is black-box. It's there or it's not, it has enough addresses or it doesn't, but for the purposes of this discussion, we simply don't care. We'd be explaining how to deploy IPv6 such that it'll work by itself, with the idea that eventually you might want to turn off IPv4, and you'd rather not have to re-architect your management, monitoring, and control plane to make that work. Making IPv4 work and making IPv6 work are essentially two variables in the same equation. Your current draft tries to solve for X and Y. I'm recommending that you only solve for Y, since multiple people have already solved for X, and there's not necessarily a dependency between the two. Similarly, I don't think that you need to expend a lot of time discussing/comparing different methods to jump across IPv4-only islands (6rd, etc) other than to note that they exist and refer to other existing comparisons of those transition and tunneling technologies. Native IPv6 (or as close as you can get) should be the goal, but acknowledging that it may not be possible to do it that purely at first can make the document more pragmatic without moving towards recommending that as an end-state solution.

Further to this, then we would need to beef up the considerations for IPv6 single stack since it's vast.
[WEG] That's sorta my point - there's not a lot of info out there on how to truly build a network that isn't reliant on IPv4, because pretty much all of them (with a few notable exceptions) are some flavor of dual-stack and can therefore rely on IPv4 to fill in the gaps where IPv6 doesn't "do that" for some values of do and that. We can probably build on some existing info, but I am not aware of anything that really covers all of the things that an ISP must consider to really dual-stack their *network* and not simply the forwarding path.
Hope that helps...
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: Wed, 7 Dec 2011 11:04:58 -0800

> round out my previous statement).

NAT46 in the home  gateway draft
http://tools.ietf.org/html/draft-mawatari-softwire-464xlat-02

>> > deployment if they haven't started yet, not to browbeat them, but to discuss
>> > the ramifications of that delay.
>> > that in a lot of cases, this is being perpetuated by the notion that you can
>> > start with "training wheels" on your IPv6 deployment because it isn't
>> > carrying enough traffic to matter, and at this point that notion is probably
>> > doing more harm than good.
>> >
>> > make IPv4 worse, but I think that making IPv6 equivalent or better should be
>> > a stated goal.
>> >
>>
>> > (or if) a given network can move away from IPv4. It assumes that the network
>> > in question already has a functional IPv4 solution that will coexist with
>> > the chosen IPv6 deployment. Further, it does not discuss any methods of IPv4
>> > extension/service continuity, because it is purely focusing on the practical
>> > considerations of deploying IPv6 support within an existing network. Other
>> > documents exist which discuss and compare options for IPv4 extension
>> > technologies in great detail [reference, reference, reference] and this can
>> > be evaluated independently of the IPv6 deployment strategy." - it may be
>> > that the separation isn't quite that clean, since you may have to note areas
>> > where coexistence isn't complete or other interaction considerations, but I
>> > think that should be the primary philosophy when determining the scope of
>> > any IPv4 discussion in this document.
>> >
>> > except for that fact that a single-stack IPv6 network has to ensure that all
>> > of its ancillary control-path things (not just data forwarding) are capable
>> > of functioning properly without IPv4 configured. Therefore I don't think
>> > it's too aggressive to treat this document as a comprehensive recommendation
>> > on how to deploy a single-stack IPv6 network, with the acknowledgement that
>> > IPv4 may coexist and make it a dual-stack network and nothing (or not much)
>> > has to change. This gives the benefit of ensuring that the network itself is
>> > ready to move to single-stack whenever there is not an appreciable amount of
>> > IPv4 traffic being carried anymore. You could then prioritize the items to
>> > IPv6-enable given the assumption that everything except IPv6 forwarding
>> > works via the existin
>> > 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: Victor Kuarsingh <[email-masked]>
Date: Wed, 7 Dec 2011 14:07:59 -0500

Wes,

On Wed, Dec 7, 2011 at 12:20 PM, George, Wes <[email-masked]>wrote:

>    *From:* Victor Kuarsingh [mailto:[email-masked]] ****
>
>
> I am assuming that NAT46 (home gateway) is not in the cards since I see
> not drafts or RFCs on that.  Hence NAT64 assumes all IPv6 endpoint/network
> (to round out my previous statement).**
>
> *[WEG] I think you’re conflating a few things that shouldn’t be and
> that’s creating confusion. I don’t mean single-stack + transition
> technologies, so let’s put DSLite, et. al aside for the moment. At its
> simplest, what I’m referring to as single-stack IPv6  is a network that is
> capable of accepting IPv6 packets at one end and pushing them out on the
> other end *without* requiring IPv4 to serve as a transport layer or control
> plane (via tunnels/translation/veg-o-matic) anywhere in the middle. That
> has no bearing on whether there that network *also* is capable of accepting
> IPv4 packets at one end and pushing them out at the other, nor what method
> it uses to accomplish moving IPv4 traffic around. *
>
Ok, I understand what you are saying.. makes sense. I agree with your
statements.

> **
>
> *In other words, this is the highest exponent of the “ships in the night”
> metaphor that is used to describe IPv4 and IPv6 coexistence. A single-stack
> IPv6 *network* enables devices and endpoints that speak IPv6 to do so. It
> does not do anything with IPv4. If there is a need to support IPv4 (and I’m
> agreeing that there is), then the network would be considered dual-stack,
> but the method for accomplishing such is largely orthogonal to the IPv6
> implementation. Yes, something like DSLite might make sense since you would
> be deploying an IPv6 infrastructure, but since your doc is assuming that
> this is not a Greenfield deployment, it’s easier for us to simply assume
> that the IPv4 support is black-box. It’s there or it’s not, it has enough
> addresses or it doesn’t, but for the purposes of this discussion, we simply
> don’t care. We’d be explaining how to deploy IPv6 such that it’ll work by
> itself, with the idea that eventually you might want to turn off IPv4, and
> you’d rather not have to re-architect your management, monitoring, and
> control plane to make that work. Making IPv4 work and making IPv6 work are
> essentially two variables in the same equation. Your current draft tries to
> solve for X and Y. I’m recommending that you only solve for Y, since
> multiple people have already solved for X, and there’s not necessarily a
> dependency between the two. Similarly, I don’t think that you need to
> expend a lot of time discussing/comparing different methods to jump across
> IPv4-only islands (6rd, etc) other than to note that they exist and refer
> to other existing comparisons of those transition and tunneling
> technologies. Native IPv6 (or as close as you can get) should be the goal,
> but acknowledging that it may not be possible to do it that purely at first
> can make the document more pragmatic without moving towards recommending
> that as an end-state solution.*
>

What would you propose we diminish?  Would this then devalue it's
applicability for some Wireline provides who will depend on IPv4 over IPv6
(6rd) for the next while (i.e. Access Network Constraints?).

If so, could we point them (at least) to the place where they can seek this
information?  (i.e. other drafts/RFCs which discuss such points including
deployment considerations).

Victor K

**

>
> ------------------------------

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 7 Dec 2011 14:11:46 -0500

Cameron,

On Wed, Dec 7, 2011 at 2:04 PM, Cameron Byrne <[email-masked]> wrote:

> not
Thanks for the reference.  Will review.  We have previously stated that we
wanted to keep the technologies in consideration to running code with
commercial availability.  Where is this with respect to that type of
position?

Victor K

> >> > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >> > Of Victor Kuarsingh
> >> >
> >> > > Questions to the Group:
> >> >
> network

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Wed, 7 Dec 2011 13:18:57 -0600

RFC 6204 and rfc6204bis for the IETF IPv6 CE router document could not
get consensus to add NAT64 or NAT46 to the CE router.    Alain may
remember when NAT64 was discussed in v6ops at a past IETF during the
IPv6 CE router presentation.

Hemant

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Victor Kuarsingh
Sent: Wednesday, December 07, 2011 2:12 PM
To: Cameron Byrne
Cc: [email-masked]
Subject: Re: [v6ops] Feedback on
draft-ietf-v6ops-wireline-incremental-ipv6

Cameron,

On Wed, Dec 7, 2011 at 2:04 PM, Cameron Byrne <[email-masked]>
wrote:

Thanks for the reference.  Will review.  We have previously stated that
we wanted to keep the technologies in consideration to running code with
commercial availability.  Where is this with respect to that type of
position?

Victor K

	>> > From: [email-masked]
[mailto:[email-masked]] On Behalf
	>> > Of Victor Kuarsingh
	>> >
	>> > > Questions to the Group:
	>> >
	>> > > Position on IPv4 and IPv6. Should there be a shift in the
document's
	>> > > tone

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 7 Dec 2011 11:21:52 -0800

> commercial availability.  Where is this with respect to that type of

There is running code for home gatetway NAT46 from NEC and the Nokia
N900 does NAT46 as well.

So, running code is there.  Have a look at
https://sites.google.com/site/tmoipv6/82nd_IETF_Softwire_464XLAT.pdf

CB

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 7 Dec 2011 15:54:21 -0600

Hi Victor,

For NAT64, the host need not be single stack IPv6, it could have IPv4
stack but simply not used.
This is what happens when you connect to IPv6-only ssid in IETF
meetings with Windows 7 PC or with smart phones with iOS or Android.

Regards,

Behcet

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 07 Dec 2011 21:08:02 -0500

Behcet,

>meetings with Windows 7 PC or with smart phones with iOS or Android.

I agree that a given device in the home can be IPv6 single stack, but the
overall home would need IPv4 of some form to service the TVs (with IP),
NAS, Printers, Older OSs, Older Security equipment etc.

This particular draft has a focus on wireline.  Some use cases would
include a directly attached PC which would at times be Win7/Vista, MACOSX
sporting IPv6 capabilities (I cannot guarantee that all the apps will
comply with IPv6 - the general computing world is hard to control and
there are so many applications that customers will use... Not sure how
confident I will be that all of them would support IPv6 for a while - some
may disagree).  Lorenzo brought this up in Taipei as a point of discussion.

So on the NAT46 side, what is the likely hood we will see this in actual
retail and OEM products soon?  I know that 6RD and DS-Lite is now out
there.. I have not seen NAT46 personally (although it has been highlighted
to me that there are some products out..).  Availability of these in the
mass market is a key consideration for technologies to include (given the
operator focus I was trying to achieve here).  I think a practical,
attainable result is a benefit to operators here.

If we have consensus in the WG that NAT46 with single stack IPv6 on WAN is
a valid option for the currently labelled phase 3, we can add it in as an
option.  But, as noted to Wes, we would need to expand the considerations
section (which we would likely do anyway if we put more focus on the IPv6
single stack [on WAN] result).

Sorry, talked to a few points here...

Victor K

>>> > To be clear, we can we define what we mean by "single stack" IPv6.
>>>In
>>> > my
>>> > drafts or RFCs on that.  Hence NAT64 assumes all IPv6
>>>endpoint/network
>>> > (to
>>we
>>> >> > By the time this document is published as RFCXXXX, I expect that
>>>one
>>> >> > or
>>> >> > providers making the decision to enable IPv6 permanently.
>>>Therefore,
>>> >> > I
>>> >> > in mind, and IMO it's time to start moving away from that. We
>>>should
>>> >> > be
>>> >> > assuming that IPv6 traffic is likely to be non-trivial on day 1
>>>for
>>> >> > those
>>> >> > There is a legitimate complaint that SPs and vendors have not
>>>taken
>>> >> > IPv6
>>> >> > scale to "real" levels, it's encapsulated, or the support
>>>structure
>>> >> > and
>>> >> > that in a lot of cases, this is being perpetuated by the notion
>>>that
>>> >> > you can
>>> >> > your primary traffic path..." say something clearer about making
>>>sure
>>> >> > that
>>> >> > your IPv6 traffic path is first-class. That doesn't mean do
>>>something
>>> >> > to
>>> >> > Something equivalent to - "This document makes no recommendation
>>>on
>>> >> > when
>>> >> > in question already has a functional IPv4 solution that will
>>>coexist
>>> >> > with
>>> >> > the chosen IPv6 deployment. Further, it does not discuss any
>>>methods
>>> >> > of IPv4
>>> >> > considerations of deploying IPv6 support within an existing
>>>network.
>>> >> > Other
>>> >> > be evaluated independently of the IPv6 deployment strategy." - it
>>>may
>>> >> > be
>>> >> > where coexistence isn't complete or other interaction
>>>considerations,
>>> >> > but I
>>> >> > except for that fact that a single-stack IPv6 network has to
>>>ensure
>>> >> > that all
>>> >> > of its ancillary control-path things (not just data forwarding)
>>>are
>>> >> > capable
>>> >> > IPv4 may coexist and make it a dual-stack network and nothing (or
>>>not
>>> >> > much)
>>> >> > 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
>>> >> > sender immediately and permanently delete the original and any
>>>copy
>>> >> > of this
>>> >> > E-mail and any printout.

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 8 Dec 2011 10:37:11 -0600

Hi Victor,

I would go with whatever Cameron says.

Regards,

Behcet