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

Re: [moonv6] /120 prefix length at UNH

New Message Reply Date view Thread view Subject view Attachment view

From: bmanning@karoshi.com
Date: 10/15/03


moonv6 post from bmanning@karoshi.com
>
> 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.

	this general idea has been around for literally years.
	most early 6bone users built BGP peers w/ /127 addresses.
	(and there is now a draft/rfc about some folks opinion that
	using /127s is bad) 
	
	For us, (EP.NET) we use /120s for core/p2p links between
	our peers and our internal links and have since 2000.

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

	statistically, those numbers are in the noise.
	more importantly is the ability to tightly bind	
	the actual, in-use addresses to mgmt systems.
	advertizing "extra" space does have one or two 
	attack vectors that are not found in tightly constrained
	p2p links.

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

	not all core structures are based on p2p links,
	so using /64 and /48 segments in a transit structure
	are valid.

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

	well, its not that much of a precedent... 6bone
	and some commercial services use /120 and /124 
	addressing in their core networks.  It is
	setting a precedent for its community of interest
	but is only following the lead of others.

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

New Message Reply Date view Thread view Subject view Attachment view

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