Subject: RE: Extending IPCP for Route Table Entries

From: Doug Kehn <[email-masked]>
Date: Tue, 20 May 2003 10:10:39 -0500

> From: Vernon Schryver [mailto:[email-masked]]
> 
> 
> > From: Brad Parker <[email-masked]>
> 

Brad, could you please cc the group on your responses?

> > ...
> > > Please investigate RIP.  You are supposed to ignore RIP 
> packets from
> > > distant networks.  
> >
> > I've implemented RIP, thanks.  Many times.
> 
> I've also implemented RIP, but only once in the current version of
> the `routed` source used in IRIX, Solaris, FreeBSD, NetBSD, and
> elsewhere, unless you count the many versions of that source. 
>  I didn't
> think there were many other implementations of RIP, at least not by
> one person.  Where did you write your implementations?
> 
> 
> > ...
> > > How does one PPP peer know about the netmask and IP 
> address for the
> > > other PPP peer?
> >
> > You may wish to refer them as PPP peers but I am sticking 
> to my CO and 
> > CPE phrases, where the CPE gear is less capable and subordinant.
> >
> > The CO concentrator provides two PPP links.  On one is 
> expect the CPE to
> > have a default route.  On the other it would like to 
> provide a net and
> > netmask so as to estabilish a single route to the alternate link.
> 
> I do not understand.  Which is the "it" that would "like to provide
> a net and netmask, the CPE or the CO PPP peer?  Do you mean that the
> CO is to tell the CPE "put most of your packets on this PPP link but
> only send packets with my IP address on this link PPP link"?
> 

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.

> 
> > ...
> > > How does one PPP peer of the customer premise equipment 
> know anything
> > > about the IP address and netmaks of any other PPP peer of the CPE?
> > > How does one PPP peer even know there is a second PPP peer?
> >
> > I don't understand what you are saying here.
> 
> Normally, PPP state machines are entirely independent, with the
> partial exception of Multilink (MP).  The fact that a box has two
> or more PPP links is normally unknown to all PPP state machines.
> 

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

> > Presumably the CPE hear has some method of establishing a 
> PPP session 
> > with the CO gear.  Let's assume for a moment the CPE gear 
> has 2 modems
> > (but it could just as well be two ATM PVC's).  Each one is 
> a distinct 
> > interface and does a separate IPCP negotiation.  One acts 
> in the nominal
> > case and gets a default route.  The other, by convention, 
> gets an IPCP
> > option which says "add a single static route to this net 
> and route it
> > through this interface".
> >
> > Is that not clear?
> > ...
> 
> No, it is not clear to me.  I thought by "CO" you meant "telco central
> office" and by "CPE" you meant "customer premise equipment."  Among
> the things that don't make sense to me are:
> 
>   - how many IP addresses are negotiated with IPCP for the 
> two PPP links,
>       0, 1, 2, 3, or 4?  I assume not zero, since IPCP is in use
>       and you've mententioned IP addresses, but that is only 
> a guess because
>       you don't need to have any IP addresses in use (not to mention
>       negotiated) even with IPCP Configure-Acks being exchanged.
> 

IPCP negotiates one IP address per PPP link.

>   - 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.

>   - how are the two PPP state machines in a pair at either 
> the CO or the
>       CPE related or coordinated?  What happens if one of the 
> PPP links
>       goes down?  Should traffic that would normally use the 
> other link
>       switch to the remaining link?
> 

The PPP state machines are independent at both peers.  The proposal states
that any routes added to an interface using the option should be deleted
when IPCP terminates.  In the absence of any routing information, the CPE
will send packets out its default route (which could be a PPP interface).
  
>   - what is the difference between the traffic for the two 
> links?  Does
>       it differ only by IP address?
>

It doesn't matter.  The intent to route packets on the appropriate
interface.
 
>   - how do the two pairs of PPP state machine ensure that they are not
>      crossed?  Would you use some extension of endpoint 
> discriminators?
> 

The practical application would be to use PPPoE and have the PPPoE Session
ID be the descriminator.  However, there are probably other ways to bind the
protocol stack in order to ensure the PPP state machines are not crossed.

>    - 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.  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.

