Subject: [v6ops] draft-carpenter-v6ops-6to4-teredo-advisory-01 diffs from -00 version

From: Brian E Carpenter <[email-masked]>
Date: Thu, 10 Feb 2011 13:53:12 +1300

http://tinyurl.com/6to4adv00-diffs

More comments are welcome, but please please please choose a new
subject header for each topic; if you don't do this and we get
another few hundred messages under the same subject, the chances that
your point will be noticed are very small.

   Brian

---

From: james woodyatt <[email-masked]>
Date: Wed, 09 Feb 2011 17:37:13 -0800

On Feb 9, 2011, at 16:53, Brian E Carpenter wrote:
> 
> More comments are welcome, 

I recommend adding text to this draft recommending that well-managed 6to4 relays be capable of responding to ICMPv6 echo requests encapsulated in IPv4 protocol 41.

The reason: certain CPE router products use ICMPv6 echo requests to detect the availability of a 6to4 relay at the anycast IPv4 address, and they will notify their users with a diagnostic message if they have 6to4 tunneled routing enabled and the relay is not responding to ICMPv6 echo requests, which is usually a sign that the anycast relay route is a black hole.

Apple has found that some 6to4 relays work just fine, but ICMPv6 echo requests sent by the CPE router do not result in any replies received.  The CPE router notifies the user there is a problem, but the user isn't *really* having a problem.  The alarm is a false positive.  The user then instructs the CPE router to stop sending the alarm, and then they don't get a notification when the relay stops working later.

Proposed text:

> Operators that deploy 6to4 relays are advised to ensure that ICMPv6 echo requests and replies encapsulated in IPv4 protocol 41 are passed properly between the relay and 6to4 hosts and routers for which it is intended to provide relay service.

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

---

From: Pekka Savola <[email-masked]>
Date: Thu, 10 Feb 2011 08:20:48 +0200 (EET)

On Wed, 9 Feb 2011, james woodyatt wrote:
> I recommend adding text to this draft recommending that well-managed 
> 6to4 relays be capable of responding to ICMPv6 echo requests 
> encapsulated in IPv4 protocol 41.

Which IPv6 address should the relay be responding pings at?

This was actually a topic of a draft some 8 years ago but didn't go 
anywhere.

Just send the echo request with TTL=1 like Microsoft implementation 
does, and whether you receive a reply -- TTL exceeded or a response -- 
is enough.

-- 
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: Daniel Roesen <[email-masked]>
Date: Thu, 10 Feb 2011 08:21:04 +0100

> encapsulated in IPv4 protocol 41.

What is the destination address of the ICMPv6 echo request packet
supposed to be, and what the echo reply source address? I think we
should specify how those probes should look like.

Best regards,
Daniel

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

---

From: james woodyatt <[email-masked]>
Date: Thu, 10 Feb 2011 07:47:02 -0800

> should specify how those probes should look like.

The implementation I'm familiar with sends IPv4 encapsulated echo requests to outer=192.88.99.1 and inner=[2002:c058:6301::] and wants to receive replies with a matching ICMPv6 identifier field from any source address.

---

From: Ole Troan <[email-masked]>
Date: Thu, 10 Feb 2011 17:41:58 +0100

> This was actually a topic of a draft some 8 years ago but didn't go anywhere.
> 
> Just send the echo request with TTL=1 like Microsoft implementation does, and whether you receive a reply -- TTL exceeded or a response -- is enough.
> 

can we not use the unreachability check from 6rd:
http://tools.ietf.org/html/rfc5969#section-8

cheers,
Ole

---

From: Pekka Savola <[email-masked]>
Date: Thu, 10 Feb 2011 18:55:01 +0200 (EET)

> The implementation I'm familiar with sends IPv4 encapsulated echo requests to outer=192.88.99.1 and inner=[2002:c058:6301::] and wants to receive replies with a matching ICMPv6 identifier field fro…

This is suboptimal compared to the implementation I described and can 
be read about e.g. from http://netcore.fi/pekkas/6to4.pdf because the 
check you describe only succeeds if the relay is configured with 
2002:c058:6301:: or supports subnet-router anycast address.

