Microsoft's participation in World IPv6 day
Mark Andrews
marka at isc.org
Mon Jun 6 07:20:26 UTC 2011
In message <DFE74319-378F-4134-B521-452328B179F0 at 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 at isc.org
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka at isc.org
More information about the NANOG
mailing list