Re: Microsoft's participation in World IPv6 day

[Mark Andrews <marka () isc org>]

In message <DFE74319-378F-4134-B521-452328B179F0 () delong com>, Owen DeLong writes:
> > It's how you handle the exceptions.  Home users have port 25 off
> > by default but can still get it turned on.  Most home users don't
> > need a public IP address as they are not running stuff that requires
> > it however some do so planning to handle the exceptions as efficiently
> > as possible is a good thing to do.
>
> I disagree. I look forward to a day when all home users by default
> have a public IPv6 address for each of their machines and hopefully
> enough to support multiple subnets within the home.

need == something they currently do will break without it when LSN is
deployed for IPv4 and there is not a suitable workaround.

I'm all for customers getting public IPv6 addresses.  Keeping IPv4
running until IPv6 is ubiquitous with minimal breakage is the
challenge.

> Until then, IPv4 service without at least one public IP is degraded
> at best compared to what most people consider normal residential
> internet access today (which, frankly, is degraded at best compared
> to what I consider normal internet access).
>
> > I've got two applications that won't work behind a LSN.  A sip phone
> > and a 6in4 tunnel however I'm not typical.
>
> You're not that atypical either, at least compared to US users. The
> following very common applications are known to have problems
> with LSN:
>       Playstation Network
>       X-Box Live
>       AIM/iChat/FaceTime
>       SIP/Vonage/other VoIP services
>       The HTTPs Server on TiVO boxes
>       Peer to Peer (torrent, etc.)
>
> Other less common applications also have problems:
>       HTTP servers
>       SMTP servers
>       Back to my Mac
>       VNC
>       Tunnels

So you take these things that are known to break as exceptions to
being behind a LSN and when there is a workable alternative you
remove it from the exception list with a desription of the work
around.

e.g. SMTP servers don't require a public IPv4 address.  STARTTLS
with authenticated TURN to a external MX will work.  Similarly a
external dual stack MX + IPv6 support will work.  The ISP could
supply that external MX.

> > Looking at 6to4 and auto tunnels they really are a small percentage
> > of customers that could be auto detected by the ISP and be put into
> > the exception pool prior to enabling LSN.  Most CPE routers today
> > don't enable 6to4 (they either don't support IPv6 let alone 6to4
> > or its not turned on by default).  As for directly connected machines
> > many of then still require 6to4 to be turned on by hand (XP, Mac
> > OS).
>
> While this is true, I'm not sure it's all that relevant.
>
> Most ISPs I have talked to in the US are dreading the deployment
> of LSN and not planning to deploy it by default except to the
> extent absolutely necessary to meet customer demand.
>
> > What's easier for the ISP, detecting the  customers that use protocol
> > 41 today and automatically adding them to a exception pool or
> > fielding the support calls?
>
> Moving them to IPv6 and hoping that enough of the content providers
> move forward fast enough to minimize the extent of the LSN deployment
> required.
>
> Owen
>
> > Mark
> >
> > > Without any commitments to cite, plan for the worst and hope for the best.
> > >
> > > Cb
> > > > If I were doing it I would also have checkboxes for some of the
> > > > more common reasons and include IPv6 connectivity as one then have
> > > > a 6 month grace period once the ISP offers IPv6 connectivity before
> > > > removing that as a valid reason for needing a address that is not
> > > > behind the LSN.
> > > >
> > > > > LSN is beeing actively implemented in the core network of several
> > > > > ISPs, and most didn't yet consider it as optional. Nor are ready for
> > > > > v6 connectivity to residential customers, though.
> > > > >
> > > > > For users behind a forced NAT (no way to disable it on the CPE) or
> > > > > LSN, the only way out is still tunneling. Talking about bandwidth and
> > > > > infrastructure waste...
> > > > --
> > > > Mark Andrews, ISC
> > > > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > > > PHONE: +61 2 9871 4742                 INTERNET: marka () isc org
> > -- 
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742                 INTERNET: marka () isc org
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka () isc org