Re: IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG?
Cameron Byrne <[email protected]> Fri, 17 Jun 2011 07:24:39 -0700
| Newsgroups | gmane.ietf.int,gmane.ietf.pppext |
|---|---|
| Message-ID | <[email protected]> |
--===============4457342280947137932== Content-Type: multipart/alternative; boundary=0016e6dee70f57527f04a5e92512 --0016e6dee70f57527f04a5e92512 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Jun 17, 2011 6:22 AM, "Mark Townsley" <[email protected]> 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 i= s 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 bee= n exercised in this manner with the expectation of it being the normal desire= d behavior. You can surely find a set of clients where this will work, but i= t 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 addres= s 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, i= n 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 synchronizatio= n 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 mak= e 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, <[email protected]> < [email protected]> 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=3D1638&t=3Dapplication/pdf&the= ma=3DEffizienzabsch=E4tzung " > > (please copy the whole text between the exclamation marks in the addres= s 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 shoul= d 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/int-area > > _______________________________________________ > Int-area mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/int-area --0016e6dee70f57527f04a5e92512 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <p><br> On Jun 17, 2011 6:22 AM, "Mark Townsley" <<a href=3D"mailto:ma= [email protected]">[email protected]</a>> wrote:<br> ><br> ><br> > Technically, this approach is naturally feasible as PPP was designed b= ack when short-lived connectivity was commonplace. There is one crucial dif= ference though in that you will be exercising PPP stacks in a way that is n= ot 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 bee= n exercised in this manner with the expectation of it being the normal desi= red behavior. =A0You can surely find a set of clients where this will work,= but it probably will not across the entire gamut of deployed PPP today.<br= > ><br> > Applications may not be all that forgiving to IPv4 coming and going ei= ther, e.g., I have a popular mail client that has recently taken to crashin= g when I switch from wired to wireless and get a different IP address in th= e process. Some of the IM connections I keep up recover quickly to IP chang= es, others do not. The IETF has a whole WG (DNA) dedicated to this tricky b= ehavior of an IP address coming and going - it's not always easy, in pa= rticular when the link-layer is not giving your IP stack any up/down notifi= cation, which I believe by definition is what your proposal requires from t= he very start.<br> ><br> > 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. =A0I suspect you'll see a noticeable uptick i= n reliance upon such persistent, long-lived, IPv4 connections as Apple'= s Lion and iOS 5 software is rolled out later this year. Both have integrat= ion 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.<br> ></p> <p>I believe the motivation is to send a clear signal and path for cloud se= rvice providers that ipv6 is the only sustainable way forward.=A0 I support= this work as legitimate technique to avoid or defer cgn.</p> <p>It is the cloud long lived sessions that pose the most challenge for cgn= . </p> <p>I would love for this work to be the foundation for similar work in 3gpp= .<br></p> <p>Granted, a testing effort is always required for any new approach.</p> <p>Cb</p> <p>> 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 ef= fort and at the same time your users may well have changed their behavior t= o 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.<br> ><br> > - Mark<br> ><br> ><br> > On Jun 14, 2011, at 6:45 PM, <<a href=3D"mailto:K.Fleischhauer@tele= kom.de">[email protected]</a>> <<a href=3D"mailto:K.Fleischha= [email protected]">[email protected]</a>> wrote:<br> ><br> > > Hi folks,<br> > ><br> > > right in time before the next IETF in Quebec, we would like to co= me up again with our Internet Draft<br> > > "On demand IPv4 address provisioning in Dual-Stack PPP deplo= yment"<br> > > in order to gather further feedback from the WG.<br> > > During our presentation in Prague I got several remarks and quest= ions<br> > > and from my understanding there has been some interest in the app= roach we describe in this I-D.<br> > > Regarding the questions I want to focus on the following two and = will try to answer them once more:<br> > ><br> > > - Use case:<br> > > In general we see this mechanism applicable for all Dual-Stack PP= P network scenarios allthrough we focussed our presentation for illustrativ= e reasons on routed gateways that may be provided by the Access Network pro= vider.<br> > > In principle as more IPv4 addresses can be saved, as more service= s are IPv6 enabled<br> > > (especially those which require always-on connectivity (e.g. VoIP= , mail, update services)) .<br> > > The PPP protocol has not to be changed in order to achieve the ne= eded functionality -<br> > > the described behaviour (of independently releasing and<br> > > refreshing the IPv4 context within a Dual-Stack PPP session)<br> > > is already inherently covered by the existing PPP spec and also m= entioned as requirements for<br> > > CPEs (see RFC 6204 - WLL-3).<br> > ><br> > > - Efficiency of the mechanism:<br> > > In principle we assume (with ongoing IPv6 deployment) that it is = possible to save<br> > > after one year of roll-out of the described mechanism about 3%,<b= r> > > after two years about 8%,<br> > > and after three years up to 13% of the provisioned IPv4 addresses= .<br> > > After 8 years 70% of the IPv4 addresses can be "re-cycled&qu= ot; according to our model calculations.<br> > > (You will find more details here:<br> > > "<a href=3D"http://www.ix-konferenz.de/getfoldat.php?vid=3D1= 638&t=3Dapplication/pdf&thema=3DEffizienzabsch%C3%A4tzung">http://w= ww.ix-konferenz.de/getfoldat.php?vid=3D1638&t=3Dapplication/pdf&the= ma=3DEffizienzabsch=E4tzung</a>"<br> > > (please copy the whole text between the exclamation marks in the = address line of you browser).)<br> > ><br> > ><br> > > We plan to come up with a 01 version of the I-D and would that= 9;s why like to gather more feedback from the WG regarding the possible ope= n issues (e.g. what has to be described in more detail, ), unanswered quest= ions or any other useful hints how to progress with this work/I-D.<br> > > 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.<br> > ><br> > ><br> > > Thanks and kind regards<br> > ><br> > > KARSTEN Fleischhauer<br> > > _______________________________________________<br> > > Int-area mailing list<br> > > <a href=3D"mailto:[email protected]">[email protected]</a><br> > > <a href=3D"https://www.ietf.org/mailman/listinfo/int-area">https:= //www.ietf.org/mailman/listinfo/int-area</a><br> ><br> > _______________________________________________<br> > Int-area mailing list<br> > <a href=3D"mailto:[email protected]">[email protected]</a><br> > <a href=3D"https://www.ietf.org/mailman/listinfo/int-area">https://www= .ietf.org/mailman/listinfo/int-area</a><br> </p> --0016e6dee70f57527f04a5e92512-- --===============4457342280947137932== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area --===============4457342280947137932==--