nanog mailing list archives

Re: IPv6 end user addressing


From: Scott Helms <khelms () ispalliance net>
Date: Thu, 11 Aug 2011 17:53:20 -0400

On 8/11/2011 5:28 PM, Owen DeLong wrote:
You're talking about the front end residential gateway that you manage. I'm talking about
the various gateways and things you might not yet expect to provide gateways that residential
end users will deploy on their own within their environments.

The question I asked you is why should I as the service provider deploy routers rather than bridges as CPE gear for residential customers. If you didn't understand the question or didn't want to address that specific questions that's fine, but you certainly didn't answer that question.

Of course, in order for the ISP to properly support these things in the home, the ISP
needs to terminate some form of IPv6 on some form of CPE head-end router in the
home to which he will (statically or otherwise) route the /48 whether it is statically
assigned or configured via DHCPv6-PD.

What is a CPE head-end router? That seems like an oxymoron. Where would such an animal live, in the home or the head end/central office? Who is responsible for purchasing it and managing it in your mind?


Owen

On Aug 11, 2011, at 1:28 PM, Scott Helms wrote:

Owen,

    The fact that you're immediately going to routing means you don't understand the problem.  The costs I'm talking about 
don't have anything to do with routing or any of the core gear and everything to do with the pieces at the customer premise.  Routers cost 
more to purchase than bridges because there is more complexity (silicon&  software).  Routers also cost more to manage for a service 
provider in almost all cases for residential customers.  There are reasons to deploy routing CPE in some cases (the use cases are increasing 
with IP video in DOCSIS systems) but they are still very nascent.

On 8/10/2011 7:24 PM, Owen DeLong wrote:
I'm pretty sure that I understand those things reasonably well. I'm quite certain that it doesn't
cost an ISP significantly more to deploy /48s than /56s as addresses don't have much of a
cost and there is little or no difficulty in obtaining large allocations for ISPs that have lots of
residential users. The difference between handing a user's CPE a /56 and a /48 will not make
for significant difference in support costs, either, other than the possible additional costs of
the phone calls when users start to discover that /56s were not enough.


Owen

On Aug 10, 2011, at 11:43 AM, Scott Helms wrote:

Tim,

    Hence the "might".  I worry when people start throwing around terms like routing in the home that they don't understand the 
complexities of balancing the massive CPE installed base, technical features, end user support, ease of installation&   managemenet, and 
(perhaps most importantly) the economics of mass adoption.  This one of the choices that made DSL deployments more complex and expensive than 
DOCSIS cable deployments which in turn caused the CEO of AT&T to say their entire DSL network is obsolete.
http://goo.gl/exwqu



On 8/10/2011 12:57 PM, Tim Chown wrote:
On 10 Aug 2011, at 16:11, Scott Helms wrote:

Neither of these are true, though in the future we _might_ have deployable technology that allows for automated routing 
setup (though I very seriously doubt it) in the home.  Layer 2 isolation is both easier and more reliable than attempting it 
at layer 3 which is isolation by agreement, i.e. it doesn't really exist.
Well, there is some new effort on this in the homenet WG in IETF.

For snooping IPv6 multicast it's MLD snooping rather than IGMP.  We use it in our enterprise since we have multiple 
multicast video channels in use.

Tim

On 8/10/2011 9:02 AM, Owen DeLong wrote:
Bridging eliminates the multicast isolation that you get from routing.

This is not a case for bridging, it's a case for making it possible to do real
routing in the home and we now have the space and the technology to
actually do it in a meaningful and sufficiently automatic way as to be
applicable to Joe 6-Mac.

--
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000
--------------------------------
http://twitter.com/kscotthelms
--------------------------------


--
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000
--------------------------------
http://twitter.com/kscotthelms
--------------------------------


--
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000
--------------------------------
http://twitter.com/kscotthelms
--------------------------------



--
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000
--------------------------------
http://twitter.com/kscotthelms
--------------------------------



Current thread: