Microsoft's participation in World IPv6 day

Mark Andrews marka at isc.org
Mon Jun 6 02:20:26 CDT 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