Subject: [BEHAVE] draft-xli-behave-icmp-address-00

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Fri, 26 Mar 2010 11:52:34 -0700

The way the ICMP messages have been translated by NATs (NAT44s) when
there is no valid mapping was to use the NAT's outgoing interface's IP
address
and that has worked reliably over the years. I see the scenario
described in this draft is no different and the section 2.4.3 is the
easiest to implement and tested solution.
Any good reason why the other solutions are better or why using the
interface's address is not a good idea?
 
Thanks
Senthil

---

From: Xing Li <[email-masked]>
Date: Sat, 27 Mar 2010 05:21:14 +0800

> interface's address is not a good idea?

(1) The v4/v6 stateless translation can have different scheme compared 
with NAT44 which is stateful.
(2) Using the interface's address will cause confusion when doing 
traceroute (routing loop).

regards,

xing
> Thanks
> Senthil
> ------------------------------------------------------------------------
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Fri, 26 Mar 2010 14:51:13 -0700

-----Original Message-----
From: Xing Li [mailto:[email-masked]] 
Sent: Friday, March 26, 2010 5:21 PM
To: Senthil Sivakumar (ssenthil)
Cc: [email-masked]
Subject: Re: [BEHAVE] draft-xli-behave-icmp-address-00

Senthil Sivakumar (ssenthil) 写道:
> address and that has worked reliably over the years. I see the 
> scenario described in this draft is no different and the section 2.4.3 
> is the easiest to implement and tested solution.

(1) The v4/v6 stateless translation can have different scheme compared with NAT44 which is stateful.

[Senthil] The same scenario exists even in stateful NAT44 is what I was trying to point out. When an intermediate router in the public realm sends an ICMP which does not match an existing mapping we will have the same issue. 

(2) Using the interface's address will cause confusion when doing traceroute (routing loop).

[Senthil] Not sure I understand, why would it cause a routing loop? I understand you wouldn’t get the right results from traceroute, but traceorute is a debugging tool than an application in itself. 

Thanks
Senthil

regards,

xing

---

From: Xing Li <[email-masked]>
Date: Sat, 27 Mar 2010 06:12:16 +0800

> [Senthil] The same scenario exists even in stateful NAT44 is what I was trying to point out. When an intermediate router in the public realm sends an ICMP which does not match an existing mapping w…

yes and no. the difference is that this draft translates between
different af and we need to document it.
> [Senthil] Not sure I understand, why would it cause a routing loop? I understand you wouldn’t get the right results from traceroute, but traceorute is a debugging tool than an application in itself…
for example, the interface address is 1.2.3.4, the ipv4 of
ipv4-translatable is 2.3.4.5 (IPv6 host)

and the traceroute 2.3.4.5 from IPv4 results in
4.5.6.7 <- in IPv4
5.6.7.8 <- in IPv4
1.2.3.4 <- in IPv6
1.2.3.4 <- in IPv6
1.2.3.4 <- in IPv6
1.2.3.4 <- in IPv6
2.3.4.5 <- host with IPv4-translatable

regards,

xing

---

From: Xing Li <[email-masked]>
Date: Sat, 27 Mar 2010 06:19:37 +0800

> [Senthil] Not sure I understand, why would it cause a routing loop? I understand you wouldn’t get the right results from traceroute, but traceorute is a debugging tool than an application in itself…

debugging is important tool. xing

---

From: "Senthil Sivakumar (ssenthil)" <[email-masked]>
Date: Sun, 28 Mar 2010 15:22:16 -0700

The use of traceroute with NAT (or NAT64) in the path obscures the view of the network and inhibits your debugging capability, no matter what kind of technique you employ to translate the other realm. The only thing the traceroute gives you in case of NAT is the number of hops and the latency. 
Regarding the routing loop, it is not really a routing loop but it appears to the end user as routing loop but the traceroute can still complete its tracing of the destination. I would suggest adding some text on the disadvantage/drawback around each of the technique described.

Thanks
Senthil

-----Original Message-----
From: Xing Li [mailto:[email-masked]] 
Sent: Friday, March 26, 2010 6:20 PM
To: Senthil Sivakumar (ssenthil)
Cc: [email-masked]
Subject: Re: [BEHAVE] draft-xli-behave-icmp-address-00

Senthil Sivakumar (ssenthil) 写道:
>> there is no valid mapping was to use the NAT's outgoing interface's 
>> IP address and that has worked reliably over the years. I see the 
>> scenario described in this draft is no different and the section 
>> 2.4.3 is the easiest to implement and tested solution.

> Thanks
> Senthil
>
> regards,
>
> xing
>   
>> Thanks
>> Senthil
>> ---------------------------------------------------------------------
>> -
>> --
>>

---

From: Xing Li <[email-masked]>
Date: Mon, 29 Mar 2010 22:40:54 +0800

> The use of traceroute with NAT (or NAT64) in the path obscures the view of the network and inhibits your debugging capability, no matter what kind of technique you employ to translate the other rea…
yes, but it is better than nothing for trouble shooting.

> Regarding the routing loop, it is not really a routing loop but it appears to the end user as routing loop but the traceroute can still complete its tracing of the destination. I would suggest addi…
yes, it is not a real routing loop, but the end users and even operators
may got confused. we have been running stateless translation (ivi) for 3
years and the operators really want to use the traceroute tool for
debugging. we will add the limitations of these methods in the next
version. if you have suggested text, please send to us. thanks in advance.

regards,

xing, congxiao