Subject: RE: I-D ACTION:draft-dasilva-l2tp-relaysvc-00.txt - Comments

From: "Reinaldo Penno" <[email-masked]>
Date: Mon, 13 Aug 2001 09:13:12 -0700

Hello Mark,

> Note that even if we don't try to support LNS to PPPoE AC 
> forwarding, we will
> have to think about some of this for relay through a tunnel switch. 

Exactly. I think we will not manage to get away with the relay without a
mechanism to know the path (something like the loop prevention AVP), unless
we blast all messages to all tunnels. 

We can change 2516 to allow more than one relay-session-id, but I would
prefer something in L2TP. If I'm not mistaked, 2516 follows the same
relaying model as DHCP, where if you already have a relay-host entry, you
cannot add a second one.

-Reinaldo

> 
> > 
> > -ron
> > 
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > Ron da Silva                          [email-masked]
> > Network Architect                    703.265.4548
> > America Online, Inc.
> > A wholly owned subsidiary of AOL Time Warner Inc.
>

---

From: "W. Mark Townsley" <[email-masked]>
Date: Mon, 13 Aug 2001 19:00:57 +0200

> Reinaldo Penno wrote:
> mechanism to know the path (something like the loop prevention AVP), unless we
> blast all messages to all tunnels.

The tunnels for which we blast messages to will need to be limited by
configuration, with definite recommendations to keep this number to one when at
all possible.

> 
> We can change 2516 to allow more than one relay-session-id, but I would prefer
> something in L2TP. 

I don't think we need more than one ID if we keep the ID of local significance
between any two devices.

> If I'm not mistaked, 2516 follows the same relaying model
> as DHCP, where if you already have a relay-host entry, you cannot add a second
> one.

<rant>

It is hard to know what model 2516 follows with only a couple of easily
misinterpreted paragraphs for the entire feature stuck at the end of the
document in the Appendix under an optional TAG TLV description. But, these days
"shorter" specifications are deemed "better" and pass through the process faster
so who can blame the authors.

</rant>

I consider the Relay-Session-ID analogous to the "xid" in DHCP. From RFC2131:

  xid           4  Transaction ID, a random number chosen by the
                   client, used by the client and server to associate
                   messages and responses between a client and a
                   server.

While we are at it, let's compare PPPoE's IDs with DHCP.

In DHCP you typically always have 3 entities: the Host, the Relay Agent, and the
DHCP server (perhaps more than one if you configure more than one helper
address). The Client ID (typically forwarded intact from the host by the relay
agent) and the giaddr (inserted by the Relay Agent) are the typical basic pieces
of information used to instruct the DHCP server as to what parameters to assign
to the host and to keep up with the lease itself. The "xid" is used to match the
individual transactions.

The Client ID (often a MAC address) may actually be programmed in the DHCP
server itself, and is more analogous to the PPPoE source MAC address that is
forwarded intact in the PPPoE PAD Relay AVP. The PPPoE relay-session-ID does not
have a similar property here. That is, I don't think the PPPoE AC, or any server
that it consults for service advertisements, will key upon the Relay-Session-ID
(at least I truly hope not).

That said, even DHCP plays games with the Client ID when need be as well. For
instance, DHCP proxy for access servers does not have a Host MAC address for
Client ID identification available, so a combination of IP address, userid, etc.
is typically used so that the DHCP server can keep track of leases. The DHCP
server doesn't care that what is in the Client ID is a MAC address or some
munged text, it is just an opaque blob that is probably hashed and stored in a
lookup table. So, even if the Relay-Session-ID were to be considered analogous
to the DHCP Client ID in some respects, we have deployed examples in general of
how games are sometimes played by agents to fool the next participant in the
relay when there is not enough information to fully play by the rules.

- Mark