Your IP Address is: 38.103.63.61
RE: [moonv6] /120 prefix length at UNH
From: Bound, Jim (jim.bound@hp.com)
Date: 10/14/03
- Next message: schultz@io.iol.unh.edu: "Re: [moonv6] /120 prefix length at UNH"
- Previous message: Bound, Jim: "RE: [moonv6] /120 prefix length at UNH"
- Maybe in reply to: Alain Durand: "[moonv6] /120 prefix length at UNH"
- Next in thread: schultz@io.iol.unh.edu: "Re: [moonv6] /120 prefix length at UNH"
moonv6 post from "Bound, Jim" <jim.bound@hp.com>
I have to ask a pretty basic question, in addition to agreeing with
Ben's logic, and that is what Moonv6 has done does not preclue EUIs at
all in anyway? What is the problem exactly and this does not break 3513?
What am I missing? This is just prefix for the core has nothing to do
with low order 64bis for ND or Autoconfig etc. Thanks.
/jim
> -----Original Message-----
> From: schultz@io.iol.unh.edu [mailto:schultz@io.iol.unh.edu]
> Sent: Tuesday, October 14, 2003 10:20 PM
> To: Alain Durand
> Cc: moonv6@iol.unh.edu
> Subject: 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