Subject: MARS proxy for PPP/ATM

From: "David Allan" <[email-masked]>
Date: Mon, 20 Apr 1998 09:26:15 -0400

The following was presented at the PPPEXT session in LosAngeles. I'd
appreciate feedback posted on the list. The draft is also available from the
IETF web site:
http://www.ietf.cnri.reston.va.us/internet-drafts/draft-allan-ion-mars-proxy
-00.txt

The "ion" in the title is a historical anacronism ;-)

Cheers
Dave
-----------------------------------------------

Network Working Group                                David Allan, Nortel
INTERNET DRAFT                                          March 13th, 1998
Expires September 13th, 1998 

                                   MARS Proxy

                      <draft-allan-ion-mars-proxy-00.txt>

Status Of This Memo

This document is an Internet-Draft.  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.''

To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

Distribution of this memo is unlimited.

Abstract:

The Point-to-Point Protocol (PPP) [1] has been proposed as an access 
vehicle for public ATM networks. Support for multicast in this 
environment via either RAS replication, or a adding MARS client side by
side with PPP is problematic on several fronts.

This document describes how an ATM attached system can act as a MARS 
proxy on behalf of a PPP client. This solution circumvents many of the 
associated problems with respect to VC frugality, scalability, and 
authentication.

Applicability:

This specification is intended for those implementations which desire to 
implement a MARS proxy on behalf of any client base. The original 
motivation for this work was to augment the capability presented to PPP 
over ATM clients, however the work has been sufficiently generalized to 
be extensible to other applications.

Allan                    Expires Sept 13th 1998                 [Page 1]

Internet Draft                MARS Proxy               January 22nd,1998

This document should be read as an extension of RFC 2022 and assumes 
familiarity with RFCs 1112, 2022 and 2236. The focus of this document in 
describing the MARS proxy is IPv4/IGMP but it is expected that this work 
could be easily generalized to other protocols. 

Table of Contents

1. Conventions 								3
2. Terminology								3
3. Introduction								3
4. MARS proxy behavior							4
   4.1  Transmit Side behavior						5
   4.2  Receive Side behavior						5
      4.2.1  Joining a multicast group					5
      4.2.2  Leaving a Multicast group					6
   4.3 Encapsulation							6
5.  Proxy client behavior						7
   5.1 Modifications to RFC1112 and RFC2236				7
   5.2 Reflected packet detection					7
6. MARS Behavior							7
7. Security Provisions							7
   7.1  Restriction of Multicast operation to MCS			7
   7.2  MARS proxy to MARS/MCS connectivity				8
   7.3  Proxy client screening of incoming p2mp VCs			9
8. Fate sharing								10
9.  Specific PPP over ATM considerations				10
   9.1  PPP over ATM, MARS and L2TP					10
   9.2  Backwards compatibility with 
		initial PPP over ATM implementations			11
   9.3 MARS cluster LIS Restriction					11
9.4  Multiple 'layer 3 over ATM interfaces'				12
9.5  Collapsed Architecture						12
10. Security Considerations						12
11. Acknowledgments							12
12. References								12
13. Authors Address							13

Allan                    Expires Sept 13th 1998                 [Page 2]

Internet Draft                MARS Proxy               January 22nd,1998

1.  Conventions

In this document, several words are used to signify the requirements of
the specification.  These words are often capitalized.

     MUST - This word, or the adjective "required", means that the
     definition is an absolute requirement of the specification.

     MUST NOT - This phrase means that the definition is an absolute
     prohibition of the specification.

     SHOULD - This word, or the adjective "recommended", means that
     there may exist valid reasons in particular circumstances to ignore
     this item, but the full implications MUST be understood and
     carefully weighed before choosing a different course.

     MAY - This word, or the adjective "optional", means that this item     
     is one of an allowed set of alternatives.  An implementation which
     does not include this option MUST be prepared to interoperate with
     another implementation which does include the option.

2.  Terminology

MARS proxy: A MARS client that functions on behalf of one or more ATM 
endpoints. A potential example would be a broadband RAS.

Proxy client: An ATM endpoint serviced by a MARS proxy.

