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

Hidden AVPs and NAT

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

Re: Hidden AVPs and NAT

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 

l2tp ports

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

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

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,

Re: Hidden AVPs and NAT