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

[<[e-mail]>]

Dear Vernon,

See my comments inline.

Best

KARSTEN


> -----Ursprüngliche Nachricht-----
> Von: Vernon Schryver [mailto:[e-mail]]
> Gesendet: Freitag, 17. Juni 2011 23:48
> An: Fleischhauer, Karsten; [e-mail]
> Cc: [e-mail]; [e-mail]
> Betreff: Re: [Pppext] [Int-area] IETF80 questions regarding
> "On demand IPv4 address provisioning in Dual-Stack PPP
> deployment" - Topic for WG?
>
> > From: Mark Townsley <[e-mail]>
> > To: "<[e-mail]>" <[e-mail]>
> > Cc: [e-mail], [e-mail]
>
> > Technically, this approach ...
>
> > > The PPP protocol has not to be changed in order to
> achieve the needed functionality -
>
> > >
> "http://www.ix-konferenz.de/getfoldat.php?vid=1638&t=applicati
on/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.

KF: You are right.

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

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

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!

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

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.

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

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.

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

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

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
> and vendors respond, the IPv4 address shortage will have been solved
> for years one way or another.
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.

>
> Vernon Schryver    [e-mail]
>