On 2011-05-30, at 22:27 , Philip Homburg wrote:
If you are really worried about this, then I guess you can also just assign
two prefixes to a single link and use one for SLAAC and the other for DHCPv6.
Of course this is possible, but this also means, that a node not doing DHCPv6
(because it
On 2011-05-30, at 22:05 , Ray Hunter wrote:
Which source address (SLAAC/DHCPv6) would be used by the client for an
outbound session if a SLAAC address and a DHCPv6 were both configured on the
same link and with the same prefix, in the absence of a flag?
As I already said in my previous
On 2011-05-31, at 11:19 , Philip Homburg wrote:
No, ND is more clever than that. All traffic between prefixes that are on-link
goes directly between the hosts. Even when the prefix is off-link it is
possible for the router the send a redirect ICMP to cause further traffic
to be directly
On 2011-05-31, at 12:10 , Mohacsi Janos wrote:
If you get /64 and you need more subnets from your provider then probably you
asked something wrong.
Or you have the wrong provider... but if this is the only provider available in
your area, that can offer you a symmetric 100 MBit/s fibre
On 2011-05-31, at 12:35 , Philip Homburg wrote:
The difference is that IPv4 has a model of one subnet per link.
Why do you think so? The computer I'm using right now has two IP addresses of
different IP subnets on the same network interface (and I really mean the same
layer 2 network, there
On 2011-05-31, at 11:57 , Mohacsi Janos wrote:
What about the ordering, if you get more than one DHCP addresses?
How would this be any different to the situation as we have it today? It's
rather strange arguing to say something introduces a problem, if this is not a
new problem, but one that
On 2011-05-31, at 13:09 , Mohacsi Janos wrote:
What collision? You should use 'u' bit accrdingly:
1 - if automaticaly assigned
0 - if manually assigned.
But it is also 0 for SLAAC addresses w/ privacy extension and those are
automatically assigned, in example.
You can argument for
On 2011-05-31, at 13:38 , Mohacsi Janos wrote:
I disagree with introduction of another flags. This requires substantial
changes in the codes Which will take ages
I took a look at the IPv6 implementations of Mac OS X (which comes from the BSD
world) and Linux a couple of weeks ago.
On 2011-05-31, at 14:01 , Philip Homburg wrote:
I would say that having an interface with two IPv4 addresses is not really in
the model.
Maybe it is rather uncommon, but it is allowed and also supported by all major
operating systems; just wanted to point that out.
But SHOULD is a bit
On 2011-05-31, at 15:28 , Mark Smith wrote:
1. Manual configured IP
2. DHCP
3. SLAAC with Privacy Extension
4. SLAAC with Interface ID
Some people might prefer SLAAC over DHCP.
That's why things like these are usually configurable. Just because there
exists a well defined default
On 2011-05-23, at 23:56 , Mark Smith wrote:
Christopher Morrow christopher.mor...@gmail.com writes:
Just say that at startup time, invoke SLAAC DHCPv6 both. Then use
whatever is available. That would have been simple and
predictable. (And avoided 10GB of mailing list discussion!)
I'm
On 2011-03-16, at 10:08 , Mohacsi Janos wrote:
Yes. DAD can fail, and you system log you will see.
How will this help a network admin, when the system log says, that a server
that is supposed to have a certain fixed IP or a DHCP client, that is also
supposed to have a certain fixed IP
On 2011-03-16, at 11:05 , Sander Steffann wrote:
The chance of this happening is *very* *very* small.
The chances that a MD5 hash of any data will ever be exactly zero (all octets
are zero) is ridiculous tiny. It is probably so extremely unlikely that the
world would rather be destroyed by a
On 2011-03-15, at 21:35 , james woodyatt wrote:
Let me try again... there is no tiny change to existing RFCs that can make
it *impossible* for address conflicts to arise.
This seems an rather odd reasoning to me; it's like saying An algorithm, that
solves only one specific problem, is bad
On 2011-03-16, at 11:45 , Mohacsi Janos wrote:
The servers are always working. Newcomers cannot hijack their addresses
since DAD will fail for them
Maybe on your network, but on our network some servers are only working at
certain office times or when they are needed. Some servers are
On 2011-03-16, at 11:27 , Philip Homburg wrote:
You look up the MAC address for that IPv6 address and then block the MAC
address on your switches. Problem solved.
Sure, that will work. However, that means I have to invest time and work to
solve a problem, that would have easily been
to always peacefully coexist within a single network,
where hosts might come and go any time. Has this issue really been
intentionally ignored, because given 2^64 addresses, the likeliness of a
collision was seen as too unlikely to ever take place in real-life?
Regards,
Markus Hanauska
On 2011-03-15, at 16:58 , Philip Homburg wrote:
I think the answer is that is statistically very unlikely that on a single
subnet, a 64-bit random number will ever be equal to any address manually
configured in DHCP.
I'd say this entirely depends on how the (usually pseudo-) random number
On 2011-03-15, at 19:27 , Philip Homburg wrote:
If you just need stable addresses, then you can also put your own random
numbers in DHCP.
Of course everything will be fine if you exclusively use DHCPv6. You can have a
pool with addresses for well known devices, so the same device always
19 matches
Mail list logo
