Subject: (ngtrans) another 6to4 question/comment

From: Paul Francis <[email-masked]>
Date: Tue, 08 Aug 2000 16:51:00 -0700

Section 7 (ICMP messages) of the 6to4 document says that 6to4 routers
will "often" be unable to forward an IPv4 ICMP message as an ICMPv6
message because of a lack of data copied into the ICMP message.

Section 4.1.3 of RFC1933 says that "many" older IPv4 routers don't
return enough data, and that more modern IPv4 routers "may" return
enough data.

I was wondering how often "often" is and how many "many" is, so Vern did
a quick trace on a UCB internet access link (attached below) and found
that 93% of unreachables potentially returned by backbone routers (host,
net), and 99% of time exceeded messages carried the minimum amount of
data.

Maybe you all knew this already, but I was surprised.  Does this mean
that, for 6to4 especially, the IPv4 segment---which amounts to most of
the path early on---is undiagnosable from an IPv6 host?  Or are there
some neat tricks around this?  How much of a problem is this in fact?

PF

---

From: Francis Dupont <[email-masked]>
Date: Wed, 09 Aug 2000 10:52:03 +0200

In your previous mail you wrote:

=> 93% seems a very low number for me (:-)!

   Maybe you all knew this already, but I was surprised.

=> we knew. ICMP data (first bytes of the offending packet) is near
unusable but the real problem is most of the (misconfigured) firewalls
just drop all ICMPs on the floor, ie. if something goes wrong then
you'll get only a dark hole... This is a nightmare for infrastructures
using encapsulation like IPsec VPNs.

   Does this mean that, for 6to4 especially, the IPv4 segment---which
   amounts to most of the path early on---is undiagnosable from an IPv6
   host?

=> if you get ICMPs you can do something useful according to the type
of error. Typically you can keep some state and reflect it for next
packets in the same flow (the definition of flow depends on errors
and on the type of tunnels, configured tunnels are far better than 6to4
for this point).

   Or are there some neat tricks around this?

=> look at RFC 2473 for instance...

   How much of a problem is this in fact?
   
=> short ICMP data delay error signaling and fail with short flows but
the real problem is spurious ICMP filtering...

Regards

[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Aug 2000 09:01:37 -0500

Paul,

As far as I can see this issue affects all 6-in-4 tunnel solutions,
not just 6to4. And yes, I can imagine it being a problem for diagnosis
(essentially it means that diagnosis would need to be done from an IPv4
host, not from the IPv6 host).

But since IPv4 will be the carrier network for IPv6 for many years,
I think network operators will just have to deal with this. I would expect
network management systems to be dual stack and capable of diagnosing
the IPv4 path when a 6-in-4 tunnel fails.

Actually this must be an issue today for plenty of 4-in-4 tunnel
deployments of various flavours.

   Brian

---

From: Keith Moore <[email-masked]>
Date: Wed, 09 Aug 2000 10:54:14 -0400

I looked at this problem when we did the first draft of 6to4.
Basically I conculded that when 6to4 was incorporated into a 
host, that host might be able to make some use of an IPv4
ICMP message, (since the host already keeps track of connection
state and there might be only one connection from that host to 
any particular remote 6to4 address block) but it was unlikely 
that a 6to4 router would be able to return any reasonable kind 
of ICMPv6 message to a host behind it.    the router would 
presumably not want to keep track of per-connection state, and 
even if it did, the chances of multiple connections with the 
same destination would be increased.

so I would expect applications running over 6to4 to see 
"connection timed out" errors (after a delay)
where they might otherwise see "network unreachable" errors. 
and already-open connections would get wedged more often.

it would be really nice if we could come up with some sort
of hybrid 6/4 traceroute/pathchar utility.  but I suspect 
this will require explicit support from 6to4 routers,
at the very least.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Aug 2000 12:17:15 -0500

True enough. 6to4 is connectionless tunnelling I guess. 

  Brian

Paul Francis wrote:
> Yes, but with configured tunnels (including v4-v4 tunnels, which I assume is
> what most v4-v4 tunnels are), the tunnel entry point maintains knowledge
> about the state of the tunnel, so you can get some diagnostics etc. out of
> it.  You can't do this with 6to4, which is why I was specifically refering
> to 6to4...
> 
> PF

---

From: Paul Francis <[email-masked]>
Date: Wed, 09 Aug 2000 09:16:27 -0700

PF