Subject: Re: [v6ops] I-D ACTION:draft-ietf-v6ops-6to4-advisory-01.txt

From: Mark Andrews <[email-masked]>
Date: Mon, 09 May 2011 13:53:40 +1000

Better still would be to specify a default in dhclient.conf if the
administrator wants to use the anycast address as a fallback and
adjust dhclient-exit-hooks appropriately.

Mark

/etc/dhclient.conf:
option 6to4-router code <tbd> = ip-address ;
request subnet-mask, broadcast-address, time-offset, routers,
	domain-name, domain-name-servers, ntp-servers, 6to4-router;
default 6to4-router 192.88.99.1;
 
/etc/dhclient-exit-hooks:
if [ -n "$new_6to4_router" && "$new_6to4_router" != 0.0.0.0 ]
then
 	ether=`ifconfig $interface ether | sed -n s/ether//p | sed 's/:/ /g'`
 	local=`printf 2e%s:%sff:%s%s:%s%s $ether`
 	octets=`echo $new_ip_address | sed 's/\./ /g'`
 	stfaddress=2002:`printf %02x%02x:%02x%02x $octets`::$local
 	ifconfig stf0 inet6 $stfaddress prefixlen 16 alias
 	ifconfig stf0 inet6 | grep -v $stfaddress |
 		sed -n 's/inet6/ifconfig stf0 delete /p' | sh
 	octets=`echo $new_6to4_router | sed 's/\./ /g'`
	route add inet6 default 2002:`printf %02x%02x:%02x%02x $octets`::
	# configure internal interfaces.
elif [ -n "$new_6to4_router" && "$new_6to4_router" = 0.0.0.0 ]
then
 	route delete -inet6 default
 	ifconfig stf0 down
 	# deconfigure internal interfaces.
fi
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Ray Hunter <[email-masked]>
Date: Mon, 09 May 2011 10:39:46 +0200

-1 as it is proposed but +0.2 with a tweak.

In the ideal world this would have been baked into the original 
deployment design from the very beginning, especially allowing the DHCP 
"OFF" option plus making the default behavior OFF. Then it might have 
been a really great idea.

Erm. But now? No thanks. 6to4 is enabled by default in Windows 7 and has 
already been deployed on many desktops. The timing is just wrong. So an 
option of having to place a "0.0.0.0" to turn off 6to4 via an option in 
DHCP that is acted upon by a few nodes that have implemented a new 
standard, whilst all other nodes ignore it, is just the wrong way around 
IMHO.

This change as proposed would potentially put 6to4 even further out of 
the control of the administrators of the transport network for the few 
nodes that are going to support it. One wiseguy host admin flips one 
switch in DHCP and the whole transport network goes haywire switching to 
IPv6 over tunnels rather than native IPv4.

At least the route to the well-known anycast address can be filtered and 
controlled by the guys controlling the transport network (as already 
clearly advised in the draft).

I can tell you that I'm spending a ratio of approx 40:1 of my time 
worrying about how to stop inappropriate or unexpected deployment of 
transition mechanisms messing up a perfectly good native IPv4 service 
than I am worrying about how to deploy native IPv6.

These automatic tunnels should just be "off" by default.  There are an 
awful lot of major enterprises considering a "Bring you own device" 
policy and then running virtual desktops on top of those (or using cloud 
computing). That means a lot of end nodes on the corporate networks may 
be configured with default settings and may not even be controllable via 
Active Directory as per today. That also means network transport admins 
may have very limited tooling to be mandate / configure the 
configuration of the end nodes. All of which suggest that the default 
should be a "fail safe" so that the administrators of the transport 
network can remain in control.

However, if you also mandate OFF as the default when adding this DHCP 
option, and so only a positive non NULL reply would enable 6to4 e.g..

/etc/dhclient.conf:
option 6to4-router code<tbd>  = ip-address ;
request subnet-mask, broadcast-address, time-offset, routers,
	domain-name, domain-name-servers, ntp-servers, 6to4-router;

if [ "$new_6to4_router" != 0.0.0.0&&  "$new_6to4_router" != NULL]
then
	...
else
	...
fi

Then it well might be a marginal improvement, but of course would break 
existing all deployments unless they also tweaked their DHCP repsonse to 
include the option. So it's a bit of a no win situation (hence the +.2 
in my vote.)

But please don't make these transition mechanisms any worse / more 
complicated to control than they already are now that they're out there.

All IMVHO [and bear in mind that I am just the messenger relaying what 
these IT strategy guys are considering]

>
> Blocking protocol 41*by ISPs*  is bad practice.  Blocking protocol
> 41 without sending back destination unreachable by enterprises is
> bad practice.
>
>    
Got it. Is is possible to make this small tweak and add the "destination 
unreachable" portion? I completely missed the significance of "silently" 
even though I read that phrase many times.

best regards,
RayH

