> -Original Message-
> From: Sheng Jiang
> Sent: Wednesday, February 27, 2013 2:45 PM
> To: Liubing (Leo); ipv6@ietf.org
> Cc: re...@ietf.org
> Subject: RE: SLAAC/DHCPv6 addr-conf operational gaps
>
> Hi, Bing,
>
> It is better to at least mention the direction of next step - clearly
> r
Hi, Bing,
It is better to at least mention the direction of next step - clearly redefine
the flag correspondent host behavior in standards.
A couple of more detailed comments: you have used word "gap" several times,
while you did not clear describe what gap it is. You have only described
issue
Hi, Sheng
Thanks for your comments.
This is the first step, to see if there is consensus of agreeing the problems
should be fixed in current standard. If so, we'll submit a draft to fix the
ambiguous issue.
B.R.
Bing
> -Original Message-
> From: Sheng Jiang
> Sent: Wednesday, February
On Wed, 2013-02-27 at 05:56 +, Liubing (Leo) wrote:
> I like the concept of separating "_address configuration_ methods" and
> "address aging methods", if we could initiate the subsequence work, it
> should be considered.
Hear, hear!
Regards, K.
--
~~
Hi, Mark
Thanks for your comment.
I like the concept of separating "_address configuration_ methods" and "address
aging methods", if we could initiate the subsequence work, it should be
considered.
All the best
Bing
> -Original Message-
> From: Mark Smith [mailto:markzzzsm...@yahoo.co
Hi, Barbara
Thanks for your comments. Please see replies inline.
> -Original Message-
> From: STARK, BARBARA H [mailto:bs7...@att.com]
> Sent: Wednesday, February 27, 2013 2:02 AM
> To: Liubing (Leo); ipv6@ietf.org; v6...@ietf.org
> Cc: re...@ietf.org
> Subject: RE: SLAAC/DHCPv6 addr-conf
This has been a historic issue. Although there was discussions several times,
the specification still remain ambiguous. The differences in OS implementations
are good proof that we need to do something in IETF.
This document has well described the current standard status and reality
operational
Hi, Victor & Arturo
Thanks for the comments.
We do plan to write a draft of subsequence solution. But as Victor said, step 1
is to see if the groups agree there are problems. So hope more people could
feed back on this.
Many thanks.
B.R.
Bing
> -Original Message-
> From: Victor Kuarsi
On Tue, 2013-02-26 at 07:14 +, Liubing (Leo) wrote:
> We submitted a new draft to discuss the SLAAC/DHCPv6 interaction gaps.
Some time ago I wrote quite a long reply on this list about it. I've
changed my mind on a few points, and here's my current thinking, for
what it's worth. I think an upd
Hi,
I've had a quick read though, I'll try to do a thorough one in the next week or
so.
Thanks for writing this, I've been thinking about doing something similar over
the last few months since, IIRC, I heard about Windows 7 invalidating IPv6
addresses learned via DHCPv6 when SLAAC was enabled
This is interesting. Thanks for doing these tests and submitting the results.
When testing the switching behavior, I'm curious for the " SLAAC-only host
receiving A=0&M=1 " case as to what you set the Preferred Lifetime to, when you
set A=0. I'm guessing Preferred Lifetime > 0?
Since RFC 4862 st
Hi:
This is work that started at 6LoWPAN and was part of the early 6LoWPAN ND WG
doc. It is now contiguous to 6MAN work with the Efficiency aware IPv6 Neighbor
Discovery.
The context is a backbone link, in a situation where the 6LoWPAN ND or the
Efficiency aware IPv6 Neighbor Discovery reserva
Bing,
I as able to review the draft and agree this needs to be documented and
discussed. I have had many frustrating nights dealing with my multiple
OSs at home and figuring out what behaviour I was trying to expect when
changing the upstream router's settings (M/O/A).
I think the problem space
A new version of I-D, draft-sarikaya-mif-6man-ra-route-02.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.
Filename:draft-sarikaya-mif-6man-ra-route
Revision:02
Title: IPv6 RA Options for Multiple Interface Next Hop Routes
Creation
Good.
Regarding a possible next step. Are you guys planning to propose a
"correct" behavior of the flags? It may be worth to try.
Regards,
as
On 26/02/2013 17:53, Liubing (Leo) wrote:
> Hi, Arturo and all
>
> That was my mistake. I derived this draft from a template and forgot
Hi, Arturo and all
That was my mistake. I derived this draft from a template and forgot to change
it.
It should be "Informational", thanks for finding this bug.
B.R.
Bing
> -Original Message-
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
> Arturo Servin
> Se
Dear authors,
Very interesting document and very valuable to document the current
behavior of the A, M and O flags (that have caused some headaches to
some including myself when troubleshooting IPv6).
I see that has been submitted as "Proposed Standard" but I failed to
find what y
17 matches
Mail list logo
