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

From: Mark Andrews <[email-masked]>
Date: Mon, 09 May 2011 18:08:48 +1000

I just posted draft-andrews-v6ops-6to4-router-option-00.txt.
	Feedback welcome.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 9 May 2011 09:14:39 -0700

>        I just posted draft-andrews-v6ops-6to4-router-option-00.txt.

I don't see any reason to do this.

First: if you're an operator (and you probably are, since you have the power
to control the DHCP server), you can already ensure 6to4 nodes to use your
relay by making sure that 192.88.99.1 is routed to it. You don't have to
change the OS stacks at all. Thus no RFC, no IANA DHCP option assignment, no
implementation changes on the server or on the client, ...

Second: this only makes the forward path more reliable. Reverse path is
still unreliable because it is not under your control (the server will just
pick whatever anycast 6to4 relay is closest to it). The only way to fix that
is by using 6rd or something like 6to4-PMT, which the WG did not adopt as an
item.

Third: as Erik says, you're really just reinventing a part of 6rd. More
specifically: RFC 3068-style anycast 6to4 is a special case of 6rd
where IPv4MaskLen = 0, 6rdPrefix = 2002::, 6rdPrefixLen = 16,
and 6rdBRIPv4Address = 192.88.99.1. From a protocol perspective, what you
are doing is adding the 6rdBRIPv4Address parameter, but not the other three
parameters, to 6to4. I think that instead of asking implementors to do this,
we should just ask them to implement 6rd instead.

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 9 May 2011 10:10:41 -0700

> we should just ask them to implement 6rd instead.

+1 for v6ops rejecting this work.  v6ops has spent way too much time
on the topic of 6to4.

6to4 is a speed bump and a distraction for people really doing IPv6.

The Advisory and Historic drafts should end the conversation on 6to4
so we can get back to the real work of deploying real IPv6.

Cameron

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: Tore Anderson <[email-masked]>
Date: Tue, 10 May 2011 08:11:35 +0200

* Lorenzo Colitti

> I don't see any reason to do this.

+1, opposed. Let's stop flogging the dead horse.

> we should just ask them to implement 6rd instead.

Fourth: You'll cement an increased failure rate because the IPv4
destination address in the outbound proto-41 packets won't match the
IPv4 source address in the inbound replies. That confuses stateful
devices in the path.

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com
Tel: +47 21 54 41 27

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 10 May 2011 09:24:57 +0200 (CEST)

On Mon, 9 May 2011, Lorenzo Colitti wrote:

> First: if you're an operator (and you probably are, since you have the power to control the DHCP server), you can already ensure 6to4 nodes
> to use your relay by making sure that 192.88.99.1 is routed to it. You don't have to change the OS stacks at all. Thus no RFC, no IANA DHCP
> option assignment, no implementation changes on the server or on the client, ...
> 
> Second: this only makes the forward path more reliable. Reverse path is still unreliable because it is not under your control (the server
> will just pick whatever anycast 6to4 relay is closest to it). The only way to fix that is by using 6rd or something like 6to4-PMT, which the
> WG did not adopt as an item.
> 
> Third: as Erik says, you're really just reinventing a part of 6rd. More specifically: RFC 3068-style anycast 6to4 is a special case of 6rd
> where IPv4MaskLen = 0, 6rdPrefix = 2002::, 6rdPrefixLen = 16, and 6rdBRIPv4Address = 192.88.99.1. From a protocol perspective, what you are
> doing is adding the 6rdBRIPv4Address parameter, but not the other three parameters, to 6to4. I think that instead of asking implementors to
> do this, we should just ask them to implement 6rd instead.

I completly agree with Lorenzo. Operators don't need 6to4 router option: 
if they need it they can emulate better with 6rd.

Best Regards,
 		Janos Mohacsi

---

From: Mark Andrews <[email-masked]>
Date: Tue, 10 May 2011 16:49:04 +1000

> > is by using 6rd or something like 6to4-PMT, which the WG did not adopt as a

6to4-PMT was designed to keep 6to4 running in the presence of NATs
in the path.  This option is designed to disable 6to4 when there
are NATs in the path.

> > we should just ask them to implement 6rd instead.

6rd is useless without ISPs turning on 6rd.  6rd is basically
undeployable if the ISP doesn't supply the CPE equipment.  This
isn't to say CPE vendors shouldn't implement 6rd.

> IPv4 source address in the inbound replies. That confuses stateful

6to4 really isn't designed to be deployed on equipment behind a
firewall.  I suspect most of the cases where setting the source
address of the returned packet to the anycast address helps are in
networks where the operator would disable 6to4 if they had a control
which would do it.  This option provides such a control.

All the +1 are indicating that you want 6to4 to crash and burn
rather than have a graceful landing.  One can actually install a
under carriage while the plane is in flight.

Mark

---

From: Tore Anderson <[email-masked]>
Date: Wed, 11 May 2011 11:04:33 +0200

* Mark Andrews

> isn't to say CPE vendors shouldn't implement 6rd.

The same thing can be said about your draft. Without ISP and CPE
support, it is dead in the water. And, just like with 6RD, the only way
an ISP can be sure that your new functionality is used by all of its
customers is to be supplying the CPE to all of them.

> firewall.

Only in theory does reality match theory...

> I suspect most of the cases where setting the source

I would much rather recommend simply disabling it by default (i.e.
-historic). Implementing that change is much easier than implementing
your new DHCP option, and I believe it is therefore more likely to
actually happen. Also, it will help for access models that does not use
DHCP too, like PPP[oX].

> rather than have a graceful landing.

Not at all, I'd very much like to see 6to4 land as gracefully as
possible, which is why I support the -advisory draft.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 11 May 2011 22:14:53 +1000

> customers is to be supplying the CPE to all of them.

One of the prime uses of this would be to turn off 6to4.  Lots of
machines that run 6to4 could be updated by their users today to
check for 0.0.0.0 if they only had the code point.  This can be
done with end user configuration.

Adding this to a dhcpd.conf would allow it to tell any machine that
had been updated that 6to4 will not work with addresses returned
from this dhcp server.

	option 6to4rro code <tbd> ip-address;
	option 6to4rro 0.0.0.0;

You don't have to have upgrade everyone.  This option won't make
things worse.  It will just make things better.   It 10% of machines
get upgraded to understand this it is 10% less machines which are
causing problems.

> actually happen. Also, it will help for access models that does not use

Disabling by default is fine but it does not help mobile machines
which move networks.  These machines often have had 6to4 explicitly
enabled.  The network itself needs to be able to tell the machines
which are running 6to4 perfectly fine when connected to their home
ISP that 6to4 shouldn't be turned on when they connect to the network
at work, at university, at the local hotspot.  Expecting the user
to turn 6to4 on and off as they move is not reasonable.

The option does not say "turn 6to4 when you see me".  It says if
you are already wanting to do 6to4 there are routers you can use
or I don't want you to do 6to4.

Similarly 6rd shouldn't be turned on just because you see the 6rd
option.  The 6rd option is about how to do 6rd not whether you want
to do 6rd.

---

From: Ole Troan <[email-masked]>
Date: Wed, 11 May 2011 14:26:18 +0200

Mark,

> done with end user configuration.

if those users could be convinced to upgrade their system for this option,
why couldn't the also then be convinced to just disable 6to4?

[...]

> to turn 6to4 on and off as they move is not reasonable.

