Re: [v6ops] Bar BoF on a 6to4 replacement?

[John Mann <[e-mail]>]

Hi,

On 3 December 2014 at 22:41, Metzler, Dan J <[e-mail]> wrote:

>  Hi,
>
>
>
> A few thoughts…
>
>
>
> ‘After dual-stack IPv6 was enabled on most subnets, protocol 41 and
> Teredo were blocked at Monash's Internet border on 15-Jun-2011.  I don't
> recall anyone ever asking for it to be re-enabled.’
>
> -          Not necessarily a problem, “IF” Monash does not provide
> internet access to other ISPs.  If it does, then were they all dual-stack
> IPv6 enabled?  If not then I would point out that this broke IPv6 service
> for some downstream customers of those ISPs.  The only reason for an ISP to
> turn off Teredo and protocol 41 is if all downstream customers have access
> to native IPv6 connectivity, and even then that decision is questionable.
>

Yes, you are right.  Monash does provide Internet transit for some
downstream organisations.
I only blocked protocol 41 and Teredo for Monash's IP address ranges.

 -          It is unlikely that anyone would ask for it to be re-enabled.
> They would more likely incorrectly assume that IPv6 is broken and disable
> it.  The reason for this is that the vast majority of people, who were
> affected by this, likely would not have had the technical skill to trace it
> back to Monash.  Before they ever got to that point someone would likely
> tell them to disable IPv6, or all tunneling protocols thus completing the
> breakage of their IPv6 connectivity.
>

I don't see how blocking tunnel protocols at Monash's border impacts any
user or server outside Monash ...
Users/servers outside Monash can still use 6to4 or Teredo tunnels -- if
those tunnels terminate outside Monash somewhere.

Monash users with native IPv6 and would not have needed any tunneling for
general Internet access.
Only Monash users could have been affected by the block, called our
Helpdesk with "The Internet is slow",
been triaged, and got through to people with technical skills.

The people who could have wanted tunnels re-enabled might be e.g.
- a student with a NAT home router in their dorm room who wants to get to
some IPv6 service (over Teredo)
  [ Mind you, a PC at Monash behind NAT -> Teredo gateway in Seattle -> Web
server at Monash on public IPv6 and back  was about 400ms RTT. ]


>  ‘I assert that the time of "experimental" IPv6 has passed.  IPv6 should
> be a "production" service.’
>
> -          100% agreed!
>
>
>
> ‘If the IPv6 network service isn't almost as good (due to reliability or
> RTTs or whatever) as IPv4,
>
> turn it off until you can do it right.’
>
> -          Noooooooooooo.
>
> -          If the IPv6 network service isn’t almost as good (due to
> reliability or RTTs or whatever), and it is under your control to fix it,
> then please fix it.
>
> -          If it isn’t under your control, then communicate it to your
> ISP or the offending party and ask them to fix it.
>
> -          “Turn it off” is the wrong answer, though probably the more
> popular answer.  Turning it off breaks it more completely than it was with
> poor performance.
>

Perhaps I wasn't clear.  I was talking as the operator of the network
service.
By "turn it off" I meant "disable IPv6 on their local subnet router
interface; don't let IPv6 RAs get to the user's devices".

We do actively work on fixing IPv6 problems.
But some vendors can take many years and many attempts before they get IPv6
support up to approximate feature and performance parity with IPv4.

In the meantime, we disable the "IPv6 network service" so that users don't
have a bad network experience and then have to disable IPv6 in their
devices to get stuff done.  And the users never learn that disabling IPv6
can sometimes fix problems.

Thanks,
    John