Subject: RE: Extending IPCP for Route Table Entries

From: Vernon Schryver <[email-masked]>
Date: Mon, 12 May 2003 20:10:06 -0600 (MDT)

> From: Ignacio Goyret <[email-masked]>

> >An RFC saying "STOP BEING STUPID" would be a good idea.
>
> :-)
>
> Should that be "informational" or "standard track" ?

STOP BEING STUPID might be a little ambitious.  However, it would be
good to have an official standards track document that says "keep
upper layer stuff in upper layers" and gives examples including using
DHCP (ugh), RIP, or IRDP for routing, DNS for DNS, SMTP for mail, LDAP
for names, and so forth.

> >> I've included the draft-carrel-info-pppoe-ext-00.txt for your review.
> >
> >sheesh...
> >The May 2000 date of that draft gives me a little hope that it got
> >squelched outside Redback's customers.  It was "Informational."
>
> See RFC 2516. For better or worse, it made it through.

at least only as Informational.

> For the record, I agree with Vernon: IPCP is not the place for these things.
> As he mentioned, there are a number of good alternatives.
>
> I guess if push comes to shove, even DHCP could be used if someone really
> insists on this being "configurable"...

well, yes, if you see "configurable" as somehow incompatible with 
routing protocols.   (Yes, I've noticed the new DHCP routing option.)

Oh, well, give us a few more years and we'll recapitulate the ISO OSI suite.

Vernon Schryver    [email-masked]

---

From: "Jari Arkko (LMF)" <[email-masked]>
Date: Tue, 13 May 2003 08:04:47 +0200

> http://www.ietf.org/internet-drafts/draft-song-pppext-mipv6-support-00.txt

I could have misunderstood the purpose of this draft,
but it appears to be against the architectural principles
in Mobile IPv6, i.e. that no special support from the local
routers is needed. Furthermore, if the access provider
wishes to "differentiate" customers by offering some
of them the possibility of using Mobile IPv6 and some
of them not, a "better" way of doing that would be
to install a filter at the access router for blocking
some traffic for the poor users in the lower category...

--Jari

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 14 May 2003 12:05:54 -0600 (MDT)

> From: Brad Parker <[email-masked]>

> ...
> Ah.  I think you're missing the point Vern.  He's got an operational 
> problem which he's trying to fix by using the protocol at hand.  I think 
> it's a reasonable thing he wants to do.

It's a priori reasonable only if you endorse seeing all of the world
as a nail because the only tool of the several in your toolbox that
you how to use is a hammer.
If the thinking in this proposal is so good, then let's get rid of
IP, UDP, TCP, DNS, SNMP, and all application protocols.  Seriously,
why draw the line at routing?

> [aside: I've worked at an ISP and I've shipped datacom/router boxes. 
> It's sometimes helpful to view both sides of this rather than being 
> entirely dogmatic.]

It's also good to recognize dogmatism of all flavers.  Besides the
dogma of insisting on using routing protocols for routing, there is
the "all the world's a link layer since that's all I can affect" dogma
that has long been popular among people coming to this mailing list.

> If I heard correctly, RIP could be used, but waiting for RIP packets to 
> come across the link and then adding routes based on them is cumbersom, 
> slow and not completely reliable (or safe).  

I think that's mistaken.
  - waiting for RIP packets to cross the link should not be more
     than milliseconds, which is insignificant.  If you really care about
     those milliseconds, you can make the delay microseconds by
     transmitting the RIP packet immediately after your IPCP packets
     in anticipation of the PPP peer liking your IPCP bits.
  - it's good to wait to add the route until after the IP machinery is
     really alive, and a RIP/UDP/IP packet is a good sign of that.
  - adding routes based on a RIP packet is no slower or more
     cumbersome than adding routes with any other mechanism.  
  - I can't see any lack of safety in this case.  You'd check that the
     IP destination address is yours, the source address is the PPP peer's,
     the route is a default with next hop address also equal to
     the PPP peer's, and probably ignore the metric.
  - I can't see any lack of reliability in adding routes based on RIP packets 

>                                              Adding a static route when 
> the link is brought up makes a lot of sense, at least from the 
> operational side.

I've written and used code that adds and removes routes with the link
state change as well as code that does the same with RIP.  The main
problem with adding adding routes with the link state change is that
it sometimes conflicts with real routing.

>
> I'd solve this by adding a private option to the IPCP packet, myself. 
> It's not negotiating a dynamic route, so it's doesn't overlap with a 
> routing protocol.  It's just negotiating a default route.  One per 
> interface.  (at least that's what I heard).

One of the things that irritates me about this proposal is that there
is little or nothing I can see to "negotiate."  When would the route
ever point to an IP address other than the IP address of the PPP peer?
If the route ever did point to some other IP address, it would be an
bogus route.  The box already knows its own and its peer's IP addresses,
so any IPCP bit cannot say anything useful.
When would the PPP peer ever issue an IPCP NAK or REJ?  If never,
it's not much of a "negotiation."

Another problem is that it's got the notion of who is negotiating with
whom partly backwards.  The PPP peer that would send say "route through
me" can only really say "if you wanted, you could route through me."
Only the other peer can know whether it needs a default route.

> I assume the requirement is a single net number with a mask.  yes?

What does a netmask have to do with a default route?
And again, the IP address of the router could never differ from the
IP address already negotiated with IPCP.

The proposal could be boiled down into a single bit saying "I've got
routes to the universe and I'm willing to forward your packets."

> If the requirement were multiple routes and/or the routes were dynamic
> I'd say ok to RIP, OSPF, etc... (btw: have you ever deployed OSPF or RIP 
> on a dial-in box with 2000 interfaces?  I have.  It can be, ahem, 
> difficult to manage. ahem. please pass the motrin. ]

Ever hear of the story about the camel's nose?  My reading of the
requirements are that they want far more than a single, simple
default route.  When they realize that, another IPCP option will be
proposed with a single traffic type value.  When that is discovered
to be simplistic for policy routing, there will be another proposal,
and so forth.

> > That sounds like a need for far fancier routing than that proposed.
> > Have the advocates for this proposal looked at "policy routing"?
>
> Your point about policy is a good one.  I suspect there is some policy
> involved (i.e. packet classification, etc...)  But having said that I'm
> not sure it matters for this discussion.

On the contrary, if the proposal does not satisfy its osstensible 
requirements, then it should be rejected on those grounds alone.

> >>BTW, we work with 15-20 service providers world wide and only 1 has a
> >>routing protocol (RIP) enabled in the CPE.
>
> I'm actually suprised anyone would do this.  The "1" must be brave (or 
> foolish; sometimes the same thing :-)
>
> > 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.
>
> I think he's responding to their need, not subverting their decision.  I 
> suspect they're asking for this...  (voice of the market, etc... blah blah)

I suspect that there is some confusion about what those 15-20 customers
really want and are really doing.  I bet the one customer using RIP 
is not foolish or brave but is using it only for the usual, entirely
safe purpose of announcing default routes.

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 19 May 2003 10:05:16 -0600 (MDT)

> well, not sure I agree.  How is the CPE to know who the RIP packet
> came from?  AH?  what if just as the link comes up someone outside
> (who knows this will work) injects some RIP packets?

Please investigate RIP.  You are supposed to ignore RIP packets from
distant networks.  

> I wish I could trust the source IP, but I'm not sure I can.

In this case, what would be the point of a forged RIP packet?
A bad guy could at most turn on the routing that you say is desirable.

If you are worried about authentication and authorization, then
RIPv2 has far better A&A facilities than IPCP.

> I can.  My instinct is that it would be fragile.

On what is your instinct based?  This is an engineering issue, so
while instincts and intuition can be good pointers, they are only
pointers to concrete problems or dangers.

> ...
> granted it's not much of a negotiation, but I think the goal was to end
> up with two static routes, which would allow some policy to exist which
> says "packets to this net go through this link and packet to everything
> else go through the other link".
>
> So, a default route through the "primary" link would work, but what is
> needed is a net/mask pair to specify the other link.  I think this is
> what is "communicated" via the IPCP option (which is granted, not 
> negotiated,but the CPE could reject it...)

