[arin-discuss] IPv6 End User Assignments
Aaron Hughes
aaronh at bind.com
Wed May 6 18:19:14 EDT 2009
Separate /64s in this case where there are point-to-points. For the colocation customers, it's just a /64 of the connected interface.
Cheers,
Aaron
On Wed, May 06, 2009 at 03:10:44PM -0700, Ted Mittelstaedt wrote:
>
> 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/
> >
--
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