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

RE: [moonv6] /120 prefix length at UNH

New Message Reply Date view Thread view Subject view Attachment view

From: Bound, Jim (jim.bound@hp.com)
Date: 10/15/03


moonv6 post from "Bound, Jim" <jim.bound@hp.com> Alain,

> 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.

Good.

>
>
> 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.

I do not interpret 2.5.1 as you do. A /120, /115, or /64 prefix does not preclude that a EUI-64 format for the low order bits exist. If UNH had used a /58 then that would be a violation of 3513.

>From 3513:

2.5.4 Global Unicast Addresses

   The general format for IPv6 global unicast addresses is as follows:

   | n bits | m bits | 128-n-m bits | 

   +------------------------+-----------+----------------------------+
   | global routing prefix  | subnet ID |       interface ID         |
   +------------------------+-----------+----------------------------+

   where the global routing prefix is a (typically hierarchicallystructured)     value assigned to a site (a cluster of subnets/links),    the subnet ID is an identifier of a link within the site, and the    interface ID is as defined in section 2.5.1.

   All global unicast addresses other than those that start with binary    000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as    described in section 2.5.1. Global unicast addresses that start with    binary 000 have no such constraint on the size or structure of the    interface ID field.

A /120 prefix does not say that n+m != 64. It simply states that the high order bits of n == 8 and m == 58, which == 64 leaving 64 for EUI-64. /120 prefix is not a violation of 3513.

>
> 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.

I agree the issue is are we counter to 3513 and I say we are not.

>
> 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.

I do not agree it is totally compliant with 3513.

>
>
>
> 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.

I agree and why I support /120. By not wasting high order bits we lead with correct attitude and this is not non compliant to 3513.

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

Hardly. Note in JTA 5.1 that the addressing architecture is "emerging" not "mandated".

>
>
>
> 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.

Allocation of a subnet is an administrative policy to the core.

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

That is our objective here clearly.

/jim
>
> - Alain.
>
>

New Message Reply Date view Thread view Subject view Attachment view

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