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

From: Ray Hunter <[email-masked]>
Date: Wed, 04 May 2011 12:17:34 +0200

Here are my comments.

On the whole an excellent document. There's obviously been a lot of hard 
work put in on preparing this one so far.

I think perhaps it might be even better if there was some factual list 
included in the introduction on the assumptions that were made when 6to4 
(via anycast) was specified and implemented. It doesn't have to 
apportion blame or flame anyone. Just straight facts.

Here's my take; I'm sure you can improve.

"The 6to4 transition mechanism can create an automatic tunnel to carry 
IPv6 traffic over a protocol 41 tunnel terminated at an IPv4 anycast 
address, and this assumes that:
IPv4 and IPv6 clouds within an enterprise or the public Internet are 
contiguous and transparent
there is a single universal boundary between the IPv4 and IPv6 clouds, 
and the precise crossing point between the two clouds is not important
the forward and reverse paths do not need to be symmetrical
protocol 41 is transported and supported in an equal manner to native 
IPv4 and native IPv6 encapsulations
the additional latency introduced by tunneling via a gateway is not 
operationally significant
waiting for a failed IPv6 session to time out is not operationally 
significant
any IPv6 connectivity (no matter what quality) is better than no IPv6 
connectivity (as of RFC3484 and not taking into account the proposed 
RFC3484 bis)
no need for explicit support of IPv4 NAT traversal
ease of use is paramount

It's easy to say with hindsight, but these assumptions do not always 
hold true in a number of real-world use cases, which may lead to 
operational difficulties. Users of 6to4 would be well-advised to check 
that these assumptions hold true in their particular use-case."

[this last sentence pending approval of moving 6to4 to historic?]

I also would like to comment on the following:

"Some operators, particularly enterprise networks, silently block 
Protocol 41 on security grounds. Doing this on its own is bad practice, 
since it contributes to the problem and harms any users who are 
knowingly or unknowingly attempting to run 6to4. "

Sure that might be considered bad practice, but maybe you should also 
include text saying that "allowing uncontrolled automatic tunneling 
across a firewall is also bad practice."

Equally I see no text in the "vendor issues" covering

"complete lack of support for protocol 41 in some devices",

or

"lack of feature equivalence in the majority of security devices, 
meaning that an organisation may not be able to effectively implement a 
similar security policy for native IPv6 and IPv6 over protocol 41 as it 
can for IPv4."

It's not about apportioning blame, but sometimes there's little choice. 
There are many people I know who would love to be able to control these 
boundaries effectively whilst transitioning to IPv6, but they just don't 
have the tools to do so, so the only course of action open to them is to 
disable much larger sets of functionality than they really want to. This 
isn't always just a knee jerk reaction. These people have auditors on 
their backs, and users shouting in their ears.

Similarly the other extreme is also true, the only way to enable 
protocol 41 on my home gateway (for 6in4) is to open up literally 
everything and forward all incoming traffic to a bastion host, and then 
control the traffic there.

As you rightly say later on "Enterprise operators who have complete 
administrative control of all end-systems may choose to disable 6to4 in 
those systems as an integral part of their plan to deploy IPv6."

I'm afraid that's the only logical choice most large enterprises have at 
the moment: disable all IPv6 transition mechanisms.

But keeping these comments to the scope of your proposal, I'd appreciate 
inclusion of some text in the vendor issues section on the subject of 
support in security devices.

Section 4.5 Page 14 "We assume that content providers and their ISPs 
have IPv6 connectivity, and that content servers are dual stacked."

That's a big assumption. Most corporate content is accelerated by Akamai 
today AFAIK, either directly or indirectly. Have you tried to buy an 
IPv6 capable content acceleration service today? Hopefully that'll 
change very very soon, but again vendor support (today, as I write).

What if this assumption does not hold true?

What if SLB IPv6-to-IPv4 takes off instead, as it is less painful?
Does that have any impact?
I think I know the answer, but I think a lot of people will ask the 
question.

There's a lot of very strong language in this section:

"To avoid this, there must be a locally positioned 6to4 relay."
"There must be a 2002::/16 route from the content server to the relay."
"Protocol 41 must not be filtered in the ISP's IPv4 network or firewalls."

