Comcast Activates First Users With IPv6 Native Dual Stack Over DOCSIS

[Mark Smith]

On Wed, 2 Feb 2011 07:47:38 -0500
Jared Mauch <jared at puck.nether.net> wrote:

> 
> On Feb 2, 2011, at 7:33 AM, Mark Smith wrote:
> 
> > On Wed, 2 Feb 2011 07:05:58 -0500
> > Jared Mauch <jared at puck.nether.net> wrote:
> > 
> >> 
> >> On Feb 2, 2011, at 3:41 AM, Mark Smith wrote:
> >> 
> >>> On Mon, 31 Jan 2011 16:50:09 -0500
> >>> John Jason Brzozowski <jjmb at jjmb.net> wrote:
> >>> 
> >>>> FYI
> >>>> 
> >>>> http://blog.comcast.com/2011/01/comcast-activates-first-users-with-ipv6-nat<http://blog.comcast.com/2011/01/comcast-activates-first-users-with-ipv6-native-dual-stack-over-docsis.html>
> >>>> ive-dual-stack-over-docsis.html<http://blog.comcast.com/2011/01/comcast-activates-first-users-with-ipv6-native-dual-stack-over-docsis.html>
> >>>> 
> >>> 
> >>> Why a single /64? You certainly won't be only getting just a /32, and
> >>> I'm sure you've got way less than 4 billion customers. A /60 would have
> >>> been a conservative option if you wanted to dip your toe in the water,
> >>> yet still would allowing people to use subnets in their home if they
> >>> wanted to perform some of their own experiments - your trial
> >>> participants are more likely to have a few routers in their home that
> >>> they may want to use to experiment with IPv6 and IPv6 routing.
> >> 
> >> This is comcasts experiment, not the end-user.  If the end-user wants to experiment, they can go find access via some other provider (eg: tunnelbroker, etc).
> >> 
> > 
> > So you work for Comcast?
> 
> Nope.
> 
> I work for another corporate beast.  While I may take the consideration of my customers into account when doing my own beta/product launches, I certainly do not let them drive the agenda.
> 

I'm not sure I agree with that philosophy. Companies only exist to
serve customers. They create the demand that ultimately dictates the
agenda the company follows, assuming the company continues to want to
service those customers.

The fundamental purpose of a beta test/trial is to see if customers
like or don't like what you're thinking you might decide to put into
production. Artificially constraining what they can do in the trial,
unnecessarily, reduces the usefulness of the beta test / trial, as it
may prevent different and unexpected uses from emerging.

> I support and applaud the efforts that John is undertaking at Comcast.  While he may decide that a /64 is suitable for his customer base, as they commonly have a single lan. 

That's all their customers will ever be able to have if the customer
only ever gets a single /64. 

> Going from a single IP to 2^64 available is a significant step forward.
> 

Not really in the context of IPv6. IPv6 allocations and
assignments are all about subnets, not node addresses. The *smallest*
allocation and assignment is a /64 when providing IPv6 access to
multiple devices. If there is the remotest possibility that just one
customer will want to create (or have future devices automatically
create for them) multiple subnets, then it's easier and cheaper to just
give out multiple subnets to everybody.

An update to RFC3177 is close to being published. Here is what is
recommended -

The IETF recommends that any policy on IPv6 address
   assignment policy to end sites take into consideration:

      - it should be easy for an end site to obtain address space to
        number multiple subnets (i.e., a block larger than a single /64)
        and to support reasonable growth projections over long time
        periods (e.g., a decade or more).

      - the default assignment size should take into consideration the
        likelihood that an end site will have need for multiple subnets
        in the future and avoid the IPv4 practice of having frequent and



draft-ietf-v6ops-3177bis-end-sites-00.txt                       [Page 7]

INTERNET-DRAFT                                            March 10, 2008


        continual justification for obtaining small amounts of
        additional space

      - Although a /64 can (in theory) address an almost unlimited
        number of devices, sites should be given sufficient address
        space to be able to lay out subnets as appropriate, and not be
        forced to use address conservation techniques such as using
        bridging. Whether or not bridging is an appropriate choice is an
        end site matter.

      - assigning a longer prefix to an end site, compared with the
        existing prefixes the end site already has assigned to it, is
        likely to increase operational costs and complexity for the end
        site, with insufficient benefit to anyone.

      - the operational considerations of managing and delegating the
        reverse DNS tree under ip6.arpa on nibble vs. non-nibble
        boundaries should be given adequate consideration





> While the more tech savvy of us is clearly part of the target tests for this IPv6 service, there is also a need to test customers that are not as enlightened by the various *NOG and IETF lists.  They are important.
> 
> I'm more worried that the current threshold for 'acceptable broken ipv6' is set at 0.01% by some major players for a global enabling of their websites for returning AAAA + A records.  I want to get the broken network elements fixed.  If you see any in the NTT network, please let me know as I want to solve it.
> 
> - Jared