On Wed, 21 Aug 2013, Brian E Carpenter wrote:
> Hi Ron,
>
> On 21/08/2013 01:33, Ronald Bonica wrote:
> > Hi Mike,
> >
> > Thanks for your review of all three documents. The following is some gentle
> > pushback.
>
> ...
>
> > There is no real solution to the long header problem. The best
>
On Tue, 20 Aug 2013, Erik Kline wrote:
To support this scheme as I understand it, the Linux kernel ipv6 code
would need to take some module parameters at boot or load time, so as to
force it to not do link-layer-derived link-local autoconfig but instead
load up the required parameters from non
Hi Andrew,
On 08/05/2013 06:51 AM, ayourtch wrote:
> The RS sending mechanism will be resilient, I assume, such that the node
> does get RA even in a high-loss environments, right ? Maybe useful to
> include a paragraph or two on the unreliability of this mechanism. I
> think Suresh said he had s
Hi Fernando/Mike,
On 08/20/2013 04:32 AM, Mikael Abrahamsson wrote:
>
> Network_ID mentions SSID. What if I have an ethernet Interface and I
> move my computer around, should it identify a new set of /64 network
> address and/or gateway MAC address as a new network as well? I think
> some text on
On Wed, 21 Aug 2013, Fernando Gont wrote:
Does SAVI prevnt forged RAs? -- Because that's why RA-Guard is being
referenced.
Well, yes, it's within the charter anyway.
http://datatracker.ietf.org/wg/savi/charter/
SAVI-WG aims to solve all kinds of first hop security problems.
Unfortunately th
Hi, Erik,
On 08/20/2013 05:55 AM, Erik Kline wrote:
>>> I agree that this all seems fine in theory. Are we collectively
>>> convinced this will not lead to tragically (IPv6-)orphaned machines in
>>> certain scenarios?
>>
>> Sorry, what are the scenarios you have in mind?
>
> Well, I guess first
On 08/21/2013 12:16 AM, Mikael Abrahamsson wrote:
>
>>> I think it would be good to reference SAVI-WG documents on first-hop
>>> security instead of writing new text on the subject.
>>
>> Where, specifically?
>
> Under 7 where ra-guard is mentioned. Oh, btw, the paragraph on RA-guard
> is missing
On Tue, 20 Aug 2013, Fernando Gont wrote:
---
There are numerous references to DAD. Isn't DAD attacks handled in other
documents that can be referenced, does this document really need to
outline this behaviour, perhaps even in conf
Hi, Mikael,
Thanks so much for your feedback! -- Please find my comments in-line...
On 08/20/2013 05:32 AM, Mikael Abrahamsson wrote:
>> draft-ietf-6man-stable-privacy-addresses-12 (ending September 2nd)
>
>
> NIT:
>
> F():
>
Hi Ron,
On 21/08/2013 01:33, Ronald Bonica wrote:
> Hi Mike,
>
> Thanks for your review of all three documents. The following is some gentle
> pushback.
...
> There is no real solution to the long header problem. The best that we can do
> is to put a stake in the ground, saying that implemen
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance Working Group of the IETF.
Title : IPv6 Multicast Address Scopes
Author(s) : Ralph Droms
Filename: draft-ietf-6man-mul
Hi Mike,
Thanks for your review of all three documents. The following is some gentle
pushback.
At IETF 87, the 6man WG was pretty clear that they are not ready to deprecate
IPv6 fragmentation. So, within the next few weeks, I will update that document
so that it makes only the following point
On 19 August 2013 18:57, Fernando Gont wrote:
> Erik,
>
> On 08/19/2013 06:40 AM, Erik Kline wrote:
>> I pre-apologize, as always, for my ignorance, but...is there an
>> implementation of this? Specifically, I'm mildly concerned about this
>> for link-local addresses.
>>
>> Compliant implementati
On Mon, 19 Aug 2013, Ole Troan wrote:
In working group last call:
draft-ietf-6man-oversized-header-chain-04(ending August 27th)
I have read this document and found no problem with it, and I support its
progression.
draft-ietf-6man-stable-privacy-addresses-12 (ending September 2nd)
14 matches
Mail list logo
