[ppml] IPv6>>32

Houle, Joseph D (Joe), CMO jdhoule at att.com
Mon May 16 14:32:06 EDT 2005

   I'm starting to get lost here.  One doesn't "get" an address block
unless one is willing to "manage addresses", right.   Whether "get"
means "assign" or "allocate".   Dorm rooms don't get blocks, ports don't
get blocks, students don't get blocks, single-offices don't get blocks,
employees don't get blocks.  (OK, so maybe there are exceptions to the
"offices" and "employees" in a research or non-production environment).
   In general the IP infrastructure provider: corporate IT, university
telecom, etc "gets" the block for the subnet, then end hosts
"learn/picks" an address out of that block (likely via some form of auto

Joe Houle

-----Original Message-----
From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On Behalf Of
Stephen Sprunk
Sent: Monday, May 16, 2005 11:38 AM
To: Owen DeLong; Larry J. Blunk; Michael.Dillon at radianz.com
Cc: ppml at arin.net
Subject: Re: [ppml] IPv6>>32

Thus spake "Owen DeLong" <owen at delong.com>
> --On Friday, May 13, 2005 3:05 PM -0500 Stephen Sprunk
<stephen at sprunk.org> wrote:
> > I agree that's what the letter of the policy states, but I can't
> > that's what was intended.
> >
> > Assigning a /48 to each student violates simple common sense.
> > Yes, I know there's enough /48s for every human on the planet,
> > but we're going to have serious problems down the road if we start
> > allocating a /48 for each host, which is the vast majority of cases
> > in a dorm today and for the conceivable future.  Burning a /64 per
> > host is bad enough, but I could be convinced to accept that if Merit
> > said they liked that idea (I personally doubt they do).
> I think by default, each student should get a /64.  If, however, the
> student expresses need for multiple subnets, then, I think a /48 is
> exactly what was intended under the policy.

"   Assignment address space size
Assignments are to be made in accordance with the existing guidelines
(RFC3177,RIRs-on-48), which are summarized here as:
- /48 in the general case, except for very large subscribers
- /64 when it is known that one and only one subnet is needed by design
- /128 when it is absolutely known that one and only one device is

This appears to prevent ISPs (i.e. universities) from assigning anything
longer than a /48 to customers (i.e. students) in most cases unless they
not qualify as "end sites".

"6.2.9. End site
An end site is defined as an end user (subscriber) who has a business
relationship with a service provider that involves:
1. that service provider assigning address space to the end user
2. that service provider providing transit service for the end user to
3. that service provider carrying the end user's traffic.
4. that service provider advertising an aggregate prefix route that
the end user's assignment"

AFAICT, each student at a university qualifies as an "end site".
unless the specific criteria for a /64 or /128 are met for each student,
which is certainly not guaranteed nor feasible to determine, each
must be assigned a /48.

Interestingly, the above could also be (mis)read to say that businesses
to assign a /48 to each employee.

> I'm not making any value judgments at this point as to whether the
> policy is good or bad, but, that is my understanding of its intent.

I think you may be right about its intent, but if we are correct then
intent was not correctly written into the policy.

> > Not to mention what actually deploying such a setup would do to
> > the existing IPv4 addressing plan.  What are the odds ARIN would
> > approve Merit (today, ignoring their legacy /8) requesting an IPv4
> > /12 so they could give every student (38,000 cited elsewhere in
> > the thread) a /29?  That's what we'd be forcing them to do if they
> > had to provide a subnet per student.
> This is where IPv4 != IPv6 and there does start to be some reason to
> consider that addresses are no longer scarce.  In IPv4, it is hard to
> imagine assigning a static address to every person on the planet.
> In IPv6, it is hard to imagine the population being sufficient that
> each person could not have a /64.

I'm working with the assumption that v6 and v4 will be deployed with the
same topology, which has yet to be disproven.  If we give each student
IPv6 /64 (or /48), then we'd need to give them an IPv4 /29 or shorter

> > Perhaps some vendor will come out with a whiz-bang device that
> > allows a shared IPv4 subnet while routing IPv6 natively, but I'm not
> > aware of anything like that on the market or even proposed for
> > development.
> I guess I'm not understanding the situation you are describing here.
> There are several ways to do 6:4 gateways which would allow you to
> run v4 and v6 on the same segment.

We're talking about native v4 and native v6, not some gatewayed or NATed

> There is nothing which requires you to match your v4 topology to
> your v6 topology.

I'm not aware of any off-the-shelf consumer-grade solution which allows
to be different.

> Most Cisco routers can bridge any protocol which is not routed on
> a given interface, so, I think CRB should be possible between v4/v6
> as you describe, although I have not tested it.

So now we're requiring every student to purchase a Cisco router (not a
Linksys box) to put in front of their one or two PCs?  And we don't even
know if that would work?

Keep in mind that most dorms (and hotels) currently allow users to plug
in a
single PC and start working without any sort of L3 device in the unit at
all.  Any IPv6 model that requires putting an L3 device in the unit is
already making things more expensive, possibly to the point of making
transition not financially viable, and there doesn't appear to be any
around that if we require a /48 per user or per room.  Even a /64 per
or per room significantly raises the administrative costs for both v4
v6, but at least that's technically feasible today.


Stephen Sprunk      "Those people who think they know everything
CCIE #3723         are a great annoyance to those of us who do."
K5SSS                                             --Isaac Asimov

More information about the ARIN-PPML mailing list