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
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
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 hosts in
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 like a
good
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 can warn
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
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 actually
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
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
- host gets
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 some
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 to get some
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 so
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
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 well as
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 more
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 details
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 server
retrieval of RA.
Best regards,
Teemu
-Original Message-
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
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 of specs w.r.t. client
behavior
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
I agree with Joseph that these should be combined and published.
As for dealing with conflicting MO, 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
As for dealing with conflicting MO, 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
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 with
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 MO bits
I have been lurking on this discussion for a while and have
one observation. Regardless of the values of the MO bits or
the prefixes (and their lengths
Subject: Re: [dhcwg] Brokenness of specs w.r.t. client
behavior with MO bits
In order for this to be a valid rejoinder, it would have to be
the case that the cellular industry was planning to use IPv6 autoconf
combined with RAs to get IPv6 addresses. It's not my understanding
that this is the case
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
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
unauthorized
-
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 MO
bits
On Fri, Oct 17, 2008 at 07:21:34AM -0400, Ralph Droms wrote:
1
.
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 MO bits
I've been tracking this discussion
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 RA.
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
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
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
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,
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
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.
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
Dunn
Info Systems Eng., Lead
MITRE Corporation.
(301) 448-6965 (mobile)
-Original Message-
From: [EMAIL 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
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]
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
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
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,
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 MO
bits
On Wed, Oct 15, 2008
PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
Ralph Droms (rdroms)
Sent: Friday, October 17, 2008 7:22 AM
To: IPV6 List Mailing; DHC WG
Subject: Re: [dhcwg] Brokenness of specs w.r.t. client behavior with MO
bits
I've been tracking this discussion about the M/O flags, which seems to
be going
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 ifconfig inet6
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 to
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 'should
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
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 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
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
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
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
Joseph Hyunwook Cha [EMAIL PROTECTED] writes:
Hello, Thomas.
Thank you for your analysis and suggestions.
IMO, as long as MO 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.
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
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 there
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.
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 new
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.
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
--- 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 MO bits
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
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
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 MO flags are configured correctly, there is no
reason to ignore the
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 over
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
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
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 broken in
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 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
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
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 purpose
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
. Hankins [EMAIL PROTECTED]
Date: Mon, 13 Oct 2008 09:49:40
To: DHC WG[EMAIL PROTECTED]
Cc: IPV6 List Mailingipv6@ietf.org
Subject: Re: [dhcwg] Brokenness of specs w.r.t. client behavior with MO bits
IETF IPv6 working group mailing
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 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
Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of David W. Hankins
Sent: Monday, October 13, 2008 12:50 PM
To: DHC WG
Cc: IPV6 List Mailing
Subject: Re: [dhcwg] Brokenness of specs w.r.t. client behavior with MO
bits
On Mon, Oct 13, 2008 at 06:30:53PM +0200, Iljitsch van
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
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
78 matches
Mail list logo
