From owner-ietf-ppp@merit.edu  Mon May 12 17:33:05 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04585
	for <pppext-archive@lists.ietf.org>; Mon, 12 May 2003 17:33:04 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id DD05591265; Mon, 12 May 2003 17:35:47 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id A659691266; Mon, 12 May 2003 17:35:47 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 6DF6291265
	for <ietf-ppp@trapdoor.merit.edu>; Mon, 12 May 2003 17:35:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 4A1B85DEDA; Mon, 12 May 2003 17:35:46 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from david.siemens.com (david.siemens.com [194.138.160.5])
	by segue.merit.edu (Postfix) with ESMTP id 09DEC5DED7
	for <ietf-ppp@merit.edu>; Mon, 12 May 2003 17:35:46 -0400 (EDT)
Received: from mail-usa.sbs.siemens.com (mail-usa.sbs.siemens.com [129.73.68.4])
	by david.siemens.com (8.11.7/8.11.7) with ESMTP id h4CLZlI01222
	for <ietf-ppp@merit.edu>; Mon, 12 May 2003 17:35:47 -0400 (EDT)
Received: from yogi.inside.efficient.com ([165.218.188.2])
	by mail-usa.sbs.siemens.com (8.11.6/8.11.6) with ESMTP id h4CLZkF01344
	for <ietf-ppp@merit.edu>; Mon, 12 May 2003 17:35:46 -0400 (EDT)
Received: by yogi.inside.efficient.com with Internet Mail Service (5.5.2653.19)
	id <KZB9Z29T>; Mon, 12 May 2003 16:35:43 -0500
Message-ID: <CD779E609614D611A3FC00508B0F1CB63A51A0@pebbles.inside.efficient.com>
From: Doug Kehn <dkehn@efficient.com>
To: "'ietf-ppp@merit.edu'" <ietf-ppp@merit.edu>
Subject: Extending IPCP  for Route Table Entries
Date: Mon, 12 May 2003 16:35:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

All,

I would like to open a discussion on the possibilities for extending IPCP to
allow the negotiation of route table entries.  The topic of adding route
information to PPP has been brought up in the DSL Forum.  However, to the
best of my knowledge, the DSL Forum has not approached the IETF regarding
this topic.  Currently, some PPPoE capable BRASs have implemented PADN (see
draft-carrel-info-pppoe-ext-00.txt) as a way a add route information over
PPP links.  This facility only suffices the need for PPPoE links.  A more
general approach would be to extend PPP itself.  To jump start the
discussion, I've included a draft RFC (see below) that oulines a method for
extending IPCP that might be used to fulfill the need.

Thanks...
doug



INTERNET-DRAFT                                                 Doug Kehn
draft-kehn-info-ppp-ipcp-ext-00.txt              Efficient Networks Inc.
Category: Informational                                         May 2003
Expires: November 2003

           PPP Internet Protocol Control Protocol Extensions
                                  for
                          Route Table Entries

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ieft/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   The Point-to-Point Protocol (PPP) [1] provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.  PPP
   defines a family of Network Control Protocols (NCPs) for establishing
   and configuring different network-layer protocols.  The PPP Internet
   Protocol Control Protocol (IPCP) [2] defines the NCP for establishing
   and configuring the Internet Protocol (IP) [3].

   This document extends IPCP by defining the negotiation of IP route
   table entries.  This extension provides added functionality but is
   optional and preserves compatibility.

1. Introduction



Kehn                          Informational                     [Page 1]

INTERNET DRAFT                                                  May 2003


   PPP is widely used by broadband service providers as the protocol of
   choice for connecting hosts to the Internet.  PPP is popular because
   it is a well-known protocol that has been utilized by dial-up service
   providers for many years.  PPP also provides per-user access control,
   billing, etc.  These later features of PPP are the most appealing to
   providers.  In recent years, PPP has seen two transport extensions
   emerge to support broadband access.  These transports are PPP over
   Ethernet (PPPoE) [5] and PPP over AAL5 (PPPoA) [6].  With the
   emergence of broadband, the PPP client is migrating from the
   subscribers PC to the broadband customer premise equipment (CPE).

   Broadband provides more bandwidth to the subscriber.  Broadband
   service providers are wanting to utilize this additional bandwidth to
   provide additional services to subscribers.  Service Providers, for
   obvious reasons, desire to isolate these additional services from
   standard Internet service.  As stated earlier, PPP provides the per-
   user access control, billing, etc.  This makes PPP a logical choice
   for providing these additional services.  PPP also allows the service
   provider to utilize its investment in networking hardware used to
   provide standard Internet access.

   If PPP is to be used for both Internet access and additional service
   access, PPP hosts (whether residing in the PC or CPE) must be able to
   establish multiple PPP links.  The presence of multiple PPP links can
   complicate packet routing decisions in the host.  This document
   proposes an extension to IPCP to address the packet routing issues
   induced in the presence of multiple PPP links.  The extension
   provides the ability to add route table entries for specific PPP
   interfaces.

2. Conventions

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [4].

3. Additional IPCP Configuration Option

3.1 Route-Add

   Description

      This configuration option defines a method for negotiating zero or
      more route table entries for the PPP interface on the local
      (client) end of the link.  If the local peer supports the Route-
      Add option, it MUST include the Route-Add option with a length of
      2 to its IPCP Configure Request.  The remote (server) peer, if it
      supports the Route-Add option, SHOULD return the appropriate



Kehn                          Informational                     [Page 2]

INTERNET DRAFT                                                  May 2003


      number of Route-Add option entries in its IPCP response.  If the
      remote peer does not wish to add any route entries to the local
      peer, the remote peer MUST NOT include the Route-Add option in its
      response.  The local peer MUST accept this response as an
      indication that the remote peer does not wish to add any routes to
      the interface.

      If the remote peer does not support the Route-Add option (e.g.
      current implementations), the remote peer MAY reject the Route-Add
      option.  This is an indication to the local peer that the remote
      peer does not support the Route-Add option and IPCP negotiation
      MUST continue without it.

      A Route-Add option entry with a Route-Address and Route-Mask of
      zero indicates a default route.

      Any routes added via the Route-Add option MUST be deleted when the
      IPCP layer terminates.

   A summary of the Route-Add option format is shown below.  The fields
   are transmitted from left to right and are in network-byte order.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |        Route-Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         Route-Address (cont)      |        Route-Mask
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         Route-Mask (cont)         |        Route-Next-Hop
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         Route-Next-Hop (cont)     |        Route-Metric
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         Route-Metric (cont)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      (To be assigned by IANA)

   Length

      18+

   Route-Address

      The four octet field defining the destination network or host
      address.



Kehn                          Informational                     [Page 3]

INTERNET DRAFT                                                  May 2003


   Route-Mask

      The four octet field defining the subnet mask for the route.  For
      host route entries, this field MUST be set to all one's.

   Route-Next-Hop

      The four octet field defining the route's next hop.  This field
      MAY be zero if the next hop for the route is the remote peer.

   Route-Metric

      The four octet field defining the metric value for the route.

Normative References

   [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51,
   RFC 1661, Daydreamer, July 1994

   [2] McGregor, G., "PPP Internet Control Protocol", RFC 1332, Merit,
   May 1992.

Informative References

   [3] Postel, J., "Internet Protocol", RFC 971, USC/Information
   Sciences Institute, September 1981.

   [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
   Levels", BCP 14, RFC 2119, March 1997.

   [5] Mamakos, et. al., "A Method for Transmitting PPP Over Ethernet
   (PPPoE)", RFC 2516, February 1999.

   [6] Gross, et. al., "PPP Over AAL5", RFC 2364, July 1998.

Security Considerations

   Security issues are not discussed in this memo.

IANA Considerations

   Requires IPCP option number assignment for the Route-Add option.

Acknowledgments

   This draft was inspired by the "work in progress" <draft-carrel-info-
   pppoe-ext-00.txt>.




Kehn                          Informational                     [Page 4]

INTERNET DRAFT                                                  May 2003


   Special thanks goes to Stephen Lyda (Efficient Networks, Inc.), and
   Dan Dworin (Efficient Networks, Inc.) for their feedback.

Author's Address

   Doug Kehn
   Efficient Networks Inc.
   4849 Alpha Road
   Dallas, TX  75244
   USA

   Phone: +1 972 852 1000
   EMail: dkehn@efficient.com

Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.










Kehn                          Informational                     [Page 5]


From owner-ietf-ppp@merit.edu  Mon May 12 17:43:32 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04912
	for <pppext-archive@lists.ietf.org>; Mon, 12 May 2003 17:43:32 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id BCD6591266; Mon, 12 May 2003 17:45:34 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 9079891267; Mon, 12 May 2003 17:45:34 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 8076C91266
	for <ietf-ppp@trapdoor.merit.edu>; Mon, 12 May 2003 17:45:33 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 6F2145DEE1; Mon, 12 May 2003 17:45:33 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3])
	by segue.merit.edu (Postfix) with ESMTP id 51C3F5DEDF
	for <ietf-ppp@merit.edu>; Mon, 12 May 2003 17:45:29 -0400 (EDT)
Received: (from vjs@localhost)
	by calcite.rhyolite.com (8.12.9/8.12.9) id h4CLjN44017286
	for ietf-ppp@merit.edu env-from <vjs>;
	Mon, 12 May 2003 15:45:23 -0600 (MDT)
Date: Mon, 12 May 2003 15:45:23 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
Message-Id: <200305122145.h4CLjN44017286@calcite.rhyolite.com>
To: ietf-ppp@merit.edu
Subject: Re: Extending IPCP  for Route Table Entries
References: <CD779E609614D611A3FC00508B0F1CB63A51A0@pebbles.inside.efficient.com>
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

> From: Doug Kehn <dkehn@efficient.com>

> I would like to open a discussion on the possibilities for extending IPCP to
> allow the negotiation of route table entries.  The topic of adding route
> information to PPP has been brought up in the DSL Forum.  However, to the
> best of my knowledge, the DSL Forum has not approached the IETF regarding
> this topic.  Currently, some PPPoE capable BRASs have implemented PADN (see
> draft-carrel-info-pppoe-ext-00.txt) as a way a add route information over
> PPP links.  This facility only suffices the need for PPPoE links.  A more
> general approach would be to extend PPP itself.  To jump start the
> discussion, I've included a draft RFC (see below) that oulines a method for
> extending IPCP that might be used to fulfill the need.

Let's put our collective feet down and stop allowing such bad ideas.
It makes no sense to extend IPCP to carry routes.  There are plenty
of existing standards for that.  For example, you could do what has
been done for literally decades and use RIP.  You could even use
authentication in RIPv2.  If you don't like RIP, you can use
Router-Discovery, OSPF, BGP, and a zillion other routing protocols.

I can't seem to find draft-carrel-info-pppoe-ext-00.txt or anything
with the string "carrel" on ftp.isi.edu.


Vernon Schryver    vjs@rhyolite.com


From owner-ietf-ppp@merit.edu  Mon May 12 18:22:43 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06894
	for <pppext-archive@lists.ietf.org>; Mon, 12 May 2003 18:22:43 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 4DD8691267; Mon, 12 May 2003 18:25:28 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 1B74491268; Mon, 12 May 2003 18:25:28 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 0D70691267
	for <ietf-ppp@trapdoor.merit.edu>; Mon, 12 May 2003 18:25:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id EC0385DEF1; Mon, 12 May 2003 18:25:26 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from david.siemens.com (david.siemens.com [194.138.160.5])
	by segue.merit.edu (Postfix) with ESMTP id 9D6AE5DED6
	for <ietf-ppp@merit.edu>; Mon, 12 May 2003 18:25:26 -0400 (EDT)
Received: from mail-usa.sbs.siemens.com (mail-usa.sbs.siemens.com [129.73.68.4])
	by david.siemens.com (8.11.7/8.11.7) with ESMTP id h4CMPRI11731;
	Mon, 12 May 2003 18:25:27 -0400 (EDT)
Received: from yogi.inside.efficient.com ([165.218.188.2])
	by mail-usa.sbs.siemens.com (8.11.6/8.11.6) with ESMTP id h4CMPQF12137;
	Mon, 12 May 2003 18:25:26 -0400 (EDT)
Received: by yogi.inside.efficient.com with Internet Mail Service (5.5.2653.19)
	id <KZB9ZJ3Q>; Mon, 12 May 2003 17:25:23 -0500
Message-ID: <CD779E609614D611A3FC00508B0F1CB63A51A1@pebbles.inside.efficient.com>
From: Doug Kehn <dkehn@efficient.com>
To: "'Vernon Schryver '" <vjs@calcite.rhyolite.com>,
        "'ietf-ppp@merit.edu '" <ietf-ppp@merit.edu>
Subject: RE: Extending IPCP  for Route Table Entries
Date: Mon, 12 May 2003 17:25:21 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

Vernon,

I agree with your comments.  However, most service providers don't use the
available routing protocols (???).  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.

I've included the draft-carrel-info-pppoe-ext-00.txt for your review.

...doug



PPP Working Group                              David Carrel, Dan Simone,
INTERNET DRAFT                                    Che-Lin Ho, Tom Stoner
Category: Informational                           Redback Networks, Inc.
Title: draft-carrel-info-pppoe-ext-00.txt
Date: May 2000



   Extensions to a Method for Transmitting PPP Over Ethernet (PPPoE)
                  <draft-carrel-info-pppoe-ext-00.txt>


                          Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt


     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.



   The distribution of this memo is unlimited.  It is filed as <draft-
   carrel-info-pppoe-ext-00.txt>, and expires 30 November, 2000.  Please
   send comments to the authors.


Abstract

   The Point-to-Point Protocol (PPP) [1] provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.
   PPPoE [2] describes how to build PPP sessions and encapsulate PPP
   packets over Ethernet.

   This document describes extensions to PPPoE.  These extensions
   provide added functionality, but are optional and preserve
   compatibility.






Carrel                                                  	[Page1]

INTERNET DRAFT                                                  May 2000


1. Introduction

   PPP over Ethernet (PPPoE) [2] provides the ability to connect a
   network of hosts over a simple Ethernet bridging access device to a
   remote Access Concentrator.  With this model, each host utilizes it's
   own PPP stack and the user is presented with a familiar user
   interface.  Access control, billing and type of service can be done
   on a per-user, rather than a per-site, basis.

   The flexibility provided by PPPoE has inspired the development of
   several extensions to the protocol.  These extensions provide for
   networking level enhancements as well as session level enhancements
   aimed at the user experience.  These enhancements maintain backwards
   compatibility with the core PPPoE protocol.


2. Conventions

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in [3].


3. Discovery Stage

   The PADI, PADO, PADR, PADS and PADT defined in [2] are unchanged.
   The following discovery packets have been added.  Since this is the
   Discovery Stage, an ETHER_TYPE of 0x8863 MUST be used.

3.1 The PPPoE Active Discovery Message (PADM) packet

   An Access Concentrator MAY send a PADM at any time while a session is
   active to convey informational messages to the Host.  The
   DESTINATION_ADDR is the unicast address of the Host.  The CODE field
   is set to 0xd3 and the SESSION_ID MUST be set to the current (active)
   SESSION_ID value.

   Use of this packet is optional for both the Access Concentrator and
   the Host.  A PADM packet MUST contain at least one TAG of type HURL
   or MOTM and SHOULD NOT contain any other TAGs.  Additional messaging
   TAGs may be defined in the future that are appropriate for PADM
   packets.









Carrel                                                  	[Page2]

INTERNET DRAFT                                                  May 2000


3.2 The PPPoE Active Discovery Network (PADN) packet

   An Access Concentrator MAY send a PADN at any time while a session is
   active to convey network level information to the Host.  The
   DESTINATION_ADDR is the unicast address of the Host.  The CODE field
   is set to 0xd4 and the SESSION_ID MUST be set to the current (active)
   SESSION_ID value.

   An Access Concentrator SHOULD send a PADN as soon as possible after
   an NCP completes negotiation.  That PADN SHOULD only contain TAGs
   that are appropriate for that NCP.  Since there is no limit on the
   number of PADNs that may be sent, it is appropriate to send a PADN
   for each NCP.

   Use of this packet is optional for both the Access Concentrator and
   the Host, though in general it is expected that it will only be sent
   by the Access Concentrator.  A PADN packet MUST contain at least one
   TAG of type IP_ROUTE_ADD and SHOULD NOT contain any other TAGs.
   Additional network TAGs may be defined in the future that are
   appropriate for PADN packets.


4. PPPoE Clarifications

   Since publication of [2], discussions have taken place which have
   identified some areas of ambiguity.  To avoid confusion and inter-
   operability problems, we are providing further clarification.  This
   is a clarification of [2] and does not change [2] in any way.























Carrel                                                  	[Page3]

INTERNET DRAFT                                                  May 2000


4.1 Service Selection

   Service Selection is a key feature of PPPoE.  It allows for the Host
   to request a specific service and it also allows for the Access
   Concentrator to "advertise" a list of services.  Service Selection is
   optional, but if the Host and Access Concentrator wish to participate
   in it, they should operate as indicated below.  User Interface (UI)
   issues are discussed as well.

   If either the Host or Access Concentrator does not wish to
   participate in Service Selection, then they SHOULD use a Service-Name
   TAG with zero length, indicating that any service is acceptable.
   This can be done in the PADI, PADO, PADR and PADS packets to indicate
   that PPPoE Service Selection is not being used and PPP authentication
   should be used to determine the user's "service".  In this case, no
   UI is needed beyond the PPP UI.

   Occasionally the Host will know in advance that it wishes to use a
   specific PPPoE Service.  In that case, it MAY put that service in a
   Service-Name TAG in both the PADI and PADR.  For this case, the UI
   should allow the Service-Name to be specified prior to beginning
   PPPoE Discovery.  Our anticipation is that this case will be very
   rare.  Since PPPoE has no security, Service Selection should be
   considered informational.  PPP Authentication can be trusted and
   should be used to identify the user when there is no desire to
   "discover" services.

   Dynamic Service Selection happens when the Host wishes to "discover"
   what services are out there.  The Host does not put a specific
   Service-Name value in the PADI and waits for a list of Service-Name
   TAGs from the Access Concentrator(s).  This is accomplished by
   sending a PADI with a zero length Service-Name TAG.  This indicates
   that the Host is trying to discover all services that are available.
   Each Access-Concentrator MAY then reply with a PADO listing multiple
   services.  If the Host is capable of doing Service Selection, it
   SHOULD send a PADI and receive the PADO(s) before accepting any user
   input.  It SHOULD then present the list of Services to the user and
   wait for the user to select one prior to sending the PADR.  The PADR
   is the point where the Host "selects" its service.  The UI should
   display the list of discovered Services.  As an added value, it could
   remember commonly chosen Services and could even remember the last
   PPP username used for each Service.  The Host MUST remember which
   Access Concentrator sent which Service-Name TAGs so that the PADR is
   sent to the correct Access Concentrator.







Carrel                                                  	[Page4]

INTERNET DRAFT                                                  May 2000


5. PPP Considerations

   PADM packets SHOULD be sent after PPP authentication has completed in
   order to provide per-user messaging.  Also PADM packets containing
   HURL TAGs SHOULD be sent after an NCP is established so that network
   connectivity is available for the web browser.  However a Host
   implementation MUST be able to receive one at any time after PPPoE
   session establishment.


6. Security Considerations

   All data confidentiality and authenticity issues are left to higher
   layers such as PPP or IP.  As such, any information sent in a PADM
   packet can not be protected.  To present data to a user in a secure
   manner, HURLs can be used to establish a connection over higher
   layers that do provide security.  Service Selection is NOT secure and
   should only be used informationally.


7. Acknowledgments

   Copious amounts of text were stolen from RFC 2516.