3. Introduction

The PPP model traditionally assumes that a session between "peers" 
consists of a single logical connection (which may consist of multiple 
physical connections inverse multiplexed). The definition of PPP over 
ATM [2] (work in progress) and PPP over Frame Relay [3] currently adhere 
to this convention. 

This convention also requires that for IP multicast, the Remote Access 
Server (RAS) function as a multicast router and perform replication of 
multicast traffic to each PPP attached "destination". This has 
undesirable scaling properties w.r.t. the consumption of bandwidth in 
the ATM subnet. This is exacerbated once multiple RAS's are required to 
service the ATM subnet; more bandwidth is required in the network behind 
the RASs.

However it is only by convention that all IP traffic between PPP "peers" 
be carried within the PPP session/connection. In the ATM access 
environment where PPP over ATM has been proposed, one peer will 
typically be an ISP client, the other an ISP, and the ATM subnet will be 

Allan                    Expires Sept 13th 1998                 [Page 3]

Internet Draft                MARS Proxy               January 22nd,1998

a public network. If the ISP wished to offer IP based multicast 
services, it would be desirable for the ISP if only a single multicast 
source (e.g. MCS) was required to service the ATM subnet, and that the 
ISP could limit users of the MCS to authenticated clients.  

The MARS/MCS model [4] has the desirable attribute that all destinations 
for an IP multicast group in the NMBA subnet can be serviced by a single 
p2mp tree. 

However the MARS/MCS model brings significant overhead:

* the client host needs to be configured with knowledge of the MARS.   
  Techniques such as ILMI based server discovery are inappropriate. The  
  management of the network cannot have advance knowledge of the PPP 
  peer.
* the client needs a p2p VC and is a leaf on the p2mp cluster control VC 
  to participate in the multicast control structure.
* the client requires a p2p VC to each MCS to source traffic and is a 
  leaf on a p2mp VC to receive traffic typically for each multicast 
  group.

and numerous unsolved issues with respect to authentication of the 
client (which also renders p2mp VC meshing as per [4] sect. 3.1 
inappropriate for this particular application).

Much of this configuration and connectivity burden on the client could 
be alleviated, and the authentication issues addressed if the RAS 
proxied connectivity to the MARS and MCS on behalf of the PPP client and 
the set of multicast "destinations" in the ATM subnet could be serviced 
by p2mp tree(s) rooted in the ISP network.

The motivation for this document assumes use of MCSs but the work has 
been generalized to encompass p2mp meshing as well.

4.  MARS proxy behavior

The MARS proxy mimics a multicast router ([5] Appendix I) to its set of 
proxy clients and interworks IGMP (version 1 or version 2) with MARS.

The MARS proxy must be able to detect and manage multicast activity for
a group via two mechanisms. Either the proxy client issues an IGMP
report indicating that it has joined a group and wishes to receive 
traffic from that group (as a 'destination'), or it has directed a 
packet to that groups class 'D' address (as a 'source'). This is 
typically termed 'receive side' and 'transmit side' respectively. 
A client indicating 'destination' status for a group must have that status 
periodically re-confirmed via IGMP query messages. The MARS proxy MUST 
maintain group membership state for each of its proxy clients.

This specification provides for both permanent and transient paths to 

Allan                    Expires Sept 13th 1998                 [Page 4]

Internet Draft                MARS Proxy               January 22nd,1998

both the MARS and the multicast group. 

4.1 Transmit side behavior 

Transmit side behavior is as per [4] sect 5.1. with the following
proviso:

The MARS proxy MAY not have ATM connectivity to multicast destinations 
on the ATM subnet (hosts or MCS) for technical or policy reasons. The 
MARS proxy may be located at the edge of an ATM subnet and have a 
forwarding path for multicast traffic outside the ATM subnet.  Should 
the MARS have no mapping for the desired class 'D' address, or be 
configured specifically to provide a MARS_NAK response, the MARS proxy 
SHOULD have the option  to forward the packet outside the ATM subnet OR 
to silently discard the packet.  A MARS proxy implementation may choose 
to use MARS_REQUEST to dynamically determine availability or may choose 
to do so via the MARS_GROUPLIST_REQUEST facility.

