Subject: Re: IP address selection questions

From: Rick Sewill <[email-masked]>
Date: Mon, 20 Dec 1999 14:23:28 -0800 (PST)

Mark,

I had assumed one was not allowed to change the IP address during the
SCCRP.  From rereading the wording in section 8.1, my belief remains the
same.

Below is the paragraph I believe people are quoting:
"8.1 L2TP over UDP/IP
"   L2TP uses the registered UDP port 1701 [RFC1700]. The entire L2TP
"   packet, including payload and L2TP header, is sent within a UDP
"   datagram. The initiator of an L2TP tunnel picks an available source
"   UDP port (which may or may not be 1701), and sends to the desired
"   destination address at port 1701.  The recipient picks a free port on
"   its own system (which may or may not be 1701), and sends its reply to
"   the initiator's UDP port and address, setting its own source port to
"   the free port it found. Once the source and destination ports and
"   addresses are established, they MUST remain static for the life of
"   the tunnel.
"

I would have interpretted the sentence "The recipient picks a free port on
its own system (which may or may not be 1701), and sends its reply to the
initiator's UDP port and address, setting its own source port to the free
port it found." as meaning the UDP port can be changed at this one point
only.  I would also have interpretted this sentence as limiting what can
be changed to the UDP port; I would not have read this sentence to
allow the IP address to be changed.

Mark, could you please ask the people in the IESG what they intended.  I
suspect it does not matter our interpretation.  We will need to do what
the IESG intended...and we will need to change the RFC to reflect their
wishes, assuming we need their blessing.

On Mon, 20 Dec 1999, W. Mark Townsley wrote:

> 
> Sabrina Minshall wrote:
> > 
> > Hi,
> > 
> > > Yes, but what if I told one LAC owner that my address was, say, 10.0.0.1
> > > and then I wanted to move to this loopback address, 10.0.0.2 without
> > > causing the LAC owner to update his config?
> > 
> >   As Mark Townsley said, assign 10.0.0.1 to the loopback interfaces to start
> >   with.
> 
> Looks like I might be talking to myself again.
> 
> OK.. I have two physical interfaces 10.0.0.1 and 10.0.1.1, both of which
> I have already published to different peers in the past, and I want to
> move everyone to 10.0.3.1.
> 
> At any rate, this was just one example. Ignacio's point about load
> sharing is a more convincing argument. However, i do agree that if we
> *really* wanted LNS loadsharing, there is likely more we could do by
> extending the protocol. 
> 
> The fact that we allow the source UDP port to float with the SCCRP,
> means that (if we choose to float) we have to open a new socket anyway.
> So, we already have ACL/IPsec consequences for such. In the most general
> case, it's not much more complex to allow the IP address to float as
> well. If we decide that the source UDP should be locked down (something
> that was argued ad nauseam long ago) for IPsec, ACLs or some other very
> convicing argument, then the same would likely apply for the IP address
> and perhaps vice-versa. 
> 
> Typical flexibility vs. complexity tradeoffs.
> 
> > 
> > > > If the tunnel responder wants to redirect the tunnel, we should
> > > > attach a redirect-to avp to a stop with the "try-another" error code.
> > > > If redirection is considered useful, it ought to be available with
> > > > one mechanism for all transports, not a separate mechanism for each.
> > 
> >   I agree with the first part of the redirect-to AVP idea. It will not break any
> >   implemenations, and could be easily supported/incorporated. I also agree to the
> >   idea of the IP address being conveyed (implicit) to the LAC during SCCRP.
> >   But, associating redirect-to avp to a stop with the "try-another" error code
> >   is not acceptale because of the additional overhead involed.
> > 
> >   The problem. The RFC is ambigous (sp?) when it comes to explaining about
> >   floating IP address. Is it allowed to float only during the establishemnt
> >   of a tunnel? and only during SCCRP? Or, is it allowed to float during the
> 
> The only two ways to read it are (1) no IP address changing at all, or
> (2) IP address changing only with the SCCRP. I believe (2) was the
> intent when it was written, but not sure if it was an oversight or not
> that it did not get changed to (1) by the IESG when publishing. I know
> of at least one or two popular implementations that work like (2).
> Unless these change their behavior, the RFC should reflect what is in
> existance - even if with wording stating that it is bad, evil,
> deprecated, etc.
> 
> >   lifetime of tunnel? The latter approach is clearly disallowed by the
> >   L2TP protocol framework as the transport parameters cannot float once the
> >   tunnel is established. The former may be acceptable. But, I think
> >   this (allowing IP address to float during the establishemnt of the
> >   tunnel - transport) would have side effects when L2TP is used in conjunction
> >   with other features, such as IPSec, ACLs, etc.
> > 
> >   Do we have any consensus?
> > 
> >   sabrina.
> 

Sincerely,

Rick Sewill
FlowPoint Corporation
5200 Great America Parkway
Santa Clara, CA 95054
U.S.A.

e-mail:   [email-masked]  -or-  [email-masked]  -or-  [email-masked]
 phone: 1-408-878-6800  fax: 1-408-878-6801  direct phone: 1-408-878-6826

---

From: Sabrina Minshall <[email-masked]>
Date: Mon, 20 Dec 1999 18:02:06 -0800 (PST)

Hi,
 how would one handle the following cases?

1. Receipt of packet for a non-existing tunnel.
   
2. Receipt of a packet for a existing tunnel and a 
   non-existing session.

Thanks,

Sabrina