Original Message
Subject: New Version Notification for draft-ietf-6man-impatient-nud-02.txt
Date: Tue, 31 Jul 2012 16:48:19 -0700
From: internet-dra...@ietf.org
To: nordm...@cisco.com
CC: i...@yahoo-inc.com
A new version of I-D, draft-ietf-6man-impatient-nud-02.txt
has been
On Wed, 2012-08-01 at 01:06 +, Liubing (Leo) wrote:
You mentioned the ambiguous M flag in RA, indeed this is a problem,
and it has been disscussed in 6renum WG.
So if you're still consern about the issue, looking forward to hear
some comments from you, either on the mics or in the mail.
On Wed, 1 Aug 2012, Karl Auer wrote:
I'll preface all this my saying that I think the M and O flags as
generally implemented and used are pretty much useless. The best thing
to do with them would be to deprecate them altogether.
I know of one vendor device (I'm trying to get them to change)
In the past the frequency of sending RAs has been improved reducing
interval down to milliseconds, with the goal of getting connectivity
faster, in mobility scenarios.
Would this be enough for these cases?
Alex
IETF IPv6
In your previous mail you wrote:
In the past the frequency of sending RAs has been improved reducing
interval down to milliseconds, with the goal of getting connectivity
faster, in mobility scenarios.
= do you mean to misuse RAs as a beacon (:-)? Seriously the issue is
pretty similar to
Wouldn't it be an option to have all applications systems accept as
input both formats, but only give as output the new one?
i.e. browsers already rewrite URIs.
--
Tassos
IETF IPv6 working group mailing list
ipv6@ietf.org
I mentioned this at the mic during the meeting and now posting the
same to the list...
Luis Santos asked a question to the authors which I'll explain to the list
as follows. RFC 3484, and RFC 3484 bis, specify an algorithm whereby
a set of destination addresses are sorted, and a source address
On Wed, Aug 01, 2012 at 09:42:44AM -0700, Tassos Chatzithomaoglou wrote:
Wouldn't it be an option to have all applications systems accept
as input both formats, but only give as output the new one?
i.e. browsers already rewrite URIs.
There are other standards that currently state that % is
Hi,
I just promised to send some additional information about the power
consumption graphs I was just showing.
The idle current draw (WiFi tethering on, phone on, cellular idle) in one
of the measurement was about 138mA (in the figures I had this was the
zero-line).
When the cellular interface
I personally like the idea of making it a standard, just to have it as a
reference for future IPv6 implementations.
imho, security related issues should preferably be solved by changing
the protocol, unless it's too much work; strict recommendations should
then be given.
We had a hard time in
Hi, all
Firstly, thanks for Karl's elaborate analysis and solution proposal for the M/O
issue. I think that's definitely reasonable reference if we want to fix the
issue.
But as some comments showed in this morning's 6man meeting, some people thought
it is not necessary to fix the M/O issue
Le 01/08/2012 13:35, Liubing (Leo) a écrit :
Hi, all
Firstly, thanks for Karl's elaborate analysis and solution proposal
for the M/O issue. I think that's definitely reasonable reference if
we want to fix the issue.
But as some comments showed in this morning's 6man meeting, some
people
On Wed, 2012-08-01 at 17:58 -0700, Alexandru Petrescu wrote:
The choice today is more than b/w 'if M then DHCP is available
otherwise SLAAC'.
That has never been the choice. It's never been either/or, one excluding
the other. Rock solid mechanisms exist to stop hosts doing SLAAC - the
autoconf
Le 01/08/2012 18:48, Karl Auer a écrit :
On Wed, 2012-08-01 at 17:58 -0700, Alexandru Petrescu wrote:
The choice today is more than b/w 'if M then DHCP is available
otherwise SLAAC'.
That has never been the choice. It's never been either/or, one
excluding the other.
Ok fair enough. The
Hi, Karl
Thanks for your reply, now I understand your arguments clearly.
I think our common view is ambiguity in not good. Then your way is just
deprecating them; if don't deprecate, then make it clear. But I just have the
opposite approach: since it's ambiguous, we need at least make them
On 8/1/2012 5:58 PM, Alexandru Petrescu wrote:
Le 01/08/2012 13:35, Liubing (Leo) a écrit :
Hi, all
Firstly, thanks for Karl's elaborate analysis and solution proposal
for the M/O issue. I think that's definitely reasonable reference if
we want to fix the issue.
But as some comments showed
16 matches
Mail list logo
