IPv6 end user addressing

Cameron Byrne cb.list6 at gmail.com
Sat Aug 6 14:19:10 UTC 2011


On Aug 6, 2011 2:11 AM, "Owen DeLong" <owen at delong.com> wrote:
>
> I'm not the only person who prefers /48 and hopefully most ISPs will
eventually
> come around and realize that /56s don't really benefit anyone vs. /48s.
>
> Hurricane Electric has been handing out /48s upon request to our customers
and
> users of our IPv6 tunnel services. We do not anticipate changing that
policy.
>
> Owen
>

A lot of good that /48 will do while HE rides out their on going peering war
and customers are missing a wide swath of the ipv6 routing table.

Cb

> On Aug 5, 2011, at 3:56 PM, Frank Bulk wrote:
>
> > Let's clarify -- /48 is much preferred by Owen, but most ISPs seem to be
> > zeroing in on a /56 for production.  Though some ISPs are using /64 for
> > their trials.
> >
> > Frank
> >
> > -----Original Message-----
> > From: Owen DeLong [mailto:owen at delong.com]
> > Sent: Friday, August 05, 2011 12:21 PM
> > To: Brian Mengel
> > Cc: nanog at nanog.org
> > Subject: Re: IPv6 end user addressing
> >
> > /56 is definitely preferable to /64, but, /48 really is a better choice.
> >
> > /56 is very limiting for autonomous hierarchical deployments.
> >
> > It's not about number of subnets. It's about the ability to provide some
> > flexibility
> > in the breadth and depth of bit fields used for creating hierarchical
> > topologies
> > automatically.
> >
> > Owen
> >
> > On Aug 5, 2011, at 9:17 AM, Brian Mengel wrote:
> >
> >> In reviewing IPv6 end user allocation policies, I can find little
> >> agreement on what prefix length is appropriate for residential end
> >> users.  /64 and /56 seem to be the favorite candidates, with /56 being
> >> slightly preferred.
> >>
> >> I am most curious as to why a /60 prefix is not considered when trying
> >> to address this problem.  It provides 16 /64 subnetworks, which seems
> >> like an adequate amount for an end user.
> >>
> >> Does anyone have opinions on the BCP for end user addressing in IPv6?
> >
>



More information about the NANOG mailing list