there appears to be some confusion here. the local network operator has no control over 6to4. that's one of the main problems with it.
the network operator can only affect the forward path, the remote-path is dependent on some unknown entity close to the destination.

why do have 6to4 been explicitly enabled on mobile machines? examples?
I've always thought 6to4 on by default as well-meaning vendors getting it wrong...
I rather want _no_ IPv6 than broken IPv6. but apparently there is a big use case I've missed where broken for 20% of the users is better than using IPv4 or no connectivity at all?

> option.  The 6rd option is about how to do 6rd not whether you want

well, depends. we'll specify this closer in the cpe-router-advanced document.
but normal behaviour on the WAN interface would be to include the 6rd DHCP option in the PRL list.

>> possible, which is why I support the -advisory draft.

I don't see how this gives a graceful landing either.
even though you now have an option stating that 'the local network supports 6to4' doesn't fix any of the other failure cases with 6to4.

cheers,
Ole

---

From: Mark Andrews <[email-masked]>
Date: Thu, 12 May 2011 00:47:36 +1000

In message <[email-masked]>, Ole Troan writ
es:
> >>=20
> >> support, it is dead in the water. And, just like with 6RD, the only =
> way
> >=20
> if those users could be convinced to upgrade their system for this =
> option,

Because they NEED IPv6 and 6to4 is the option the currently have
working.  The alternatives: 6rd needs ISP support.  Tunnel brokers,
similar issues to 6to4 (experienced most of them over the last 7
years of using such a tunnel) and will likely break with CGN.  Native
needs ISP support.

> there appears to be some confusion here. the local network operator has =
> no control over 6to4. that's one of the main problems with it.
> the network operator can only affect the forward path, the remote-path =
> is dependent on some unknown entity close to the destination.

And you just want to shoot down options which will give then some
control.

Sites that care about 6to4 reverse performance configure their dual
stack servers to do the encapsulation or install dedicated boxes
to do the encapsulation.  Neither of these is hard.

For most 6to4 users, who arn't sitting behind a firewall they don't
control, 6to4 works and the worst problem it usually causes is non
optimal routes.

> why do have 6to4 been explicitly enabled on mobile machines? examples?

You have a cable/dls modem.  You connect your laptop to it.  You
turn on 6to4 because you need it.  You suspend your laptop and go
to work, uni.  You open your laptop up.  It resumes from suspend
and gets a new lease.  6to4 is still on.

Not everyone has, needs or can afford a router.

This sort of thing has been documented as happening many times.

> I've always thought 6to4 on by default as well-meaning vendors getting =
> it wrong...

No. Thats just one way it gets turned on.

> I rather want _no_ IPv6 than broken IPv6. but apparently there is a big =
> use case I've missed where broken for 20% of the users is better than =
> using IPv4 or no connectivity at all?

You see Geoff 20% failure as saying 6to4 doesn't work.   I see the
20% failure rate as 20% of boxes with 6to4 on when it shouldn't be.

I know plenty of people who have been using 6to4 for years without
operational problem.  It isn't broken for them.  They get reasonable
performance sometime better than IPv4.

> >=20
> well, depends. we'll specify this closer in the cpe-router-advanced =
> document.
> but normal behaviour on the WAN interface would be to include the 6rd =
> DHCP option in the PRL list.

There is nothing wrong with requesting the information all the time.  It's
what you do with the information that in important.
 
> >>=20
> even though you now have an option stating that 'the local network =
> supports 6to4' doesn't fix any of the other failure cases with 6to4.
>
> cheers,
> Ole
>

---

From: Tore Anderson <[email-masked]>
Date: Wed, 11 May 2011 19:24:28 +0200

* Mark Andrews

>>> One of the prime uses of this would be to turn off 6to4.  Lots
>>> of machines that run 6to4 could be updated by their users today
>>> to check for 0.0.0.0 if they only had the code point.  This can
>>> be done with end user configuration.
>> 
>> if those users could be convinced to upgrade their system for this
>> option, why couldn't the also then be convinced to just disable
>> 6to4?
> 
> working.

I'm really confused as to how you mean your proposed DHCP option will
help these users. If the user NEEDS 6to4 to work, yet is in a network
where 6to4 DOESN'T work, how does the DHCP server informing him of that
fact make him any less SOL?

> The alternatives: 6rd needs ISP support.  Tunnel brokers, similar
> issues to 6to4 (experienced most of them over the last 7 years of
> using such a tunnel) and will likely break with CGN.  Native needs
> ISP support.

I find it very difficult to imagine a network environment where 6to4 can
succeed but where a brokered proto-41 tunnel fails. Do you have any
examples?

