Subject: [v6ops] new draft: draft-andrews-v6ops-6to4-router-option-00.txt

From: <[email-masked]>
Date: Mon, 9 May 2011 06:55:01 -0700 (PDT)

A new draft has been posted, at http://tools.ietf.org/html/draft-andrews-v6ops-6to4-router-option. Please take a look at it and comment.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 09 May 2011 16:34:18 +0200

In your letter dated Mon, 9 May 2011 06:55:01 -0700 (PDT) you wrote:
>A new draft has been posted, at http://tools.ietf.org/html/draft-andrews-v6ops
>-6to4-router-option. Please take a look at it and comment.

The first question I have is why would anyone want to use an address other
than the RFC-3068 defined one?  What's the point? 

I think it is important to evaluate 6ot4 in the context of the measurements
done by Geoff Huston and others. And using a different IPv4 address for the
relay is most likely just going to break things.

The second question is the value of disabling 6to4 by returning 0.0.0.0. By
itself that sounds like a useful feature. But features are not for free. 
You have implement them, document them, test them. There may have unexpected
security or other operational implications, etc.

So assuming that in future 6to4 is disabled by default. The only thing this
feature does override the user's preference to turn 6to4 on. I don't think it
makes any sense to implement this feature.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 09 May 2011 19:11:52 +0200

In your letter dated Tue, 10 May 2011 01:40:20 +1000 you wrote:
>In message <[email-masked]>, Philip Homburg writes:
>There is lots of value in not using the anycast relay routers.

I think you may have to add some text to your draft about this. My ISP runs an
6to4 relay for their clients and I absolutely no idea why 6to4 would work
better if they would run that relay on another address.

>> done by Geoff Huston and others.
>
>The point is to use a relay that is local to the client (mostly
>eliminating the transmission delays causes by using a relay router)
>that is being run by someone the client has a contract with (allows
>faults to be reported).  Both of these are issues identified by
>Geoff and others.

A local relay is just of matter of injecting a route to the anycast address
in the local IGP. Why would that be easier if run it on another address? Well
then you don't have to add a route to the local IGP. Instead you have to make
sure that each and every 6to4 implementation on your local net supports the
new DHCP option.

>> And using a different IPv4 address for the relay is most likely just
>> going to break things.
>
>This is a unsubstanciated claim.

I don't have a specific reference, but i.r.c. at some point Geoff Huston 
reported a difference in failure rates of around 5% depending on whether the
relay router on the return path would use the anycast address as source 
address or not.

Sounds alike a good argument for sticking to the anycast address.

>Lots of equipment moves between networks.  In one network 6to4 will
>work and in another 6to4 won't work or it causes operational problems
>for the network when the 6to4 is misconfigured (rogue RAs which
>blackhole IPv6 traffic).  In the first you use the option to optimise
>traffic flows.  In the latter you set the option to 0.0.0.0 to
>disable 6to4.  The equipment can safely move between networks without
>requiring reconfiguration everytime it moves.

If you allow random hosts to orginate RAs then you have a big problem anyhow.
So I think we can ignore that.

6to4 doesn't work behind NAT. So, for this to be an issue you have to have 
devices that move between at least two networks that all have routable IPv4
addresses. Sounds like a corner case to me.

IMHO, effort would be much better spend making sure that a 6to4 implementations
honors ICMP destination unreachables for the anycast address or by
implementing the TTL=1 hack for verifying the actual reachability of the 
relay.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 10 May 2011 01:40:20 +1000

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Erik Kline <[email-masked]>
Date: Mon, 9 May 2011 19:16:38 +0000

Even with this attempt to help make the "first hop" more reliable, it
will not and cannot address the return path failures.  This is
fundamental to the 2002::/16 aspect of 3068.

Geoff's numbers for failures when the server sees SYNs from 2002::/16
client addresses are remarkable, and don't satisfactorily diminish
even when the return route to 2002::/16 is on the server sending the
SYN-ACK (i.e. it encapsulates it directly).

The *return path* problem is what 6rd fixes.  Optimizing the client
proximity to its relay is insufficient to make the mechanism useful at
scale for IPv6 transition.

Let's let -advisory and -historic do their thing.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 May 2011 10:07:57 +1200

On 2011-05-10 02:34, Philip Homburg wrote:
> And using a different IPv4 address for the

Not so. The issue with not using the anycast address for return packets
to the 6to4 user is that a stateful firewall will drop them, because
the outbound packet was sent to the anycast address. As long as the
outbound and return packets use the *same* IPv4 address for the relay,
a stateful firewall will not interfere.

   Brian

---

From: Mark Andrews <[email-masked]>
Date: Tue, 10 May 2011 11:11:14 +1000

In message <BANLkTinx5i=[email-masked]>, Erik Kline wri
tes:
> will not and cannot address the return path failures.

The option performs two roles.

1.  It identifies a local 6to4 relay.  Nothing prevents the operator
    putting 192.88.99.1 in the response however it you put 192.88.99.1
    in the response it is a indication that you are running the
    router and will accept fault reports.  ISPs have also indicated
    that they are not happy to deploy a router at 192.88.99.1 but
    would be willing to deploy a router at a different address.
    This provides a configuration mechanism for them to do so.

    It also provide a mechanism to distribute decapsulation load
    that is not dependent on the routing infrastructure.

2.  It provides a signal to 6to4 CPE/hosts that 6to4 will not work
    properly when you are connected to this network and that you
    should not use 6to4 when connected to this network.

> This is fundamental to the 2002::/16 aspect of 3068.

Actually it is a fundemental part of RFC 3056.  See 5.2.2 Summary
of relay router configuration.

> SYN-ACK (i.e. it encapsulates it directly).

Which indicates that 6to4 is being attempted in environments where
it shouldn't be.  Being able to tell the CPE/host not to use 6to4
in those environments prevents the host attempting a IPv6 connection
using a 6to4 IPv6 address in the first place.  The day of week data
is enough to show that failures are due to environment and not load.

> scale for IPv6 transition.

Actually I've yet to see evidence that it cannot scale.  I've seen
plenty of evidence that 6to4 is being used in environments where
it will not work for reasons that have nothing to do with scaling.

Getting 6to4 to scale is simply a matter of deploying enough 6to4
relay routers.  The fact that there is little change when the server
does encapsulation of the reply traffic indicates that there isn't
currently a scaling issue.  If there was as scaling issue then
performing local encapsulation would address it.

---

From: Gert Doering <[email-masked]>
Date: Tue, 10 May 2011 09:39:25 +0200

Hi,

> a stateful firewall will not interfere.

And how exactly will you get everyone else's relay to use this specific
source address?

Gert Doering
        -- NetMaster
-- 
did you enable IPv6 on something today...?

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: Philip Homburg <[email-masked]>
Date: Tue, 10 May 2011 09:15:30 +0200

>a stateful firewall will not interfere.

I have no idea how that is supposed to work. Suppose an ISP is using
203.0.113.1 as the 6to4 relay address. How is a remote relay on the
return path supposed to know that it has to put 203.0.113.1 in the source
address instead of the regular 6to4 anycast address?