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

From: Vernon Schryver <[email-masked]>
Date: Thu, 16 Mar 2000 17:40:52 -0700 (MST)

> From: "Petri Helenius" <[email-masked]>

> ...
> > Exactly what problem needs solving in a timely fashion?
>
> Configuring the CPE device´s netmask without having to have DHCP client on
> the CPE
> (or in the whole system).

The proposal would a bad solution if the problem were real, but the
problem is not real:

  - without a DHCP (or BOOTP, etc) server somewhere, the hosts beyond
   the PPP router cannot use the CIDR block that would be communicated
   by the proposed IPCP option.  Without DHCP, the hosts beyond the PPP
   router must be statically configured.  If the hosts are statically
   configured, then there is no technical reason for an IPCP option.

  - the notion of IPCP negotiating implies that sometimes the negotiated
   CIDR block would change.  If the block does change, then how do hosts
   on the network beyond the PPP router discover they need to kill all of
   their applications and reconfigure their interfaces?  On the other
   hand, if the network number and netmask never change, then why
   complicate IPCP by negotiating something that is unrelated to PPP?

  - NAT, for all of its disadvantages and bad side effects, is a better
   solution.  It is better because it does not require the hosts on the
   leaf network to change their IP addresses and netmasks (and if they
   don't change then the proposed IPCP option is useless).  NAT is also
   better because it does a better job of conserving IPv4 addresses.

  - even if this proposal were better than NAT, then the proposal would 
   be moot, because the industry has already decided to use NAT to solve
   the problem.

>                           With this added, you could also (in another
> scenario)
> populate an DHCP server in the CPE with IPCP derived information. (but that
> is not the main goal here)

That thought is another compelling reason for the IETF to refuse to
publish the proposal.

> > > Unfortunately that decision isn't in our hands.  I know of at least one
> > > vendor who already does this.
> >
> > What do you mean by "this"?  Yes, I know of the Microsoft DNS garbage,
>
> This netmask stuff. Two major vendors are shipping this, in both CPE and
> aggregation equipment. They are also interoperable.

It is believable that tests by two vendors have failed to find
interoperability problems.  However, it is *not* plausible that this
proposal has been or can be used by real life end user customers in the
supposed scenarios, especially including having no DHCP servers.  It is
believable that non-trivial CIDR blocks (i.e. not /32's) have appeared
in IPCP packets sent by the vendors' equipment, but not that the CIDR
blocks were honestly "allocated" (because of the lack of DHCP server)
or honestly "negotiated" (because you can't change the IP addresses of
all of the hosts on a network unilaterally).

> ...
> One of the reasons for putting the (revised) draft forward was to get it
> documented
> and, if possible, move it forward towards being accepted.

Because of the bad faith by the vendors involved, as well as the technical
flaws in the proposal, the IETF should refuse to publish anything
documenting this proposal.
Yes, I mean bad faith, as demonstrated by the history of the proposal,
including the effort to sneak it past the PPP working group.  There is
also the evidence that those involved had and have no intention of
listening to the IETF.  Their plan is get an IETF rubber stamp for their
bad, proprietary idea, and then advertise the bad idea as IETF approved.

It's one thing to have an outside protocol published by the IETF when
the protocol is widely used and when the IETF has not examined the
protocol and found it to be a bad idea.  It is something else to demand
a stamp of approval for a bad modification to an IETF protocol that the
IETF has examined and found to be bad.

That the proposal has been rendered moot by the industry decision to
use NAT makes the proposal a good place for the IETF to start resisting
the efforts by vendors to make the IETF into a rubber stamp for bad
ideas.

>                                                           It's significantly
> more compicated to get DHCP to do this job so I think this is optimal
> approach
> to the problem regardless if DHCP is used in the picture or not.

That is wrong on technical as well as administrative grounds.

Vernon Schryver    [email-masked]

---

From: James Carlson <[email-masked]>
Date: 16 Mar 2000 20:55:38 -0500

[email-masked] (Vernon Schryver) writes:
>    their applications and reconfigure their interfaces?

Pretty clearly, they'll need to be doing DHCP with this hypothetical
CPE box.  Of course, once they're doing DHCP there, it hardly makes a
difference whether the CPE box is relaying to an upstream server or
it's pooling locally from data it got out of IPCP.  In fact, the only
real difference is that the latter is going to be *much* harder for
the ISP to administer and control.  There are all sorts of common
tools for dealing with DHCP accounting.  What exists for this new
subnet mask option?

>  On the other

I think part of the underlying assumption seems to be that that IPCP
negotiation somehow "controls" the addresses that the peer may use.
It doesn't.  There's nothing at all stopping the peer from negotiating
one address and then using another.  In fact, the intelligence has to
be up at the ISP end -- where source address filtering is required.

(One could imagine a network where the server systems have extensive
host-route support and customers can get individual IP addresses on
demand, rather than requiring a doubling of the allocation every time.
Will we then need an "IP-Address-List" option ... ?)

-- 
James Carlson, System Architect                     <[email-masked]>
IronBridge Networks / 55 Hayden Avenue   71.246W   Vox:  +1 781 372 8132
Lexington MA  02421-7996 / USA           42.423N   Fax:  +1 781 372 8090
"PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp

---

From: "Petri Helenius" <[email-masked]>
Date: Thu, 16 Mar 2000 22:33:32 -0800

> be up at the ISP end -- where source address filtering is required.

Modern aggregation devices install anti-spoofing filters automatically
based on the IPCP netmask negotiation. This helps getting rid of all
kinds of source-address spoofing pollution on the public Internet.

I´m open to suggestions how the above will be accomplished with DHCP
and how the DSL aggregation device would know the routes and neccessary
filters to install?
Pete

---

From: James Carlson <[email-masked]>
Date: 17 Mar 2000 07:52:55 -0500

> kinds of source-address spoofing pollution on the public Internet.

Modern, sure, but certainly not all, and perhaps not even many.  I'm
pretty sure RPF is off by default on Ciscos.  This is certainly an
ongoing sore spot with ISPs.  If the anti-spoofing were always
automatic on (at least!) links to single-homed sites, those recent
DDoS attacks would have been much easier to trace and prevent.

> and how the DSL aggregation device would know the routes and neccessary

The CPE box will need to receive and process the DHCPDISCOVER
message.  One obvious way to handle this would be to allow the CPE to
send the DHCP subnet option (draft-ietf-dhc-subnet-option-03.txt) to
the aggregation device, and have the aggregation device allocate a
network for the CPE and set the filters.  The CPE can then do its own
address pooling and DHCPOFFER replies.

Another way would be to make the CPE box just a DHCP relay.  Have the
aggregation device handle the DHCPDISCOVER messages individually.
That probably doesn't scale as well, but it probably also doesn't
matter.  It would have interesting network management possibilities.

Clearly, the aggregation box has exactly the right information in both
cases to apply appropriate filters, install static routes, and
dynamically update DNS entries.

You would, of course, be likely to use unrelated addresses in the IPCP
IP-Address option.  If the networks allocated by DHCP were real,
globally visible addresses (not NAT'd), then I'd use regular RFC 1918
addresses on the PPP link itself.  The actual addresses in use there
don't matter, since folks outside of the link itself -- like the owner
of the computers on that CPE-side network -- cannot see them.

There are certainly many other possibilities here using application-
level protocols like DHCP.  One doesn't need link-layer negotiation to
solve the problem.