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

From: Mark Townsley <[email-masked]>
Date: Fri, 17 Jun 2011 15:22:06 +0200

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, <[email-masked]> <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 17 Jun 2011 21:48:08 GMT

> From: Mark Townsley <[email-masked]>
> To: "<[email-masked]>" <[email-masked]>
> Cc: [email-masked], [email-masked]

> Technically, this approach ...

> > "http://www.ix-konferenz.de/getfoldat.php?vid=1638&t=application/pdf&thema=Effizienzabschätzung"

What is the topic or issue?  That PDF slide show has plenty of words
and pictures justifying and advocating whatever it is talking about,
but I don't seem much about concrete mechanisms or changes to PPP code.
My guess is that the topic is something about PPP peers killing their
IPCP state machines after IP inactivity (presumably ignoring LCP
activity as well as other activity such as bridging) and then restarting
IPCP on new activity to negotiate potentially new IPv4 addresses.

If I've guessed the topic correctly then:

  - I bet M.Townsley is right and that some PPP implementations 
     treat a broken IPCP state as reason to kill LCP and restart
     the whole session.

  - I think M.Townsley has understated the problems in changing IP
     addresses on running systems.  I bet most server programs will
     not notice that their carefully constructed lists of TCP LISTEN
     or UDP sockets are kaput because the local IP addresses changed.

     Of course, any and all existing TCP sessions break when IP addresses
     change.  Besides apparently quiet ssh, ftp, and (secure-)telnet
     sessions, and so forth, what about cached SMTP and HTTP connections?

     What about firewalls?

  - How often is IPCP used today to allocate IP addresses?  Isn't DHCP
     often used even over PPP, especially for the consumer grade
     Internet services that are most likely to be targets of a scheme
     like this?

  - Would this scheme have more or fewer odd side effects and bad
     boundary cases than the other schemes for dealing with IPv4 address
     shortages such as "large scale" or "carrier grade NAT"?  Besides
     application hiccups on changing addresses, what happens when all
     of your users try to be active and so you temporary can't allocate
     addresses for all of them?

> > We plan to come up with a 01 version of the 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.

Given the statement about the protocol itself not changing, how does
the PPPEXT working group or the IETF in general have standing to talk
about the issue or object to the proposal, whatever it is?

Before writing an I-D that would merely try to convince others to write
and test code, why not write and test some code before writing an I-D?
Successful tests with a few 100 real users would go a long way to
answering objections and generating interest in the idea.  The idea
might sound good if 500 real Windows users behind Lunix-based cable
or DSL modems with the modest code implementing this idea have no
problems.  (What's the name of the commodity consumer router that is
frequently and routinely hacked to support new things?)

On the other hand, if it is impossible or impractical to write code,
get it installed in a small test environment (e.g. a few 100 users),
or get positive results from tests, then there's no need to write
an I-D or for anyone else or any working group to consider it.

If there is no hope of getting a router vendors to implement the
idea before an RFC (not just an I-D) is published, then the idea
has no hope.  By the time an RFC could be approved and published
and vendors respond, the IPv4 address shortage will have been solved
for years one way or another.

Vernon Schryver    [email-masked]

---

From: <[email-masked]>
Date: Sun, 19 Jun 2011 13:07:27 +0200

Dear Vernon,

See my comments inline.

Best

KARSTEN

> -----Ursprüngliche Nachricht-----
> Von: Vernon Schryver [mailto:[email-masked]]
> Gesendet: Freitag, 17. Juni 2011 23:48
> An: Fleischhauer, Karsten; [email-masked]
> Cc: [email-masked]; [email-masked]
> Betreff: Re: [Pppext] [Int-area] IETF80 questions regarding
> "On demand IPv4 address provisioning in Dual-Stack PPP
> deployment" - Topic for WG?
>

KF: You are right.

>      treat a broken IPCP state as reason to kill LCP and restart

I afraid you would win the bet.
Therefore we are thinking it is important to
have this ID/RFC to discuss/inform that also implementations are needed and
will exists that expect an standard compliant PPP session peer.

>      sessions, and so forth, what about cached SMTP and HTTP

That is right.
But we would configure an "IPCP idle timer" value (for releasing the IPv4 address)
which is equal to the today used "PPP idle timer" value.
So we are expecting no additional problems in this implementations.
Nevertheless, when here problems occur we provide at least in the internet access
area IPv6 as an alternative. Applications, services etc. can using IPv6!

>      Internet services that are most likely to be targets of a scheme

We are addressing here PPP and IPCP.
Of course a similar use case is possible with DHCP with or without PPP.
Maybe here the DHCP/DHCPv6 implementations have here not so many dependencies as
Mark has reported for IPCP/IPv6CP.
I do not know if the description of the same scenario for DHCP/DHCPv6 is needed.
In any case I would see this in an additional ID and not in PPPEXT or INTAREA.

>      addresses for all of them?

