RE: Extending IPCP for Route Table Entries

Doug Kehn writes:
> The CO PPP peer is to provide the route information.  The CO PPP peer is
> telling the CPE to route packets on "this" interface.  The route information
> could either be a network route or a host route.

That's exactly what RIP-2 and other routing protocols do.

> Each PPP interface has its own PPP state machine.  The analogy is similar to
> having multiple ethernet NICs.

If you had multiple Ethernet NICs, where would you get your non-local
routes?  You wouldn't have an IPCP to modify.

If some solution works reasonably for Ethernet interfaces, why does
that solution not work for PPP?

> >   - which pair of PPP peers, the pair at the CPE or at the CO, sends
> >       the new IPCP option in an IPCP configure-Req?  My guess 
> > is the CO.
> > 
> 
> The intent was for the CPE to add the option in the Configure-Request.  The
> remote peer could then ACK, NAK, REJ the option just as it does with the IP
> Address and DNS Address options.

Note that the Microsoft DNS address option is defined backwards and
should not be used as a model here.  It has the "CPE" side specifying
(via Configure-Request) its knowledge of (or lack thereof) the name
servers on the remote side, and requires the remote to correct
erroneous information with Configure-Nak.

> >    - why do you need a netmask for a point-to-point link?
> > 
> 
> A netmask isn't necessarily needed.  If a netmask were available (e.g.
> Option 144), the CPE could treat the point-to-point interface as if it were
> a networked interface.

Huh?  PPP interfaces *are* network interfaces.

No netmask is required (or even really usable) because they're
point-to-point.

>  Instead of making a host route to the remote peer on
> the PPP interface, the CPE could make a network route [with the remote peer
> as the gateway] on the PPP interface.
> 
> Without a netmask and in the presence of multiple PPP interfaces, the CPE
> needs route entries in order to reach specific hosts on specific PPP links.

... which brings us back to the purpose of routing protocols.

-- 
James Carlson, Solaris Networking         <james.d.carlson@xxxxxxxxxxxx>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677