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

[Vernon Schryver <[e-mail]>]

> From: <[e-mail]>
> To: <[e-mail]>
> CC: <[e-mail]>, <[e-mail]>, <[e-mail]>

> > 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.
>
> KF: You are right.

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

> >   - I think M.Townsley has understated the problems in changing IP
> >      addresses on running systems.  I bet most server programs will

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

> >      What about firewalls?
>
> 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.

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


> >   - How often is IPCP used today to allocate IP addresses?  Isn't DHCP
> >      often used even over PPP, especially for the consumer grade

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


> >   - Would this scheme have more or fewer odd side effects and bad
> >      boundary cases than the other schemes for dealing with

> >      shortages such as "large scale" or "carrier grade NAT"?  Besides

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

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.


Vernon Schryver    [e-mail]