page 15 "This is in fact trivial," Maybe technically speaking for 
someone with root access and your brain power, but not operationally 
speaking. Certainly it isn't trivial on a hosted web service.

I know this is only an informational RFC, but putting myself in the 
position of a first time reader of this section, I'm not really getting 
what I'm supposed to do, and what happens if I don't.

Can section 4.5 be made more advisory with achievable actions, and then 
listing the possible negative consequences of not complying? e.g. 
unpredictable latency, users experiencing noticeable delay as sessions 
fall back to IPv4. losing all your customers and going bankrupt?

p16 "A blanket recommendation to block Protocol 41 is not compatible 
with mitigating the 6to4 problems described in this document."

Suggest adding
", as it will cause operational problems for other protocols that also 
make use of protocol 41 tunneling and which do not suffer from the same 
problems as 6to4."

best regards,
RayH

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 09 May 2011 10:52:58 +1200

Ray,

Thanks for the review. Unfortunately the WGLC is technically over, so the
current version is now in AD review - no doubt there will be a new version
in due course. My comments below:

> apportion blame or flame anyone. Just straight facts.

I can't really speak for the author of RFC 3068 about the assumptions
(except where they are documentd in the RFC). Also, we had exactly the
opposite comment from Pekka Savola - he thinks there is too much text
about RFC 3056 and 3068. So IMHO we shouldn't add anything.
Nevertheless I basically agree with the points you make.

> across a firewall is also bad practice."

Personal opinion: I disagree. It all depends on the site or network
concerned and on its service model.

> "complete lack of support for protocol 41 in some devices",

Well, ideal routers and switches don't support *any* protocol
numbers, and that's as it should be - only devices acting as
tunnel end points should support the tunnel protocol.
> similar security policy for native IPv6 and IPv6 over protocol 41 as it

There's no doubt that digging into encapsulated packets is extra
work for a firewall, but that applies to all tunnels, not just to 6to4
and not even just to protocol 41. But going into that just seems
out of scope to me; advising firewall vendors what to do is a bit
of a third rail in the IETF anyway.

> control the traffic there.

Most home gateways are NATs anyway, so 6to4 doesn't work at all and
the issue doesn't arise. If you're fortunate enough to have a supply
of real IPv4 addresses inside the home, yes, you need a home router
than can do things right. In that case, the home is really behaving
like a mini-enterprise, isn't it?

> support in security devices.

Security devices should contain no 6to4-specific code,
and their protocol 41 behaviour is covered elsewhere.
> change very very soon, but again vendor support (today, as I write).

Well, Akamai have it up and running, ready for World IPv6 Day.
However, there is a gap in the draft: it should state that the
content provider recommendations also apply to CDN servers and
to HTTP caches. I need to add that.

> Does that have any impact?

Can you explain the scenario you have in mind?

> speaking. Certainly it isn't trivial on a hosted web service.

The word 'trivial' is badly chosen; 'straightforward' would be better.
The Geoff Huston reference talks about how to do it.

On a hosted service it's the hosting provider who should be doing this.
That should probably be clarified in the text.

> fall back to IPv4. losing all your customers and going bankrupt?

Well, that really applies to the whole draft - "If you don't do these
things, you will lose customer sessions, annoy users, and receive more
help desk calls." We generally don't dwell on business issues in
IETF documents, however. Don't you think the problem analysis
in section 3 covers this?

> make use of protocol 41 tunneling and which do not suffer from the same

It will also cause problems to successful users of 6to4, which is the
focus here.

Regards
    Brian

---

From: Mark Andrews <[email-masked]>
Date: Mon, 09 May 2011 09:46:32 +1000

One thing I havn't seen suggested yet is a DHCP option to distribute
local 6to4 outbound relay information.  This would allow ISP's to
to provide managed relays which arn't open to the world.  It would
also allow them to distribute load by adjusting which DHCP clients
get which relay.  There isn't a chance of the anycast route leaking.
Clients using using such 6to4 relays have a clear point of contact.

		<TBD><4><IPv4 address of relay>

The option could also be used to signal that 6to4 should not be used with
this IPv4 address by setting the value to 0.0.0.0.

		<TBD><4><0.0.0.0>		Disable 6to4.

