Subject: RE: Extending IPCP for Route Table Entries

From: Doug Kehn <[email-masked]>
Date: Tue, 20 May 2003 11:46:06 -0500

> From: Vernon Schryver [mailto:[email-masked]]
> 
> > From: Doug Kehn <[email-masked]>
> 
> > >   - how many IP addresses are negotiated with IPCP for the 
> > > two PPP links,
> > >       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?
>

My mistake, I was only thinking about the CPE-end of the link.  Yes, both
peers get an address.

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

These are good questions.  Maybe only routes added by the Route-Add option
should be deleted when IPCP transitions out of "Opened" (I like your
description).  Preference should/could be determined by the route metric.

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

The answer is yes.  But, other mechinisms, not IP routing, would be used to
direct the packet to 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.
> 
> How do the CPE PPP state machines know which PPPoE Sessions ID
> should have a default route and which should not?
> 

We do it by configuring the interface to be the default route (I'm sure
there are other ways).

> 
> > >    - 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.
> 
> That's interesting.  Why only a single network route?  Why wouldn't
> several be necessary?
> 
> 
> > >    - 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?
> 
> What about that question?
> 
> And why are you talking about PPPoE and ATM now when earlier messages
> talked about 3G phones?
> 

I never talked about 3G phones.  That was someone else.

> 
> Vernon Schryver    [email-masked]
>

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 20 May 2003 11:05:46 -0600 (MDT)

> ...

So there are a total of 4 IP addresses involved, two for the CPE and
two for the CO?

> ...
> > > >   goes down?  Should traffic that would normally use the other link

> ...

> description).  Preference should/could be determined by the route metric.

By "preference" I did not mean metric.

There are implementation problems with that, since routing tables tend
to not contain the process origins of routes or duplicates.  It's
usual to expect that when one mechanism adds a route and a second
mechasm adds and then deletes a similar route, the route added by the
first mechanism is first overwritten and then deleted.

Your mention of paying attention to metrics opens a large can of worms.
My guess was that the IPCP option would not involve any metrics or
that any and all metrics would be ignored or treated as if they were
equal.  If you have metrics, do you also have hop counts?  If the
metrics for the two routes added for the two PPP links (I think you
said there would be two routes) differ, then how do you pick the
outgoing interface on the CPE?  Do you do longest-match?  Do you have
an "infinite" metric that means "use this only as a last resort because
it's being removed"?

("Opened" is the official word in these parts since the first PPP RFC.
I don't like it, and I disavow all ownership of it.  However, using
the official terminology minimizes misunderstanding, even when the
official terms might have been chosen better.)

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

I am confused.  If IP routing is not used to direct the packet to the
appropriate interface, then what do IP routes have to do with anything?
Why bother with sending IP routes though IPCP?

> ...

I clearly have no clue about the target application, because that
makes no sense to me.

> ...

> I never talked about 3G phones.  That was someone else.

Oh, my mistake.

Could you please describe a scenario in which CPE would have two
ATM VCs or two PPPoE links and would use the proposed mechanism?

What sort of CPE are we talking about?  I almost understood the issue
of 1000 words of code in EEPROM for a phone, but I don't understand
why there is any shortage in a box that probably does NAT, general
firewalling, has both HTTP and telnet configuration interfaces and
MBytes of program storage.