Mark Andrews wrote:
> option 6to4-router code<tbd>  = ip-address ;
> if [ -n "$new_6to4_router"&&  "$new_6to4_router" != 0.0.0.0 ]
> then
> elif [ -n "$new_6to4_router"&&  "$new_6to4_router" = 0.0.0.0 ]
> then

---

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

In message <[email-masked]>, Ray Hunter writes:
> This is a multi-part message in MIME format.
> --------------090500050302010506000404
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
> 

Only if the clients are requesting the option.

> clearly advised in the draft).

Which really doesn't help all that much.
 
> network can remain in control.

So the enterprise just sets "6to4-router 0.0.0.0;" and any client
that supports this disables itself when connected to the enterprise
network and re-enables itself when connected at home.

> --------------090500050302010506000404
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: 7bit
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
>   <meta content="text/html; charset=ISO-8859-1"
>  http-equiv="Content-Type">
> </head>
> <body text="#000000" bgcolor="#ffffff">
> -1 as it is proposed but +0.2 with a tweak.<br>
> <br>
> been a really great idea.<br>
> <br>
> Erm. But now? No thanks. 6to4 is enabled by default in Windows 7 and
> has already been deployed on many desktops. The timing is just wrong.
> So an option of having to place a "0.0.0.0" to turn off 6to4 via an
> option in DHCP that is acted upon by a few nodes that have implemented
> a new standard, whilst all other nodes ignore it, is just the wrong way
> around IMHO. <br>
> <br>
> switch in DHCP and the whole transport network goes haywire switching
> to IPv6 over tunnels rather than native IPv4.<br>
> <br>
> At least the route to the well-known anycast address can be filtered
> and controlled by the guys controlling the transport network (as
> already clearly advised in the draft).<br>
> <br>
> than I am worrying about how to deploy native IPv6.<br>
> <br>
> These automatic tunnels should just be "off" by default.&nbsp; There are an
> policy and then running virtual desktops on top of those (or using
> cloud computing). That means a lot of end nodes on the corporate
> networks may be configured with default settings and may not even be
> controllable via Active Directory as per today. That also means network
> transport admins may have very limited tooling to be mandate /
> configure the configuration of the end nodes. All of which suggest that
> the default should be a "fail safe" so that the administrators of the
> transport network can remain in control.<br>
> <br>
> <br>
> <br>
> option, and so only a positive non NULL reply would enable 6to4 e.g..<br>
> <br>
> <pre wrap="">/etc/dhclient.conf:
> option 6to4-router code &lt;tbd&gt; = ip-address ;
> if [ "$new_6to4_router" != 0.0.0.0 &amp;&amp; "$new_6to4_router" != NULL]
> then
> 	...
> else
> 	...
> fi
> 
> </pre>
> existing all deployments unless they also tweaked their DHCP repsonse
> to include the option. So it's a bit of a no win situation (hence the
> +.2 in my vote.)<br>
> <br>
> complicated to control than they already are now that they're out there.<br>
> <br>
> these IT strategy guys are considering]<br>
> <br>
> <blockquote type="cite">
>   <pre wrap=""><!---->
> Blocking protocol 41 <b class="moz-txt-star"><span class="moz-txt-tag">*</spa
> n>by ISPs<span
>  class="moz-txt-tag">*</span></b> is bad practice.  Blocking protocol
>   </pre>
> </blockquote>
> Got it. Is is possible to make this small tweak and add the
> "destination unreachable" portion? I completely missed the significance
> of "silently" even though I read that phrase many times. <br>
> <br>
> best regards,<br>
> RayH<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> <br>
> Mark Andrews wrote:
> <blockquote cite="mid:[email-masked]"
>  type="cite">
>   <pre wrap="">Better still would be to specify a default in dhclient.conf if
>  the
> option 6to4-router code &lt;tbd&gt; = ip-address ;
> if [ -n "$new_6to4_router" &amp;&amp; "$new_6to4_router" != 0.0.0.0 ]
> then
> elif [ -n "$new_6to4_router" &amp;&amp; "$new_6to4_router" = 0.0.0.0 ]
> then
>   </pre>
> </blockquote>
> <br>
> </body>
> </html>
> --------------090500050302010506000404--

---

From: Ray Hunter <[email-masked]>
Date: Mon, 09 May 2011 15:25:01 +0200

It sounds like I'm the only paranoid on this list.

Mark Andrews wrote:
> In message<[email-masked]>, Ray Hunter writes:
>    
And knowing the record of IPv6 implementations so far, the default is 
"on" and "yes, go for it!" (which I very much regret)
> Which really doesn't help all that much.
Yes it does. It prevents automatic tunnels from messing up QoS and 
latency of native IPv4 connectivity used in production networks.

If the tunnel can't be built to the anycast address it ain't going to 
cause uncontrolled trombone-ing in the network.

You guys seem to work on the fact that everything is homogeneous, 
networks are small, and 100% of admins know what they are doing.

