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

Re: [moonv6] /120 prefix length at UNH

New Message Reply Date view Thread view Subject view Attachment view

From: Tim Chown (tjc@ecs.soton.ac.uk)
Date: 10/15/03


moonv6 post from Tim Chown <tjc@ecs.soton.ac.uk> Hi Jim,

For info 6NET uses /64 as I believe does GEANT.

However some NRENs use whatever they like, typically /126.

Using /64 here seems OK but something to flag for discussion (amongst a very long list you guys will probably find :)

Tim

On Wed, Oct 15, 2003 at 10:50:46AM -0400, Robert J. Rockell wrote:
> moonv6 post from "Robert J. Rockell" <rrockell@sprint.net>
> Understood. We know that if we leave holes open, people will use them to
> invalidate our testing. Taking the most conservative approach, imho, will
> give us the best credibility when we release our results.
>
> Thanks
> Rob Rockell
> SprintLink
> (+1) 703-689-6322
> It's just a little pin prick...
> -----------------------------------------------------------------------
>
> On Wed, 15 Oct 2003, Bound, Jim wrote:
>
> ->Robert,
> ->
> ->This is good input to our thinking and important. I can live with /64.
> ->
> ->What I am more concerned about on this list now is an invalid
> ->interpretation by Alain of EUI-64 technically regarding use for our
> ->processes? If it is invalid I want that stated and if it is valid then
> ->I want that stated. So now I am more concerned that we all agree on
> ->this section of 3315.
> ->
> ->But if we move to /64 I will support what you and other providers state
> ->as you know best in my opinion. I also support RIR using /64
> ->completely. The idea here was to be conservative and I agree with Ben
> ->on initial approach if the providers are ok with not worrying about that
> ->and the mail list I am fine with that completely as one technical input
> ->data point on the list. But it is important we interpret the specs
> ->correctly on Moonv6 too.
> ->
> ->Thanks
> ->/jim
> ->
> ->> -----Original Message-----
> ->> From: Robert J. Rockell [mailto:rrockell@sprint.net]
> ->> Sent: Wednesday, October 15, 2003 8:36 AM
> ->> To: Bound, Jim
> ->> Cc: Alain Durand; moonv6@iol.unh.edu
> ->> Subject: RE: [moonv6] /120 prefix length at UNH
> ->>
> ->>
> ->> If you want to test interoperabilty with
> ->> best-common-practices (in the grammatical sense of the
> ->> phrase, not the IETF one) then you need to look at
> ->> /64's. This is the way the majority of the 6bone is
> ->> numbered. I don't see
> ->> motivation for /120. If you are going to just pick a random
> ->> netwmask, use /127, to save space, on all p2p links. the
> ->> notion of reserved and broadcast on a p2p link have changed,
> ->> after all...
> ->>
> ->> I can tell you from a provider standpoint, we ALWAYS use /64.
> ->> Personal opinions on whether or not this is needed/smart
> ->> aside, this is how things get deployed. I would recommend
> ->> consistency, if you want to maximize impact of your testing.
> ->>
> ->>
> ->> Thanks
> ->> Rob Rockell
> ->> SprintLink
> ->> (+1) 703-689-6322
> ->> It's just a little pin prick...
> ->> --------------------------------------------------------------
> ->> ---------
> ->>
> ->> On Wed, 15 Oct 2003, Bound, Jim wrote:
> ->>
> ->> ->moonv6 post from "Bound, Jim" <jim.bound@hp.com>
> ->> ->Folks,
> ->> ->
> ->> ->I would like to make something clear as we have this discussion.
> ->> ->
> ->> ->This is not an IETF issue other than IETF can help with
> ->> interpretation
> ->> ->of the standard though I await Alain's response as I see no
> ->> spec issue
> ->> ->here at all per his mail with /120.
> ->> ->
> ->> ->But the IETF has NOTHING TO SAY ABOUT MOONV6 DEPLOYMENT OR
> ->> OPERATIONS.
 > ->> ->NOTHING AT ALL. They are a standards body we are an implementation
> ->> ->deployment body.
> ->> ->
> ->> ->Thanks
> ->> ->/jim
> ->> ->
> ->> ->> -----Original Message-----
> ->> ->> From: Alain Durand [mailto:Alain.Durand@Sun.COM]
> ->> ->> Sent: Tuesday, October 14, 2003 9:51 PM
> ->> ->> To: moonv6@iol.unh.edu
> ->> ->> Subject: [moonv6] /120 prefix length at UNH
> ->> ->>
> ->> ->>
> ->> ->> 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