Subject: [v6ops] RAmond Download URL

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 31 Mar 2011 07:19:58 +0000

FYI – The presentation in v6ops gave the URL http://raymond.sourceforge.net, which does not have the software (redirect-->404). The correct URL appears to be: http://sourceforge.net/projects/ramond/

Jason

---

From: Tim Chown <[email-masked]>
Date: Thu, 31 Mar 2011 09:27:41 +0200

> FYI – The presentation in v6ops gave the URL http://raymond.sourceforge.net, which does not have the software (redirect-->404). The correct URL appears to be: http://sourceforge.net/projects/ramond/

Thanks Jason.  I smell Powerpoint autocorrect at play :)

RAmond is a derivative of rafixd implemented as part of a student project.   It can simply be used as a way to log rogue RAs, or to issue deprecating RAs against them.   It's better though to use methods like RAguard or ACLs if you're in a managed environment.

Tim

---

From: Roland Bless <[email-masked]>
Date: Thu, 31 Mar 2011 09:56:35 +0200

Hi Tim,

On 31.03.2011 09:27, Tim Chown wrote:
>> FYI – The presentation in v6ops gave the URL
>> http://raymond.sourceforge.net <http://raymond.sourceforge.net/>,
>> which does not have the software (redirect-->404). The correct URL
>> appears to be: http://sourceforge.net/projects/ramond/

but  http://ramond.sourceforge.net/ works, which was what I noted
down from the presentation (human auto-correction? :-).

I just wanted to confirm what you measured: I also see
several rogue RAs every day in our wireless campus network,
obviously coming from smartphones offering a 6to4 tethering service
which doesn't work.

Regards,
 Roland

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 31 Mar 2011 08:34:42 +0000

>down from the presentation (human auto-correction? :-).

Ha! I think you are right. Unfortunately that option works at the
subconscious level and I cannot switch it off. ;-)

Anyway, good tool to check out.

Jason

---

From: Tim Chown <[email-masked]>
Date: Thu, 31 Mar 2011 10:56:13 +0200

> down from the presentation (human auto-correction? :-).

Ah...we try to pronounce it r-a-mon-d rather than raymond :)

> obviously coming from smartphones offering a 6to4 tethering service

Would be interested if you had some measurements.   Ours were taken over quite a small area (~40-50 APs).

The 'moving 6to4 to historic' discussion is in the second v6ops session today.   As someone commented remotely RFC3484-bis will help, as could connection-sharing RAs using a 'low' router preference option, but it will be interesting to see the room's view later.

Tim

---

From: George Michaelson <[email-masked]>
Date: Thu, 31 Mar 2011 10:57:34 +0200

Can you also confirm the ieee OUI map of the RA's?

I believe Apple may predominate, with Apple airport/express offering 6to4.

-George

On 31/03/2011, at 10:56 AM, Tim Chown wrote:

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

---

From: Mohacsi Janos <[email-masked]>
Date: Thu, 31 Mar 2011 11:02:51 +0200 (CEST)

Hi,

I think the most problem from several sources:
- Broken treatment of 6to4 in Mac OS X
- Windows Internet Connection sharing switched on accidentally or left 
switched on - generating 6to4 RAs
But look at Tim's presentation
- there were also HTC smarthpone device doing rogue RA...

Regards,

On Thu, 31 Mar 2011, George Michaelson wrote:

>>>>> FYI ? The presentation in v6ops gave the URL

---

From: <[email-masked]>
Date: Thu, 31 Mar 2011 11:04:30 +0200

After following the HE presentation during the v6ops WG meeting (and having another short look into the I-D) I'm wondering if there are any thoughts regarding an exit strategy for this Happy Eyeball approach. In other words how can this mechanism be pushed back in future when the IPv6 network / Internet has become reliable? 
Is there some kind of threshold indicating that HE should be turned off? And how can this happen?

Anoter point that scares me from a network / accsess service provider point of view is the recommendation that the per-destination value should expire after 10 min. That means that the host again tries to initiate an IPv4 connection (also in the case when IPv6 works fine) and generates (most likely unneeded) IPv4 traffic.
And if there is no exit strategy for HE than this will go on forever. Any thoughts?

