Your IP Address is: 38.107.191.84
Re: [moonv6] /120 prefix length at UNH
From: schultz@io.iol.unh.edu
Date: 10/14/03
- Next message: Alain Durand: "[moonv6] /120 prefix length at UNH"
- Previous message: Bound, Jim: "RE: [moonv6] /120 prefix length at UNH"
- 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"
- Reply: bmanning@karoshi.com: "Re: [moonv6] /120 prefix length at UNH"
- Reply: Tony Hain: "RE: [moonv6] /120 prefix length at UNH"
moonv6 post from schultz@io.iol.unh.edu
Alain,
Excellent point. This is a tough topic.
We understand that using a /64 on edge networks where auto-config takes place is something we are doing. Hosts should always support a /64.
Using /120 and /124 addresses is coming from our service provider-based designs.
Didn't we learn anything from being conservative about address allocation from IPv4? People are always claiming in technology that we "have enough to last forever". That is definitely never the case. I would make the argument here that being conservative is always better. Just think of all the subnet space we will save in service provider networks by using /120 or /124.
Do we want people in the technology field referencing the Moonv6 network design as a reason that all the IPv6 addresses are depleated? Was there a valid reason for /64? I currently fail to understand the logic behind that design in core networks with point-to-point links.
I completely understand RFC 3513, but I think that the above arguments may support what we are doing.
I fully encourage discussion around this topic, because I do understand there will be many opinions here. This IS setting a precedent, and I would like this project to set the correct one.
I look forward to your input.
-Ben
> moonv6 post from Alain Durand <Alain.Durand@Sun.COM>
> From what our engineer reported from UNH tests,
> the plan on record is to use /120 prefixes for
> the backbone links at UNH.
>
> This would be a violation of RFC 3513, section 2.5.1.
>
> I'm concerned that if this network setup gets published,
> it would set up a dangerous precedent.
>
> - Alain.
>
>
> 2.5.1 Interface Identifiers
>
> Interface identifiers in IPv6 unicast addresses are used to identify
> interfaces on a link. They are required to be unique within a subnet
> prefix. It is recommended that the same interface identifier not be
> assigned to different nodes on a link. They may also be unique over
> a broader scope. In some cases an interface's identifier will be
> derived directly from that interface's link-layer address. The same
> interface identifier may be used on multiple interfaces on a single
> node, as long as they are attached to different subnets.
>
> Note that the uniqueness of interface identifiers is independent of
> the uniqueness of IPv6 addresses. For example, a global unicast
> address may be created with a non-global scope interface identifier
> and a site-local address may be created with a global scope interface
> identifier.
>
> 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.
>
This archive was generated by hypermail 2.1.7 : 12/01/06 EST