Olaf's calculation of the saving effects is based on statistics.
The calculation/configuration of the address pool size in the operational network
Will be done as a result of practical experience that we have already
today for IPv4-only PPP usage (usage in the past + trend + reserve).
Maybe today the PPP session capacity is a bottleneck,
which will change to the size of the IPv4 address pools.
But also in a CGN scenario a calculation is needed to optimize
the network configuration/usage and costs.
An also in this case bottlenecks will exist.

> about the issue or object to the proposal, whatever it is?
As indended status of the ID we proposed in the version 00 "Informational".
The final classification will be a result of the discussion within the IETF.
In any case we want to discuss the draft in the IETF community and
considering the feedback from all experts in future versions.

> has no hope.

Before we introducing anything in the network for customer
we analyzing,
specifying,
prototyping,
implementing,
testing internal and
testing external.
Because of our experience with PPP we see no need for a customer field trial.
Currently we or our vendors are in different phases of speciying,
prototyping and implementing.
But we are thinking that it is not useful to discuss within the IETF community any
project or business plans.

> By the time an RFC could be approved and published
We believe that several solutions will be needed
to mitigate the IPv4 address shortage.
As stated above we are thinking that this solution can be one of them
that could also applicable for other ISPs.
Because of the relativly few changes in the implementatipons/message flow
we are thinking that we will have until end of this year a very stable draft.
So there is no burden to implement and use and solve the IPv4 address shortage.
The IETF ID/RFC processing could be done in parallel.
IMHO it is important that on the end the description of the mechanism is available/published
as an IETF Draft or finally RFC.

---

From: <[email-masked]>
Date: Sun, 19 Jun 2011 13:51:24 +0200

Dear Mark,

See my comments inline.

Best

KARSTEN

> Von: Mark Townsley [mailto:[email-masked]]
> Gesendet: Freitag, 17. Juni 2011 15:22
> An: Fleischhauer, Karsten
> 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.

> > 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.
> > 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

---

From: Vernon Schryver <[email-masked]>
Date: Sun, 19 Jun 2011 15:45:47 GMT

> From: <[email-masked]>
> To: <[email-masked]>
> CC: <[email-masked]>, <[email-masked]>, <[email-masked]>

> > IPCP on new activity to negotiate potentially new IPv4 addresses.

That seems to contradict the later statement that the new IPCP idle
timer would have the same value as existing LCP idle timers.

> >      Of course, any and all existing TCP sessions break when

> which is equal to the today used "PPP idle timer" value.

In that case, I wonder if I understand what is being proposed I think
that LCP idle timers are generally reset by IP traffic.  So an additional
explicit IPCP idle timer would not be needed.  See
http://www.google.com/search?q=lcp+idle+timer

> We are addressing here PPP and IPCP.

I think it is best to consider to entire systems.  A PPP mechanism
that would almost never be used because other standardized mechanism
are and will be used to provide its facilities is inadmissable to a
reasonable official standards process.

> Of course a similar use case is possible with DHCP with or without PPP.

It sounds as if the proposal is a recommendation that Internet services
provides who lack IPv4 addresses configure things so that:
   - IPv4 addresses are not statically assigned on PPP links,
   - dynamic IPCP IPv4 address assignments do not endure PPP resets,
      especially those triggered by LCP idle timers,
   - DHCP lease times be shortened
   - the de facto standard DHCP features that try to give returning
      users the same IPv4 addresses be turned off

Those ideas seem like common sense (al beit rather obvious) and
don't unnecessarily violate layers or introduce distasteful IPCP
options like certain proposals outside the PPPEXT working group.

> In any case I would see this in an additional ID and not in PPPEXT or INTAREA.

Since no point-to-point protocol changes are being proposed and contents
of an ID would be obvious operational advice, I don't see a PPP RFC.
Perhaps an informational RFC could be justified.  It would be better
than some informational I-Ds involving vendor-specific IPCP options.

> >      boundary cases than the other schemes for dealing with

> An also in this case bottlenecks will exist.

I do not see an answer to my question about how this proposal compares
with schemes such as LSN or CGN.  See
http://www.google.com/search?q=IPv4+cgn+OR+lsn
Perhaps your informational I-D could say something about that.

See also
http://www.google.com/search?q=ietf+IPv4+address+shortage+bcp
and even
http://www.google.com/search?q=ietf+IPv4+address+shortage+ppp

> As indended status of the ID we proposed in the version 00 "Informational".

I thought informational RFCs do not depend on the let, leave, or
hindrance of IETF working groups.

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 17 Jun 2011 07:24:39 -0700

On Jun 17, 2011 6:22 AM, "Mark Townsley" <[email-masked]> 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.
> > 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.
> > "
http://www.ix-konferenz.de/getfoldat.php?vid=1638&t=application/pdf&thema=Effizienzabschätzung
"
> > 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.

---

From: Dave Thaler <[email-masked]>
Date: Fri, 17 Jun 2011 17:04:39 +0000

Mark Townsley wrote:
[...]
> 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.
[...]

I'll second the above.   This is very problematic for some applications.
(Other solutions like DSTM that have on-demand IP addresses have this same issue.)