Just my 0.02$.

Kind regards
Olaf

---

From: Gert Doering <[email-masked]>
Date: Thu, 31 Mar 2011 11:06:26 +0200

Hi,

> And if there is no exit strategy for HE than this will go on forever. Any thoughts?

Well, if there is no A record, HE will not try IPv4...  obvious exit
strategy.

(And it might be worthwile to mention somewhere that "if there is no
IPv4 configured on the local host, don't try IPv4 connections either").

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: Erik Kline <[email-masked]>
Date: Thu, 31 Mar 2011 11:13:39 +0200

> Is there some kind of threshold indicating that HE should be turned off? And how can this happen?

One thing that could happen is that it could simply morph into/merge
with a generic multi-connect approach that helps clients connect to
the destination with the shortest RTT.

---

From: Roland Bless <[email-masked]>
Date: Thu, 31 Mar 2011 11:25:28 +0200

Hi Tim,

> over quite a small area (~40-50 APs).

Unfortunately not yet. This was just my personal experience: my
connection was broken every time my laptop (linux)
was "multihomed" in the WLAN campus network and our IPv6 enabled
wired network, or also when attaching it from wireless only access
to its docking station...
The reason were prior rogue RAs received via the wireless network.
I was just manually running tcpdump to find out the source of these
rogue RAs and I saw several different RAs and changing IIDs (no
EUI-64 derived IIDs). Note that our wireless LAN on campus is not yet
IPv6 enabled, but it will be soon. Our NOC people are aware of the
potential upcoming problems...

For getting measurement data I have to contact the NOC folks at
our campus. Our campus comprises roughly 400APs (not sure).
Thanks for the pointer to the software, which may be helpful.

> The 'moving 6to4 to historic' discussion is in the second v6ops
> session today.   As someone commented remotely RFC3484-bis will help,
> as could connection-sharing RAs using a 'low' router preference
> option, but it will be interesting to see the room's view later.

Yep. My personal experience with 6to4 were also quite disappointing.
The AVM FritzBox DSL box had IPv6 enabled via a firmware update,
offering 6to4 as fallback in case you have no other IPv6 connection
(either native or tunnel). This didn't work at all. I didn't investigate
the cause for this, but protocol filtering is very likely.
As resort I got a sixxs tunnel connection until my DSL provider will
support native IPv6...

Regards,
 Roland

---

From: <[email-masked]>
Date: Thu, 31 Mar 2011 11:32:36 +0200

Hmm I've made the experience that DNS records are very often not at such an actualized status as they should be.
Besides that this (sit back and wait) seems not be an an acceptable exit strategy from a provider point of view. (The same applies also to the "wait until the last IPv4 user died" approach.)

Regards
	Olaf

> -----Ursprüngliche Nachricht-----
> Von: Gert Doering [mailto:[email-masked]] 
> Gesendet: Donnerstag, 31. März 2011 11:06
> An: Bonneß, Olaf
> Cc: [email-masked]
> Betreff: Re: [v6ops] Happy Eyeballs - Exit strategies?
> 
> Hi,
>

---

From: Roland Bless <[email-masked]>
Date: Thu, 31 Mar 2011 11:48:09 +0200

Hi,

> - there were also HTC smarthpone device doing rogue RA...

Yes, I can confirm that from my personal experience.
Some time ago I also had some HTC Windows 6.x based model and
every time I wanted to use tethering, it advertised a non-working
6to4 prefix to my laptop, breaking every v6 connection,
i.e., because our institute is IPv6 enabled since 2001 I
always had to kill the IPv6 address manually (as workaround)
if I wanted to contact any server in the office. It's not
clear to me whether this was an HTC specific or Windows
feature...

Regards,
 Roland

---

From: james woodyatt <[email-masked]>
Date: Thu, 31 Mar 2011 10:08:42 -0700

> I believe Apple may predominate, with Apple airport/express offering 6to4.

This would not be what I would expect.  There was once a time when I would have thought that, but that was years ago.  Not so much anymore.

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

---

From: George Michaelson <[email-masked]>
Date: Thu, 31 Mar 2011 19:21:37 +0200

> This would not be what I would expect.  There was once a time when I would have thought that, but that was years ago.  Not so much anymore.

Good to know. You still show top of the 2002::/16 reverses by OUI however. That was the basis of my belief. It probably reflects market weight of product.

-G

---

From: Hagen Paul Pfeifer <[email-masked]>
Date: Thu, 31 Mar 2011 19:26:18 +0200

>Besides that this (sit back and wait) seems not be an an acceptable exit
>strategy from a provider point of view. (The same applies also to the "wait
>until the last IPv4 user died" approach.)

What are these drawbacks that makes Happy Eyeball approach somewhat stinking?
Why is Gert's reply not adequate from a provider point of view?

Hagen

---

From: Erik Kline <[email-masked]>
Date: Thu, 31 Mar 2011 19:39:42 +0200

> Good to know. You still show top of the 2002::/16 reverses by OUI however. That was the basis of my belief. It probably reflects market weight of product.

Well, if you look only at 2002:: addresses that have EUI64 components,
that may not be surprising.  I think you can find the Windows 2002::
addresses by looking for their specific forms, assuming they have a
consistanly recognizable form (were they largely
2002:<ipv4>::<ipv4>?).

---

From: <[email-masked]>
Date: Thu, 31 Mar 2011 19:47:49 +0200

Hi Hagen,

as I tried to explain: If the HE approach remains in the network without a dedicated exit strategy than all the clients outthere will go on trying to connect via IPv4 (see "flashing the destination P value every 10 min") also in the case when there is already a better IPv6 connectivity is available.

According to Gerds proposal this will end when there is no A record for the destination is available anymore or the client is IPv6-only. Gerd is of course right but the problem with this approach is, that it simply relies on the assumption that all the people are accordingly updating there DNS records. 

Besides that, one of the IETF standardization basics is to also think about exit strategies for mechanisms and protocols they standardize.
I hope that I could make my position a bit more clear.

Regards
	Olaf

PS: IMHO, HE is a very useful and needed mechanism (that may perhaps have some room for improvement), and thats why I definitely don't share your classification of this mechanism.

> Von: Hagen Paul Pfeifer [mailto:[email-masked]] 
> Gesendet: Donnerstag, 31. März 2011 19:26
> An: Bonneß, Olaf
> Cc: [email-masked]; [email-masked]
> >Hmm I've made the experience that DNS records are very often 
> not at such an
> >actualized status as they should be.
>

---

From: George Michaelson <[email-masked]>
Date: Thu, 31 Mar 2011 20:30:49 +0200

> consistanly recognizable form (were they largely

Geoff also made that observation privately. 

I'll re-do my counts, Observing that privacy mode kicked in early last year.

-G

---

From: james woodyatt <[email-masked]>
Date: Thu, 31 Mar 2011 11:28:47 -0700

On Mar 31, 2011, at 10:21 AM, George Michaelson wrote:
> 
> You still show top of the 2002::/16 reverses by OUI however.

Those are probably Mac OS X and iOS hosts that don't implement RFC 3484, and that's why you see such a disproportionate number of them.  They are likely located behind 6to4 routers by other equipment makers.  The AirPort/TimeCapsule product line does not have a very large share of the market compared to other vendors who have 6to4 router features enabled.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 01 Apr 2011 15:22:00 +1100

In message <[email-masked]>, james woodyatt writes:
> Those are probably Mac OS X and iOS hosts that don't implement RFC 3484, and that's why you see such a disproportionate num
> ber of them.  They are likely located behind 6to4 routers by other equipment makers.  The AirPort/TimeCapsule product line 
> does not have a very large share of the market compared to other vendors who have 6to4 router features enabled.

What's needed now is 6rd images for all these 6to4 CPE boxes so
that the customers that are successfully using 6to4 today continue
to work in the presence of CGN's.  Yes that means that when a ISP
deploys a CGN they also will need to deploy 6rd BR's.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Scott Brim <[email-masked]>
Date: Fri, 1 Apr 2011 08:46:48 +0200

Happy eyeballs is eminently configurable.  For IPv4/v6, you could
initialize the P value so that it never tries IPv4 unless there are
extreme delays in getting an IPv6 connection.  You could also
parameterize P adjustment behavior.

Scott