8. References

   [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
   1661, July 1994

   [2] Mamakos, et. al., "A Method for Transmitting PPP Over Ethernet
   (PPPoE)", RFC 2516, February 1999

   [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
   Levels", BCP 14, RFC 2119, March 1997.

   [4] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
   2279, January 1998.

   [5] Berners-Lee, T., Masinter, L., and McCahill, M.  "Uniform
   Resource Locators (URL)", RFC 1738, December 1994










Carrel                                                  	[Page5]

INTERNET DRAFT                                                  May 2000


Appendix A

   TAG_TYPES and TAG_VALUES

   0x0111 HURL

      This TAG MAY be added to PADM packets by the Access Concentrator.
      It contains a URL that the Host MAY pass to a web browser for
      presentation to the user.  The TAG_VALUE contains a standard URL
      [5].  It is an UTF-8 string which is not NULL terminated.

   0x0112 MOTM

      This TAG MAY be added to PADM packets by the Access Concentrator.
      It contains a Message Of The Minute (MOTM) that the Host MAY
      display to the user.  The TAG_VALUE contains an UTF-8 string which
      is not NULL terminated.  It is a text message that is presentable
      to the user on the Host.

   0x0121 IP_ROUTE_ADD

      This TAG MAY be added to PADN packets by the Access Concentrator.
      It contains a IP route that MAY be used by the Host to populate
      it's routing table.  The behavior of PPP is not defined in terms
      of what routes should be installed if multiple concurrent PPP
      sessions exist.  Many client implementations will install a
      default route but that only works if one PPP session is active.
      When multiple PPPoE sessions are active, the IP_ROUTE_ADD TAG can
      provide a more granular set of routes to the client.  The
      TAG_VALUE contains four 32 bit integers in network byte order.
      The first integer contains a destination network number and the
      second contains a destination network mask.  The third integer
      contains the gateway IP address.  The fourth integer contains a
      metric value.  The destination of the route is always assumed to
      be the remote end of the PPP link.  If the first two integers are
      zero this indicates a default route.  In general the gateway IP
      address will be the same as the Access Concentrator's IP address
      on that PPP session, because use of this tag is only intended to
      provide routing information about the first hop (ie. which PPP
      interface the client should use).  Any routes installed as a
      result of the IP_ROUTE_ADD TAG being received, SHOULD be removed
      when the PPPoE session terminates.









Carrel                                                  	[Page6]

INTERNET DRAFT                                                  May 2000


Appendix B

   The following are some example packets:

   A PADM packet:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Host_mac_addr                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Host_mac_addr (cont)     | Access_Concentrator_mac_addr  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Access_Concentrator_mac_addr (cont)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    ETHER_TYPE = 0x8863        | v = 1 | t = 1 |  CODE = 0xd3  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     SESSION_ID = 0xNNNN       |      LENGTH = 0x001a          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      TAG_TYPE = 0x0111        |    TAG_LENGTH = 0x0016        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     0x68      |     0x74      |     0x74      |     0x70      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     0x3a      |     0x2f      |     0x2f      |     0x77      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     0x77      |     0x77      |     0x2e      |     0x72      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     0x65      |     0x64      |     0x62      |     0x61      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     0x63      |     0x6b      |     0x2e      |     0x63      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     0x6f      |     0x6d      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


















Carrel                                                  	[Page7]

INTERNET DRAFT                                                  May 2000


   A PADN packet: This contains two IP_ROUTE_ADD TAGs.  The first is the
   route "10.1.1.0 255.255.255.0".  The second is "20.2.0.0
   255.255.0.0".  The Access Concentrator's IP address for the PPPoE
   session is 10.1.1.1.

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Host_mac_addr                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Host_mac_addr (cont)     | Access_Concentrator_mac_addr  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |             Access_Concentrator_mac_addr (cont)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    ETHER_TYPE = 0x8863        | v = 1 | t = 1 |  CODE = 0xd4  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     SESSION_ID = 0xNNNN       |      LENGTH = 0x0028          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      TAG_TYPE = 0x0121        |    TAG_LENGTH = 0x0010        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          0x0a010100                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          0xffffff00                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          0x0a010101                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          0x00000001                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      TAG_TYPE = 0x0121        |    TAG_LENGTH = 0x0010        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          0x14020000                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          0xffff0000                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          0x0a010101                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          0x00000001                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+













Carrel                                                  	[Page8]

INTERNET DRAFT                                                  May 2000


Authors' Addresses:

   David Carrel <carrel@redback.com>
   Dan Simone <dan@redback.com>
   Che-Lin Ho <che@redback.com>
   Tom Stoner <tstoner@redback.com>
   Redback Networks, Inc.
   350 Holger Way
   San Jose, CA  95134
   United States of America









































Carrel                                                  	[Page9]


-----Original Message-----
From: Vernon Schryver
To: ietf-ppp@merit.edu
Sent: 5/12/03 4:45 PM
Subject: Re: Extending IPCP  for Route Table Entries

> From: Doug Kehn <dkehn@efficient.com>

> I would like to open a discussion on the possibilities for extending
IPCP to
> allow the negotiation of route table entries.  The topic of adding
route
> information to PPP has been brought up in the DSL Forum.  However, to
the
> best of my knowledge, the DSL Forum has not approached the IETF
regarding
> this topic.  Currently, some PPPoE capable BRASs have implemented PADN
(see
> draft-carrel-info-pppoe-ext-00.txt) as a way a add route information
over
> PPP links.  This facility only suffices the need for PPPoE links.  A
more
> general approach would be to extend PPP itself.  To jump start the
> discussion, I've included a draft RFC (see below) that oulines a
method for
> extending IPCP that might be used to fulfill the need.

Let's put our collective feet down and stop allowing such bad ideas.
It makes no sense to extend IPCP to carry routes.  There are plenty
of existing standards for that.  For example, you could do what has
been done for literally decades and use RIP.  You could even use
authentication in RIPv2.  If you don't like RIP, you can use
Router-Discovery, OSPF, BGP, and a zillion other routing protocols.

I can't seem to find draft-carrel-info-pppoe-ext-00.txt or anything
with the string "carrel" on ftp.isi.edu.


Vernon Schryver    vjs@rhyolite.com


From owner-ietf-ppp@merit.edu  Mon May 12 18:33:17 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07084
	for <pppext-archive@lists.ietf.org>; Mon, 12 May 2003 18:33:17 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 4BAF091268; Mon, 12 May 2003 18:36:02 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 1B3B891269; Mon, 12 May 2003 18:36:02 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 2FD3091268
	for <ietf-ppp@trapdoor.merit.edu>; Mon, 12 May 2003 18:36:01 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 0FB215DF07; Mon, 12 May 2003 18:36:01 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from internaut.com (unknown [64.38.134.99])
	by segue.merit.edu (Postfix) with ESMTP id 850215DF06
	for <ietf-ppp@merit.edu>; Mon, 12 May 2003 18:36:00 -0400 (EDT)
Received: from localhost (aboba@localhost)
	by internaut.com (8.10.2/8.10.2) with ESMTP id h4CMEgC16226;
	Mon, 12 May 2003 15:14:42 -0700
Date: Mon, 12 May 2003 15:14:42 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: Doug Kehn <dkehn@efficient.com>
Cc: "'Vernon Schryver '" <vjs@calcite.rhyolite.com>,
        "'ietf-ppp@merit.edu '" <ietf-ppp@merit.edu>
Subject: RE: Extending IPCP  for Route Table Entries
In-Reply-To: <CD779E609614D611A3FC00508B0F1CB63A51A1@pebbles.inside.efficient.com>
Message-ID: <Pine.LNX.4.53.0305121509410.15810@internaut.com>
References: <CD779E609614D611A3FC00508B0F1CB63A51A1@pebbles.inside.efficient.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

> I agree with your comments.  However, most service providers don't use the
> available routing protocols (???).  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).

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?

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.txt
http://www.ietf.org/internet-drafts/draft-ietf-pppext-ipv6-dns-addr-01.txt



From owner-ietf-ppp@merit.edu  Mon May 12 21:25:12 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10840
	for <pppext-archive@lists.ietf.org>; Mon, 12 May 2003 21:25:12 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 5A9EC9126A; Mon, 12 May 2003 21:27:57 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 2A3449126B; Mon, 12 May 2003 21:27:57 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 1A32A9126A
	for <ietf-ppp@trapdoor.merit.edu>; Mon, 12 May 2003 21:27:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id F3A935DF7A; Mon, 12 May 2003 21:27:56 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3])
	by segue.merit.edu (Postfix) with ESMTP id 27F675DEB6
	for <ietf-ppp@merit.edu>; Mon, 12 May 2003 21:27:55 -0400 (EDT)
Received: (from vjs@localhost)
	by calcite.rhyolite.com (8.12.9/8.12.9) id h4D1RsuR008158
	for ietf-ppp@merit.edu env-from <vjs>;
	Mon, 12 May 2003 19:27:54 -0600 (MDT)
Date: Mon, 12 May 2003 19:27:54 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
Message-Id: <200305130127.h4D1RsuR008158@calcite.rhyolite.com>
To: ietf-ppp@merit.edu
Subject: RE: Extending IPCP  for Route Table Entries
References: <CD779E609614D611A3FC00508B0F1CB63A51A1@pebbles.inside.efficient.com>
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

> From: Doug Kehn <dkehn@efficient.com>

> 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@internaut.com>

] ...
] 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.txt
] http://www.ietf.org/internet-drafts/draft-ietf-pppext-ipv6-dns-addr-01.txt

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-add-spec-03.pdf
http://www.ietf.org/internet-drafts/draft-terrell-math-quant-new-para-redefi-bin-math-04.pdf


Vernon Schryver    vjs@rhyolite.com


From owner-ietf-ppp@merit.edu  Mon May 12 22:07:23 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11360
	for <pppext-archive@lists.ietf.org>; Mon, 12 May 2003 22:07:23 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id A4BDE9126B; Mon, 12 May 2003 22:10:09 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 6C2CD9126C; Mon, 12 May 2003 22:10:09 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 7084A9126B
	for <ietf-ppp@trapdoor.merit.edu>; Mon, 12 May 2003 22:10:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 606315DF57; Mon, 12 May 2003 22:10:08 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3])
	by segue.merit.edu (Postfix) with ESMTP id 520695DEA6
	for <ietf-ppp@merit.edu>; Mon, 12 May 2003 22:10:07 -0400 (EDT)
Received: (from vjs@localhost)
	by calcite.rhyolite.com (8.12.9/8.12.9) id h4D2A6lk017052
	for ietf-ppp@merit.edu env-from <vjs>;
	Mon, 12 May 2003 20:10:06 -0600 (MDT)
Date: Mon, 12 May 2003 20:10:06 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
Message-Id: <200305130210.h4D2A6lk017052@calcite.rhyolite.com>
To: ietf-ppp@merit.edu
Subject: RE: Extending IPCP  for Route Table Entries
References:  <200305130159.SAA10275@grigri.eng.ascend.com>
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

> From: Ignacio Goyret <igoyret@lucent.com>

> >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    vjs@rhyolite.com


From owner-ietf-ppp@merit.edu  Tue May 13 02:02:38 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19208
	for <pppext-archive@lists.ietf.org>; Tue, 13 May 2003 02:02:37 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 183019126E; Tue, 13 May 2003 02:05:24 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id DDE929126F; Tue, 13 May 2003 02:05:23 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id A7F179126E
	for <ietf-ppp@trapdoor.merit.edu>; Tue, 13 May 2003 02:05:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 915D45E026; Tue, 13 May 2003 02:05:21 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from albatross.tn.sw.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49])
	by segue.merit.edu (Postfix) with ESMTP id 1C6B75E01E
	for <ietf-ppp@merit.edu>; Tue, 13 May 2003 02:05:21 -0400 (EDT)
Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120])
	by albatross.tn.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h4D6540J003099;
	Tue, 13 May 2003 08:05:04 +0200 (MEST)
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55)
	id <KTVY6551>; Tue, 13 May 2003 08:05:17 +0200
Message-ID: <F8EFC4B4A8C016428BC1F589296D4FBF0385FB96@esealnt630.al.sw.ericsson.se>
From: "Jari Arkko (LMF)" <Jari.Arkko@lmf.ericsson.se>
To: "'Bernard Aboba'" <aboba@internaut.com>, Doug Kehn <dkehn@efficient.com>
Cc: "'Vernon Schryver '" <vjs@calcite.rhyolite.com>,
        "'ietf-ppp@merit.edu '" <ietf-ppp@merit.edu>
Subject: RE: Extending IPCP  for Route Table Entries
Date: Tue, 13 May 2003 08:04:47 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu


> 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 owner-ietf-ppp@merit.edu  Tue May 13 10:40:38 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15012
	for <pppext-archive@lists.ietf.org>; Tue, 13 May 2003 10:40:38 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id C035491284; Tue, 13 May 2003 10:43:24 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 93B4891285; Tue, 13 May 2003 10:43:24 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 6365A91284
	for <ietf-ppp@trapdoor.merit.edu>; Tue, 13 May 2003 10:43:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 7119C5DDA9; Tue, 13 May 2003 10:43:22 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from david.siemens.com (david.siemens.com [194.138.160.5])
	by segue.merit.edu (Postfix) with ESMTP id 0742B5DDA8
	for <ietf-ppp@merit.edu>; Tue, 13 May 2003 10:43:22 -0400 (EDT)
Received: from mail-usa.sbs.siemens.com (mail-usa.sbs.siemens.com [129.73.68.4])
	by david.siemens.com (8.11.7/8.11.7) with ESMTP id h4DEhNG28005;
	Tue, 13 May 2003 10:43:23 -0400 (EDT)
Received: from yogi.inside.efficient.com ([165.218.188.2])
	by mail-usa.sbs.siemens.com (8.11.6/8.11.6) with ESMTP id h4DEhMF13775;
	Tue, 13 May 2003 10:43:22 -0400 (EDT)
Received: by yogi.inside.efficient.com with Internet Mail Service (5.5.2653.19)
	id <KZB9ZRF7>; Tue, 13 May 2003 09:43:19 -0500
Message-ID: <CD779E609614D611A3FC00508B0F1CB63A51A6@pebbles.inside.efficient.com>
From: Doug Kehn <dkehn@efficient.com>
To: "'Vernon Schryver '" <vjs@calcite.rhyolite.com>,
        "'ietf-ppp@merit.edu '" <ietf-ppp@merit.edu>
Subject: RE: Extending IPCP  for Route Table Entries
Date: Tue, 13 May 2003 09:43:18 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

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@merit.edu
Sent: 5/12/03 8:27 PM
Subject: RE: Extending IPCP  for Route Table Entries

> From: Doug Kehn <dkehn@efficient.com>

> 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@internaut.com>

] ...
] 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@rhyolite.com


From owner-ietf-ppp@merit.edu  Tue May 13 10:55:13 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15374
	for <pppext-archive@lists.ietf.org>; Tue, 13 May 2003 10:55:12 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id ED62491285; Tue, 13 May 2003 10:57:59 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id B8C2691286; Tue, 13 May 2003 10:57:58 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 8E8C091285
	for <ietf-ppp@trapdoor.merit.edu>; Tue, 13 May 2003 10:57:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 790DE5DDB1; Tue, 13 May 2003 10:57:57 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3])
	by segue.merit.edu (Postfix) with ESMTP id 95E745DDA9
	for <ietf-ppp@merit.edu>; Tue, 13 May 2003 10:57:56 -0400 (EDT)
Received: (from vjs@localhost)
	by calcite.rhyolite.com (8.12.9/8.12.9) id h4DEvtXQ011434
	for ietf-ppp@merit.edu env-from <vjs>;
	Tue, 13 May 2003 08:57:55 -0600 (MDT)
Date: Tue, 13 May 2003 08:57:55 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
Message-Id: <200305131457.h4DEvtXQ011434@calcite.rhyolite.com>
To: ietf-ppp@merit.edu
Subject: RE: Extending IPCP  for Route Table Entries
References: <CD779E609614D611A3FC00508B0F1CB63A51A6@pebbles.inside.efficient.com>
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

> From: Doug Kehn <dkehn@efficient.com>

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

That problem has absolutely nothing to do with PPP.  We've been dealing
with that problem for literally decades.  It's what routing protocols
are all about.  Even before there was PPP, people had boxes with
multiple interfaces, such as a LAN and a dynamically dialed SLIP link.

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

That sounds like a need for far fancier routing than that proposed.
Have the advocates for this proposal looked at "policy routing"?


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

As I said before, reasonable PPP and SLIP implementations have for 
literally decades installed routes as needed when their links came up.

For just as long, people have also used RIP for the same purpose.
For example, the `routed` code in common UNIX flavors including IRIX,
Solaris, FreeBSD, and NetBSD can notice when an interface appears and
advertise a route.


> BTW, we work with 15-20 service providers world wide and only 1 has a
> routing protocol (RIP) enabled in the CPE.

There is a difference between fully enabling RIP and enabling RIP
to advertise a default route.  The first can adventurous, because
it implies listening to whatever RIP packets come from the customer.
The second is quite safe.  It's a standard feature in many PPP boxes
precisely for this purpose of telling CPE where to send packets.

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.


Vernon Schryver    vjs@rhyolite.com


From owner-ietf-ppp@merit.edu  Wed May 14 14:03:47 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29137
	for <pppext-archive@lists.ietf.org>; Wed, 14 May 2003 14:03:47 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id A887F912A4; Wed, 14 May 2003 14:06:33 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 75EA9912A6; Wed, 14 May 2003 14:06:33 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 64110912A4
	for <ietf-ppp@trapdoor.merit.edu>; Wed, 14 May 2003 14:06:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 4A0375E195; Wed, 14 May 2003 14:06:32 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3])
	by segue.merit.edu (Postfix) with ESMTP id 50D665E190
	for <ietf-ppp@merit.edu>; Wed, 14 May 2003 14:06:15 -0400 (EDT)
Received: (from vjs@localhost)
	by calcite.rhyolite.com (8.12.9/8.12.9) id h4EI5spt026363
	for ietf-ppp@merit.edu env-from <vjs>;
	Wed, 14 May 2003 12:05:54 -0600 (MDT)
Date: Wed, 14 May 2003 12:05:54 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
Message-Id: <200305141805.h4EI5spt026363@calcite.rhyolite.com>
To: ietf-ppp@merit.edu
Subject: Re: Extending IPCP  for Route Table Entries
References:  <3EC27CBF.4080501@heeltoe.com>
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

> From: Brad Parker <brad@heeltoe.com>

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


Vernon Schryver    vjs@rhyolite.com


From owner-ietf-ppp@merit.edu  Wed May 14 14:26:39 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29749
	for <pppext-archive@lists.ietf.org>; Wed, 14 May 2003 14:26:39 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 78107912A6; Wed, 14 May 2003 14:27:43 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 35112912A7; Wed, 14 May 2003 14:27:43 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 891FB912A6
	for <ietf-ppp@trapdoor.merit.edu>; Wed, 14 May 2003 14:27:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 696675E1A9; Wed, 14 May 2003 14:27:38 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130])
	by segue.merit.edu (Postfix) with ESMTP id F36015E1A8
	for <ietf-ppp@merit.edu>; Wed, 14 May 2003 14:27:37 -0400 (EDT)
Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10])
	by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4EIRTkc187812;
	Wed, 14 May 2003 14:27:29 -0400
Received: from cichlid.adsl.duke.edu (sig-9-65-210-236.mts.ibm.com [9.65.210.236])
	by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h4EIRSBO026664;
	Wed, 14 May 2003 12:27:28 -0600
Received: from cichlid.adsl.duke.edu (narten@localhost)
	by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h4EIRIZ05372;
	Wed, 14 May 2003 14:27:18 -0400
Message-Id: <200305141827.h4EIRIZ05372@cichlid.adsl.duke.edu>
To: "Bernard Aboba" <aboba@internaut.com>
Cc: "'ietf-ppp@merit.edu '" <ietf-ppp@merit.edu>
Subject: Reigning in "bad" extensions to PPP
In-Reply-To: Message from aboba@internaut.com
   of "Mon, 12 May 2003 15:14:42 PDT." <Pine.LNX.4.53.0305121509410.15810@internaut.com> 
Date: Wed, 14 May 2003 14:27:18 -0400
From: Thomas Narten <narten@us.ibm.com>
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

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

Bernard is right, unfortunately.

IMO, a document for PPP IANA Considerations is needed. At a minimum,
an IANA considerations document would define when and under what
conditions IANA should allocate code points. Right now, there are some
nume spaces where anyone can get a code point just by asking. It would
be quite reasonable for the WG to say "for standards track only" for
some of the number spaces, for example. For a recent example of how to
do this, see draft-aboba-radius-iana-07.txt, which the IESG approved
recently.

If you want to reign in bad uses of PPP, there are ways of documenting
that too, but it's a bit more work. One  possible example is:

     RFC 3427 "Change Process for the Session Initiation Protocol (SIP)"

That document contains the steps that must be followed for extending
SIP. Having such documents makes it a lot easier for the IESG to say
"no" to bad requests, since we would be speaking for the PPP
community.

Thomas


From owner-ietf-ppp@merit.edu  Wed May 14 14:30:11 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29829
	for <pppext-archive@lists.ietf.org>; Wed, 14 May 2003 14:30:11 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 2D869912A7; Wed, 14 May 2003 14:33:02 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id CC8F0912A8; Wed, 14 May 2003 14:33:01 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 096B4912A7
	for <ietf-ppp@trapdoor.merit.edu>; Wed, 14 May 2003 14:32:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id DDA495E1B0; Wed, 14 May 2003 14:32:34 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.129])
	by segue.merit.edu (Postfix) with ESMTP id 73D3F5E196
	for <ietf-ppp@merit.edu>; Wed, 14 May 2003 14:32:34 -0400 (EDT)
Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10])
	by e31.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4EIWXQs216064
	for <ietf-ppp@merit.edu>; Wed, 14 May 2003 14:32:33 -0400
Received: from cichlid.adsl.duke.edu (sig-9-65-210-236.mts.ibm.com [9.65.210.236])
	by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h4EIWWBO047718
	for <ietf-ppp@merit.edu>; Wed, 14 May 2003 12:32:33 -0600
