RE: Extending IPCP for Route Table Entries

> From: Doug Kehn <dkehn@xxxxxxxxxxxxx>

> It is the end-user PPP links that are being addressed here.  The usage is a
> broadband CPE router residing in the home.  The CPE terminates the PPP
> interface and must route packets between the WAN (PPP interface) and the
> LAN.  The LAN is using private IP addresses (from the CPEs DHCP server) and
> the CPE utilizes NAPT to translate the private LAN IP addresses to the
> public IP address of the PPP interface.  If there is only a single PPP
> interface, there is no problem.  The CPEs default route is the one and only
> PPP interface.  However, in the presence of multiple PPP interfaces, which
> interface interface does the router choose to route the packet?  The default
> route of course.  But, what if the default route is not the correct path for
> the packet?

That problem has absolutely nothing to do with PPP.  We've been dealing
with that problem for literally decades.  It's what routing protocols
are all about.  Even before there was PPP, people had boxes with
multiple interfaces, such as a LAN and a dynamically dialed SLIP link.

> Extending the scenario assume the CPE has two PPP interfaces.  One interface
> is to the Internet and is the router's default route.  The other PPP
> interface is to an isolated network that the Service Provider provisions for
> additional services (gaming, video, etc).  PPP is logical choice for the
> additional services interface because tracking/billing services are already
> available.  Without any routing information, the router will route all
> packets to the default route (unless the packets are destined to the remote
> peer of the additional services PPP interface).  The Service Provider may
> wish to put several servers in the additional services network; thus,
> sending packets to the remote peer won't reach the desired server.  Now the
> router needs routing information so that it can ensure packets are routed to
> the correct PPP interface.

That sounds like a need for far fancier routing than that proposed.
Have the advocates for this proposal looked at "policy routing"?


> RIP (or another routing protocol) would suffice.  However, my gut feeling is
> that Service Providers see the use of a routing protocol as overkill.  All
> that is needed is a static route (most likely a single route entry) so that
> the CPE can properly route packets to the additional services PPP interface.
> Furthermore, the route only needs to exist as long the PPP interface exists.

As I said before, reasonable PPP and SLIP implementations have for 
literally decades installed routes as needed when their links came up.

For just as long, people have also used RIP for the same purpose.
For example, the `routed` code in common UNIX flavors including IRIX,
Solaris, FreeBSD, and NetBSD can notice when an interface appears and
advertise a route.


> BTW, we work with 15-20 service providers world wide and only 1 has a
> routing protocol (RIP) enabled in the CPE.

There is a difference between fully enabling RIP and enabling RIP
to advertise a default route.  The first can adventurous, because
it implies listening to whatever RIP packets come from the customer.
The second is quite safe.  It's a standard feature in many PPP boxes
precisely for this purpose of telling CPE where to send packets.

Besides, if your 14-19 providers have turned off RIP, it would be
wrong to sneak an ad hoc not-really routing protocol into PPP in order
to subvert their decision to turn off routing.


Vernon Schryver    vjs@xxxxxxxxxxxx