IETF Logo Mail Archive

Re: [dhcwg] DHCPv6 router option

Thomas Narten <narten@us.ibm.com> Fri, 20 March 2009 18:00 UTC

Return-Path: <narten@us.ibm.com>
X-Original-To: dhcwg@core3.amsl.com
Delivered-To: dhcwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAAA33A6C11 for <dhcwg@core3.amsl.com>; Fri, 20 Mar 2009 11:00:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.199
X-Spam-Level:
X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 fHhdcnTo5FAj for <dhcwg@core3.amsl.com>; Fri, 20 Mar 2009 11:00:49 -0700 (PDT)
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) by core3.amsl.com (Postfix) with ESMTP id D06C53A682D for <dhcwg@ietf.org>; Fri, 20 Mar 2009 11:00:48 -0700 (PDT)
Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e4.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id n2KHwfjX016709 for <dhcwg@ietf.org>; Fri, 20 Mar 2009 13:58:41 -0400
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n2KI1YoS180090 for <dhcwg@ietf.org>; Fri, 20 Mar 2009 14:01:34 -0400
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n2KI1YNv026799 for <dhcwg@ietf.org>; Fri, 20 Mar 2009 14:01:34 -0400
Received: from cichlid.raleigh.ibm.com (sig-9-76-148-145.mts.ibm.com [9.76.148.145]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n2KI1XmL026681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Mar 2009 14:01:34 -0400
Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.2/8.12.5) with ESMTP id n2KI1VQ5025391; Fri, 20 Mar 2009 14:01:32 -0400
Message-Id: <200903201801.n2KI1VQ5025391@cichlid.raleigh.ibm.com>
To: Iljitsch van Beijnum <iljitsch@muada.com>
In-reply-to: <E206991E-081C-4EFC-81AD-7559DCBDD864@muada.com>
References: <E206991E-081C-4EFC-81AD-7559DCBDD864@muada.com>
Comments: In-reply-to Iljitsch van Beijnum <iljitsch@muada.com> message dated "Wed, 11 Mar 2009 16:38:35 +0100."
Date: Fri, 20 Mar 2009 14:01:31 -0400
From: Thomas Narten <narten@us.ibm.com>
Cc: DHC WG <dhcwg@ietf.org>, Ralph Droms <rdroms@cisco.com>
Subject: Re: [dhcwg] DHCPv6 router option
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Mar 2009 18:00:49 -0000

Iljitsch van Beijnum <iljitsch@muada.com> writes:

> The ability to put a random address in DHCPv6 that is supposed to be a  
> router, but which in actuality may or may not be a working router is a  
> huge step backwards from the current situation where routers  
> themselves announce their existance and therefore there is a  
> reasonable expectation that they are, in fact, working routers.

When ND was designed, it was felt that even routers that advertised
themselves could not be trusted. I.e., they might well say they are a
default router, but then blackhole packets sent to them. Hence, ND
includes Neighbor Unreachability Detection. And the notion of a
Default Router List.

All the RA does, is place a router on the client's Default Router
List. When the client needs a router, it selects one from the list. If
it turns out that the chosen router doesn't actually work, NUD takes
over and a new (different) router is selected. That is how you get
better robustness with IPv6 and routers.

The DHCPv6 option that we are proposing does nothing more than add a
router to the client's Default Router List. If that router doesn't
actually work, it is intended that client will behave just like above
and select another router. Thus, if the client has at least one
working router, it will use that one, regardless of how it learned of
it. It will not use routers that do not deliver packets.

Thus, I don't quite get the hysteria that this option is going to
"break" your network.

> What I suggest is that you change the draft such that router  
> advertisements are still required, but the DHCPv6 option indicates  
> which of the routers that advertise their presence a host should
> use.

As others of said, this would undermine a key operational requirement,
namely, the site doesn't want to use RAs at all.

> I'm also missing any discussion about dead neighbor detection, which  
> would normally make a host select a different default router.

It was 100% intended by the authors that NUD be done with DHC-learned
default routers just as with RA-learned default routers. We will make
that more clear in the next version.

Thomas

v2.23.0 | Report a Bug | By Email