RE: question regarding draft-ietf-6man-rfc3484-revise-02 section 2.3

Mikael Abrahamsson <swmike@swm.pp.se> Mon, 28 March 2011 13:02 UTC

Return-Path: <swmike@swm.pp.se>
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 194EA3A6978 for <ipv6@core3.amsl.com>; Mon, 28 Mar 2011 06:02:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.258
X-Spam-Level:
X-Spam-Status: No, score=-2.258 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, J_CHICKENPOX_13=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRvyjfCA3YIq for <ipv6@core3.amsl.com>; Mon, 28 Mar 2011 06:02:25 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 3185C3A67DA for <ipv6@ietf.org>; Mon, 28 Mar 2011 06:02:25 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 155BF9E; Mon, 28 Mar 2011 15:04:02 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 0FF489C; Mon, 28 Mar 2011 15:04:02 +0200 (CEST)
Date: Mon, 28 Mar 2011 15:04:02 +0200 (CEST)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: "Hemant Singh (shemant)" <shemant@cisco.com>
Subject: RE: question regarding draft-ietf-6man-rfc3484-revise-02 section 2.3
In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30121E5C1@XMB-RCD-109.cisco.com>
Message-ID: <alpine.DEB.2.00.1103281501150.4842@uplift.swm.pp.se>
References: <alpine.DEB.2.00.1103281015240.4842@uplift.swm.pp.se> <5B6B2B64C9FE2A489045EEEADDAFF2C30121E5C1@XMB-RCD-109.cisco.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: ipv6@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Mon, 28 Mar 2011 13:02:26 -0000

On Mon, 28 Mar 2011, Hemant Singh (shemant) wrote:

> It's the IPv6 default router for the DHCPv6 client that sends a RA with 
> the M-bit set and seeing such an RA the client initiates DHCPv6.  Or the 
> client could initiate DHCPv6 even on receiving an RA with the M-bit 
> cleared.  But the fact still remains that the DHCPv6 client did receive 
> an RA from the IPv6 first-hop router to the client.  The client is 
> supposed to perform router discovery and send RS.  The RA lets the 
> client know what the default router is.  If I missed anything, perhaps 
> if you could please draw a diagram and let us know what specific use 
> case I missed.

I'm thinking in the terms of multiple routers on the same LAN but with 
multiple subnets, the multihoming scenario we're discussing in v6ops.

Your above description makes perfect sense for single homing, and if text 
like this (how to tie them together) was present in the draft (or a 
referral to other text describing it), I'd be fine.

Right now I couldn't help reading the text in section 2.3 and wondering 
how it was supposed to achieve what was described.

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