[ppml] IPv6>>32

[Owen DeLong]

--On Monday, May 16, 2005 10:38 AM -0500 Stephen Sprunk
<stephen at sprunk.org> wrote:

> 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
>> > imagine 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.
> 
> "6.5.4.1   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
> connecting."
> 
> 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
> do not qualify as "end sites".
> 
No... In most cases, it can be assumed that a student needs only one subnet
by design.  If the student invalidates said assumption, then, a /48 is
required.

> "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
> other sites
> 3. that service provider carrying the end user's traffic.
> 4. that service provider advertising an aggregate prefix route that
> contains the end user's assignment"
> 
> AFAICT, each student at a university qualifies as an "end site".
> Therefore, unless the specific criteria for a /64 or /128 are met for
> each student, which is certainly not guaranteed nor feasible to
> determine, each student must be assigned a /48.
> 
Right.  However, the ISP can easily make presumptive policies that state
"It is assumed unless the student requests otherwise that the student's
use of campus internet in their dorm room does not require more than
a single subnet.  As such, the default allocation to students is a /64.
If more is needed, the student should submit a written request and a /48
will be assigned."

I believe such a policy would meet the test and that ARIN would accept
allocations done through such a policy as compliant.

> Interestingly, the above could also be (mis)read to say that businesses
> need to assign a /48 to each employee.
> 
If the business is acting as an LIR for the employee rather than treating
the employee as part of said businesses' end site, then, yes, that would
be true.  However, the same option above would apply.


>> 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 that
> intent was not correctly written into the policy.
> 
I'm not convinced of that.  I think that some wordsmithing or clarification
could improve readability and clarity, but, I'm not convinced that the
policy does not say what it means.  Remember, also, that the policy you
are criticizing states that it is strictly a summary of the RFC.  A detailed
read of the RFC (which I don't have time to do right now, and, don't
remember clearly enough to quote from memory), I believe, reveals the
intent pretty clearly as I stated it.

> 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 an
> IPv6 /64 (or /48), then we'd need to give them an IPv4 /29 or shorter too.
> 
Why?  Why do we necessarily have to give the student any IPv4 space at all?
I have yet to understand this particular assumption or where it came from.
Ignoring your feeling that this assumption should be disproven, I just can't
find a basis for the assumption to be made in the first place.

>> 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
> service.
> 
Again, I'm not sure why someone who is receiving end-site V6 allocation
necessarily needs a V4 assignment.  I understand you think that is
desirable,
but, I don't understand why you think it is necessary.

>> 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
> them to be different.
> 
I'm not aware of any need for such a device.  At the consumer-grade end of
things, I think it makes much more sense for the consumer to be either V4
or V6.  At some point, one must pick a minimum unit of change.  The single
consumer (household, dorm-room, etc.) seems like a pretty small unit to me.

>> 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 $50
> Linksys box) to put in front of their one or two PCs?  And we don't even
> know if that would work?
> 
No.  We're requiring every student to be either V6 or V4.  If they're V4,
then,
they may be limited to a single public address.  If they're V6, they get
additional abilities to get public addresses.

> 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 the transition not financially viable, and there doesn't appear to
> be any way around that if we require a /48 per user or per room.  Even a
> /64 per user or per room significantly raises the administrative costs
> for both v4 and v6, but at least that's technically feasible today.
> 
There's nothing that says a campus couldn't support this under existing
policy.  Imagine it this way:

	Default: A single device is plugged into the campus network and
		receives a /128 address from the dorm's /64 segment.

	Student requests single network:
		Student is assigned a static /64 which student configures
		into L3 device local segment.  Student connects remote
		segment to wall.  Remote receives dynamic /128 address
		from dorm's /64 segment and advertises students /64 to
		upstream default gateway.

	Student requests multiple networks:
		Student is assigned a static /48.  Otherwise, same as
		previous example.  Student can build any appropriate
		topology within dorm room beyond that.

Owen


-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20050516/076f79e0/attachment.sig>