How does one PPP peer know about the netmask and IP address for the
other PPP peer?

> really? I'm not sure what "peer" is in this context.  I'm thinking CPE
> box and large ISP concentrator.  The concentrator wants to offer some
> links which are used to route to a special network.  It needs to 
> communicate what the route should be.

We are talking about PPP.  In this context, "peer" has a fixed and
well known meaning.  The peer is the box sending IPCP packets.

> as I said before, it's not the default route that is the interesting 
> part.  It's the other-link/other-route.
>
> sorry, no.  The main link has the default route but I suspect the 
> secondary link needs a net/mask pair to define routing to it.

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?

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 20 May 2003 08:02:54 -0600 (MDT)

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

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

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

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

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

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

  - what is the difference between the traffic for the two links?  Does
      it differ only by IP address?

  - how do the two pairs of PPP state machine ensure that they are not
     crossed?  Would you use some extension of endpoint discriminators?

   - why do you need a netmask for a point-to-point link?

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

---

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

> you're joking, right?  there must be 5,000 implementation of RIP out
> there.  I've certainly writen 4-5 myself. (sad to say).

I do not believe there are 5000 implementations of RIP, but that there
are more installations than 5000.  I'm still curious about where your
4-5 implementations landed, but that's just irrelevant, nosey curiosity
about stuff that's none of my business.

> ...
> yes, exactly. The CO PPP peer would (I presume) like to tell the
> CPE PPP peer that certain links have a static route.

Are you talking about G3 phones or something else?

> Each link has only one address.

Are there 2 or 4 IP addresses total?  IPCP does not negotiate addresses
for "links" but for PPP peers.  Sometimes both PPP peers negotiate
the same address or one peer has not address so that the link can be
said to have one address.

Modulo my confusion about the scenario, the most likely case I can
imagine is 3 IP addresses, 1 for the CPE, and 1 for each of the two
CO instances.  I can get 4 addresses by assuming the "gaming" involves
RFC 1918 addresses.

> ...
> If by "pair of PPP peers" you mean two things located in the same box, 
> then we are not talking about the same thing.  Just to be clear, I am
> describing two independant PPP session.  One session from a CPE box to
> a CO concentrator which has the default route and one session from the
> same CPE box to the same CO concentrator over a different link (perhaps
> physical but possibly virtual) which has a static route to a single
> network.
>
> They are not related or coordinated (as far as PPP goes).  They just 
> come  from the same box and go to the same box.

Yes, but what happens to IP traffic?  Say the non-default-route PPP link
goes down.  By the usual rules, the "game" traffic should now use the
default-route PPP link.  Is that desired in this case?

How does the CPE know which PPP link is which?  Does it just assume
that the PPP link with the non-default route is for gaming?

On the other hand, if the CPE knows gaming by manual configuration
and CHAP username, then why does it need any IPCP, RIP, or DHCP bits?
Why can't that manual conguration say "use this PPP link for game packets"
intead of "use this PPP link for anything with the right route"?

> I can't speak to payload, but the one link carries all the default 
> traffic and the other link carries only traffic to/from the single 
> static network.

How does the CPE know that it should put this special, ill defined
traffic into IP packets with a "static" IP address?  

Since there is to be a "static network," how does the CPE know about it?

> Good point.  I suspect the answer has something to do with operational 
> requirements/constraints.  I don't think, however, that separate 
> parallel networks are completely uncommon.  Certainly folks like UUNet 
> and PSI have (in the way back past) used them for multicast traffic.
> I suspect gaming traffic is operationally like multicast... (if you 
> squint hard :-)

Yes, but I think those parallel PPP links were rather more static.
At least, they didn't use an IPCP option for routing.

My best guess of the instant is that what is really wanted is not an
IPCP option carrying a route, but something carrying a netmask and a
bit that says "DO NOT use this link for anything except packets to
this network."  It sounds as if you would put default-route options
into all IPCP Configure-Requests except the special "gaming" links.