Although there is an expectation that a multicast router will be a MARS 
client (possibly integrated), the network operator may wish to limit 
what multicast groups are supported by MARS/MCS (not fully promiscuous) 
for reasons of tariffs, service differentiation or other, or may wish to 
restrict direct ATM connectivity from the MARS proxies to an MCS.  Non-
ATM MCS connectivity (back end via any attached multicast router) can be 
done transparently without fear of routing loops or reflection problems. 
This will introduce additional latency when compared with a direct ATM 
path and requires some administrivia in that filtering of group lists is 
required for responses to MARS_REQUESTs. Hosts blocked from direct MCS 
connectivity would receive MARS_NAKS as a response to MARS_REQUESTs. 

4.2 Receive side behavior

The receiver side behavior of the MARS proxy is as per [4] section 5.2 
but with the difference that:
- the MARS proxy is a cluster member in that it participates in the 
  cluster control structure.
- the MARS proxy is not a group member in that it is not a 'source' nor 
  'destination' of multicast traffic for any multicast group. 
It does forward multicast traffic 'sourced' by its set of proxy clients 
to the set of 'destinations' specified by MARS interaction. 

An associated difference is that when p2mp meshing is used and a p2mp VC 
is rooted at the proxy, the set of end points may include proxy clients 
served by the MARS proxy. 

4.2.1 Joining a multicast group

Allan                    Expires Sept 13th 1998                 [Page 5]

Internet Draft                MARS Proxy               January 22nd,1998

Unlike a normal MARS client, issuing a MARS_JOIN on behalf of a proxy 
client may involve modifications to the set of destinations served by a 
locally rooted p2mp VC (addition of the proxy). When the MARS proxy 
receives an IGMP_Report from a proxy client it performs the following 
actions:

i) Ensures that it is registered with a MARS.

ii)  Issues a MARS_JOIN to the currently attached MARS for the requested 
group. The MARS_JOIN request conforms to [4] sect 5.2.1 with the 
exception that:
- the mar$sha value is set to the ATM address of the proxy client 
  rather than that of the MARS proxy
- the mar$spa value is to the layer 3 address of the proxy client 
  rather than the MARS proxy.

iii)  Upon receipt of MARS_JOIN confirmation, check if there is a pre-
existing p2mp VC associated with the group rooted at the MARS proxy. If 
so, the MARS proxy MUST determine if local ATM connectivity be modified 
to support the addition of the proxy client.

   It issues a MARS_REQUEST to determine group membership. The 
   MARS_MULTI responses are audited against the pre-existing p2mp VC and 
   it is appropriately modified. If there is no pre-existing VC then the   
   MARS proxy initiates one as per [4] sect 5.1.3.

   The MARS_REQUEST step MAY be dispensed with by observing which path 
   the MARS_JOIN confirmation arrives on. If it arrives on the cluster 
   control VC, then p2mp meshing is employed and adding the proxy client 
   is required. If it arrives on the MARS unicast VC (curiously un-named 
   in RFC 2022), then an MCS is employed and no ATM connectivity changes 
   are needed. This is not as authoritative as re-validating the set of 
   'destinations' but does reduce the amount of traffic and may be an 
   optimization in some circumstances. Some hybrid of the two approaches 
   may be employed to combine robustness with frugality.

4.2.2 Leaving a multicast group

When a MARS proxy has issued an IGMP_QUERY to a proxy client and the 
absence of response indicates that a proxy client has left a multicast 
group or an explicit IGMPv2_LEAVE is received, the MARS proxy will issue 
a MARS_LEAVE for the specified proxy client/specified group.

4.3  Encapsulation

Multicast sources MUST use type #2 encapsulation as defined in [4] sect 
5.5.2. When the MARS proxy is forwarding traffic sourced by its proxy 
client base, the MARS proxy will insert the address of the proxy client 

Allan                    Expires Sept 13th 1998                 [Page 6]

Internet Draft                MARS Proxy               January 22nd,1998

as the source ID. For IPv4, this will occupy the first four octets of 
the 8 octets allocated. The remaining octets should be zeroed.

