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

[<[e-mail]>]

Dear Mark,

See my comments inline.

Best

KARSTEN

> -----Ursprüngliche Nachricht-----
> Von: Mark Townsley [mailto:[e-mail]]
> Gesendet: Freitag, 17. Juni 2011 15:22
> An: Fleischhauer, Karsten
> Cc: [e-mail]; [e-mail]
> Betreff: Re: [Int-area] 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 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 behaviour.  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.

I share this fear but on the end this as also any other changes in the network needs
testing before launch.
On the network PPP peer side you could be "backward compatible".
So also non draft "On demand IPv4 address provisioning in Dual-Stack PPP deployment" compatible PPP peers will work without problems.
Maybe a problem can occur when a draft "On demand IPv4 address provisioning in Dual-Stack PPP deployment" compliant PPP peers will appear on a network where this support is missed.
Maybe in this case an upgrade is needed.

>
> 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 behaviour 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.
In this case a "deactivation" of the feature on the HG would be useful.
This could be done maybe due configuration or simply with sending IPv4 requests within the "IPCP idle timer" value.
But we would hope that these always-on applications will be move quickly to IPv6.

>
> Finally, devices are moving towards a "cloud connected" mode
> of operation. In IPv4, there is essentially no end-to-end
> reach ability, 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.
That should be considered in our efficiency calculation.
As already mentioned we would recommend here the usage of IPv6.
This is also valid for other update services (anti-virus, OS, email, etc.).
I think the support of NAT444 as "alternative" would not simplify such apps.

>
> 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.
Our estimation of the saving effects is more or less conservative and considering
a rather small adaption of IPv6.
We will introduce Dual-Stack in the first phase, the address saving in the second phase.
So the IPv6 content provider would have here a small advance to enable their apps.
Maybe other ISPs can initially implement the address saving feature (no revision of the Dual-Stack implementation is needed). But these ISPs would be benefit from the early mover.
Surely beside the implementation of the draft also other ISP internal IPv4 address efficiency measures would be useful und helpful to provide the customer the best IP connectivity as possible.

>
> - 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=applicati
on/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
>
>