Re: From the dualstack-is-fun department...

On Mon, 28 Feb 2011, Daniel Roesen wrote:

> Seriously, I think we operators would be well advised to help reviewing
> and polish up the Happy Eyeballs spec and - if deemed feasible - promote
> implementation to OS/Distro/App vendors ASAP.
>
> http://tools.ietf.org/html/draft-wing-v6ops-happy-eyeballs-ipv6-01
>
> Happy Eyeballs ain't unproblematic. Opportunistic session setup will
> have impact on - if the IPv6 transport of a dual-stacked target host
> works fine, the opportunistic IPv4 session setups will "unnecessarily"
> (as no data traffic transfer follows) clog up resources on LSNAT44
> and the target firewalls, loadbalancers and host (phantom sessions).
> See section 4.2.1

And, would you have noticed the IPv6 related bug if happy-eyeballs was
already implemented or would legacy IP have worked well enough for you
to not notice (read as - what's better?, getting the bug fixed or not
noticing and harming IPv6 for longer)?

/bz

--

-- 
Bjoern A. Zeeb                                 You have to have visions!
          Stop bit received. Insert coin for new address family.

Re: From the dualstack-is-fun department...

On Tue, Mar 01, 2011 at 12:07:36AM +0000, Bjoern A. Zeeb wrote:
> And, would you have noticed the IPv6 related bug if happy-eyeballs was
> already implemented or would legacy IP have worked well enough for you
> to not notice (read as - what's better?, getting the bug fixed or not
> noticing and harming IPv6 for longer)?

IPv6 is not customer-driven, but provider driven. So #1 priority must be
that "things keep working" as painless as possible.

But you're right in the sense that with Happy Eyeballs we need methods
to measure problems being masked by HE. How, is one of the things
which seem to be missing in the Happy Eyeballs discussion.

Best regards,
Daniel

--

-- 
CLUE-RIPE -- Jabber: dr <at> cluenet.de -- dr <at> IRCnet -- PGP: 0xA85C8AA0

Re: From the dualstack-is-fun department...

Daniel,

On Tue, Mar 1, 2011 at 1:34 AM, Daniel Roesen <dr <at> cluenet.de> wrote:
> On Tue, Mar 01, 2011 at 12:07:36AM +0000, Bjoern A. Zeeb wrote:
>> And, would you have noticed the IPv6 related bug if happy-eyeballs was
>> already implemented or would legacy IP have worked well enough for you
>> to not notice (read as - what's better?, getting the bug fixed or not
>> noticing and harming IPv6 for longer)?
>
> IPv6 is not customer-driven, but provider driven. So #1 priority must be
> that "things keep working" as painless as possible.
>
> But you're right in the sense that with Happy Eyeballs we need methods
> to measure problems being masked by HE. How, is one of the things
> which seem to be missing in the Happy Eyeballs discussion.

