Hi,
Sorry for slow response, I had somehow missed your message.
Vijayrajan ranganathan wrote:
But regarding the 2nd solution, I am wondering how vmware and xen
are able to offer a unique MAC address to each virtual OS.
I mean, what address space do these come from?
Both Xen and VMware
Hi Tim,
This is a wonderful idea!!
Do you by any chance know whether Sun has a patent on this?
Is it possible for me to adopt a variation of this idea in my
implementation?
Thanks to everyone for sharing your thoughts, much appreciated !!
Thanks & Regards,
Vijay
On Wed, Jul 8, 2
Hi Aleksi,
These are indeed good ideas.
The 1st solution is not feasible in my case as I am stuck with an
existing implementation.
But regarding the 2nd solution, I am wondering how vmware and xen
are able to offer a unique MAC address to each virtual OS.
I mean, what address space
Hi David,
Yes, indeed the implementation I am working on (it is FreeBSD based)
is generating autoconf addresses in the same manner. It picks up the
host-id part from the configured Link-local address.
Thanks & Regards
Vijay
On Fri, Jul 3, 2009 at 11:58 AM, David Malone wrote:
> On Thu
On Fri, Jul 03, 2009 at 07:28:31AM +0100, David Malone wrote:
> On Thu, Jul 02, 2009 at 12:40:20PM +0530, Vijayrajan ranganathan wrote:
> > Is there a standard solution for this kind of problem?
>
> On some OSes it is possible to control the host part of the
> autoconfigured address by manually co
On Thu, Jul 02, 2009 at 12:40:20PM +0530, Vijayrajan ranganathan wrote:
> Is there a standard solution for this kind of problem?
On some OSes it is possible to control the host part of the
autoconfigured address by manually configuring a link local address
before the interface is brought up. The h
Vijayrajan ranganathan wrote:
I did consider using vlans but this requires huge changes in existing network
topology and switch-side re-configurations.
Is there a standard solution for this kind of problem?
One often used solution is that either the host OS or another virtual OS
functions a
Hi Thomas,
I have an interface that is shared by multiple virtual hosts on the box, each of
which requires autoconf addresses. The one standard address can't be shared
as, in my implementation, the IP address is the one that uniquely identifies
the virtual host for an incoming connection.
These ad
BTW, why do you want or need to do this? Why do you not not want to
generate a standard Interface Identifier like everyone else?
Thomas
> Hi Everyone,
> I have an ethernet interface for which I am defining the Interface-ID
> in a different manner.
> For an ethernet interface with MAC "34-56-78-
Hi Tony,
Reply inline.
> Technically you would comply with the RFCs, but the FFFE value was
> negotiated with the IEEE to avoid colliding with their eventual conversion
> to EUI-64. If you pick other values for the actual mac you need to talk to
> the IEEE, but if it is only the IPv6 address the b
nteroperate with your methodology.
>
> Best Regards,
>
> Jeffrey Dunn
> Info Systems Eng., Lead
> MITRE Corporation.
> (301) 448-6965 (mobile)
>
>
> -Original Message-----
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Bob
> Hinden
> Sent:
ard J. (Jeremy) CONTRACTOR
Cc: nav...@nav6tf.org; ipv6@ietf.org
Subject: RE: Implementation specific Interface-ID
Vijay et al.,
RFC 4291 states in section 5.1:
"For all unicast addresses, except those that start with the binary value
000, Interface IDs are required to be 64 bits long
From: Duncan, Richard J. (Jeremy) CONTRACTOR
[mailto:richard.duncan_contrac...@dtra.mil]
Sent: Friday, June 26, 2009 9:22 AM
To: Dunn, Jeffrey H.; Bob Hinden
Cc: ipv6@ietf.org
Subject: RE: Implementation specific Interface-ID
Jeff-
Yes, but nothing in the IEEE spec states anything that using the F
pv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of Bob
Hinden
Sent: Thursday, June 25, 2009 7:51 AM
To: Duncan, Richard J. (Jeremy) CONTRACTOR
Cc: nav...@nav6tf.org; ipv6@ietf.org
Subject: Re: Implementation specific Interface-ID
Duncan,
> Vijay-
>
> The only thing I could fi
Duncan,
Vijay-
The only thing I could find is that it's just standard practice to
use FF
FE.. For example, if you use privacy extensions then there is no FF FE
because its address is hashed right?
No, there is no FF FE because the IIDs created by RFC4941 have local
significance. From se
Vijay-
The only thing I could find is that it's just standard practice to use FF
FE.. For example, if you use privacy extensions then there is no FF FE
because its address is hashed right? I think it's just a 16 bit filler for a
MAC 48.. See below from the IEEE:
http://standards.ieee.org/regauth
Technically you would comply with the RFCs, but the FFFE value was
negotiated with the IEEE to avoid colliding with their eventual conversion
to EUI-64. If you pick other values for the actual mac you need to talk to
the IEEE, but if it is only the IPv6 address the bits will work until an
implement
17 matches
Mail list logo
