George, Wes
2015-04-09 15:20:26 UTC
I think you mean "it is *not* feasible" in 3.4
Generally, I think updates to the transition guidance are somewhat useful,
at least acknowledging that due to the limited amount of IPv4 address
space available, the notion of continued parallel support for IPv4 such
that you can provide truly native dual-stack is going to become
increasingly difficult without one or more life-support options. We're not
here to judge the presence of those life-support options as good, bad, or
indifferent as much as we are to acknowledge that reality.
I know that I have given guidance in reviews of several recent documents
and given other presentations to socialize the idea that IPv6-only isn't
an all-or-nothing thing, and that some services and devices can move there
much quicker for various reasons, such that you may end up with islands or
certain services that are no longer dependent on IPv4 long before you can
truly turn it off completely. I've also drawn the parallel to the SNA to
IP transition, where people installed gateways that allowed the portion of
the network that supported legacy SNA to be very small (i.e. Right in
front of the offending mainframe) and the rest of the network, including
all remote hosts transition to IP. I see a similar thing happening with
some legacy IPv4-only things, where a specific ALG is deployed to enable
it to speak IPv6 so that you can have IPv6-only hosts access it without
having to do wider IPv6<-> IPv4 transition or deploy IPv4 to a bunch of
hosts solely to support that application.
That said, I'm not sure whether this draft has a lot new to say when
considered with recent documents like Enterprise Incremental (7381), and I
think it'd be more useful to consider something that has more limited
scope, and only discusses the transition to IPv6-only in greater detail.
Thanks,
Wes
Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------
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.
Generally, I think updates to the transition guidance are somewhat useful,
at least acknowledging that due to the limited amount of IPv4 address
space available, the notion of continued parallel support for IPv4 such
that you can provide truly native dual-stack is going to become
increasingly difficult without one or more life-support options. We're not
here to judge the presence of those life-support options as good, bad, or
indifferent as much as we are to acknowledge that reality.
I know that I have given guidance in reviews of several recent documents
and given other presentations to socialize the idea that IPv6-only isn't
an all-or-nothing thing, and that some services and devices can move there
much quicker for various reasons, such that you may end up with islands or
certain services that are no longer dependent on IPv4 long before you can
truly turn it off completely. I've also drawn the parallel to the SNA to
IP transition, where people installed gateways that allowed the portion of
the network that supported legacy SNA to be very small (i.e. Right in
front of the offending mainframe) and the rest of the network, including
all remote hosts transition to IP. I see a similar thing happening with
some legacy IPv4-only things, where a specific ALG is deployed to enable
it to speak IPv6 so that you can have IPv6-only hosts access it without
having to do wider IPv6<-> IPv4 transition or deploy IPv4 to a bunch of
hosts solely to support that application.
That said, I'm not sure whether this draft has a lot new to say when
considered with recent documents like Enterprise Incremental (7381), and I
think it'd be more useful to consider something that has more limited
scope, and only discusses the transition to IPv6-only in greater detail.
Thanks,
Wes
Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------
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.