>    - why do you need two PPP links to a single 3G telephone?  Why not
>       use a single PPP link and an appropriate queuing discipline for
>       the various kinds of traffic?
> 
> 
> Vernon Schryver    [email-masked]
>

---

From: James Carlson <[email-masked]>
Date: Tue, 20 May 2003 11:24:25 -0400

> could either be a network route or a host route.

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

> 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?

> 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.

> 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

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

-- 
James Carlson, Solaris Networking         <[email-masked]>
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

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 20 May 2003 09:30:28 -0600 (MDT)

> From: Doug Kehn <[email-masked]>

> >       0, 1, 2, 3, or 4?  ...

> IPCP negotiates one IP address per PPP link.

Formally, IPCP does not negotiate IP addresses for PPP links, but
for the PPP peer that sends the IPCP configure-request.  When PPP
links are run in some form of "unnumbered" mode, only 0 or 1 IP
address is used by the two PPP peers. Otherwise, IPCP is commonly
used to negotiate two IP addreses for each link, one address for
each PPP peer.

In this case, are there a total of 2 or 4 IP addresses for the 4 PPP 
peers or state machines?
If there are only 2, do the PPP peers at the CO or CPE get the addresses?

> >       the new IPCP option in an IPCP configure-Req?  My guess is the CO.
>

> >   - how are the two PPP state machines in a pair at either the CO or the
> >       CPE related or coordinated?  What happens if one of the PPP links
> >       goes down?  Should traffic that would normally use the other link

That sounds as the answer to my second question is "yes, if the
remaining link has the default route."  However, your answer raises
other questions.  What happens if the route was already present as
a static route?  Should the link going down delete routes added by
other mechanisms?  What should happen if a routing protocol is
running?  Which processes routes, IPCP's or the routing protocol's,
should have preference?

(By "IPCP terminates" I assume that means any state transition out
of "Opened".  See page 16 of RFC 1661.)

> >   - what is the difference between the traffic for the two links?  Does

Which is the appropriate interface for an IP packet?  Is that
appropriateness determined by anything other than IP address, such
as IP TOS/QOS bits?  Or other bits in the IP payload?

> >      crossed?  Would you use some extension of endpoint discriminators?
>

How do the CPE PPP state machines know which PPPoE Sessions ID
should have a default route and which should not?

> needs route entries in order to reach specific hosts on specific PPP links.

That's interesting.  Why only a single network route?  Why wouldn't
several be necessary?

> >       the various kinds of traffic?

What about that question?

And why are you talking about PPPoE and ATM now when earlier messages
talked about 3G phones?

---

From: James Carlson <[email-masked]>
Date: Tue, 20 May 2003 13:46:15 -0400

Brad Parker writes:
> yes, but to fill in the analogy, if I where using ethernet, I'd be 
> mobile and "plug in" (the analog to dialing-in) and then I'd probably 
> use DHCP which would no doubt give me a default route.  In this scenario 
> I wonder if IPCP is like DHCP (and believe me, it pains me to say that).

It's not like DHCP, unless we allow unnecessary duplication like that
proposed here to creep in.

If you would use DHCP in the Ethernet case, then why would you not use
it in the PPP case?  DHCP runs over UDP, and it works just fine over
just about any reasonable medium.

> None of my mobile hosts listen for RIP when the plug in.  They all use
> DHCP and get a default route.  Maybe I'm 2 sigmas out of the norm... :-)

Fine.  Then send DHCPINFORM (per RFC 2131) and use the existing
mechanism to do this.  No new standards required, no IPCP changes, no
changes to existing implementations.

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 20 May 2003 12:25:24 -0600 (MDT)

> From: James Carlson <[email-masked]>
> To: Brad Parker <[email-masked]>

> changes to existing implementations.

There's also the router discovery protocol that is older than the DHCP
option, stands alone, works anywhere that IP works, and can be treated
as simply as the DHCP option.

---

From: James Carlson <[email-masked]>
Date: Tue, 20 May 2003 14:35:01 -0400

> as simply as the DHCP option.

My point was that if he already needed to have DHCP in *some* cases,
and he was already relying on that, then there's really no reason not
to use it for the PPP case as well.

If he has nothing at all, then, certainly, RFC 1256 router discovery
is about as simple as you're possibly going to get.