[143532] in North American Network Operators' Group
Re: IPv6 end user addressing
daemon@ATHENA.MIT.EDU (Owen DeLong)
Thu Aug 11 18:11:27 2011
From: Owen DeLong <owen@delong.com>
In-Reply-To: <4E444F50.8070603@ispalliance.net>
Date: Thu, 11 Aug 2011 15:09:10 -0700
To: Scott Helms <khelms@ispalliance.net>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Aug 11, 2011, at 2:53 PM, Scott Helms wrote:
> 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.
>=20
> 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.
>=20
I think i did below. However, in my region of the world, most service =
providers don't provide the
CPE and most customers are BYOB.
>> 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.
>=20
> 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?
>=20
In the home and the consumer is responsible. The fact that you utterly =
want to avoid
the concept of topology in the home shows me that you really aren't =
understanding
where things already are in many homes and where they are going in the =
future.
ISP->CPE Head End Router-><Multiple additional routers and other deivces =
some of which have additional routers and or topology behind them.
Some definitions of the above pseudo-diagram already exist in many =
people's
homes (and I am including Joe six-pack in this) today.
Lots of users string wired and wireless routers together in multiple =
layers with and
without NAT in various (and often creative albeit not necessarily =
constructive) ways
within their homes.
Today, all of that is hidden from you because their CPE head end router =
(the one
that talks to your supplied bridge in most cases) NATs it all behind one =
address.
In the future, it will be semi-visible in that you'll see the additional =
addresses, but,
you still won't have to do anything about it because it's routed and all =
you have
to do is deliver the /48 instead of delivering the /128 (equivalent of =
the /32 you
deliver today).
Owen
>>=20
>> Owen
>>=20
>> On Aug 11, 2011, at 1:28 PM, Scott Helms wrote:
>>=20
>>> Owen,
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>>=20
>>>>=20
>>>> Owen
>>>>=20
>>>> On Aug 10, 2011, at 11:43 AM, Scott Helms wrote:
>>>>=20
>>>>> Tim,
>>>>>=20
>>>>> 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
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On 8/10/2011 12:57 PM, Tim Chown wrote:
>>>>>> On 10 Aug 2011, at 16:11, Scott Helms wrote:
>>>>>>=20
>>>>>>> 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.
>>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>> Tim
>>>>>>=20
>>>>>>> On 8/10/2011 9:02 AM, Owen DeLong wrote:
>>>>>>>> Bridging eliminates the multicast isolation that you get from =
routing.
>>>>>>>>=20
>>>>>>>> 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.
>>>>>>>>=20
>>>>>>> --=20
>>>>>>> Scott Helms
>>>>>>> Vice President of Technology
>>>>>>> ISP Alliance, Inc. DBA ZCorum
>>>>>>> (678) 507-5000
>>>>>>> --------------------------------
>>>>>>> http://twitter.com/kscotthelms
>>>>>>> --------------------------------
>>>>>>>=20
>>>>>>>=20
>>>>> --=20
>>>>> Scott Helms
>>>>> Vice President of Technology
>>>>> ISP Alliance, Inc. DBA ZCorum
>>>>> (678) 507-5000
>>>>> --------------------------------
>>>>> http://twitter.com/kscotthelms
>>>>> --------------------------------
>>>>>=20
>>>=20
>>> --=20
>>> Scott Helms
>>> Vice President of Technology
>>> ISP Alliance, Inc. DBA ZCorum
>>> (678) 507-5000
>>> --------------------------------
>>> http://twitter.com/kscotthelms
>>> --------------------------------
>>=20
>=20
>=20
> --=20
> Scott Helms
> Vice President of Technology
> ISP Alliance, Inc. DBA ZCorum
> (678) 507-5000
> --------------------------------
> http://twitter.com/kscotthelms
> --------------------------------