Received: from cichlid.adsl.duke.edu (narten@localhost)
	by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h4EIWMU05388
	for <ietf-ppp@merit.edu>; Wed, 14 May 2003 14:32:22 -0400
Message-Id: <200305141832.h4EIWMU05388@cichlid.adsl.duke.edu>
To: ietf-ppp@merit.edu
Subject: draft-song-pppext-sip-support-02.txt
Date: Wed, 14 May 2003 14:32:22 -0400
From: Thomas Narten <narten@us.ibm.com>
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

Speaking of which, the RFC editor has received a request to publish
the above document as an informational RFC.

What does this WG think of this request? Should the RFC editor publish
this document? Or would doing so be an end-run around this WG?

Thomas


From owner-ietf-ppp@merit.edu  Wed May 14 14:33:15 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29911
	for <pppext-archive@lists.ietf.org>; Wed, 14 May 2003 14:33:15 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id A3301912A8; Wed, 14 May 2003 14:36:01 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 6C879912A9; Wed, 14 May 2003 14:36:01 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 6EF72912A8
	for <ietf-ppp@trapdoor.merit.edu>; Wed, 14 May 2003 14:36:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 5C7D95E1BE; Wed, 14 May 2003 14:36:00 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3])
	by segue.merit.edu (Postfix) with ESMTP id E96675E1BD
	for <ietf-ppp@merit.edu>; Wed, 14 May 2003 14:35:55 -0400 (EDT)
Received: (from vjs@localhost)
	by calcite.rhyolite.com (8.12.9/8.12.9) id h4EIZt0L011006
	for ietf-ppp@merit.edu env-from <vjs>;
	Wed, 14 May 2003 12:35:55 -0600 (MDT)
Date: Wed, 14 May 2003 12:35:55 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
Message-Id: <200305141835.h4EIZt0L011006@calcite.rhyolite.com>
To: ietf-ppp@merit.edu
Subject: Re: Reigning in "bad" extensions to PPP
References: <200305141827.h4EIRIZ05372@cichlid.adsl.duke.edu>
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

> From: Thomas Narten <narten@us.ibm.com>

> > 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?
>
> Bernard is right, unfortunately.

Ouch!

> IMO, a document for PPP IANA Considerations is needed. At a minimum,
> an IANA considerations document would define when and under what
> conditions IANA should allocate code points. Right now, there are some
> nume spaces where anyone can get a code point just by asking. It would
> be quite reasonable for the WG to say "for standards track only" for
> some of the number spaces, for example. For a recent example of how to
> do this, see draft-aboba-radius-iana-07.txt, which the IESG approved
> recently.

Could we do this for all of the PPP state machines with a single
document?  This seems like a worthwhile effort that should be done
immediately.

> If you want to reign in bad uses of PPP, there are ways of documenting
> that too, but it's a bit more work. One  possible example is:
>
>      RFC 3427 "Change Process for the Session Initiation Protocol (SIP)"
>
> That document contains the steps that must be followed for extending
> SIP. Having such documents makes it a lot easier for the IESG to say
> "no" to bad requests, since we would be speaking for the PPP
> community.

There are a lot of words in RFC 3427.  Some, such as those about X-headers
don't seem relevant.

Perhaps it would be sufficent to corral all of the PPP (sub)option numbers.

What do we need to do to get at least that started?


Vernon Schryver    vjs@rhyolite.com


From owner-ietf-ppp@merit.edu  Wed May 14 14:40:41 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00128
	for <pppext-archive@lists.ietf.org>; Wed, 14 May 2003 14:40:40 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 390F0912A9; Wed, 14 May 2003 14:43:27 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 0A7F3912AA; Wed, 14 May 2003 14:43:26 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 234B0912A9
	for <ietf-ppp@trapdoor.merit.edu>; Wed, 14 May 2003 14:43:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 0BC1D5E1B4; Wed, 14 May 2003 14:43:26 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from internaut.com (unknown [64.38.134.99])
	by segue.merit.edu (Postfix) with ESMTP id 8AD995E1B1
	for <ietf-ppp@merit.edu>; Wed, 14 May 2003 14:43:25 -0400 (EDT)
Received: from localhost (aboba@localhost)
	by internaut.com (8.10.2/8.10.2) with ESMTP id h4EIM7t02887;
	Wed, 14 May 2003 11:22:08 -0700
Date: Wed, 14 May 2003 11:22:07 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: Vernon Schryver <vjs@calcite.rhyolite.com>
Cc: ietf-ppp@merit.edu
Subject: Re: Reigning in "bad" extensions to PPP
In-Reply-To: <200305141835.h4EIZt0L011006@calcite.rhyolite.com>
Message-ID: <Pine.LNX.4.53.0305141119170.1976@internaut.com>
References: <200305141827.h4EIRIZ05372@cichlid.adsl.duke.edu>
 <200305141835.h4EIZt0L011006@calcite.rhyolite.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

> Could we do this for all of the PPP state machines with a single
> document?  This seems like a worthwhile effort that should be done
> immediately.

Sure. Just write a document called "IANA Consideration for PPP", and
describe the procedures for assignment of each of the parameters.

It's not all that hard -- you can look at draft-aboba-radius-iana-07.txt
as an example.  In that document we took some of the first come first
served parameters that had been abused and made allocation require review.


From owner-ietf-ppp@merit.edu  Wed May 14 14:41:10 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00156
	for <pppext-archive@lists.ietf.org>; Wed, 14 May 2003 14:41:10 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 8F26E912AB; Wed, 14 May 2003 14:43:51 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 422AA912AA; Wed, 14 May 2003 14:43:51 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 73821912BE
	for <ietf-ppp@trapdoor.merit.edu>; Wed, 14 May 2003 14:43:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 580045E1B4; Wed, 14 May 2003 14:43:46 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3])
	by segue.merit.edu (Postfix) with ESMTP id 416A65E1B1
	for <ietf-ppp@merit.edu>; Wed, 14 May 2003 14:43:45 -0400 (EDT)
Received: (from vjs@localhost)
	by calcite.rhyolite.com (8.12.9/8.12.9) id h4EIhiZv012331
	for ietf-ppp@merit.edu env-from <vjs>;
	Wed, 14 May 2003 12:43:44 -0600 (MDT)
Date: Wed, 14 May 2003 12:43:44 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
Message-Id: <200305141843.h4EIhiZv012331@calcite.rhyolite.com>
To: ietf-ppp@merit.edu
Subject: Re: draft-song-pppext-sip-support-02.txt
References: <200305141832.h4EIWMU05388@cichlid.adsl.duke.edu>
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

> From: Thomas Narten <narten@us.ibm.com>
>
> Speaking of which, the RFC editor has received a request to publish
> the above document as an informational RFC.
>
> What does this WG think of this request? Should the RFC editor publish
> this document? Or would doing so be an end-run around this WG?

Ugh.  No.  Yes.

The proposal makes no sense.  Unless SIP Is utterly broken, there must
be other means for discovering SIP proxy servers besides special
link-layer kludges.  What happens on other point to point links that
don't use PPP?  What about point-to-point links that use PPP but not
IPCP, such as only BCP?

Besides, this proposal could not and would not be widely deployed for
a long time.  Unless SIP is utterly broken, those othe mechanisms,
whatever they are, must render this mechanism irrelevant.

It's not a coincidence that proposal to stuff routing or at least
router discovery into IPCP cited this proposal as a precedent.


Vernon Schryver    vjs@rhyolite.com


From owner-ietf-ppp@merit.edu  Wed May 14 14:50:42 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00340
	for <pppext-archive@lists.ietf.org>; Wed, 14 May 2003 14:50:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id B29F3912AA; Wed, 14 May 2003 14:53:26 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 84039912AC; Wed, 14 May 2003 14:53:26 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id A4F90912AA
	for <ietf-ppp@trapdoor.merit.edu>; Wed, 14 May 2003 14:53:25 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 892B75E1C1; Wed, 14 May 2003 14:53:25 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from internaut.com (unknown [64.38.134.99])
	by segue.merit.edu (Postfix) with ESMTP id F3E205E1B4
	for <ietf-ppp@merit.edu>; Wed, 14 May 2003 14:53:24 -0400 (EDT)
Received: from localhost (aboba@localhost)
	by internaut.com (8.10.2/8.10.2) with ESMTP id h4EIW7v03510;
	Wed, 14 May 2003 11:32:07 -0700
Date: Wed, 14 May 2003 11:32:07 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: Thomas Narten <narten@us.ibm.com>
Cc: ietf-ppp@merit.edu
Subject: Re: draft-song-pppext-sip-support-02.txt
In-Reply-To: <200305141832.h4EIWMU05388@cichlid.adsl.duke.edu>
Message-ID: <Pine.LNX.4.53.0305141122410.2914@internaut.com>
References: <200305141832.h4EIWMU05388@cichlid.adsl.duke.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

Personally, I don't care much for this document.

It seems to me that allowing configuration mechanisms to proliferate isn't
helpful.

First off, it means that devices may have to implement multiple
mechanisms, since they can't be sure that they can get the required
configuration via a single mechanism.  Since they  might need PPP IPCP, or
maybe DHCP, or maybe something else, you have to implement all of them
-- if you want to interoperate.  More likely, the device chooses a
single mechanism, which means that it won't work in a heterogenous
vendor environment.  Great -- multiple IETF standards, but no true
interoperability.

Then there is the potential for conflict. What if DHCP doesn't agree with
IPCP?  What about security?  IPCP isn't secured -- though DHCP might be.

Once upon a time, the logic for IPCP extension support was that
implementing DHCP service in the ISP network would increase access
latency and furthermore was an implementation burden, so that the user
experience would be better and ISP deployment would be easier if
configuration could be done by the authenticator.

However, with DHCPINFORM it is possible for an authenticator to implement
a stateless server so that it isn't required for the ISP to implement DHCP
in their network.  The latency argument doesn't hold anymore either.


On Wed, 14 May 2003, Thomas Narten wrote:

> Speaking of which, the RFC editor has received a request to publish
> the above document as an informational RFC.
>
> What does this WG think of this request? Should the RFC editor publish
> this document? Or would doing so be an end-run around this WG?
>
> Thomas
>


From owner-ietf-ppp@merit.edu  Wed May 14 15:23:40 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02308
	for <pppext-archive@lists.ietf.org>; Wed, 14 May 2003 15:23:40 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 85700912AE; Wed, 14 May 2003 15:26:26 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 50C0F912AF; Wed, 14 May 2003 15:26:26 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 533EE912AE
	for <ietf-ppp@trapdoor.merit.edu>; Wed, 14 May 2003 15:26:25 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 3018B5E1C8; Wed, 14 May 2003 15:26:25 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.130])
	by segue.merit.edu (Postfix) with ESMTP id 8DA1F5E1DE
	for <ietf-ppp@merit.edu>; Wed, 14 May 2003 15:26:24 -0400 (EDT)
Received: from westrelay01.boulder.ibm.com (westrelay01.boulder.ibm.com [9.17.195.10])
	by e32.co.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4EJQEkc294214;
	Wed, 14 May 2003 15:26:14 -0400
Received: from cichlid.adsl.duke.edu (sig-9-65-210-236.mts.ibm.com [9.65.210.236])
	by westrelay01.boulder.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h4EJQDBO039536;
	Wed, 14 May 2003 13:26:13 -0600
Received: from cichlid.adsl.duke.edu (narten@localhost)
	by cichlid.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id h4EJQ3L07231;
	Wed, 14 May 2003 15:26:03 -0400
Message-Id: <200305141926.h4EJQ3L07231@cichlid.adsl.duke.edu>
To: Vernon Schryver <vjs@calcite.rhyolite.com>
Cc: ietf-ppp@merit.edu
Subject: Re: Reigning in "bad" extensions to PPP 
In-Reply-To: Message from vjs@calcite.rhyolite.com
   of "Wed, 14 May 2003 12:35:55 MDT." <200305141835.h4EIZt0L011006@calcite.rhyolite.com> 
Date: Wed, 14 May 2003 15:26:03 -0400
From: Thomas Narten <narten@us.ibm.com>
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

> Could we do this for all of the PPP state machines with a single
> document?  This seems like a worthwhile effort that should be done
> immediately.

I agree. This gets the biggest bang for the buck.

> > If you want to reign in bad uses of PPP, there are ways of documenting
> > that too, but it's a bit more work. One  possible example is:
> >
> >      RFC 3427 "Change Process for the Session Initiation Protocol (SIP)"
> >
> > That document contains the steps that must be followed for extending
> > SIP. Having such documents makes it a lot easier for the IESG to say
> > "no" to bad requests, since we would be speaking for the PPP
> > community.

> There are a lot of words in RFC 3427.  Some, such as those about X-headers
> don't seem relevant.

yep. Maybe enough ground can be covered in an IANA considerations
document. For example, when describing the IPCP name space, one could
say it is intended for link-specific PPP-specific configuration
information and is not intended to be used for carrying generic stuff
that can be carried by more general protocols like DHCP or RIP/OSPF.

> Perhaps it would be sufficent to corral all of the PPP (sub)option numbers.

> What do we need to do to get at least that started?

Go to the IANA web page for PPP and look at all the name spaces. Start
with a document modeled after draft-aboba-radius-iana-07.txt and have
a section or sub-section for each name space and say what the policy
should be for each of them and under what conditions an allocation is
appropriate (Reading RFC 2434 is probably also a good thing at this
point). The key thing it to ensure that sufficient review takes place
by someone familiar with PPP before an assignment is allowed that
might lead to "abuse" of PPP.

Thomas


From owner-ietf-ppp@merit.edu  Wed May 14 15:45:12 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03065
	for <pppext-archive@lists.ietf.org>; Wed, 14 May 2003 15:45:11 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 813D5912AF; Wed, 14 May 2003 15:47:56 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 4E9CA912B0; Wed, 14 May 2003 15:47:56 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 06BC5912AF
	for <ietf-ppp@trapdoor.merit.edu>; Wed, 14 May 2003 15:47:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id D7CBC5E1E6; Wed, 14 May 2003 15:47:43 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from david.siemens.com (david.siemens.com [194.138.160.5])
	by segue.merit.edu (Postfix) with ESMTP id 6D5CA5E1E4
	for <ietf-ppp@merit.edu>; Wed, 14 May 2003 15:47:43 -0400 (EDT)
Received: from mail-usa.sbs.siemens.com (mail-usa.sbs.siemens.com [129.73.68.4])
	by david.siemens.com (8.11.7/8.11.7) with ESMTP id h4EJli117872;
	Wed, 14 May 2003 15:47:44 -0400 (EDT)
Received: from bambam.inside.efficient.com ([165.218.188.5])
	by mail-usa.sbs.siemens.com (8.11.6/8.11.6) with ESMTP id h4EJlgF25386;
	Wed, 14 May 2003 15:47:43 -0400 (EDT)
Received: by bambam.inside.efficient.com with Internet Mail Service (5.5.2653.19)
	id <KTP35881>; Wed, 14 May 2003 14:47:40 -0500
Message-ID: <CD779E609614D611A3FC00508B0F1CB63A51BA@pebbles.inside.efficient.com>
From: Doug Kehn <dkehn@efficient.com>
To: "'Thomas Narten '" <narten@us.ibm.com>
Cc: "'ietf-ppp@merit.edu '" <ietf-ppp@merit.edu>
Subject: RE: Reigning in "bad" extensions to PPP 
Date: Wed, 14 May 2003 14:47:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

Thomas,

I gather from your post that you agree that the Route-Add option proposal is
a bad idea?  If so, I will inform the appropriate parties that the pppext WG
doesn't endorse such a proposal.

What is the pppext WG stance with regard to IPCP option 144?  I have yet to
find an RFC or a draft describing such an option.  Yet, I'm being asked
(actually forced) to implement this option in order to be considered for
operation in certain broadband networks.

Thanks...
doug


-----Original Message-----
From: Thomas Narten
To: Vernon Schryver
Cc: ietf-ppp@merit.edu
Sent: 5/14/03 2:26 PM
Subject: Re: Reigning in "bad" extensions to PPP 

> Could we do this for all of the PPP state machines with a single
> document?  This seems like a worthwhile effort that should be done
> immediately.

I agree. This gets the biggest bang for the buck.

> > If you want to reign in bad uses of PPP, there are ways of
documenting
> > that too, but it's a bit more work. One  possible example is:
> >
> >      RFC 3427 "Change Process for the Session Initiation Protocol
(SIP)"
> >
> > That document contains the steps that must be followed for extending
> > SIP. Having such documents makes it a lot easier for the IESG to say
> > "no" to bad requests, since we would be speaking for the PPP
> > community.

> There are a lot of words in RFC 3427.  Some, such as those about
X-headers
> don't seem relevant.

yep. Maybe enough ground can be covered in an IANA considerations
document. For example, when describing the IPCP name space, one could
say it is intended for link-specific PPP-specific configuration
information and is not intended to be used for carrying generic stuff
that can be carried by more general protocols like DHCP or RIP/OSPF.

> Perhaps it would be sufficent to corral all of the PPP (sub)option
numbers.

> What do we need to do to get at least that started?

Go to the IANA web page for PPP and look at all the name spaces. Start
with a document modeled after draft-aboba-radius-iana-07.txt and have
a section or sub-section for each name space and say what the policy
should be for each of them and under what conditions an allocation is
appropriate (Reading RFC 2434 is probably also a good thing at this
point). The key thing it to ensure that sufficient review takes place
by someone familiar with PPP before an assignment is allowed that
might lead to "abuse" of PPP.

Thomas


From owner-ietf-ppp@merit.edu  Thu May 15 02:35:53 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28637
	for <pppext-archive@lists.ietf.org>; Thu, 15 May 2003 02:35:53 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 87C5E91226; Thu, 15 May 2003 02:38:38 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 537C691228; Thu, 15 May 2003 02:38:38 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 3523A91226
	for <ietf-ppp@trapdoor.merit.edu>; Thu, 15 May 2003 02:38:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 137625E38C; Thu, 15 May 2003 02:38:37 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from webmail.maginet.co.kr (unknown [203.229.167.227])
	by segue.merit.edu (Postfix) with ESMTP id EF9E15E38A
	for <ietf-ppp@merit.edu>; Thu, 15 May 2003 02:38:35 -0400 (EDT)
Received: from gwzw2k ([218.145.160.100])
	by webmail.maginet.co.kr (8.11.6/8.11.6) with ESMTP id h4F6ekQ13296;
	Thu, 15 May 2003 15:40:46 +0900
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "'Bernard Aboba'" <aboba@internaut.com>,
        "'Thomas Narten'" <narten@us.ibm.com>
Cc: <ietf-ppp@merit.edu>
Subject: RE: draft-song-pppext-sip-support-02.txt
Date: Wed, 14 May 2003 23:38:10 -0700
Organization: Cisco Systems
Message-ID: <001801c31aac$8fc252c0$1200000a@amer.cisco.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0019_01C31A71.E3637AC0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Importance: Normal
In-Reply-To: <Pine.LNX.4.53.0305141122410.2914@internaut.com>
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

This is a multi-part message in MIME format.

------=_NextPart_000_0019_01C31A71.E3637AC0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Bernard Aboba <mailto:aboba@internaut.com> writes:

> Personally, I don't care much for this document.
> 
> It seems to me that allowing configuration mechanisms to proliferate
> isn't helpful. 

Even less helpful is attempting to force all access networks to fit a
single mold.

> 
> First off, it means that devices may have to implement multiple
> mechanisms, since they can't be sure that they can get the required
> configuration via a single mechanism.  Since they  might need PPP
> IPCP, or maybe DHCP, or maybe something else, you have to implement
> all of them    
> -- if you want to interoperate.  More likely, the device chooses a
> single mechanism, which means that it won't work in a heterogenous
> vendor environment.  

How does this conclusion follow?  Are you claiming that no two vendors
will ever implement the same set of standards?

> Great -- multiple IETF standards, but no true
> interoperability.   

your use of the term "interoperability" here seems to me to be a novel
one.  At the protocol level, interoperability is ensured by the correct
implementation of the protocol and required features thereof, but you
seem to be suggesting that "true" interoperability can only exist if all
devices on the network support precisely the same protocols, implemented
in exactly the same way.

> 
> Then there is the potential for conflict. What if DHCP doesn't agree
> with IPCP?  

If I already have the data I need (obtained through static
configuration, IPCP, etc.), why am I going to ask DHCP for it?  In real,
existing networks, is the fact that IP addresses can be obtained through
either IPCP or DHCP causing massive meltdowns?

> What about security?  IPCP isn't secured -- though DHCP
> might be.  

Please excuse my ignorance: I thought that DHCP security didn't go
between the client and server, just between relays and servers.

> 
> Once upon a time, the logic for IPCP extension support was that
> implementing DHCP service in the ISP network would increase access
> latency and furthermore was an implementation burden, so that the
> user experience would be better and ISP deployment would be easier if
> configuration could be done by the authenticator.    
> 
> However, with DHCPINFORM it is possible for an authenticator to
> implement a stateless server so that it isn't required for the ISP to
> implement DHCP in their network.  

