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: 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=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    [e-mail]