Then there's also the tunnel brokers that use UDP-based encapsulation
protocols (e.g. SixXS' AYIYA) which pierce nicely through NATs. A user
that NEEDS IPv6 to work, no matter what network he connects to, would be
much better off using something like that instead of 6to4, IMO.

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 11 May 2011 10:36:18 -0700

> fact make him any less SOL?

being informed that you're hosed has some merit, you will however intuit
it rather quickly, more to the point does the device handing out
addresses always know when you're hosed?

> much better off using something like that instead of 6to4, IMO.

client vpn's are a pretty well established technology for dealing with
the local or remote network access restrictions. they are of coruse
contingent on the client having access to s network where the policy
suites their needs on which they can anchor the vpn endpoint.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 12 May 2011 09:21:29 +1000

> fact make him any less SOL?

Please re-read what is needed.  It is *IPv6* not 6to4.  6to4 is the
means.

There are networks with IPv6, maybe even supplied by another 6to4
router which does have a path carved through the firewall for it
or it the external router, but machines connecting to it don't stop
trying to establish their own 6to4 tunnels.  We have had plenty of
reports of that happening as well.

You can filter protocol-41 to everyone but yourself.  You then
filter the IPv6 traffic inbound on the virtual interface after
de-encapsulating it.  For outbound you do the filtering before you
encapsulate it.  You have 6to4 address working fine internally but
you can't bring up a different 6to4 tunnel.

> succeed but where a brokered proto-41 tunnel fails. Do you have any

Look at all the complaints about 6to4.   Most of them are applicable
to brokered tunnels.  Remote tunnel endpoint, overloaded tunnels,
no dead tunnel detection, non responsive tunnel administators.  HE
have been good to me on that last point but there are other tunnel
brokers that arn't anywhere near as responsive.  Remember most of
the tunnel brokers arn't being paid to run the service.

> much better off using something like that instead of 6to4, IMO.

And there are firewall administrators that filter that as well.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 12 May 2011 09:39:45 +1000

> addresses always know when you're hosed?

Not always but there are plenty of network admins that would like
to have a switch they could use to turn off 6to4 on machines
connecting to their networks.  They would set the switch even if
it only stopped a single machine they would think that the 3 seconds
it took to install the option was worth it.

Then when they chase down the next machine that doesn't support the
options they could tell it owner that they need to upgrade to
something that does support the option.

Lots of the problem machines here do have automated maintenance
paths or no cost upgrade paths.

DHCP server vendors could default this to 0.0.0.0 when returning
RFC 1918 addresses.  Belts and braces network administration.

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 11 May 2011 17:01:20 -0700

On May 11, 2011 4:39 PM, "Mark Andrews" <[email-masked]> wrote:
> connecting to their networks.

You speak for them? And they want to support  sufficient upgrades to
process  this "switch"?

 They would set the switch even if

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 11 May 2011 17:12:22 -0700

> it took to install the option was worth it.

Actually, if I were such a network admin, I think I would prefer my machines
to turn off 6to4 unconditionally, not based on some DHCP option. Either way
it's a code upgrade...

---

From: Mark Andrews <[email-masked]>
Date: Thu, 12 May 2011 10:45:39 +1000

In message <[email-masked]>, Cameron Byrne writes:
> --e0cb4e6ff23f9ca84104a308e37b
> Content-Type: text/plain; charset=ISO-8859-1
> 

I've got 10 year old DHCP servers and DHCP clients that can support
this once a code point is allocated.  This is configuration file
change for those servers and clients that is no harder than changing
a nameserver address.   They were designed to support the addition
of new code points.  They were designed to allow the user to change
what happens when a lease request is answered.

Not all servers and clients can do this but a large percentage of
them can.

Mark

---

From: Mark Andrews <[email-masked]>
Date: Thu, 12 May 2011 11:14:53 +1000

> to turn off 6to4 unconditionally, not based on some DHCP option. Either way

It's minor configuration changes in many cases.  Real life configs.
The "default 6to4rro 192.88.99.1;" isn't strictly needed as this
is a outbound 6to4 interface for return traffic, however if you
were using 6to4 for forward traffic it sets the address of the
anycast relay.

Old:
interface "sis0" {
        request subnet-mask, broadcast-address, time-offset, routers,
                domain-name, domain-name-servers, ntp-servers;
        require subnet-mask, domain-name-servers;
        supersede domain-name "dv.isc.org isc.org rc.vix.com";
        prepend domain-name-servers 127.0.0.1;
        send dhcp-lease-time 7200;
}

octets=`echo $new_ip_address | sed 's/\./ /g'`
ifconfig stf0 inet6 2002:`printf %02x%02x:%02x%02x $octets`:: \
        prefixlen 16 alias anycast link0
route add -inet6 2002:: -prefixlen 16 ::1
route change -inet6 2002:: -prefixlen 16 ::1 -ifp stf0

New:
option 6to4rro code <tbd> ip-address;
interface "sis0" {
        request subnet-mask, broadcast-address, time-offset, routers,
                domain-name, domain-name-servers, ntp-servers, 6to4rro;
        require subnet-mask, domain-name-servers;
        supersede domain-name "dv.isc.org isc.org rc.vix.com";
        prepend domain-name-servers 127.0.0.1;
        send dhcp-lease-time 7200;
	default 6to4rro 192.88.99.1;
}

if [ -n "$new_6to4rro" -a "$6to4rro" != 0.0.0.0 ]
then
	octets=`echo $new_ip_address | sed 's/\./ /g'`
	ifconfig stf0 inet6 2002:`printf %02x%02x:%02x%02x $octets`:: \
		prefixlen 16 alias anycast link0
	route add -inet6 2002:: -prefixlen 16 ::1
	route change -inet6 2002:: -prefixlen 16 ::1 -ifp stf0
elif [ "$6to4rro" = 0.0.0.0 ]
then
	route delete -inet6 2002:: -prefixlen 16
	ifconfig stf0 down
fi

---

From: Mark Andrews <[email-masked]>
Date: Thu, 12 May 2011 12:26:25 +1000

In message <[email-masked]>, Lorenzo Colitti writes:
> --000e0cd28fee3ba47d04a3090c56

Remember having 0.0.0.0 turn 6to4 off is mainly for when the machines
arn't yours or they move.  If the machines are yours then turning
6to4 off unconditionally is definitely a option.

---

From: Doug Barton <[email-masked]>
Date: Wed, 11 May 2011 19:37:11 -0700

> the tunnel brokers arn't being paid to run the service.

My experience (albeit limited, anecdotal, etc.) has been universally 
positive with both HE and sixxs. I've had minor speed-bumps with both, 
and got the help I needed from either the vendor, the community forums, 
or both.

I also feel compelled to make the periodic repetition of a point I've 
made before, no one _needs_ IPv6 right now. There is no IPv6-only 
content, and there isn't going to be for years to come.

Having read some of the discussion about this on NANOG I would also take 
this a step further and say that if somehow we *do* reach a point where 
IPv6-only content is widespread enough to create an actual need for 
reliable IPv6 tunnels that the market will cause them to be created.

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Mark Andrews <[email-masked]>
Date: Thu, 12 May 2011 13:08:33 +1000

> content, and there isn't going to be for years to come.

You may not need IPv6 but I do need IPv6.  Different people, different
needs.

---

From: Doug Barton <[email-masked]>
Date: Wed, 11 May 2011 20:29:39 -0700

> You may not need IPv6 but I do need IPv6.  Different people, different

And neither of us fall into the "average user" category.

Regardless, you made the point earlier, the need (such as it is) is 
IPv6, not 6to4.

--

---

From: Michael Newbery <[email-masked]>
Date: Thu, 12 May 2011 15:49:57 +1200

On 12/05/2011, at 2:37 PM, Doug Barton wrote:
> I also feel compelled to make the periodic repetition of a point I've made before, no one _needs_ IPv6 right now. There is no IPv6-only content, and there isn't going to be for years to come.
> 

That mischaracterizes the Internet as being just the Web (or a few content providers and many content consumers). The Internet has, and has always had, a significant amount of direct communication.

Right now there is a tiny amount of users with only IPv6. If you want to communicate with these users: play an on-line game, VoIP (including video), etc. then YOU need IPv6. Right now.

As the number of such users increases, the need for IPv6 in the general Internet will increase, and not in a linear fashion. LTE for instance is about to magnify the amount of IPv6 users dramatically. Very soon, NOT "years to come", there will be enough of the Internet (end users) that are accessible only via IPv6 that to be connected to the Internet will mean having an IPv6 address. At which point, the hosting sites will start to think about saving costs by not bothering with IPv4.

Imagine "Irritated Avians 2" comes out with a cooperative direct network play mode. You enjoy playing it, and want to match up with your friend on Berizontal LTE. But you can't because YOUR ISP doesn't support IPv6---but your other friend next door with a different ISP has no such problems...

---

From: Tore Anderson <[email-masked]>
Date: Thu, 12 May 2011 07:54:17 +0200

* Mark Andrews

> Please re-read what is needed.  It is *IPv6* not 6to4.  6to4 is the

You wrote that the users in question could not disable 6to4 because they
NEEDED IPv6, implying that 6to4 was the only usable option avaliable to
them. It follows logically, then, that they NEED 6to4. If they don't,
your reason why they cannot disable it makes no sense.

In any case, the talk about non-6to4 based connectivity, whether
brokered tunnels or native, is a red herring. Your draft is about 6to4,
after all.

So, If I have understood correctly, the arguments you made in the
message I was replying to, were:

1) There are users that have an absolute need for IPv6 connectivity
2) Use of 6to4 is the only solution available to them
3) They will therefore override a 6to4-default-off setting
4) They are possibly completely happy using 6to4
5) Making 6to4 «crash and burn» would be a disservice to these user

They way I see it, your arguments seems to support Brian's -advisory
draft, and perhaps also oppose Ole's -to-historic draft, instead of
actually make the case for why your own draft is a good idea.

At least I fail to understand how your draft will have any effect on
these 6to4 users you're talking about. Either 1) they are already
happily using 6to4 and will be able to continue to do so without any new
DHCP options, or 2) they're in a network where 6to4 doesn't work and
they'll be without their much-needed IPv6 connectivity, regardless of
any new DHCP options.

