Vernon,
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?
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.
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.
Thanks...
doug
BTW, we work with 15-20 service providers world wide and only 1 has a
routing protocol (RIP) enabled in the CPE.
-----Original Message-----
From: Vernon Schryver
To: ietf-ppp@xxxxxxxxx
Sent: 5/12/03 8:27 PM
Subject: RE: Extending IPCP for Route Table Entries
> From: Doug Kehn <dkehn@xxxxxxxxxxxxx>
> I agree with your comments. However, most service providers don't use
the
> available routing protocols (???).
On the contrary, almost all service providers use the available routing
protocols somewhere, even if not on their end-user PPP links. What
hardware can't announce a RIP route? What hardware that might support
such a new option could not at least as easily synthesize a RIP
announcement.
> I believe it would be okay to "put
our
> collective feet down and stop allowing such bad ideas." But until it
is
> done so publicly, rogue protocol extensions may prevail (i.e. I've yet
to
> find an RFC for IPCP option 144).
>
> My goal was to come up with an admissible solution/compromise at the
PPP
> layer or to have the working group put its foot and say no. I would
hate
> for another non-IETF sanctioned protocol extension prevail.
An RFC saying "STOP BEING STUPID" would be a good idea.
> 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."
Among the problems with putting routing into IPCP is that it is
cannot advertise the route more than once, because you really don't
want to re-negotiate IPCP more than once, because so much of this
drek hardware is junk and cannot.
But if you only announce the route once, then you may as well do
what PPP implementations have done since before there was PPP and
there was only SLIP. That is to install a default route to the PPP
(or SLIP) peer.
]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]
] From: Bernard Aboba <aboba@xxxxxxxxxxxxx>
] ...
] I believe that "putting our collective feet down" would require a
change
] in the IANA allocations policy for IPCP code points. Today this is
"first
] come first served", no?
Why do you say that IPCP types are "first come first served"? I
thought we fixed that problem that a long time ago.
On http://www.iana.org/numbers.html I see something about ordering
PPP protocol numbers, but nothing about IPCP.
] We now have the following proposals for (additional) uses of IPCP:
]
]
http://www.ietf.org/internet-drafts/draft-song-pppext-sip-support-02.txt
]
http://www.ietf.org/internet-drafts/draft-song-pppext-mipv6-support-00.t
xt
]
http://www.ietf.org/internet-drafts/draft-ietf-pppext-ipv6-dns-addr-01.t
xt
The IPv6 DNS extension is a mistake, but probably forced on us because
we failed to stop Microsoft from perpetrating the IPv4 predecessor.
The other two have expired and are about to expire. Why are those
other two drafts more persuasive or "standard" than the following:
http://www.ietf.org/internet-drafts/draft-terrell-iptx-dns-req-iptx-ip-a
dd-spec-03.pdf
http://www.ietf.org/internet-drafts/draft-terrell-math-quant-new-para-re
defi-bin-math-04.pdf
Vernon Schryver vjs@xxxxxxxxxxxx
|