It's a long jump from "possible" to "necessary", which your definition
of "true interoperability" would seem to imply.  If DHCP was the only
way to get config data, of course, then _every_ authenticator would have
to implement the stateless server.  Is that the desired outcome?

> The latency argument doesn't hold
> anymore either. 

In what environments?  802.11, Ethernet, UMTS, CDMA-2000, 14.4K dial-up?
  
> 
> 
> On Wed, 14 May 2003, Thomas Narten wrote:
> 
>> Speaking of which, the RFC editor has received a request to publish
>> the above document as an informational RFC.
>> 
>> What does this WG think of this request? Should the RFC editor
>> publish this document? Or would doing so be an end-run around this
>> WG? 
>> 
>> Thomas

~gwz

"They that can give up essential liberty to obtain a little temporary
safety deserve neither..." 

-- Benjamin Franklin, 1759


I've stopped 24,754 spam messages. You can too!
Get your free, safe spam protection at
http://www.cloudmark.com/spamnetsig/ 

------=_NextPart_000_0019_01C31A71.E3637AC0
Content-Type: text/x-vcard;
	name="Glen Zorn.vcf"
Content-Disposition: attachment;
	filename="Glen Zorn.vcf"
Content-Transfer-Encoding: quoted-printable

BEGIN:VCARD
VERSION:2.1
N:Zorn;Glen
FN:Glen Zorn
ORG:Cisco Systems
TITLE:CTO Consulting Engineer
NOTE;ENCODING=3DQUOTED-PRINTABLE:PGP Key Fingerprint: 4F41 B93A 007D =
E2FC 9769  FB97 FBCF 7DA4 9A2D 1963=3D0D=3D
=3D0A=3D0D=3D0A
TEL;HOME;VOICE:+1 (425) 513-8512
TEL;CELL;VOICE:+1 (425) 344-8113
TEL;WORK;FAX:+1 (425) 740-0168
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;500 108th Avenue =
N.E.=3D0D=3D0ASuite 500;Bellevue;WA;98004;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:500 108th Avenue =
N.E.=3D0D=3D0ASuite 500=3D0D=3D0ABellevue, WA 98004=3D0D=3D0AUSA
URL;WORK:http://www.cisco.com
EMAIL;PREF;INTERNET:gwz@cisco.com
REV:20021107T033833Z
END:VCARD

------=_NextPart_000_0019_01C31A71.E3637AC0--




From owner-ietf-ppp@merit.edu  Thu May 15 07:31:31 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04076
	for <pppext-archive@lists.ietf.org>; Thu, 15 May 2003 07:31:30 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 8090A91227; Thu, 15 May 2003 07:34:15 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 4E578912B5; Thu, 15 May 2003 07:34:15 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 1594091227
	for <ietf-ppp@trapdoor.merit.edu>; Thu, 15 May 2003 07:34:14 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id EDFBE5DE66; Thu, 15 May 2003 07:34:13 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by segue.merit.edu (Postfix) with ESMTP id 826245DE64
	for <ietf-ppp@merit.edu>; Thu, 15 May 2003 07:34:13 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h4FBY7jB011226;
	Thu, 15 May 2003 04:34:08 -0700 (PDT)
Received: from gwzw2k (tokyo-vpn-user302.cisco.com [10.70.83.46]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id EAA08951; Thu, 15 May 2003 04:34:06 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "'Vernon Schryver'" <vjs@calcite.rhyolite.com>, <ietf-ppp@merit.edu>
Subject: RE: draft-song-pppext-sip-support-02.txt
Date: Thu, 15 May 2003 04:33:31 -0700
Organization: Cisco Systems
Message-ID: <001d01c31ad5$e31cfd70$1200000a@amer.cisco.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_001E_01C31A9B.36BFAC10"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-Reply-To: <200305141843.h4EIhiZv012331@calcite.rhyolite.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

This is a multi-part message in MIME format.

------=_NextPart_000_001E_01C31A9B.36BFAC10
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Vernon Schryver <mailto:vjs@calcite.rhyolite.com> writes:

>> From: Thomas Narten <narten@us.ibm.com>
>> 
>> Speaking of which, the RFC editor has received a request to publish
>> the above document as an informational RFC.
>> 
>> What does this WG think of this request? Should the RFC editor
>> publish this document? Or would doing so be an end-run around this
>> WG? 
> 
> Ugh.  No.  Yes.
> 
> The proposal makes no sense.  Unless SIP Is utterly broken, there
> must be other means for discovering SIP proxy servers besides special
> link-layer kludges.  What happens on other point to point links that
> don't use PPP?  

Who cares?

> What about point-to-point links that use PPP but not
> IPCP, such as only BCP? 

Ditto.
   
> 
> Besides, this proposal could not and would not be widely deployed for
> a long time.  Unless SIP is utterly broken, those othe mechanisms,
> whatever they are, must render this mechanism irrelevant.  

Vern please read the document: "This draft specifies an IPCP (PPP
Internet Protocol Control Protocol) option that allows SIP clients to
locate a list of SIP proxy servers that is to be used for all SIP
requests. This approach is applicable to a system utilizing PPP for its
link layer protocol and IP address allocation (ex. 3GPP2 Packet Data
System)."
                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Presumably, 3GPP2 will be widely deployed in less than a long time (if
not, sell your Sprint stock now ;-).  Please understand that I don't
much care for this idea either, but all of the arguments against it so
far seem at best lame.  

> 
> It's not a coincidence that proposal to stuff routing or at least
> router discovery into IPCP cited this proposal as a precedent. 
> 
> 
> Vernon Schryver    vjs@rhyolite.com

~gwz

"They that can give up essential liberty to obtain a little temporary
safety deserve neither..." 

-- Benjamin Franklin, 1759


I've stopped 24,754 spam messages. You can too!
Get your free, safe spam protection at
http://www.cloudmark.com/spamnetsig/ 

------=_NextPart_000_001E_01C31A9B.36BFAC10
Content-Type: text/x-vcard;
	name="Glen Zorn.vcf"
Content-Disposition: attachment;
	filename="Glen Zorn.vcf"
Content-Transfer-Encoding: quoted-printable

BEGIN:VCARD
VERSION:2.1
N:Zorn;Glen
FN:Glen Zorn
ORG:Cisco Systems
TITLE:CTO Consulting Engineer
NOTE;ENCODING=3DQUOTED-PRINTABLE:PGP Key Fingerprint: 4F41 B93A 007D =
E2FC 9769  FB97 FBCF 7DA4 9A2D 1963=3D0D=3D
=3D0A=3D0D=3D0A
TEL;HOME;VOICE:+1 (425) 513-8512
TEL;CELL;VOICE:+1 (425) 344-8113
TEL;WORK;FAX:+1 (425) 740-0168
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;500 108th Avenue =
N.E.=3D0D=3D0ASuite 500;Bellevue;WA;98004;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:500 108th Avenue =
N.E.=3D0D=3D0ASuite 500=3D0D=3D0ABellevue, WA 98004=3D0D=3D0AUSA
URL;WORK:http://www.cisco.com
EMAIL;PREF;INTERNET:gwz@cisco.com
REV:20021107T033833Z
END:VCARD

------=_NextPart_000_001E_01C31A9B.36BFAC10--




From owner-ietf-ppp@merit.edu  Thu May 15 09:00:56 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07737
	for <pppext-archive@lists.ietf.org>; Thu, 15 May 2003 09:00:56 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 21A1B912B9; Thu, 15 May 2003 09:03:37 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id DD06C912BA; Thu, 15 May 2003 09:03:36 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id D5606912B9
	for <ietf-ppp@trapdoor.merit.edu>; Thu, 15 May 2003 09:03:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id BB7BA5DEBF; Thu, 15 May 2003 09:03:35 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from internaut.com (unknown [64.38.134.99])
	by segue.merit.edu (Postfix) with ESMTP id C0F025DEBC
	for <ietf-ppp@merit.edu>; Thu, 15 May 2003 09:03:34 -0400 (EDT)
Received: from localhost (aboba@localhost)
	by internaut.com (8.10.2/8.10.2) with ESMTP id h4FCgAr32040;
	Thu, 15 May 2003 05:42:10 -0700
Date: Thu, 15 May 2003 05:42:10 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: Glen Zorn <gwz@cisco.com>
Cc: "'Thomas Narten'" <narten@us.ibm.com>, ietf-ppp@merit.edu
Subject: RE: draft-song-pppext-sip-support-02.txt
In-Reply-To: <001801c31aac$8fc252c0$1200000a@amer.cisco.com>
Message-ID: <Pine.LNX.4.53.0305150534070.30835@internaut.com>
References: <001801c31aac$8fc252c0$1200000a@amer.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

> How does this conclusion follow?  Are you claiming that no two vendors
> will ever implement the same set of standards?

I'm claiming that requiring embedded devices to implement multiple
standards may not be practical -- so they'll choose one and not
interoperate instead.

> your use of the term "interoperability" here seems to me to be a novel
> one.  At the protocol level, interoperability is ensured by the correct
> implementation of the protocol and required features thereof, but you
> seem to be suggesting that "true" interoperability can only exist if all
> devices on the network support precisely the same protocols, implemented
> in exactly the same way.

If the network is only supporting one set of protocols for configuration,
then the device must support that set in order to obtain configuration. If
different networks use different protocols and the device is mobile, then
it must support *all* the potential configuration protocols, or when it
moves to some networks, it will be unable to obtain configuration.  Worse
yet, when it moves, it may have to try multiple mechanisms in order to
obtain configuration. This can increase the latency required for the
device to become functional on movement.

> If I already have the data I need (obtained through static
> configuration, IPCP, etc.), why am I going to ask DHCP for it?  In real,
> existing networks, is the fact that IP addresses can be obtained through
> either IPCP or DHCP causing massive meltdowns?

Presumably once a host obtains an IP address it is done.  If the host
needs more configuration than is provided by IPCP it still may need to do
DHCPINFORM.

> Please excuse my ignorance: I thought that DHCP security didn't go
> between the client and server, just between relays and servers.

It goes between client and server -- see RFC 3118.

> It's a long jump from "possible" to "necessary", which your definition
> of "true interoperability" would seem to imply.  If DHCP was the only
> way to get config data, of course, then _every_ authenticator would have
> to implement the stateless server.  Is that the desired outcome?

I think it is.  We're already much of the way there -- Cisco IOS includes
support for a full fledged DHCP server,  something that was not considered
possible back in 1995 when the idea of IPCP "extensions" was first proposed.

> In what environments?  802.11, Ethernet, UMTS, CDMA-2000, 14.4K dial-up?

If the authenticator implements a DHCP server, there won't be much latency
difference between DHCPINFORM and IPCP.



From owner-ietf-ppp@merit.edu  Thu May 15 10:21:06 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10584
	for <pppext-archive@lists.ietf.org>; Thu, 15 May 2003 10:21:06 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id A156291229; Thu, 15 May 2003 10:23:43 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 771D3912BB; Thu, 15 May 2003 10:23:43 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 60F5D91229
	for <ietf-ppp@trapdoor.merit.edu>; Thu, 15 May 2003 10:23:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 4C9B55DEAD; Thu, 15 May 2003 10:23:42 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3])
	by segue.merit.edu (Postfix) with ESMTP id 6ACF55DEFC
	for <ietf-ppp@merit.edu>; Thu, 15 May 2003 10:23:41 -0400 (EDT)
Received: (from vjs@localhost)
	by calcite.rhyolite.com (8.12.9/8.12.9) id h4FENe90012307
	for ietf-ppp@merit.edu env-from <vjs>;
	Thu, 15 May 2003 08:23:40 -0600 (MDT)
Date: Thu, 15 May 2003 08:23:40 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
Message-Id: <200305151423.h4FENe90012307@calcite.rhyolite.com>
To: ietf-ppp@merit.edu
Subject: RE: draft-song-pppext-sip-support-02.txt
References: <001d01c31ad5$e31cfd70$1200000a@amer.cisco.com>
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

> From: "Glen Zorn" <gwz@cisco.com>

> > The proposal makes no sense.  Unless SIP Is utterly broken, there
> > must be other means for discovering SIP proxy servers besides special
> > link-layer kludges.  What happens on other point to point links that
> > don't use PPP?  
>
> Who cares?
>
> > What about point-to-point links that use PPP but not
> > IPCP, such as only BCP? 
>
> Ditto.

Please stop the insults and think about what we've said. 

If SIP is utterly broken, then there is no need for the proposal
because it can't and won't be used.  Let's assume that SIP is not
broken, not useless, and can be used and is used.  I don't know that
SIP is good, but given the vast number of IDs and RFCs about it, I
hope it is.  That SIP is good implies that it already has perfectly
good mechanisms for finding proxies without this new, quite late idea.
Thus this new, late idea is redundant, unnecessary, extra, and can
only cause confusion and interoperation problems.


> > Besides, this proposal could not and would not be widely deployed for
> > a long time.  Unless SIP is utterly broken, those othe mechanisms,
> > whatever they are, must render this mechanism irrelevant.  
>
> Vern please read the document: "This draft specifies an IPCP (PPP
> Internet Protocol Control Protocol) option that allows SIP clients to
> locate a list of SIP proxy servers that is to be used for all SIP
> requests. This approach is applicable to a system utilizing PPP for its
> link layer protocol and IP address allocation (ex. 3GPP2 Packet Data
> System)."
>                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Presumably, 3GPP2 will be widely deployed in less than a long time (if
> not, sell your Sprint stock now ;-).  Please understand that I don't
> much care for this idea either, but all of the arguments against it so
> far seem at best lame.  

Whether 3GPP2 is deployed implies nothing that I can see.  I haven't
been buying any more stock in 3G telephones than I did in WAP telephones
and for some of the same reasons, but you should make your own investment
decisions.  This PPP proposal stinks of the same sort of Internet
Engineering that brought us WAP.  It is based on the assumption that
existing mechanisms do not exist or are irrelevant.

Perhaps the existing SIP mechanisms cannot work over PPP.  If that is
true, then this proposal must say so and provide convincing technical
reasons.

Let's cut the obscuring politeness and admit the main motive for
these IDs.  Like the old Microsoft DNS server botch, they come from
ignorance of existing standards and practices and an ambition to
see one's name in the RFC index.

The fact that this SIP proposal does not advert to the existence of
any mechanism on other link layers without broadcasts to discover
proxies suggests that the author does not know how SIP works on other
media.  The IPCP default route proposal has a similar stigmata of not
mentioning the ancient alternatives to its wonderful idea.  I'm sure
that author is not trying to hide the alternatives but was innocently
unaware of their ease, popularity, and effectiveness.  If all you know
about routing comes from the cries of anquish of people fighting with
BGP, you wouldn't consider using RIP for router discovery, not to
mention the IP router discovery protocol or the ancient mechanism of
adding routes as interfaces awaken.  If you don't really understand
IPCP, you'd not realize that it makes no sense to put the IP address
of the peer into the IPCP packet twice.  You'd also not recognize the
dangerous swamp of policy routing you'd wandered into.


Vernon Schryver    vjs@rhyolite.com


From owner-ietf-ppp@merit.edu  Thu May 15 11:48:26 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12931
	for <pppext-archive@lists.ietf.org>; Thu, 15 May 2003 11:48:26 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 5CF4F912C7; Thu, 15 May 2003 11:48:29 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 30627912C6; Thu, 15 May 2003 11:48:29 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 9FCFC912C7
	for <ietf-ppp@trapdoor.merit.edu>; Thu, 15 May 2003 11:48:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 87A245DF1F; Thu, 15 May 2003 11:48:22 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105])
	by segue.merit.edu (Postfix) with ESMTP id 1E1D75DF16
	for <ietf-ppp@merit.edu>; Thu, 15 May 2003 11:48:22 -0400 (EDT)
Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206])
	by e5.ny.us.ibm.com (8.12.9/8.12.2) with ESMTP id h4FFmKtd211102;
	Thu, 15 May 2003 11:48:20 -0400
Received: from rotala.raleigh.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by northrelay04.pok.ibm.com (8.12.9/NCO/VER6.5) with ESMTP id h4FFm7iN016976;
	Thu, 15 May 2003 11:48:13 -0400
Received: from rotala.raleigh.ibm.com (localhost.localdomain [127.0.0.1])
	by rotala.raleigh.ibm.com (8.12.8/8.12.5) with ESMTP id h4FFkI15024764;
	Thu, 15 May 2003 11:46:18 -0400
Received: from rotala.raleigh.ibm.com (narten@localhost)
	by rotala.raleigh.ibm.com (8.12.8/8.12.5/Submit) with ESMTP id h4FFkIIM024760;
	Thu, 15 May 2003 11:46:18 -0400
Message-Id: <200305151546.h4FFkIIM024760@rotala.raleigh.ibm.com>
To: Doug Kehn <dkehn@efficient.com>
Cc: "'ietf-ppp@merit.edu '" <ietf-ppp@merit.edu>
Subject: Re: Reigning in "bad" extensions to PPP 
In-Reply-To: Message from dkehn@efficient.com
   of "Wed, 14 May 2003 14:47:35 CDT." <CD779E609614D611A3FC00508B0F1CB63A51BA@pebbles.inside.efficient.com> 
Date: Thu, 15 May 2003 11:46:18 -0400
From: Thomas Narten <narten@us.ibm.com>
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

> I gather from your post that you agree that the Route-Add option proposal is
> a bad idea?

That would be an accurate reflection of my personal opinion.

> If so, I will inform the appropriate parties that the pppext WG
> doesn't endorse such a proposal.

That would not be a logical next step from the previous statement. I
don't speak for the WG.

> What is the pppext WG stance with regard to IPCP option 144?  I have
> yet to find an RFC or a draft describing such an option.  Yet, I'm
> being asked (actually forced) to implement this option in order to
> be considered for operation in certain broadband networks.

I would assume that since there is no IETF-blessed RFC, this WG has
chosen not to do something along the lines of option 144. Indeed, my
recollection is that this WG has a long tradition of not supporting
extensions to PPP that are not really PPP-specific. E.g., quoting from
the PPPEXT charter:

> The Point-to-Point Protocol (PPP, RFC 1661) is a mature protocol with a
> large number of subprotocols, encapsulations and other extensions. The 
> group will actively advance PPP's most useful extensions to full 
> standard, while defending against further enhancements of questionable 
> value.

Thomas


From owner-ietf-ppp@merit.edu  Thu May 15 18:56:22 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26796
	for <pppext-archive@lists.ietf.org>; Thu, 15 May 2003 18:56:22 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id BDBB591230; Thu, 15 May 2003 18:59:08 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 895B1912D7; Thu, 15 May 2003 18:59:08 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 450D991230
	for <ietf-ppp@trapdoor.merit.edu>; Thu, 15 May 2003 18:59:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 23B505E0C4; Thu, 15 May 2003 18:59:06 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by segue.merit.edu (Postfix) with ESMTP id AD5355E0C3
	for <ietf-ppp@merit.edu>; Thu, 15 May 2003 18:59:05 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h4FMwtG4007717;
	Thu, 15 May 2003 15:58:56 -0700 (PDT)