Totally agree. Like I told to Bjoern when we met in  <at> fosdem a few
weeks ago - from the pure engineering point of view I think a good
thing that could happen is IPv4 would suddenly vanish from the face of
earth for 3-4 months. Then we notice all the problems and can fix them
(very fast  (Un)fortunately this is not possible - as it would be a
major catastrophy from the user experience point of view.

Happy Eyeballs is a bit on the other side of the spectrum - by working
hard to make the UX as seamless as possible indeed it masks these
kinds of problems - so with it the chances are high that these
problems will not be noticed. Actually, even more so since the
opportunistic connection establishment that you mentioned in the first
mail might not even happy if the single protocol consistently wins (so
it is not 100% true about the increase in load).

RE: From the dualstack-is-fun department...

> -----Original Message-----
> From: ipv6-ops-
> bounces+guillaume.leclanche=swisscom.com <at> lists.cluenet.de [mailto:ipv6-
> ops-bounces+guillaume.leclanche=swisscom.com <at> lists.cluenet.de] On
> Behalf Of Daniel Roesen
> Sent: Monday, February 28, 2011 11:34 PM
> To: ipv6-ops <at> lists.cluenet.de
> Subject: From the dualstack-is-fun department...


> DS-Website having one AAAA RR:  ~3 minutes time to IPv4 fallback(!)

I analyzed this behavior, the reason is that the browser is calling the connect() API from the OS. This
function will then try the complete TCP opening process, including TCP retries. Linux (at least debian
flavour) will do 5 retries, with exponentially growing time between them.

You can play with the number of retries; I put it down to 2, and the fallback-to-ipv4 time was roughly 10s.

I opened a feature request on the kernel bug tracker to request the possibility to tune this parameter for
dualstack websites, and put it by default to 2, but nothing happened afaik.

The request :
https://bugzilla.kernel.org/show_bug.cgi?id=23242


The sysctl control is tcp_syn_retries (sorry forgot the hierarchy, you'll have to grep :)

Guillaume

Re: From the dualstack-is-fun department...

Re: From the dualstack-is-fun department...

Well, there's always the much-hated whitelisting approach...

Re: IPv6 PPP/RADIUS and PD on Redback SEOS 6.4.1

On Mon, Feb 28, 2011 at 09:56:35PM +0000, David Freedman wrote:
> >
> > I'm struggling to get PD to work. My Cisco CPE sends out the Solicits
> >over the PPP link but the SE100 doesn't seem to reply. Since my carrier
> >doesn't officially support DHCP-PD I'm wondering wether this is because
> >of the lack of carrier support or because SEOS lets me down. I suspect
> >that sending the SOLICIT to ff02::1:2 directly goes into the dialer
> >interface that carries the PPP tunnel and hence the carrier (KPN) doesn't
> >even see this and neither would have to formally support this, am I
> >mistaken?
> 
> You are correct, the traffic should be wrapped in IPv6CP which should be
> carried over the PPP,

Ahem. Minor nit from the former Usenet PPP eveng^WFAQ maintainer:

IPv6CP is the control protocol (protocol field 0x8057) used to negotiate
transport of IPv6 over PPP (protocol filed 0x0057). Thus, in respect to
IPv6, it's out of band. Same for OSI, IPv4, DECnet, Appletalk, etc. over
PPP.

	-is

Re: From the dualstack-is-fun department...

Hi Guillaume,

On Tue, 1 Mar 2011 08:16:53 +0100
<Guillaume.Leclanche <at> swisscom.com> wrote:

> > -----Original Message-----
> > From: ipv6-ops-
> > bounces+guillaume.leclanche=swisscom.com <at> lists.cluenet.de [mailto:ipv6-
> > ops-bounces+guillaume.leclanche=swisscom.com <at> lists.cluenet.de] On
> > Behalf Of Daniel Roesen
> > Sent: Monday, February 28, 2011 11:34 PM
> > To: ipv6-ops <at> lists.cluenet.de
> > Subject: From the dualstack-is-fun department...
> 
> 
> > DS-Website having one AAAA RR:  ~3 minutes time to IPv4 fallback(!)
> 
> I analyzed this behavior, the reason is that the browser is calling the connect() API from the OS. This
function will then try the complete TCP opening process, including TCP retries. Linux (at least debian
flavour) will do 5 retries, with exponentially growing time between them.
> 
> You can play with the number of retries; I put it down to 2, and the fallback-to-ipv4 time was roughly 10s.
> 
> I opened a feature request on the kernel bug tracker to request the possibility to tune this parameter for
dualstack websites, and put it by default to 2, but nothing happened afaik.
> 
> The request :
> https://bugzilla.kernel.org/show_bug.cgi?id=23242
> 
> The sysctl control is tcp_syn_retries (sorry forgot the hierarchy, you'll have to grep :)
> 

Are you using a Fritzbox 7390? When you enable IPv6, they enable ULAs
by default (although their ULAs aren't (near-)unique because the unique
id is all zeros!), and don't issue ICMPv6 Destination Unreachables then
they don't have an IPv6 default route. So with an IPv4 only WAN link,
this problem occurs on all dual-stack websites. According to RFC4443,
they SHOULD be issuing ICMPv6 Destination Unreachables, No route to
destination.

Regards,
Mark.

Re: From the dualstack-is-fun department...

Hi,

On Tue, Mar 01, 2011 at 04:32:49PM +0900, Erik Kline wrote:
> Well, there's always the much-hated whitelisting approach...

Which would not have helped Daniel at all...  he has working v6, he
has a whitelisted provider, but "something in his personal setup is
not working"

(I assume that the underlying problem here is "bridging from a VM to a 
wifi network", since wifi is bad at the "use a different MAC for the VM 
thingie" - but it could be any number of things breaking locally, even
if you're nicely whitelisted)

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

Re: From the dualstack-is-fun department...

On Tue, Mar 1, 2011 at 8:31 AM, Cameron Byrne <cb.list6 <at> gmail.com> wrote:
>
> On Feb 28, 2011 10:41 PM, "Andrew Yourtchenko" <ayourtch <at> gmail.com> wrote:
>>
>> Daniel,
>>
>> On Tue, Mar 1, 2011 at 1:34 AM, Daniel Roesen <dr <at> cluenet.de> wrote:
>> > On Tue, Mar 01, 2011 at 12:07:36AM +0000, Bjoern A. Zeeb wrote:
>> >> And, would you have noticed the IPv6 related bug if happy-eyeballs was
>> >> already implemented or would legacy IP have worked well enough for you
>> >> to not notice (read as - what's better?, getting the bug fixed or not
>> >> noticing and harming IPv6 for longer)?
>> >
>> > IPv6 is not customer-driven, but provider driven. So #1 priority must be
>> > that "things keep working" as painless as possible.
>> >
>> > But you're right in the sense that with Happy Eyeballs we need methods
>> > to measure problems being masked by HE. How, is one of the things
>> > which seem to be missing in the Happy Eyeballs discussion.
>>
>> Totally agree. Like I told to Bjoern when we met in  <at> fosdem a few
>> weeks ago - from the pure engineering point of view I think a good
>> thing that could happen is IPv4 would suddenly vanish from the face of
>> earth for 3-4 months. Then we notice all the problems and can fix them
>> (very fast  (Un)fortunately this is not possible - as it would be a
>> major catastrophy from the user experience point of view.
>>
>> Happy Eyeballs is a bit on the other side of the spectrum - by working
>> hard to make the UX as seamless as possible indeed it masks these
>> kinds of problems - so with it the chances are high that these
>> problems will not be noticed. Actually, even more so since the
>> opportunistic connection establishment that you mentioned in the first
>> mail might not even happy if the single protocol consistently wins (so
>> it is not 100% true about the increase in load).
>>
>> We plan a bar bof  <at> Prague, I will definitely bring this topic up there
>> too - meantime if you have ideas, feel free to write them up for the
>> discussion.
>>
>> Side remark: I noticed this trend overall - the more robust you have a
>> protocol to external influences (soft failures instead of hard
>> failures), the "nicer" is the user experience, and the more hell is in
>> debugging of this protocol for the support/dev folks when the
>> experience slowly degrades to the point of being unacceptable. It's a
>> tough choice.
>>
>
> This also creates the ugly situation where customer calls help desk saying
> website x is down, support person tries to get to website x, and it works.
> Help desk says, nope "works for me" and the broken ipv6 access or dare I say
> ipv4 access is broken to the none-HE user but works for the HE user. If the
> none he-user cannot easily convince others that there is a problem, that is
> bad.

Yes, we already have in the latest text:

"Debugging and Troubleshooting

This mechanism is aimed to help the user experience in case of connectivity
problems. However, this precise reason also makes it tougher to use these
applications as a means of the verification that the problems are fixed. To
assist in that regard, the applications implementing the proposal in this
document SHOULD also provide a mechanism to temporarily use only one
address family."

Too weak ? Wrong approach ?

>
> This is a support nightmare as HE masks the issue and will not be uniformly
> deployed -- ever.
>
> This is a classic dilemma. Masking the problem ostensibly makes it go away,
> but at the same time exacerbates the ability to resolve it. It is kind of
> like beer :)
> and beer is good, especially when I been troubleshooting
> connectivity issues all day and my customers keeping telling me  websites
> are down
> ... but not all of them ... they all but works for me ....

...and "no-one changed anything". (That's what everyone says for the
past 15 or so years, I keep asking just in case, to see how often it's
"we changed X and Y has broken". I can count the occasions on fingers
of one hand, vs. the ~mid-4-digits number of the other outcome. So
fundamentally nothing changes - it breaks by itself today too 

(but seriously: appreciate all of the comments. I thought the above
blurb about troubleshooting in the draft should be enough, but maybe
it is not too strongly worded.
Maybe there needs to be some way to flag the problem that has been
worked around. To whom ? How ? Is it supposed to be specifit to this
area or maybe should there be something generic ? I think I'm getting
on hyperbolic HE-tangent trajectory with these questions.)

cheers,
andrew

>
> Cb
>> cheers,
>> andrew
>