In message <dfe74319-378f-4134-b521-452328b17...@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: ma...@isc.org > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org