Re: [v6ops] new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem

Mikael Abrahamsson <swmike@swm.pp.se> Tue, 05 November 2013 03:30 UTC

Return-Path: <swmike@swm.pp.se>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C7711E8232 for <v6ops@ietfa.amsl.com>; Mon, 4 Nov 2013 19:30:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.866
X-Spam-Level:
X-Spam-Status: No, score=-5.866 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
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 q+n00A5OJqrr for <v6ops@ietfa.amsl.com>; Mon, 4 Nov 2013 19:30:39 -0800 (PST)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5A25D21E811A for <v6ops@ietf.org>; Mon, 4 Nov 2013 19:30:33 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 93E27A1; Tue, 5 Nov 2013 04:30:12 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8DA039A; Tue, 5 Nov 2013 04:30:12 +0100 (CET)
Date: Tue, 05 Nov 2013 04:30:12 +0100
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: fred@cisco.com
In-Reply-To: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com>
Message-ID: <alpine.DEB.2.02.1311050427070.26054@uplift.swm.pp.se>
References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Cc: v6ops@ietf.org, draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org
Subject: Re: [v6ops] new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Nov 2013 03:30:44 -0000

On Mon, 21 Oct 2013, fred@cisco.com wrote:

>
> A new draft has been posted, at http://tools.ietf.org/html/draft-liu-bonica-v6ops-dhcpv6-slaac-problem. Please take a look at it and comment.

My comment just now at the mic:

I would like to see if any implementation actually deprecates the /64 
onlink prefix when A goes from 1 to 0, or ignores the on-link prefix when 
A=0.

Ie the on-link prefix should be used by installing a /64 route towards the 
interface, then the A-flag determines if the host is allowed to create 
addresses within this /64 itself, or not.

But when one reads RFC4862 and (from my interpration) is just in the 
context of creating addresses, not what to do with the on-link prefix.

5.5.3.  Router Advertisement Processing

    For each Prefix-Information option in the Router Advertisement:

     a)  If the Autonomous flag is not set, silently ignore the Prefix
       Information option.

This doesn't say anything regarding the /64 route towards the interface, 
it only talks about creating addresses within this /64. I can imagine 
implementators getting this wrong?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se