Re: [Pppext] [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG?

[Cameron Byrne <[e-mail]>]

On Jun 17, 2011 6:22 AM, "Mark Townsley" <[e-mail]> wrote:
>
>
> Technically, this approach is naturally feasible as PPP was designed back
when short-lived connectivity was commonplace. There is one crucial
difference though in that you will be exercising PPP stacks in a way that is
not common by tearing down and bringing up IPCP while not doing so with LCP.
According to all the RFCs this should work just fine, but my intuition is
that some PPP stacks will be forced into new code paths that have never been
exercised in this manner with the expectation of it being the normal desired
behavior.  You can surely find a set of clients where this will work, but it
probably will not across the entire gamut of deployed PPP today.
>
> Applications may not be all that forgiving to IPv4 coming and going
either, e.g., I have a popular mail client that has recently taken to
crashing when I switch from wired to wireless and get a different IP address
in the process. Some of the IM connections I keep up recover quickly to IP
changes, others do not. The IETF has a whole WG (DNA) dedicated to this
tricky behavior of an IP address coming and going - it's not always easy, in
particular when the link-layer is not giving your IP stack any up/down
notification, which I believe by definition is what your proposal requires
from the very start.
>
> Finally, devices are moving towards a "cloud connected" mode of operation.
In IPv4, there is essentially no end-to-end reachability, so modern
applications are moving toward persistent, long-lived, connections in order
to achieve this.  I suspect you'll see a noticeable uptick in reliance upon
such persistent, long-lived, IPv4 connections as Apple's Lion and iOS 5
software is rolled out later this year. Both have integration of the free
"iCloud" services, and have replaced the USB cord for device synchronization
with a persistent network connection. It's not just Apple though, the same
trend is forming across the industry.
>

I believe the motivation is to send a clear signal and path for cloud
service providers that ipv6 is the only sustainable way forward.  I support
this work as legitimate technique to avoid or defer cgn.

It is the cloud long lived sessions that pose the most challenge for cgn.

I would love for this work to be the foundation for similar work in 3gpp.

Granted, a testing effort is always required for any new approach.

Cb

> So, my fear is that by the time you have built TDM into IPv4 across your
user base, it will have required at the very least a grand testing effort
and at the same time your users may well have changed their behavior to make
it unworkable anyway. I as much as anyone would hope that all these new
persistent connections would run over IPv6 if available, but that is of
course the exception not the rule for the time being as well.
>
> - Mark
>
>
> On Jun 14, 2011, at 6:45 PM, <[e-mail]> <
[e-mail]> wrote:
>
> > Hi folks,
> >
> > right in time before the next IETF in Quebec, we would like to come up
again with our Internet Draft
> > "On demand IPv4 address provisioning in Dual-Stack PPP deployment"
> > in order to gather further feedback from the WG.
> > During our presentation in Prague I got several remarks and questions
> > and from my understanding there has been some interest in the approach
we describe in this I-D.
> > Regarding the questions I want to focus on the following two and will
try to answer them once more:
> >
> > - Use case:
> > In general we see this mechanism applicable for all Dual-Stack PPP
network scenarios allthrough we focussed our presentation for illustrative
reasons on routed gateways that may be provided by the Access Network
provider.
> > In principle as more IPv4 addresses can be saved, as more services are
IPv6 enabled
> > (especially those which require always-on connectivity (e.g. VoIP, mail,
update services)) .
> > The PPP protocol has not to be changed in order to achieve the needed
functionality -
> > the described behaviour (of independently releasing and
> > refreshing the IPv4 context within a Dual-Stack PPP session)
> > is already inherently covered by the existing PPP spec and also
mentioned as requirements for
> > CPEs (see RFC 6204 - WLL-3).
> >
> > - Efficiency of the mechanism:
> > In principle we assume (with ongoing IPv6 deployment) that it is
possible to save
> > after one year of roll-out of the described mechanism about 3%,
> > after two years about 8%,
> > and after three years up to 13% of the provisioned IPv4 addresses.
> > After 8 years 70% of the IPv4 addresses can be "re-cycled" according to
our model calculations.
> > (You will find more details here:
> > "
http://www.ix-konferenz.de/getfoldat.php?vid=1638&t=application/pdf&thema=Effizienzabschätzung
"
> > (please copy the whole text between the exclamation marks in the address
line of you browser).)
> >
> >
> > We plan to come up with a 01 version of the I-D and would that's why
like to gather more feedback from the WG regarding the possible open issues
(e.g. what has to be described in more detail, ), unanswered questions or
any other useful hints how to progress with this work/I-D.
> > And of course we are also interested in your opinion if this work should
be done within the Intarea WG or if other WGs (PPPEXT?) may be more
appropriate.
> >
> >
> > Thanks and kind regards
> >
> > KARSTEN Fleischhauer
> > _______________________________________________
> > Int-area mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/int-area
>
> _______________________________________________
> Int-area mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/int-area