5.0  proxy client behavior

5.1 Extensions to RFC1112 and RFC2236

The proxy client behavior corresponds to either RFC1112 [5] or RFC 2236 
[9] with modifications such that multicast traffic MAY be received over 
transient p2mp paths. Further elaboration on criteria for accepting 
incoming p2mp calls and mapping calls to the correct 'layer 3 over ATM' 
interface is discussed in section 7.3.

5.2  Reflected packet detection

Use of a MARS proxy means that the reflected packet problem exists 
regardless of the multicast topology used (p2mp mesh OR MCS). Use of the 
CMI (type #1) as a filtering mechanism is inadequate as the CMI has 
insufficient granularity for a proxy community. Each proxy client is 
required to examine the type #2 encap. source ID field in each packet 
received and silently discard all packets originating with itself.

6. MARS behavior

The MARS MUST track group memberships by cluster member ID (cmi) to 
correctly associate the MARS proxy (i.d.'d by the cmi) with the proxy 
client base. This permits the MARS to correctly perform resource 
recovery when there is a loss of connectivity between the MARS and the 
proxy client. So [4] Appendix 'F' sect 1.2 handling of an ERR_L_RELEASE 
would read: Remove all ATM endpoints associated with the cmi associated 
with the ERR_L_RELEASE from all groups.

7. Security provisions

The following discussion focuses on then problem of securing the ATM 
end-points on a public network and suggests several strategies for 
minimizing the number of points that need be secured against 
unauthorized calls. In general the strategy is to minimize the number of 
points that are required to accept incoming calls.

7.1 Restriction of Multicast operation to MCS

Although the function of a MARS proxy is not limited to operation with 
an MCS, implementations SHOULD permit administrative limitation of 
operation to supporting MCS multicast only (as opposed to p2mp meshed). 

Allan                    Expires Sept 13th 1998                 [Page 7]

Internet Draft                MARS Proxy               January 22nd,1998

The mechanisms to do so are outside the scope of this document. (see 
also sect. 4.1)

7.2 MARS proxy to MARS/MCS connectivity

One issue w.r.t. MARS and MCS is that in a public network, it is useful 
to secure these ATM end-points from unauthorized access. The entire set 
of mechanisms for accomplishing this is outside the scope of this document. 

There are a number of connections to be secured. A MARS proxy is 
connected to the MARS via the p2p bi-directional control VC and is a 
leaf on the p2mp cluster control VC. An MCS is connected to the MARS via 
a p2p control VC and is a leaf on the p2mp server control VC. The MARS 
proxy will be connected to MCSs of interest via a p2p VC. 

RFC 2022 [4] sect. 5 suggests that these are transient connections with 
a recommended time out. However in an environment where a relatively 
small number of MARS proxies serves a large number of proxy clients for 
a small number of multicast groups, a provisioned infrastructure is not 
an unreasonable solution. This specification recommends that the option 
of PVC connectivity to the MARS be included for the following reasons:

* authentication of the proxy would be based on physical connectivity 

* the community of MARS clients would be relatively small, so scaling   
  the number of p2p and p2mp VCs is not an issue.

* the number of hosts serviced by a MARS proxy would be relatively large

* when combined with provisioned connectivity to an MCS/MCSs, all 
  transient connections are initiated by the MCS only (L_MULTI_RQ or 
  L_MULTI_ADD). The MARS and MCS are not required to accept incoming 
  calls. 

PVC connectivity does not imply proxy to MARS connectivity. It is 
possible for either to lose state. Therefore PVC connectivity comes with 
the following provisos:

1)  The MARS proxy MUST register by issuing a MARS-JOIN after any start 
up. 

2)  Upon receipt of a MARS-JOIN, the MARS will assume that it was 
preceded by a loss of connectivity to the MARS proxy. The MARS will use 
the cluster member identifier associated with the previous session  with 
the MARS proxy to identify any pre-existing group memberships and tear 
them down.
 
3)  Upon receipt of a MARS-JOIN, the MARS will assume Cluster Control VC 
 
Allan                    Expires Sept 13th 1998                 [Page 8]

Internet Draft                MARS Proxy               January 22nd,1998

   connectivity to the MARS client has been pre-established.

Similarly for MARS to MCS connectivity

1)  The MCS will register by issuing a MARS_MSERV after any startup.
 
2)  The MCS will issue a MARS_REQUEST to re-discover supported group 
membership and re-establish the p2mp tree.

Note that the intent is not to preclude SVC connectivity to the 
MARS/MCS, only to provide a solution that includes authentication of the 
client without either "yet-to-be-invented" access control protocols or 
access lists.

7.3 Proxy client screening of incoming p2mp VCs

A proxy client is obliged to accept incoming p2mp calls without an 
authoritative authentication mechanism. The definition of this is 
outside the scope of this document. 

Further, the proxy client is typically not able to determine which IP 
network the p2mp call(s) originates from in the scenarios where multiple 
layer 3 over ATM interfaces is being supported. Once a proxy client is a 
member of a multicast group, it must be prepared to accept an arbitrary 
number of incoming p2mp calls at arbitrary times during the duration of 
group membership. Multiple layer 3 interfaces over ATM merely compounds 
the problem.

The chief security vulnerability would be an insertion attack in which a 
malicious entity masquerades as a p2mp VC to obtain unauthorized access 
to the proxy client. This assumes some knowledge of the proxy client, 
and assumes that a separate VC offers opportunities to exploit security 
vulnerabilities that are not available by other means. 

To provide a first tier authentication of incoming calls against 
insertion attacks and to successfully map incoming p2mp calls to the
 correct layer 3 interface, the root add leaf signalling SHOULD also echo 
back the layer 3 address of the leaf. P2mp roots (either MARS proxies, 
hosts or MCSs) compliant with this approach would echo the lower 6 bytes 
of the mar$spa field in the UNI 3.0/3.1 BHLI field. Where the source 
protocol address length is less than 6 (as indicated in the mar$spln 
field), the most significant octets of the BHLI field will be zeroed. 
Incoming calls with an incorrect BHLI are rejected with a cause of 21 
"call rejected" ([8] sect. 5.4.5.15).

It is useful to limit the scope of what a malicious insertion attack can 
accomplish to significantly less than that of the coexisting layer 3 
connectivity. This can be performed by several means:

Allan                    Expires Sept 13th 1998                 [Page 9]

Internet Draft                MARS Proxy               January 22nd,1998

i)  Timing:

A proxy client MUST not accept any incoming p2mp calls on a layer 3 over 
ATM interface while not currently a member of a multicast group. Good 
security practice suggest that clients SHOULD record information on 
unexpected incoming call requests.

ii) Limiting destination addressability:

Packets arriving on a p2mp VC associated with multicast should be 
filtered according to the destination multicast address. Rejected 
packets MUST be silently discarded. Good security practice suggests that 
clients SHOULD record information on discarded packets.

iii)  Correctly limiting VC capability

A p2mp VC is unidirectional, therefore no traffic should be able to be 
forwarded onto that VC by the proxy client. This MUST be reflected in 
calling traffic descriptors. Calls in which the backward cell rates are 
not set to zero MUST be rejected.

8. Fate sharing 

It is important for network resource management and recovery that 
multicast group membership by a proxy client be tightly coupled to 
connectivity between the proxy client and the MARS proxy. 

One example of this would be the existence of a PPP session between the 
proxy client and the MARS proxy (specifically an active NCP). 

Should, by whatever means, the MARS proxy detect loss of connectivity to 
a proxy client it will issue MARS_LEAVEs for all groups associated with 
the proxy client. Loss of connectivity between the MARS and MARS proxy 
is discussed in sect. 4.4.

9.  Specific PPP over ATM considerations

9.1 PPP over ATM, MARS and L2TP

One scenario of interest is when there is service interworking in the 
network core and multiple PPP sessions are aggregated into an L2TP [7] 
(work in progress) tunnel. The assumption is that ATM exit point was an 
L2TP Access Concentrator (LAC).  The following provisos apply:

1)  MARS control messages are not routable therefore some direct 
connectivity is required between a MARS proxy and MARS for control 
traffic. 
 
