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

Mikael Abrahamsson <swmike@swm.pp.se> Mon, 28 March 2011 15:59 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 6DDF428C0DC for <ipv6@core3.amsl.com>; Mon, 28 Mar 2011 08:59:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.552
X-Spam-Level:
X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599]
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 xTTj5SsWCKWZ for <ipv6@core3.amsl.com>; Mon, 28 Mar 2011 08:59:52 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 6452E28C0D9 for <ipv6@ietf.org>; Mon, 28 Mar 2011 08:59:52 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 9814E9C; Mon, 28 Mar 2011 18:01:28 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 95CA19A; Mon, 28 Mar 2011 18:01:28 +0200 (CEST)
Date: Mon, 28 Mar 2011 18:01:28 +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: <5B6B2B64C9FE2A489045EEEADDAFF2C30121E663@XMB-RCD-109.cisco.com>
Message-ID: <alpine.DEB.2.00.1103281755550.4842@uplift.swm.pp.se>
References: <alpine.DEB.2.00.1103281015240.4842@uplift.swm.pp.se> <5B6B2B64C9FE2A489045EEEADDAFF2C30121E5C1@XMB-RCD-109.cisco.com> <alpine.DEB.2.00.1103281501150.4842@uplift.swm.pp.se> <5B6B2B64C9FE2A489045EEEADDAFF2C30121E663@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 15:59:53 -0000

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

> Here is an attempt to explain the text above from section 2.3 of the 
> document that I have included between squared brackets above.  SA was 
> acquired using DHCPv6 where the DHCPv6 response did arrive to the client 
> on the IPv6 link-local address of the first-hop.  The client already 
> knows this link-local address matches a mac-address of, say, 
> mac-address1 obtained from the RA from the same first-hop router.  Thus 
> SA is associated with Router 1 (from Figure 1 of section 2.1.1 of RFC 
> 5220).  Likewise SB is associated with Router 2 with mac-addr of say, 
> mac-address2.  Thus far we established that SA is used when sending to 
> the default router of Router 1 and likewise for SB with Router 2.  An 
> orthogonal question is how does the host know for a destination D which 
> default router to go to - should such a question be addressed by this 
> document?  If yes, then an out of band mechanism is needed to let the 
> host know what default router to use for a destination D.  One out of 
> band mechanism is use an MSR to signal a specific route to the host.
>
> Did I miss anything?

I am not at all worried about "destination D". Destination based routing 
we know how to do already, we can always add an IGP.

Source based routing is more magic.

Your above text is approximately what I envisioned how things could work, 
and I do think there needs to be text somewhere that describes this. I am 
though worried that it would require quite a lot of work to implement this 
because of the decoupling between DHCPv6 and routing as I mentioned 
before, since for instance on Linux the kernel handles RA and DHCP client 
runs in userspace. They will need to invent new APIs or move things around 
to handle what we're requiring here.

Anyhow, the above text seems fine to me from a technical point of view, 
nothing pops up as weird or wrong anyway. I think it needs a second look 
over before it's ready for publishing?

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