Subject: [L2tpext] Question about AVP parsing

From: Chirayu Shah <[email-masked]>
Date: Fri, 10 May 2002 11:25:31 -0400

Hi,
	If we receive an L2TP message from a buggy implementation that sets
the M-bit in an AVP and the AVP requires the M bit to be set to 0, should
we ignore the M bit if the AVP is known to us? In other words, should there
be a check for (M bit == 0) for AVPs that should not have the M bit set?
Does this kind of check buy us anything? The RFC talks about M bit only in
references to unknown AVPs.

Thanks,
Chirayu.

_______________________________________________
L2tpext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext

---

From: Jed Lau <[email-masked]>
Date: Fri, 10 May 2002 09:57:16 -0700 (PDT)

Hi Chirayu,

I'm not sure that check buys you much.  Clearly, the peer implementation
shouldn't be setting the M bit to 1 for those AVPs.  As the RFC states:
"... It is the full responsibility of the peer sending the Mandatory AVP
to accept fault for causing an non-interoperable situation."  Having said
that, an implementation that is flexible in what it receives would not
check for (M bit == 0).  The M bit is most important for figuring out what
to do when an unrecognized AVP is received.

Jed

---

From: Ignacio Goyret <[email-masked]>
Date: Fri, 10 May 2002 10:07:12 -0700

You should be flexible in what you accept. The M-bit is used only to
indicate what to do if and only if you don't know about that particular
AVP. If you do know, you should ignore the M-bit.
If you really want to, you might consider issuing some sort of message
but IMO you should not reject those AVPs.

---

From: "Yoav Nir" <[email-masked]>
Date: Sun, 12 May 2002 09:45:03 +0200

Hello all,

As far as I can tell from RFC 2661, an LAC connects to only a single LNS.
There is no provision for an LAC to open multiple tunnels to multiple LNS
and to tunnel each call to the appropriate LNS based either on configuration
parameters (calling number?) or on client request.

Is there some extension draft or RFC somewhere for this functionality?  I
imagine this would also require an extension to PPP to allow the client to
request a specific LNS.

Thanks in advance

Yoav Nir

---

From: "W. Mark Townsley" <[email-masked]>
Date: Sun, 12 May 2002 09:03:18 +0200

> parameters (calling number?) or on client request.

An LAC may open Control Connections to as many LNSs as it would like.

> 
> Is there some extension draft or RFC somewhere for this functionality?  

Such an RFC is unnecessary. Each Control Connection to a separate LNS (or even
the same LNS) is fully independent of the other, so there is no great motivation
to explicitly point out the interaction between each.

> I

No. Just select your LNS based on your local policy. An example is the @domain
method mentioned in the RFC, calling number as you suggest, or a any other
method based upon your policy. PPP does not need to be extended for any of
these.

---

From: "Yoav Nir" <[email-masked]>
Date: Sun, 12 May 2002 10:32:10 +0200

I'm afraid I don't understand what the "@domain method" mentioned in the RFC
is.

Suppose an LAC is owned by an ISP and suppose further that we don't know any
phone numbers in advance.  How would the LAC know which LNS to contact?
What information does it have that it can possible base a policy on?

---

From: "W. Mark Townsley" <[email-masked]>
Date: Sun, 12 May 2002 09:59:57 +0200

> I'm afraid I don't understand what the "@domain method" mentioned in the RFC

Sorry, perhaps I was not being clear.

The idea is that you perform enough PPP signaling at the LAC to obtain the
user's "apparant identity" and then begin the tunneling process to the LNS
indicated by policy (either locally configured, or from a directory lookup).
Thus, you perform LCP negotiation, and at least part of PPP authentication,
receiving, say, a username of the form [email-masked]. Based on your local policy,
you tunnel all users with "@isp.com" as a suffix in the username to a given LNS.
Thus the LAC is only configured with the LNSs it has agreements with, rather
than every possible user at each LNS.