Home
Vendor
Project
  Phase I
Press
  Phase I
About
You Are Using IPv4 To Access This Site
Your IP Address is: 38.103.63.61

Re: [moonv6] /120 prefix length at UNH

New Message Reply Date view Thread view Subject view Attachment view

From: Alain Durand (Alain.Durand@Sun.COM)
Date: 10/15/03


moonv6 post from Alain Durand <Alain.Durand@Sun.COM> Let me be very clear upfront that this is _not_ an IETF discussion. My understanding of Moonv6 is to verify interoperability of IPv6 implementation according to the relevant RFCs, RFC3513 being one of them.

  1. RFC3513, section 2.5.1

>> 2.5.1 Interface Identifiers
>>
>> For all unicast addresses, except those that start with binary
>> value
>> 000, Interface IDs are required to be 64 bits long and to be
>> constructed in Modified EUI-64 format.

RFC3513 does _not_ make any distinction on the type of links this applies to;
so this is to be applied to _all_ links, even point to point links. If you use a /120 prefix for a point to point link, then the interface ID
on this link will not be in Modified EUI-64 format. period. So this would be a violation of RFC3513 that is listed in the JTA 5.1 as emerging.

One may or may not like RFC3513 section 2.5.1, I, for one, do no really like it much,
but this is not the point.
The point is the spec says to do something, and IMHO, Moonv6 should concentrate on testing the implementations of the specs and not come out with cleverer ideas on how to architect the global unicast address space differently.
If there are problems with the spec, Moonv6 should report it to IETF. But for now, it still remain to be proven that RFC3513, section 2.5.1 is a problem.

The fact that some vendor support /120 prefixes is not relevant to this discussion.
The fact that some folks on the 6bone have used in the past /124 or other weird length prefixes is also not relevant. It is not because some people decided to do things a certain way in their corner of the universe
that this should be replicated in a larger context.

Bottom line, my point is that if you want to use /120 prefixes in Moonv6,
nothing will prevent you from doing it, but you will not be testing implementations
against an RFC listed in the JTA 5.1, but against something different, not documented in any standard.

2. Address space conservation.

I'm very well aware of the concern about address space conservation in the Internet.
However, to get an idea of how large the address space really is, I would
recommend people to re-read RFC3177.

What is at stake about address conservation are the upper bits of the addresses (i.e. bits 3-48), not the lower bits.
I'm actually more concerned at this point about getting more people to use IPv6 than by very fine grain address space conservation measures.

However, if this ever becomes a problem, RFC3513 can be revisited at anytime.

3. What to do about point to point links?

One idea that has been circulated many times is not to allocate a subnet at all
to point to point links but just allocate one IPv6 address at each end coming
from each side's address space and then simply use a static route to say that
your peer address is directly reachable on the other side of the link.

I think testing this in the context of Moonv6 would be very valuable.

New Message Reply Date view Thread view Subject view Attachment view

This archive was generated by hypermail 2.1.7 : 12/01/06 EST