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

Technically, this approach is naturally feasible as PPP was designed back w=
hen short-lived connectivity was commonplace. There is one crucial differen=
ce though in that you will be exercising PPP stacks in a way that is not co=
mmon by tearing down and bringing up IPCP while not doing so with LCP. Acco=
rding 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 exe=
rcised in this manner with the expectation of it being the normal desired b=
ehavior.  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 whe=
n I switch from wired to wireless and get a different IP address in the pro=
cess. Some of the IM connections I keep up recover quickly to IP changes, o=
thers do not. The IETF has a whole WG (DNA) dedicated to this tricky behavi=
or 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, w=
hich I believe by definition is what your proposal requires from the very s=
tart.

Finally, devices are moving towards a "cloud connected" mode of operation. =
In IPv4, there is essentially no end-to-end reachability, so modern applica=
tions are moving toward persistent, long-lived, connections in order to ach=
ieve 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 i=
s forming across the industry. =


So, my fear is that by the time you have built TDM into IPv4 across your us=
er 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 i=
t unworkable anyway. I as much as anyone would hope that all these new pers=
istent 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, <[email protected]> <K.Fleischhauer@te=
lekom.de> wrote:

> Hi folks,
> =

> right in time before the next IETF in Quebec, we would like to come up ag=
ain 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 networ=
k scenarios allthrough we focussed our presentation for illustrative reason=
s 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 IP=
v6 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 fun=
ctionality -
> 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 o=
ur model calculations.
> (You will find more details here:
> "http://www.ix-konferenz.de/getfoldat.php?vid=3D1638&t=3Dapplication/pdf&=
thema=3DEffizienzabsch=E4tzung"
> (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 appropr=
iate.
> =

> =

> Thanks and kind regards
> =

> KARSTEN Fleischhauer
> _______________________________________________
> Int-area mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/int-area