Bernie,
Bernie Volz (volz) wrote:
It would seem quite dangerous to enable/disable DHCPv6 clients
arbitrarily based on bit settings in un-protected RA messages.
This support already exists with the definition of the M O bits.
Setting these in an RA means run DHCPv6. As Joseph pointed out, the
Brian:
If the client doesn't do anything with that knowledge, there's no reason
for the client to follow draft-cha-ipv6-ra-mo-00.txt and there's no
threat or danger.
If the client does start DHCPv6 because of receipt of M or O set, then
draft-cha-ipv6-ra-mo-00.txt really adds no additional
Brian - I think this thread reasonably supports the conclusion that
the text in the RFCs does not clearly capture the consensus reached of
the IETF. In my opinion, some sort of additional information is
needed because I've gotten questions on exactly this issue. I think
the problem can
OK, I'm going to wade back into this and say that I believe we've
botched things. Let's take a typical client implementor, who looks at,
say, RFCs 4861, 4862 and/or RFC 3315 (the DHCPv6 spec).
Question: just when are they supposed to invoke DHCPv6? All the time?
Only if the M or O bits are set?
On 13 okt 2008, at 18:12, Alain Durand wrote:
IPv6 is IPv4 with longer addresses. Why would we want to make life
more
complex with more choices wrt starting DHCPv6?
That ship sailed when DCHPv6 was invented even though IPv6 works fine
without it.
I vote for 1.
This is the IETF; you
Iljitsch van Beijnum [EMAIL PROTECTED] writes:
Seems to me that this is simple enough: no bits, no DHCP. Always is
not an acceptable out of the box behavior. (!!!)
In the spirit of keeping this discussion productive and about
engineering, can you please explain why (operationally or
On 13 okt 2008, at 18:20, Thomas Narten wrote:
In the spirit of keeping this discussion productive and about
engineering, can you please explain why (operationally or technically)
that always is not acceptable?
Ok:
On 13 okt 2008, at 18:19, Iljitsch van Beijnum wrote:
I don't have any use
On 13 okt 2008, at 17:40, Thomas Narten wrote:
OK, I'm going to wade back into this and say that I believe we've
botched things. Let's take a typical client implementor, who looks at,
say, RFCs 4861, 4862 and/or RFC 3315 (the DHCPv6 spec).
Question: just when are they supposed to invoke
The answer is inconsistent. Some DHCPv6 clients default to a /64
prefix so that this scenario works, and systems with those clients can
and do interoperate.
Those clients are broken however. Getting a DHCPv6 address assigned and
assuming it is /64 (and on link) is wrong. If there is no prefix
I'd like to encourage serious and thoughtful conversation about this
topic. Thomas is right (I know he's right, because I agree with him)
that the current text in various RFCs is unclear. Even if it does not
conflict with the previous consensus about how to deal with the M/O
flags, the
A DHCPv6 server will answer all Solicits, even if it has no addresses to
provide, with an Advertise. The difference is in the status code in each IA.
I don't believe that is an accurate statement. According to RFC 3736 section
5.1, clients and servers implement the following messages for
Iljitsch van Beijnum [EMAIL PROTECTED] writes:
On 13 okt 2008, at 18:19, Iljitsch van Beijnum wrote:
I don't have any use for DHCPv6. I need a way to shut up DHCPv6
clients that may end up visiting my network. Running DHCPv6 in a
network that doesn't support is is especially harmful
Greg - RFC 3736 is simply a summary of how DHCPv6 can be used with a
two-message exchange and a simplified server. It was intended to
describe how DHCPv6 might be implemented in network elements to
provide other configuration information without the overhead of a
full-featured DHCPv6
-Original Message-
From: Thomas Narten [mailto:[EMAIL PROTECTED]
My understanding is that when clients invoke DHC, and there are no
DHCP servers, they backoff and retransmit, eventually stablizing as is
governed by the following (from RFC 3315):
MRT specifies an upper bound on
On Mon, 13 Oct 2008, Thomas Narten wrote:
1) We could ignore/deprecate the MO bits and simply have any
client that implements DHCP invoke DHCP without even bothering to
see what the MO flags say. I.e, the way DHCPv4 works today.
IMO, this approach would work fine. Indeed, it has the
15 matches
Mail list logo