Received: from gwzw2k (tokyo-vpn-user302.cisco.com [10.70.83.46]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id PAA03971; Thu, 15 May 2003 15:58:54 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "'Bernard Aboba'" <aboba@internaut.com>
Cc: "'Thomas Narten'" <narten@us.ibm.com>, <ietf-ppp@merit.edu>
Subject: RE: draft-song-pppext-sip-support-02.txt
Date: Thu, 15 May 2003 15:58:17 -0700
Organization: Cisco Systems
Message-ID: <001d01c31b35$8c4b0810$1200000a@amer.cisco.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_001E_01C31AFA.DFEC3010"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-Reply-To: <Pine.LNX.4.53.0305150534070.30835@internaut.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Importance: Normal
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

This is a multi-part message in MIME format.

------=_NextPart_000_001E_01C31AFA.DFEC3010
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Bernard Aboba <mailto:aboba@internaut.com> writes:

>> How does this conclusion follow?  Are you claiming that no two
>> vendors will ever implement the same set of standards?
> 
> I'm claiming that requiring embedded devices to implement multiple
> standards may not be practical -- so they'll choose one and not
> interoperate instead.  

Possibly.  So, presupposing that these devices use PPP, why would they
choose to implement DHCP instead of an IPCP option?

> 
>> your use of the term "interoperability" here seems to me to be a
>> novel one.  At the protocol level, interoperability is ensured by the
>> correct implementation of the protocol and required features thereof,
>> but you seem to be suggesting that "true" interoperability can only
>> exist if all devices on the network support precisely the same
>> protocols, implemented in exactly the same way.
> 
> If the network is only supporting one set of protocols for
> configuration, then the device must support that set in order to
> obtain configuration. If different networks use different protocols
> and the device is mobile, then it must support *all* the potential
> configuration protocols, or when it moves to some networks, it will
> be unable to obtain configuration.  Worse yet, when it moves, it may
> have to try multiple mechanisms in order to obtain configuration.
> This can increase the latency required for the device to become
> functional on movement.        
> 
>> If I already have the data I need (obtained through static
>> configuration, IPCP, etc.), why am I going to ask DHCP for it?  In
>> real, existing networks, is the fact that IP addresses can be
>> obtained through either IPCP or DHCP causing massive meltdowns?
> 
> Presumably once a host obtains an IP address it is done.  If the host
> needs more configuration than is provided by IPCP it still may need
> to do DHCPINFORM.

Exactly.
  
> 
>> Please excuse my ignorance: I thought that DHCP security didn't go
>> between the client and server, just between relays and servers.
> 
> It goes between client and server -- see RFC 3118.

Yup, thanks for the pointer!

> 
>> It's a long jump from "possible" to "necessary", which your
>> definition of "true interoperability" would seem to imply.  If DHCP
>> was the only way to get config data, of course, then _every_
>> authenticator would have to implement the stateless server.  Is that
>> the desired outcome? 
> 
> I think it is.  We're already much of the way there -- Cisco IOS
> includes support for a full fledged DHCP server,  something that was
> not considered possible back in 1995 when the idea of IPCP
> "extensions" was first proposed.   
> 
>> In what environments?  802.11, Ethernet, UMTS, CDMA-2000, 14.4K
>> dial-up?
> 
> If the authenticator implements a DHCP server, there won't be much
> latency difference between DHCPINFORM and IPCP. 

Only if the DHCP server in the authenticator is omniscient: if the
correct values can only be provided by the home network (in a roaming
situation), then presumably the request would need to be relayed.  OTOH,
(devil's advocate hat on) if the appropriate values were returned from
the home AAA server and set in IPCP, the task would be complete before
DHCP would even have started, reducing both latency and code footprint
in the mobile device.

~gwz

"They that can give up essential liberty to obtain a little temporary
safety deserve neither..." 

-- Benjamin Franklin, 1759


I've stopped 24,785 spam messages. You can too!
Get your free, safe spam protection at
http://www.cloudmark.com/spamnetsig/ 

------=_NextPart_000_001E_01C31AFA.DFEC3010
Content-Type: text/x-vcard;
	name="Glen Zorn.vcf"
Content-Disposition: attachment;
	filename="Glen Zorn.vcf"
Content-Transfer-Encoding: quoted-printable

BEGIN:VCARD
VERSION:2.1
N:Zorn;Glen
FN:Glen Zorn
ORG:Cisco Systems
TITLE:CTO Consulting Engineer
NOTE;ENCODING=3DQUOTED-PRINTABLE:PGP Key Fingerprint: 4F41 B93A 007D =
E2FC 9769  FB97 FBCF 7DA4 9A2D 1963=3D0D=3D
=3D0A=3D0D=3D0A
TEL;HOME;VOICE:+1 (425) 513-8512
TEL;CELL;VOICE:+1 (425) 344-8113
TEL;WORK;FAX:+1 (425) 740-0168
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;500 108th Avenue =
N.E.=3D0D=3D0ASuite 500;Bellevue;WA;98004;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:500 108th Avenue =
N.E.=3D0D=3D0ASuite 500=3D0D=3D0ABellevue, WA 98004=3D0D=3D0AUSA
URL;WORK:http://www.cisco.com
EMAIL;PREF;INTERNET:gwz@cisco.com
REV:20021107T033833Z
END:VCARD

------=_NextPart_000_001E_01C31AFA.DFEC3010--




From owner-ietf-ppp@merit.edu  Thu May 15 19:04:28 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26989
	for <pppext-archive@lists.ietf.org>; Thu, 15 May 2003 19:04:28 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 58AF891232; Thu, 15 May 2003 19:07:10 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 28679912D7; Thu, 15 May 2003 19:07:10 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 511EB91232
	for <ietf-ppp@trapdoor.merit.edu>; Thu, 15 May 2003 19:07:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 401F35E0C8; Thu, 15 May 2003 19:07:09 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from internaut.com (unknown [64.38.134.99])
	by segue.merit.edu (Postfix) with ESMTP id B4D9A5E0C7
	for <ietf-ppp@merit.edu>; Thu, 15 May 2003 19:07:08 -0400 (EDT)
Received: from localhost (aboba@localhost)
	by internaut.com (8.10.2/8.10.2) with ESMTP id h4FMjhb12254;
	Thu, 15 May 2003 15:45:43 -0700
Date: Thu, 15 May 2003 15:45:43 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: Glen Zorn <gwz@cisco.com>
Cc: "'Thomas Narten'" <narten@us.ibm.com>, ietf-ppp@merit.edu
Subject: RE: draft-song-pppext-sip-support-02.txt
In-Reply-To: <001d01c31b35$8c4b0810$1200000a@amer.cisco.com>
Message-ID: <Pine.LNX.4.53.0305151541530.11939@internaut.com>
References: <001d01c31b35$8c4b0810$1200000a@amer.cisco.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

> Possibly.  So, presupposing that these devices use PPP, why would they
> choose to implement DHCP instead of an IPCP option?

If they ever needed to move to a link which didn't support PPP.

> Only if the DHCP server in the authenticator is omniscient: if the
> correct values can only be provided by the home network (in a roaming
> situation), then presumably the request would need to be relayed.  OTOH,
> (devil's advocate hat on) if the appropriate values were returned from
> the home AAA server and set in IPCP, the task would be complete before
> DHCP would even have started, reducing both latency and code footprint
> in the mobile device.

In either case, assuming that the AAA protocol supported the necessary
configuration, then it could be made to work -- all that changes is the
protocol spoken between the peer and authenticator.  For example, if AAA
were to provide the address of the DNS server, then the peer could request
this via DHCP or IPCP and the authenticator could answer.  So roaming
doesn't come into it, really.



From owner-ietf-ppp@merit.edu  Thu May 15 19:32:18 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27316
	for <pppext-archive@lists.ietf.org>; Thu, 15 May 2003 19:32:18 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 3E435912D7; Thu, 15 May 2003 19:35:02 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 0B700912DA; Thu, 15 May 2003 19:35:01 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id EDE97912D7
	for <ietf-ppp@trapdoor.merit.edu>; Thu, 15 May 2003 19:35:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id D251F5E10C; Thu, 15 May 2003 19:35:00 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by segue.merit.edu (Postfix) with ESMTP id 956DD5E0F7
	for <ietf-ppp@merit.edu>; Thu, 15 May 2003 19:35:00 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by sj-core-2.cisco.com (8.12.6/8.12.6) with ESMTP id h4FNYuG4015534;
	Thu, 15 May 2003 16:34:56 -0700 (PDT)
Received: from gwzw2k (tokyo-vpn-user302.cisco.com [10.70.83.46]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with ESMTP id QAA27784; Thu, 15 May 2003 16:34:55 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "'Vernon Schryver'" <vjs@calcite.rhyolite.com>, <ietf-ppp@merit.edu>
Subject: RE: draft-song-pppext-sip-support-02.txt
Date: Thu, 15 May 2003 16:34:21 -0700
Organization: Cisco Systems
Message-ID: <006801c31b3a$953111e0$1200000a@amer.cisco.com>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----=_NextPart_000_0069_01C31AFF.E8D239E0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4024
In-Reply-To: <200305151423.h4FENe90012307@calcite.rhyolite.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Importance: Normal
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

This is a multi-part message in MIME format.

------=_NextPart_000_0069_01C31AFF.E8D239E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Vernon Schryver <mailto:vjs@calcite.rhyolite.com> writes:

>> From: "Glen Zorn" <gwz@cisco.com>
> 
>>> The proposal makes no sense.  Unless SIP Is utterly broken, there
>>> must be other means for discovering SIP proxy servers besides
>>> special link-layer kludges.  What happens on other point to point
>>> links that don't use PPP?
>> 
>> Who cares?
>> 
>>> What about point-to-point links that use PPP but not
>>> IPCP, such as only BCP?
>> 
>> Ditto.
> 
> Please stop the insults and think about what we've said.

I apologize if you feel that I've insulted you: that certainly wasn't my
intent; nor do I believe the questions to be facetious.  The draft in
question only addresses systems (specifically, 3GPP2 PDS) that run over
PPP/IP, so I really think that these objections are kind of irrelevant.
It seems much like calling FTP evil because it doesn't run over, say,
LU6.2.

> 
> If SIP is utterly broken, then there is no need for the proposal
> because it can't and won't be used.  Let's assume that SIP is not
> broken, not useless, and can be used and is used.  I don't know that
> SIP is good, but given the vast number of IDs and RFCs about it, I
> hope it is.  That SIP is good implies that it already has perfectly
> good mechanisms for finding proxies without this new, quite late
> idea. Thus this new, late idea is redundant, unnecessary, extra, and
> can only cause confusion and interoperation problems.     

I'm certainly not a SIP expert either, but OTOH I'm willing to entertain
the idea that some discovery/configuration methods that work perfectly
well in e.g., a high-bandwidth/low latency environment might not be
worth a damn in a more constrained one.

> 
> 
>>> Besides, this proposal could not and would not be widely deployed
>>> for a long time.  Unless SIP is utterly broken, those othe
>>> mechanisms, whatever they are, must render this mechanism
>>> irrelevant. 
>> 
>> Vern please read the document: "This draft specifies an IPCP (PPP
>> Internet Protocol Control Protocol) option that allows SIP clients to
>> locate a list of SIP proxy servers that is to be used for all SIP
>> requests. This approach is applicable to a system utilizing PPP for
>> its link layer protocol and IP address allocation (ex. 3GPP2 Packet
>>                                           Data System)."
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Presumably, 3GPP2 will be widely
>> deployed in less than a long time (if not, sell your Sprint stock
>> now ;-).  Please understand that I don't much care for this idea
>> either, but all of the arguments against it so far seem at best lame.
> 
> Whether 3GPP2 is deployed implies nothing that I can see.  I haven't
> been buying any more stock in 3G telephones than I did in WAP
> telephones and for some of the same reasons, but you should make your
> own investment decisions.  

Whatever we think of the future of 3G, my point was that if 3GPP2 has
decided that this is way to do it, it will be deployed.

> This PPP proposal stinks of the same sort
> of Internet Engineering that brought us WAP.  It is based on the
> assumption that existing mechanisms do not exist or are irrelevant.  

Since you and I both admit that we are basically ignorant of whatever
alternative mechanisms may exist, it seems that you are assuming that
this draft is based upon an assumption, rather than careful analysis of
the options in the context of the system under design. 
 
> 
> Perhaps the existing SIP mechanisms cannot work over PPP.  If that is
> true, then this proposal must say so and provide convincing technical
> reasons. 

I agree.
 
> 
> Let's cut the obscuring politeness and admit the main motive for
> these IDs.  Like the old Microsoft DNS server botch, they come from
> ignorance of existing standards and practices and an ambition to see
> one's name in the RFC index.   
> 
> The fact that this SIP proposal does not advert to the existence of
> any mechanism on other link layers without broadcasts to discover
> proxies suggests that the author does not know how SIP works on other
> media.  

Another possibility is that the author thinks that it is so completely
obvious that the question needn't be broached.  It would be very good if
they addressed the question, though.

> The IPCP default route proposal has a similar stigmata of not
> mentioning the ancient alternatives to its wonderful idea.  I'm sure
> that author is not trying to hide the alternatives but was innocently
> unaware of their ease, popularity, and effectiveness.  If all you
> know about routing comes from the cries of anquish of people fighting
> with BGP, you wouldn't consider using RIP for router discovery, not
> to mention the IP router discovery protocol or the ancient mechanism
> of adding routes as interfaces awaken.  If you don't really
> understand IPCP, you'd not realize that it makes no sense to put the
> IP address of the peer into the IPCP packet twice.  You'd also not
> recognize the dangerous swamp of policy routing you'd wandered into. 
> 
> 
> Vernon Schryver    vjs@rhyolite.com

~gwz

"They that can give up essential liberty to obtain a little temporary
safety deserve neither..." 

-- Benjamin Franklin, 1759


I've stopped 24,811 spam messages. You can too!
Get your free, safe spam protection at
http://www.cloudmark.com/spamnetsig/ 

------=_NextPart_000_0069_01C31AFF.E8D239E0
Content-Type: text/x-vcard;
	name="Glen Zorn.vcf"
Content-Disposition: attachment;
	filename="Glen Zorn.vcf"
Content-Transfer-Encoding: quoted-printable

BEGIN:VCARD
VERSION:2.1
N:Zorn;Glen
FN:Glen Zorn
ORG:Cisco Systems
TITLE:CTO Consulting Engineer
NOTE;ENCODING=3DQUOTED-PRINTABLE:PGP Key Fingerprint: 4F41 B93A 007D =
E2FC 9769  FB97 FBCF 7DA4 9A2D 1963=3D0D=3D
=3D0A=3D0D=3D0A
TEL;HOME;VOICE:+1 (425) 513-8512
TEL;CELL;VOICE:+1 (425) 344-8113
TEL;WORK;FAX:+1 (425) 740-0168
ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;500 108th Avenue =
N.E.=3D0D=3D0ASuite 500;Bellevue;WA;98004;USA
LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:500 108th Avenue =
N.E.=3D0D=3D0ASuite 500=3D0D=3D0ABellevue, WA 98004=3D0D=3D0AUSA
URL;WORK:http://www.cisco.com
EMAIL;PREF;INTERNET:gwz@cisco.com
REV:20021107T033833Z
END:VCARD

------=_NextPart_000_0069_01C31AFF.E8D239E0--




From owner-ietf-ppp@merit.edu  Thu May 15 20:41:32 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28474
	for <pppext-archive@lists.ietf.org>; Thu, 15 May 2003 20:41:32 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id CB3129122B; Thu, 15 May 2003 20:44:09 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 5FA33912DB; Thu, 15 May 2003 20:44:09 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 476249122B
	for <ietf-ppp@trapdoor.merit.edu>; Thu, 15 May 2003 20:44:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 0CCAD5E168; Thu, 15 May 2003 20:44:07 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from pit.databus.com (p70-227.acedsl.com [66.114.70.227])
	by segue.merit.edu (Postfix) with ESMTP id 84F895E167
	for <ietf-ppp@merit.edu>; Thu, 15 May 2003 20:44:06 -0400 (EDT)
Received: from pit.databus.com (localhost [127.0.0.1])
	by pit.databus.com (8.12.9/8.12.9) with ESMTP id h4G0i0iK011058;
	Thu, 15 May 2003 20:44:00 -0400 (EDT)
	(envelope-from barney@pit.databus.com)
Received: (from barney@localhost)
	by pit.databus.com (8.12.9/8.12.9/Submit) id h4G0i0up011057;
	Thu, 15 May 2003 20:44:00 -0400 (EDT)
Date: Thu, 15 May 2003 20:44:00 -0400
From: Barney Wolff <barney@databus.com>
To: Bernard Aboba <aboba@internaut.com>
Cc: Glen Zorn <gwz@cisco.com>, "'Thomas Narten'" <narten@us.ibm.com>,
        ietf-ppp@merit.edu
Subject: Re: draft-song-pppext-sip-support-02.txt
Message-ID: <20030516004400.GA10926@pit.databus.com>
References: <001d01c31b35$8c4b0810$1200000a@amer.cisco.com> <Pine.LNX.4.53.0305151541530.11939@internaut.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.53.0305151541530.11939@internaut.com>
User-Agent: Mutt/1.4.1i
X-Scanned-By: MIMEDefang 2.32 (www . roaringpenguin . com / mimedefang)
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

> Possibly.  So, presupposing that these devices use PPP, why would they
> choose to implement DHCP instead of an IPCP option?

Funny, I listened to this exact debate in the ipsec wg:  whether to pass
dhcp or invent a new mechanism.  Apparently the inventive urge is
universal.

DHCP is a perfectly respectable and useful protocol.  What is there that
people don't like about it?

The IESG really needs to speak up, and promulgate a policy that inventing
new ways to do old things is BAD unless the old ways are manifestly
inferior.

-- 
Barney Wolff         http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.


From owner-ietf-ppp@merit.edu  Thu May 15 22:02:55 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA29467
	for <pppext-archive@lists.ietf.org>; Thu, 15 May 2003 22:02:55 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 14C1191234; Thu, 15 May 2003 22:05:35 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id DCABE912DC; Thu, 15 May 2003 22:05:34 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 7B66691234
	for <ietf-ppp@trapdoor.merit.edu>; Thu, 15 May 2003 22:05:33 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 608B25E1A2; Thu, 15 May 2003 22:05:33 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from internaut.com (unknown [64.38.134.99])
	by segue.merit.edu (Postfix) with ESMTP id B3CF75E1DD
	for <ietf-ppp@merit.edu>; Thu, 15 May 2003 22:05:32 -0400 (EDT)
Received: from localhost (aboba@localhost)
	by internaut.com (8.10.2/8.10.2) with ESMTP id h4G1i4h22210;
	Thu, 15 May 2003 18:44:04 -0700
Date: Thu, 15 May 2003 18:44:04 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: Barney Wolff <barney@databus.com>
Cc: Glen Zorn <gwz@cisco.com>, "'Thomas Narten'" <narten@us.ibm.com>,
        ietf-ppp@merit.edu
Subject: Re: draft-song-pppext-sip-support-02.txt
In-Reply-To: <20030516004400.GA10926@pit.databus.com>
Message-ID: <Pine.LNX.4.53.0305151839350.21588@internaut.com>
References: <001d01c31b35$8c4b0810$1200000a@amer.cisco.com>
 <Pine.LNX.4.53.0305151541530.11939@internaut.com> <20030516004400.GA10926@pit.databus.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

> Funny, I listened to this exact debate in the ipsec wg:  whether to pass
> dhcp or invent a new mechanism.  Apparently the inventive urge is
> universal.

In the name of optimization, even reuse can be dangerous.  Given the
solutions for integrating DHCP, AAA and EAP which are now IPsec WG work
items, I'm not sure that they could have done worse inventing something new.

> DHCP is a perfectly respectable and useful protocol.  What is there that
> people don't like about it?

Traditionally people have been adverse to the idea of DHCP relays and the
extra latency involved in DHCP exchanges.  Also there is the need for
stable storage in classical DHCPv4 servers.

Neither of those considerations apply to stateless deployments of
DHCPINFORM, though.

> The IESG really needs to speak up, and promulgate a policy that inventing
> new ways to do old things is BAD unless the old ways are manifestly
> inferior.

The IAB has been looking at issuing some architectural guidance on the
subject of IP configuration.  If you think that there is something useful
that they could do you might send mail to iab@ietf.org proposing what that
is.


From owner-ietf-ppp@merit.edu  Fri May 16 22:04:51 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17045
	for <pppext-archive@lists.ietf.org>; Fri, 16 May 2003 22:04:51 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id CFE479123A; Fri, 16 May 2003 22:07:29 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 9775A91245; Fri, 16 May 2003 22:07:29 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 56A119123A
	for <ietf-ppp@trapdoor.merit.edu>; Fri, 16 May 2003 22:07:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 3B6E65DF28; Fri, 16 May 2003 22:07:28 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3])
	by segue.merit.edu (Postfix) with ESMTP id 68C3B5DF2D
	for <ietf-ppp@merit.edu>; Fri, 16 May 2003 22:07:27 -0400 (EDT)
Received: (from vjs@localhost)
	by calcite.rhyolite.com (8.12.9/8.12.9) id h4H27P9q014203
	for ietf-ppp@merit.edu env-from <vjs>;
	Fri, 16 May 2003 20:07:25 -0600 (MDT)
Date: Fri, 16 May 2003 20:07:25 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
Message-Id: <200305170207.h4H27P9q014203@calcite.rhyolite.com>
To: ietf-ppp@merit.edu
Subject: proposed draft IANA Considerations
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

Enclosed is a proposed IANA Considerations ID for PPP numbers.
What say you?  Should I send it to the RFC Editor?  Does it need
large or small changes?


Vernon Schryver    vjs@rhyolite.com

P.S. It's sad how much boilerplate required by the modern IETF, but not
   quite as sad as the need for this procedural change.



...........................................................................






Network Working Group                                           Schryver
Internet Draft                                         Rhyolite Software
                                                                May 2003



                      IANA Considerations for PPP


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 15, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.


1. Introduction

   The charter of the Point-to-Point Protocol Extensions (pppext)
   working group includes the responsibility to "actively advance PPP's
   most useful extensions to full standard, while defending against
   further enhancements of questionable value."  In support of that
   charter, the allocation of PPP protocol and other assigned numbers
   will no longer be "first come first served."


2. Terminology




Schryver                                                        [Page 1]

Internet-Draft       IP IANA Considerations for PPP             May 2003


   The terms "name space", "assigned value", and "registration" are used
   here with the meanings defined in BCP 26.  The policies "First Come
   First Served" and "IETF Consensus" used here also have the meanings
   defined in BCP 26.


3. IANA Considerations

   The Point-to-Point protocol (PPP, RFC 1661) is a mature protocol with
   a large number of subprotocols, encapsulations and other extensions.
   The main protocol as well as its extensions involve many name spaces
   in which values must be assigned.
   Http://www.iana.org/assignments/ppp-numbers contains a list of the
   address spaces and their current assignments.

   Historically, initial values in new name spaces have often been
   chosen in the RFCs creating the name spaces.  The IANA made
   subsequent assignments with a "First Come First Served" policy.  This
   memo changes that policy for some PPP address spaces.

   Most of the PPP names spaces are quiescent, but some continue to
   attract proposed extensions.  Extensions of PPP have been defined in
   RFCs that are "Informational" and so are not subject to review.
   These extensions usually require values assigned in one or more of
   the PPP name spaces.  Making these allocations require "IETF
   Consensus," usually through the Point-to-Point Protocol Extensions
   (pppext) working group, will ensure that proposals are reviewed.

   It is sufficient to require IETF Consensus for assigning new values
   in the following address spaces:

                DLL PROTOCOL NUMBERS
                LCP AND IPCP CODES
                LCP CONFIGURATION OPTION TYPES
                CCP CONFIGURATION OPTION TYPES
                AUTHENTICATION ALGORITHMS
                LCP FCS-ALTERNATIVES
                MULTILINK ENDPOINT DISCRIMINATOR CLASS
                LCP CALLBACK OPERATION FIELDS
                BRIDGING CONFIGURATION OPTION TYPES
                BRIDGING MAC TYPES
                BRIDGING SPANNING TREE
                EAP REQUEST/RESPONSE TYPES
                IPCP CONFIGURATION OPTION TYPES
                IPV6CP CONFIGURATION OPTIONS
                IP-Compression-Protocol Types





Schryver                                                        [Page 2]

Internet-Draft       IP IANA Considerations for PPP             May 2003


4. Security Considerations

      This memo deals with matters of process, not protocol.


Normative References

[RFC2434]   Alvestrand, H. and T. Narten, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 2434,
            October 1998.

Author's Address

   Vernon Schryver
   Rhyolite Software
   2482 Lee Hill Drive
   Boulder, Colorado 80302

   EMail: vjs@rhyolite.com


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.




Schryver                                                        [Page 3]

Internet-Draft       IP IANA Considerations for PPP             May 2003


   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION






























Schryver                                                        [Page 4]



From owner-ietf-ppp@merit.edu  Fri May 16 22:56:36 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17755
	for <pppext-archive@lists.ietf.org>; Fri, 16 May 2003 22:56:35 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id A884891319; Fri, 16 May 2003 22:59:15 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 6D7909131A; Fri, 16 May 2003 22:59:15 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 7E76691319
	for <ietf-ppp@trapdoor.merit.edu>; Fri, 16 May 2003 22:59:14 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 580965DF48; Fri, 16 May 2003 22:59:14 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from internaut.com (unknown [64.38.134.99])
	by segue.merit.edu (Postfix) with ESMTP id E099A5DEC1
	for <ietf-ppp@merit.edu>; Fri, 16 May 2003 22:59:13 -0400 (EDT)
Received: from localhost (aboba@localhost)
	by internaut.com (8.10.2/8.10.2) with ESMTP id h4H2bbP08397;
	Fri, 16 May 2003 19:37:37 -0700
Date: Fri, 16 May 2003 19:37:37 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: Vernon Schryver <vjs@calcite.rhyolite.com>
Cc: ietf-ppp@merit.edu
Subject: Re: proposed draft IANA Considerations
In-Reply-To: <200305170207.h4H27P9q014203@calcite.rhyolite.com>
Message-ID: <Pine.LNX.4.53.0305161936090.8231@internaut.com>
References: <200305170207.h4H27P9q014203@calcite.rhyolite.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

One  comment -- allocation policy for EAP Request/Response types is being
handled in RFC 2284bis (and is also being upgraded from FCFS).  So you
don't need to bother with that one.





From owner-ietf-ppp@merit.edu  Mon May 19 12:03:07 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25357
	for <pppext-archive@lists.ietf.org>; Mon, 19 May 2003 12:03:07 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id F355991212; Mon, 19 May 2003 12:05:20 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id BEEE391213; Mon, 19 May 2003 12:05:19 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 946E291212
	for <ietf-ppp@trapdoor.merit.edu>; Mon, 19 May 2003 12:05:18 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 80CEC5DDB0; Mon, 19 May 2003 12:05:18 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3])
	by segue.merit.edu (Postfix) with ESMTP id AE8755DDAD
	for <ietf-ppp@merit.edu>; Mon, 19 May 2003 12:05:17 -0400 (EDT)
