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

[Mark Townsley <[e-mail]>]

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. 

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