Re: 6MAN Agenda for IETF86

Karl Auer <kauer@biplane.com.au> Tue, 05 March 2013 09:37 UTC

Return-Path: <kauer@biplane.com.au>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44BBC21F8742 for <ipv6@ietfa.amsl.com>; Tue, 5 Mar 2013 01:37:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpLHlz1jXWOB for <ipv6@ietfa.amsl.com>; Tue, 5 Mar 2013 01:37:15 -0800 (PST)
Received: from ipmail05.adl6.internode.on.net (unknown [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 220E221F86C3 for <ipv6@ietf.org>; Tue, 5 Mar 2013 01:37:13 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApMBALy7NVGWZX+7/2dsb2JhbAANN8JUgReDEgEBAQSBCQsYLkkBDRmzGoMxkDqPExaDKgOINpltiDE
Received: from eth4284.nsw.adsl.internode.on.net (HELO [192.168.1.202]) ([150.101.127.187]) by ipmail05.adl6.internode.on.net with ESMTP; 05 Mar 2013 20:07:12 +1030
Message-ID: <1362476231.3387.278.camel@karl>
Subject: Re: 6MAN Agenda for IETF86
From: Karl Auer <kauer@biplane.com.au>
To: ipv6@ietf.org
Date: Tue, 05 Mar 2013 20:37:11 +1100
In-Reply-To: <7EE61AD6-2E54-4F17-BBFD-30BE77F7E782@gmail.com>
References: <7EE61AD6-2E54-4F17-BBFD-30BE77F7E782@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
X-Mailer: Evolution 3.2.3-0ubuntu6
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Mar 2013 09:37:20 -0000

On Mon, 2013-03-04 at 16:02 -0800, Bob Hinden wrote:
>    A Simple Secure Addressing Generation Scheme for IPv6
> AutoConfiguration
> 	draft-rafiee-6man-ssas-01.txt
> [...]
>    DHCPv6/SLAAC Address Configuration Interaction Problem Statement
> 	draft-liu-bonica-dhcpv6-slaac-problem-01.txt
> 
> We did not think there had been enough discussion or interest on the
> w.g. list to guarantee a speaking slot.  We allocated short slots at
> the end of the session if there is time before the meeting ends.  If
> anyone (other than the authors) think one of these should be given
> more time, please speak up.

For what it's worth it seems to me that there is a gaping hole around
securing ND. IPSec is obviously ridiculous, SEND is only marginally less
ridiculous. Maybe SSAS is a way forward? Or maybe noone else thinks ND
needs to be secured? Maybe the meeting could attempt to gauge whether
this is actually a real problem. I think it is, and I urge others to
speak up if they too think this should be pursued.

If there is a priority to these things, then sorting out the perceived
and actual discrepancies\ and ambiguities in the meaning of the RA M and
O flags would seem pretty important. Otherwise they will end up cemented
into even more implementations than they are now. The way Windows
handles them is just plain broken, and if the RFCs support that way of
handling them, then the RFCs are broken. At very least this topic needs
some impetus.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer@biplane.com.au)
http://www.biplane.com.au/kauer
http://www.biplane.com.au/blog

GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A
Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017