W. Mark Townsley | 4 Sep 09:10 2003
Picon

Last Call for draft-ietf-l2tpext-mcast-03.txt


This is Last Call for draft-ietf-l2tpext-mcast-03.txt

I will advise the Area Directors no sooner than September 18, 2003, to publish 
draft-ietf-l2tpext-mcast-02.txt as an Experimental RFC unless there is 
substantive comment raised on this list.

Thanks,

- Mark
Avinash Natarajan | 20 Sep 12:35 2003

Hidden AVPs and NAT

Hi...
    i am trying to write a l2tp pass through for NAT. i need to get the assigned tid value
from the Assigned Tid AVP and create some mappings when necassary. is there any known
way of dealing with it/work around it in cases where this avp is hidden?
    Thanks.
-Avinash
 
 
"Because i live in a large tin can and i work in an egg carton Flirting is the only joy i have:)"
Vipin Jain | 22 Sep 18:32 2003
Picon

Re: Hidden AVPs and NAT


In L2TPv2:

Instead of mapping tids across NAT, you may want to map
the udp port. For example, for a given incoming IP address
choose a source udp port and remap it back for the packets
coming back from the LNS. You may want to look into section
8.1, rfc2661 for more details.

That way you would avoid keeping the configuratin of tunnel
secrets for various LAC-LNS pairs.

-- vipin

--- Avinash Natarajan <avinash.nat <at> wipro.com> wrote:
> Hi...
>     i am trying to write a l2tp pass through for NAT. i need to get the
> assigned tid value
> from the Assigned Tid AVP and create some mappings when necassary. is there
> any known
> way of dealing with it/work around it in cases where this avp is hidden?
>     Thanks.
> -Avinash
> 
> 
> "Because i live in a large tin can and i work in an egg carton Flirting is
> the only joy i have:)"
> 

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Avinash Natarajan | 23 Sep 18:09 2003

Re: Hidden AVPs and NAT

Hi
    One more clarification, suppose i can only be an initiator of a tunnel/session(pkts goin out of the NAT
would only be SSRQ/ICRQ), in that case a NAT capable of port mapping would suffice right. I need
not do anything extra to handle l2tp as a special case. (cos the recepient will always set the destination
port as the source port of the sender - so reverse translation will always succeed, the recepient can alter
source port to any free port of his but that will not affect my NAT's operation).
    Thanks.
-Avinash
 
 
"Because i live in a large tin can and i work in an egg carton Flirting is the only joy i have:)"
----- Original Message -----
From: Vipin Jain
Sent: Monday, September 22, 2003 10:02 PM
Subject: Re: [L2tpext] Hidden AVPs and NAT


In L2TPv2:

Instead of mapping tids across NAT, you may want to map
the udp port. For example, for a given incoming IP address
choose a source udp port and remap it back for the packets
coming back from the LNS. You may want to look into section
8.1, rfc2661 for more details.

That way you would avoid keeping the configuratin of tunnel
secrets for various LAC-LNS pairs.

-- vipin


--- Avinash Natarajan <avinash.nat <at> wipro.com> wrote:
> Hi...
>     i am trying to write a l2tp pass through for NAT. i need to get the
> assigned tid value
> from the Assigned Tid AVP and create some mappings when necassary. is there
> any known
> way of dealing with it/work around it in cases where this avp is hidden?
>     Thanks.
> -Avinash
>
>
> "Because i live in a large tin can and i work in an egg carton Flirting is
> the only joy i have:)"
>


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Dave Thaler | 23 Sep 23:41 2003
Picon

FW: tunnelMIB (RC2667) implementations and/or deployment

Forwarding to L2TP WG and L2TP MIB authors, 
since the L2TP MIB (RFC 3371) extends RFC 2667.

Please cc mibs <at> ops.ietf.org on replies. 

-Dave

