Subject: Re: I-D Action:draft-vandevelde-v6ops-harmful-tunnels-01.txt

From: Gert Doering <[email-masked]>
Date: Wed, 1 Sep 2010 12:25:31 +0200

Hi,

On Wed, Sep 01, 2010 at 10:22:15AM +1200, Brian E Carpenter wrote:
> Some positive proposals for how to correct these failure modes would
> be more productive than a "considered harmful" conclusion, too.
> 6to4 exists to bypass IPv4-only ISPs; 

This model seems to assume that end users see value in deploying IPv6
if they have enough IPv4 addresses.

Looking around, I can see a few end users for those this is true - but
those can help themselves with configured tunnels.

For the large mass of end users, they don't seem to see a benefit in
deploying IPv6 while their IPv4 internet is still working - so I doubt
that the originally-envisioned usage case of 6to4-with-anycast (3068)
really does anything good these days, while it definitely does harm, as 
there *are* overloaded/badly managed anycast relays out there, and they
won't go away any time soon.

(You want operator input - here's operator input:  use IPv6 in a fully
managed and controlled way[*], or stick to IPv4.)

[*] 6rd is something I have no issues with it - it's no better or worse 
than 6PE MPLS tunneling "the ISP manages this for his customers and there 
is a well-defined point of contact to make it work if something is broken".

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  155817

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Fernando Gont <[email-masked]>
Date: Wed, 01 Sep 2010 23:05:47 -0300

Gert,

> that the originally-envisioned usage case of 6to4-with-anycast (3068)

Is 6to4-with-anycast the most deployed form of 6to4?

FWIW, Windows does not use the 6to4 anycast address, but rather resolves
6to4.ipv6.microsoft.com, and uses the corresponding a records for the
destination address of tunneled packets (Hurrican Electric relays, the
last time that I checked). One would guess that for managed 6to4 routers
this would be even more so the case.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 01 Sep 2010 20:13:56 -0700

> this would be even more so the case.

in the case where for example your home router is the 6to4 device the
router and not the windows stack is the involved party since  it's the
only device with a public v4 address. watching the dlinks and some other
devices I have they certainly do use the v4 anycast address.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Sep 2010 15:37:22 +1200

On 2010-09-02 15:13, Joel Jaeggli wrote:
>> 6to4.ipv6.microsoft.com, 

But that resolves to 192.88.99.1 which *is* the anycast address [RFC3068],
at least where I'm sitting.

C:\>tracert 6to4.ipv6.microsoft.com

Tracing route to 6to4.ipv6.microsoft.com [192.88.99.1]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  csrs5.sfac.auckland.ac.nz [130.216.38.254]
  2    <1 ms    <1 ms    <1 ms  com-sci-to-sci-sx.net.auckland.ac.nz [130.216.252.46]
  3    <1 ms    <1 ms    <1 ms  sci-sx-to-com-sci.net.auckland.ac.nz [130.216.252.45]
  4    <1 ms    <1 ms    <1 ms  cx-alfa-to-sx-300.net.auckland.ac.nz [130.216.252.5]
  5    <1 ms    <1 ms    <1 ms  br1-to-cx-alpha.net.auckland.ac.nz [130.216.246.41]
  6    <1 ms    <1 ms    <1 ms  210.7.32.1
  7    <1 ms    <1 ms    <1 ms  210.7.36.67
  8    24 ms    24 ms    24 ms  210.7.47.10
  9    24 ms    24 ms    24 ms  192.88.99.1

Trace complete.

and uses the corresponding a records for the
>> this would be even more so the case.

When I was using 6to4 actively, I scouted out a list of unicast relays,
because there was no nearby anycast relay at that time.

If you know the right magic, you can make Windows (XP, at any rate) use
whatever outbound relay you want, but it's still host-based 6to4, and
the RFC 3056 model is router based.

netsh interface ipv6 6to4 set relay <ipv4 address goes here>

> devices I have they certainly do use the v4 anycast address.

Oh, you have DLINKs that do 6to4? Pray tell the model number and software version.

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Thu, 02 Sep 2010 01:38:45 -0300

Hi, Brian,

> at least where I'm sitting.

Yes. Now I wonder... a few days ago I was snooping my own traffic, and
my 6to4 packets were *not* being directed to 192.88.99.1. :-/  -- for
instance, I was rather surprised about that.

> the RFC 3056 model is router based.

One could expect a vendor to, e.g., populate a domain like
6to4.ipv6.dlink.com that contains several A records, and have their
equipment resolve that domain, find the closest domain, and use that one
rather than the anycast domain.

FWIW, what I don't like about the 6to4 anycast addr is that 6to4 relays
respond to queries (e.g. ping) with the anycast address as the source
address, rather than the unicast one. -- Yes, this was suggested in some
RFC (6to4 security?)

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 02 Sep 2010 01:40:41 -0300

> rather than the anycast domain.

They could even do some magic. e.g., respond to queries based on the
source address of the querier -- and e.g. respond with the whole list or
the anycast address in case of overload.

Thanks,

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Thu, 2 Sep 2010 10:17:27 +0200

> instance, I was rather surprised about that.

Perhaps because the IPv6 destination was 2002:xyz then 6to4 'went' direct to the embedded IPv4?

-éric

---

From: Gert Doering <[email-masked]>
Date: Thu, 2 Sep 2010 10:36:23 +0200

Hi,

> Is 6to4-with-anycast the most deployed form of 6to4?

As far as I understand, yes.

> last time that I checked). 

Well, what shall I say...

$ host 6to4.ipv6.microsoft.com
6to4.ipv6.microsoft.com has address 192.88.99.1

... this *is* the anycast relay address.

The IPv6 address returned points somewhere else, but is fairly meaningless
as that's never used by an encapsulating client.

Even if that would point to a managed relay, it won't help for the reply
packets "from the native IPv6 internet".  So the point is completely moot.

> One would guess that for managed 6to4 routers

Ditto: return packets.  As long as you use 2002:: addresses, you have no
control on the return path.

6rd uses different address space, and has full control over both directions.

Gert Doering
        -- NetMaster