Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published

Marc Blanchet <marc.blanchet@viagenie.ca> Tue, 27 March 2012 12:05 UTC

Return-Path: <marc.blanchet@viagenie.ca>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32A4721E81BA for <mif@ietfa.amsl.com>; Tue, 27 Mar 2012 05:05:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.548
X-Spam-Level:
X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 x86QlnKEvSmu for <mif@ietfa.amsl.com>; Tue, 27 Mar 2012 05:05:56 -0700 (PDT)
Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id 64E6E21E81BB for <mif@ietf.org>; Tue, 27 Mar 2012 05:05:56 -0700 (PDT)
Received: from dhcp-51c6.meeting.ietf.org (dhcp-51c6.meeting.ietf.org [130.129.81.198]) by jazz.viagenie.ca (Postfix) with ESMTPSA id A75DE40054; Tue, 27 Mar 2012 08:05:55 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: multipart/alternative; boundary="Apple-Mail=_A029AF96-F446-4CC0-AE2D-21DB10C75CBE"
From: Marc Blanchet <marc.blanchet@viagenie.ca>
In-Reply-To: <4F71A8D1.6000807@gmail.com>
Date: Tue, 27 Mar 2012 14:05:54 +0200
Message-Id: <3BA5CC86-1D2F-4DC1-8117-2C55218224BA@viagenie.ca>
References: <20120224101611.22703.52041.idtracker@ietfa.amsl.com> <4F47688B.10508@gmail.com> <4F5E2F61.9040009@gmail.com> <CAAedzxqSPqPp1f34Z1Fm1h87mOB0aESfivZQMZmYAh7DNLv1ZQ@mail.gmail.com> <4F71A8D1.6000807@gmail.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
X-Mailer: Apple Mail (2.1257)
Cc: mif@ietf.org
Subject: Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Mar 2012 12:05:57 -0000

Le 2012-03-27 à 13:47, Alexandru Petrescu a écrit :
> 
> When setting up routes one would like to make sure they're right and
> they lead somewhere at least most of the time.  At the smart end node
> and dumb network, there should always exist a fallback and that fallback
> is typically the default route ("when everything else fails").
> 
> In this sense, if the end node sets up its routes with DHCP, it would
> like to be sure they're right most of the time, otherwise use the
> default route.
> 
> But when the default route _and_ the other more specific routes are
> provided by DHCP, and if failing, then there is a risk of misconfiguration.

yes and no.  ipv6 stack is pretty good in actively tracking if routers are up. 

in fact, having the default route or not does not change the basic issue, which is, to me, a trust issue.

say for example that you have two different types as you suggest: one for more specific routes and one for default route.
well, if the dhcpv6 server sends you a specific route such as 2000::/3, it is almost a default route, and moreover, it will be preferred over the (good,appropriate) default routes. 
Therefore, a specific type does not help the problem.

So your proposal does not help the root issue which is, to me, does the node trust the dhcpv6 server for routes insertions.

Marc.


> 
> Something that could be done about this is the use of different Types in
> DHCP (ORO) for specific routes and a different Type for default routes.
> This would mean not only that the config file owuld have different
> sections for default routes vs specific routes (thus guide  the Server's
> administrator to double check the default part) but also the DHCP Client
> implementation to have separate software sections for specific routes vs
> default routes.  Some lighter DHCP Clients may choose to implement
> _only_ the default route option part (and not the specific route part).
> 
> With respect to this there was also a question about compliance with
> specs - if a stack doesn implement eg ICMP Redirect then it's not
> compliant.  Do we want to ensure the same level of strength in
> compliance with DHCP?   Even for low end devices?
> 
> Alex
> 
> _______________________________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif