Hello, Teemu.
Thank you for your clarification.
>>Since DHCPv6 server is also able to assign multiple addresses
>>to single client depending on the poliy, the host can activate
>>its server with the assigned address except the one used by
>>itself if it has
>>DHCPv6 server installed. Then, other
Christian Huitema wrote:
>
> Let's observe first that while there have been many proposal for variable
> length addresses, the length are always somehow bounded. For example, there
> will be an address length field in the packet header, and there will be some
> limited number of bits to encode
> > I can't see why IPv6 having variable length addresses would have
> > prevented people creating NAPT66 if /128s were allocated.
>
> Human hoarding instinct combined with old practices from the IPv4 days.
> You can see similar behaviour in areas where the PSTN uses fixed-length
> numbers (e.g. N
Mark Smith wrote:
>
> I'm curious as to why you think this might be the case?
>
> From what I understand, fixed length addresses were chosen for a few
> reasons (a) only CLNS had variable length addresses, verses every other
> protocol that didn't (e.g. applelalk, IPv4, IPX etc.), so there was
>
Hi Joseph,
>Right as long as DHCPv6 server can assign only one address to the host.
>One more thing I would like to know is whether the host is
>allowed to configure multiple arbitrary addresses in the
>scenario of SLAAC plus ND proxy in the service provider's
>view. If other hosts in LAN conf
Hello, all.
I would like to share my interests on this issue and discuss DHCPv6
based solution more.
Solutions suggested by Pekka are below.
1) run DHCPv6 again, with a different DUID or client identifier (could
it get more /128's that way,
2) use DHCPv6 IAs to request multiple addresses? Then it
Hi Pekka,
>-Original Message-
>From: ext Pekka Savola [mailto:[EMAIL PROTECTED]
>Sent: 30 October, 2008 09:26
>But, maybe there is an implementable workaround to this
>operational issue. Would it be possible for the host to
>either 1) run DHCPv6 again, with a different DUID or client
>Pardon my ignorance. Is there a concrete case of this in some access
>
>network standard?
>
>(I heard some rumors thereabout)
I have heard rumors as well that were in favor of using DHCPv6 for address
allocation also in some cellular accesses.
By my understanding this is not yet so concrete pr
On Mon, 03 Nov 2008 09:59:03 +1300, Brian E Carpenter
<[EMAIL PROTECTED]> wrote:
>> Failing silently or loudly are no options. You cannot blame the operator
>> if you expect him to subsidized your device sale. You cannot fail if
your
>> competitor "just works" by using NAPT66.
>
> Agreed, but you
On 2008-10-31 21:09, Rémi Denis-Courmont wrote:
> On Fri, 31 Oct 2008 15:31:27 +1300, Brian E Carpenter
> <[EMAIL PROTECTED]> wrote:
>>> Well I'm not completely certain whether involving users here would
>>> provide very good experience,
>> I see your argument, but failing silently doesn't seem lik
Hi Peter,
On Sat, 01 Nov 2008 17:03:44 -0700
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Brian E Carpenter wrote:
> >
> >> I would not like to see IPv6 NAPT, but I see that as a real risk if
> >> network is using DHCPv6 for allocating hosts just /128 addresses but at
> >> the same time is not
Brian E Carpenter wrote:
I would not like to see IPv6 NAPT, but I see that as a real risk if
network is using DHCPv6 for allocating hosts just /128 addresses but at
the same time is not willing to delegate prefixes on demand.
Agreed.
The sad part is that it's probably inevitable given the
On Fri, 31 Oct 2008 15:31:27 +1300, Brian E Carpenter
<[EMAIL PROTECTED]> wrote:
>> Well I'm not completely certain whether involving users here would
>> provide very good experience,
>
> I see your argument, but failing silently doesn't seem like a
> good idea.
It is only worse. What will actua
Teemu,
On 2008-10-30 18:42, [EMAIL PROTECTED] wrote:
> Brian,
>
> (changed topic to be more descriptive)
>
>>> Consider cellular host case:
>>> - host implements e.g. ND proxy and DHCPv6 PD for WAN connection
>>> sharing
>>> - host attaches to a network where only DHCPv6 happens to be used
>>
> I have a couple of related questions regarding /128s:
>
> 1) can a requesting router use DHCPv6 prefix delegation to
> obtain /128's from a delegating router?
yes, but that seems a little contrived.
> 2) Must a requesting router examine the M&O bits in another
> router's RAs before determining
Re: [dhcwg] /128 address allocation and "localized
>IPv6 addressspace exhaustion",was RE: Brokenness of specs
>w.r.t. client behavior with M&O bits
>
>On Thu, 30 Oct 2008, [EMAIL PROTECTED] wrote:
>>>> Consider cellular host case:
>>>> - h
On Thu, 30 Oct 2008, [EMAIL PROTECTED] wrote:
Consider cellular host case:
- host implements e.g. ND proxy and DHCPv6 PD for WAN connection
sharing
- host attaches to a network where only DHCPv6 happens to be used
- host gets single /128 IPv6 address from DHCPv6
- host tries to get some prefixes
Brian,
(changed topic to be more descriptive)
>> Consider cellular host case:
>> - host implements e.g. ND proxy and DHCPv6 PD for WAN connection
>> sharing
>> - host attaches to a network where only DHCPv6 happens to be used
>> - host gets single /128 IPv6 address from DHCPv6
>> - host tries
Hello, all.
I would like to see what is the IETF consensus on this topic.
Currently we have no further conclusion on this topic than the point that it is
very difficult to choose the silver bullet among several options listed by
Thomas and Ralph. However, I also believe that we need to encourag
Hello, Teemu.
Thank you for your clarification.
> Consider cellular host case:
> - host implements e.g. ND proxy and DHCPv6 PD for WAN connection sharing
> - host attaches to a network where only DHCPv6 happens to be used
> - host gets single /128 IPv6 address from DHCPv6
> - host tries to get som
Teemu,
On 2008-10-27 19:50, [EMAIL PROTECTED] wrote:
> Hi Joseph,
>
> Thank you for your responses, comment inline
>
>> As for your question, I would say that it depends on implementations.
>> AFAIK, there are already several opensources like ISC DHCP
>> which supports IA_NA(maybe IA_TA) as we
On Tue, Oct 28, 2008 at 11:06:10AM -0400, James Carlson wrote:
> Neither is the current solution described by the RFCs: you are
> required to set up both your IPv6 routers and your DHCPv6 server in
> order for the system to work consistently.
James, we're talking about different things. You're st
On Tue, Oct 28, 2008 at 04:18:48PM +0100, Iljitsch van Beijnum wrote:
> Obviously multicasts are useful so I'm not saying we can't have any. But in
I just want to say that what I'm actually hearing in this is that
you'll waffle on the performance criteria you invented so long as it
means you get
On 24 okt 2008, at 18:38, David W. Hankins wrote:
What if DHCPv6 servers do not exist? AFAIK, in this thread, the cost
of unnecessary multicast DHCPv6 messages which may be prevented
through M&O bits are being discussed.
That's a separate issue. Iljitsch is proposing that Multicasts must
be
On Thu, Oct 23, 2008 at 08:15:54AM -0400, James Carlson wrote:
> Unless your DHCPv6 server box also happens to be an IPv6 router for
> the prefix in question, I don't think you should be trying to do
> anything with RS/RA messages.
I agree completely, I would rather not ever transmit an RA.
But s
On Fri, Oct 24, 2008 at 11:23:55AM +0900, hyunwook cha wrote:
> What if DHCPv6 servers do not exist? AFAIK, in this thread, the cost
> of unnecessary multicast DHCPv6 messages which may be prevented
> through M&O bits are being discussed.
That's a separate issue. Iljitsch is proposing that Multic
Hi Joseph,
Thank you for your responses, comment inline
>As for your question, I would say that it depends on implementations.
>AFAIK, there are already several opensources like ISC DHCP
>which supports IA_NA(maybe IA_TA) as well as IA_PD. And
>Windows 2008 server also does. Even though detail
Hi Joseph,
>> Used link-layer does have an impact: on cellular networks
>the link-layer is nowadays most often opened on-demand (i.e.
>when an application starts), or quickly reopened e.g. if
>network connection is temporarily lost for any reason. In the
>future always-on connectivity becomes
gt;Cc: David W. Hankins; [EMAIL PROTECTED]; List Mailing; DHC WG
>>Subject: Re: [dhcwg] Brokenness of specs w.r.t. client
>>behavior with M&O bits
>>
>>In order for this to be a valid rejoinder, it would have to be
>>the case that the cellular industry was plan
;>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>>On Behalf Of ext Dunn, Jeffrey H.
>>Sent: 17 October, 2008 17:20
>>To: TJ; IPV6 List Mailing
>>Cc: DHC WG; Dunn, Jeffrey H.
>>Subject: Re: [dhcwg] Brokenness of specs w.r.t. client
>>behavior with M&O
Hello, David.
A few comments are inserted.
2008/10/23 David W. Hankins <[EMAIL PROTECTED]>:
> Just a few things that I think are potential factual errors or
> misreads that need clarifying.
>
> On Tue, Oct 14, 2008 at 09:48:42AM +0200, Iljitsch van Beijnum wrote:
>> It's not a question of "problem
Hello, Tony.
Thank you for your agreement and interests in the issues being
addressed by the draft "draft-cha-ipv6-ra-mo-00.txt".
Since I feel that we need to discuss how to solve the issues more, I
would like to insert my comments as below.
2008/10/24 Tony Hain <[EMAIL PROTECTED]>:
> I agree wi
> As for dealing with conflicting M&O, just XOR the received set.
Before the world erupts over trivia, that should have said OR
I clearly need more sleep,
Tony
IETF IPv6 working group mailing list
ipv6@ietf.org
Administr
I agree with Joseph that these should be combined and published.
As for dealing with conflicting M&O, just XOR the received set. When the
state changes from 1 to 0 (actually in either direction), after a random
delay re-query DHCP to verify the lease time/config information. In a
managed configur
Replying to your change of subject, not (necessarily) the message
itself:
At the last IETF meeting, I captured a bunch of wireless traffic
during the plenary with the idea to analyze the broadcasts to see how
much airtime they take up. Unfortunately, I didn't get around to it
and deleted
On 17 okt 2008, at 22:54, Bernie Volz (volz) wrote:
In my view, I believe encouraging implementers to use the M & O bits
is
a good thing (the RFC 2462 "should") but a client's local policy
should
be able to override that (always on, never on, or "use M&O" if
possible).
Fully agree. However
On 16 okt 2008, at 19:48, Ted Lemon wrote:
The whole notion that we need
to specify a binary format for every new piece of data that may need
to be configured and then wait until both clients and servers are
updated is completely outdated.
Updating an XML schema every time you get a new option
Hi,
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
>Behalf Of ext Ted Lemon
>Sent: 16 October, 2008 20:49
>To: Iljitsch van Beijnum
>Cc: David W. Hankins; [EMAIL PROTECTED]; List Mailing; DHC WG
>Subject: Re: [dhcwg] Brokenness o
PROTECTED] [mailto:[EMAIL PROTECTED] On
>Behalf Of TJ
>Sent: Friday, October 17, 2008 9:07 AM
>To: 'IPV6 List Mailing'
>Cc: 'DHC WG'
>Subject: RE: [dhcwg] Brokenness of specs w.r.t. client
>behavior with M&O bits
>
>Not trying to oversimplify thing
Just a few things that I think are potential factual errors or
misreads that need clarifying.
On Tue, Oct 14, 2008 at 09:48:42AM +0200, Iljitsch van Beijnum wrote:
> It's not a question of "problematic yes/no". More multicasts means less
> performance for other stuff. Obviously ARP and ND already
On Fri, Oct 17, 2008 at 05:31:54PM -0700, JINMEI Tatuya / 神明達哉 wrote:
> In this case, the DHCPv6 server (or a relay, which would also rely on
> a router and wouldn't work in this situation anyway) can send out an
> RA with the router lifetime being 0 and with a prefix information
> option. The ser
Hello, Ralph and all.
I would like to insert another option into the following list.
draft-ietf-ipv6-ra-mo-flags-01.txt
I am not clear why this WG document failed to proceed. However, I view
this document as nice base docuement since I think that it seems that
we do not have clear reason to deprec
On 2008-10-17 05:18, David W. Hankins wrote:
> On Tue, Oct 14, 2008 at 03:10:06PM +0800, Kadirvel Chockalingam Vanniarajan
> wrote:
>> 1) Is there a way for a IPv6 client to distinguish between a authoritative
>> RA vs non-authoritative RA? I guess not but I may be wrong. I refer to an
>> unauth
technology.
Thanks
Kadir
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ralph Droms
Sent: Friday, October 17, 2008 4:52 PM
To: IPV6 List Mailing; DHC WG
Subject: Re: [dhcwg] Brokenness of specs w.r.t. client behavior with M&O bits
I've been track
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
>David W. Hankins
>Sent: Friday, October 17, 2008 12:51 PM
>To: DHC WG
>Cc: IPV6 List Mailing
>Subject: Re: [dhcwg] Brokenness of specs w.r.t. client behavior with M&O
>bits
>
>
At Tue, 14 Oct 2008 07:48:32 +0300 (EEST),
Pekka Savola <[EMAIL PROTECTED]> wrote:
> I don't see why M/O bits would need to be completely deprecated (they
> could still be hints about what should be available in the network).
>
> I've yet to see a DHCPv6 client implementation that would listen t
At Wed, 15 Oct 2008 08:51:05 -0700,
"David W. Hankins" <[EMAIL PROTECTED]> wrote:
> > Correct, and that is the motivation for
> > draft-ietf-6man-ipv6-subnet-model-02.txt. See Section 3, for example.
>
> That draft completely misses the original point. This isn't a
> question of whether "ifconfi
ts in the first place). Perhaps this work should just be
extended or reframed to provide the motivations for DHCPv6 clients to
use the bits.
- Bernie
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Ralph Droms (rdroms)
Sent: Friday, October 17, 2008 7:22 AM
To:
or may not take on.
- Wes
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
David W. Hankins
Sent: Wednesday, October 15, 2008 11:51 AM
To: DHC WG
Cc: IPV6 List Mailing
Subject: Re: [dhcwg] Brokenness of specs w.r.t. client behavior with M&O
bits
On Wed, O
On Oct 17, 2008, at 4:21 AM, Ralph Droms wrote:
1. Is the following text an accurate summary of the previous IETF
consensus on the definition and use of M/O bits:
The M/O flags indicate the availability of DHCPv6 service for
address assignment and other configuration information,
respectiv
On Oct 16, 2008, at 7:18 AM, Iljitsch van Beijnum wrote:
Anyone in the cellular industry reading this? What about firing up
transmitters and using up battery every 120 seconds for a protocol
that you KNOW isn't going to do anything useful?
In order for this to be a valid rejoinder, it would hav
On Fri, Oct 17, 2008 at 07:21:34AM -0400, Ralph Droms wrote:
> 1. Is the following text an accurate summary of the previous IETF
> consensus on the definition and use of M/O bits:
>
> The M/O flags indicate the availability of DHCPv6 service for
> address assignment and other configuration info
>More practically, how do you configure an interface if you don't know
>the subnet mask?
# ip -6 addr add 2001:DB8::1/128 dev lo
That, along with a few FIB entries, is all the IPv6
configuration some nodes will ever need.
Fred
[EMAIL PROTECTED]
-
bject: RE: [dhcwg] Brokenness of specs w.r.t. client behavior with
M&O bits
Not trying to oversimplify things here, but to me it makes the most
sense to
start with what we have working now and *not* make any broad, sweeping
changes. To do otherwise is not only a tremendous disservice to all of
Not trying to oversimplify things here, but to me it makes the most sense to
start with what we have working now and *not* make any broad, sweeping
changes. To do otherwise is not only a tremendous disservice to all of
those who have implemented/adopted IPv6 (or are considering doing so) but
also
> From: Ralph Droms <[EMAIL PROTECTED]>
> 1. Is the following text an accurate summary of the previous IETF
> consensus on the definition and use of M/O bits:
>
>The M/O flags indicate the availability of DHCPv6 service for
>address assignment and other configuration information,
>res
Ny own answers, to kick off discussion...
1. Is the following text an accurate summary of the previous IETF
consensus on the definition and use of M/O bits:
The M/O flags indicate the availability of DHCPv6 service for
address assignment and other configuration information,
respectively.
I've been tracking this discussion about the M/O flags, which seems to
be going in several different directions. I thought it might be
useful to try to get some agreement on what needs to be done so we can
focus on coming to consensus on a course of action. It also seems
like a small grou
In-line...
On Oct 16, 2008, at Oct 16, 2008,5:48 PM, Iljitsch van Beijnum wrote:
On 16 okt 2008, at 16:52, Ralph Droms wrote:
My understanding is (and I would happily have my understanding
corrected) that there should *never* be a prefix length associated
with address assignment, whether t
On 16 okt 2008, at 23:36, David W. Hankins wrote:
Iljitsch, the last time we discussed this (on nanog@), we argued
technical points until you finished with "I like RA." I will again
admit freely that I can't (or won't) change what you do or do not
like. It has never been my intent to adjust yo
Iljitsch, the last time we discussed this (on nanog@), we argued
technical points until you finished with "I like RA." I will again
admit freely that I can't (or won't) change what you do or do not
like. It has never been my intent to adjust your desires.
I think this time you are leading us thr
On Tue, Oct 14, 2008 at 03:10:06PM +0800, Kadirvel Chockalingam Vanniarajan
wrote:
> 1) Is there a way for a IPv6 client to distinguish between a authoritative RA
> vs non-authoritative RA? I guess not but I may be wrong. I refer to an
> unauthorized host sending out RA to be non-authoritative R
On 16 okt 2008, at 16:52, Ralph Droms wrote:
My understanding is (and I would happily have my understanding
corrected) that there should *never* be a prefix length associated
with address assignment, whether that address comes from DHCPv6,
manual address assignment, etc. Prefix length is n
On Thu, 16 Oct 2008, Iljitsch van Beijnum wrote:
On 14 okt 2008, at 18:45, Pekka Savola wrote:
The reality is that most implementors will just ignore anything the spec
says they don't like or consider unnecessary in the scenarios they have in
mind. As long as their code interoperates (in those
On Oct 16, 2008, at Oct 16, 2008,10:18 AM, Iljitsch van Beijnum wrote:
The error in your reasoning is in thinking that "forked paths will
simplify the network." It complicates it. We need a single place to
look for host configuration, not two and certainly not three.
So why isn't there a sub
On 14 okt 2008, at 18:32, David W. Hankins wrote:
See my earlier emails.
Why? They don't answer the question. If we apply the thinking that
all multicasts must be avoided, then there are a great many protocols
outside of DHCPv6 to which we must also direct our attention.
Generally people
On Wed, Oct 15, 2008 at 07:44:33PM +0300, Pekka Savola wrote:
> For example, we don't use any DHCP in server-only LANs. (In 'office' LANs
> where laptops, desktops, etc. connect it is used however.) I'm pretty sure
> this is a very common way to manage servers, though I admit that usign DHCP
>
On Thu, Oct 16, 2008 at 11:09:42AM +1300, Brian E Carpenter wrote:
> Two goals, two solutions: that is OK systems engineering IMHO.
Unfortunately (?), the IETF is engaged in protocol engineering, not
systems engineering. Throwing spaghetti at the wall just to see what
sticks is not adequate proto
On Wed, Oct 15, 2008 at 07:44:33PM +0300, Pekka Savola wrote:
> On Tue, 14 Oct 2008, David W. Hankins wrote:
>> [RA] fails to suck less than DHCPv4; consequently, anyone who runs
missing word: dual
>> stack today uses DHCPv4 to configure IPv6 (using IPv4 nameservers)!
>
> I wonder where you have go
On 14 okt 2008, at 18:45, Pekka Savola wrote:
The reality is that most implementors will just ignore anything the
spec says they don't like or consider unnecessary in the scenarios
they have in mind. As long as their code interoperates (in those
specific scenarios) with other major impleme
On Wed, Oct 15, 2008 at 08:45:12AM -0400, Thomas Narten wrote:
> Correct, and that is the motivation for
> draft-ietf-6man-ipv6-subnet-model-02.txt. See Section 3, for example.
That draft completely misses the original point. This isn't a
question of whether "ifconfig inet6 2001:db8::1/64" 'shoul
On 2008-10-16 14:15, David Conrad wrote:
> Hi,
>
> On Oct 15, 2008, at 4:30 PM, Bob Hinden wrote:
>> The IPv6 auto-configuration was modeled after IPX (based on XNS)
>> auto-configuration. IPX was very successful at the time and it's
>> auto-configuration mechanisms were considered an improvement
Hello, Thomas.
Inline comments are continued below.
2008/10/15 Thomas Narten <[EMAIL PROTECTED]>:
> Joseph Hyunwook Cha <[EMAIL PROTECTED]> writes:
>
>> Hello, Thomas.
>
>> Thank you for your analysis and suggestions.
>
>> IMO, as long as M&O flags are configured correctly, there is no
>> reason
Hi,
On Oct 15, 2008, at 4:30 PM, Bob Hinden wrote:
The IPv6 auto-configuration was modeled after IPX (based on XNS)
auto-configuration. IPX was very successful at the time and it's
auto-configuration mechanisms were considered an improvement over
IPv4. At the time considered better for en
seph
--- Original Message ---
Sender : Ted Lemon<[EMAIL PROTECTED]>
Date : 2008-10-16 04:34 (GMT+09:00)
Title : Re: [dhcwg] Brokenness of specs w.r.t. client behavior with M&O bits
On Oct 13, 2008, at 9:48 PM, Pekka Savola wrote:
> I don't see why M/O bits would
and in starting from scratch with
IPv6, the IETF has made the mistake of throwing out the meaningful
results of this dialogue.
As a matter of historical accuracy, the IPv6 auto-config design was
done at a time when DHCP was so new that reliable implementations
were not available. The best
> > and in starting from scratch with
> > IPv6, the IETF has made the mistake of throwing out the meaningful
> > results of this dialogue.
>
> As a matter of historical accuracy, the IPv6 auto-config design was
> done at a time when DHCP was so new that reliable implementations
> were not ava
David,
On 2008-10-15 05:32, David W. Hankins wrote:
...
> and in starting from scratch with
> IPv6, the IETF has made the mistake of throwing out the meaningful
> results of this dialogue.
As a matter of historical accuracy, the IPv6 auto-config design was
done at a time when DHCP was so ne
On Tue, 14 Oct 2008 09:48:42 +0200
Iljitsch van Beijnum <[EMAIL PROTECTED]> wrote:
> On 13 okt 2008, at 22:59, Thomas Narten wrote:
>
> > So, clients will retransmit about once every 2 minutes.
>
> But they'll transmit packets more frequently initially.
>
> >> This is unnecessary multicast traf
On Oct 13, 2008, at 9:48 PM, Pekka Savola wrote:
I don't see why M/O bits would need to be completely deprecated (they
could still be hints about what should be available in the network).
I don't see what good a hint is. We'd need to understand what advice
the hint was intending to give.
On Tue, 14 Oct 2008, David W. Hankins wrote:
[RA] fails to suck less than DHCPv4; consequently, anyone who runs
stack today uses DHCPv4 to configure IPv6 (using IPv4 nameservers)!
I wonder where you have gotten the latter misconception. There are
LOTS of networks which *at least in significan
Joseph Hyunwook Cha <[EMAIL PROTECTED]> writes:
> Hello, Thomas.
> Thank you for your analysis and suggestions.
> IMO, as long as M&O flags are configured correctly, there is no
> reason to ignore the bits. So, I do not think that one of two
> options should be selected and specified exclusive
"Bernie Volz (volz)" <[EMAIL PROTECTED]> writes:
> >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
> as
On Tue, Oct 14, 2008 at 11:55:06AM +0200, Iljitsch van Beijnum wrote:
>> Why? It seems perfectly fine to me, since the Solicits follow an
>> exponential backoff.
>
> See my earlier emails.
Why? They don't answer the question. If we apply the thinking that
all multicasts must be avoided, then th
On 14 okt 2008, at 22:35, Brian E Carpenter wrote:
I would rather move in the direction where we all implement RFC
5006 and
DHCPv6 is only used to _register_ addresses that hosts select for
themselves if central knowledge of which host has which address is
desired.
How would that work on
On 2008-10-14 20:54, Iljitsch van Beijnum wrote:
...
> I would rather move in the direction where we all implement RFC 5006 and
> DHCPv6 is only used to _register_ addresses that hosts select for
> themselves if central knowledge of which host has which address is desired.
How would that work on s
On Tue, 14 Oct 2008, Iljitsch van Beijnum wrote:
I've yet to see a DHCPv6 client implementation that would listen to
the flags in RA and conditionally start or stop the service depending
of the presence of flags there.
Apart from Vista and special cases such as Cisco routers I'm not aware of an
Iljitsch van Beijnum <[EMAIL PROTECTED]> writes:
> On 13 okt 2008, at 22:59, Thomas Narten wrote:
> > So, clients will retransmit about once every 2 minutes.
> But they'll transmit packets more frequently initially.
Sure.
> It's not a question of "problematic yes/no". More multicasts means
>
ssage-
From: "David W. Hankins" <[EMAIL PROTECTED]>
Date: Mon, 13 Oct 2008 09:49:40
To: DHC WG<[EMAIL PROTECTED]>
Cc: IPV6 List Mailing
Subject: Re: [dhcwg] Brokenness of specs w.r.t. client behavior with M&O bits
--
On 13 okt 2008, at 18:38, David W. Hankins wrote:
Seems to me that this is simple enough: no bits, no DHCP. "Always"
is not
an acceptable out of the box behavior. (!!!)
Why? It seems perfectly fine to me, since the Solicits follow an
exponential backoff.
See my earlier emails.
Further
On Mon, Oct 13, 2008 at 01:17:38PM -0500, [EMAIL PROTECTED] wrote:
> Just so I'm clear... when you say "ignore M/O and always run DHCPv6", does
> that mean stateful or stateless DHCPv6? And of course, if it is "or", then
> how is that determined without the M/O bits in the RA?
The general purpo
On Mon, Oct 13, 2008 at 01:24:41PM -0400, Bernie Volz (volz) wrote:
> 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
> advertisement, the client should only assume a /128.
Being "wrong" or "working but brok
On Mon, Oct 13, 2008 at 06:30:53PM +0200, Iljitsch van Beijnum wrote:
> A corner case is the situation where there are no routers, but I don't see
> how having a DHCPv6 server in that case still makes sense (would it even
> work?), communication can and probably should happen over link locals in
On Mon, Oct 13, 2008 at 06:03:14PM +0200, Iljitsch van Beijnum wrote:
> On 13 okt 2008, at 17:40, Thomas Narten wrote:
>> Question: just when are they supposed to invoke DHCPv6?
This is essentially Joseph's question (one of them). He is stating,
"I am an implementer, someone tell me what to do."
On 14 okt 2008, at 9:10, Kadirvel Chockalingam Vanniarajan wrote:
1) Is there a way for a IPv6 client to distinguish between a
authoritative RA vs non-authoritative RA?
What are those?
2) In an enterprise-level deployments, IPv6 deployments will
typically happen on top of existing subnet s
Some DHCPv6 clients default to a /64
prefix so that this scenario works, and systems with those clients can
and do interoperate. The obvious complete solution to this problem is
to deliver the prefix length via DHCPv6
Right. Not doing that is a flaw in the DHCPv6 design, IMO.
at which point y
On 13 okt 2008, at 22:59, Thomas Narten wrote:
So, clients will retransmit about once every 2 minutes.
But they'll transmit packets more frequently initially.
This is unnecessary multicast traffic that could easily affect wifi
performance because on 802.11 multicasts are generally sent at th
ubject: Re: [dhcwg] Brokenness of specs w.r.t. client behavior with M&O bits
On Mon, 13 Oct 2008, Thomas Narten wrote:
> 1) We could ignore/deprecate the M&O bits and simply have any
> client that implements DHCP invoke DHCP without even bothering to
> see what the M&O flags
Hello, Thomas.
Thank you for your analysis and suggestions.
IMO, as long as M&O flags are configured correctly, there is no reason to
ignore the bits. So, I do not think that one of two options should be selected
and specified exclusively. What I am saying is that it will be ok if there is
an
On Mon, 13 Oct 2008, Thomas Narten wrote:
1) We could ignore/deprecate the M&O bits and simply have any
client that implements DHCP invoke DHCP without even bothering to
see what the M&O flags say. I.e, the way DHCPv4 works today.
IMO, this approach would work fine. Indeed, it has the adva
1 - 100 of 112 matches
Mail list logo
