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
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
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
>>
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, 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 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
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, 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
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
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]
-
Thoughts?
Best Regards,
Jeffrey 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'
Su
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 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
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
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
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 s
>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 sta
-Original 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 M&O
bits
On Mon, Oct 13, 2008 at 06:30:53PM +0200,
84 matches
Mail list logo