IETF Logo Mail Archive

Re: [v6ops] control and security of DHCP

Alexandru Petrescu <alexandru.petrescu@gmail.com> Fri, 10 January 2014 09:09 UTC

Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE7431ACCFF for <v6ops@ietfa.amsl.com>; Fri, 10 Jan 2014 01:09:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.683
X-Spam-Level:
X-Spam-Status: No, score=-4.683 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvQz9zT5hzLs for <v6ops@ietfa.amsl.com>; Fri, 10 Jan 2014 01:09:53 -0800 (PST)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 2D66A1A1F5D for <v6ops@ietf.org>; Fri, 10 Jan 2014 01:09:53 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s0A99g1k007603; Fri, 10 Jan 2014 10:09:42 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 7E715206FFE; Fri, 10 Jan 2014 10:10:44 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 6E19520324C; Fri, 10 Jan 2014 10:10:44 +0100 (CET)
Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s0A99f8a020076; Fri, 10 Jan 2014 10:09:42 +0100
Message-ID: <52CFB8D5.70900@gmail.com>
Date: Fri, 10 Jan 2014 10:09:41 +0100
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Vízdal Aleš <ales.vizdal@t-mobile.cz>, Mikael Abrahamsson <swmike@swm.pp.se>
References: <7DE31D3E-EB5B-40FD-8C94-FAB0724F7E30@gmail.com> <52CD7462.7050304@gmail.com> <20140108172808.GA81676@Space.Net> <52CEA1D2.3000109@gmail.com> <52CEA420.5020305@fud.no> <52CEB1EE.1070708@gmail.com> <alpine.DEB.2.02.1401091530220.20074@uplift.swm.pp.se> <52CEB6C1.8050105@gmail.com> <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz>
In-Reply-To: <1808340F7EC362469DDFFB112B37E2FCDA31A30EB1@SRVHKE02.rdm.cz>
Content-Type: text/plain; charset="ISO-8859-2"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, Pete Vickers <peter.vickers@gmail.com>
Subject: Re: [v6ops] control and security of DHCP
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 10 Jan 2014 09:09:56 -0000

Le 09/01/2014 18:15, Vízdal Aleš a écrit :
>> -----Original Message-----
>> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of
>> Alexandru Petrescu
>> Sent: Thursday, January 09, 2014 3:49 PM
>> To: Mikael Abrahamsson
>> Cc: v6ops@ietf.org; Pete Vickers
>> Subject: Re: [v6ops] control and security of DHCP
>>
>> Le 09/01/2014 15:33, Mikael Abrahamsson a écrit :
>>> On Thu, 9 Jan 2014, Alexandru Petrescu wrote:
>>>
>>>> But why should there be a PIO in the RA if nobody is
>> allowed to use
>>>> it anyway for configuring an address?  Noise?
>>>
>>> RA is used for routing.
>>
>> Well, that's a principle put very briefly, but in details one
>> may notice that RA is used for other less-routingly aspects
>> such as MTU which is a pure local variable. (and which DHCP
>> doesnt do either).
>
> As MTU is usually link specific, RA/ICMPv6 seems to be a good fit.

Yes.  link-specific vs network-specific I suppose?

Isn't MTU part of PMTUD which is network-specific?

DHCP seems a good fit to provide MTU as well.

>>> The only mechanism that can configure routing is RA.
>>
>> Well, as you discuss, it reads head-on with a routing
>> protocol... Many say that it is not that good for RA to
>> configure routing.
>>
>> Actually, if you take your statement that RA is used to
>> configure routing and extend it to new work at IETF, you'd
>> realize that RA is claimed to do routing which is actually
>> very little of more real routing.
>>
>> RA does routing without computing shortest paths, without
>> avoiding loops, without avoiding split horizon, without
>> converging, without exchanging route databases, etc.
>
> RA does provide the host with routing information. It is not a dynamic
> routing protocol as per your description above.

Right, but routing would not work without a good dynamic routing protocol.

It would make little sense to have good RAs without being backed by a 
good dynamic routing protocol, right?  And, since other parts of this 
dynamic routing would need Prefix Delegation (which is exclusively a 
DHCP or OSPF feature, not RA), one may find that it may make little 
sense for RA to provide routing.  In some contexts where DHCP and OSPF 
already prevail.

Alex

>
>> Alex
>
> Ales
>
>

v2.23.0 | Report a Bug | By Email