Received: (from vjs@localhost)
	by calcite.rhyolite.com (8.12.9/8.12.9) id h4JG5GEJ014372
	for ietf-ppp@merit.edu env-from <vjs>;
	Mon, 19 May 2003 10:05:16 -0600 (MDT)
Date: Mon, 19 May 2003 10:05:16 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
Message-Id: <200305191605.h4JG5GEJ014372@calcite.rhyolite.com>
To: ietf-ppp@merit.edu
Subject: Re: Extending IPCP  for Route Table Entries
References: <3EC8FCCE.6020904@heeltoe.com>
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

> From: Brad Parker <brad@heeltoe.com>

> ...
> >   - adding routes based on a RIP packet is no slower or more
> >      cumbersome than adding routes with any other mechanism.  
>
> 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 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 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't see any lack of reliability in adding routes based on RIP packets 
>
> 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?


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


> >>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.
>
> as I said before, it's not the default route that is the interesting 
> part.  It's the other-link/other-route.
>
> > 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."
>
> 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?


Vernon Schryver    vjs@rhyolite.com


From owner-ietf-ppp@merit.edu  Tue May 20 10:00:56 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13462
	for <pppext-archive@lists.ietf.org>; Tue, 20 May 2003 10:00:51 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 90BF991259; Tue, 20 May 2003 10:03:02 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 5EB599125F; Tue, 20 May 2003 10:03:02 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id EB16191259
	for <ietf-ppp@trapdoor.merit.edu>; Tue, 20 May 2003 10:03:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id D58855DDCB; Tue, 20 May 2003 10:03:00 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3])
	by segue.merit.edu (Postfix) with ESMTP id 25CAA5DDCA
	for <ietf-ppp@merit.edu>; Tue, 20 May 2003 10:02:59 -0400 (EDT)
Received: (from vjs@localhost)
	by calcite.rhyolite.com (8.12.9/8.12.9) id h4KE2skX023141
	for ietf-ppp@merit.edu env-from <vjs>;
	Tue, 20 May 2003 08:02:54 -0600 (MDT)
Date: Tue, 20 May 2003 08:02:54 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
Message-Id: <200305201402.h4KE2skX023141@calcite.rhyolite.com>
To: ietf-ppp@merit.edu
Subject: Re: Extending IPCP  for Route Table Entries
References:  <3ECA2DEA.1020800@heeltoe.com>
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

> From: Brad Parker <brad@heeltoe.com>

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


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

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


Vernon Schryver    vjs@rhyolite.com


From owner-ietf-ppp@merit.edu  Tue May 20 10:07:22 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14049
	for <pppext-archive@lists.ietf.org>; Tue, 20 May 2003 10:07:21 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id AF00A91258; Tue, 20 May 2003 10:10:08 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 848C39125A; Tue, 20 May 2003 10:10:08 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 6878191258
	for <ietf-ppp@trapdoor.merit.edu>; Tue, 20 May 2003 10:10:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 2F3565DDA1; Tue, 20 May 2003 10:10:07 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3])
	by segue.merit.edu (Postfix) with ESMTP id 59B3B5DDC2
	for <ietf-ppp@merit.edu>; Tue, 20 May 2003 10:10:06 -0400 (EDT)
Received: (from vjs@localhost)
	by calcite.rhyolite.com (8.12.9/8.12.9) id h4KEA08d025571
	for ietf-ppp@merit.edu env-from <vjs>;
	Tue, 20 May 2003 08:10:00 -0600 (MDT)
Date: Tue, 20 May 2003 08:10:00 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
Message-Id: <200305201410.h4KEA08d025571@calcite.rhyolite.com>
To: ietf-ppp@merit.edu
Subject:  I-D ACTION:draft-schryver-pppext-iana-00.txt 
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

I don't know if the RFC editor normally sends copies of ID announcements
to this mailing list these days, but it seems it won't happen for the
ID to change the IANA considerations for many PPP numbers from "First
come, first served" to "IETF consensus."

The announcement is in
http://www1.ietf.org/mail-archive/ietf-announce/Current/msg24163.html

The draft can be found in 
http://www.ietf.org/internet-drafts/draft-schryver-pppext-iana-00.txt

What needs to be done to get the ID advanced, after it has been 
modified or corrected?


Vernon Schryver    vjs@rhyolite.com


From owner-ietf-ppp@merit.edu  Tue May 20 10:21:57 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15298
	for <pppext-archive@lists.ietf.org>; Tue, 20 May 2003 10:21:56 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 03D869125A; Tue, 20 May 2003 10:24:47 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id C38929125B; Tue, 20 May 2003 10:24:46 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id A756B9125A
	for <ietf-ppp@trapdoor.merit.edu>; Tue, 20 May 2003 10:24:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 927665DDA8; Tue, 20 May 2003 10:24:45 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from goliath.siemens.com (goliath.siemens.com [194.138.160.6])
	by segue.merit.edu (Postfix) with ESMTP id 977575DDA4
	for <ietf-ppp@merit.edu>; Tue, 20 May 2003 10:24:44 -0400 (EDT)
Received: from mail-usa.sbs.siemens.com (mail-usa.sbs.siemens.com [129.73.68.4])
	by goliath.siemens.com (8.11.7/8.11.7) with ESMTP id h4KEOfJ24076;
	Tue, 20 May 2003 10:24:45 -0400 (EDT)
Received: from bambam.inside.efficient.com ([165.218.188.5])
	by mail-usa.sbs.siemens.com (8.11.6/8.11.6) with ESMTP id h4KEOeF27715;
	Tue, 20 May 2003 10:24:40 -0400 (EDT)
Received: by bambam.inside.efficient.com with Internet Mail Service (5.5.2653.19)
	id <LD4HR6R2>; Tue, 20 May 2003 09:24:37 -0500
Message-ID: <CD779E609614D611A3FC00508B0F1CB63A51EC@pebbles.inside.efficient.com>
From: Doug Kehn <dkehn@efficient.com>
To: "'Vernon Schryver '" <vjs@calcite.rhyolite.com>,
        "'ietf-ppp@merit.edu '" <ietf-ppp@merit.edu>
Subject: RE: Extending IPCP  for Route Table Entries
Date: Tue, 20 May 2003 09:24:29 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

>From: Vernon Schryver

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

1. [DSL specific] Each PPP link could be transported across a separate ATM
PVC.  The ATM PVCs could be switched, in the Access Providers network, to
separate PPP termination points.  The CPE would be configured to bring up
each PPP link.  Once each PPP link was established, the CPE's routing table
would contain a host route entry to the remote peer for each PPP interface.
At this point the CPE has mutlitple PPP interfaces which packets can be
routed.  The remote peers don't necessarily know or care about all the
remote peers that the CPE is attached.

2. [PPPoE specific]  The CPE could request a unique Access
Concentrator/Service for each PPP link.  Each Access Concentrator/Service
combination could be linked (i.e. L2TP) to separate PPP termination points.
The CPE would be configured to bring up each PPPoE link.  Once each PPPoE
link was established, the CPE's routing table would contain a host route
entry to the remote peer for each PPPoE interface.  At this point the CPE
has mutlitple PPPoE interfaces which packets can be routed.  The remote
peers don't necessarily know or care about all the remote peers that the CPE
is attached.



From owner-ietf-ppp@merit.edu  Tue May 20 10:36:23 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15923
	for <pppext-archive@lists.ietf.org>; Tue, 20 May 2003 10:36:22 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id D82769125C; Tue, 20 May 2003 10:39:18 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id A7BBA9125D; Tue, 20 May 2003 10:39:18 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 36CC69125C
	for <ietf-ppp@trapdoor.merit.edu>; Tue, 20 May 2003 10:39:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 21B0A5DDC5; Tue, 20 May 2003 10:39:16 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3])
	by segue.merit.edu (Postfix) with ESMTP id 276685DDC3
	for <ietf-ppp@merit.edu>; Tue, 20 May 2003 10:39:14 -0400 (EDT)
Received: (from vjs@localhost)
	by calcite.rhyolite.com (8.12.9/8.12.9) id h4KEdB1x028961
	for ietf-ppp@merit.edu env-from <vjs>;
	Tue, 20 May 2003 08:39:11 -0600 (MDT)
Date: Tue, 20 May 2003 08:39:11 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
Message-Id: <200305201439.h4KEdB1x028961@calcite.rhyolite.com>
To: ietf-ppp@merit.edu
Subject: RE: Extending IPCP  for Route Table Entries
References: <CD779E609614D611A3FC00508B0F1CB63A51EC@pebbles.inside.efficient.com>
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

> From: Doug Kehn <dkehn@efficient.com>

> >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?
>
> 1. [DSL specific] Each PPP link could be transported across a separate ATM
> PVC.  The ATM PVCs could be switched, in the Access Providers network, to
> separate PPP termination points.  The CPE would be configured to bring up
> each PPP link.  Once each PPP link was established, the CPE's routing table
> would contain a host route entry to the remote peer for each PPP interface.
> At this point the CPE has mutlitple PPP interfaces which packets can be
> routed.  The remote peers don't necessarily know or care about all the
> remote peers that the CPE is attached.
>
> 2. [PPPoE specific]  The CPE could request a unique Access
> Concentrator/Service for each PPP link.  Each Access Concentrator/Service
> combination could be linked (i.e. L2TP) to separate PPP termination points.
> The CPE would be configured to bring up each PPPoE link.  Once each PPPoE
> link was established, the CPE's routing table would contain a host route
> entry to the remote peer for each PPPoE interface.  At this point the CPE
> has mutlitple PPPoE interfaces which packets can be routed.  The remote
> peers don't necessarily know or care about all the remote peers that the CPE
> is attached.

Isn't that exactly the way things work today without the proposed
IPCP extension?

How is the proposal used in either the DSL or PPPoE case?  
In either case, doesn't one set of PPP state machines need to know
about each other so that one of them can include the proposed
extra IPCP option?

How is the PPP state machine that should include the proposed extra
IPCP option chosen?  What distinguishes that PPP link from the others?

I clearly don't understand the scenarios in which the proposed IPCP
option would be used.  I thought it had something to do with 3G
radio-telephones.  Could you repeat the description of the game (?)
scenario with different words?


Vernon Schryver    vjs@rhyolite.com


From owner-ietf-ppp@merit.edu  Tue May 20 11:08:04 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17029
	for <pppext-archive@lists.ietf.org>; Tue, 20 May 2003 11:08:02 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 0F1349125E; Tue, 20 May 2003 11:10:51 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id CEBBE9125F; Tue, 20 May 2003 11:10:50 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 962729125E
	for <ietf-ppp@trapdoor.merit.edu>; Tue, 20 May 2003 11:10:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 7554A5DDEA; Tue, 20 May 2003 11:10:49 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from goliath.siemens.com (goliath.siemens.com [194.138.160.6])
	by segue.merit.edu (Postfix) with ESMTP id F408E5DDD1
	for <ietf-ppp@merit.edu>; Tue, 20 May 2003 11:10:48 -0400 (EDT)
Received: from mail-usa.sbs.siemens.com (mail-usa.sbs.siemens.com [129.73.68.4])
	by goliath.siemens.com (8.11.7/8.11.7) with ESMTP id h4KFAoJ10933;
	Tue, 20 May 2003 11:10:50 -0400 (EDT)
Received: from yogi.inside.efficient.com ([165.218.188.2])
	by mail-usa.sbs.siemens.com (8.11.6/8.11.6) with ESMTP id h4KFAmF16445;
	Tue, 20 May 2003 11:10:48 -0400 (EDT)
Received: by yogi.inside.efficient.com with Internet Mail Service (5.5.2653.19)
	id <LDSW0LVV>; Tue, 20 May 2003 10:10:46 -0500
Message-ID: <CD779E609614D611A3FC00508B0F1CB63A51EE@pebbles.inside.efficient.com>
From: Doug Kehn <dkehn@efficient.com>
To: "'Vernon Schryver'" <vjs@calcite.rhyolite.com>, ietf-ppp@merit.edu
Subject: RE: Extending IPCP  for Route Table Entries
Date: Tue, 20 May 2003 10:10:39 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

> From: Vernon Schryver [mailto:vjs@calcite.rhyolite.com]
> 
> 
> > From: Brad Parker <brad@heeltoe.com>
> 

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    vjs@rhyolite.com
> 


From owner-ietf-ppp@merit.edu  Tue May 20 11:21:49 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17417
	for <pppext-archive@lists.ietf.org>; Tue, 20 May 2003 11:21:49 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 7542D9125F; Tue, 20 May 2003 11:24:40 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 40CE991260; Tue, 20 May 2003 11:24:40 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 26A409125F
	for <ietf-ppp@trapdoor.merit.edu>; Tue, 20 May 2003 11:24:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 0C2515DDFB; Tue, 20 May 2003 11:24:39 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by segue.merit.edu (Postfix) with ESMTP id 802955DDF9
	for <ietf-ppp@merit.edu>; Tue, 20 May 2003 11:24:38 -0400 (EDT)
Received: from eastmail2bur.East.Sun.COM ([129.148.13.40])
	by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4KFOQsa004711;
	Tue, 20 May 2003 09:24:26 -0600 (MDT)
Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143])
	by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4KFOPEg002444;
	Tue, 20 May 2003 11:24:25 -0400 (EDT)
Received: from phorcys.East.Sun.COM (localhost [127.0.0.1])
	by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id h4KFOP6e011166;
	Tue, 20 May 2003 11:24:25 -0400 (EDT)
Received: (from carlsonj@localhost)
	by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9/Submit) id h4KFOPTt011163;
	Tue, 20 May 2003 11:24:25 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16074.18601.268635.128179@gargle.gargle.HOWL>
Date: Tue, 20 May 2003 11:24:25 -0400
From: James Carlson <james.d.carlson@east.sun.com>
To: Doug Kehn <dkehn@efficient.com>
Cc: "'Vernon Schryver'" <vjs@calcite.rhyolite.com>, ietf-ppp@merit.edu
Subject: RE: Extending IPCP  for Route Table Entries
In-Reply-To: Doug Kehn's message of 20 May 2003 10:10:39
References: <CD779E609614D611A3FC00508B0F1CB63A51EE@pebbles.inside.efficient.com>
X-Mailer: VM 7.01 under Emacs 21.2.1
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu
Content-Transfer-Encoding: 7bit

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@east.sun.com>
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 owner-ietf-ppp@merit.edu  Tue May 20 11:28:29 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17669
	for <pppext-archive@lists.ietf.org>; Tue, 20 May 2003 11:28:28 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 6AD4E91260; Tue, 20 May 2003 11:30:32 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 3C61791262; Tue, 20 May 2003 11:30:32 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 141AF91260
	for <ietf-ppp@trapdoor.merit.edu>; Tue, 20 May 2003 11:30:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 0299A5DDFA; Tue, 20 May 2003 11:30:31 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3])
	by segue.merit.edu (Postfix) with ESMTP id 9E0295DE14
	for <ietf-ppp@merit.edu>; Tue, 20 May 2003 11:30:29 -0400 (EDT)
Received: (from vjs@localhost)
	by calcite.rhyolite.com (8.12.9/8.12.9) id h4KFUSeb012319
	for ietf-ppp@merit.edu env-from <vjs>;
	Tue, 20 May 2003 09:30:28 -0600 (MDT)
Date: Tue, 20 May 2003 09:30:28 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
Message-Id: <200305201530.h4KFUSeb012319@calcite.rhyolite.com>
To: ietf-ppp@merit.edu
Subject: RE: Extending IPCP  for Route Table Entries
References: <CD779E609614D611A3FC00508B0F1CB63A51EE@pebbles.inside.efficient.com>
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

> From: Doug Kehn <dkehn@efficient.com>

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



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

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

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


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


Vernon Schryver    vjs@rhyolite.com


From owner-ietf-ppp@merit.edu  Tue May 20 12:25:33 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20154
	for <pppext-archive@lists.ietf.org>; Tue, 20 May 2003 12:25:33 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 8628291252; Tue, 20 May 2003 12:25:59 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 53BBC91261; Tue, 20 May 2003 12:25:59 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 08DC791252
	for <ietf-ppp@trapdoor.merit.edu>; Tue, 20 May 2003 12:25:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id E57325DE4A; Tue, 20 May 2003 12:25:57 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from david.siemens.com (david.siemens.com [194.138.160.5])
	by segue.merit.edu (Postfix) with ESMTP id 4F93A5DE48
	for <ietf-ppp@merit.edu>; Tue, 20 May 2003 12:25:56 -0400 (EDT)