How exactly does your draft benefit the 6to4 users you're concerned
about? Or, if the draft doesn't benefit them, how are their problems
relevant to the discussion?

Best regards,

---

From: Mark Andrews <[email-masked]>
Date: Thu, 12 May 2011 17:33:53 +1000

> your reason why they cannot disable it makes no sense.

Take 2 networks.  1 with IPv6, one without IPv6.  You have a machine
that is moving between the two networks.  You don't want the machine
to use 6to4 on the first.  You do want it to use 6to4 on the second.
Expecting the user to remember to enable and disable 6to4 everytime
the machine moves is 1. unrealistic and 2. error prone.   Having
network 1 tell the machine to not use 6to4 as part of the process of
connecting to the network prevents the error condition.

> brokered tunnels or native, is a red herring. Your draft is about 6to4,

When the default reply is "Just kill 6to4" you need to justify why
the alternatives don't work or are just as bad.

> they'll be without their much-needed IPv6 connectivity, regardless of

The problem is that you are failing to take into account that
machines move between networks.  DHCP is about configuring the
machine for the network it is currently connecting to.

> relevant to the discussion?

It benefits them by allowing the machine to correctly configure
itself to the properties of the network it is connecting to.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 12 May 2011 11:02:06 +0200

>connecting to the network prevents the error condition.

So, write a script that hooks to the dhcp client and enables 6to4 only if 
the IPv4 address is in a certain range. Problem solved.

---

From: Tore Anderson <[email-masked]>
Date: Thu, 12 May 2011 13:18:09 +0200

* Mark Andrews

> connecting to the network prevents the error condition.

Okay. I think I understand now. The point is to make the failure mode
when in networks that don't support 6to4 somewhat more smooth in that
the 6to4 interface won't come up at all, instead of becoming a black
hole. Correct?

In that case, I can see that there is some value in it, but I don't
think that benefit justifies the effort. There's a lot of
implementations out there that needs to be changed, CPE/hosts and
networks needs to implement both in order for it to be effective. I
think it's simply not worth while to begin such an endeavour at this
point in time, considering that you're not actually solving the user's
main problem, i.e., no IPv6 connectivity.

That said, I'd be more inclined to support a draft, or perhaps a new
section in the -advisory document, that instructed the hosts/CPEs to
probe the reliability of the outbound relay. For example by sending an
encapsulated ICMPv6 packet to 192.88.99.1 with IPv6 SRC=DST=[it's own
6to4 address]. If it doesn't come back, then don't enable the 6to4
interface. This would, as far as I can tell, accomplish the same
smoother failure mode as your draft when in networks that don't support
6to4, without requiring explicit support from the ISP (or the use of
DHCP for that matter).

Furthermore, I understand that major vendors such as Apple and Microsoft
have implemented, or are about to implement, [something similar] to this
already.

> the alternatives don't work or are just as bad.

Your draft isn't about the killing or not killing of 6to4, so again,
this is a red herring.

Best regards,

---

From: Mark Andrews <[email-masked]>
Date: Thu, 12 May 2011 22:05:51 +1000

In message <[email-masked]>, =?iso-8859-1?Q?R=E9m
i_Despr=E9s?= writes:
> 
> Le 10 mai 2011 =E0 08:49, Mark Andrews a =E9crit :
> > ... 6rd is basically
> > undeployable if the ISP doesn't supply the CPE equipment. =20
> 
> See lists.cluenet.de/pipermail/ipv6-ops/2011-January/004711.html
> Some vendor CPE's do support 6rd.

Which is good and I encourage more.
 
> Regards,
> RD=

---

From: Pekka Savola <[email-masked]>
Date: Thu, 12 May 2011 15:48:44 +0300 (EEST)

> have implemented, or are about to implement, [something similar] to this

Nit-pick:

The relay is not supposed to get address where both the source and 
destination are from 2002::/16 prefix, so it could legitimately drop 
it. (That's recommended in RFC3964.) I'm not sure if relays in general 
do this or not.

But in any case, the test e.g. done by MS has at least 5-6 years of 
deployment experience behind it and it accomplishes almost the same 
thing -- also not requiring any support.

FWIW, I agree that recommending a connectivity test procedure is much 
better than providing a DHCP option.  I'm not adamant on adding a 
recommendation to do the test prodecure in -advisory (as I can see the 
argument that even this is not worth the effort at this point), but I 
think it would probably be a good idea to do so.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Philip Homburg <[email-masked]>
Date: Thu, 12 May 2011 15:11:06 +0200

In your letter dated Thu, 12 May 2011 21:59:21 +1000 you wrote:
>
>In message <[email-masked]>, Philip Homburg writes:
>Which doesn't work in the general case.  

This is just a user interface issue. If it happens a lot you may want a 
widget on the desktop to inform you about the status of 6to4. No big deal.
It is not that different from connecting to a wifi network.

>It also doesn't help when
>ISP's start putting clients behind CGN's which wern't before.

It works perfectly for that case. Instead of a global address you now get an
RFC-1918 address and 6to4 stays disabled.

>Address don't indicate properties of networks.  

No, but (non-1918) addresses tend to correlate very well with location. And
if you want to enable 6to4 only in a specific location, then doing pattern 
matching on the IP address works very well.

>It also doesn't
>help when the ISP gives you different addresses each day.

Then don't put a single address there but match on a pattern.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 12 May 2011 07:35:31 -0700

> to use 6to4 on the first.  You do want it to use 6to4 on the second.

No, you don't. If you are an operator, you *never* want to use 6to4 -
because it's not reliable. You may be able to control for firewalls in your
network and install relays 0ms away from every client, but there is still
the major problem that the reverse path is completely unknown and may be
going through random third-party relays that could on a whim decide to drop
or rate-limit your traffic. And there's nothing you can do about it because
it depends on which BGP announcement the other side happened to choose. This
is worse than native traffic because at least there you have some control in
the form of prepending and so on.

Giving your users connectivity you can't control is assuming responsibility
for bad service without being able to fix it, and this is something that
operators tend to avoid like the plague because they don't like support
costs.

---

From: james woodyatt <[email-masked]>
Date: Thu, 12 May 2011 08:07:00 -0700

On May 12, 2011, at 7:35 AM, Lorenzo Colitti wrote:
> 
>  If you are an operator, you *never* want to use 6to4 - because it's not reliable.

This isn't strictly true.  If you're an IPv4-only operator of a public access network, then you probably want to make 6to4 available for users who are willing to put up with the unreliability or who have specific destinations in mind, like their home networks, that are known to have a reverse path relay.

I assume this is why we don't feel inclined to publish a phase-out plan for 6to4.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 12 May 2011 08:43:23 -0700

On May 12, 2011 8:07 AM, "james woodyatt" <[email-masked]> wrote:
> This isn't strictly true.  If you're an IPv4-only operator of a public
access network, then you probably want to make 6to4 available for users who
are willing to put up with the unreliability or who have specific
destinations in mind, like their home networks, that are known to have a
reverse path relay.
> I assume this is why we don't feel inclined to publish a phase-out plan
for 6to4.

James, are you speaking on behalf of an operator who cannot speak for
themselves?

There seems to be a misconception that consumers want or care about ipv6.
They don't. Yet, real ipv6 is needed to *replace* ipv4 for engineering
reasons.

IMHO, 6to4 is a techies trick. What Mark has published is not for the
benefit of the internet at large, it is a clever script that is more fit for
a FREEBSD users group.

I have yet to encounter anything beyond boutique network operators that
believe 6to4 is a supportable technology that has a place in the current and
going forward reality of this network of netkworks.

Cb

---

From: james woodyatt <[email-masked]>
Date: Thu, 12 May 2011 08:53:16 -0700

On May 12, 2011, at 8:43 AM, Cameron Byrne wrote:

> James, are you speaking on behalf of an operator who cannot speak for themselves?

Yes.  Well, actually more like one that can't be bothered to speak for itself, but yes, the operator in question has deliberately made sure that 6to4 works while native IPv6 is not yet available, and they did this for the reason I mentioned in my previous message.  Is that *really* so hard to imagine?

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 12 May 2011 08:59:36 -0700

On Thu, May 12, 2011 at 8:53 AM, james woodyatt <[email-masked]> wrote:

> Yes.  Well, actually more like one that can't be bothered to speak for
> itself, but yes, the operator in question has deliberately made sure that
> 6to4 works while native IPv6 is not yet available, and they did this for the
> reason I mentioned in my previous message.  Is that *really* so hard to
> imagine?

They can do this now to placate the tiny percentage of their customers that
asks for IPv6. But once content moves to IPv6 they will have to stop,
because their customers will complain that websites are slow and unreliable.

---

From: james woodyatt <[email-masked]>
Date: Thu, 12 May 2011 09:08:49 -0700

On May 12, 2011, at 8:59 AM, Lorenzo Colitti wrote:

> But once content moves to IPv6 they will have to stop, because their customers will complain that websites are slow and unreliable.

Yes, but content won't be moving to general availability over IPv6 for a long, long time.

We can safely assume it will not happen before dual-stacked IPv6/IPv4 retail service is ubiquitous.  Every major content provider I've asked about this says they cannot foresee when they will be willing to make their content generally available over IPv6 without DNS whitelisting.

It therefore makes sense for IPv4-only operators to deploy 6to4 relays for those people who use actively use 6to4 in full knowledge of its unreliability for transporting general web content.  Deploying the 6to4 relays and making sure that protocol 41 works, as I-D.ietf-v6ops-6to4-advistory recommends, doesn't actively make anything worse for content providers, you know.

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 12 May 2011 09:43:54 -0700

> Yes, but content won't be moving to general availability over IPv6 for a long, long time.

This is the chicken and egg problem that requires white-listing to
exist... and a self fulfilling prophecy.

I believe for networks that work for it, they will have a substantial
volume (<50% on  a per user basis in my mobile case) of IPv6 content
available within 12 months.  World IPv6 day should provide some
meaningful data.

Cameron

---

From: Daniel Roesen <[email-masked]>
Date: Thu, 12 May 2011 23:30:09 +0200

On Tue, May 10, 2011 at 09:24:57AM +0200, Mohacsi Janos wrote:
> I completly agree with Lorenzo. Operators don't need 6to4 router option: if 
> they need it they can emulate better with 6rd.

+1

I fail to see the user base fully understanding the basic problems of
6to4 and happy to accept them conciously (as James described), yet
unable to just use "reliable" 6RD instead.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0

---

From: Mark Andrews <[email-masked]>
Date: Fri, 13 May 2011 09:34:19 +1000

In message <[email-masked]>, james woodyatt wri
tes:
> > But once content moves to IPv6 they will have to stop, because their custom
> ers will complain that websites are slow and unreliable.
> 
> We can safely assume it will not happen before dual-stacked IPv6/IPv4 retail 
> service is ubiquitous.  Every major content provider I've asked about this sa
> ys they cannot foresee when they will be willing to make their content genera
> lly available over IPv6 without DNS whitelisting.
> 
> It therefore makes sense for IPv4-only operators to deploy 6to4 relays for th
> ose people who use actively use 6to4 in full knowledge of its unreliability f
> or transporting general web content.  Deploying the 6to4 relays and making su
> re that protocol 41 works, as I-D.ietf-v6ops-6to4-advistory recommends, doesn
> 't actively make anything worse for content providers, you know.

It also make sense for dual stack operators to deploy 6to4 reverse
relays for their customers that don't have the skills to self deploy.
If a operator has IPv6 only customers then those customers can't
self deploy a 6to4 reverse relay so the ISP should be doing it for
them.

You don't have to announce reverse relays.  You just need to put
them where they can see the IPv6 traffic that needs to be encapsulated.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 13 May 2011 13:50:05 +1000

> unable to just use "reliable" 6RD instead.

Because you can't get from 6to4 to 6rd without ISP support.  The
ISP needs to get themselves connected via IPv6.  They need to setup
6rd border routers (hard to come by).  They need to advertise them.
The customer also needs to get 6rd compatible equipement (hard to
come by).

---

From: Roger Jørgensen <[email-masked]>
Date: Fri, 13 May 2011 07:55:28 +0200

> In message <[email-masked]>, Daniel Roesen writes:
<snip>
> The customer also needs to get 6rd compatible equipement (hard to

That ISP don't have IPv6 would have worried me 10years ago, maybe even 5.
Right now, in the current time with IPv4 running out fast that should not be
an issue. ISP has to move to IPv6 sooner or later and the faster customers
"force" them to do so the better it is.

Change or be gone really...

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Gert Doering <[email-masked]>
Date: Fri, 13 May 2011 20:59:56 +0200

Hi,

On Thu, May 12, 2011 at 09:08:49AM -0700, james woodyatt wrote:
> Every major content provider I've asked about this says they cannot 
> foresee when they will be willing to make their content generally 
> available over IPv6 without DNS whitelisting.

So you haven't spoken to Tore recently?

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: Daniel Roesen <[email-masked]>
Date: Sat, 14 May 2011 15:43:11 +0200

> It's minor configuration changes in many cases.  Real life configs.

In real life, most customers run on Windows based platforms, not using
ISC DHCP client.

Regards,
Daniel

---

From: Daniel Roesen <[email-masked]>
Date: Sat, 14 May 2011 15:52:58 +0200

> In real life, most customers run on Windows based platforms, not using

To add to myself, don't forget all the CPE implementations which never
see automatic updates.

Best regards,
Daniel

---

From: james woodyatt <[email-masked]>
Date: Sat, 14 May 2011 10:08:51 -0700

On May 14, 2011, at 6:52 AM, Daniel Roesen wrote:
> 
> don't forget all the CPE implementations which never see automatic updates.

Or the ones that will never see any attention to 6to4 in their updates after complying with the recommendations in I-D.ietf-v6ops-6to4-to-historic.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 16 May 2011 09:17:23 +1000

In message <[email-masked]>, Pekka Savola write
> think it would probably be a good idea to do so.

Test procedures are for temporary errors.  You withdraw the default
route and/or return network unreachable.  You continue to announce
the 6to4 prefixes.

The DHCP option is for permanent errors.  You tear down / never
establish the 6to4 interface and stop / don't start announcing 6to4
prefixes on the other interfaces.

---

From: Pekka Savola <[email-masked]>
Date: Mon, 16 May 2011 08:44:12 +0300 (EEST)

> prefixes on the other interfaces.

I fail to see the distinction.  While I can see it'd would be more 
optimal, if the test procedure was not run every 5 minutes or 24 hours 
(per host), it still achieves essentially the same thing.  Actually 
more -- with DHCP option, even if an IP address is provided, the 
implementation won't test that it actually works.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 16 May 2011 16:24:59 +1000

In message <[email-masked]>, Pekka Savola write
> implementation won't test that it actually works.

If 6to4 was only a single host then there is little distinction but
6to4 is not a just single host.  It is a border router, RAs, PD and
a whole lot more.  6to4 gives you a /48 not a /128.  What you do to
a network is different to what you do to a single host.

Mark

---

From: Philip Homburg <[email-masked]>
Date: Mon, 16 May 2011 11:38:54 +0200

>a network is different to what you do to a single host.

So what you should do (at least what I would do) is to not advertise anything
related to 6to4 until you have verified that the relay is reachable.

Similarly, I would stop advertising anything related to 6to4 as soon as the
connection to the relay is broken. If it is a transient error then there will
be just a bit of packet loss, if it is a longer lasting error then eventually
all addressen and routes will timeout and hosts will revert to IPv4.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 16 May 2011 08:50:18 -0700

Recently, there was discussion regarding how to discern
an ISATAP IPv6 address from a native IPv6 address, and an
implication that this may have some bearing on RFC3484
address selection. The correct answer is that an IPv6
address is an ISATAP address IFF it is assigned to an
ISATAP interface, i.e., a node can tell that its IPv6
source address is ISATAP by examining the interface to
which the address is assigned. Therefore, there is a way
for a node to prefer native IPv4 over ISATAP even though
an IPv6 address cannot be identified as ISATAP solely by
examining the prefix.

This policy is manifested in RFC3484, Section 6, Rule 7:

   "Rule 7:  Prefer native transport.
   If DA is reached via an encapsulating transition mechanism (e.g.,
   IPv6 in IPv4) and DB is not, then prefer DB.  Similarly, if DB
   is reached via encapsulation and DA is not, then prefer DA.

      Discussion:  6-over-4 [15], ISATAP [16], and configured tunnels
      [17] are examples of encapsulating transition mechanisms for which
      the destination address does not have a specific prefix and hence
      can not be assigned a lower precedence in the policy table.  An
      implementation MAY generalize this rule by using a concept of
      interface preference, and giving virtual interfaces (like the
      IPv6-in-IPv4 encapsulating interfaces) a lower preference than
      native interfaces (like ethernet interfaces)."

Although the Discussion shows a "MAY", the rule itself
asserts that the native transport is to be preferred over
an encapsulating transport. Hence, there is no particular
reason for an ISATAP host to avoid placing AAAA records in
the DNS for any of its SLAAC-derived ISATAP addresses.

Fred
[email-masked]

---

From: Dmitry Anipko <[email-masked]>
Date: Mon, 16 May 2011 12:47:51 -0700

Hello Fred,

Rule 7 does help to distinguish native IPv6 versus ISATAP. 

However, rule 7 doesn't help to distinguish ISATAP from native IPv4: the rule 7 is only considered after rule 6, and per rule 6 ISATAP is already prioritized higher than IPv4 due to the default prefix policy table precedence values. As a result, rule 7 won't apply in that case, and ISATAP is preferred over IPv4.

I'm not weighing in on whether that is a problem or not, but trying to clarify what I believe the raised concern was.

Thank you,
Dmitry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Templin, Fred L
Sent: Monday, May 16, 2011 8:50 AM
To: [email-masked]; [email-masked]
Subject: RFC3484, Section 6, Rule 7 and ISATAP

Fred
[email-masked]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Mark Andrews <[email-masked]>
Date: Tue, 17 May 2011 10:54:48 +1000

> related to 6to4 until you have verified that the relay is reachable.
 
The option is design to be used on RENEW as well as initial requests.
It's designed for the operator of the network to tell the clients
of the network that 6to4 will no longer work and you should stop
running 6to4.

> connection to the relay is broken.

Define "broken".  I've had to work over IPv4 which dropped packet
but I didn't pull the IPv4 addresses off the machines just because
some packets got lost.

> If it is a transient error then there will

So you would have host continuly renumbering themselves for temporary
errors.

This group has grossly over reacted to 6to4 and mixed up different
6to4 issues.

You have 6to4 failing due to being run in a environment where it
will not even start up.

You have machines moving from places where 6to4 works to places
where 6to4 cannot work.

You have machines moving from places where 6to4 works to places
where 6to4 still works but shouldn't be started for policy reasons.

You have networks that move from working 6to4 to non working 6to4
due to the introduction of things like CGN.

And you have potential load based issues which quite frankly are
completely solvable including return path issues.

Now from the http server operator perspective these are all the
same but from a engineering perspective (and we all claim to be
engineers here) they are very different problems which should be
addresses seperately.

Additionally none of the issues here are unique to 6to4.  With any
multi-homed service with multiple addresses you will have cases
where one address is reachable and one isn't.  This problem will
continue with IPv6 native though to a lesser degree as IPv4 and
IPv6 are treated seperately in the network so you will get failure
modes where one or other of these is unreachable and the other
isn't.  Applications don't have to behave badly when this occurs.

If the W3C was to certify browsers and part of that certification
required that the browser operated well in the presence of partially
unreachable multi-homed servers how long would you think it would
take the browser vendors to fix their products.

Removing this problem from most applications is not hard.  It just
requires someone to spend the time to do it.  Personally I thing
this would make a good project for Google's Summer of Code.  Have
a open source OS vendor manage someone to go through their package
collection and fixup the connection code with the idea to submit
the changes back upstream.  Once you have done it a couple of times
it doesn't take long to do the next one.

The OS vendor gets a better product fast as they can incorporate
the fixes directly into their package system and the fixes trickle
down to the rest of the community.

Mark

---

From: Philip Homburg <[email-masked]>
Date: Tue, 17 May 2011 11:43:57 +0200

>of the network that 6to4 will no longer work and you should stop

I understand that you are just trying to push your DHCP option, without
considering any other alternative, but this line of reasoning is unlikely
to get you anywhere.

So, take for a example the message you just replied to. I described how I
would use the reachability test to prevent 6to4 from being advertised and
how a lack of reachability would cause those advertisements to timeout.

So the only thing (in that scenario) a network operator has to do is block 
access to the 6to4 anycast address.

Now you may not like that mechanism, but is completely pointless to keep adding
all kinds of new features to your solution in the hope that you find a niche
where it might be used.

Get real, an operator who is going to dynamically (with RENEW) turn 6to4
support on and off?

>but I didn't pull the IPv4 addresses off the machines just because

So, just read what I wrote in my previous message, reflect on how IPv6
neighbor discovery works, and you will see that this not what is going to
happen.

>So you would have host continuly renumbering themselves for temporary

So of course not, because addresses are valid much longer than a short
transient error.

>You have 6to4 failing due to being run in a environment where it

That is not failure from this group's perspective. 

>You have machines moving from places where 6to4 works to places

So, do a reachbility check and you will be fine. Or, just enable 6to4
when the IPv4 address is in a specific range. That requires a small change
to the user interface, but allows the user to sepcify what he wants.

>where 6to4 still works but shouldn't be started for policy reasons.

So, block access to the anycast address and you are back to the previous case.

>due to the introduction of things like CGN.

If it is done properly, then the RFC-1918 address will prevent 6to4 from 
starting anyhow. Otherwise, the reachability check will prevent 6to4 from
being used. Otherwise, the new IPv4 address will be outside the range for
which 6to4 is enabled (assuming the UI changes are in place).

>completely solvable including return path issues.

That's why this group wants to discourage the use of 6to4.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 17 May 2011 23:30:06 +1000

In message <[email-masked]>, Philip Homburg writes:
> >> So what you should do (at least what I would do) is to not advertise anyth
> in
> >g

The other alteratives don't meet the operational needs.  Once you have
suceeded in getting 6to4 up and you have already advertised a prefix
you have cross a point which you really shouldn't go back across unless
you know that you won't recover.
 
> how a lack of reachability would cause those advertisements to timeout.

They are not mutually exclusive.
 
> access to the 6to4 anycast address.

Which is stupid.  Having to infer something is ALWAY going lead to wrong
results.

> all kinds of new features to your solution in the hope that you find a niche

I haven't added anything new.  0.0.0.0 for off has been there from the
begining.  What DHCP returns can and does change.

 
> >> be just a bit of packet loss, if it is a longer lasting error then eventua
> ll
> >y

Which requires the use to know what address he his going to get and
if he know that he doesn't need dhcp.
 
> So, block access to the anycast address and you are back to the previous case

And you are back to guessing.
 
> which 6to4 is enabled (assuming the UI changes are in place).

Which is all supposition and guessing

---

From: Philip Homburg <[email-masked]>
Date: Tue, 17 May 2011 15:59:39 +0200

>you know that you won't recover.

That is something you just pull out of thin air. If you fail to receive a
valid Router Advertisement for a long enough time, you have to expire your
addresses. 

If you fail to reach the DHCP(v4 or v6) server in time to renew your leases
you have the same problem.

But I also gave a solution for manual configuration. Which of course you
ignore.

>Which is stupid.  Having to infer something is ALWAY going lead to wrong

Yes always. That's why duplicate address dectection is in the specs, that's
why we have neighbor unreachability detection. It is all going to fail.

>if he know that he doesn't need dhcp.

You know, a long time ago somebody came up a notation for a range IP
addresses. Very cool.

>> So, block access to the anycast address and you are back to the previous cas
>e
>> .
>

Guessing? If you get a reply from a 6to4 relay, then access to that relay is
not blocked by NAT or firewall. Doesn't sound like guessing to me.

>Which is all supposition and guessing

I'll just stop here.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 18 May 2011 13:28:42 +1000

For those that like the test procedures please define a standard
test procedure which will work with any 6to4 relay.  Asking CPE
vendor to test without describing how to do the test really isn't
up to snuff.  You also find that some of the "obvious" test methods
don't work.

ICMPv6 echo requests don't work as the relays are often configured
to not respond to them.  HE's don't respond which are the only ones
I can test against.

Constructing a encapsulated packets from yourself(ipv6) to
yourself(ipv6) and sending them to the relay results in them to be
dropped by anti-spoof ingress filters which FreeBSD turns on by
default in the virtual interface driver (stf).  You can see them
if you use a packet filter but that really doesn't test that they
will make it past the host firewall which is one of the things
people are complaining about.  Adding exceptions also doesn't test
the general case.  I'm also slightly suprised that the relay accepted
encapsultate IPv6 packets to 2002::/16 as they should be able to
be delivered directly.  That being said it provides about the only
test path.

You can forge a IPv6 packet from somewhere not inside your network
but what IPv6 source address should you use?  ULA, should be being
filtered.  I did try the relay's address (2002:c058:6301::) which
worked but I'm really suprised that it did as it means that there
wasn't a anti-spoof ingress filter installed for 2002:c058:6301::/48.

For testing I was encapsulating icmp6 echo reply packets using
socket(AF_INET, SOCK_RAW, IPPROTO_IPV6) and making sure they were
delivered to a icmp6 socket, i.e. socket(AF_INET6, SOCK_RAW,
IPPROTO_ICMPV6).  UDP packets would have also worked but I wanted
a IPv6 packet that would not generate a IPv6 error.

Note 6rd will have these issues as well as it doesn't have well
defined BR reachability detection.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 May 2011 20:56:46 -0700

On Tue, May 17, 2011 at 8:28 PM, Mark Andrews <[email-masked]> wrote:

> test procedure which will work with any 6to4 relay.

Send a TTL=1 packet to one of those IPv6-only sites whose existence you cite
as a reason to keep 6to4 around, and see if you get an unreachable back. Or
send a TTL=1 DNS query to the root servers.

Given the average quality of the relays out there, something like that it
going to be a hell of a lot more reliable than actually using the 6to4 relay
itself for two-way connectivity.

Not that trying to fix 6to4 makes any sense anyway, IMO. I'm just providing
some token opposition every now and then in order to ensure that silence is
not taken as agreement. :-)

---

From: Mark Andrews <[email-masked]>
Date: Wed, 18 May 2011 14:12:56 +1000

In message <[email-masked]>, Lorenzo Colitt
> send a TTL=1 DNS query to the root servers.

Which is subject to ICMPv6 rate limiting.  i.e. it won't work if all the
6to4 sites using the relay do this.

---

From: "John Mann (ITS)" <[email-masked]>
Date: Wed, 18 May 2011 14:38:57 +1000

Hi,

On 18 May 2011 13:56, Lorenzo Colitti <[email-masked]> wrote:

> Send a TTL=1 packet to one of those IPv6-only sites whose existence you
> cite as a reason to keep 6to4 around, and see if you get an unreachable
> back. Or send a TTL=1 DNS query to the root servers.
>

I would like to see a standard set of tests that could be used to work out
if 6to4 gateways and relays are working.
[ And try to avoid the debates about DHCP options, -historic, 100%
reliability of tests etc etc. ]
- Where is the 6to4 gateway or relay?
- Is it up?
- Is it passing packets?
- Is the network working but the remote end is down?

The test definition would include packet dumps,
a tool that performs the test - ping, *traceroute*,  hping3, sendip, C or
Perl program, ...
whatever command line or binary blob input is required, and
what output is expected for success and failure.

Test taxonomy may be something like:

For normal 6to4:
   client <-> gateway1 <-> gateway2 <-> server
client and server are in 2002::/16

T1: client -> gateway1
T2: client -> gateway2
T3: client -> server
[ tests from server are same as tests from client ]
[ client may be same as gateway1, server may be same as gateway2 ]

For Anycast 6to4:
    client -> gateway1 -> relay1 -> server -> relay2 -> gateway1 -> client
client is in 2002::/16, server is in normal 2000::/3
[ client may be same as gateway1 ]

T11: client -> gateway1
T12: client -> relay1
T13: client -> server
T14: server -> relay2
T15: server -> gateway1
T16: server -> client

===
Has someone made such a list of tests before?
Defined any of these tests?

Thanks,
    John

---

From: Mark Andrews <[email-masked]>
Date: Wed, 18 May 2011 15:07:06 +1000

In message <BANLkTi=[email-masked]>, "John Mann (IT
> Defined any of these tests?

If the client is not the gateway you are limited to standard IPv6
test tools.  If the client is the gateways then you can add IPv4
test tools.

It wouldn't be to hard to do a 6to4 traceroute which send a IPv6
hlim=1 packet with changing IPv4 ttls until you get a ICMPv6 time
exceeded message and then start counting that up.  You would need
the ability to set the IPv6 hop limit independent of the IPv4 ttl
to get around a relay that isn't sending back ttl exceeded.

Mark

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 17 May 2011 22:45:37 -0700

On Tue, May 17, 2011 at 9:12 PM, Mark Andrews <[email-masked]> wrote:

> cite

So no worse than the return 6to4 relay, which could be subject to rate
limiting of all packets. Real story, real outage.

---

From: Ole Troan <[email-masked]>
Date: Wed, 18 May 2011 08:00:11 +0200

Mark,

> defined BR reachability detection.

section 8 of RFC5969.

Ole

---

From: Mark Andrews <[email-masked]>
Date: Wed, 18 May 2011 16:53:22 +1000

In message <[email-masked]>, Lorenzo Colitt
i writes:
> --000e0cd6ecd812e4e704a3866732

And how many relays rate limit encapsulation vs rate limit icmp?
1 vs almost all.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 18 May 2011 17:08:27 +1000

In message <[email-masked]>, Ole Troan writ
> > defined BR reachability detection.

And I tried the described technique with 6to4.  It runs into problems
with standard anti-spoofing filters.  The packet gets delivered,
de-encapsultated then dropped.  I don't expect 6rd to not have
anti-spoofing ingress filtering.

"Constructing a encapsulated packets from yourself(ipv6) to
test path."

Mark

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 18 May 2011 00:08:11 -0700

> And how many relays rate limit encapsulation vs rate limit icmp?

I see no data on either side of that assertion.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 18 May 2011 10:39:21 +0300 (EEST)

> And how many relays rate limit encapsulation vs rate limit icmp?

The fact that if you run a 6to4 relay, you may need to increase ICMPv6 
rate limits is well known.  On some systems, this is by default 
100pps.  On some others, it is by default 1000pps.  1000pps is the 
minimum that works.  When running a public relay, I think I used 
5000pps myself.

Dozens of millions Windows boxes have been sending ICMPv6 Echo 
Requests with Hop Count=1 for 5+ years.  This creates a lot of traffic 
on the relays.  This is already an established procedure.

All in all, this works just fine.

(FWIW, Windows implementations are supposed to send only one probe per 
24 hours and additional ones when you change network settings. There 
have been observations of more frequent probes.  But the amount is 
still manageable.)

---

From: Mark Andrews <[email-masked]>
Date: Wed, 18 May 2011 18:29:25 +1000

In message <[email-masked]>, Pekka Savola write
> on the relays.  This is already an established procedure.

And this is documented where? 

http://go6.net/ipv6-6bone/v6ops/minutes/IETF-59-Seoul/6to4-stats.pdf
Mentions it in "Weird Things Seen on the Wire".

---

From: Ole Troan <[email-masked]>
Date: Wed, 18 May 2011 11:50:13 +0200

Mark,

> anti-spoofing ingress filtering.

section 9.2, RFC5969

we are going off topic now. you stated that "6rd will have these issues as well...".
I claim that it will not, as connectivity tests are described in the protocol specification.

cheers,
Ole

---

From: Pekka Savola <[email-masked]>
Date: Wed, 18 May 2011 13:25:29 +0300 (EEST)

> Mentions it in "Weird Things Seen on the Wire".

Which part? The procedure is described in my "Observations of IPv6 
Traffic on a 6to4 Relay" paper that can be found easily from Google. 
AFAIK, there no official description of this from Microsoft.

ICMP rate-limiting issues have been discussed e.g. here:

http://lists.cluenet.de/pipermail/ipv6-ops/2008-February/001708.html
http://www.gossamer-threads.com/lists/nanog/users/129609
draft-ietf-v6ops-6to4-advisory-01 Section 4.4 point 6

---

From: Mark Andrews <[email-masked]>
Date: Wed, 18 May 2011 21:12:23 +1000

In message <[email-masked]>, Ole Troan writ
es:
> we are going off topic now. you stated that "6rd will have these issues =
> as well...".
> I claim that it will not, as connectivity tests are described in the =
> protocol specification.
> 
> cheers,
> Ole=

Machines other than the BR in the 6rd domain can't spoof as the
ipv4/ipv6 source address must match.  The BR however can be a source
of spoofed traffic as there are no restrictions placed on the ipv6
source addresses recieved from the BR.  Any sane implemation wouldn't
be depending in the ISP having done ingress filtering and would do
its own ingress filtering.

Mark

9.2.  Receiving Rules

   In order to prevent spoofing of IPv6 addresses, the 6rd BR and CE
   MUST validate the embedded IPv4 source address of the encapsulated
   IPv6 packet with the IPv4 source address it is encapsulated by
   according to the configured parameters of the 6rd domain.  If the two
   source addresses do not match, the packet MUST be dropped and a
   counter incremented to indicate that a potential spoofing attack may
   be underway.  Additionally, a CE MUST allow forwarding of packets
   sourced by the configured BR IPv4 address.

   By default, the CE router MUST drop packets received on the 6rd
   virtual interface (i.e., after decapsulation of IPv4) for IPv6
   destinations not within its own 6rd delegated prefix.

---

From: Ole Troan <[email-masked]>
Date: Wed, 18 May 2011 13:58:11 +0200

Mark,

[...]

> its own ingress filtering.

I don't get your point. there is no source address spoofing in the mechanism described in rfc5969.

cheers,
Ole

---

From: Mark Andrews <[email-masked]>
Date: Wed, 18 May 2011 23:51:35 +1000

In message <[email-masked]>, Ole Troan writ
es:
> I don't get your point. there is no source address spoofing in the =
> mechanism described in rfc5969.
> 
> cheers,
> Ole

There is nothing in RFC5969 to prevent someone outside of the 6rd
domain spoofing machines inside the 6rd domain.

You send a packet from <6rd-prefix><target-v4suffix><m1> to
<6rd-prefix><target-v4suffix><m2>.  The ISP may or may not be
filtering this.  The BR isn't required to filter it.  The CE is not
instructed to filter it.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 18 May 2011 16:19:22 +0200

>filtering this.  The BR isn't required to filter it.  The CE is not

I guess everybody knows that is not smart to rely on IP addresses for
authentication. But apart from that, it makes sense for the CE to filter out
its own prefix (just like you would do for native). It also makes sense for
an ISP to deploy ingress filtering everywhere (including traffic handled
by the 6rd relay). Otherwise, customers can make a mess of your network.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 19 May 2011 00:26:16 +1000

> by the 6rd relay). Otherwise, customers can make a mess of your network.

Indeed.  The problem is that when you do that sort of filtering you
also block the test traffic to determine if the BR is running.

Mark

---

From: Philip Homburg <[email-masked]>
Date: Wed, 18 May 2011 16:36:16 +0200

>also block the test traffic to determine if the BR is running.

I don't see any problem for the BR: it receives a packet from the IPv4 address
assigned to the CE and the IPv6 packet also has a source address in the
customer's prefix.

It is true that for the CE, you have to capture the packet from BR before
ingress filtering rules drop it. But that is something you already see in
the lab when you first turn the device on. Doesn't strike me as a big problem.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 19 May 2011 01:14:28 +1000

> the lab when you first turn the device on. Doesn't strike me as a big problem

Then you havn't understood part of the firewall issues with 6to4
are equally applicable to 6rd and that adding exceptions for BR
tests doesn't help.  It's quite easy to not allow anything except
the BR tests through be accident when you start adding exections.

Mark