[arin-discuss] IPv6 End User Assignments
Ted Mittelstaedt
tedm at ipinc.net
Wed May 6 18:10:44 EDT 2009
What separates the customer's broadcast domains from yours?
I assume there's a router at the customer (DSL modem, cable modem or
whatever) and the /64 is on the customer side of the CPE. If that
is the case, what is on your side of the CPE? Part of the /64 or
a separate subnet?
Ted
> -----Original Message-----
> From: Aaron Hughes [mailto:aaronh at bind.com]
> Sent: Wednesday, May 06, 2009 2:24 PM
> To: Ted Mittelstaedt
> Cc: 'Matthew Wilder'; arin-discuss at arin.net
> Subject: Re: [arin-discuss] IPv6 End User Assignments
>
>
> On Wed, May 06, 2009 at 01:37:33PM -0700, Ted Mittelstaedt wrote:
> >
> > Aaron,
> >
> > Was space-wasting the only reason you went with a /64
> instead of a
> > /48 or /56?
>
> Yes.
>
> > For your single point customers, is this /64 intended for use on
> > just a single PC? Such as for example a DSL customer with just a
> > single PC plugged into a bridged DSL modem?
>
>
> /64 was for any customer with one broadcast domain, 1 to
> several machines. If they have multiple broadcast domains
> (more than one), they get a 48. 56 vs 64 was just a flip a
> coin decision to some extent. There was a ton of discussion
> on the topic and I just picked one and moved forward. At
> some point you just have to implement and get some real world
> experience.
>
> I did look at assigning something smaller than a 64 initially
> and tools turned out to be the deciding factor. Since all of
> my v4 tools such as allocations/assignments/router
> config/CRM/ERP/etc store the v4 address as 4 x INT(11), it
> was rather easy to convert hex to dec and store in the same
> tables. The mask in this case is also an INT(11). Adding
> the additional octets would have been much more effort.
>
> > Do you consider a customer
> > who has a wireless router with 5-6 PC's on it as needing a
> subnet ie
> > /48?
>
> No. a 64 should be fine for that kind of customer assuming
> all the objects are in the same broadcast domain (e.g.
> bridged mode on the wireless router).
>
> Cheers,
> Aaron
>
>
>
> >
> > Ted
> >
> >
> > > -----Original Message-----
> > > From: arin-discuss-bounces at arin.net
> > > [mailto:arin-discuss-bounces at arin.net] On Behalf Of Aaron Hughes
> > > Sent: Wednesday, May 06, 2009 10:59 AM
> > > To: Matthew Wilder
> > > Cc: arin-discuss at arin.net
> > > Subject: Re: [arin-discuss] IPv6 End User Assignments
> > >
> > > Matthew,
> > >
> > > You are highly likely correct. Regional aggregation will be
> > > implemented by any reasonable ISP. Also, if ISPs did
> assign /48s to
> > > each customer your math is correct, each ISP of this massive size
> > > would need a /21ish. Also, I agree a /48 is excessive for each
> > > customer.
> > >
> > > For a moment we should separate policy from operations.
> > >
> > > As architects in the planning phase of a v6 roll-out we
> get to plan
> > > for company needs, customer needs, aggregation, reachability,
> > > scalability, etc etc etc. One of the aspects we should
> all evaluate
> > > is wasting space.
> > >
> > > When I rolled out v6 to my customers, I made the company policy
> > > decision to assign /64s to customers by default and /48s to those
> > > who requested more than one subnet. This made it rather easy to
> > > have 2 pools of aggregatable regional space for customer
> > > assignments. The company policy / network architecture
> fits within
> > > certain, what I will call, ARIN guidelines in that it does not
> > > violate ARIN policy. Policy has never dictated
> operational practice.
> > >
> > > That being said, policy should _allow_ for an implementation that
> > > requires /48 assignments to the LIRs respective
> customers. There are
> > > implementations where this makes sense.
> > > It is highly unlikely that very large ISPs will be
> assigning 48s to
> > > each customer as it would be a waste of space.
> > >
> > > This list, just like Planing / Design / Architecture / Operations
> > > groups are full of opinions about how things should be
> implemented.
> > > Time will reveal best practices and policies will get updated to
> > > reflect them as long as the operational community is
> involved in the
> > > policy process.
> > >
> > > I am involved in many v6 implementations and none of them
> assign 48s
> > > by default.
> > >
> > > Cheers,
> > > Aaron
> > >
> > >
> > > On Wed, May 06, 2009 at 11:28:47AM -0600, Matthew Wilder wrote:
> > > > This is where it gets interesting. I doubt the worst case
> > > is a /23. Remember, IPv6 has so many bits for the very
> purpose of
> > > clean summarization and easy subnetting.
> > > >
> > > > Comcast might want to regionalize their subnetting. And
> > > then within each region, they might want to have a nice big block
> > > for each edge router so they don't have to constantly add address
> > > resources to the router. All of a sudden, instead of
> assuming a 90%
> > > utilization of that block (which is heinously unreasonable and
> > > inconsistent with IPv6 intentions) you are looking at
> maybe 20 - 30%
> > > utilization at the /48 assignments. Now they need probably a /21
> > > for those customers.
> > > >
> > > > This gets this sort of ISP into the hairy edge of what the
> > > HD ratio allows in the best case. Assuming a /48
> assignment to an
> > > end user counts as 100% utilization of the entire /48
> subnet, then
> > > they will probably squeak through on the Threshold
> > > (https://www.arin.net/policy/nrpm.html#six7).
> > > >
> > > > And this discussion here is exactly why I originally
> > > through out the question. Why would an ISP assign a /48
> so that a
> > > consumer can have two large layers of subnetting (16 bits
> of subnet
> > > address to be exact) at the expense of their own routing and
> > > summarization?
> > > >
> > > > MW
> > > >
> > > >
> > > > Aaron Hughes wrote:
> > > > > US population is roughly 300 million.
> > > > > A /19 would cover 536,870,912 /48s A /27 would cover
> 536,870,912
> > > > > /56s
> > > > >
> > > > > 7 billion in the world.
> > > > > A /15 would cover 8,589,934,592 /48s A /23 would cover
> > > 8,589,934,592
> > > > > /56s.
> > > > >
> > > > > Number of total Internet users in the world roughly 1.5
> > > billion or
> > > > > 20% of the population.
> > > > > Number of total Internet users in the US roughly 220 million.
> > > > >
> > > > > Let's say you are Comcast.. ~ 25 million customers. Worst
> > > cast you
> > > > > are looking at a /23 to give each one a /48, or roughly
> > > best case a
> > > > > /39 for 2x/64s per customer.
> > > > >
> > > > > This is not a repeat of v4.
> > > > >
> > > > > IPv4 ISPs gave a single host to the outside interface of
> > > the CPE AND
> > > > > some flavor of space in (RFC1918) 10.0.0.0/8, 172.16.0.0/12,
> > > > > 192.168.0.0/16 for their inside interface. If we
> > > implement NAT in
> > > > > v6, we will stop progress with end-to-end application
> > > > > development and make the same silly mistakes we made
> with v4.
> > > > > The
> > > mistake was
> > > > > not wasting space but rather not making the leap to IPv6
> > > when we identified the potential for growth so many years ago.
> > > > > Instead we focused on CIDR/VLSM and NATing everything
> we could
> > > > > to extend the life of a dying protocol.
> > > > >
> > > > > It is perfectly reasonable to have standard
> assignment sizes to
> > > > > create an appropriate customer expectation. Your customers do
> > > > > not need to know what a subnet is. If the standard was, for
> > > example, to
> > > > > assign a /64 to the WAN and /64 to the LAN with SLAAC
> > > enabled, the
> > > > > customer behaves the same way they do today. Those who
> > > request more
> > > > > space know what they are doing (generally speaking).
> > > > >
> > > > > Cheers,
> > > > > Aaron
> > > --
> > >
> > > Aaron Hughes
> > > aaronh at bind.com
> > > (703) 244-0427
> > > Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C
> > > C6 B8 http://www.bind.com/
> > > _______________________________________________
> > > ARIN-Discuss
> > > You are receiving this message because you are subscribed to the
> > > ARIN Discussion Mailing List (ARIN-discuss at arin.net).
> > > Unsubscribe or manage your mailing list subscription at:
> > > http://lists.arin.net/mailman/listinfo/arin-discuss
> > > Please contact info at arin.net if you experience any issues.
> > >
>
> --
>
> Aaron Hughes
> aaronh at bind.com
> (703) 244-0427
> Key fingerprint = AD 67 37 60 7D 73 C5 B7 33 18 3F 36 C3 1C
> C6 B8 http://www.bind.com/
>
More information about the ARIN-discuss
mailing list