-----Original Message-----
From: owner-mibs <at> ops.ietf.org [mailto:owner-mibs <at> ops.ietf.org] On Behalf
Of Wijnen, Bert (Bert)
Sent: Tuesday, September 23, 2003 7:54 AM
To: mibs (E-mail)
Subject: tunnelMIB (RC2667) implementations and/or deployment

I'd be interested to hear about implementations and/or
deployment of the tunnelMIB as defined in RFC2667.

Thanks,
Bert 
Avinash Natarajan | 25 Sep 10:55 2003

l2tp ports

Hi,
    i want to confirm if my understanding of how ports are set in lac/lns is right. i have a nat
which checks for the entire session info before letting a pkt pass thru that causes l2tp to
not operate over it.
    is the following port related data right for l2tp operation?
 
-----------------------------------------------------------------------------------------------
LAC(initial packet):
Src port = X
Dstn port = 1701
 
LNS (response to the above pkt):
Src port = Y (some free port,cud also be 1701)
Dstn port = X
 
LAC (rest of the tunnel's life after establishment)
Src port = X
Dstn port = Y
 
LNS (rest of the tunnel's life after establishment)
Src port = Y
Dstn port = X
-------------------------------------------------------------------------------------------------
 
  also, is there any scenario(any know implementation of lns) in which an LNS might decide to choose a
source ip different from that on which it received the initial packet. there is no mention of such a thing in the
l2tp std but i saw such a scenario being discussed in linux netfilters forum with respect to l2tp operation
over nat.
 
-Avinash
 
 
 
 
 
 
"Because i live in a large tin can and i work in an egg carton Flirting is the only joy i have:)"
Vipin Jain | 25 Sep 19:29 2003
Picon

Re: Hidden AVPs and NAT


>     One more clarification, suppose i can only be an initiator of a
> tunnel/session(pkts goin out of the NAT
> would only be SSRQ/ICRQ),
I assume you meant SCCRQ; I also assume that you
are talking about incoming calls;

> in that case a NAT capable of port mapping would
> suffice right. I need
> not do anything extra to handle l2tp as a special case.
> (cos the recepient will always set the destination
> port as the source port of the sender - so reverse
> translation will always succeed, the recepient can alter
> source port to any free port of his but that will not
> affect my NAT's operation).
IMO it would work.

On other hand if you are not the originator, then
implementing NAT for incoming calls from outside is
little confusing. NAT, typically makes sense, when
connections/sessions (whether TCP, UDP, L2TP, etc.)
are initiated from within.

Or did I not understand your point?

-- vipin

>     Thanks.
> -Avinash
> 
> 
> "Because i live in a large tin can and i work in an egg carton Flirting is
> the only joy i have:)"
>   ----- Original Message ----- 
>   From: Vipin Jain 
>   To: Avinash Natarajan ; l2tpext <at> ietf.org 
>   Sent: Monday, September 22, 2003 10:02 PM
>   Subject: Re: [L2tpext] Hidden AVPs and NAT
> 
> 
> 
>   In L2TPv2:
> 
>   Instead of mapping tids across NAT, you may want to map
>   the udp port. For example, for a given incoming IP address
>   choose a source udp port and remap it back for the packets
>   coming back from the LNS. You may want to look into section
>   8.1, rfc2661 for more details.
> 
>   That way you would avoid keeping the configuratin of tunnel
>   secrets for various LAC-LNS pairs.
> 
>   -- vipin
> 
> 
>   --- Avinash Natarajan <avinash.nat <at> wipro.com> wrote:
>   > Hi...
>   >     i am trying to write a l2tp pass through for NAT. i need to get the
>   > assigned tid value
>   > from the Assigned Tid AVP and create some mappings when necassary. is
> there
>   > any known
>   > way of dealing with it/work around it in cases where this avp is hidden?
>   >     Thanks.
>   > -Avinash
>   > 
>   > 
>   > "Because i live in a large tin can and i work in an egg carton Flirting
> is
>   > the only joy i have:)"
>   > 
> 
> 
>   __________________________________
>   Do you Yahoo!?
>   Yahoo! SiteBuilder - Free, easy-to-use web site design software
>   http://sitebuilder.yahoo.com
> 
> **************************Disclaimer************************************
> 
> Information contained in this E-MAIL being proprietary to Wipro Limited is 
> 'privileged' and 'confidential' and intended for use only by the individual
>  or entity to which it is addressed. You are notified that any use, copying 
> or dissemination of the information contained in the E-MAIL in any manner 
> whatsoever is strictly prohibited.
> 
> ***************************************************************************
> 

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
Tissa Senevirathne | 26 Sep 20:57 2003
Picon

generic NSP layer signaling

The ID below discuss generic NSP layer signaling. The motivation of this ID 
is to define a generic NSP layer signaling method that is not specifically 
tied to the undelying tunnel signaling protocol. As an example NSP foo 
signaling should not change (or redefined ) whether it is over tunnel bar or 
bar2. Signaling protocols both bar and bar2 does not really need to know the 
content of the NSP signaling and simply transport the NSP signaling.

http://www.ietf.org/internet-drafts/draft-tsenevir-sig-nsp-00.txt

Appreciate, if you could comment on the method presented in the ID.

Thanks

Tissa

_________________________________________________________________
Get MSN 8 Dial-up Internet Service FREE for one month.  Limited time offer-- 
sign up now!   http://join.msn.com/?page=dept/dialup
Motonori Shindo | 29 Sep 08:08 2003
Picon

Re: l2tp ports

Avinash,

From: "Avinash Natarajan" <avinash.nat <at> wipro.com>
Subject: [L2tpext] l2tp ports
Date: Thu, 25 Sep 2003 14:25:38 +0530

> i want to confirm if my understanding of how ports are set in lac/lns is 
> right. i have a nat which checks for the entire session info before 
> letting a pkt pass thru that causes l2tp to not operate over it.
> is the following port related data right for l2tp operation?

> -----------------------------------------------------------------------
> LAC(initial packet):
> Src port = X
> Dstn port = 1701
> 
> LNS (response to the above pkt):
> Src port = Y (some free port,cud also be 1701)
> Dstn port = X
> 
> LAC (rest of the tunnel's life after establishment)
> Src port = X
> Dstn port = Y
> 
> LNS (rest of the tunnel's life after establishment)
> Src port = Y
> Dstn port = X

I believe this is right. Couple of points you'd better be aware of:

  - LAC is not always the "initiator" in terms of tunnel
    establishment. LNS can also be an initiator (and this is because
    the standard is using the term "initiator" and "recipient", not
    LAC and LNS)

  - port number selected by initiator (port number X in above diagram)
    can be 1701

  - As mentioned in the standard, choosing port number "X" to be
    something other than 1701, there is some implication for such an
    L2TP implimentation to be NAT-friendly. Most implementations would
    choose 1701 to avoid such a complication if possible, but there
    are some systems that need to choose non-1701 port due to its
    system architecture (e.g. modular (line-card) architecture).

> also, is there any scenario(any know implementation of lns) in which 
> an LNS might decide to choose a  source ip different from that on which 
> it received the initial packet. there is no mention of such a thing in 
> the l2tp std but i saw such a scenario being discussed in linux 
> netfilters forum with respect to l2tp operation over nat.

In early days of l2tp draft, there was a paragraph:

   It is legal for a peer's IP address and/or UDP port used for a given
   tunnel to change over the life of a connection; this may correspond
   to a peer with multiple IP interfaces responding to a network
   topology change.  Responses should reflect the last source IP address
   and UDP port for that Tunnel ID.

but this paragraph was eliminated in draft-12 or later. I don't know
the rationale behind this decision, but it seems to me that it is to
avoid unnecessary complication for most implementations (particularly
that based on UNIX socket).

Regards,
Avinash Natarajan | 29 Sep 08:47 2003

Re: Hidden AVPs and NAT

Hi..
 
 
----- Original Message -----
From: Vipin Jain
Sent: Thursday, September 25, 2003 10:59 PM
Subject: Re: [L2tpext] Hidden AVPs and NAT


>     One more clarification, suppose i can only be an initiator of a
> tunnel/session(pkts goin out of the NAT
> would only be SSRQ/ICRQ),
I assume you meant SCCRQ; I also assume that you
are talking about incoming calls;

> in that case a NAT capable of port mapping would
> suffice right. I need
> not do anything extra to handle l2tp as a special case.
> (cos the recepient will always set the destination
> port as the source port of the sender - so reverse
> translation will always succeed, the recepient can alter
> source port to any free port of his but that will not
> affect my NAT's operation).
IMO it would work.

On other hand if you are not the originator, then
implementing NAT for incoming calls from outside is
little confusing. NAT, typically makes sense, when
connections/sessions (whether TCP, UDP, L2TP, etc.)
are initiated from within.

Or did I not understand your point?
 
---Yes, i am always the originator, everything is initiated from inside the NAT.
But the prob is, the NAT i am talking about does a comparison for the entire session information
for any incoming packet. So comparison is made at nat for src ip,dstn ip,src port and
dstn port. Now the source port of the SCCRP could be different from the 1701(since recepient
can use any free port as source port while responding to a SCCRQ). This wud cause
a failure in the NAT lookup. i've deviced a workaround for the same with the port table
kindof thing i had sent earlier in the group as the basis...
 
There's one more scenario where i foresee a problem(when more than one guy behind a nat tries to
initiate a tunnel).
 
                             -----------------------
Initiator1----------------|                      |
                            |         NAT      |---------------------Recepient
Initiator2----------------|                      |
                            -----------------------
 
In above case, when originator 1 and 2 try to set up tunnels with the same assigned Tunnel id values
one of them would fail. This calls for some kindof tunnel id mapping for the above scenario to work.
This brings back the problem of hidden avps.
Is this a real problem or am i inventing it.
 
Thanks.
-Avinash

-- vipin

>     Thanks.
> -Avinash
>
>
> "Because i live in a large tin can and i work in an egg carton Flirting is
> the only joy i have:)"
>   ----- Original Message -----
>   From: Vipin Jain
>   To: Avinash Natarajan ; l2tpext <at> ietf.org
>   Sent: Monday, September 22, 2003 10:02 PM
>   Subject: Re: [L2tpext] Hidden AVPs and NAT
>
>
>
>   In L2TPv2:
>
>   Instead of mapping tids across NAT, you may want to map
>   the udp port. For example, for a given incoming IP address
>   choose a source udp port and remap it back for the packets
>   coming back from the LNS. You may want to look into section
>   8.1, rfc2661 for more details.
>
>   That way you would avoid keeping the configuratin of tunnel
>   secrets for various LAC-LNS pairs.
>
>   -- vipin
>
>
>   --- Avinash Natarajan <avinash.nat <at> wipro.com> wrote:
>   > Hi...
>   >     i am trying to write a l2tp pass through for NAT. i need to get the
>   > assigned tid value
>   > from the Assigned Tid AVP and create some mappings when necassary. is
> there
>   > any known
>   > way of dealing with it/work around it in cases where this avp is hidden?
>   >     Thanks.
>   > -Avinash
>   >
>   >
>   > "Because i live in a large tin can and i work in an egg carton Flirting
> is
>   > the only joy i have:)"
>   >
>
>
>   __________________________________
>   Do you Yahoo!?
>   Yahoo! SiteBuilder - Free, easy-to-use web site design software
>   http://sitebuilder.yahoo.com
>
> **************************Disclaimer************************************
>
> Information contained in this E-MAIL being proprietary to Wipro Limited is
> 'privileged' and 'confidential' and intended for use only by the individual
>  or entity to which it is addressed. You are notified that any use, copying
> or dissemination of the information contained in the E-MAIL in any manner
> whatsoever is strictly prohibited.
>
> ***************************************************************************
>


__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com

Gmane