So any network that deploys such a solution in anything other than 
a tightly controlled environment where directly connected nodes are restricted
to a specific set of pre-tested applications, will likely result in many support calls.

-Dave

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 17 Jun 2011 10:17:07 -0700

> to a specific set of pre-tested applications, will likely result in many support calls.

Is this really different from the dial-on-demand routing that has
existed for years and still exist as  common backup connectivity
technique?

I assume that this would be implemented on an Home Gateway which
provides consistent addressing to IPv4 hosts within the home, and
dial-on-demand type mechanism request the IPv4 address to the home
gateway to do NAT44 in the event of an IPv4 stream arrives.

Cameron

---

From: Joshua Shire <[email-masked]>
Date: Fri, 17 Jun 2011 11:31:27 -0600

I'll second this. Most of the new SMB level gateway devices we're seeing on the market support some type of USB connected 3G/HSPA dial-on demand system as a backup link. We've implemented it quite extensively with little to no problems.

Josh

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cameron Byrne
Sent: Friday, June 17, 2011 11:17 AM
To: Dave Thaler
Cc: [email-masked]; [email-masked]
Subject: Re: [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG?

Cameron

---

From: Dave Thaler <[email-masked]>
Date: Fri, 17 Jun 2011 19:00:28 +0000

Requiring the CPE to be a gateway rather than a host running arbitrary applications
is one way to restrict directly connected nodes to a specific set of pre-tested applications.

-Dave

> From: Joshua Shire [mailto:[email-masked]]
> Sent: Friday, June 17, 2011 10:31 AM
> To: Cameron Byrne; Dave Thaler
> Subject: RE: [Int-area] IETF80 questions regarding "On demand IPv4 address
> provisioning in Dual-Stack PPP deployment" - Topic for WG?
> 
> I'll second this. Most of the new SMB level gateway devices we're seeing on the
> market support some type of USB connected 3G/HSPA dial-on demand system
> as a backup link. We've implemented it quite extensively with little to no
> problems.
> 
> Josh
> 
> Subject: Re: [Int-area] IETF80 questions regarding "On demand IPv4 address
> provisioning in Dual-Stack PPP deployment" - Topic for WG?
> 
> >> 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.
> > [...]
> >
> > So any network that deploys such a solution in anything other than a
> > tightly controlled environment where directly connected nodes are
> > restricted to a specific set of pre-tested applications, will likely result in many
> support calls.
> >
> 
> Is this really different from the dial-on-demand routing that has existed for
> years and still exist as  common backup connectivity technique?
> 
> I assume that this would be implemented on an Home Gateway which provides
> consistent addressing to IPv4 hosts within the home, and dial-on-demand type
> mechanism request the IPv4 address to the home gateway to do NAT44 in the
> event of an IPv4 stream arrives.
> 
> 
> Cameron

---

From: <[email-masked]>
Date: Mon, 20 Jun 2011 09:56:34 +0200

Hi folks,

please find my comments inline.

Kind regards
Olaf

> Im Auftrag von Vernon Schryver
> Gesendet: Sonntag, 19. Juni 2011 17:46

... (Some lines deleted)

> timer would have the same value as existing LCP idle timers.

As far as I understand it Karsten tries to say the following:
The IPCP session is released after an timeout interval that is comparable to the timeout used  in _todays_ LCP implementations. (Thats why this IPCP release will show the same effects to the IPv4 part of the user as todays PPP release.)
The LCP timeout is assumed to be longer and the LCP is usually kept alive because of the IPCPv6 or bridging or whatever.

...

> http://www.google.com/search?q=lcp+idle+timer

Hopefully my 3 sentenses above answer this.
(BTW it is IMHO not very useful to post Google search requests here. I would prefer to have a real link to a dedicated source in order to find the right reference and to make sure that I do understand your point.)

> > >      often used even over PPP, especially for the consumer grade

Amazingly often PPP is used for that within legacy networks especially if you do not _want_ to implement / run DHCP because of several reasons.

> reasonable official standards process.

The proposed mechanism  in this I-D is described for scenarios where IPCP is used for IPv4 address provisioning in Dual-Stack PPP sessions. The idea itself may easily be extended to DHCP based scenarios, 3G and 4G networks - but this is not part of the mentioned I-D.

>       users the same IPv4 addresses be turned off

Where did you read these remarks regarding DHCP?

> In any case I would see this in an additional ID and not in

Hmmm additional I-D. Do you mean informational or individual? Or where is "additional"

> Since no point-to-point protocol changes are being proposed
> and contents of an ID would be obvious operational advice, I don't see a PPP RFC.

O.k. you are voting for informational.

> Perhaps your informational I-D could say something about that.

Just another nice google search list :).
Couly you be more specific what you mean with "compares"? Do you mean comparability in terms of efficiency?

Regards
        Olaf

> http://www.google.com/search?q=ietf+IPv4+address+shortage+ppp

:)

> Pppext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pppext
>