Received: from mail-usa.sbs.siemens.com (mail-usa.sbs.siemens.com [129.73.68.4])
	by david.siemens.com (8.11.7/8.11.7) with ESMTP id h4KGPt007195;
	Tue, 20 May 2003 12:25:56 -0400 (EDT)
Received: from yogi.inside.efficient.com ([165.218.188.2])
	by mail-usa.sbs.siemens.com (8.11.6/8.11.6) with ESMTP id h4KGPrF15551;
	Tue, 20 May 2003 12:25:54 -0400 (EDT)
Received: by yogi.inside.efficient.com with Internet Mail Service (5.5.2653.19)
	id <LDSW0M7X>; Tue, 20 May 2003 11:25:51 -0500
Message-ID: <CD779E609614D611A3FC00508B0F1CB63A51EF@pebbles.inside.efficient.com>
From: Doug Kehn <dkehn@efficient.com>
To: "'James Carlson '" <james.d.carlson@east.sun.com>,
        Doug Kehn <dkehn@efficient.com>
Cc: "''Vernon Schryver' '" <vjs@calcite.rhyolite.com>,
        "'ietf-ppp@merit.edu '" <ietf-ppp@merit.edu>
Subject: RE: Extending IPCP  for Route Table Entries
Date: Tue, 20 May 2003 11:25:46 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

From the outset, it has been acknowledged that this proposal duplicates what
could be done with a routing protocol.  The argument for the duplication is
that a routing protocol is "seen" as overkill when all that the Service
Providers are wanting to do is add a single (okay...maybe two) static route
entries on an interface.  Another factor to consider is the realization that
CPE cost is being driven down to that of a dial-up modem.  Cost reductions
are mainly realized through using lower density flash/RAM (when dealing with
100K+ magnitude every penny counts).  Lower memory density means that
features must be removed/reduced as every byte counts.

Also, Service Providers (I'm referring to broadband) use PPP because it
provides accountability and authentication.  It also resembles the familiar
dial-up model.  However, a problem arises as PPP termination moves off the
PC and on to the CPE.  The CPE now becomes a router but is straddled with a
point-to-point WAN interface when what is really needed is a networked
interface.  I don't see (my opinion of course) Service Providers moving away
from PPP because of the cost already invested in a PPP infrastructure.

At the expense of duplication could another method be found to solve the
problems.  If the Route-Add option isn't appealing, maybe reconsider Option
144 (Subnet mask) again.


-----Original Message-----
From: James Carlson
To: Doug Kehn
Cc: 'Vernon Schryver'; ietf-ppp@merit.edu
Sent: 5/20/03 10:24 AM
Subject: 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@east.sun.com>
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 owner-ietf-ppp@merit.edu  Tue May 20 12:36:41 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20587
	for <pppext-archive@lists.ietf.org>; Tue, 20 May 2003 12:36:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id E5D8C91262; Tue, 20 May 2003 12:37:12 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id A92EC91263; Tue, 20 May 2003 12:37:12 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 9D65591262
	for <ietf-ppp@trapdoor.merit.edu>; Tue, 20 May 2003 12:37:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 8AB325DE62; Tue, 20 May 2003 12:37:11 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3])
	by segue.merit.edu (Postfix) with ESMTP id 4E0D55DE5B
	for <ietf-ppp@merit.edu>; Tue, 20 May 2003 12:37:09 -0400 (EDT)
Received: (from vjs@localhost)
	by calcite.rhyolite.com (8.12.9/8.12.9) id h4KGatkV023951
	for ietf-ppp@merit.edu env-from <vjs>;
	Tue, 20 May 2003 10:36:55 -0600 (MDT)
Date: Tue, 20 May 2003 10:36:55 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
Message-Id: <200305201636.h4KGatkV023951@calcite.rhyolite.com>
To: ietf-ppp@merit.edu
Subject: RE: Extending IPCP  for Route Table Entries
References:  <CD779E609614D611A3FC00508B0F1CB63A51EF@pebbles.inside.efficient.com>
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

> From: Doug Kehn <dkehn@efficient.com>

> >From the outset, it has been acknowledged that this proposal duplicates what
> could be done with a routing protocol.  The argument for the duplication is
> that a routing protocol is "seen" as overkill when all that the Service
> Providers are wanting to do is add a single (okay...maybe two) static route
> entries on an interface.  Another factor to consider is the realization that
> CPE cost is being driven down to that of a dial-up modem.  Cost reductions
> are mainly realized through using lower density flash/RAM (when dealing with
> 100K+ magnitude every penny counts).  Lower memory density means that
> features must be removed/reduced as every byte counts.

Are you sure that even a penny would be needed for the at most 2000 
instructions needed to implement the fragment of RIP required to
have the same effect as the proposed IPCP option?

Could you justify the implicit claim that it would cost more in the
CPE to implement the necessary fragment of RIP than to implement the
same functions with the propsed IPCP option?  I suspect that in fact
the IPCP implementation would require more code, because there are
more corner cases.  For example, you don't need to handle configure-Naks
and and configure-Rejs in the RIP case.  Both cases require the same
changes to the CPE's routing table.  Both require the same sanity
checking of the route itself.

Given the reported popularity of software n CPE that is not known for
its small size, such as Windows CE, worrying about 100 lines of C or
2000 machine instructions seems misplaced.


> Also, Service Providers (I'm referring to broadband) use PPP because it
> provides accountability and authentication.  It also resembles the familiar
> dial-up model.  However, a problem arises as PPP termination moves off the
> PC and on to the CPE.  The CPE now becomes a router but is straddled with a
> point-to-point WAN interface when what is really needed is a networked
> interface.  I don't see (my opinion of course) Service Providers moving away
> from PPP because of the cost already invested in a PPP infrastructure.

What is a "networked interface" and how does it differ from at "point-to-point 
WAN interface?"  Both seem to involve PPP.


> At the expense of duplication could another method be found to solve the
> problems.  If the Route-Add option isn't appealing, maybe reconsider Option
> 144 (Subnet mask) again.

I can't find any such option in http://www.iana.org/assignments/ppp-numbers


Vernon Schryver    vjs@rhyolite.com


From owner-ietf-ppp@merit.edu  Tue May 20 12:45:50 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20903
	for <pppext-archive@lists.ietf.org>; Tue, 20 May 2003 12:45:49 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id A559A91263; Tue, 20 May 2003 12:46:23 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 6A7A091264; Tue, 20 May 2003 12:46:23 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 4757C91263
	for <ietf-ppp@trapdoor.merit.edu>; Tue, 20 May 2003 12:46:15 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 25B4A5DE69; Tue, 20 May 2003 12:46:15 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from goliath.siemens.com (goliath.siemens.com [194.138.160.6])
	by segue.merit.edu (Postfix) with ESMTP id B2D0F5DE19
	for <ietf-ppp@merit.edu>; Tue, 20 May 2003 12:46:14 -0400 (EDT)
Received: from mail-usa.sbs.siemens.com (mail-usa.sbs.siemens.com [129.73.68.4])
	by goliath.siemens.com (8.11.7/8.11.7) with ESMTP id h4KGkFT14229;
	Tue, 20 May 2003 12:46:15 -0400 (EDT)
Received: from yogi.inside.efficient.com ([165.218.188.2])
	by mail-usa.sbs.siemens.com (8.11.6/8.11.6) with ESMTP id h4KGkEF22013;
	Tue, 20 May 2003 12:46:14 -0400 (EDT)
Received: by yogi.inside.efficient.com with Internet Mail Service (5.5.2653.19)
	id <LDSW0N2T>; Tue, 20 May 2003 11:46:12 -0500
Message-ID: <CD779E609614D611A3FC00508B0F1CB63A51F1@pebbles.inside.efficient.com>
From: Doug Kehn <dkehn@efficient.com>
To: "'Vernon Schryver'" <vjs@calcite.rhyolite.com>, ietf-ppp@merit.edu
Subject: RE: Extending IPCP  for Route Table Entries
Date: Tue, 20 May 2003 11:46:06 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

> From: Vernon Schryver [mailto:vjs@calcite.rhyolite.com]
> 
> > From: Doug Kehn <dkehn@efficient.com>
> 
> > >   - 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    vjs@rhyolite.com
> 


From owner-ietf-ppp@merit.edu  Tue May 20 13:05:23 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21494
	for <pppext-archive@lists.ietf.org>; Tue, 20 May 2003 13:05:22 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 67C2391264; Tue, 20 May 2003 13:05:58 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 395C491265; Tue, 20 May 2003 13:05:58 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 00BB691264
	for <ietf-ppp@trapdoor.merit.edu>; Tue, 20 May 2003 13:05:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id DC5165DE81; Tue, 20 May 2003 13:05:56 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3])
	by segue.merit.edu (Postfix) with ESMTP id 9E3B85DE1F
	for <ietf-ppp@merit.edu>; Tue, 20 May 2003 13:05:55 -0400 (EDT)
Received: (from vjs@localhost)
	by calcite.rhyolite.com (8.12.9/8.12.9) id h4KH5kAI003850
	for ietf-ppp@merit.edu env-from <vjs>;
	Tue, 20 May 2003 11:05:46 -0600 (MDT)
Date: Tue, 20 May 2003 11:05:46 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
Message-Id: <200305201705.h4KH5kAI003850@calcite.rhyolite.com>
To: ietf-ppp@merit.edu
Subject: RE: Extending IPCP  for Route Table Entries
References: <CD779E609614D611A3FC00508B0F1CB63A51F1@pebbles.inside.efficient.com>
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

> From: Doug Kehn <dkehn@efficient.com>

> > > >   - how many IP addresses are negotiated with IPCP for the 
> > > > two PPP links,
> > > >       0, 1, 2, 3, or 4?  ...

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

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
> > > >    switch to the remaining 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?

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

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

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?


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

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


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

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.

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.


Vernon Schryver    vjs@rhyolite.com


From owner-ietf-ppp@merit.edu  Tue May 20 13:47:18 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22801
	for <pppext-archive@lists.ietf.org>; Tue, 20 May 2003 13:47:18 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 2689191265; Tue, 20 May 2003 13:46:52 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id E01AC91266; Tue, 20 May 2003 13:46:51 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id D830D91265
	for <ietf-ppp@trapdoor.merit.edu>; Tue, 20 May 2003 13:46:50 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id BE2635DECA; Tue, 20 May 2003 13:46:50 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by segue.merit.edu (Postfix) with ESMTP id 4A02A5DDA9
	for <ietf-ppp@merit.edu>; Tue, 20 May 2003 13:46:50 -0400 (EDT)
Received: from eastmail2bur.East.Sun.COM ([129.148.13.40])
	by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4KHkGx9015327;
	Tue, 20 May 2003 10:46:16 -0700 (PDT)
Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143])
	by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4KHkFEg010986;
	Tue, 20 May 2003 13:46:15 -0400 (EDT)
Received: from phorcys.East.Sun.COM (localhost [127.0.0.1])
	by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id h4KHkF6e011987;
	Tue, 20 May 2003 13:46:15 -0400 (EDT)
Received: (from carlsonj@localhost)
	by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9/Submit) id h4KHkF3s011984;
	Tue, 20 May 2003 13:46:15 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16074.27111.497748.906222@gargle.gargle.HOWL>
Date: Tue, 20 May 2003 13:46:15 -0400
From: James Carlson <james.d.carlson@east.sun.com>
To: Brad Parker <brad@heeltoe.com>
Cc: Doug Kehn <dkehn@efficient.com>,
        "'Vernon Schryver'" <vjs@calcite.rhyolite.com>, ietf-ppp@merit.edu
Subject: Re: Extending IPCP  for Route Table Entries
In-Reply-To: Brad Parker's message of 20 May 2003 13:40:37
References: <CD779E609614D611A3FC00508B0F1CB63A51EE@pebbles.inside.efficient.com>
	<16074.18601.268635.128179@gargle.gargle.HOWL>
	<3ECA6895.4010008@heeltoe.com>
X-Mailer: VM 7.01 under Emacs 21.2.1
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu
Content-Transfer-Encoding: 7bit

Brad Parker writes:
> > If you had multiple Ethernet NICs, where would you get your non-local
> > routes?  You wouldn't have an IPCP to modify.
> 
> 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.

> > If some solution works reasonably for Ethernet interfaces, why does
> > that solution not work for PPP?
> 
> 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.

-- 
James Carlson, Solaris Networking         <james.d.carlson@east.sun.com>
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 owner-ietf-ppp@merit.edu  Tue May 20 14:25:45 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24098
	for <pppext-archive@lists.ietf.org>; Tue, 20 May 2003 14:25:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id CA29191269; Tue, 20 May 2003 14:25:27 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 91A4E9126A; Tue, 20 May 2003 14:25:27 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 7D8E991269
	for <ietf-ppp@trapdoor.merit.edu>; Tue, 20 May 2003 14:25:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 6B95C5DF21; Tue, 20 May 2003 14:25:26 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3])
	by segue.merit.edu (Postfix) with ESMTP id B8F855DF27
	for <ietf-ppp@merit.edu>; Tue, 20 May 2003 14:25:25 -0400 (EDT)
Received: (from vjs@localhost)
	by calcite.rhyolite.com (8.12.9/8.12.9) id h4KIPOe0023170
	for ietf-ppp@merit.edu env-from <vjs>;
	Tue, 20 May 2003 12:25:24 -0600 (MDT)
Date: Tue, 20 May 2003 12:25:24 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
Message-Id: <200305201825.h4KIPOe0023170@calcite.rhyolite.com>
To: ietf-ppp@merit.edu
Subject: Re: Extending IPCP  for Route Table Entries
References: <CD779E609614D611A3FC00508B0F1CB63A51EE@pebbles.inside.efficient.com>
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

> From: James Carlson <james.d.carlson@east.sun.com>
> To: Brad Parker <brad@heeltoe.com>

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

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.


Vernon Schryver    vjs@rhyolite.com


From owner-ietf-ppp@merit.edu  Tue May 20 14:35:33 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24471
	for <pppext-archive@lists.ietf.org>; Tue, 20 May 2003 14:35:33 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id ADBB99126B; Tue, 20 May 2003 14:35:16 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 7F57A9126C; Tue, 20 May 2003 14:35:16 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 819D49126B
	for <ietf-ppp@trapdoor.merit.edu>; Tue, 20 May 2003 14:35:15 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 6D1BD5DF3D; Tue, 20 May 2003 14:35:15 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id E0B2D5DF3C
	for <ietf-ppp@merit.edu>; Tue, 20 May 2003 14:35:14 -0400 (EDT)
Received: from eastmail2bur.East.Sun.COM ([129.148.13.40])
	by brmea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4KIZ1Y9027886;
	Tue, 20 May 2003 12:35:01 -0600 (MDT)
Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143])
	by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4KIZ1Eg022937;
	Tue, 20 May 2003 14:35:01 -0400 (EDT)
Received: from phorcys.East.Sun.COM (localhost [127.0.0.1])
	by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id h4KIZ16e012044;
	Tue, 20 May 2003 14:35:01 -0400 (EDT)
Received: (from carlsonj@localhost)
	by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9/Submit) id h4KIZ1EE012041;
	Tue, 20 May 2003 14:35:01 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16074.30037.250657.317739@gargle.gargle.HOWL>
Date: Tue, 20 May 2003 14:35:01 -0400
From: James Carlson <james.d.carlson@east.sun.com>
To: Vernon Schryver <vjs@calcite.rhyolite.com>
Cc: ietf-ppp@merit.edu
Subject: Re: Extending IPCP  for Route Table Entries
In-Reply-To: Vernon Schryver's message of 20 May 2003 12:25:24
References: <CD779E609614D611A3FC00508B0F1CB63A51EE@pebbles.inside.efficient.com>
	<200305201825.h4KIPOe0023170@calcite.rhyolite.com>
X-Mailer: VM 7.01 under Emacs 21.2.1
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu
Content-Transfer-Encoding: 7bit

Vernon Schryver writes:
> > > 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.
> 
> 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.

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.

-- 
James Carlson, Solaris Networking         <james.d.carlson@east.sun.com>
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 owner-ietf-ppp@merit.edu  Tue May 20 14:51:36 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24911
	for <pppext-archive@lists.ietf.org>; Tue, 20 May 2003 14:51:36 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 90A2A9126C; Tue, 20 May 2003 14:51:19 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 602F69126D; Tue, 20 May 2003 14:51:19 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 565129126C
	for <ietf-ppp@trapdoor.merit.edu>; Tue, 20 May 2003 14:51:18 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 3F12E5DF4C; Tue, 20 May 2003 14:51:18 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3])
	by segue.merit.edu (Postfix) with ESMTP id 59E025DF56
	for <ietf-ppp@merit.edu>; Tue, 20 May 2003 14:51:17 -0400 (EDT)
Received: (from vjs@localhost)
	by calcite.rhyolite.com (8.12.9/8.12.9) id h4KIpChD026625
	for ietf-ppp@merit.edu env-from <vjs>;
	Tue, 20 May 2003 12:51:12 -0600 (MDT)
Date: Tue, 20 May 2003 12:51:12 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
Message-Id: <200305201851.h4KIpChD026625@calcite.rhyolite.com>
To: ietf-ppp@merit.edu
Subject: Re: Extending IPCP  for Route Table Entries
References: <3ECA66D8.3070302@heeltoe.com>
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

> From: Brad Parker <brad@heeltoe.com>

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


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



> >   - what is the difference between the traffic for the two links?  Does
> >       it differ only by IP address?
>
> 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?



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


Vernon Schryver    vjs@rhyolite.com


From owner-ietf-ppp@merit.edu  Tue May 27 23:31:38 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17360
	for <pppext-archive@lists.ietf.org>; Tue, 27 May 2003 23:31:37 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id CA00F91227; Tue, 27 May 2003 23:31:13 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 346459122B; Tue, 27 May 2003 23:31:09 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id C3CD291227
	for <ietf-ppp@trapdoor.merit.edu>; Tue, 27 May 2003 23:31:02 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 8462A5DF4C; Tue, 27 May 2003 23:31:02 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from calcite.rhyolite.com (calcite.rhyolite.com [192.188.61.3])
	by segue.merit.edu (Postfix) with ESMTP id 93D6C5DF4B
	for <ietf-ppp@merit.edu>; Tue, 27 May 2003 23:31:01 -0400 (EDT)
Received: (from vjs@localhost)
	by calcite.rhyolite.com (8.12.9/8.12.9) id h4S3UxO1011115
	for ietf-ppp@merit.edu env-from <vjs>;
	Tue, 27 May 2003 21:30:59 -0600 (MDT)
Date: Tue, 27 May 2003 21:30:59 -0600 (MDT)
From: Vernon Schryver <vjs@calcite.rhyolite.com>
Message-Id: <200305280330.h4S3UxO1011115@calcite.rhyolite.com>
To: ietf-ppp@merit.edu
Subject: IANA PPP considerations
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

What needs to be done to get the IANA considerations advanced?

I've heard no comments about draft-schryver-pppext-iana-00.txt
since it was published a week ago.  It's not listed 
on http://ietf.org/html.charters/pppext-charter.html

If I misunderstood and someone else should write it or it is a bad
thing best forgotten, that's fine with me.

If I understood correctly that there is a consensus for trying to
ensure that allocations of PPP numbers get reviewed, what needs to be
done next?  Is it something I can do?


Vernon Schryver    vjs@rhyolite.com


From owner-ietf-ppp@merit.edu  Wed May 28 07:32:37 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25098
	for <pppext-archive@lists.ietf.org>; Wed, 28 May 2003 07:32:37 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 65E7E9122E; Wed, 28 May 2003 07:32:23 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 3596291235; Wed, 28 May 2003 07:32:23 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 33BC69122E
	for <ietf-ppp@trapdoor.merit.edu>; Wed, 28 May 2003 07:32:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 0F3255E2CD; Wed, 28 May 2003 07:31:35 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14])
	by segue.merit.edu (Postfix) with ESMTP id 905295E2CB
	for <ietf-ppp@merit.edu>; Wed, 28 May 2003 07:31:34 -0400 (EDT)
Received: from eastmail1bur.East.Sun.COM ([129.148.9.49])
	by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h4SBVMLv017153;
	Wed, 28 May 2003 04:31:22 -0700 (PDT)
Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143])
	by eastmail1bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4SBVL7O016700;
	Wed, 28 May 2003 07:31:21 -0400 (EDT)
Received: from phorcys.East.Sun.COM (localhost [127.0.0.1])
	by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id h4SBVL6e054737;
	Wed, 28 May 2003 07:31:21 -0400 (EDT)
Received: (from carlsonj@localhost)
	by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9/Submit) id h4SBVL6O054734;
	Wed, 28 May 2003 07:31:21 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16084.40457.414124.898357@gargle.gargle.HOWL>
Date: Wed, 28 May 2003 07:31:21 -0400
From: James Carlson <james.d.carlson@east.sun.com>
To: Vernon Schryver <vjs@calcite.rhyolite.com>
Cc: ietf-ppp@merit.edu
Subject: Re: IANA PPP considerations
In-Reply-To: Vernon Schryver's message of 27 May 2003 21:30:59
References: <200305280330.h4S3UxO1011115@calcite.rhyolite.com>
X-Mailer: VM 7.01 under Emacs 21.3.2
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu
Content-Transfer-Encoding: 7bit

