Subject: Re: draft-helenius-ppp-subnet-00.txt

From: Vernon Schryver <[email-masked]>
Date: Wed, 15 Mar 2000 11:01:45 -0700 (MST)

> From: Rene Tio <[email-masked]>

> ..
> I'm going to have to make this my last email on the subject because (a) I no
> longer do this stuff, and (b) I feel somewhat silly defending this in a
> public forum, especially when the authors haven't spoken up, and when
> neither I nor Redback had anything to do with the draft, nor do I/we
> necessarily want to.  I'd just like to see the problem solved instead of
> peter out like last time without a clear direction.

If what you've said accurately represents the assumptions of the draft,
you've done us all a sigificant service.

> The implicit assumption in this model is that there is no DHCP server.

That sounds like a problem that should be fixed.  Why assume there
is no DHCP server merely to rationalize jamming DHCP facilities into PPP?

> There is a RADIUS which contains the user record, including the size of the
> users' subnet and most likely a static IP address.  Instead of a static IP,
> there was thought to use a pool in the NAS, which hands out address in
> increments according to a subnet size (different pools for different subnet
> sizes).  I don't believe anyone is doing the latter today, since it
> introduces other problems,

My guess is that the use of NAT has made the issue moot, as well as the
fact that it is impossible to such an allocation once it is made.

>                            however using a pool was seen as an advantage
> since one could oversubscribe when deploying a not-always-on service, and
> the NAS could regain addresses by taking down the CPE PPP connection.

That seems to assume that it makes sense to revoke a network allocation
after it has been made, as you mentioned before.  Revoking a network
allocation is NONSENSE!  There is no need to communicate more than one
IP address unless there are 2 or more computers beyond the PPP link
(possibly including the PPP box itself).  Just how would the other
computers on the network be told that their host addresses have been
revoked?  To put it mildly, most hosts or applications don't take well
to having their IP addresses changed.  There is lots of machinery in
DHCP to deal with this unavoidable fact.

> Regarding the problem to be solved, it was autoconfiguration of the CPE home
> ethernet segment, with autoconfiguration of other parameters a distant
> second.

It sounds to me like the ever popular, unthinking "if it has something to
do with networking it has to have its own packets" reaction.

Autoconfiguration of the CPE home Ethernet segment makes no sense if you
stop and think about the computers on the Ethernet.  First and foremost,
you expect them to continue to be able to talk to each other (e.g. NETBIOS
file and print sharing) even when disconnected from the Internet.  That
implies you can cannot change the CIDR block given a CPE home Ethernet
segment.  That "autoconfiguration" necessarily degenerates into "configure
once and never change for the life of the customer's contract."

>          I cannot comment beyond this since I have not kept up with the
> latest work in this area, although I would venture a guess that anything
> which involves protocols other than RADIUS or DHCP would meet with great
> resistance.  When this discussion popped up a year ago I believe several
> vendors at least prototyped it.

There's nothing wrong with trying things, although it pays to think
about implications first, such as what you expect the other computers
on the home CPE Ethernet segment to do when the IPCP negotiation offers
a different CIDR block).

> Finally, I really don't know why the draft wasn't published on the PPP
> mailing list since I was not part of it.

I can think of two reasons.  One is almost reasonable, that the working
group will not bee meeting.  I'm trying not to mention the other.

Vernon Schryver    [email-masked]