Yes. I know this is very late in the 6to4 lifetime and there may be
limited implementation.
-- 
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 02:32:01 +0200

> Yes. I know this is very late in the 6to4 lifetime and there may be

Yeah, I think if you want to go down this road you're going to end up
at 6rd (the 6to4 client nodes will need a software refresh to get
knowledge of this DHCP option anyway).

It might be worth recommending that existing 6to4 implementors support
transitioning their code to 6rd in coming updates (I can't recall if
such a statement is in the draft already or not).

---

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

In message <[email-masked]>, Erik Kline wri
> knowledge of this DHCP option anyway).

Except 6rd requires kernel changes.  For many OS's this is just a
userland change which doesn't require new code to be compiled,
just minor tweeks to existing shell scripts and configuration files.

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;

/etc/dhclient-exit-hooks:
new_6to4_router=${new_6to4_router:-192.88.99.1}
if [ "$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.
else
	route delete -inet6 default
	ifconfig stf0 down
	# deconfigure internal interfaces.
fi

instead of adding the ipv6 default route you could start a daemon that
does reachability checks.

> such a statement is in the draft already or not).

Indeed.

---

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

In message <[email-masked]>, Brian E Carpenter writes:
> 
> On 2011-05-09 12:32, Erik Kline wrote:
> Yes, I rather wish we'd done that instead of RFC 3068.
> 
> Anyway, there will be no new protocol ideas in the -advisory draft.

Fine.  I'm just putting it out there. 
 
> 6rd is only for ISPs who can upgrade the CPEs, but yes.
> 
> Not in -advisory; anyway it seems more like a point for -historic.
> 
>    Brian
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 09 May 2011 14:00:35 +1200

Brian

---

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

If I'm too late, I'm too late. Fair enough. Apologies. Just attempting 
to suggest what I considered "improvements" on something that is 
already  fit for purpose. I shall try to be more timely in my comments 
in future (I sometimes get confused about the status in the IETF web 
tooling. Unless you follow every single email on the list it's sometimes 
not immediately obvious when comments are welcome, and certainly by 
which cut off date) Mea culpa.

As for whether blocking protocol 41 is "bad practice" or not: I defer to 
others e.g.

international standard ISO/IEC 27001:2005(E). I have not come across a 
single organization in my line of work that have interpreted that 
allowing automatic tunneling over protocol 41 over a network security 
zone boundary would be desirable in their security policy.

Microsoft, for example says protocol 41 to the Internet can and should 
be filtered. http://technet.microsoft.com/en-us/library/bb726956.aspx

Cisco say it is wrong to allow implicitly configured tunnels that are 
not under administrator control through the firewall 
www.cisco.com/.../02Eric_Vyncke_*Security*_*Best*_*Practices*.pdf

And last, but not least, http://www.rfc-archive.org/getrfc.php?rfc=5214

quote: There is a possible spoofing attack in which spurious 
ip-protocol-41packets are injected into an ISATAP link from outside.  
Since an ISATAP link spans an entire IPv4 site, restricting access to 
the link can be achieved by restricting access to the site; i.e., by 
having site border routers implement IPv4 ingress filtering and 
ip-protocol-41 filtering.

So if blocking protocol 41 is "bad practice" then the v6ops WG had 
better come up with a better way of authenticating and securing ISATAP 
tunnels.

I do worry that firewalls seem somehow to be considered to be "out of 
scope" or "off limits" for the IETF WG, whereas the reality is that they 
are absolutely everywhere today (fact of life), they're not going to go 
away, and they really could be the number one stumbling block for the 
vast majority of users transitioning to IPv6.

They're the elephant in the room, and I'm not afraid to point it out.

best regards,

RayH

---

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

> better come up with a better way of authenticating and securing ISATAP 

Blocking protocol 41 *by ISPs* is bad practice.  Blocking protocol
41 without sending back destination unreachable by enterprises is
bad practice.

> They're the elephant in the room, and I'm not afraid to point it out.

draft-ietf-v6ops-6to4-advisory-01.txt acknowledged that firewalls
exist and that block is reasonable under certain conditions.