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

<Olaf.Bonness@telekom.de> Mon, 20 June 2011 07:56 UTC

Return-Path: <Olaf.Bonness@telekom.de>
X-Original-To: pppext@ietfa.amsl.com
Delivered-To: pppext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CA611E8114; Mon, 20 Jun 2011 00:56:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level:
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROpE1BLqQtyA; Mon, 20 Jun 2011 00:56:53 -0700 (PDT)
Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by ietfa.amsl.com (Postfix) with ESMTP id 40A6511E80F9; Mon, 20 Jun 2011 00:56:51 -0700 (PDT)
Received: from he111527.emea1.cds.t-internal.com ([10.125.90.86]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 20 Jun 2011 09:56:36 +0200
Received: from HE111541.emea1.cds.t-internal.com ([169.254.2.158]) by HE111527.EMEA1.CDS.T-INTERNAL.COM ([2002:7cd:5a56::7cd:5a56]) with mapi; Mon, 20 Jun 2011 09:56:36 +0200
From: <Olaf.Bonness@telekom.de>
To: <vjs@calcite.rhyolite.com>, <K.Fleischhauer@telekom.de>
Date: Mon, 20 Jun 2011 09:56:34 +0200
Thread-Topic: [Pppext] [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG?
Thread-Index: AcwumAHgi1pRnzWpQOKcZAsIRuAf9QAgzzKA
Message-ID: <CE8995AB5D178F44A2154F5C9A97CAF4024E41392886@HE111541.emea1.cds.t-internal.com>
References: <580BEA5E3B99744AB1F5BFF5E9A3C67D08ADE52C2A@HE111648.emea1.cds.t-internal.com> <201106191545.p5JFjlWL042969@calcite.rhyolite.com>
In-Reply-To: <201106191545.p5JFjlWL042969@calcite.rhyolite.com>
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: pppext@ietf.org, int-area@ietf.org
Subject: Re: [Pppext] [Int-area] IETF80 questions regarding "On demand IPv4 address provisioning in Dual-Stack PPP deployment" - Topic for WG?
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PPP Extensions <pppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pppext>, <mailto:pppext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pppext>
List-Post: <mailto:pppext@ietf.org>
List-Help: <mailto:pppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pppext>, <mailto:pppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jun 2011 07:56:54 -0000

Hi folks,

please find my comments inline.

Kind regards
Olaf

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

... (Some lines deleted)

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

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.

...

> 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

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

> > >   - How often is IPCP used today to allocate IP addresses?  Isn't DHCP
> > >      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.

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

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.

> 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

Where did you read these remarks regarding DHCP?

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

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.
> Perhaps an informational RFC could be justified.  It would be better
> than some informational I-Ds involving vendor-specific IPCP options.

O.k. you are voting for informational.

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

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

> 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    vjs@rhyolite.com
> _______________________________________________
> Pppext mailing list
> Pppext@ietf.org
> https://www.ietf.org/mailman/listinfo/pppext
>