2)  Where an MCS is employed, direct connectivity between the MARS proxy 

Allan                    Expires Sept 13th 1998                [Page 10]

Internet Draft                MARS Proxy               January 22nd,1998

   and the MCS is not required. As discussed in sect 4.1, a MARS proxy 
   may forward multicast traffic to the MCS via a non-NBMA path.

3)  The MARS proxy requires knowledge of the ATM end-point address of 
the proxy client. The dialing number in an Incoming Call Request (ICRQ, 
[7] sect 6.9) would be a suitable mechanism. 

A PVC architecture between the PPP client and the L2TP LAC could be 
supported but is outside the scope of this document.

9.2 Backwards compatibility with initial PPP over ATM implementations

A desirable goal would be that multicast worked with any combination of 
proxy client vintage and MARS proxy vintage. 

There are three scenarios possible:

1)  The RAS does not support MARS proxy. The proxy client is a don't 
care. In this scenario, all multicast traffic will traverse the unicast 
PPP path. This will be effectively transparent to the end-system.

2)  The RAS supports MARS proxy and the proxy client supports MARS proxy 
p2mp call back.
 
3)  The RAS supports MARS proxy and the proxy client does not support 
p2mp call back. There are two sub-cases: 
 
i)  The PPP client cannot handle a p2mp callback. In this scenario, the 
L_MULTI_ADD will fail with a reason code other than those which suggest 
retry ([4] sect 5.1.3) and MARS clients/MCSs will silently drop the 
client from group membership. It is assumed such clients pre-date this 
specification therefore their behavior cannot be retroactively defined.

The proxy client nor the MARS proxy can recover as there is no knowledge 
of failure. This is an insoluble problem unless the MARS proxy can 
obtain knowledge of the connectivity failure (true for p2mp mesh, false 
for MCS).  
 
ii)  The PPP client accepts p2mp callback but cannot process multicast 
encapsulated packets. The user is effectively blocked from receiving 
packets from the multicast group supported by the p2mp VC.

9.3 MARS cluster LIS Restriction
 
A MARS cluster is currently defined as serving a single LIS. The 
restriction is intended to minimize the problems of interaction of 
multicast routing protocols and subnet boundaries (pending further 
research). In, for example the PPP over ATM case, there is no LIS: the 
end system is reachable via a host route. A PPP connected end system is 
also typically (but not always) connected as a stub network therefore 

Allan                    Expires Sept 13th 1998                [Page 11]

Internet Draft                MARS Proxy               January 22nd,1998

multicast routing topology problems are not expected to emerge. In this 
particular application this restriction does not apply.

The complicated scenario is when an end-system is homed on more than one 
MARS proxy. This is a topic for further study.

9.4 Multiple 'layer 3 over ATM interfaces'

A MARS proxy client will typically be located at a single PPP over ATM 
RAS and as such the MARS client MAY (not MUST) allow for multiple 
independent 'layer 3 over ATM' interfaces.

9.5  Collapsed Architecture

The MARS architecture defines the different entities and interactions 
such that each function may be hosted on different platforms. It would 
be reasonable to suggest that for simplicity, the function of MARS, MCS 
and multicast router at the edge of the ATM subnet could be collapsed 
onto a single platform. 

10. Security Considerations

The focus of the security considerations expressed in this document have 
assumed a public ATM network. Therefore the mechanisms described herein 
have been concerned with ensuring hosts/systems who do not have a 
relationship with the operator/owner of the MARS/MCS infrastructure are 
obstructed from access to it or authorized proxy clients. 

Once authorized access to the 'layer 3' network has been established, 
the security considerations are similar to that both MARS/MCS or of IP 
multicast in general. The reader is directed to [6] as a discussion of 
some of the other pertinent security issues with ION protocols.

11. Acknowledgments

This design is an extension of work originally proposed at the ADSL 
forum with Juha Heinanen of Telia, and Petri Helenius of Santa Monica 
Software.

12. References

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

[2]   Gross, G. et al, "PPP over AAL5", draft-ietf-pppext-aal5-04.txt, 
      Dec 1997