I prefer a few more fail-safes. DNS and DHCP servers are generally 
managed by the network group in enterprises. DHCP and DNS content is 
generally not managed by the same guys who manage the transport network. 
In fact an awful lot of content is auto-generated nowadays (via AD)

> network and re-enables itself when connected at home.
Remember in RFC3484 (out in the wild today on hundreds of thousands if 
not millions of desktop machines) 6to4 is preferred over IPv4 (that 
changes in RFC3484 bis, but how many nodes implement that today in 
production? precisely zero AFAIK.) And then you have yet another 
dependency / combination of things that could go wrong .... node 
implements 6to4 router config detection via DHCP before implementing 
RFC3484 bis.

This is yet another thing for an enterprise manager to "turn off" in 
order to maintain control. And this one I find hard to guarantee. How do 
I grant rights to an inexperienced DHCP admin to be able to add custom 
DHCP entry for turning on some useful feature like setting up a local 
print server or back up server, and yet prevent them from adding some 
content that is potentially disruptive for the normal business 
operations of a corporation?

Besides which, the flip side is also true. Since when has DHCP been 
universally deployed and controlled?

I presume this has to be a DHCP (v4) option, because at the point the 
record is requested there (may/will) be no IPv6 connectivity available 
to a DHVPv6 server. Otherwise what's the benefit of 6to4? Chicken and egg.

Once again firewalls and CPE routers creep in. The DHCP server behind a 
firewall is often run on the CPE, and not centrally. So the end hosts 
would probably not even see the central ISP setting. Or will that all 
change in IPv6 and home users have to start trusting an ISP's DHCP and 
DHCPv6?

All of this auto-configuration stuff is nice and works well in small and 
homogeneous environments. But my experience in practice tells me 
otherwise. Especially during a major transition. Remember Appletalk II 
ZIP storms? I do.

As I wrote to Fred Templin, we wouldn't design an aircraft with features 
that deployed major functionality or configuration changes automatically 
based on some remote and opaque dependency on external content. I 
wouldn't want the wheels to go down automatically if the aircraft 
thought it was at 100ft up, because the altimeter may be broken and the 
aircraft may be at 30000 feet and flying at 600 mph. Why are we assuming 
that this is a good idea to implement these features in network 
protocols, where the deployment is at least 2 steps removed from IETF 
control (implementers / developers and then network managers)?

We shouldn't be in the business of second guessing the guys who are 
managing the transition of the transport network.

best regards,
RayH

---

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

You make a assumption that the presence of the option indicates
that the client SHOULD perform 6to4.  It does not.

The option tells the client HOW to perform 6to4 and if it SHOULD
disable 6to4.  It does NOT tell the client to perform 6to4.

Mark

---

From: Ray Hunter <[email-masked]>
Date: Mon, 09 May 2011 16:58:27 +0200

You appear to be claiming to be agnostic as to whether 6to4 is enabled 
or not.

Your code fragment example that you attached to your original post would 
appear to have indeed assumed that 6to4 is on by default, unless of 
course there is some tweak elsewhere to detect the admin status of 6to4 
(which I couldn't find in all of maybe 5 minutes looking on my own local 
Linux box, so I don't discount it really exists). Hence my assumption 
that 6to4 was "on" by default, which is why I suggested the 
$new_6to4_router" != NULL edit.

So I think it was maybe a reasonable assumption to make at the time, 
given the context of the discussion and the information available so 
far. Apologies if that wasn't your intention.

I'd personally be delighted if your proposal would go one stage further 
and suggest that the default for 6to4 is "off", although you may argue 
that is not your problem and is outside your scope.

As a guy who transitions operational networks, I can't afford that 
luxury of selectivity. I can't close my eyes to the reality that 6to4 is 
"on" by default in many cases, and also to the reality that RC3484 is 
also the norm out there today (at least on some popular OS's), no matter 
how attractive another tweak in an RFC looks.

So the base line assumption of any new proposal should be made on the 
assumption that "6to4" is already "on" and we should heed the 
Hippocratic oath of "do no harm" IMHO. Adding yet another option for 
giving a different addresses to a 6to4 router is potentially harmful in 
my book, because the transport network manager can no longer filter them 
out and stay in control of the network (apparently all of protocol 41 
can't blocked, as then ISATAP would be disabled too if they ever wanted 
to use that protocol [I don't]). Yours and others perception may be 
different.

But most of all, I'd be delighted if we stopped trying to tweak a 
protocol (6to4) that we apparently all agree is broken, and instead 
started debating how to roll out and improve and support native IPv6.

I have seen precious few posts on the v6ops list on how to do that. And 
at the minute I am really struggling to see what tools are available to 
the typical transport network manager that supply sufficient 
granularity, together with an associated scalable  administrative model, 
to be able to remain in control of the IPv4 network and guarantee 
ongoing production, whilst at the same time introducing IPv6 gradually.

Good luck with developing your proposal further.

regards,
RayH