Vernon Schryver writes:
> If I misunderstood and someone else should write it or it is a bad
> thing best forgotten, that's fine with me.

I think it's a good thing, though perhaps the IPR statement could be
dropped as (I hope!) you haven't actually filed a patent on the IANA
statement.

> If I understood correctly that there is a consensus for trying to
> ensure that allocations of PPP numbers get reviewed, what needs to be
> done next?  Is it something I can do?

I believe that Karl Fox needs to send mail to the IAD (Thomas Narten
and Erik Nordmark) proposing that this be published as a Best Current
Practice.

-- 
James Carlson, Solaris Networking         <james.d.carlson@east.sun.com>
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 owner-ietf-ppp@merit.edu  Wed May 28 08:50:52 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29499
	for <pppext-archive@lists.ietf.org>; Wed, 28 May 2003 08:50:51 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 7D25291235; Wed, 28 May 2003 08:50:31 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 44B5691236; Wed, 28 May 2003 08:50:31 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 5108291235
	for <ietf-ppp@trapdoor.merit.edu>; Wed, 28 May 2003 08:50:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 314655E302; Wed, 28 May 2003 08:50:30 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from ohsmtp03.ogw.rr.com (ohsmtp03.ogw.rr.com [65.24.7.38])
	by segue.merit.edu (Postfix) with ESMTP id E56935E1B5
	for <ietf-ppp@merit.edu>; Wed, 28 May 2003 08:50:29 -0400 (EDT)
Received: from [10.0.0.3] (dhcp93126241.columbus.rr.com [24.93.126.241])
	by ohsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id h4SCoL6E028475;
	Wed, 28 May 2003 08:50:21 -0400 (EDT)
Subject: Re: IANA PPP considerations
From: Karl Fox <karlfox@columbus.rr.com>
To: James Carlson <james.d.carlson@east.sun.com>
Cc: Vernon Schryver <vjs@calcite.rhyolite.com>, ietf-ppp@merit.edu
In-Reply-To: <16084.40457.414124.898357@gargle.gargle.HOWL>
References: <200305280330.h4S3UxO1011115@calcite.rhyolite.com>
	 <16084.40457.414124.898357@gargle.gargle.HOWL>
Content-Type: text/plain
Message-Id: <1054126219.30937.1.camel@kff>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4- 
Date: 28 May 2003 08:50:20 -0400
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu
Content-Transfer-Encoding: 7bit

Should I do it now or should I wait for a change to the IPR statement? 
Is it really necessary in a document like this?

Karl

On Wed, 2003-05-28 at 07:31, James Carlson wrote:
> Vernon Schryver writes:
> > If I misunderstood and someone else should write it or it is a bad
> > thing best forgotten, that's fine with me.
> 
> I think it's a good thing, though perhaps the IPR statement could be
> dropped as (I hope!) you haven't actually filed a patent on the IANA
> statement.
> 
> > If I understood correctly that there is a consensus for trying to
> > ensure that allocations of PPP numbers get reviewed, what needs to be
> > done next?  Is it something I can do?
> 
> I believe that Karl Fox needs to send mail to the IAD (Thomas Narten
> and Erik Nordmark) proposing that this be published as a Best Current
> Practice.



From owner-ietf-ppp@merit.edu  Wed May 28 08:56:57 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00172
	for <pppext-archive@lists.ietf.org>; Wed, 28 May 2003 08:56:57 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 42BD091236; Wed, 28 May 2003 08:56:40 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 1682391237; Wed, 28 May 2003 08:56:40 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 20D6691236
	for <ietf-ppp@trapdoor.merit.edu>; Wed, 28 May 2003 08:56:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 0E2FC5DD95; Wed, 28 May 2003 08:56:39 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by segue.merit.edu (Postfix) with ESMTP id AA9EB5DD90
	for <ietf-ppp@merit.edu>; Wed, 28 May 2003 08:56:38 -0400 (EDT)
Received: from eastmail2bur.East.Sun.COM ([129.148.13.40])
	by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4SCuRep029538;
	Wed, 28 May 2003 06:56:27 -0600 (MDT)
Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143])
	by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4SCuREg019378;
	Wed, 28 May 2003 08:56:27 -0400 (EDT)
Received: from phorcys.East.Sun.COM (localhost [127.0.0.1])
	by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id h4SCuQ6e056791;
	Wed, 28 May 2003 08:56:27 -0400 (EDT)
Received: (from carlsonj@localhost)
	by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9/Submit) id h4SCuQtV056788;
	Wed, 28 May 2003 08:56:26 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16084.45562.814515.137200@gargle.gargle.HOWL>
Date: Wed, 28 May 2003 08:56:26 -0400
From: James Carlson <james.d.carlson@east.sun.com>
To: Karl Fox <karlfox@columbus.rr.com>
Cc: Vernon Schryver <vjs@calcite.rhyolite.com>, ietf-ppp@merit.edu
Subject: Re: IANA PPP considerations
In-Reply-To: Karl Fox's message of 28 May 2003 08:50:20
References: <200305280330.h4S3UxO1011115@calcite.rhyolite.com>
	<16084.40457.414124.898357@gargle.gargle.HOWL>
	<1054126219.30937.1.camel@kff>
X-Mailer: VM 7.01 under Emacs 21.3.2
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu
Content-Transfer-Encoding: 7bit

Karl Fox writes:
> Should I do it now or should I wait for a change to the IPR statement? 
> Is it really necessary in a document like this?

Since this bit of boilerplate is not really material to the wg's
interest in the document, and appears to be more of an editorial
matter that will almost certainly be handled by IESG review, I don't
see a particular need to wait before doing a last call and submission.
But I think it should be your call.

-- 
James Carlson, Solaris Networking         <james.d.carlson@east.sun.com>
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 owner-ietf-ppp@merit.edu  Wed May 28 09:05:19 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00872
	for <pppext-archive@lists.ietf.org>; Wed, 28 May 2003 09:05:19 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id AE05C91237; Wed, 28 May 2003 09:05:03 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 7193A91238; Wed, 28 May 2003 09:05:03 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 52D9E91237
	for <ietf-ppp@trapdoor.merit.edu>; Wed, 28 May 2003 09:05:02 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 0FE505DDA2; Wed, 28 May 2003 09:05:02 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from ohsmtp03.ogw.rr.com (ohsmtp03.ogw.rr.com [65.24.7.38])
	by segue.merit.edu (Postfix) with ESMTP id 8DF435DDA3
	for <ietf-ppp@merit.edu>; Wed, 28 May 2003 09:05:01 -0400 (EDT)
Received: from [10.0.0.3] (dhcp93126241.columbus.rr.com [24.93.126.241])
	by ohsmtp03.ogw.rr.com (8.12.5/8.12.2) with ESMTP id h4SD506E009928;
	Wed, 28 May 2003 09:05:00 -0400 (EDT)
Subject: IANA Considerations for PPP to Proposed Standard
From: Karl Fox <karlfox@columbus.rr.com>
To: Thomas Narten <narten@us.ibm.com>, Erik Nordmark <Erik.Nordmark@sun.com>
Cc: ietf-ppp@merit.edu, iesg-secretary@ietf.org
Content-Type: text/plain
Message-Id: <1054127099.30903.5.camel@kff>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4- 
Date: 28 May 2003 09:04:59 -0400
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu
Content-Transfer-Encoding: 7bit

Thomas and Erik,

The PPPEXT Working Group recommends that IANA Considerations for PPP,
draft-schryver-pppext-iana-00.txt, be advanced to Proposed Standard.

Thanks,

Karl



From owner-ietf-ppp@merit.edu  Wed May 28 20:36:41 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA01201
	for <pppext-archive@lists.ietf.org>; Wed, 28 May 2003 20:36:41 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 3C07891245; Wed, 28 May 2003 20:36:25 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 0DC1191246; Wed, 28 May 2003 20:36:24 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 1808791245
	for <ietf-ppp@trapdoor.merit.edu>; Wed, 28 May 2003 20:36:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id F2B7B5E001; Wed, 28 May 2003 20:36:23 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from ohsmtp02.ogw.rr.com (ohsmtp02.ogw.rr.com [65.24.7.37])
	by segue.merit.edu (Postfix) with ESMTP id 82DFD5DFA8
	for <ietf-ppp@merit.edu>; Wed, 28 May 2003 20:36:23 -0400 (EDT)
Received: from [10.0.0.3] (dhcp93126241.columbus.rr.com [24.93.126.241])
	by ohsmtp02.ogw.rr.com (8.12.5/8.12.2) with ESMTP id h4T0aIYU018718;
	Wed, 28 May 2003 20:36:22 -0400 (EDT)
Subject: Re: draft-song-pppext-sip-support-02.txt
From: Karl Fox <karlfox@columbus.rr.com>
To: Thomas Narten <narten@us.ibm.com>
Cc: ietf-ppp@merit.edu
In-Reply-To: <200305141832.h4EIWMU05388@cichlid.adsl.duke.edu>
References: <200305141832.h4EIWMU05388@cichlid.adsl.duke.edu>
Content-Type: text/plain
Message-Id: <1054168576.30937.42.camel@kff>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.4- 
Date: 28 May 2003 20:36:16 -0400
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu
Content-Transfer-Encoding: 7bit

I think the consensus is clear: Existing mechanisms are adequate to the
task.

Karl

On Wed, 2003-05-14 at 14:32, Thomas Narten wrote:
> Speaking of which, the RFC editor has received a request to publish
> the above document as an informational RFC.
> 
> What does this WG think of this request? Should the RFC editor publish
> this document? Or would doing so be an end-run around this WG?
> 
> Thomas



From owner-ietf-ppp@merit.edu  Thu May 29 08:07:46 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29709
	for <pppext-archive@lists.ietf.org>; Thu, 29 May 2003 08:07:45 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 6024091250; Thu, 29 May 2003 08:07:20 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 2DC7691253; Thu, 29 May 2003 08:07:20 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 19AB691250
	for <ietf-ppp@trapdoor.merit.edu>; Thu, 29 May 2003 08:07:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id E7AE55E2C9; Thu, 29 May 2003 08:07:19 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from mta03bw.bigpond.com (mta03bw.bigpond.com [139.134.6.86])
	by segue.merit.edu (Postfix) with ESMTP id B7CF85E2C4
	for <ietf-ppp@merit.edu>; Thu, 29 May 2003 08:07:17 -0400 (EDT)
Received: from oemcomputer ([144.135.24.87]) by
          mta03bw.bigpond.com (Netscape Messaging Server 4.15 mta03bw Jul
          16 2002 22:47:55) with SMTP id HFNDO100.CQA for
          <ietf-ppp@merit.edu>; Thu, 29 May 2003 22:07:13 +1000 
Received: from 144.139.99.87 ([144.139.99.87]) by bwmam07.bigpond.com(MailRouter V3.2g 56/5688759); 29 May 2003 22:07:04
Message-ID: <006201c325db$848b67e0$7a638b90@oemcomputer>
From: "Glardy" <glardy@bigpond.com>
To: "PPP Mailing List" <ietf-ppp@merit.edu>
Subject: Configuration of remote routers (IPCP vs DHCP)
Date: Thu, 29 May 2003 22:11:03 +1000
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_005F_01C3262F.31C63EA0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

This is a multi-part message in MIME format.

------=_NextPart_000_005F_01C3262F.31C63EA0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The recent discussions about using IPCP to pass static routes to a PPP =
peer, negotiate a netmask etc, suggest that a lot of people are trying =
to work out how to address the problem of configuring remote routers =
over a PPP connection (dial-up or xDSL mostly I would guess).

Summary:  Check out RFC 3442 and draft-ietf-dhc-subnet-alloc-00.txt for =
how to do this with DHCP.

Long version:

The context where I have faced this problem is where I have a large =
number of small remote sites connecting up to my central access server =
using PPP.  Each remote site generally has a router with a small network =
behind it, and I want my central server to be able to send the router a =
subnet to use in addition to the IP address it got for the PPP link.  It =
could then give itself an address out of that subnet and set itself up =
as a DHCP server (or possibly a relay) to allow other hosts on the =
remote network to get an IP address, netmask and default gateway.  In =
more complex scenarios there may be multiple subnets involved and =
perhaps a couple of static routes required as well.

Many small routers have a DHCP server and/or relay agent built-in =
already, and RADIUS gives me the ability to send the necessary =
addressing and routing information to the access server.  What is =
lacking is a protocol to transport that information from the server to =
the remote router for it to set up its DHCP server.

Given the general consensus on the list that DHCP is a better protocol =
than IPCP for this function, I have had a quick look at the dhc working =
group's list of work completed and in progress.

The problem I have just outlined appears to have been solved there.  The =
option to pass classless static routes in DHCP is in RFC 3442 (Standards =
track) and the option to allocate multiple subnets to a host is =
currently a dhc working group draft =
(draft-ietf-dhc-subnet-alloc-00.txt).

Looks like I will have to implement DHCP on my access server.  I don't =
suppose anyone knows of an ISDN/ADSL router that implements a DHCP =
client for remote configuration?

Cheers,

Greg Lampard



------=_NextPart_000_005F_01C3262F.31C63EA0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>The recent discussions about using IPCP =
to pass=20
static routes to a PPP peer, negotiate a netmask etc,&nbsp;suggest that =
a lot of=20
people are trying to work out how to address the problem of configuring =
remote=20
routers over a PPP connection (dial-up or xDSL mostly I would=20
guess).</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Summary:&nbsp; Check out RFC 3442 and=20
draft-ietf-dhc-subnet-alloc-00.txt for how to do this with =
DHCP.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Long version:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The&nbsp;context where I have faced =
this problem is=20
where I have a large number of small remote sites connecting up to my =
central=20
access server using PPP.&nbsp; Each remote site generally has a router =
with a=20
small network behind it, and I want my central server to be able to send =
the=20
router a subnet to use in addition to the IP address it got for the PPP=20
link.&nbsp; It could then give itself an address out of that subnet and =
set=20
itself up as a DHCP server (or possibly a relay) to allow other hosts on =
the=20
remote network to get an IP address, netmask and default gateway.&nbsp; =
In more=20
complex scenarios there may be multiple subnets involved and perhaps a =
couple of=20
static routes required as well.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Many small routers have&nbsp;a DHCP =
server and/or=20
relay agent built-in already, and RADIUS gives me the ability to send =
the=20
necessary addressing and routing information to the access server.&nbsp; =
What is=20
lacking is a protocol to transport that information from the server to =
the=20
remote router for it to set up its DHCP server.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Given the general consensus on the list =
that DHCP=20
is a better protocol than IPCP for this function, I have had a quick =
look at the=20
dhc working group's list of work completed and in progress.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>The problem I have just outlined =
appears to have=20
been solved there.&nbsp; The option to pass classless static routes in =
DHCP is=20
in RFC 3442 (Standards track) and the option to allocate multiple =
subnets to a=20
host is currently a dhc working group draft=20
(draft-ietf-dhc-subnet-alloc-00.txt).</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Looks like I will have to implement =
DHCP on my=20
access server.&nbsp; I don't suppose anyone knows of an ISDN/ADSL router =
that=20
implements a DHCP client for remote configuration?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Cheers,</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Greg Lampard</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_005F_01C3262F.31C63EA0--



From owner-ietf-ppp@merit.edu  Thu May 29 09:04:51 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01922
	for <pppext-archive@lists.ietf.org>; Thu, 29 May 2003 09:04:51 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id 4010391253; Thu, 29 May 2003 09:04:36 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id 0DB2A91255; Thu, 29 May 2003 09:04:35 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id 2E54091253
	for <ietf-ppp@trapdoor.merit.edu>; Thu, 29 May 2003 09:04:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 0135B5E2C8; Thu, 29 May 2003 09:04:35 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from internaut.com (unknown [64.38.134.99])
	by segue.merit.edu (Postfix) with ESMTP id E8F605E243
	for <ietf-ppp@merit.edu>; Thu, 29 May 2003 09:04:33 -0400 (EDT)
Received: from localhost (aboba@localhost)
	by internaut.com (8.10.2/8.10.2) with ESMTP id h4TCfiq22635;
	Thu, 29 May 2003 05:41:45 -0700
Date: Thu, 29 May 2003 05:41:44 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: Glardy <glardy@bigpond.com>
Cc: PPP Mailing List <ietf-ppp@merit.edu>
Subject: Re: Configuration of remote routers (IPCP vs DHCP)
In-Reply-To: <006201c325db$848b67e0$7a638b90@oemcomputer>
Message-ID: <Pine.LNX.4.53.0305290539100.22265@internaut.com>
References: <006201c325db$848b67e0$7a638b90@oemcomputer>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu

> Many small routers have a DHCP server and/or relay agent built-in already, and RADIUS
>gives me the ability to send the necessary addressing and routing
>information to the access server.  What is lacking is a protocol to
>transport that information from the server to the remote router for it to
>set up its DHCP server.

RADIUS has Framed-Route and Framed-Routing. You can use these to setup a
routing protocol such as RIP, to operate between your Access Server and the clients.

> Given the general consensus on the list that DHCP is a better protocol than IPCP for this

I don't think that the concensus was that either was a subsitute for a routing protocol.



From owner-ietf-ppp@merit.edu  Thu May 29 10:05:55 2003
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04172
	for <pppext-archive@lists.ietf.org>; Thu, 29 May 2003 10:05:48 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix)
	id CEDEE91255; Thu, 29 May 2003 10:05:26 -0400 (EDT)
Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56)
	id A4A1191256; Thu, 29 May 2003 10:05:26 -0400 (EDT)
Delivered-To: ietf-ppp@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by trapdoor.merit.edu (Postfix) with ESMTP id B101391255
	for <ietf-ppp@trapdoor.merit.edu>; Thu, 29 May 2003 10:05:25 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 948675DD9A; Thu, 29 May 2003 10:05:25 -0400 (EDT)
Delivered-To: ietf-ppp@merit.edu
Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34])
	by segue.merit.edu (Postfix) with ESMTP id 0D7D15DDB2
	for <ietf-ppp@merit.edu>; Thu, 29 May 2003 10:05:25 -0400 (EDT)
Received: from eastmail2bur.East.Sun.COM ([129.148.13.40])
	by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h4TE55ep013847;
	Thu, 29 May 2003 08:05:06 -0600 (MDT)
Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143])
	by eastmail2bur.East.Sun.COM (8.12.9+Sun/8.12.9/ENSMAIL,v2.2) with ESMTP id h4TE55Eg004418;
	Thu, 29 May 2003 10:05:05 -0400 (EDT)
Received: from phorcys.East.Sun.COM (localhost [127.0.0.1])
	by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9) with ESMTP id h4TE556e061035;
	Thu, 29 May 2003 10:05:05 -0400 (EDT)
Received: (from carlsonj@localhost)
	by phorcys.East.Sun.COM (8.12.9+Sun/8.12.9/Submit) id h4TE55IO061032;
	Thu, 29 May 2003 10:05:05 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16086.5008.998630.432757@gargle.gargle.HOWL>
Date: Thu, 29 May 2003 10:05:04 -0400
From: James Carlson <james.d.carlson@east.sun.com>
To: Bernard Aboba <aboba@internaut.com>
Cc: Glardy <glardy@bigpond.com>, PPP Mailing List <ietf-ppp@merit.edu>
Subject: Re: Configuration of remote routers (IPCP vs DHCP)
In-Reply-To: Bernard Aboba's message of 29 May 2003 05:41:44
References: <006201c325db$848b67e0$7a638b90@oemcomputer>
	<Pine.LNX.4.53.0305290539100.22265@internaut.com>
X-Mailer: VM 7.01 under Emacs 21.3.2
Sender: owner-ietf-ppp@merit.edu
Precedence: bulk
Errors-To: owner-ietf-ppp-outgoing@merit.edu
Content-Transfer-Encoding: 7bit

Bernard Aboba writes:
> > Given the general consensus on the list that DHCP is a better protocol than IPCP for this
> 
> I don't think that the concensus was that either was a subsitute for a routing protocol.

It all depends on what you're trying to accomplish.

If you're delegating address assignment authority for a subnet from
one DHCP server to another, then a DHCP-specific mechanism sounds like
the best way to go about doing this.

If you're just configuring an Ethernet interface that happens to be
attached to some CPE box with a PPP link on the other side, then
BOOTP, DHCP, or just DHCPINFORM would probably be about right.

If all that you're doing is ferrying routes around (and not
specifically configuring an interface), then ICMP Router Discovery or
RIP-2 are good choices.

In any event, the one thing that does *NOT* make sense is to pass a
subnet mask along via IPCP and have that mask be somehow applied to
either a remote DHCP server, some interface unrelated to the PPP link
itself, or to a forwarding table.

-- 
James Carlson, Solaris Networking         <james.d.carlson@east.sun.com>
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