Subject: Re: [BEHAVE] draft-denis-icmpv6-generation-for-teredo-00 (was I-D Action:draft-denis-icmpv6-generation-for-teredo-00.txt)

From: <[email-masked]>
Date: Thu, 2 Jul 2009 22:55:48 +0200

Inline,

>Is this diagram accurate?
>
> +-----------+                       +--------------+  +---------+
> |IPv4 client+---<Internet>--(IPv6)--+6/4 translator+--+  IPv4   |
> |with Teredo|                       +--------------+  | server  |
> +-----------+                                         +---------+
>
>So in this case the IPv4 client prefers Teredo over IPv4, does 
>an AAAA query and gets an AAAA response, which is the 6/4 translator.
>
>That 6/4 translator is part of the "same network" as the IPv4 
>server, that is, the 6/4 translator is under the same 
>administrative domain as the IPv4 server because the IPv4 
>server's AAAA record points to the 6/4 translator's IPv6 address.
>
>In this network topology, the IPv4 ICMP Echo Requests (or their
>responses) would be dropped between the 6/4 translator and the 
>IPv4 server, correct?  If so, this seems like an issue with 
>configuring the firewalls and ACLs between the 6/4 translator 
>and IPv4 server?

That indeed can be one scenario. However, if the IPv4 server is configured/blocked from sending ICMPv4 echo replies by policy, will firewall and ACL rule changes be possibility? That would actually be closer to the IPv6 firewall configured to block ICMPv6 echo requests -case.

Another scenario is where the translator is closer to the client than the IPv4 server (different administrative domain), like:

+-----------+               +--------------+  +--------------+          +--------+
|IPv4 client+--<v4Network>--+ Teredo relay +--+6/4 translator+--(IPv6)--+  IPv4  |
|with Teredo|               +--------------+  +--------------+          | server |
+-----------+                                                           +--------+

There the ACL/firewall of IPv4 server cannot be altered.

>> I am somewhat uncomfortable as well, but we did not figure any other 
>> way without changing Teredo client implementations.
>> It would be nice, though, if the echo reply could be tagged with an 
>> "evil bit" - ideas are welcome how to do that backwards compatible 
>> way.
>
>If the 6/4 translator is in the same administrative domain as 
>the server it is spoofing, I am more comfortable with it 
>spoofing traffic from the host it is serving.  But if it does 
>that, it would be better if it did some sort of liveliness 
>check with the server.

Ok, but then I guess question is also why not allow ICMPv4 echo request/replies in ACLs..

	Teemu

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 2 Jul 2009 16:58:50 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: Thursday, July 02, 2009 1:56 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [BEHAVE] 
> draft-denis-icmpv6-generation-for-teredo-00 (was I-D 
> Action:draft-denis-icmpv6-generation-for-teredo-00.txt)
> 
> Inline,
> 
> That indeed can be one scenario. However, if the IPv4 server 
> is configured/blocked from sending ICMPv4 echo replies by 
> policy, will firewall and ACL rule changes be possibility? 
> That would actually be closer to the IPv6 firewall configured 
> to block ICMPv6 echo requests -case.

I could make the same argument that a firewall might possibly
exist between the IPv6/IPv4 translator and the IPv6 Internet,
which would break the effectiveness of your proposal.

> Another scenario is where the translator is closer to the 
> client than the IPv4 server (different administrative domain), like:
> 
> +-----------+                                                 
>           +--------+
Agreed.

(Your diagram had a small error; it should show IPv4 
(rather than IPv6) between the 6/4 translator and the 
IPv4 server).

> echo request/replies in ACLs..

Are you asking why network administrators configure their
routers and firewalls to block ICMP echo requests?

-d