Wrt Ole's mail, 6rd check seems like a self-ping procedure which may 
imply special requirements wrt. RPF checking (e.g. allow-self-ping 
special knob).  In case of 6to4, the relay might drop the packet, 
depending on filtering.  Relays should not be expecting to get traffic 
from 6to4 source addresses destined to 6to4 addresses.  RFC3964 
Section 5.2 recommends (SHOULD) dropping these. I'm not familiar if 
this is commonplace or not.

---

From: james woodyatt <[email-masked]>
Date: Thu, 10 Feb 2011 10:15:58 -0800

On Feb 10, 2011, at 08:55, Pekka Savola wrote:
> This is suboptimal...

I agree.  I'm not describing what should be done in the future, but rather what has already been done and shipped in large numbers around the world.  We're talking about a terrain feature, remember?

Yes, it would be nice if we had built a 5-star golf course where there is now a midge-infested swamp... Brian's advisory draft is aimed at telling operators how to help in draining the swamp, not how to keep the grass from dying on hypothetical fairways.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 10 Feb 2011 20:22:04 +0200 (EET)

On Thu, 10 Feb 2011, james woodyatt wrote:
>> This is suboptimal...
>
> I agree.  I'm not describing what should be done in the future, but 
> rather what has already been done and shipped in large numbers 
> around the world.  We're talking about a terrain feature, remember?

It is good to hear what some implementations have done.  Even better 
would be hearing about the side effects.

The more robust check I mentioned has been deployed and is being run 
by (dozens of?) millions of Windows boxes daily for at least 5+ years 
now.

It's causing some load on the relays, but otherwise I suppose it works 
OK.

---

From: Daniel Roesen <[email-masked]>
Date: Thu, 10 Feb 2011 19:56:06 +0100

> your point will be noticed are very small.

I would suggest replacing all references to the marketing term "Carrier
Grade NAT" with "ISP-operated NAT44", depending on the context
ammended by "(NAT444 scenario)" to more clearly specify the setting.

Best regards,
Daniel

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Feb 2011 08:37:34 +1300

> ammended by "(NAT444 scenario)" to more clearly specify the setting.

The BEHAVE WG just decided to stick to "CGN". Actually your phrase is a
good one, but I guess I have to follow the BEHAVE party line.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 11 Feb 2011 08:42:12 +1300

Pekka,

Do the words I have in the draft cover it adequately? If not,
please send suggested text.

"  Unless the answer to all these questions is 'yes', subscribers will
   be no worse off, and possibly better off, if the route to 192.88.99.1
   is blocked and generates 'destination unreachable'.  At least one
   host implementation (Windows XP) starts with a 'ping' to the anycast
   address, so will quickly learn that 6to4 is not available [Savola]."

(As James implied, I'm not very interested in adding suggestions for
improvements to 6to4 code at this point in history.)

Regards
   Brian

On 2011-02-11 07:22, Pekka Savola wrote:
>> rather what has already been done and shipped in large numbers around
>> the world.  We're talking about a terrain feature, remember?
> 
> The more robust check I mentioned has been deployed and is being run by
> (dozens of?) millions of Windows boxes daily for at least 5+ years now.
> 
> It's causing some load on the relays, but otherwise I suppose it works OK.
>

---

From: Nathan Ward <[email-masked]>
Date: Fri, 11 Feb 2011 11:00:45 +1300

On 11/02/2011, at 5:55 AM, Pekka Savola wrote:

> This is suboptimal compared to the implementation I described and can be read about e.g. from http://netcore.fi/pekkas/6to4.pdf because the check you describe only succeeds if the relay is configured with 2002:c058:6301:: or supports subnet-router anycast address.

I think both these methods are suboptimal as they don't test whether the relay is actually usable to reach the IPv6 network, though the Windows method of selecting a relay's non-anycast IPv4 address is interesting, and should perhaps be looked in to further.

I posted a mail to this list yesterday that seems to have not escaped my mail client. Anyway, about 2 years ago I wrote up how we might do this better, in a way that is easy to deploy now, doesn't require support of existing relays (special addresses, etc), tests the ability of a relay to forward traffic to the IPv6 network, and tests for more things than simply "is reachable".
It does, as with all these solutions, require support from "client" implementations - however like I say, no relay support is required so is (in my opinion) much easier to have deployed and usable rapidly.
Folks didn't seem interested at the time and I had other commitments so didn't pursue this - maybe it's time to kick it off again?

