I really like this idea.
What worries me is the different cases to be examined/solved depending on the
source device: host (applications) or router (protocols).
And this draft takes into account mostly the first.
--
Tassos
Ronald Bonica wrote on 20/06/2013 18:55:
Folks,
Please review this
I believe the doc describes nicely the possible security issues of predictable
fragment ids in IPv6.
Although the attack scenarios aren't so common/easy as in IPv4 and various
operating systems have fixed most of them, i still find urgent to need to
standardize this behavior, now that IPv6 is
Fernando Gont wrote on 20/1/2013 03:00:
Hi, Tassos,
On 01/19/2013 07:49 PM, Tassos Chatzithomaoglou wrote:
First of all, i would like to see a reference to cases where the prefix
doesn't change too often (since this is recommended by many people for
various deployments, i.e. residential dsl
Hi Fernando,
I would like to make some last comments about your draft, which i
fully support.
First of all, i would like to see a reference to cases where the
prefix doesn't change too often (since this is recommended by many
people for
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 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
I like support the idea, but it's not clear to me the
randomness/stableness of the created identifiers.
Is there a guarantee, that after rebooting or powering-off/on the host,
the produced RID will remain the same if Prefix remains the same?
Is there a way to change the secret key in case
Maybe i have misunderstood something, but how does DNS interfere with
source address selection?
I would go with option A.
I would even prefer to limit even more the usage of temporary addresses,
but that's another talk.
--
Tassos
On 27/3/2012 9:41 πμ, JORDI PALET MARTINEZ wrote:
Hi Brian,
colleague said about overloading the Flow Label.
Regards,
Hemant
-Original Message-
From: Tassos Chatzithomaoglou [mailto:ach...@forthnetgroup.gr]
Sent: Friday, October 14, 2011 8:17 PM
To: Brian E Carpenter
Cc: Hemant Singh (shemant); IPv6 WG Mailing List
Subject: Re: FW: New Version
Hi,
I was wondering...wouldn't the flow label be a "better" field for
storing this random number?
If i remember correctly, early drafts of RPL were using it for loop
detection (ok, in a very different way), although in the later ones
a new option was chosen.
Hemant Singh (shemant) wrote on 15/10/2011 01:41:
Tassos,
From: Tassos Chatzithomaoglou [mailto:ach...@forthnet.gr]
Sent: Friday, October 14, 2011 6:29 PM
To: Hemant Singh (shemant)
Cc: IPv6 WG Mailing List
Subject: Re: FW: New Version Notification for
draft-hsingh-6man-enhanced-dad-01.txt
:43:
Also remember that 3697 is obsoleted by draft-ietf-6man-flow-3697bis,
which is fully approved and very close to becoming an RFC.
Regards
Brian
On 2011-10-15 12:30, Tassos Chatzithomaoglou wrote:
Hemant Singh (shemant) wrote on 15/10/2011 01:41:
Tassos,
From: Tassos Chatzithomaoglou
Hemant Singh (shemant) wrote on 15/10/2011 02:57:
Tassos,
-Original Message-
From: Tassos Chatzithomaoglou [mailto:ach...@forthnetgroup.gr]
Sent: Friday, October 14, 2011 7:31 PM
To: Hemant Singh (shemant)
Cc: IPv6 WG Mailing List
Subject: Re: FW: New Version Notification for
draft
13 matches
Mail list logo
