Subject: [lisp] Some ideas about the interworking issues.

From: Xuewei Wang <[email-masked]>
Date: Thu, 28 Jan 2010 18:06:08 +0800

Hi all,

I am a newcomer of this group. Recently i read the interworking draft, below is some my considerations.

The PTR mechanism allows a non-LISP site to send packets to a LISP-NR site. Traffics from the non-LISP to the LISP-NR sites will be routed towards the PTRs, which will force heavy burden on the PTRs, and possibly PTRs will be the bottleneck of the network. LISP-NAT mechanism allows a LISP-NR site to speak to a non-LISP site, which has no the problem of the PTR mechanism, but not consider the case of a non-LISP site speaking to a LISP-NR site.

I am thinking another method for the case of a non-LISP site speaking to a LISP-NR site as an extension to the LISP-NAT mechanism, with which the traffic load on RTRs could be reduced to some extent. This method only requires some changes to DNS、ITR and ETR. By defining a new opcode for the DNS message, we can identify whether a DNS query message is from a LISP site or not. 

At the source site an host initiates a DNS query for the destination host in a LISP-NR site. If the source site is a LISP site we make the DNS resolver or the ITR of the site to set the new defined opcode which indicates the DNS request is from a LISP site. If the source site is a non-LISP site no change is needed.

At the destination site when receiving a DNS query message, the DNS server responds with the EID of the destination host and copies the new defined opcode of the query message to the response message. The ETR intercepts the response message and judges whether the query is from a LISP site or not according to the opcode of the response message. If the query comes from a LISP site the ETR assigns a routable address of the ETR for the destination host(reusing the LISP-NAT function on ETR) and responds with the routable address to the source host, and if the query comes from a non-LISP site the ETR just forwards the response message to the source host.

Thus the host from the non-LISP site can communcate with the host in the LISP-NR site with this routable address as destination address, and the ETR of the LISP-NR site plays the same role as a NAT.

How do you think this method?

Xuewei Wang

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Fri, 29 Jan 2010 13:37:55 -0800

> Hi all,
>  
> 
> I am a newcomer of this group. Recently i read the 
> interworking draft, below is some my considerations.
> 

Thanks for your feedback!  

> 
> 
> The PTR mechanism allows a non-LISP site to send packets to a 
> LISP-NR site. Traffics from the non-LISP to the LISP-NR sites 
> will be routed towards the PTRs, which will force heavy 
> burden on the PTRs, and possibly PTRs will be the bottleneck 
> of the network. LISP-NAT mechanism allows a LISP-NR site to 
> speak to a non-LISP site, which has no the problem of the PTR 
> mechanism, but not consider the case of a non-LISP site 
> speaking to a LISP-NR site.

I'm sorry the draft was not clear.  A non-LISP site can communicate with a LISP-NR which is using LISP-NAT because the outer-NAT addresses are routable.  So a LISP-NAT site would put this outer address into DNS.  Of course, this has all the classic limitations of IPv4 NAT. 

>
> 
> I am thinking another method for the case of a non-LISP site 
> speaking to a LISP-NR site as an extension to the LISP-NAT 
> mechanism, with which the traffic load on RTRs could be 
> reduced to some extent. This method only requires some 
> changes to DNS、ITR and ETR. By defining a new opcode for the 
> DNS message, we can identify whether a DNS query message is 
> from a LISP site or not. 
> 

So if I understand you correctly, in theory a LISP site would return the outer address to non-LISP sites, and the inner address to LISP-NR sites.  It would know to do this because the incoming DNS request indicated that the source was a LISP site.

>  
> 
> At the source site an host initiates a DNS query for the 
> destination host in a LISP-NR site. If the source site is a 
> LISP site we make the DNS resolver or the ITR of the site to 
> set the new defined opcode which indicates the DNS request is 
> from a LISP site. If the source site is a non-LISP site no 
> change is needed.
> 

Understood.

>  
> 
> At the destination site when receiving a DNS query message, 
> the DNS server responds with the EID of the destination host 
> and copies the new defined opcode of the query message to the 
> response message. The ETR intercepts the response message and 
> judges whether the query is from a LISP site or not according 
> to the opcode of the response message. If the query comes 
> from a LISP site the ETR assigns a routable address of the 
> ETR for the destination host(reusing the LISP-NAT function on 
> ETR) and responds with the routable address to the source 
> host, and if the query comes from a non-LISP site the ETR 
> just forwards the response message to the source host.

I'm not sure that its viable to expect the ETR to intercept the DNS reply packet and do something to it.  There are many reasons for this, including the fact that the ITR may be on a separate device from the ETR, so the ETR will never see the response.  Also, hijacking and changing the contents of data-packets on the fly is not something I feel comfortable having a protocol doing (performance, security, lots of issues).

>  
> 
> Thus the host from the non-LISP site can communcate with the 
> host in the LISP-NR site with this routable address as 
> destination address, and the ETR of the LISP-NR site plays 
> the same role as a NAT.
> 
> 
> 
My initial reaction that, while an interesting idea, it suffers from some problems (if I understand this proposal correctly):

1)  Its complicated LISP-NAT is supposed to be a local, simple mechanism to allow for communication
2)  It requires middle boxes to modify DNS reply packets
3)  It assumes a LISP-NR site is using DNS when it communicates with a LISP-NR site.
4)  It requires DNS changes when a site migrates to LISP

Thanks for taking the time to write this idea up!

-Darrel

> 
> Xuewei Wang
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Xu Xiaohu <[email-masked]>
Date: Sat, 30 Jan 2010 10:38:03 +0800

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Darrel
> Lewis (darlewis)
> 发送时间: 2010年1月30日 5:38
> 收件人: Xuewei Wang; [email-masked]
> 主题: Re: [lisp] Some ideas about the interworking issues.
> 
> 
> > Hi all,
> >
> >
> I'm sorry the draft was not clear.  A non-LISP site can communicate with a
> LISP-NR which is using LISP-NAT because the outer-NAT addresses are
routable.
> So a LISP-NAT site would put this outer address into DNS.  Of course, this
has
> all the classic limitations of IPv4 NAT.

If so, the hosts in a LISP site would have to also use the routable outer
address as destination address for initiating communication to the hosts in
a LISP-NR. As a result, the traffic between two LISP sites would also have
to traverse the PTRs. I think this is not your expection.

Xiaohu
 
> So if I understand you correctly, in theory a LISP site would return the
outer
> address to non-LISP sites, and the inner address to LISP-NR sites.  It
would
> know to do this because the incoming DNS request indicated that the source
was
> a LISP site.
> I'm not sure that its viable to expect the ETR to intercept the DNS reply
packet
> and do something to it.  There are many reasons for this, including the
fact
> that the ITR may be on a separate device from the ETR, so the ETR will
never
> see the response.  Also, hijacking and changing the contents of
data-packets
> on the fly is not something I feel comfortable having a protocol doing
> (performance, security, lots of issues).
> 
> >
> >
> My initial reaction that, while an interesting idea, it suffers from some
> problems (if I understand this proposal correctly):
> 
> 1)  Its complicated LISP-NAT is supposed to be a local, simple mechanism
to
> allow for communication
> 3)  It assumes a LISP-NR site is using DNS when it communicates with a
LISP-NR
> site.