[3]   Simpson, W., "PPP in Frame Relay", RFC 1973, June 1996

[4]   Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM 
      Networks", RFC 2022, November 1996

Allan                    Expires Sept 13th 1998                [Page 12]

Internet Draft                MARS Proxy               January 22nd,1998

[5]   Deering, S., "Host Extensions for IP Multicasting", STD 3, RFC 
      1112, August 1989

[6]   Armitage, G., "Security issues for ION protocols", Internet Draft
      <draft-armitage-ion-security-01.txt>, October 1997

[7]   Hamzeh, K. et. al., "Layer Two Tunneling Protocol 'L2TP'",     
      Internet Draft, <draft-ietf-pppext-l2tp-08.txt>, November 1997

[8]   ATM Forum, "ATM User-Network Interface Specification Version 3.0", 
      September 1993

[9]   Fenner, W., "Internet Group Management Protocol, Version 2", 
      RFC2236, November 1997

13. Author's Address

Questions about this memo can also be directed to:

     Dave Allan
     Nortel
     P.O. Box 3511, Station 'C'
     Ottawa, Ontario
     CANADA, K2B 5P9
     Tel:	(613)763-6362
     [email-masked]

-----------------------
Dave Allan
Nortel PDN Architecture Team

---

From: Chip Sharp <[email-masked]>
Date: Tue, 21 Apr 1998 13:02:37 -0400

Could you please point out the extensions to PPP that you propose?

Despite the use of the acronym PPP in the document, I did not see any
proposed PPP extensions.   I don't think pppext is the appropriate place
for this.  It belongs in ion.  I read the minutes and I understand that
ion is not taking any more work, but that needs to be resolved with ion,
not in pppext.

If the rest of the pppext WG disagrees and wants to start working on
things outside of PPP, then I'll provide technical comments/questions. 
The pppext charter is sufficiently vague that we can justify working on
pretty much whatever we want.  I especially like the "No Goals and
Milestones". See
http://www.ietf.org/html.charters/pppext-charter.html

Chip

> The "ion" in the title is a historical anacronism ;-)
...snip...
-------------------------------------------------
Chip Sharp		voice: +1 (919) 851-2085
Cisco Systems		Telco Consulting 
-------------------------------------------------

---

From: James Carlson <[email-masked]>
Date: Tue, 21 Apr 1998 14:31:08 -0400

> ion is not taking any more work, but that needs to be resolved with ion,

My thoughts on reading the draft as well.

> things outside of PPP, then I'll provide technical comments/questions. 

I agree that the sections which seem to specify interaction with L2TP
also don't actually specify anything that appears to be different from
what we've got today.

I think this belongs in a new "ion2" or (even) issll.  Even the AD is
probably a better place than pppext ...

-- 
James Carlson, Consulting S/W Engineer  <[email-masked]>
IronBridge Networks / 55 Hayden Avenue  71.246W    Vox:  +1 781 402 8032
Lexington MA  02173-7999 / USA          42.423N    Fax:  +1 781 402 8092
"PPP Design and Debugging" ------- http://id.wing.net/People/carlson/ppp

---

From: Matt Holdrege <[email-masked]>
Date: Tue, 21 Apr 1998 12:23:32 -0700

>probably a better place than pppext ...

The AD's from the Routing and Internet areas moved this from ION to PPP.
But if you think it shouldn't be in PPP, you should let the AD's from those
areas know. 

Of course if you have any comments on the draft, please let the author know.

---

From: Chip Sharp <[email-masked]>
Date: Tue, 21 Apr 1998 16:40:35 -0400

>But if you think it shouldn't be in PPP, you should let the AD's
from those

I didn't see in the minutes that the AD's had decreed that this
should be done in pppext.  I don't agree, but the wg never needed my
approval to do anything. ;-)

>Of course if you have any comments on the draft, please let the
author know.

My basic comment was to ask what changes are needed in PPP.  
I didn't see any.  For the time being comments will be addressed to
pppext.

Chip
--------------------------------------------------
Chip Sharp			voice: +1 (919) 851-2085 
Cisco Systems		Mgr - Telco Consulting  			
--------------------------------------------------