Your IP Address is: 38.103.63.61
RE: [moonv6] /120 prefix length at UNH
From: Bound, Jim (jim.bound@hp.com)
Date: 10/15/03
- Next message: Robert J. Rockell: "RE: [moonv6] /120 prefix length at UNH"
- Previous message: Alain Durand: "[moonv6] /120 prefix length at UNH"
- Maybe in reply to: Alain Durand: "[moonv6] /120 prefix length at UNH"
- Next in thread: Alain Durand: "Re: [moonv6] /120 prefix length at UNH"
- Reply: Alain Durand: "Re: [moonv6] /120 prefix length at UNH"
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.
>
>
This archive was generated by hypermail 2.1.7 : 12/01/06 EST