http://tools.ietf.org/agenda/74/slides/v6ops-11.pdf
http://tools.ietf.org/html/draft-nward-6to4-qualification-00

--
Nathan Ward

---

From: Pekka Savola <[email-masked]>
Date: Fri, 11 Feb 2011 08:41:53 +0200 (EET)

>   address, so will quickly learn that 6to4 is not available [Savola]."

I do not know if an (IPv4) destination unreachable will propagate to 
the application (or the stack).  Windows uses the method as a 
qualification procedure (if it doesn't work, the 6to4 relay is not 
used) and as such it won't get reported to the applications in such a 
manner that e.g. ICMPv6 error would be or how you probably hope that 
ICMPv4 would be.

So, I would suggest the following caveat to the former (unless we get 
info on how implementations react -- preferable), and more precise on 
the methodology:

     Unless the answer to all these questions is 'yes', subscribers
     will be no worse off, and possibly better off, if the route to
     192.88.99.1 is blocked and generates an IPv4 'destination
     unreachable'. There is little operational experience with this,
     however.

     Some implementations also perform some form of 6to4 relay
     qualification. For example, a host implementation (Windows) tests
     the protocol-41 reachability by sending an ICMPv6 echo request
     with Hop Limit=1 to the relay, expecting a response or Hop Limit
     exceeded error back. Lack of any response indicates that the 6to4
     relay does not work and it is turned off [Savola].

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 11 Feb 2011 10:35:23 +0000

> good one, but I guess I have to follow the BEHAVE party line.

There is a long-term problem here: because "Carrier Grade NAT" is a 
marketing term rather than a technical term which conveys a specific 
meaning, its meaning will degrade over time to whatever a particular vendor 
is attempting to sell.

I'd like to second Daniel's suggestion of "ISP-Operated NAT44", because it 
is a specific and unambiguous technical term, which will still mean the 
same thing in 10 or 20 years time.

Nick

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 11 Feb 2011 11:17:57 +0000

Or Network-Based NAT (NBN), or some variation thereof, since the operator of the NAT may or may not be an ISP. Think enterprise, academic, or other large network…

Also, there can be some question of what "Carrier Grade" really means. It sounds vaguely more scalable/available I suppose. In my experience, carrier grade mainly means it costs more. ;-)

Jason

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 11 Feb 2011 11:19:44 +0000

On 11/02/2011 11:17, Livingood, Jason wrote:
> Also, there can be some question of what "Carrier Grade" really means. It
> sounds vaguely more scalable/available I suppose. In my experience, carrier
> grade mainly means it costs more. ;-)

Using the name "Carrier Grade" is putting lipstick on a pig.

Nick

---

From: Jack Bates <[email-masked]>
Date: Fri, 11 Feb 2011 08:33:10 -0600

On 2/11/2011 5:17 AM, Livingood, Jason wrote:
> Also, there can be some question of what "Carrier Grade" really means.
> It sounds vaguely more scalable/available I suppose. In my experience,
> carrier grade mainly means it costs more. ;-)

I had shifted to the more generic LSN, which is more appropriate than 
CGN and is still vague enough to deal with ds-lite and NAT444.

Jack

---

From: Rémi Després <[email-masked]>
Date: Fri, 11 Feb 2011 15:54:18 +0100

> Just send the echo request with TTL=1 like Microsoft implementation does, and whether you receive a reply -- TTL exceeded or a response -- is enough.

+1 in favor of recommending this host behavior: it only depends on what every relay must do.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 11 Feb 2011 15:58:15 +0100

> ammended by "(NAT444 scenario)" to more clearly specify the setting.

+1
RD

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

---

From: Rémi Després <[email-masked]>
Date: Fri, 11 Feb 2011 16:49:50 +0100

> good one, but I guess I have to follow the BEHAVE party line.

Yes, where an abbreviation is used, "CGN" is the choice. 

Where a more explicit designation is used "ISP-operated NAT44" is IMHO much better than "Carrier-grade NAT".

Regards,
RD

---

From: "Frank Bulk" <[email-masked]>
Date: Sat, 12 Feb 2011 01:09:32 -0600

Someone willing to write a NAGIOS plugin?

Frank

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Pekka Savola
Sent: Friday, February 11, 2011 12:42 AM
To: Brian E Carpenter
Cc: IPv6 Operations
Subject: Re: [v6ops] 6to4 reliability check